Single Sign On: Domande da porre

Il nonno diceva sempre: “Non provare mai nulla di nuovo. Aspetta e vedi se prima uccide qualcuno”. Recentemente, sono stato coinvolto nel portare a termine diversi progetti di Single Sign On, e le sue parole mi hanno costantemente ronzato nella mente. Una parte di me dice: “È una cattiva idea avere solo un nome utente e una password per accedere a tutto”. Se si verifica un attacco hacker, l'intruso entra in possesso delle loro cose, hanno accesso a tutto. Ma l'altra parte lo guarda e dice: “Gli utenti adoreranno questa cosa”. È la classica situazione in cui sei stupido se lo fai, e stupido se non lo fai. Quindi, cosa fai?

Cos'è il Single Sign On?

Quando osservi per la prima volta il Single Sign On (SSO) dal punto di vista di qualcuno che è aggiornato sulla sicurezza, ma non ne comprende i dettagli, l'SSO sembra un suicidio a livello aziendale. Il nome stesso, Single Sign-On, evoca immagini dell'uso di un unico set di credenziali per tutto, ma in realtà è progettato per semplificare la vita agli utenti, senza compromettere la sicurezza. Quello che stai facendo è sfruttare qualcosa chiamato SAML (Security Assertion Markup Language, nientemeno). Si tratta di un formato di dati open source basato su XML che ci permette di scambiare dati di autenticazione e autorizzazione tra diverse applicazioni o parti. In realtà, rafforza un po' le cose aggiungendo un altro strato, per così dire, sfruttando le informazioni degli utenti AD o LDAP.

Quindi abbiamo potenziato la sicurezza collegando come influenzano i diritti già concessi in AD. Nella maggior parte dei casi, se c'è un nome utente/password separati associati a un'applicazione, questi vengono inseriti una volta sola, e l'app SSO ci dà accesso. Sembra un po' spaventoso, ma tenete presente che i normali blocchi di AD sono ancora funzionanti, e abbiamo il vantaggio aggiunto che se l'account è compromesso, la maggior parte dei software SSO sono dotati di alcune funzionalità di reportistica davvero potenti. Quindi possiamo rilevare gli account compromessi e i dati a cui è stato acceduto.

Domande da fare prima di impegnarsi nel Single Sign On

Voglio fare l'avvocato del diavolo e porre la domanda che tutti hanno in mente. Quanto è davvero sicuro?

Beh, come il Diavolo, ti terrò sulle spine per la risposta e dirò che esamineremo quello nelle prossime settimane. Per ora, supponiamo che tu voglia implementare il Single Sign On nella tua organizzazione. Se desideri il SSO nella tua organizzazione, ecco un paio di cose a cui pensare.

Primo punto dell'elenco, stiamo parlando di qualcosa di nuovo o di un aggiornamento? Molte volte si tratta di un nuovo prodotto SSO che sostituisce uno vecchio. Proprio lì, è necessario iniziare a pensare alla formazione e alla comunicazione. Comunicazione – affinché gli utenti sappiano cosa sta succedendo, formazione (anche se si tratta solo di un video online) – su come utilizzare il nuovo prodotto.

Cosa stiamo cercando di fare con esso? Stiamo cercando di centralizzare l'accesso? Tentiamo di migliorare la sicurezza migliorando l'autorizzazione? O che ne dici di una semplice e vecchia revisione? Forse stiamo cercando di realizzare tutti e tre. La cosa fondamentale è che sicuramente aiuta a realizzare un progetto di successo quando sai cosa aspettarti alla fine di tutto.

Decidere quali applicazioni vogliamo rendere accessibili fin dall'inizio è molto importante. La maggior parte delle applicazioni funzionerà bene con un SSO, ma altre no. Le “altre” potrebbero renderti la vita davvero difficile e richiedere l'intervento di terze parti e più di un pizzico di creatività per farle funzionare. Quindi aspettati questo.

Chi se ne occuperà? Qualcuno deve essere responsabile del sistema e potrebbe coinvolgere diverse persone a vari livelli dell'azienda per gestirlo. Ad esempio, in un recente progetto SSO, ero responsabile della configurazione sui server, dell'aiuto nella gestione del progetto e dell'avvio delle applicazioni iniziali e del seeding degli utenti. Ma si è stabilito fin dall'inizio che in futuro i nuovi utenti sarebbero stati aggiunti dal personale di Tier 1. Quindi abbiamo dovuto formarli almeno fino a quel punto. Le applicazioni, tuttavia, così come la cura e la manutenzione dei server (per non parlare degli aggiornamenti futuri e del DR) sarebbero state saldamente nelle mie mani.

Probabilmente l'aspetto più importante da considerare è se l'SSO che acquistiamo continua a crescere ed evolversi man mano che l'azienda cresce ed evolve.

E come si diceva negli anni '60, non toccare la manopola.