Il futuro dei servizi di directory è senza dominio

Gli approcci fondamentali alla sicurezza, alla gestione dei dispositivi e al controllo degli accessi stanno cambiando.

Per quasi 30 anni, queste priorità IT fondamentali sono state inseparabili da Active Directory e OpenLDAP, che erano soluzioni eccellenti nell'era del dominio on-premise. Ma il recente passaggio al lavoro da remoto chiarisce che la tradizionale sicurezza perimetrale e l'infrastruttura on-premise non sono più sufficienti per proteggere le identità degli utenti e i dati riservati di un'organizzazione nel cloud.

Per gestire al meglio gli ambienti di lavoro moderni, è necessario reimmaginare le singole funzioni di un servizio di directory e separare tali funzioni dal concetto datato di dominio cablato, castello e fossato. Ciò che conta di più oggi è proteggere l'utente e il dispositivo, non importa in quale parte del mondo si trovino.

Il futuro dei servizi di directory, quindi, è senza dominio. Ecco uno sguardo più dettagliato su come siamo arrivati ​​qui, come appare in pratica l'impresa senza dominio e i passaggi che le organizzazioni possono intraprendere per modernizzare la propria infrastruttura IAM.

Reimmaginare i servizi di directory e il concetto di dominio

Il concetto di dominio come lo conosciamo è stato essenzialmente concepito negli anni '90 ed era un'eccellente soluzione per la sicurezza degli utenti e la governance dei computer negli ambienti di ufficio cablati dell'epoca. Mentre la maggior parte delle altre aree dell'IT si è completamente trasformata da allora, questo modello è ancora alla base degli approcci della maggior parte delle organizzazioni all'identità e alla gestione degli accessi oggi.

Molti professionisti IT danno per scontato il dominio e ritengono che il passaggio logico successivo sia quello di adattarlo ed estenderlo all'era del cloud aggiungendo provider SSO (Single Sign-On) di applicazioni Web e altri bridge di identità. Ma un approccio più pratico potrebbe essere quello di guardare indietro ai problemi fondamentali per i quali il dominio era stato inizialmente progettato, decidere quali di questi problemi sono ancora rilevanti oggi ed esplorare nuovi modi per risolverli utilizzando le innovazioni moderne.

Tra la metà degli anni '90 e la metà degli anni 2000, gli ambienti dell'ufficio erano molto diversi. I lavoratori sono entrati in stabilimenti fisici utilizzando chiavi magnetiche o chiavi reali. Si avvicinarono alle loro scrivanie e si sedettero davanti a computer fissi. Quei computer erano collegati tramite un cavo Ethernet a un data center interno oa un armadio server all'interno dell'ufficio fisico. Dall'interno di tale posizione centrale, il controller di dominio ha concesso l'accesso alle risorse IT all'interno della rete locale. Quella rete fisica, a sua volta, era protetta dagli attacchi esterni da un firewall e dall'edificio stesso per l'accesso fisico.

All'epoca, questa configurazione era essenzialmente sicura e semplice da gestire e offriva un'esperienza utente così semplice che gli utenti non dovevano gestire più password o pensare ai processi di autorizzazione e autenticazione che avvenivano dietro le quinte. Gli ambienti erano omogenei, con una torre desktop che eseguiva programmi Windows e Microsoft su ogni workstation. Active Directory (AD) era così adatto a questo tipo di ambiente da offrire agli utenti quella che forse è stata la prima esperienza Single Sign-On (SSO): un unico set di credenziali per accedere alle risorse IT basate su Windows tramite un unico accesso al sistema.

Ora, vai avanti veloce al presente e abbatti tutti i muri di quell'edificio. L'IT tendeva alla flessibilità fuori dall'ufficio, resa possibile dalla tecnologia cloud e dalla connessione Internet wireless ad alta velocità ampiamente disponibile. Invece di computer fissi con torri e monitor a tubo, i dipendenti ora hanno laptop e altri dispositivi che possono portare con sé quasi ovunque, connettersi a Internet e iniziare a lavorare. Questa è l'impresa senza dominio in poche parole, e questa è la nostra realtà attuale.

Ma in un mondo in cui così tanto lavoro viene svolto al di fuori del dominio, i dipartimenti IT sono costretti a rivalutare le sfide che Active Directory una volta gestiva da solo.

Le carenze moderne del modello di dominio

Active Directory ha faticato ad adattarsi e integrarsi con le moderne risorse cloud e con i sistemi operativi non Windows e il modello di sicurezza perimetrale per cui è stato progettato non è sufficiente per proteggere i lavoratori remoti.

Quindi la domanda diventa come tradurre il flusso di lavoro amministrativo centralizzato e l'esperienza utente semplice e sicura una volta offerta da AD in un ambiente moderno che include sistemi Mac e Linux, app Web, server cloud e reti remote, e può essere ancora attivo o meno -infrastrutture prem pure. Gli utenti devono connettersi alle proprie risorse IT con il minimo attrito indipendentemente da dove lavorano e gli amministratori IT devono essere sicuri che le identità degli utenti e i dati proprietari siano protetti dagli attacchi.

Il problema è che l'IT non ha quasi il livello di controllo sulle moderne identità degli utenti che avrebbe avuto in un ambiente di dominio AD convenzionale. Le applicazioni sono migrate da un'architettura legacy con acquisto unico e installazione locale a un modello di abbonamento basato su cloud. Alcune app sono ancora installate localmente, con identità e configurazioni gestite nel cloud tramite un browser web.

Lasciati a gestire le proprie identità, gli utenti si ritrovano con decine, se non centinaia, di password e affrontano la tentazione di ignorare le linee guida di sicurezza e condividere o riutilizzare password deboli.

Gli utenti possono anche essere tentati di creare i propri account per le nuove applicazioni come meglio credono, senza l'approvazione o la regolamentazione dell'IT. Questo IT ombra rappresenta un rischio per la sicurezza non necessario per l'organizzazione. E anche le identità gestite dall'IT potrebbero esistere nei propri silos, con ciascuna identità separata che richiede il proprio processo di provisioning e deprovisioning manuale.

Non esiste un'identità unica e centrale analoga all'identità AD del passato. Gli amministratori hanno bisogno di un nuovo modo per proteggere le connessioni, mantenere tutto al sicuro sotto la sfera di competenza dell'IT, soddisfare le basi di sicurezza e conformità e preparare i dispositivi per il lavoro remoto.

Quando si tratta di sistemi, i MacBook e i sistemi Linux sono ormai all'ordine del giorno. Laddove un tempo amministratori Microsoft esperti resistevano all'introduzione dei sistemi Mac sul posto di lavoro, ora è pratica standard accogliere tali sistemi. In un dominio Active Directory tradizionale, la gestione del sistema Mac e Linux non sarebbe così semplice o sicura senza l'aggiunta di altre soluzioni puntuali oltre ad AD, come uno strumento di gestione del sistema o persino un MDM.

Gli ambienti di dominio basati su OpenLDAP non sono molto migliori: i domini e i server LDAP gestiscono principalmente identità, password, gruppi e unità organizzative, ma spesso mancano di gestione del sistema, applicazione delle policy di sicurezza e capacità di integrazione delle app cloud. Le risorse IT sono passate dal semplice utilizzo di LDAP come protocollo di autenticazione preferito allo sfruttamento di standard moderni come SAML, SCIM, OAuth, OIDC e altri. Anche gli ambienti LDAP legacy richiedono un elevato grado di esperienza per la configurazione e la manutenzione.

Il modo logico per colmare le lacune di cui sopra nella supervisione IT è implementare una moderna architettura senza dominio.

Cosa significa veramente senza dominio in pratica?

La prospettiva di passare senza dominio potrebbe sembrare un po' spaventosa per gli amministratori esperti, ma un ambiente senza dominio configurato correttamente può essere notevolmente più sicuro di una configurazione di dominio tradizionale nel panorama IT di oggi. In un ambiente senza dominio, la posizione di sicurezza dell'organizzazione avvolge ogni singolo utente, il suo sistema Mac, Windows o Linux e le risorse a cui deve accedere, ovunque si trovi ciascuno di questi componenti.

Ogni risorsa IT ora ha il proprio perimetro ristretto. Ciò significa, invece di funzionare essenzialmente non protetto entro i confini di un perimetro più ampio rafforzato dopo l'autenticazione una volta, le identità e i diritti di accesso vengono costantemente controllati e verificati. Gli utenti accedono alle proprie risorse direttamente tramite una connessione Internet standard, anziché instradare tramite un dominio per l'autenticazione. E al posto di un controller di dominio, un servizio di directory cloud gestisce la gestione degli accessi, l'autenticazione degli utenti e l'applicazione della sicurezza.

È questo concetto di servizio di directory cloud che rende praticabile l'impresa senza dominio. Ma anche se così tanti altri aspetti dell'IT sono migrati efficacemente al cloud, molti amministratori hanno delle riserve sull'implementazione di una gamma completa di servizi di directory nel cloud.

Per la maggior parte, ciò è dovuto al fatto che l'idea stessa di un servizio di directory è così indissolubilmente legata ad Active Directory: lo strumento esistente sostituisce i singoli problemi una volta risolti. E l'aspetto della sicurezza del dominio è più intuitivo: firewall e serrature ci sono familiari e ci danno una sensazione di controllo. Sembra logico che rinunciare al dominio significhi una maggiore esposizione agli attacchi e un minor controllo sulla sicurezza.

Ma la verità è che anche con misure come firewall, rilevamento della rete e rilevamento e risposta degli endpoint in atto, le organizzazioni vengono comunque violate. Dopo che ogni nuovo attacco riuscito ha raggiunto il ciclo delle notizie, la comunità IT si concentra nuovamente su come applicare una versione migliore e più forte dello stesso approccio alla sicurezza. Chiaramente, il vecchio modo di fare le cose non funziona. È giunto il momento per un approccio incentrato sul cloud fondamentalmente nuovo.

Funzioni principali di un servizio di directory cloud

L'espressione servizio di directory cloud viene utilizzata per descrivere una varietà di soluzioni che rientrano vagamente nella categoria di IAM, ma è difficile definire cosa significhi davvero questa frase da fornitore a fornitore.

Diverse soluzioni di directory cloud offrono raramente funzionalità comparabili e quasi nessuna replica l'intera gamma di funzionalità di governance, autenticazione e controllo degli accessi del sistema originale di AD come provider di identità principale di un'organizzazione. Ma questo è esattamente ciò che deve fare un servizio di directory cloud per supportare e proteggere una moderna architettura senza dominio.

In effetti, un servizio di directory cloud utile dovrebbe effettivamente andare oltre l'ambito originale di AD gestendo l'accesso ad applicazioni di terze parti e sistemi operativi non Windows da un'unica piattaforma.

Questa distinzione è importante per confrontare un vero servizio di directory cloud con una piattaforma SSO per app Web, che offre agli utenti un'identità per accedere alle loro applicazioni SaaS ma potrebbe non essere in grado di gestire l'accesso ai dispositivi, le basi di sicurezza o autenticare gli utenti su legacy o in locale risorse utilizzando i loro protocolli authN preferiti. In questo senso, SSO basato su SAML è solo un componente di un servizio di directory cloud; i termini non sono intercambiabili.

Invece di creare una traduzione uno-a-uno del modello di dominio AD stabilito nel cloud, un servizio di directory cloud adeguato suddivide le funzioni di AD nelle loro parti componenti e reinventa ciascuna di queste parti. Se riusciamo a separare i singoli problemi dalla soluzione che diamo per scontata, possiamo arrivare a nuovi modi per risolverli.

Le seguenti funzionalità principali sono essenziali per un servizio di directory cloud creato per l'azienda senza dominio:

• Un'unica identità utente sicura per accedere a dispositivi, applicazioni, WiFi/VPN, server e infrastruttura di sviluppo, sia in locale che nel cloud e indipendentemente dal fornitore
• Capacità di integrare e consolidare le identità degli utenti da altri servizi, inclusi G Suite, Office 365, AWS, AD/Azure e sistemi HR/paghe
• Capacità di provisioning e deprovisioning utenti automatizzati
• Gestione remota del sistema con controllo dei criteri simile a GPO su sistemi Mac, Windows e Linux e report approfonditi sullo stato e gli attributi del sistema
• Autenticazione a più fattori (MFA) all'accesso al sistema Mac, Windows e Linux e per l'accesso praticamente a tutte le altre risorse IT, oltre a funzionalità di gestione delle chiavi SSH
• Amministrazione flessibile e automatizzata tramite scripting, API o PowerShell
• Dati dettagliati e registrazione degli eventi per supportare le esigenze di controllo e conformità

Molti errori di sicurezza non sono riconducibili alla totale assenza di uno qualsiasi dei componenti di cui sopra, ma all'impossibilità di applicarli, applicarli e aggiornarli in modo uniforme all'interno dell'organizzazione. Con questo in mente, diventa chiaro il valore di un servizio di directory cloud centralizzato.

Le chiavi per passare al dominio senza dominio: attendibilità dei dispositivi e MFA

Sebbene molte soluzioni cloud IAM siano interamente basate su browser, mancano la chiave della moderna sicurezza senza dominio: il dispositivo. Gli utenti hanno ancora bisogno di un gateway fisico per il loro lavoro, indipendentemente dal fatto che quel gateway sia un laptop, un tablet o uno smartphone. Gran parte della costante verifica richiesta per proteggere un ambiente senza dominio dovrebbe essere gestita dal dispositivo, utilizzando un framework che possiamo considerare come attendibilità del dispositivo .

L'idea è che l'utente acceda al dispositivo una volta, utilizzando una combinazione di password o credenziali senza password più MFA, e quindi ottenga un accesso sicuro a tutte le proprie risorse IT. Ogni transazione è protetta e crittografata a livello atomico, quindi il lavoro può essere svolto in sicurezza tramite una connessione Internet standard.

L'esperienza dell'utente è simile all'esperienza SSO dell'accesso a una macchina desktop nel dominio AD di fine anni '90/inizio metà anni 2000, ma ciò che accade dietro le quinte è molto più complesso e l'ampiezza delle risorse IT disponibili per l'accesso è molto maggiore.

Affinché un servizio di directory cloud possa stabilire una relazione di fiducia con un dispositivo, è necessario soddisfare e riaffermare costantemente diversi criteri. Tali criteri semplificano la verifica che:

• L'utente giusto sta accedendo al dispositivo e quell'utente è chi dice di essere
• Il dispositivo giusto richiede l'accesso
• L'accesso viene richiesto dalla posizione corretta
• Vengono applicate le autorizzazioni corrette per l'utente/dispositivo all'interno di una determinata risorsa

È qui che il concetto di MFA si espande oltre le misure rivolte all'utente come i token TOTP e le chiavi di sicurezza WebAuthn. I requisiti di cui sopra possono essere confermati tra il dispositivo e il servizio di directory cloud, stabilendo un terzo, quarto, quinto e più fattori di autenticazione che sarebbe praticamente impossibile per un utente malintenzionato replicare insieme.

L'idea di violare una rete è radicalmente cambiata da questa ripetuta autenticazione a più fattori: non c'è più un'area non protetta da attraversare durante una sessione aperta dopo una sola autenticazione iniziale. Questo perché nel modello senza dominio, la sicurezza e il controllo degli accessi si verificano effettivamente a ogni livello invece che solo a livello di rete. Solo la persona giusta, con la macchina giusta, che accede dalla posizione giusta con le autorizzazioni appropriate può accedere a dati e applicazioni.

Un servizio di directory cloud stabilisce l'affidabilità dei dispositivi attraverso una combinazione di governance del sistema simile a GPO, software basato sul principio del privilegio minimo e crittografia di tutti i dati in transito e inattivi. Un altro modo di pensare a questo approccio è nel contesto della sicurezza zero-trust .

Sicurezza zero-trust in pratica

Sicurezza zero-trust significa che il servizio di directory incaricato dell'autenticazione non dà mai per scontata la legittimità di un utente, dispositivo, applicazione o altra risorsa IT. Si ottiene proteggendo le seguenti quattro aree: dipendenti, sistemi, applicazioni e rete.

Dipendenti

È in atto un sistema per verificare che siano veramente chi dicono di essere confermando la loro password (qualcosa che conoscono) e il loro token MFA (qualcosa che hanno) contro il database delle directory, che funge da autorevole fonte di verità.

Sistemi

Il sistema, probabilmente una macchina emessa dall'azienda, che una persona convalidata sta utilizzando per accedere alle risorse IT deve essere pulito e la persona deve avere accesso legittimo a quella macchina. In pratica, ciò significa una sorta di meccanismo per garantire che la macchina sia nota, le politiche e le impostazioni impongono gli standard di sicurezza e un alto grado di certezza che l'utente sia chi dice di essere. Il software di sicurezza viene controllato e aggiornato. La telemetria di sistema aiuta a garantire la visibilità che la macchina stessa non è compromessa.

Applicazioni

È fondamentale che solo le persone giuste, su sistemi affidabili, accedano alle applicazioni. L'estensione logica di quanto sopra, quindi, è verificare che l'utente e la macchina dispongano dei diritti sull'app e sulla rete su cui si trova l'app e verificare la sicurezza di quella rete. È qui che una VPN a volte può ancora svolgere un ruolo cruciale nell'impresa senza dominio, come tunnel sicuro verso un'applicazione o una risorsa.

Rete

Qualunque sia la rete su cui si trova l'utente dovrebbe essere il più sicura possibile, ma anche se non è completamente sicura, l'utente può creare un'enclave sicura all'interno di quella rete utilizzando una VPN. Inoltre, le reti possono essere protette tramite mezzi aggiuntivi come MFA e persino la segmentazione VLAN.

Primi passi verso l'implementazione di un'architettura senza dominio

Questa idea di un'architettura senza dominio abilitata da un servizio di directory cloud e da una sicurezza zero-trust non è puramente filosofica o un'aspirazione lontana per il futuro: è qui ora e i team IT possono iniziare a implementarla immediatamente, completamente o in un approccio graduale e graduale adatto alla loro infrastruttura esistente.

Per le organizzazioni che sono profondamente impegnate in un dominio AD funzionante, un servizio di directory cloud può avvolgere l'istanza di AD, fornendo molti dei vantaggi del modello senza dominio e fungendo da trampolino di lancio per il modello all-cloud.

Un potente servizio di directory cloud avrà la capacità di stare da solo come provider di identità principale, quindi anche le organizzazioni che non sono pronte per passare al 100% senza dominio ora hanno la possibilità di abbandonare AD senza interruzioni quando la migrazione ha senso.

Se vuoi saperne di più, esplora le informazioni sui servizi di directory cloud su G2.