La password non è mai stata l'unico problema: PAM legacy contro PAM moderno

Parte 1 di 3 della nostra serie Rethinking Privileged Access.

La conversazione sul privileged access management (PAM) ruotava originariamente attorno a una domanda: come proteggiamo la password? Custodirla in un vault. Ruotarla. Iniettarla nelle sessioni così che nessuno la veda mai. Vincolarla ad approvazioni e MFA così che solo la persona giusta possa richiederla. Il PAM legacy è una delle risposte più mature e diffuse a quella domanda.

Risolvere il problema delle password è importante, ma è lontano dall'essere l'unico. Zero trust, zero privilegi permanenti e accesso just-in-time sono maturati da quando è stato progettato il PAM legacy, che però non ha tenuto il passo.

È il bivio tra PAM legacy e PAM moderno con Netwrix Privilege Secure (NPS). Il PAM legacy ha fatto benissimo ciò per cui è stato costruito, ma fermare gli attacchi moderni richiede uno strumento progettato per altro.

PAM legacy: proteggere la password

Il PAM legacy parte da un presupposto: gli account privilegiati esistono in modo permanente e il tuo compito è proteggerli il meglio possibile. Se oggi un account è membro di Domain Admins, lo sarà anche domani, la settimana prossima e l'anno prossimo, che qualcuno usi quel privilegio o no. Il PAM legacy agisce come un guardiano rigoroso davanti a quel privilegio permanente.

In pratica, questo controllo si presenta così:

• Un utente deve accedere a un account privilegiato. Prima di tutto servono i permessi giusti all'interno dello strumento PAM, tramite assegnazioni di ruolo o accesso a livello di cartella al segreto.
• A seconda della policy, potrebbe dover superare l'MFA prima di procedere.
• Richiede l'accesso al segreto (un check-out), che può richiedere l'approvazione di uno o più approvatori designati.
• Una volta approvato, di norma l'utente non vede mai la password. Lo strumento avvia una sessione RDP o SSH e inietta direttamente la credenziale al suo interno.
• Il check-out ha un limite di tempo. Quando l'utente termina o il tempo scade, lo strumento riporta il segreto nel vault (check-in).
• Dopo il check-in, lo strumento ruota la password, quindi anche una credenziale esposta durante l'uso non è più valida.

Questo modello elimina l'esposizione delle credenziali, crea una traccia di audit pulita e impone i controlli di approvazione prima che chiunque tocchi un account sensibile. Ma per quanto rigoroso sia il flusso di lavoro, l'account sottostante resta un Domain Admin (o un amministratore locale, o un sudoer) tra una sessione e l'altra. Il privilegio è permanente. Solo l'accesso alla password è temporaneo. Un amministratore può anche recuperare una password per un lavoro «veloce» al di fuori dello strumento, aggirando tutti questi controlli.

Il PAM legacy ha anche un limite netto in Active Directory. Legge l'appartenenza ai gruppi per decidere chi accede ai segreti, ma non crea, elimina né modifica i gruppi AD. L'appartenenza ai gruppi, e il privilegio permanente che ne deriva, è interamente fuori dal suo controllo.

La Parte 2 di questa serie copre gli attacchi che aggirano l'accesso alla password o che non ne hanno bisogno, e spiega perché il just-in-time e lo zero standing privilege sono così potenti.

Quando i fornitori di PAM legacy dicono «just-in-time» o «zero standing privilege», si riferiscono all'accesso alla password, non al privilegio sull'account. Ti diranno anche che un vero just-in-time richiede un prodotto separato di gestione dei privilegi sugli endpoint. Quel prodotto controlla i diritti di amministratore locale sui computer dei dipendenti. È una forma di just-in-time, ma non copre gli account che sostengono la tua infrastruttura critica, che è il compito del PAM. Netwrix offre un prodotto anche in quella categoria: Netwrix PolicyPak.

PAM moderno: Netwrix Privilege Secure elimina lo standing privilege

Netwrix Privilege Secure parte da una premessa diversa. Invece di chiedersi «come proteggiamo un account potente?», si chiede «perché un account potente deve essere potente tutto il tempo?»

NPS si concentra sulla sessione e sulle Activities, che vengono eseguite prima, durante e dopo quella sessione per concedere il privilegio esattamente quando serve e rimuoverlo nel momento in cui non serve più. NPS supporta tre approcci agli account, e ciascuno gestisce quel ciclo di vita in modo diverso.

1. Account richiedenti

È l'account che l'utente già usa per accedere al computer e alla posta, senza un account privilegiato separato. All'avvio di una sessione, un'Activity concede il privilegio al volo, per esempio aggiungendo l'utente a Domain Admins o a un altro gruppo AD privilegiato. Poiché è l'account personale dell'utente, la password non viene custodita nel vault e l'utente la inserisce durante la sessione. Al termine della sessione, NPS rimuove automaticamente il privilegio concesso all'inizio.

È spesso l'approccio più comodo dei tre, ma offre la protezione delle credenziali minore, perché la password non viene ruotata né iniettata. Elimina comunque lo standing privilege, perché l'account ha diritti elevati solo per la durata della sessione.

2. Account gestiti

È l'analogo più vicino al funzionamento del PAM legacy. All'avvio di una sessione, NPS ruota la password dell'account e lo abilita. Le Activities concedono il privilegio per quella sessione, per esempio aggiungendo l'account a Domain Admins, ad Administrators locali o a un gruppo sudo. La password viene iniettata nella sessione, quindi l'utente non la vede mai.

La differenza emerge alla fine: NPS ruota di nuovo la password e la custodisce nel vault, annulla il privilegio concesso e disabilita l'account. L'account continua a esistere, ma tra una sessione e l'altra non ha privilegi e non può autenticarsi, il che rende inutile una password rubata per un attaccante.

3. Account effimeri

Questo modello va oltre: crea un account completamente nuovo all'inizio di ogni sessione. Durante la sessione si comporta come un account gestito: il privilegio viene concesso e la password iniettata. Quando la sessione termina, NPS elimina del tutto l'account, senza lasciare nulla da attaccare.

Oltre il privilegio: cos'altro possono fare le Activities

Concedere e revocare l'appartenenza ai gruppi è la funzione principale, ma le Activities chiudono anche percorsi di attacco che i modelli di accesso permanente di solito lasciano aperti:

• Purge dei ticket Kerberos. Quando una sessione RDP termina, NPS può eliminare i ticket Kerberos dalla risorsa, tagliando un percorso di movimento laterale che non richiede la password di un account.
• Abilitazione/disabilitazione di RDP. La maggior parte dei server Windows lascia RDP attivo per impostazione predefinita. NPS può abilitarlo solo all'avvio di una sessione e disabilitarlo subito dopo, rimuovendo un'ampia superficie d'attacco sempre disponibile.
• Modalità di protezione. NPS può analizzare risorse Windows o Linux alla ricerca di account locali non approvati. Un insider malintenzionato che usa correttamente il tuo strumento PAM potrebbe creare in silenzio amministratori locali per un uso non autorizzato successivo.
• Sincronizzazione della replica dei DC. Una modifica dei privilegi su un controller di dominio non sempre si propaga subito al DC che gestisce l'autenticazione della sessione. NPS può forzare una sincronizzazione mirata, così il privilegio concesso è disponibile immediatamente invece di attendere i tempi normali di replica di AD.

Confronto

Il PAM legacy ha ridotto il rischio sulle credenziali. Il PAM moderno elimina il bersaglio.

Il modello di check-out/check-in del PAM legacy è un modo maturo e ben collaudato per ridurre l'esposizione delle credenziali e aggiungere responsabilità all'accesso privilegiato. Per molte organizzazioni è stato un grande passo avanti rispetto alle password condivise non gestite.

Netwrix Privilege Secure è costruito per gli attacchi di oggi. Tratta lo standing privilege stesso, insieme alla password che lo protegge, come la superficie d'attacco da eliminare. Che si tratti dell'account personale di un utente elevato solo per la durata di una sessione, di un account gestito reso inutile tra un utilizzo e l'altro o di un account effimero che cessa di esistere quando il lavoro è finito, la logica è la stessa: se non c'è alcun privilegio fermo ad aspettare di essere usato, non c'è nulla che un attaccante possa rubare.

Prossimamente in questa serie

Eliminare lo standing privilege interrompe molto più del flusso di check-out/check-in che il PAM legacy era progettato per proteggere. Parte 2, Oltre il vault: come NPS blocca più dei soli attacchi alle password, illustra la superficie d'attacco più ampia delle credenziali Windows e Active Directory (hash NTLM, ticket Kerberos, Kerberoasting, credenziali di dominio in cache e altro) e mappa quali di questi il modello di sessione di NPS chiude e quali no.

Poi, Parte 3 illustra come Bring Your Own Vault ti permetta di ottenere queste protezioni a livello di sessione sopra il vault che già utilizzi, senza una migrazione rip-and-replace.