Utenti amministrativi

Utenti amministrativi#

NethSecurity consente agli utenti locali di ottenere l’accesso amministrativo all’interfaccia web. Gli utenti amministrativi dovrebbero essere account personali assegnati ai singoli operatori, in modo che le azioni possano essere attribuite a uno specifico utente nei log.

Questa pagina spiega come funzionano gli utenti amministrativi, come l’MFA si applica agli amministratori, come vengono registrate le azioni amministrative e come ricostruire l’attività degli amministratori per scopi di troubleshooting e audit.

Tipi di account amministrativi#

NethSecurity utilizza i seguenti tipi di account amministrativi:

  • root: account di sistema locale. Dovrebbe essere riservato, ove possibile, alle operazioni di emergenza o di ripristino.

  • Utenti amministrativi: utenti locali con l’opzione Utente amministratore abilitata. Possono accedere all’interfaccia utente di NethSecurity ed eseguire operazioni amministrative.

  • Utenti non amministrativi: utenti locali o remoti utilizzati per servizi come VPN o autenticazione, senza accesso all’interfaccia utente di NethSecurity.

Nota

L’accesso amministrativo dovrebbe essere concesso solo a operatori affidabili.

Creazione di utenti amministrativi#

Gli utenti amministrativi vengono creati dal database utenti locale.

Per creare un utente amministrativo:

  1. Creare un utente locale.

  2. Impostare una password per l’utente.

  3. Abilitare l’opzione Utente amministratore.

  4. Salvare la configurazione.

Per informazioni generali sui database utenti locali e remoti, consultare users_databases-section.

Interfaccia utente NethSecurity 2FA#

Proteggere l’account amministratore di NethSecurity è fondamentale, e l’Autenticazione a Due Fattori (2FA) aggiunge un ulteriore livello di sicurezza oltre alla sola password. La 2FA richiede due passaggi di verifica durante l’accesso. Oltre alla password, sarà necessario inserire anche un codice temporaneo generato da un’app separata sul proprio smartphone o tablet. Questo riduce significativamente il rischio di accessi non autorizzati anche nel caso in cui la password venga compromessa.

Abilitazione dell’autenticazione a due fattori (2FA) nell’interfaccia utente di NethSecurity:

  • Accedere all’interfaccia web di NethSecurity

  • Fare clic sull’icona utente nell’angolo in alto a destra e selezionare Impostazioni account

  • Individuare l’opzione Autenticazione a due fattori e fare clic su Configura 2FA

Configurazione dell’app di autenticazione:

  • Scaricare un’app di autenticazione sul proprio smartphone o tablet. Opzioni popolari includono FreeOTP, Google Authenticator e Microsoft Authenticator.

  • Aprire l’app e scansionare il codice QR visualizzato sull’interfaccia web di NethSecurity. Questo aggiungerà l’account NethSecurity all’app di autenticazione.

  • Inserire il codice a 6 cifre visualizzato dall’app di autenticazione nel campo One-Time Password (OTP) dell’interfaccia web di NethSecurity.

Il sistema fornirà anche un set di codici di backup. Questi codici possono essere utilizzati per accedere nel caso in cui si perda lo smartphone o l’app di autenticazione. Conservare questi codici in modo sicuro, preferibilmente offline.

Disabilitare l’autenticazione a due fattori (2FA) tramite l’interfaccia web#

Se l’amministratore può ancora accedere all’interfaccia web:

  1. Fare clic sull’icona utente nell’angolo in alto a destra e selezionare Impostazioni account.

  2. Scorrere fino alla sezione Autenticazione a due fattori.

  3. Fare clic su Revoca 2FA.

  4. Viene visualizzata una finestra di conferma che avverte che il livello di sicurezza sarà ridotto. Fare clic su Revoca 2FA per confermare.

  5. Se richiesto, inserire la password attuale per autorizzare la modifica.

Dopo la conferma, il badge di stato cambia in disabilitato e al prossimo accesso non sarà più richiesto un OTP.

Disabilitare l’autenticazione a due fattori (2FA) dalla riga di comando (recupero d’emergenza)#

Se un amministratore ha perso sia il dispositivo OTP che i codici di recupero e non può più accedere all’interfaccia web, l’autenticazione a due fattori (2FA) può essere reimpostata direttamente dalla shell come root tramite SSH.

Eseguire i seguenti comandi, sostituendo <username> con il nome dell’account amministratore (utilizzare root per l’amministratore predefinito):

SECRETS_DIR=/etc/ns-api-server
USERNAME=root   # change to the affected username

rm -f  "${SECRETS_DIR}/${USERNAME}/secret"
rm -f  "${SECRETS_DIR}/${USERNAME}/codes"
printf '0' > "${SECRETS_DIR}/${USERNAME}/status"

Dopo questi comandi, l’utente può accedere solo con la propria password. L’autenticazione a due fattori (2FA) può essere riattivata in qualsiasi momento dall’interfaccia web.

Nota

Solo l’account root ha accesso SSH per impostazione predefinita. Gli amministratori non-root non possono essere recuperati tramite SSH dall’utente interessato stesso; è necessaria una sessione root esistente per eseguire i comandi sopra indicati per loro conto.

Accesso root e di emergenza#

L’account root è l’account principale del sistema locale; dovrebbe essere utilizzato solo come account di emergenza o per il recupero e non dovrebbe essere impiegato per le normali attività amministrative quando sono disponibili utenti amministrativi personali. Utilizzare account amministrativi personali per le operazioni quotidiane, in modo che le azioni possano essere attribuite ai singoli utenti nei log.

Registrazione delle attività amministrative#

NethSecurity registra l’attività amministrativa eseguita tramite l’interfaccia web in /var/log/messages. I log amministrativi possono supportare la risoluzione dei problemi, l’analisi degli incidenti e la ricostruzione degli audit.

Dove trovare i log amministrativi#

I log vengono scritti in /var/log/messages e ruotati su base settimanale; sono visibili dall’interfaccia utente nella sezione dedicata. Per visualizzare gli eventi dell’interfaccia amministrativa, utilizzare il filtro nethsecurity-api.

Per la conservazione a lungo termine e l’audit centralizzato, configurare l’archiviazione persistente dei log, l’inoltro remoto tramite syslog, l’inoltro dei log del Controller o Cloud Log Manager. Per dettagli, vedere Log.

Ricostruzione delle azioni dell’amministratore#

Per ricostruire l’attività dell’amministratore, iniziare dall’evento di accesso e poi esaminare i successivi eventi di autorizzazione e commit tramite UI/API per lo stesso utente; i log permettono di rispondere a domande come:

  • chi ha effettuato l’accesso;

  • quando l’amministratore ha effettuato l’accesso al firewall;

  • quali pagine dell’interfaccia utente o funzioni API sono state utilizzate;

  • quali aree di configurazione sono state modificate;

  • quali valori sono stati inviati;

  • se una modifica è stata confermata;

  • se l’azione è stata seguita da errori di servizio o eventi di sicurezza.

Ogni volta che un amministratore accede all’interfaccia utente di NethSecurity, il sistema registra l’evento all’interno del file /var/log/messages. Esempio di evento di accesso per l’utente goofy:

Jun 21 09:43:19 NethSec nethsecurity-api[5376]: nethsecurity_api 2024/06/21 09:43:19 middleware.go:78: [INFO][AUTH] authentication success for user goofy
Jun 21 09:43:19 NethSec nethsecurity-api[5376]: nethsecurity_api 2024/06/21 09:43:19 middleware.go:186: [INFO][AUTH] login response success for user o

Esempio di evento di logout per l’utente goofy:

Jun 21 09:46:13 NethSec nethsecurity-api[5376]: nethsecurity_api 2024/06/21 09:46:13 middleware.go:214: [INFO][AUTH] logout response success for user goofy

Inoltre, ogni azione eseguita da un amministratore all’interno dell’interfaccia NethSecurity viene registrata nel file /var/log/messages. Esempio di azione eseguita dall’utente goofy:

Jun 21 09:43:19 NethSec nethsecurity-api[5376]: nethsecurity_api 2024/06/21 09:43:19 middleware.go:170: [INFO][AUTH] authorization success for user goofy. POST /api/ubus/call {"path":"ns.dashboard","method":"service-status","payload":{"service":"internet"}}

Raccomandazioni per audit e conformità#

Per le distribuzioni orientate all’audit:

  • creare un account amministrativo personale per ciascun operatore;

  • evitare account amministrativi condivisi;

  • abilitare l’MFA per tutti gli utenti amministrativi;

  • riservare root per operazioni di emergenza o di ripristino, ove possibile;

  • utilizzare password robuste e proteggere i codici di recupero;

  • configurare l’archiviazione persistente dei log o l’inoltro remoto dei log;

  • inoltrare i log a un server syslog remoto, SIEM, Controller o Cloud Log Manager;

  • verificare che l’inoltro dei log funzioni correttamente;

  • assicurarsi che data, ora e fuso orario siano corretti, preferibilmente utilizzando NTP;

  • definire la conservazione dei log secondo la policy di sicurezza dell’organizzazione;

  • proteggere i log remoti da accessi non autorizzati o dalla cancellazione;

  • esaminare periodicamente i log di accesso amministrativo e delle modifiche alla configurazione.

I log di NethSecurity possono supportare la ricostruzione degli audit e l’analisi degli incidenti. I processi organizzativi come l’approvazione delle modifiche, la revisione periodica, la classificazione degli incidenti e la conservazione delle evidenze rimangono di responsabilità dell’organizzazione che gestisce il firewall.

Limitazioni attuali#

I log delle attività amministrative sono log tecnici destinati a supportare la risoluzione dei problemi e la ricostruzione degli audit.

Gli amministratori devono essere a conoscenza delle seguenti limitazioni:

  • NethSecurity attualmente non fornisce un modello RBAC locale completo per gli amministratori web;

  • un ruolo amministratore locale dedicato in sola lettura non è attualmente disponibile;

  • gli utenti amministrativi dovrebbero quindi essere assegnati solo a operatori affidabili;

  • alcune voci di log potrebbero richiedere una correlazione con i log di commit della configurazione o con i log dei servizi correlati;

  • un evento di autorizzazione significa che la richiesta API è stata consentita, ma è necessario controllare i log correlati per confermare l’effetto finale dell’operazione;

  • non tutte le voci di log necessariamente contengono gli stessi campi;

  • i log locali in memoria potrebbero andare persi dopo un riavvio o una rotazione, a meno che non sia configurato uno storage persistente o l’inoltro remoto.

Per requisiti di audit a lungo termine, utilizzare l’inoltro remoto dei log o Cloud Log Manager oltre ai log locali.