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 ancheread).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
# 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"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
# 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 detailIl 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)
# 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 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)
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.Continua con
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