L’identità è il nuovo perimetro della sicurezza. Qualsiasi violazione di questo perimetro può consentire a persone malintenzionate di accedere ad applicazioni, dati e attività aziendali. Per tutte le organizzazioni che forniscono servizi di identità basati su Azure Active Directory o un ambiente ibrido con Active Directory in locale e Azure AD, la protezione dei sistemi a identità ibrida può richiedere tempo e molte risorse. D’altro canto, è un’attività fondamentale.
Errori e configurazioni non adatte sono problemi frequenti negli ambienti ibridi, che sono quindi particolarmente vulnerabili agli attacchi informatici. Per gli utenti malintenzionati è sufficiente violare un servizio tra il local AD e Azure AD perché possano agire indisturbati su entrambi. L’attacco a SolarWinds è un ottimo esempio di questa strategia.
La protezione delle identità in ambienti ibridi comporta problemi molto diversi rispetto a quanto avviene in ambienti puramente locali. Se l’infrastruttura della di un’organizzazione include Azure AD (ed è così se si usa Microsoft Office 365), ci sono vari aspetti a cui occorre prestare attenzione. Ecco i più importanti.
Attacchi incrociati dall’interno del servizio local AD
Spesso i criminali informatici usano tecniche di phishing o social engineering per attaccare utenti vulnerabili e ottenere con l’inganno informazioni sensibili, ad esempio credenziali di identità. Gli esempi di SolarWinds e Colonial Pipeline mostrano i rischi correlati a casi simili. Gli autori degli attacchi hanno preso il controllo del servizio AD in locale, manomesso la federazione ADFS (AD Federation Services) affinché creasse token SAML e ottenuto l’accesso ad Azure AD.
Cosa si può fare per contrastare gli attacchi e proteggere i sistemi a identità ibrida
Innanzitutto, imporre ovviamente l’uso dell’autenticazione a più fattori. Le credenziali di identità rubate sono uno degli strumenti d’attacco più pericolosi. E come se non bastasse, può trascorrere molto tempo prima che ci si accorga del furto. Non tutti i sistemi di monitoraggio sono in grado di segnalare attività dell’account insolite, quindi aggiungere questa misura di protezione è fondamentale.
In secondo luogo, prendere coscienza del fatto che ormai la gestione delle identità ibride richiede controlli di sicurezza più avanzati rispetto a quelli disponibili con una classica implementazione dell’ADFS. Mantenere l’infrastruttura necessaria a ospitare l’ADFS comporta dei rischi intrinsechi, come la possibilità di saltare l’applicazione di una patch, l’obsolescenza dei componenti hardware e così via.
Va piuttosto considerato il passaggio all’autenticazione pass-through di AD, che permette di usare la stessa password per accedere ad app in locale e su cloud. Questo approccio sfrutta un modello di connessione solo in uscita e l’autenticazione basata su certificato per delegare il processo di autenticazione al servizio AD in locale; questa è un’alternativa più sicura rispetto ad ADFS. È anche possibile integrare l’autenticazione pass-through di AD con altre misure di sicurezza di Azure AD per scongiurare infiltrazioni e furto di credenziali come anche sincronizzare gli hash delle password AD con Azure AD.
Inoltre, è possibile prendere in considerazione Azure AD Application Proxy, ossia una funzionalità che usa le credenziali di Azure AD per configurare un accesso remoto sicuro alle app in locale e offre la stessa esperienza utente di qualsiasi applicazione con Azure AD integrato.
Configurazione lenta e complessa
Proteggere i sistemi a identità ibrida è complicato per chiunque, per gli amministratori AD come per gli esperti di identità o sicurezza. Le minacce cambiano di continuo e bloccare gli accessi agli asset tier 0, come AD e Azure AD, richiede molto tempo. La stessa quantità di tempo se non di più può essere necessaria quando si prova a ripristinare l’AD a seguito di un attacco informatico.
Usare Azure AD per l’autenticazione di app di terze parti rende più complesso il modello di sicurezza. In alcuni casi, queste app possono leggere e archiviare dati da Azure AD; ciò espande il perimetro di rischio e fa sì che la sicurezza dei dati dipenda dall’applicazione con l’Azure AD integrato.
Un altro possibile punto debole sono le autorizzazioni impostate in Azure AD: se non vengono concesse con molta attenzione, le app potrebbero avere un margine di manovra più ampio del necessario. Dal momento che può aumentare il rischio di modifiche nel tenant AD, questa è una svista che potrebbe costare molto caro.
Infine, misure come l’autenticazione a più fattori potrebbero non funzionare per alcune app, che quindi saranno vincolate ai controlli di sicurezza integrati, qualunque essi siano.
Cosa fare per ridurre il numero di accessi
Queste potenziali falle di sicurezza richiedono una governance rigorosa e audit periodici per quanto riguarda le autorizzazioni concesse alle app al fine di capire dove applicare restrizioni aggiuntive. Va identificata ogni eventuale lacuna e occorre assicurarsi di aver abilitato il corretto settaggio dei ruoli in Azure AD, eseguire un audit delle impostazioni di autorizzazione e rendere più rigide le configurazioni di sicurezza, quindi aggiungere metodi di protezione come l’autenticazione a più fattori.
Bisogna valutare anche il modo in cui viene gestito il controllo degli accessi basato sui ruoli (Role-Based Access Control, RBAC). L’assegnazione dei ruoli in Azure AD è un’attività diversa rispetto alla gestione degli accessi sull’AD tradizionale: va posta molta attenzione al modo in cui vengono definiti i ruoli e concesse le autorizzazioni.
Per proteggere i sistemi a identità ibrida è importante seguire il principio dei privilegi minimi. Non vanno aggiunti account sincronizzati dall’AD in locale ad Azure AD all’interno di ruoli RBAC con privilegi, come ad esempio per gli amministratori globali, piuttosto va riservato questo tipo di ruoli agli account nativi Azure AD. È anche possibile creare unità amministrative nel tenant Azure AD per ridurre il numero di oggetti gestibili dai membri del team IT tramite uno specifico ruolo RBAC: quest’ultimo è un altro modo per rispettare il principio dei privilegi minimi.
Errori di configurazione e altre vulnerabilità di sicurezza
Errori di configurazione e vulnerabilità di sicurezza della soluzione di gestione delle identità sono un punto di accesso ideale per gli utenti malintenzionati. Azure AD si basa su servizi gestiti ed è Microsoft a proteggerne l’infrastruttura sul cloud. Ma la protezione dei propri dati e della configurazione di Azure AD è una responsabilità che riguarda l’organizzazione.
Durante un attacco informatico, è possibile che vengano alterati o cancellati utenti, gruppi, ruoli, criteri di accesso condizionale e altro ancora. A meno che non si abbia già un piano di recovery adeguato, l’impatto di un evento simile può essere devastante e duraturo. Esistono pochi controlli nativi che possono impedire la sovrascrittura di dati o configurazioni in Azure AD durante un attacco.
Cosa fare per semplificare la protezione dei sistemi a identità ibrida
Il cestino di Azure AD offre una funzionalità di eliminazione temporanea che consente di ripristinare gli utenti eliminati, ma va ricordato che conserva gli elementi solo per 30 giorni.
Altre forme di compromissione possono essere difficili da individuare e mitigare, soprattutto se gli utenti malintenzionati sono in grado di muoversi tra il local AD e Azure AD nel cloud. Oltre alle misure di sicurezza native, i responsabili IT devono sfruttare strumenti avanzati che permettano di identificare attacchi potenzialmente in grado di espandersi a più servizi all’interno degli ambienti ibridi. Funzionalità come il rilevamento delle modifiche e le correzioni automatiche degli errori possono impedire il furto di credenziali e l’accesso da parte di persone malintenzionate. Infine, è fondamentale disporre sempre di un piano di recovery collaudato e proattivo per AD e Azure AD.
Di Guido Grillenmeier, Chief Technologist di Semperis
