Configurare l'autenticazione multifattore¶
L'autenticazione multifattore (MFA) richiede all'utente una seconda prova oltre al suo identificativo e alla sua password. CyberElements Bastion offre diversi modi per ottenerla. Questa pagina ne tratta quattro, nell'ordine in cui vengono solitamente presi in considerazione, poi descrive in dettaglio quello che non dispone di una pagina di integrazione propria: la password monouso inviata via e-mail.
Quattro fattori, non il quadro completo
Questi quattro sono quelli che questa pagina illustra — non sono i soli secondi fattori che la piattaforma può richiedere. Sono inoltre disponibili, ma fuori dall'ambito di questa pagina:
- un OTP inviato tramite SMS, attraverso uno dei numerosi operatori proposti dal modulo OTP Token Generators;
- un connettore Radius verso una soluzione MFA di terze parti, tramite il tipo OTP - Radius dello stesso modulo;
- l'autenticazione tramite certificato x509, che non è un token ma un metodo di autenticazione del dominio stesso — User certificate, oppure User certificate and form per conservare anche la password;
- un'MFA imposta a monte da un provider SAML, o da qualsiasi altra autenticazione delegata. Il secondo fattore viene allora richiesto prima che intervenga la piattaforma, che non lo configura né lo vede.
L'MFA si imposta sul dominio di autenticazione, mai su un utente
Qualunque fattore si scelga, viene abilitato su un dominio di autenticazione e si applica a ogni utente che vi accede. Non esiste un'impostazione per singolo utente: per sottoporre all'MFA solo una parte della propria popolazione, collocare quegli utenti dietro un dominio di autenticazione dedicato.
Scegliere un fattore¶
| Fattore | Che cosa fa l'utente | Che cosa richiede | Procedura |
|---|---|---|---|
| Neomia Pulse | Nulla. L'utente viene riconosciuto dal modo in cui digita sulla tastiera. | L'opzione Neomia Pulse, le impostazioni di connessione al proprio servizio Pulse, un dominio di autenticazione di tipo local o LDAP e un secondo fattore di questa tabella sullo stesso dominio. |
Integrazione di Neomia Pulse |
| FIDO2 | Presenta il proprio autenticatore — inserendo una chiave di sicurezza, oppure approvando sul dispositivo o sul vault che contiene la passkey — poi immette un PIN se l'autenticatore lo richiede. | Un autenticatore FIDO2 per utente, una relying party dichiarata nella console e un account personale — un dominio di autenticazione anonimo è escluso. | Integrazione di Yubico |
| TOTP | Legge un codice di sei cifre in un'applicazione di autenticazione. | Un'applicazione sul telefono o sulla postazione di lavoro dell'utente (Google Authenticator, FreeOTP, Microsoft Authenticator e così via) e una registrazione per utente. | Integrazione di Google Authenticator |
| OTP via e-mail | Copia un codice ricevuto via e-mail. | Un server SMTP raggiungibile dalla piattaforma e un indirizzo e-mail contenuto in un attributo utente. | Configurare un OTP via e-mail |
Neomia Pulse si configura sopra un altro fattore
L'abilitazione di Neomia Pulse richiede che un'altra MFA sia abilitata sullo stesso dominio. Le sue impostazioni decidono poi a che cosa serve quell'altro fattore: può essere ignorato quando Pulse convalida l'utente e richiesto quando Pulse non lo fa. Neomia Pulse è quindi un modo per risparmiare il secondo fattore anziché per sostituirlo.
Dove si dichiara ciascun fattore e dove si abilita¶
La configurazione prevede due fasi possibili — dichiarare il fattore nel proprio modulo, poi abilitarlo sul dominio di autenticazione — ma due dei quattro ne saltano una:
| Fattore | Dichiarato in | Abilitato sul dominio di autenticazione |
|---|---|---|
| Neomia Pulse | nulla da dichiarare | ✅ l'opzione Enable neomia Pulse authentication, più le impostazioni di connessione al servizio Pulse — vedere la nota sottostante |
| FIDO2 | Relying parties | ❌ nulla da abilitare — vedere la nota sottostante |
| TOTP | OTP Token Generators | ✅ come token di autenticazione |
| OTP via e-mail | un server SMTP, poi OTP Token Generators | ✅ come token di autenticazione |
FIDO2 non ha alcun interruttore sul dominio di autenticazione
Le chiavi di sicurezza non si abilitano provider per provider: la piattaforma propone il fattore non appena è dichiarata almeno una relying party, su ogni dominio di autenticazione che non sia anonimo — una chiave deve essere associata a un account personale. Ed è l'utente che registra il proprio autenticatore dal portale, non l'amministratore che glielo assegna.
Neomia Pulse non ha nulla da dichiarare in anticipo
Pulse non è un token da creare in un modulo: l'opzione si abilita direttamente sul dominio di autenticazione, dove se ne imposta anche il comportamento.
Pulse richiede le proprie impostazioni di connessione
La selezione di Enable neomia Pulse authentication rivela tre campi obbligatori che indirizzano la piattaforma al proprio servizio Pulse:
| Campo | Che cosa immettere |
|---|---|
| API URL | URL dell'API Pulse. |
| Authentication API URL | URL dell'API di autenticazione Pulse. |
| API key | Chiave che autentica la piattaforma presso tale servizio. |
Il dominio di autenticazione non viene salvato finché i tre campi non sono compilati.
Il resto di questa pagina tratta l'OTP via e-mail dall'inizio alla fine. Gli altri tre fattori sono trattati nella rispettiva pagina di integrazione, collegata nella tabella precedente.
Configurare un OTP via e-mail¶
Un OTP via e-mail invia all'utente un codice monouso via e-mail una volta accettati il suo identificativo e la sua password. L'utente immette tale codice nel portale per completare l'accesso.
Prima di iniziare: che cosa protegge davvero un OTP via e-mail¶
Un OTP via e-mail non aggiunge sempre un fattore
Leggere quanto segue prima di scegliere questo fattore anziché gli altri tre.
Se l'utente accede con il proprio account Active Directory e recupera il codice da una casella di posta associata a quello stesso account, il secondo fattore aggiunge quasi nulla: un attaccante che ha ottenuto le credenziali apre la casella di posta proprio con quelle credenziali e legge il codice.
Vale la pena di distribuire un OTP via e-mail quando la casella di posta non è raggiungibile con le credenziali che vengono verificate, ossia quando:
- l'utente accede con un account locale, o con un account distinto dalla propria casella di posta;
- il codice viene inviato a un indirizzo diverso da quello appartenente all'account di accesso.
Passaggio 1 — Disporre di un server SMTP¶
Il codice viene inviato dalla piattaforma tramite un server SMTP dichiarato nel modulo SMTP servers. Se non ne è ancora disponibile alcuno, dichiararne uno prima di proseguire:
Configurare l'invio delle e-mail
Utilizzare quindi il blocco SMTP configuration test di quel modulo per confermare la consegna: un errore diagnosticato in questa fase è un errore che non si dovrà cercare più avanti nel flusso di accesso.
Il messaggio di prova non utilizza il mittente che si configurerà
Il test invia da noreply@cleanroom.com, un indirizzo fissato nel prodotto: non può essere modificato in alcun punto e serve anche come indirizzo di risposta. Il proprio mittente è l'SMTP sender del token, impostato nel passaggio 2 — è quello che portano i messaggi OTP reali.
Vale la pena di conoscere la conseguenza prima di trarre conclusioni: un server SMTP che limita gli indirizzi di invio può rifiutare il test lasciando passare i messaggi reali, e viceversa.
La connessione viene aperta dalla piattaforma
Il flusso verso il server SMTP parte dalla piattaforma, non dalla postazione di lavoro dell'utente. Se il proprio server SMTP si trova sulla propria LAN, tale flusso deve essere autorizzato.
Passaggio 2 — Creare il token OTP¶
Aprire il modulo OTP Token Generators e fare clic su +. Nella finestra Add OTP token, selezionare il tipo OTP - email, quindi compilare i campi.
| Campo | Che cosa immettere |
|---|---|
| OTP Type | OTP - email. Questa scelta non può essere modificata in seguito — un canale diverso significa un token diverso. |
| Name | Il nome del token. Viene mostrato all'utente nel portale, quindi dovrebbe leggersi come il nome di un fattore anziché come un riferimento interno. |
| Description | Testo libero, visibile solo agli amministratori. |
| OTP usable characters | L'alfabeto da cui viene estratto il codice. |
| OTP Length | Il numero di caratteri del codice. |
| Validity period of a token (seconds) | Il tempo di cui dispone l'utente per immettere il codice prima che venga rifiutato. |
| Message before the OTP | La frase che precede il codice nel corpo del messaggio. |
| Mail subject | L'oggetto del messaggio. |
| SMTP sender | L'indirizzo del mittente del messaggio. |
| SMTP server | Il server dichiarato nel passaggio 1. |
L'elenco completo dei campi, con i rispettivi valori predefiniti e vincoli, si trova nella pagina di riferimento: Blocco generico e Invio via e-mail.
Fare clic su Validate per salvare il token.
Passaggio 3 — Abilitare il token su un dominio di autenticazione¶
Aprire il modulo Authentication domain e modificare il dominio che deve richiedere l'OTP.
| Campo | Che cosa immettere |
|---|---|
| Authentication token | Il token creato nel passaggio 2. È possibile selezionare più token. |
| User attribute used to send the OTP | Il nome dell'attributo utente che contiene l'indirizzo a cui viene inviato il codice. |
| Token expiration duration | Per quanto tempo un OTP convalidato resta accettato prima di essere richiesto di nuovo. 0 disabilita la scadenza, il che significa che l'OTP viene richiesto a ogni accesso. |
| Time unit | Hours o Days, applicati al campo precedente. |
| Expiration starts | Se il conto alla rovescia parte dall'ultima convalida dell'OTP oppure dall'ultimo accesso riuscito. |
Quale attributo contiene l'indirizzo
L'attributo è quello della directory a cui punta il dominio di autenticazione, non un nome di nostra scelta: utilizzare l'attributo in cui i propri utenti hanno effettivamente un indirizzo. Per una directory locale, l'indirizzo immesso nelle proprietà dell'utente è quello da indicare; per una directory LDAP è l'attributo mail della directory stessa.
Fare clic su Validate. Agli utenti di quel dominio di autenticazione viene richiesto un codice al successivo accesso.
Passaggio 4 — Verificare prima su un dominio di autenticazione di prova¶
L'abilitazione dell'MFA su un dominio di autenticazione la applica a tutti gli utenti che vi si trovano dietro, compresi se stessi se si accede tramite esso. Prima di abilitare il token sul dominio di produzione, creare un dominio di autenticazione di prova contenente un solo account ed eseguirvi un accesso completo: identificativo, password, ricezione del messaggio, immissione del codice.
Un utente senza indirizzo non riceve mai un codice
A un utente il cui attributo è vuoto non può essere inviato nulla e il suo accesso non può essere completato. Verificare che l'attributo sia compilato per ogni account dietro il dominio di autenticazione prima di abilitarvi il token.