Due anni di OneIdP: costruire la fiducia zero oltre l'identità

C'è una domanda che ogni amministratore IT prima o poi smette di porsi ad alta voce perché ha accettato che non ha una risposta univoca.

"Come mai so tutto di questo dispositivo, ma quasi nulla di chi è seduto proprio di fronte ad esso in questo momento?"

Hai a disposizione lo stato delle patch, la conformità, l'inventario delle app e la posizione. Puoi cancellare tutto da remoto alle 2 del mattino dal tuo telefono. Ma la persona che effettua l'accesso alle 9 del mattino? Si tratta ancora in gran parte di un accordo basato su una stretta di mano e di una password che probabilmente è stata riutilizzata da altri tre account.

È proprio per colmare quel divario che esiste OneIdP. E a due anni dall'avvio, ecco la storia vera di ciò che è servito per colmarlo.

Il mondo in cui vivevano effettivamente i team IT

La risposta convenzionale era già ben consolidata: acquistare uno strumento IAM, integrarlo con il proprio UEM e configurare l'SSO da qualche parte nel mezzo. 

Fornitori diversi, dashboard diverse e punti diversi in cui la tua politica può silenziosamente contraddirsi nel momento in cui un caso limite si presenta alla porta.

Il problema più profondo era che Scalefusion Gli ambienti IT aziendali riconosciuti non sono costruiti attorno a scenari ideali, bensì attorno alle eccezioni. Dispositivi condivisi, onboarding da remoto, collaboratori esterni con laptop personali e team distribuiti su cinque fusi orari, solo per citarne alcuni.

Non si trattava di casi limite da gestire. Erano le effettive condizioni operative.

Eppure, la maggior parte delle strategie di accesso erano ancora state concepite per un mondo in cui tutti si presentavano nello stesso ufficio, utilizzando lo stesso dispositivo gestito, ogni singolo giorno. Quindi l'autenticazione diventava il surrogato di tutto. L'autenticazione veniva considerata un problema risolto. Verifica la password, concedi la sessione. Fatto.

La maggior parte delle decisioni relative all'accesso veniva ancora presa avendo a disposizione solo un quadro parziale della situazione. Perché sapere chi è una persona non fornisce quasi nessuna informazione sul dispositivo da cui effettua l'accesso. Se il dispositivo è stato aggiornato, se appartiene all'organizzazione, se si tratta del computer registrato nel trimestre precedente o di un portatile personale nella hall di un hotel.

Era proprio questo il divario che ci eravamo prefissati di colmare.

Cosa abbiamo lanciato il primo giorno e perché era solo l'inizio

Quando abbiamo lanciato OneIdP, abbiamo fatto una scelta deliberata che la maggior parte dei team di prodotto non fa. Abbiamo rilasciato una base solida anziché un elenco di funzionalità.

Una directory cloud. Accesso condizionale tramite Keycard. Autenticazione a più fattori integrata nella stessa dashboard che i team IT utilizzavano quotidianamente. Le fondamenta sono state volutamente solide prima di essere arricchite di funzionalità. 

keycard Consente ai team IT di impostare condizioni di accesso reali: posizioni approvate, intervalli IP attendibili, reti Wi-Fi specifiche e finestre temporali. Per i team che utilizzano password condivise e accessi senza contesto, anche quella prima versione rappresentava un modo di lavorare diverso.

Una base solida, prima di iniziare a costruire.

E poi è successo qualcosa che ci ha fatto capire che le fondamenta erano state gettate. E nel giro di pochi mesi, i clienti non chiedevano più se OneIdP funzionasse. Pensavano già a cosa sarebbe successo dopo. 

• Come integrare la loro configurazione Okta o Entra esistente. 
• Come prendere decisioni di accesso che riflettano la conformità del dispositivo, e non solo l'identità. 
• Come far funzionare il sistema per team che lavorano su turni e condividono le macchine per l'intera giornata lavorativa.

Quella era la mappa, e noi l'abbiamo seguita.

Due anni di lavoro per realizzare quella realtà.

La maggior parte degli strumenti di gestione dell'identità si basa su presupposti.

Che una credenziale valida garantisca una sessione sicura. Che i team IT ricostruiranno la loro directory per adattarla alla nuova piattaforma. Che ci sarà qualcuno con una profonda esperienza in materia di IAM (Identity and Access Management) disponibile per gestire il tutto.

Questi presupposti sono stati integrati nella gestione degli accessi aziendali per anni, semplicemente perché nessuno si è mai fermato a metterli in discussione.

Abbiamo interrogato tutti e tre.

1. L'identità è sufficiente per concedere l'accesso

L'SSO, così come è sempre stato implementato nel settore, si interrompe nel momento in cui le credenziali vengono verificate. L'utente è chi dichiara di essere. Sessione concessa.

Ciò che non è mai stato chiesto è cosa si nasconda dietro le credenziali. Se il dispositivo sia aggiornato. Se la richiesta provenga da una posizione plausibile. Se l'applicazione a cui si sta accedendo debba essere aperta su quella specifica macchina in quel preciso momento.

Noi abbiamo costruito Criteri di accesso esteso (XAP) chiedere proprio questo.

Ogni accesso viene valutato nel contesto completo. I segnali di conformità del dispositivo in tempo reale provenienti da Veltar alimentano direttamente la decisione di accesso. Se qualcosa non è a posto, l'accesso viene bloccato prima che si apra qualsiasi cosa. Nessuna revisione manuale. Nessun intervento dell'amministratore. La policy funziona e basta.

Poi abbiamo esaminato l'altro lato dello stesso problema.

Su un dispositivo che OneIdP già conosce e di cui si fida, chiedere all'utente di digitare nuovamente la password non aggiunge nulla. È solo un ostacolo che comunica implicitamente a chi si trova dietro lo schermo che il reparto IT non si fida di lui. L'SSO avanzato sui dispositivi gestiti elimina completamente questo problema. Lo stato di conformità del dispositivo diventa la credenziale. L'esperienza diventa impercettibile, nel migliore dei modi.

2. Ricomincerai da capo con la tua identità

Ogni proposta del tipo "passa alla nostra piattaforma" ha lo stesso punto cieco.

Si presume che i team IT abbandoneranno anni di configurazione delle directory, integrazioni con IdP e politiche di accesso, per ricostruire tutto da zero all'interno di un nuovo strumento. Per un team che gestisce 800 dispositivi in ​​due continenti, non si tratta di una migrazione semplice.

Identity Federation è stata creata proprio per rispondere a questa realtà.

OneIdP si posiziona come livello di policy di accesso al di sopra di qualsiasi infrastruttura preesistente. Entra, Google Workspace, Okta, PingOne o configurazioni di Active Directory on-premise precedenti all'attuale team IT: tutto rimane al suo posto. 

Siamo andati ancora oltre con SCIM In entrata e in uscita. Quando qualcuno si unisce al team, l'accesso viene fornito automaticamente. Quando il ruolo cambia, l'accesso si adatta di conseguenza. Quando qualcuno lascia l'azienda, gli account vengono rimossi senza che sia necessario aprire un ticket o saltare alcun passaggio manuale. La rappresentazione della forza lavoro in tutte le applicazioni connesse rimane sempre accurata.

3. Ci sarà sempre qualcuno pronto a gestirlo

La scelta dell'architettura è la parte più semplice. È nella gestione quotidiana della piattaforma che di solito sorgono le complicazioni legate all'identità.

Password di amministratore locale Sono un buon esempio di un problema che rimane latente finché non emerge. Credenziali identiche su centinaia di macchine, invariate per mesi, perché la rotazione manuale è un'operazione per cui nessuno ha tempo. LAPS ha automatizzato questo processo. La rotazione avviene secondo una pianificazione prestabilita. Ogni credenziale viene verificata. Il rischio scompare senza richiedere alcun intervento da parte di nessuno.

Il portale utenti ha fornito ai dipendenti un unico punto di accesso per tutte le applicazioni autorizzate. Gestito dal reparto IT, sempre aggiornato, senza ambiguità su ciò che è approvato. Il tipo di soluzione che non genera elogi ma elimina definitivamente una specifica categoria di richieste di assistenza.

L'SSO basato sul dispositivo ha risolto il problema dei dispositivi condivisi, rimasto irrisolto sin dal lancio. Qualsiasi utente registrato su una macchina gestita ottiene l'accesso alle proprie applicazioni. Non è necessaria una nuova registrazione tra un turno e l'altro. L'accesso segue l'utente. Il dispositivo rimane pronto per chiunque lo utilizzi successivamente.

I registri di accesso SSO hanno fornito a ogni CISO la traccia di controllo richiesta durante la prima revisione della sicurezza, in modo automatico e senza bisogno di alcun intervento manuale tramite fogli di calcolo.

Tre presupposti. Tre decisioni deliberate per costruire in modo diverso.

Ma le decisioni prese sulla carta e quelle prese nella fase di produzione sono due cose ben diverse.

Ecco come si sono svolti i fatti.

La cronologia, onestamente

È utile capire come si è sviluppato il tutto, non come una tabella di marcia del prodotto, ma come una serie di risposte a ciò che stavamo imparando:

Ecco come si presenta OneIdP oggi.

Al momento del lancio, le discussioni vertevano sulla costruzione di solide fondamenta. Integrare la fiducia e l'identità dei dispositivi nello stesso livello di policy. Far sì che l'accesso condizionale riflettesse effettivamente ciò che accadeva sull'endpoint in tempo reale.

Oggi, le discussioni vertono su ciò che questa infrastruttura di base può supportare. Integrazioni più profonde, una copertura più ampia della flotta, politiche di accesso che si estendono ulteriormente all'interno dell'infrastruttura, perché la piattaforma è stata progettata proprio per questo.

Questa progressione, dalle fondamenta alla piattaforma completa, è esattamente dove volevamo arrivare.

OneIdP Oggi, identità, affidabilità del dispositivo e policy di accesso vengono valutate congiuntamente, a ogni singolo accesso, in tempo reale e senza alcuna separazione tra l'endpoint gestito e l'accesso controllato. Il dispositivo e la persona che lo utilizza finalmente convivono nello stesso universo di policy.

Ciò a cui ci siamo sempre attenuti è un principio che viene costantemente messo alla prova nello sviluppo del prodotto: "la piattaforma di accesso più sofisticata è valida solo nella misura in cui il team IT è in grado di gestirla efficacemente. Un team snello che gestisce un parco macchine distribuito non dovrebbe aver bisogno di un ingegnere IAM dedicato per garantire il corretto funzionamento del sistema."

Ogni versione rilasciata negli ultimi due anni ha rispettato questi principi: essere sufficientemente potente per un ambiente complesso e al contempo sufficientemente funzionale per le persone che lo utilizzano quotidianamente.

È proprio questo equilibrio che ci rende più orgogliosi.

Cosa sta arrivando

Due anni di lavoro a fianco di team IT ti insegnano qualcosa di utile: il problema è sempre più grande di quello che hai appena risolto.

La fiducia nei dispositivi ha sollevato interrogativi sull'accesso alla rete. L'accesso alla rete ha sollevato interrogativi sull'infrastruttura. Il supporto RADIUS nel cloud e l'accesso SSH basato sull'identità sono le prossime risposte, già in fase di sviluppo e frutto delle stesse discussioni che hanno generato tutto quanto sopra. 

L'ambito di applicazione del modello di accesso zero trust è in continua espansione e intendiamo espanderci di conseguenza.

Pronti a scoprire a che punto è OneIdP oggi?

Iscriviti per una prova gratuita di 14 giorni.

Esplora la piattaforma