È facile capire perché le aziende stiano gravitando verso un modello di gestione delle identità ibrido che promette il meglio dei due mondi: un po' nel cloud e un po' in sede. In un ambiente incentrato su Active Directory, sfruttare il cloud significa integrarsi con Azure Active Directory.
Azure Active Directory (AAD), dopo tutto, è stato progettato con un occhio di riguardo per le applicazioni SaaS, fornendo single sign-on e controllo degli accessi. Con l'aumento dell'adozione del cloud, la capacità di gestire gli accessi sia on-premise che nel cloud sta diventando una necessità aziendale. necessità aziendale. L'integrazione di AAD con Active Directory (AD) contribuisce a rendere la gestione ibrida delle identità una realtà.
Come per ogni altra cosa nel settore IT, tuttavia, l'adagio "guardare prima di saltare" è ancora valido.
Lettura correlata
Monumentale cambiamento con il passaggio al cloud
Lo spostamento di qualsiasi parte di un'operazione IT nel cloud richiede un adeguamento. L'autenticazione degli utenti non è da meno. Da un punto di vista concettuale, le organizzazioni devono considerare tre aspetti critici.
1. Un nuovo modello di autenticazione
Dopo 20 anni di gestione dell'identità in un solo modo, l'aggiunta dell'AAD al mix sarà un adattamento critico un adeguamento critico. Passare dall'utilizzo del solo AD on-premises all'estensione dell'autenticazione al cloud richiede una mentalità e un approccio diversi. Nel DAA non esistono unità organizzative o foreste, né oggetti di criteri di gruppo. I concetti (e le cicatrici di battaglia) su come proteggere le identità in AD non sono più validi in AAD.
Molti amministratori iniziano a credere che la protezione dell'AAD sia simile a quella dell'AD, ma non è così. Ae si potrebbe già utilizzare il DAA senza pensarci troppo. Se la vostra organizzazione utilizza un sistema Microsoft cservizi Microsoft, come Office 365, allora AAD viene già utilizzato in background. L'AAD viene utilizzato anche per connettersi ad altre applicazioni SaaS non Microsoft, come Salesforce. Tutti questi fattori introducono nuove considerazioni e scelte. Ad esempio, è opportuno mantenere AD e AAD separati o unirli utilizzando Azure AD Connect? È necessario comprendere molti nuovi concetti per poter prendere queste decisioni mantenendo la sicurezza dei sistemi informativi.
2. L'estensione del perimetro
Quando un'organizzazione abbraccia il cloud, la nozione di perimetro di rete tradizionale cessa di esistere. Per gli amministratori IT che hanno trascorso gli ultimi vent'anni a gestire l'AD on-premise, questa nozione rappresenta un enorme adattamento. In un ambiente di identità ibrido, le organizzazioni devono devono prepararsi a difendersi da una serie infinita di possibili punti di accesso.
3. Cambiamenti radicali nel modello di autorizzazione
Il passaggio all'AAD cambia drasticamente anche il modello di autorizzazioni che le organizzazioni devono devono proteggere. In sede, è abbastanza facile abbastanza facile controllare chi ha accesso fisico ai controller di dominio e i punti di accesso alla gestione generale sono ben definiti e documentati. In un ambiente AD ibrido, le identità sono ora archiviate anche nel cloud, vulnerabili allo sfruttamento da parte di chiunque abbia accesso a Internet. Improvvisamente, gli amministratori hanno a che fare con un modello intrinsecamente aperto per le connessioni di accesso iniziali, che-se abbinato al maggior numero di servizi, ruoli e autorizzazioni richiesti, - si trova ad avere a che fare con un modello intrinsecamente aperto per le connessioni di accesso iniziali.-ha un impatto significativo sul rischio.
Microsoft ha cercato attivamente di fornire materiale didattico per preparare le aziende ai cambiamenti causati dall'adozione dell'AAD. Tuttavia, molte organizzazioni IT non riescono ancora a comprendere appieno le implicazioni della gestione ibrida delle identità. Man mano che sempre più aziende adottano un approccio ibrido, gli aggressori hanno hanno ampliato il loro modus operandi di conseguenza.
A settembre 2020i ricercatori di Mandiant (FireEye) hanno rilevato un aumento degli incidenti che coinvolgono Microsoft 365 e Azure Active Directory, per lo più legati a e-mail di phishing che tentano di indurre le vittime a inserire le proprie credenziali di Office 365 in un sito di phishing. I ricercatori di Mandiant hanno anche osservato che gli aggressori utilizzano un modulo PowerShell chiamato AADInternalsche consente agli aggressori di passare dall'ambiente on-premises all'AAD, creare backdoor, rubare password e compiere altre azioni dannose. Queste minacce continueranno ad aumentare con la crescita esponenziale dell'interesse verso Azure e Office 365.
Permessi, permissioni, permissioni
Di gran lunga, dei tre argomenti sopra citati, il rischio maggiore per la sicurezza è causato dalle modifiche al modello di autorizzazioni. Quando le organizzazioni passano a un ambiente di identità ibrido, sono disponibili un numero enorme di servizi. Invece di un insieme ben definito di gruppi amministrativi in Active Directory, ora in Azure AD ci sono ruoli, che non vi saranno familiari. Potete vedere questo elenco di ruoli qui. Ogni ruolo ha un lungo elenco di autorizzazioni assegnate. È difficile capire le autorizzazioni assegnate a ciascun ruolo solo dalla descrizione, ma molti di essi hanno un livello di accesso elevato che non è apparente.
Inoltre, il collegamento di qualsiasi servizio SaaS ad AAD, che probabilmente è il motivo per cui avete aggiunto AAD al mix, aggiunge modelli di autorizzazione che devono essere gestiti. Microsoft Teams, ad esempio, utilizza l'integrazione di SharePoint nel back end. posteriore. Con le configurazioni sbagliate, l'aggiunta di un ospite a Teams potrebbepotrebbe creare una situazione in cui questo nuovo utente ha accesso ai file archiviati in SharePoint per Teams.. Fochi potrebbero non essere consapevoli che questi file sono ora disponibili agli utenti ospiti che sono stati aggiunti al loro canale solo per una breve chiacchierata. Inoltre, la possibilità di aggiungere app in Teams estende di fatto il modello di autorizzazione a questi strumenti di terze parti. Questo è solo un esempio della matrice di problemi complessi per ogni servizio gestito tramite AAD.
In effetti, tenere traccia delle autorizzazioni delle app di terze parti è fondamentale ed è un'area che non viene gestita nella maggior parte delle implementazioni AAD. Queste richieste di autorizzazione attivano un pop-up unico che elenca le autorizzazioni necessarie all'applicazione. Questi elenchi possono essere lunghi e dovrebbero essere esaminati attentamente prima di essere accettati, ma raramente lo sono.
Le organizzazioni possono anchemento potrebbero affrontare questi due nuovi scenari relativi alle autorizzazioni che devono essere compresi in un contesto di sicurezza:
- Strumenti di terze parti che estraggono i dati da Azure AD e li archiviano nel proprio database. Ad esempio, un'applicazione registrata in Azure AD che consente a un sistema CRM di leggere i profili degli utenti o che ha altre autorizzazioni di lettura ha la capacità di recuperare e archiviare i dati per se stessa. Una volta che i dati vengono prelevati da Azure AD, si trovano in un database esterno, lasciando che l'organizzazione si affidi al quadro di sicurezza dello strumento di terze parti.
- Strumenti di terze parti con accesso in scrittura che possono apportare modifiche all'interno del loro strumento. In questo caso, l'autenticazione richiesta per apportare modifiche nel tenant viene spostata da Azure AD a qualsiasi controllo dello strumento di terze parti. Un utente puòpotrebbe essere in grado di accedere allo strumento senza autenticazione multifattoriale perché non supporta il single sign-on (SSO), operando invece con l'applicazione che agisce come permission proxy che esegue l'azione per conto dell'utente senza alcuni dei controlli che sarebbero normalmente richiesti.
Le organizzazioni IT dovrebbero prendere in considerazione l'idea di limitare i soggetti che possono approvare applicazioni o, per lo meno, di averee chiare indicazioni su quali autorizzazioni debbano essere considerate appropriate. L'adozione di un approccio di identità ibrida richiede la gestione di un modello di permessi molto più ampio. Per farlo in modo efficace, le organizzazioni devono stabilire una forte governance su quali app saranno attivate e quali diritti di accesso otterranno.
Comprendere il rischio della gestione ibrida delle identità
Che l'autenticazione sia gestita nel cloud, on-premise o in entrambi, mettere la sicurezza al primo posto è sempre un obbligo. Sebbene la gestione delle identità in un ambiente ibrido possa sembrare semplice come unire un dispositivo Windows all'AAD, non tenere conto dei cambiamenti del panorama dei rischi apre la porta a problemi che possono causare problemi in futuro. cambiamenti nel panorama dei rischi apre la porta a problemi che possono causare grattacapi in futuro. La conoscenza è sempre la prima linea di difesa, ma la quantità di documentazione necessaria per comprendere appieno la sicurezza nel DAA è scoraggiante. Gli strumenti nativi o di terze parti che automatizzano la comprensione e riducono la complessità della sicurezza contribuiranno a ridurre il rischio di sicurezza durante e dopo l'implementazione dell'ambiente ibrido.
