Aggiornato: Azure AD Password Protection è diventato generalmente disponibile il2 aprile 2019. Il servizio è in gran parte lo stesso che ho presentato in questo post, con i seguenti aggiornamenti:
- Il limite di due deleghe è stato abolito.
- Quando si registra il proxy e la foresta Active Directory, sono ora disponibili 3 modalità di autenticazione . Due di esse supportano l'MFA, quindi non è necessario avere un account Global Admin senza MFA.
- L'algoritmo di valutazione delle password vietate è stato aggiornato. Vedere "Come vengono valutate le password" nella documentazione Microsoft. Nota: questo algoritmo può cambiare in qualsiasi momento, senza preavviso o aggiornamento della documentazione.
- Le licenze sono state semplificate: Tutti gli utenti sincronizzati con Azure AD devono avere Azure AD Premium P1 o P2. Una volta soddisfatto questo requisito, tutti gli utenti di Active Directory hanno la licenza per questo servizio.
- I clienti di Anteprima devono aggiornare gli agenti; gli agenti di Anteprima pubblica smetteranno di funzionare dopo il 1° luglio 2019.
- Le mie fonti Microsoft mi dicono che, con un po' di comunicazione preventiva, gli utenti non stanno trovando il nuovo rifiuto delle password comuni con il messaggio standard "La tua password non soddisfa i requisiti di complessità" così confuso come pensavano.
- Iniziate a distribuire!
Microsoft ha finalmente fornito un servizio che attenua il rischio di sicurezza legato alle password più critico nelle aziende: le password comuni. Dovreste provare questa nuova funzionalità di Active Directory oggi stesso, in modo da poterla implementare non appena raggiungerà la disponibilità generale.
Questo è un post lungo; se non siete interessati alla versione TL;DR (e dovreste esserlo), potete passare direttamente a
- La password comune come vettore di attacco
- Architettura
- Flusso di autenticazione in fase di esecuzione
- Processo di valutazione delle password
- Vantaggi del design
- Fasi di implementazione
- Monitoraggio
- Licenze
- Notizie varie
La password comune come vettore di attacco
Ho pubblicato in questo blog e parlato al Cloud Identity Summit (ora Identiverse) delle raccomandazioni di Microsoft e del NIST su come configurare la lunghezza delle password, la loro scadenza e altri criteri per le password alla luce delle loro ricerche e dell'esperienza sul campo. Una delle raccomandazioni principali di entrambe le organizzazioni è l'uso di un elenco di password vietate, in cui le password più semplici e comuni non sono consentite. (E sì, sono qui per dirvi che alcune delle password più comuni sono "password" e "12345678". Temo per la razza umana).
Secondo Microsoft, negli ultimi mesi gli attacchi alle password più comuni tramite attacchi "password spray" sono aumentati drasticamente. È estremamente difficile difendersi da questi attacchi con gli strumenti di sicurezza convenzionali, perché l'aggressore non colpisce un singolo account con più password. Piuttosto, utilizza poche password comuni per attaccare più account. Ogni account viene tentato solo poche volte, magari con un lungo intervallo tra un tentativo e l'altro per evitare di attivare gli avvisi. Il modo migliore per proteggersi da questi attacchi è semplicemente quello di non avere password comuni.
La maggior parte delle grandi organizzazioni utilizza un'architettura di identità ibrida in cui le password sono gestite in una foresta Active Directory on-premises. Purtroppo Active Directory non dispone di una soluzione immediata per vietare le password comuni. Di conseguenza, la maggior parte delle organizzazioni non dispone di alcuna protezione contro le password comuni.
Azure AD Password Protection è un servizio ibrido in anteprima pubblica che fornisce protezione contro le password più comuni sia per gli account organizzativi Azure AD che per gli account Windows Server Active Directory on-premises. Impedisce agli utenti e agli amministratori di modificare o reimpostare le password con password semplici e facilmente craccabili come "987654321" o "quertyjkl;" (per i dattilografi).
Architettura
Azure AD Password Protection ha un componente Azure, un servizio proxy on-premises, un servizio DC e infine un filtro password personalizzato (Figura 1):
Gli scopi di questa architettura sono: 1) utilizzare l'elenco globale di password vietate (GBPL) di Azure per proteggere gli account Azure AD dall'uso di password comuni; 2) consentire agli amministratori di Azure di creare un elenco di password vietate personalizzato che aumenti il GBPL; 3) proteggere gli account Active Directory dalle password comuni fornendo un servizio in sede che utilizza l'elenco consolidato di password vietate.
Azure
Da tempo Azure AD utilizza un elenco di password vietate generato internamente e impone il rispetto di lunghezze minime di password più elevate. Se si inserisce una password comune, si viene gentilmente avvisati di riprovare:
Il servizio di protezione delle password (Figura 3) utilizza le informazioni sulle minacce di Azure per una visione globale delle password vietate. L'elenco viene compilato a partire dalle password presenti negli elenchi di credenziali trapelate, oltre all'analisi che il sistema di intelligence sulle minacce di Azure esegue sui 20 milioni (!) di tentativi di acquisizione di account che cattura quotidianamentei. L'elenco non contiene tutte le password più comuni mai trovate, ma solo le 1000 più comuni utilizzate attivamente negli attacchi.
Perché il servizio non verifica la presenza di più di 1000 password comuni? Questo potrebbe essere pratico per Azure, ma non per i server in sede. Nel processo di valutazione delle password, la password dell'utente viene confrontata non solo con le oltre 1000 password vietate, ma anche con migliaia di varianti di ciascuna. Si tratta di un gran numero di password da confrontare. Se l'elenco delle password contiene 1 milione di password, i DC devono controllare miliardi di varianti di password e si fermerebbero per il carico di lavoro.
Il controllo e la configurazione della funzione di protezione con password sono gestiti nel blade Azure Active Directory del portale di gestione, nella nuova sezione Metodi di autenticazione. L'unica voce presente in questa nuova sezione - anche se sono sicuro che crescerà - è Protezione password (Figura 4).
Oltre all'elenco globale di password vietate (GBPL) generato da Azure, Azure AD Password Protection offre una visione a livello di tenant delle password vietate da utilizzare (TBPL). Ad esempio, un'azienda di servizi finanziari potrebbe voler vietare password come "mutuo" o "assicurazione", oltre alle password comuni determinate a livello globale da Azure. (Questo elenco consolidato è quello utilizzato in sede.
Si noti che il servizio è configurato in modo tale che se si installano componenti on-premises senza toccare i controlli Azure, il servizio di protezione delle password inizierà a funzionare immediatamente, in modalità audit, utilizzando l'elenco globale di password vietate di Azure.
Servizio proxy
Lo scopo del servizio proxy Azure AD Password Protection è acquisire la BPL e passarla ai DC. Agendo come un servizio di relay stateless, il proxy consente ai DC di ottenere la BPL da Azure AD senza dover accedere a Internet (un punto delicato nella sicurezza aziendale). Il proxy non esegue il polling di Azure AD; si limita a inoltrare le richieste di BPL dei DC al servizio Azure e a inoltrare il BPL risultante al DC richiedente. In questo modo non è necessario che i DC stessi dispongano di connettività a Internet.
Il servizio proxy può essere installato su qualsiasi server unito al dominio. In questa anteprima, può essere installato su uno o due server per garantire la tolleranza agli errori; questo limite dovrebbe essere eliminato prima della GA. Sia il servizio proxy che la foresta Active Directory devono essere registrati con Azure AD utilizzando il nuovo modulo AzureADPasswordProtection. (Una volta registrato, il proxy si pubblicizza al DC con un punto di connessione al servizio AzureAdPasswordProtectionProxy sotto l'oggetto computer (Figura 5):
Agente DC
Il pacchetto agente DC contiene due componenti (Figura 6). Il primo componente è l'agente DC stesso, che viene eseguito come AzureADPasswordProtectionDCAgent. Il secondo è un filtro password personalizzato. Esaminiamoli in ordine inverso.
Un filtro password AD è una DLL personalizzata che consente di estendere la funzionalità di base di un controllo di validità della password. Il filtro password del cliente Azure AD Password Protection è il più semplice possibile; tutto ciò che fa è inoltrare la richiesta di password all'agente DC e raccogliere la risposta di accettazione o rifiuto dall'agente.
Poiché il filtro password è parte integrante del sistema di sicurezza del DC, un effetto collaterale è che il DC deve essere riavviato ogni volta che l'agente DC viene installato o rimosso.
L'agente DC è il cuore del servizio on-premises. Durante le operazioni di runtime del DC, l'agente controlla la validità delle modifiche alle password degli utenti rispetto al criterio delle password. In background si assicura che il DC disponga di una copia corrente della BPL ottenuta da Azure AD. In caso contrario, ne ottiene una, la elabora per creare un criterio di password e la memorizza su SYSVOL all'indirizzo
C:WindowsSYSVOLsysvolPolicies{4A9AB66B-4365-4C2A-996C-58ED9927332D}AzureADPasswordProtection.
Il modo in cui gli agenti dei DC (in una distribuzione di produzione, dovrebbe essercene uno su ogni DC) ottengono e distribuiscono i criteri delle password è piuttosto elegante:
- Un agente DC in ogni sito Active Directory si sveglia circa una volta all'ora per decidere se la sua copia locale del criterio delle password su SYSVOL deve essere aggiornata.
- Se il criterio deve essere aggiornato o se non esiste ancora un criterio, richiederà un nuovo BPL crittografato da Azure AD tramite il proxy, creerà un criterio per le password e lo salverà in SYSVOL.
- SYSVOL replica questo criterio in tutti i DC del dominio tramite DFS-R (Figura 7).
Al massimo, un DC per sito può richiedere la BPL, ma probabilmente il numero di richieste sarà molto inferiore, anche solo una volta all'ora per dominio. Perché? Grazie all'efficiente replica dei criteri da parte di DFS-R tramite SYSVOL. In una rete sufficientemente connessa, un criterio aggiornato sarà replicato a tutti i DC prima che gli altri agenti si sveglino e quindi avranno un criterio aggiornato e non dovranno richiedere un nuovo BPL ad Azure. Questa architettura garantisce anche che i DC in ambienti chiusi ricevano comunque il criterio della password, perché la replica di SYSVOL è una parte essenziale della funzionalità del DC.
Flusso di autenticazione in fase di esecuzione
La valutazione dei criteri delle password vietate è integrata nel processo di valutazione delle password standard di AD (Figura 8):
- L'utente cerca di impostare una nuova password e il suo DC locale gestisce la richiesta.
- Sul DC, la richiesta viene elaborata dal filtro password personalizzato che passa la password all'agente DC.
- L'agente DC confronta la password proposta con quella presente su SYSVOL e la approva o la rifiuta.
- Il successo o il fallimento vengono restituiti all'utente.
Processo di valutazione delle password
La password proposta dall'utente viene confrontata con un elenco di circa 1000 parole e modelli ("asdf", ecc.). Inoltre, vengono effettuate sostituzioni di caratteri sulla password ($ per s, maiuscole/minuscole, ecc.). Attualmente, per ogni password viene calcolato un punteggio nel seguente modo:
Ogni carattere vale un punto, ma ogni sottostringa che corrisponde a una parola/frase/modello vietato vale solo un punto in totale. Il punteggio minimo consentito è di 5 punti. Ad esempio, "Primavera" e "2018" sono parole vietate, quindi "Primavera2018" vale solo 2 punti e non sarebbe consentito.
"Spring2018asdfj236" si scompone nel modo seguente:
- Primavera = 1 punto
- 2018 = 1 punto
- asdf = 1 punto
- f, j, 2, 3, 6 = 1 punto ciascuno
Totale = 8 punti = PASS
Questo processo consente alcune parole o frasi vietate se la password contiene un numero sufficiente di altri caratteri casuali. Si noti che è anche soggetto a modifiche, in quanto Microsoft evolve le sue informazioni sulle minacce su scala cloud relative agli attacchi alle passwordvi.
Il criterio si applica a tutti gli utenti della foresta - non c'è una porta sul retro per gli amministratori - e si applica a tutti i processi di modifica della passwordvii. Il normale controllo delle password errate con l'emulatore PDC non è influenzato da questa nuova funzionalità.
Vantaggi del design
Questo design ibrido presenta numerosi vantaggi:
- Il processo di richiesta e aggiornamento della BPL è progettato per avere un impatto estremamente ridotto sulle operazioni dei DC. In una rete ben collegata, solo un DC per dominio all'ora richiederà la BPL.
- Il processo di richiesta e aggiornamento funziona con un'ampia gamma di topologie di rete. I DC non hanno bisogno di connettività a Internet; solo il proxy deve avere accesso a Internet. Se necessario, il proxy deve connettersi a un solo DC per dominio tramite RPC (e la porta è configurabile). La replica di SYSVOL tramite DFSR garantirà che il criterio della password arrivi a tutti i DC del dominio.
- La verifica della password avviene attraverso i normali processi di Active Directory e le modifiche alla funzionalità AD di base sono ridotte al minimo. Nessuna parte dell'operazione viene mai esclusa dal DC; ad esempio, un tentativo di modifica della password non viene mai bloccato se il DC deve interrogare Azure per ottenere un nuovo BPL. Il filtro delle password è il più semplice possibile.
- Il software è progettato in modo "fail open", cioè se qualche componente non è installato o non funziona (ad esempio, l'agente DC è installato ma il proxy non è installato) la password sarà consentita, ma verrà registrato un errore nel registro eventi del DC.
- L'architettura aperta fail consente di preinstallare l'agente DC su un server che si intende promuovere a DC.
- L'agente DC esegue lo stesso codice di controllo delle password del servizio Azure.
- Non è necessario distribuirlo su tutti i DC per testarlo. Anzi, questo è un buon modo per distribuirlo in modo incrementale.
Fasi di implementazione
I passi dettagliati per la distribuzione sono documentati qui; dato che questo servizio è in anteprima, mi aspetto che vengano aggiornati regolarmente. Ad alto livello, i passi sono
- Stabilite su quali computer uniti al dominio desiderate installare il servizio proxy e su quali DC desiderate effettuare il test. Non è necessario che il proxy si trovi sul server Azure AD Connect o su un DC; qualsiasi server membro (ad esempio un server che ospita già i connettori Application Proxy) è sufficiente. Ricordate che non dovreste usare le anteprime pubbliche sui server di produzione, o almeno contro gli utenti di produzione; potreste promuovere e isolare un DC nel proprio sito per testarlo contro utenti specifici.
- Assicurarsi che il servizio Azure AD Password Protection sia configurato per la modalità Audit (l'impostazione predefinita) e aggiungere facoltativamente eventuali password personalizzate al tenant BPL.
- Ottenere i bit di anteprima per il servizio proxy dei criteri di password e l'agente DC dal centro di download.
- Installare il servizio proxy dei criteri di password.
- Sul server proxy,
a. Registrare il servizio proxy con Azure AD.
b. Registrare la foresta Active Directory on-premises con Azure AD. - Installare gli agenti DC.
- Riavviare i DC.
Monitoraggio
Al momento, le informazioni sull'attività del servizio Azure AD Password Protection devono essere raccolte dal server proxy e dai registri eventi del DC. Al momento non è prevista l'integrazione con Azure AD Connect Health nell'anteprima pubblica, né il monitoraggio dell'agente proxy dal blade Azure AD nel portale proxy.
Gli ID degli eventi nell'intervallo 10000 sono generati dal filtro password, mentre gli ID nell'intervallo 30000 provengono dall'agente DC. I messaggi dell'agente DC forniscono (leggermente) più informazioni (Figura 9):
L'agente DC ha i propri contatori di prestazioni in Perfmon sotto Azure AD Password Protection (Figura 10):
È inoltre possibile utilizzare il cmdlet PowerShell Get-AzureADPasswordProtectionSummaryReport per ottenere una visualizzazione sintetica dell'attività di modifica delle password.
Licenze
Che tipo di licenza Azure AD richiede questa funzionalità? Si suddivide nel modo seguenteviii:
- Account solo cloud: Protezione della password di Azure AD con elenco globale di password vietate: Gratuito
- Protezione password Azure AD con elenco personalizzato: Azure AD di base
- Integrazione di Windows Server AD Protezione delle password di Azure AD con elenco globale di password vietate: Tutti gli utenti sincronizzati devono avere licenze Azure AD Premium P1
- Protezione della password di Azure AD con elenco personalizzato (ciò che descrivo in questo post): Tutti gli utenti sincronizzati devono avere Azure AD Premium P1
Anche in questo caso, trattandosi di un'anteprima pubblica, è soggetta a modifiche.
Notizie varie
- Non c'è alcuna relazione tra i componenti on-premises di Azure AD Password Protection e Azure AD Connect. Pertanto, non è necessario installare il proxy su uno o più server Azure AD Connect (anche se funzionerà benissimo su di essi).
- Poiché non sono state apportate modifiche al lato client, qualsiasi password comune rifiutata mostrerà l'errore standard "la password non soddisfa i requisiti di complessità" sul client.
- L'anteprima pubblica richiede che Global Admin nel tenant configuri il componente Azure e installi il proxy on-premises, e (ovviamente) Domain Admin per installare il software. Tuttavia, inizialmente l'MFA non è supportato per la registrazione, quindi dovrete togliere l'MFA dall'account Global Admin che state usando per installare il proxy. Questo problema sarà risolto prima di GAix.
- Se volete testare alcune delle vostre password rispetto a quelle che il NIST ritiene siano comuni, date un'occhiata al progetto NIST Bad Passwords su Github. Oltre a fornire un esempio di codice per creare un proprio verificatore di password vietate sul lato client, è possibile testare le password per verificarne la debolezza.
Microsoft si sta muovendo in modo aggressivo per adottare le raccomandazioni del NIST per i criteri delle password. Vietando le modifiche alle password più comuni in Active Directory, Azure AD Password Protection chiude un'importante area di rischio aziendale causata dagli attacchi alle password. Vi consiglio vivamente di valutare questo servizio e di implementarlo una volta raggiunta la disponibilità generale.
Il divieto delle password comuni è solo una parte della vostra soluzione di sicurezza delle identità. L'accesso condizionato con controllo MFA alle applicazioni aziendali, sia in cloud che in locale, è un'altra cosa. Man mano che le architetture aziendali passano da un modello di sicurezza perimetrale a uno basato sulle identità, la sicurezza delle risorse aziendali richiede un approccio ampio che comprenda la sicurezza delle identità, dei dispositivi e dei dati.
Risorse
ihttps://twitter.com/Alex_A_Simons/status/1009490805369655296
iihttps://twitter.com/Alex_A_Simons/status/1009500870872973312
iiihttps://twitter.com/Alex_A_Simons/status/1009923402998562816
viihttps://techcommunity.microsoft.com/t5/Azure-Active-Directory-AMA/bd-p/AzureActiveDirectoryAMA
ixhttps://twitter.com/Alex_A_Simons/status/1009490805369655296
