Federazione, sincronizzazione e account Guest
Molte aziende hanno distribuito servizi directory locali, ad esempio Active Directory, all'interno dell'organizzazione per archiviare le informazioni relative a utenti e altre entità. In alcuni casi, questi servizi sono in uso da decenni e le informazioni che contengono sono voluminose e vitali per il buon funzionamento dell'organizzazione.
Quando organizzazioni come queste passano al cloud, uno dei problemi che si trovano ad affrontare è come controllare l'accesso alle risorse cloud con le stesse identità utente, gruppo e applicazione che usano per controllare l'accesso alle risorse locali. Una soluzione potrebbe essere l'uso di identità separate e credenziali separate per le risorse locali e le risorse cloud, ma è tutt'altro che ideale. Se un utente lascia l'organizzazione sarà necessario rimuoverlo dalla directory cloud e dalla directory locale. Gli utenti saranno inoltre costretti a destreggiarsi tra molteplici account. Una situazione che, oltre a essere scomoda, costituisce anche una minaccia per la sicurezza.
Per estendere i servizi directory locali al cloud sono disponibili tecnologie che semplificano l'amministrazione delle risorse cloud ed evitano che gli utenti debbano usare un set di credenziali per accedere a una risorsa locale e un altro set di credenziali per accedere a una risorsa cloud. Una di queste tecniche è la federazione, un'altra è la sincronizzazione. Un problema distinto ma correlato è come consentire ad utenti esterni, ad esempio terzisti che non fanno parte dell'organizzazione ma che lavorano per conto dell'organizzazione, di accedere alle risorse cloud aziendali senza rilasciare loro credenziali per il sistema. Una soluzione elegante e usata di frequente sono gli account Guest. Di seguito verranno esaminati la federazione, la sincronizzazione e gli account Guest, si illustrerà cosa sono e il ruolo che svolgono nell'amministrazione cloud.
Federazione
La federazione precede il cloud. Lo scopo è quello di creare una relazione di trust tra le organizzazioni in modo che l'organizzazione A possa accedere alle risorse di rete dell'organizzazione B senza che quest'ultima rilasci credenziali ai membri dell'organizzazione A. La federazione si basa su standard quali ad esempio WS-Fed che definiscono i protocolli usati per gestire le informazioni relative all'identità nei vari sistemi. I servizi federativi, ad esempio Active Directory Federation Services (ADFS) di Microsoft, implementano i protocolli WS-Fed e connettono i sistemi di identità in modo che le identità dell'organizzazione A possano essere usate come identità federate dall'organizzazione B. In altre parole, la federazione consente agli utenti esterni di accedere alle risorse interne. Ovvero estende le identità di un'organizzazione oltre i confini dell'organizzazione stessa.
Si supponga che due aziende denominate Contoso e Fabrikam stabiliscano un'alleanza strategica. Contoso vuole che i dipendenti di Fabrikam abbiano accesso a determinate condivisioni file nella rete di Contoso e viceversa. Le due aziende attuano la federazione dei sistemi di identità che consente ai dipendenti di Fabrikam di accedere alle risorse di Contoso con le stesse credenziali che usano per accedere alle risorse di Fabrikam. Al momento di aggiungere utenti all'elenco di quelli autorizzati ad accedere alle condivisioni file, gli amministratori IT di Contoso vedranno i dipendenti della propria azienda e quelli di Fabrikam, anche se Contoso non ha mai creato account per i dipendenti di Fabrikam. In breve, questa è la federazione.
La federazione non si limita alla connessione delle reti locali di organizzazioni diverse, ma può anche essere usata per estendere le identità locali al cloud. Azure, AWS e GCP offrono soluzioni di gestione delle identità che consentono ai servizi directory locali, ad esempio Active Directory, di inviare informazioni sull'identità anche ai servizi cloud. Se un utente prova ad accedere a una risorsa cloud protetta, la richiesta viene reindirizzata alla soluzione di directory locale che autenticherà l'utente come se questo stesse accedendo a una risorsa locale (Figura 3.4). Ciò consente la gestione centralizzata di utenti, credenziali e autorizzazioni. Evita inoltre che gli utenti debbano usare un account separato per accedere alle risorse cloud della propria organizzazione.
Figura 3.4: Flusso di identità federata.
La federazione è ampiamente usata dalle organizzazioni per proteggere l'accesso alle risorse cloud usando le stesse informazioni di identità che proteggono l'accesso alle risorse locali. Ma non è perfetta. Richiede una connessione affidabile tra il servizio directory locale e il cloud, in modo che sia possibile consultare la directory locale ogni volta che un utente accede a una risorsa cloud che richiede l'autenticazione. Una soluzione a questo problema, oltre che un altro mezzo per condividere le credenziali tra le directory locali e il cloud, è la sincronizzazione.
Sincronizzazione
La sincronizzazione è un'alternativa alla federazione. Con la sincronizzazione, le informazioni della directory locale vengono sincronizzate periodicamente con una directory nel cloud. La differenza principale tra la federazione e la sincronizzazione risiede nel fatto che con la prima l'autenticazione avviene in locale, mentre con la sincronizzazione l'autenticazione avviene nel cloud.
La sincronizzazione viene implementata tramite l'installazione di un servizio di sincronizzazione all'interno dei sistemi locali dell'organizzazione (figura 3.5). Il servizio sincronizza periodicamente le informazioni utente tra la directory locale e la directory cloud. Tutte le operazioni di autenticazione vengono quindi eseguite nella directory cloud che contiene le stesse informazioni della directory locale.
Figura 3.5: Flusso di identità sincronizzata.
Una differenza operativa fondamentale tra la federazione e la sincronizzazione è che quest'ultima è più resiliente alle interruzioni della connettività. La sincronizzazione non richiede l'accesso alla directory locale ogni volta che un utente accede a una risorsa cloud. L'accesso è necessario solo quando avviene la sincronizzazione. Lo svantaggio principale della sincronizzazione è che la propagazione al cloud delle modifiche apportate alla directory locale richiede tempo. Se un amministratore aggiunge Alice alla directory locale ma la sincronizzazione avviene solo ogni ora, prima di poter accedere alle risorse cloud protette, Alice potrebbe dover attendere fino a un'ora dopo che è stata apportata la modifica.
Sono disponibili strumenti come Microsoft Entra Connect per la sincronizzazione delle directory. Azure AD Connect sincronizza le informazioni archiviate localmente in Active Directory con quelle archiviate nel cloud in Microsoft Entra ID. Amazon propone un'offerta simile con AD Connector, così come Google con Google Cloud Directory Sync (GCDS).
Le soluzioni di sincronizzazione sono generalmente preferibili agli approcci basati sulla federazione. In genere comportano un sovraccarico minore in termini di gestione e non richiedono una connessione sempre disponibile tra i servizi directory. Questo consiglio viene ripreso anche dal National Cyber Security Centre del Regno Unito1.
Account Guest
Un altro problema per il reparto IT è la modalità di gestione degli utenti esterni all'organizzazione. Questi utenti spesso includono terzisti, consulenti e stagisti, ovvero utenti che non sono formalmente parte dell'organizzazione, ma che necessitano dell'accesso alle risorse interne come se lo fossero.
Una soluzione consiste nella creazione di account interni per utenti esterni. Questi account spesso usano un prefisso o un suffisso nei nomi account che ne denota la natura esterna. In Microsoft, ad esempio, la maggior parte degli account esterni ha nomi come v-jeffpro, dove "v" sta per "vendor" (fornitore). Questo approccio, tuttavia, è tutt'altro che perfetto. Tanto per cominciare, aggrava il fenomeno della proliferazione degli account. ("Ecco un altro nome utente da monitorare e un'altra password che deve essere cambiata ogni 60 giorni ed essere conforme ai criteri specifici di questa organizzazione.") Aumenta anche il carico di lavoro che grava sugli amministratori poiché aumenta il numero di account dei quali sono responsabili e li costringe a definire un meccanismo o un processo per la propagazione delle modifiche dello stato degli utenti esterni presenti all'interno delle proprie organizzazioni ai sistemi di gestione delle identità interni. Ad esempio, se un consulente con credenziali di "esterno" va in pensione o decide di accettare una posizione altrove, le sue credenziali dovranno essere revocate in modo che non possano più essere usate per accedere ai sistemi.
Una soluzione migliore consiste nell'uso di account Guest. Gli account Guest sono un caso particolare di account federati. Gli utenti esterni sono "invitati" a entrare nel sistema di gestione delle identità di un'organizzazione usando le credenziali della propria organizzazione. Viene creato un nuovo record utente, ma quando l'utente guest esegue l'autenticazione, questa avviene nell'organizzazione principale dell'utente. In questo modo, l'utente non dovrà gestire un altro set di credenziali e il reparto IT non dovrà essere informato quando lo stato dell'utente cambia nell'organizzazione principale. Dopo che il personale IT dell'organizzazione principale lo avrà rimosso dal sistema, l'utente non sarà più in grado di eseguire l'autenticazione in nessuno dei due sistemi.
Riferimenti
- National Cyber Security Centre (2019). Securing Office 365 with better configuration. https://www.ncsc.gov.uk/blog-post/securing-office-365-with-better-configuration