Sicurezza e Active Directory: cosa fare per proteggere il servizio di Microsoft

Active Directory nell’occhio del ciclone. Il servizio di Microsoft alla base dei suoi sistemi operativi server prima e di Azure Active Directory su cloud oggi, rappresenta una grande preoccupazione per gli esperti di sicurezza. D’altronde, Microsoft ne paga la diffusione: secondo Semperis, vendor specializzato nella protezione delle identità in ambienti Active Directory, per circa il 90% delle aziende in tutto il mondo il servizio rappresenta il “core identity store” di riferimento. E Microsoft non aggiorna la versione “classica” dal 2016, avendo concentrato tutti gli sforzi di sviluppo su Azure.

Alla base di tutte le versioni dei sistemi operativi per server di Microsoft a partire da Windows 2000, Active Directory è il servizio, basato sul concetto di dominio, ideato per la gestione centralizzata delle informazioni di tutte le utenze connesse a una rete informatica Windows. E quando diciamo tutte, intendiamo proprio tutte. Dalle info e i privilegi sugli utenti, a quelli sui computer e le stampanti fino a tutti i servizi, dai siti all’ecommerce alla posta elettronica e alle singole applicazioni.

Il servizio, insomma, è il repository centralizzato di informazioni, privilegi, profili e policy di configurazione che gestiscono qualsiasi entità connessa a una rete Windows. Questa centralizzazione delle informazioni e il carattere di “apertura” del servizio, per cui chiunque abbia l’accesso può vedere tutto, si sono trasformate in vulnerabilità. È sufficiente, infatti, entrare in possesso delle credenziali di accesso al servizio per danneggiare la rete aziendale.La vulnerabilità, dunque, è per certi versi "intrinseca" all’architettura di Active Directory e si manifesta anche nella sua declinazione cloud, Azure Active Directory. Di esempi che hanno contribuito a innalzare il livello di preoccupazione ce ne sono tanti. Si è dimostrato che il servizio ha avuto un ruolo nello storico attacco a SolarWinds, così come in quello a Colonial Pipeline. Gli esperti di Mandiant hanno addirittura dichiarato che, nel 90% degli attacchi analizzati, c’era di mezzo Active Directory. Dal rilascio, nel marzo 2021, di Purple Knight di Semperis, un tool gratuito che analizza l’ambiente Active Directory di un’infrastruttura IT, tutte le aziende che l’hanno utilizzato hanno riportato un punteggio medio di sicurezza iniziale di 68 su 100. Un valore preoccupante secondo il vendor di sicurezza.

Il gioco dell’attaccante è abbastanza semplice: una volta entrato in possesso di un account per l’accesso ad Active Directory e introdotto nel servizio, diventa semplice fare danni. Si possono sfruttare le vulnerabilità delle centinaia di servizi Windows collegati, uno su tutti il Printer Service, e anche la necessità di un’alta frequenza di modifica della struttura certo non aiuta. Capita spesso, infatti, che si debba intervenire sulle configurazioni con grande frequenza e che gli utenti abilitati abbiano qualsiasi tipo di privilegio, anche ingiustificato. Queste condizioni comportano troppi accessi e troppi rischi di errore.

L’openess di Kerberos

Insomma, l’openess di Active Directory insieme alla capacità di integrarsi facilmente con le applicazioni, che inizialmente erano dei vantaggi, oggi sono un problema. Altro punto critico è la fatidica “delega di accesso ad AD” permessa da Kerberos alle applicazioni. Kerberos, il protocollo di autenticazione di rete sfruttato in Active Directory, permette, semplificando, agli attaccanti di “impersonare” un utente Active Directory, e iniziare a “fare danni”.

Nonostante Microsoft nel tempo abbia permesso configurazioni più sicure di Kerberos e degli altri servizi, il problema è che questa “openess” è fornita di default. Ciò significa che se ci si vuole proteggere (meglio) ci si deve ricordare di personalizzare le configurazioni e di interrompere l’erogazione dei servizi non utilizzati su determinati ambienti. Insomma, un lavoro complesso che la maggior parte degli amministratori di rete, nella migliore delle ipotesi, si dimentica di fare.Le questioni sul tavolo, insomma, sono due: l’inadeguatezza di Active Directory e dei servizi che utilizza e i privilegi degli utenti autenticati. In primo luogo, lungo l’architettura di Active Directory viaggiano file di testo che comprendono troppe informazioni sensibili. E, una volta dentro la struttura, un attaccante può facilmente intercettarle e analizzarle fino a quando non trova ciò che gli interessa, sostanzialmente credenziali di accesso. Inoltre, i troppi privilegi concessi, più o meno involontariamente, rappresentano l’altro problema, di cui abbiamo piena evidenza anche nella versione cloud Active Directory. Chi riesce a impossessarsi di un account di amministratore di dominio, per esempio, avrà piena visibilità di tutta la struttura, compresi ruoli e accessi degli altri utenti.

Buttare via Active Directory non si può

Cosa fare, dunque? Buttare via Active Directory? Impensabile, visto che lo utilizza ancora il 90% delle aziende nel mondo. Conviverci, dunque, ma come? Sfruttare un tool di analisi e monitoraggio dell’architettura è la prima cosa da fare. Essere ben consci delle vulnerabilità della rete aziendale è il primo passo, obbligato. Ricorrere ad ambienti distribuiti ibridi, combinazione di cloud pubblici e privati, è un’alternativa, così come replicare la struttura su un cloud privato ad accesso molto limitato.

Infine, concentrarsi e investire su strumenti di Identity Management di alto livello. È ben noto, infatti, che la stragrande maggioranza degli attacchi alle reti informatiche deriva da accessi autorizzati e da end point ritenuti sicuri. Come nei casi di accesso al cloud o alle risorse aziendali, anche l’accesso all’Active Directory di Microsoft deve essere riprogettato con grande attenzione.

Inevitabile, dunque, il ricorso a strumenti di autenticazione forte, quando possibile, o a policy di accesso estremamente rigide e da aggiornare costantemente. Soprattutto oggi, in tempi di outsourcing spinto, quando alle componenti critiche dell’It aziendale accedono diversi profili. In primis i partner It che gestiscono l’infrastruttura, le risorse dell’hyperscaler in caso di ricorso a cloud pubblici, i team It interni e gli sviluppatori.