Guida MikroTik
Sistema e alta affidabilitàIntermedio

Utenti e gruppi: policy, chiavi SSH e accesso sicuro

Come gestire gli account amministrativi di RouterOS con gruppi e policy granulari, autenticazione a chiave SSH, restrizione per IP sorgente e audit, per un accesso pulito e sicuro in un team WISP.

RouterOS gestisce l'accesso amministrativo con utenti assegnati a gruppi, e ogni gruppo ha un set di policy (permessi atomici). Il principio guida è il least privilege: ogni persona o sistema ha solo i permessi minimi necessari. In un WISP con tecnici, NOC e integrazioni NMS questo evita disastri e rende l'audit possibile.

Le policy disponibili (cosa permette ciascuna)

  • read — leggere la configurazione e lo stato (no modifiche).
  • write — modificare la configurazione (richiede anche read).
  • policy — gestire utenti, gruppi e policy (permesso più potente: chi ce l'ha può darsi qualsiasi diritto).
  • test — eseguire ping, traceroute, bandwidth-test, ecc.
  • password — cambiare la propria password.
  • sensitive — vedere informazioni sensibili (password, chiavi, secret PPP).
  • ssh, telnet, winbox, web, api, ftp, rest-api — i canali di accesso consentiti al gruppo.
  • reboot, sniff, romon — riavvio, packet sniffer, accesso RoMON.

Creare gruppi su misura per i ruoli del team

Gruppi: NOC (sola lettura), tecnico, NMS
# Gruppo NOC: monitoraggio in sola lettura, niente modifiche, niente sensibili
/user/group add name=noc \
    policy=read,test,winbox,ssh,web \
    comment="NOC: monitoraggio in sola lettura"

# Gruppo tecnico: può configurare ma NON gestire utenti (no policy)
/user/group add name=tecnico \
    policy=read,write,test,reboot,winbox,ssh,web,sensitive \
    comment="Tecnico: configura ma non tocca utenti/gruppi"

# Gruppo per integrazione NMS/automazione (solo API SSL, sola lettura)
/user/group add name=nms-readonly \
    policy=read,test,api,rest-api \
    comment="NMS: lettura via API per monitoraggio"
Il permesso policy è il vero 'superpotere': solo gli account owner/amministratori di piattaforma dovrebbero averlo, perché chi lo possiede può assegnarsi qualsiasi altro permesso. Non darlo mai a tecnici di campo o a integrazioni automatiche.

Creare utenti e restringerli per IP sorgente

/user add con allowed-address
# Crea un utente tecnico raggiungibile solo dalla rete NOC
/user add name=mrossi group=tecnico \
    address=10.0.0.0/24 \
    comment="Mario Rossi - tecnico campo"

# Utente NMS limitato a un singolo server (massima restrizione)
/user add name=zabbix group=nms-readonly \
    address=10.0.0.5/32 \
    comment="Account read-only per Zabbix"

# Imposta/aggiorna la password di un utente esistente
/user set mrossi password="PasswordMoltoLunga#2026"

# Verifica utenti e da quali IP possono accedere
/user print detail

Il campo address (qui chiamato anche allowed-address) è una difesa preziosa: anche se la password trapela, l'account è usabile solo dalle reti elencate. Per gli account di servizio (NMS, automazioni, il connettore WispOS) usa sempre una /32 sull'IP esatto.

Autenticazione a chiave SSH (più sicura della password)

Importare una chiave pubblica SSH
# 1) Genera la coppia di chiavi sul TUO PC (non sul router):
#    ssh-keygen -t ed25519 -C "mrossi@noc"
# 2) Carica il file id_ed25519.pub sul router (Winbox > Files o scp)
# 3) Associa la chiave pubblica all'utente
/user/ssh-keys/import user=mrossi public-key-file=id_ed25519.pub

# Verifica le chiavi importate
/user/ssh-keys print

# (Hardening) Disabilita il login SSH con sola password,
# forzando l'uso delle chiavi per gli account amministrativi
/ip/ssh set always-allow-password-login=no
/ip/ssh set strong-crypto=yes

Audit: chi è collegato e chi ha provato ad accedere

Sessioni attive e tentativi falliti
# Sessioni amministrative attualmente aperte
/user/active print

# Storico degli accessi (login riusciti e falliti) nei log
/log print where topics~"system" && topics~"account"

# Suggerimento: invia i log di account a un syslog esterno per conservarli
# (vedi articolo diag-logging-syslog)
Best practice per un WISP: (1) NON usare l'utente di default 'admin' in produzione — crea account nominali e disabilita admin o limitane l'address; (2) un account = una persona (mai credenziali condivise), così l'audit è significativo; (3) usa chiavi SSH per gli admin e password lunghe e casuali per gli account di servizio; (4) restringi sempre address alla rete di gestione; (5) revoca subito gli account di chi lascia il team. Conserva queste impostazioni anche nei template di provisioning dei nuovi router.
userutentigroupgruppipolicyrbacpermessissh keychiave sshallowed-addressadminleast privilegeconsoleRouterOS

Configura senza fatica con l'AI

In WispOS l'agente AI genera la configurazione RouterOS dalle tue parole e un tutor ti guida passo passo.

Prova WispOS