L’Active Directory (AD) è il sistema di identità utilizzato dalla maggior parte delle aziende. Per questo motivo negli ultimi tempi è diventato uno degli obiettivi principali dei cyber attacchi, che si verificano principalmente a causa di alcuni aspetti:
- la carenza di competenze da parte delle figure che si dedicano all’impostazione dell’AD;
- il lavoro remoto che spesso viene eseguito senza connessioni sicure;
- la mancanza di un monitoraggio completo che riesca ad individuare tutte le superfici esposte;
- la mancanza di un processo efficace di recovery in caso di attacco.
Analizziamo dunque le cause fornendo alcuni suggerimenti utili per ridurre il più possibile l’eventualità di un attacco ed evidenziare i parametri chiave da monitorare.
La formazione alla cyber security è un investimento che ritorna
Indice degli argomenti
Cos’è l’Active Directory
Innanzitutto, è utile ricordare che l’Active Directory è un servizio di directory fondamentale per tutte le aziende che dispongono di risorse informatiche complesse, permessi utente e gruppi di lavoro di tipo gerarchico.
Attraverso l’AD, la struttura IT di un’organizzazione può raggruppare in modo logico e coerente un certo numero di utenti e computer all’interno di un dominio, che è gestito centralmente da uno o più server (Domain Controller).
L’Active Directory consente pertanto la gestione dell’autenticazione e dell’accesso a tutte le risorse business-critical all’interno dell’azienda dando la possibilità anche di modificare, interrogare e strutturare i dati degli utenti e di tutti gli oggetti al suo interno.
L’Active Directory è stata lanciata sul mercato oltre vent’anni fa ed è in continuo sviluppo e aggiornamento; questo ha permesso di stare al passo con le mutate esigenze delle aziende. Infatti, negli ultimi anni il modello aziendale è passato dall’essere rigido e “ufficiocentrico” a un’impostazione più flessibile che ha richiesto l’adozione di un’infrastruttura IT ibrida, ossia con applicazioni sia on-premise sia on-cloud.
La maggior parte delle organizzazioni continua per praticità ad usufruire di questo mix on-premise/cloud poiché si adatta maggiormente alle singole necessità. Sebbene gli ambienti ibridi garantiscano una maggiore flessibilità con conseguenti vantaggi, comportano un sensibile aumento dei rischi informatici.
I cyber attacchi e il loro perdurare nel tempo
Consideriamo che fino ad una decina di anni fa la sicurezza dell’Active Directory non era un aspetto prioritario e ciò ha comportato nel tempo l’accumularsi di numerose problematiche legate alla mancanza di consapevolezza delle implicazioni.
Le aziende spesso si ritrovano l’AD caratterizzata da numerose impostazioni errate o non sicure (probabilmente non sono del tutto consapevoli di questo), il che rappresenta un pericolo.
Nell’Active Directory tipica, esistono milioni di percorsi di attacco che i cyber criminali possono sfruttare per controllare un dominio, pertanto è di fondamentale importanza essere consapevoli di qualsiasi punto debole, modificare tutte le impostazioni ed errori di configurazione e individuare ogni area esposta ad eventuali attacchi.
È impossibile proteggere ciò che non è visibile
Vi è una serie di errori comuni e ricorrenti nell’impostazione dell’AD, che spesso viene replicata. Un errore qualunque potrebbe diventare una backdoor perfetta. Gli errori più comuni sono:
- numero eccessivo di privilegi;
- numero eccessivo di account di amministrazione;
- password degli account di amministrazione non modificate regolarmente;
- configurazione di diverse autorizzazioni rischiose riguardanti il dominio;
- account utenti inattivi (e non eliminati);
- computer configurato con delega senza restrizioni;
- account amministratore integrato di un dominio utilizzato in modo improprio.
È quindi impossibile proteggere ciò che non si riesce a vedere ed è difficoltoso avere la situazione completa sullo stato dell’AD, poiché molti tool di monitoraggio possono tralasciare qualche dettaglio.
Vi è anche un altro importante parametro da valutare, che è l’analisi del perimetro AD: i tool analizzano solitamente i percorsi più comuni (quindi non tutti) scelti dagli attaccanti quando vogliono ottenere il controllo dei domini dall’esterno all’interno.
I team operativi IT spesso non hanno le risorse o le conoscenze sufficienti per correggere le dozzine o addirittura centinaia di errori di configurazione che riscontrano e la carenza di competenze si aggrava quando a seguito dell’introduzione del cloud si migra verso le identità ibride.
La corretta gestione delle identità ibride
La gestione della sicurezza dei sistemi di identità ibridi è più complessa poiché i paradigmi di impostazione fra AD e Azure AD (AAD), sono molto diversi. Il passaggio da un ambiente on-premise ad uno a identità ibrida consente un elevato numero di servizi.
L’AD ha un insieme ben definito di gruppi amministrativi, mentre l’AAD è impostato attraverso i ruoli con cui si tende ad avere poca familiarità. Ogni ruolo dispone di un lungo elenco di autorizzazioni assegnate, pertanto dalla sola descrizione è difficile capire quali e quante autorizzazioni sono state assegnate e quei ruoli che possiedono un livello di accesso elevato non sono evidenti da individuare.
Inoltre, il collegamento di qualsiasi servizio SaaS come anche tool di terze parti all’AAD implica la gestione di ulteriori modelli di autorizzazioni. Riassumendo brevemente, le differenze fra AD e AAD possono essere:
- L’AD e l’AAD non hanno quasi nulla in comune ed è importante comprendere da subito questa differenza. Per i team IT esperti nella gestione delle impostazioni di sicurezza di Active Directory locali, concetti familiari come foreste, oggetti, criteri di gruppo, non possono essere applicati nell’ambiente AAD e contrariamente all’AD, la nozione di perimetro di rete tradizionale non esiste. Con l’AAD i team IT e di sicurezza devono essere preparati a proteggersi da un numero infinito di potenziali punti di ingresso in un ambiente di identità ibrido.
- Il passaggio all’AAD apporta modifiche radicali al modello di autorizzazioni. In un ambiente locale, i team IT possono facilmente controllare chi accede ai controller di dominio e i punti di accesso sono ben definiti. In un ambiente ibrido, le identità sono archiviate nel cloud e sono potenzialmente vulnerabili.
- Le risorse AAD create dal team IT per gestire l’accesso ai servizi a livello aziendale, come ad esempio account utente, ruoli e gruppi, devono essere sottoposte a backup, poiché se tali risorse dovessero essere cancellate da un attacco, o tramite un’eliminazione accidentale dell’account dovranno essere ricostruite da zero. Questo processo richiederà molto tempo e le conseguenze saranno quelli di avere ferma qualsiasi attività.
- Il concetto di spostare risorse e servizi nel cloud promette molti vantaggi, come la risoluzione di alcuni problemi di gestione al provider cloud. Tuttavia, per garantire che le aziende siano in grado di resistere a un attacco informatico, occorre avere una chiara comprensione delle responsabilità dell’Identity provider del cloud. In sostanza, la responsabilità dell’IDP è quella di garantire che il servizio sia continuamente disponibile.
Monitorare le autorizzazioni fornite a terze parti
Come detto, occorre fare attenzione anche ai tool di terze parti presenti nell’AAD, poiché spesso vi lavorano direttamente al suo interno attraverso i dati.
I tool di terze parti sono in grado di acquisire i dati dall’AAD e archiviarli nei propri database, come ad esempio un’applicazione registrata nell’AAD che permetta a un sistema CRM di leggere tutti i profili utente o che possa disporre di altre autorizzazioni di lettura. In questo caso l’applicazione può recuperare i dati in completa autonomia e una volta acquisiti, saranno presenti in un database esterno.
Inoltre, i tool con accesso in scrittura che possono apportare modifiche all’interno del tool stesso necessitano logicamente dell’autenticazione. Tuttavia essa viene richiesta per apportare modifiche e trasferita dall’AAD a qualsiasi controllo appartenente al tool.
In questo caso, un utente potrebbe accedere senza l’autenticazione a più fattori, sebbene il tool non supporti l’accesso SSO (Single Sign On), e utilizzerebbe l’applicazione come proxy dell’autorizzazione. Questo è un sistema di azione privo di controlli normalmente richiesti.
Occorre quindi tenere sempre traccia delle autorizzazioni fornite alle applicazioni di terze parti, poiché questo aspetto, seppur fondamentale, viene spesso sottovalutato. Le richieste di autorizzazione attivano una pop-up temporanea che elenca le autorizzazioni necessarie all’applicazione. L’elenco può essere lungo e pertanto deve essere esaminato con attenzione, ed è proprio per questioni di tempo che questa prassi viene eseguita raramente.
Le tematiche affrontate fin qui rappresentano problemi complessi che possono insorgere per ogni servizio gestito tramite AAD. Ad ogni modo i team IT dovranno limitare le utenze che possono approvare le applicazioni o almeno redigere linee guida chiare e coerenti su quali autorizzazioni possono essere considerate appropriate.
L’importanza di un efficace processo di recovery
Le conseguenze di un attacco all’AD obbligano ad affrontare diversi scenari. È molto probabile che gli attaccanti abbiano effettuato profonde modifiche allo schema di Active Directory come anche tutti i controller di dominio siano danneggiati.
Indipendentemente dalla situazione e dalle cause, le conseguenze di questi eventi sono i tempi di inattività che possono durare ore fino ad estendersi a molti giorni. Pertanto, più è lungo il tempo di inattività, maggiore sarà il danno. Tuttavia, sebbene la velocità sia importante, lo è altrettanto l’operazione di recovery poiché deve essere portata a termine con efficacia.
Inoltre, durante questa operazione, è necessario assicurarsi che tutti gli attori delle minacce siano stati eliminati e che non siano rimaste aree esposte che possono rappresentare ulteriori punti di accesso per futuri attacchi.
Per predisporre una procedura di recovery è necessaria la creazione di un ambiente di ripristino isolato.
Va tenuto conto che l’AD e l’AAD devono essere considerate due directory separate poiché le soluzioni di backup e recovery per l’AD non avranno un impatto sull’ambiente cloud. Ad esempio, un utente cancellato dall’AAD potrebbe essere parzialmente recuperato dall’AD, ma non avrebbe alcun attributo specifico del cloud.
Negli ambienti ibridi va predisposta una doppia procedura di recovery. Un’altra problematica a cui fare attenzione è la possibilità che non si sia in grado di sapere con chiarezza cosa sia stato aggiunto o modificato nell’AD ( ad esempio, se viene rimossa l’autenticazione multifattoriale per un particolare account).
Anche in questo caso è necessario estendere al cloud lo stesso livello di monitoraggio e sicurezza dell’AD. Pertanto, quando si decide su cosa effettuare il backup, l’attenzione dovrebbe concentrarsi su utenti, gruppi e ruoli, poiché queste entità controllano l’accesso ad altre risorse.
Ad ogni modo, identificare attività sospette per tenere sotto controllo lo stato di salute dell’ ambiente AD è già un primo passo per rendere più rapide le operazioni di recovery.
