Penso sia stato uno dei pochi eventi ufficiali di Microsoft a Vicenza, la città in cui vivo, ma l’importanza del lancio di Windows 2000 Server e del suo servizio principale, l’Active Directory, giustificava la presenza di Microsoft in piazze “minori”. Da subito capii l’importanza che avrebbe assunto l’Active Directory in tutte le organizzazioni e iniziai a formarmi in tal senso, accettando di buon grado gli “sfottò” dei colleghi estimatori di “Novell Directory Services”.
Non si contano i domini Windows NT4 che, nei successivi 3, 4 anni, migrai verso Active Directory. Le aziende impiegarono alcuni anni per prendere coscienza dei benefici offerti da Active Directory, ma oggi, quante sono le aziende che non la utilizzano?
Grazie ad essa si superarono i confini dei domini NT4, molto limitati a causa dei vincoli tecnici della replica a Master Singolo e questa esigenza di “allargamento dei confini” la vedo ripetersi oggi; la “governance” che le organizzazioni esercitano all’interno della propria foresta (o foreste) AD, vogliono esercitarla quando dispositivi e utenti si collegano da reti meno sicure: internet.
I miglioramenti in termini di sicurezza, efficienza e flessibilità del lavoro sono di immediata percezione, ma lo è anche la complessità dell’architettura che il personale IT deve gestire.
Corretto, ma da dove cominciamo?
A mio avviso ci sono delle regole, meglio, dei “comandamenti”, ai quali bisogna attenersi.
Centralizzazione delle identità:
gli “oggetti” della mia organizzazione devono essere gestiti da un solo punto.
Identificazione inequivocabile:
ogni accesso alle risorse aziendali deve essere identificato con certezza.
Iniziamo dalla centralizzazione delle identità. Facile. Questo problema lo abbiamo già risolto adottando l’Active Directory, ma, purtroppo, la nostra Active Directory non si estende al di fuori della rete locale. Tuttavia, è possibile “replicare” una parte della nostra AD e renderla accessibile dall’esterno, in sicurezza, mettendo a disposizione un servizio di autenticazione e di autorizzazione con “Web Based Protocols” quali SAML, OAuth+OID Connect. Il servizio di directory disponibile sul web si chiama Azure Active Directory (AAD).
Questo permette di identificare inequivocabilmente l’utente. Ma come posso identificare il dispositivo?
Semplice. (Beh! non proprio 🙂 ) Con lo stesso strumento con cui sincronizziamo gli utenti, sincronizziamo i computer (alias Dispositivi) e, così come effettuiamo il join dei dispositivi ad Active Directory on-prems, effettuiamo il join degli stessi ad Azure AD. Questo “doppio join” prende il nome di Azure AD Hybrid Join.
Da qui possiamo partire per superare tutti i confini e accedere alle opportunità offerte da cloud, anzi dal MultiCloud. La gestione centralizzata continuiamo a farla con i cari, vecchi, Active Directory Domain Services (ADDS).
Parliamo di sicurezza
La sicurezza è un argomento troppo vasto, ma voglio spendere due parole su un paio di strumenti per aumentarne il livello.
Sappiamo identificare l’utente e il dispositivo dal quale si collega, ma questo non è sufficiente a garantire la tranquillità della connessione. Vogliamo avere la certezza che la persona sia realmente chi dice di essere e che il dispositivo sia conforme alle nostre politiche di sicurezza.
MultiFactor Authentication (MFA)
La garanzia sulla persona si ottiene chiedendo una conferma con un secondo fattore di autenticazione (ad esempio un codice inviato via SMS o una richiesta di conferma al dispositivo mobile). Uno studio di Microsoft mostra che la possibilità di compromissione delle credenziali si riduce del 99,9% in presenza di MFA.
Conditional Access
Basandosi su alcuni segnali che arrivano dalla richiesta di connessione alla risorsa (ad esempio la rete sorgente, il dispositivo, la presenza di un antivirus aggiornato o altro) possiamo prendere una decisione (ad esempio bloccare l’accesso, richiedere la MFA o limitare le funzionalità dell’applicazione)
Queste due funzionalità sono offerte dalle versioni premium di Azure AD. La MFA per le applicazioni della suite Microsoft 365 sono disponibili anche in Azure AD per Office 365.
Mi avete convinto, iniziamo
Tutte le foreste ADDS che migrai da Windows NT sono ancora operative o, sono state consolidate in altre foreste ADDS. I tecnici delle organizzazioni per le quali abbiamo lavorato sanno che il mio approccio ad una Active Directory che presenta errori o progettata male è sempre quello di preservare e correggere.
La stessa lunga vita va assicurata in questa fase di estensione al cloud. Bisogna quindi considerare questi aspetti:
- Conoscenza dell’organizzazione aziendale
E’ fondamentale conoscere molto bene l’organizzazione aziendale, le persone, le applicazioni utilizzate e per questo è necessaria la composizione di una squadra che riesca a raccogliere e formalizzare tutte queste informazioni - Conoscenza del campo di gioco
Servono spiccate competenze tecniche per progettare e implementare queste soluzioni che costituiranno il “campo di gioco”. I giocatori saranno le applicazioni, che potranno cambiare nel tempo. Ma se il campo di gioco non c’è o se il terreno è dissestato, i giocatori non potranno scendere in campo o non si esprimeranno al meglio - Adozione graduale
Dopo aver creato il “campo di gioco” è bene iniziare con un ristretto gruppo di persone e dispositivi
E poi?
Bella domanda. Quando creavo le prime foreste AD non avrei mai pensato allo scenario che oggi chiamiamo Cloud, ma penso di non sbagliare considerando Azure Hybrid AD Join un passo per arrivare ad una centralizzazione delle identità “Fully Cloud”.
Un passo necessario sul quale dobbiamo porre la massima attenzione per governare, e non subire, questa fase di coesistenza e rendere la nostra organizzazione “Cloud Opportunity Ready”.
Enrico Giacomin
Solution Designer – SMEUP ICS
My LinkedIn Profile
Naviga per categoria:
Seleziona una categoria d’interesse dal nostro magazine
