Steven LafortuneGli account privilegiati non vengono compromessi nella schermata di accesso. Vengono compromessi dopo l’accesso: quando una sessione viene dirottata, un dispositivo viene lasciato sbloccato, oppure le credenziali vengono condivise con un po’ troppa disinvoltura. È questa la lacuna che l’MFA al checkout PAM è pensato per chiudere: invece di fidarsi di chiunque si trovi già all’interno del perimetro, Devolutions verifica ora nuovamente l’identità, esattamente nel momento in cui qualcuno richiede l’accesso a un account privilegiato.
Il problema che l’MFA al checkout risolve
L’MFA standard al login dimostra chi si è autenticato all’inizio della giornata. Non dimostra chi si trova davanti alla tastiera un’ora dopo, quando arriva una richiesta di checkout privilegiato. Per gli account sensibili — amministratori di dominio, account di servizio, tutto ciò che dispone di diritti elevati — questa lacuna è importante. Richiedere una nuova verifica MFA esattamente nel momento del checkout la chiude: la verifica ora segue la richiesta di accesso stessa, non solo l’autenticazione iniziale.
Attivare l’MFA per il checkout
In Devolutions Server:
- Assicurarsi che gli utenti abbiano un metodo MFA configurato, sia per singolo utente (
Administration – Users – Multifactor), sia imposto a livello globale tramiteAdministration – Configuration – Server Settings – Security – Conditional Access Policies(impostare l’obiettivo MFA su Required, Optional per user, o Skipped). - Aprire le proprietà del provider PAM o della voce e andare alla scheda Checkout policy.
- Attivare l’opzione che richiede l’MFA al checkout.
- Salvare. Il requisito si applica alla successiva operazione di checkout di quella voce.
In Devolutions Cloud: la stessa logica si applica tramite Administration – Configuration – Security – Authentication, dove è possibile attivare la verifica MFA per l’avvio delle voci sensibili. I metodi supportati includono e-mail e TOTP, con altri provider di identità coperti tramite le opzioni MFA più ampie della piattaforma (Yubikey, Duo, Radius e altri, in base alla configurazione).
Cosa succede quando un utente effettua il checkout di un account
Il flusso di checkout in sé non cambia in superficie: l’utente seleziona la voce, sceglie una durata e invia un motivo o un numero di ticket, se richiesto. La novità avviene proprio lì, prima ancora che la richiesta venga inviata a chiunque. Se l’MFA è richiesto per quella voce, l’utente deve verificarsi — un codice TOTP, un codice inviato via e-mail o via SMS — come parte dell’invio della richiesta. Senza un MFA valido, la richiesta non arriva mai all’approvatore: l’identità viene confermata all’origine, non aggiunta successivamente.
Cosa vede l’approvatore
Gli approvatori non devono più chiedersi se l’identità sia stata confermata. Nel momento in cui una richiesta di checkout arriva a loro per la revisione, la verifica MFA è già avvenuta — il richiedente non avrebbe potuto inviare la richiesta altrimenti. La schermata di approvazione riflette questo aspetto, offrendo all’approvatore un’incognita in meno nella decisione e un dato in più nella traccia di audit, nel caso in cui quel checkout venga esaminato in seguito.
Perché è importante
L’MFA al checkout non sostituisce le approvazioni, la registrazione delle sessioni o le politiche di checkout già in uso, si affianca a esse come ulteriore punto di controllo, posizionato esattamente dove il rischio è più alto: il momento in cui qualcuno ottiene l’accesso a un account privilegiato. Per i team che già utilizzano Devolutions PAM, si tratta di un’opzione da attivare, non di un nuovo sistema da implementare.
Se utilizzate Devolutions PAM, vale la pena attivarla. Consultate la documentazione qui sotto per la configurazione completa, e fatecene sapere il riscontro per il vostro team.
Risorse: