E nel caso delle password, ognuna di esse – specialmente quelle dimenticate – rappresenta un piccolo rischio per la sicurezza che si aggira nell’ombra. Potresti pensare di esserti sbarazzato di esse (o almeno di averne ridotto il numero a una quantità gestibile), ma continuano a spuntare fuori. E come tutti sappiamo, le applicazioni SaaS, che si tratti di app personali o social come Facebook o delle migliaia di app aziendali oggi in uso, hanno fatto sì che questo problema, beh… si moltiplicasse rapidamente.
Il motivo principale per cui le offerte di identity-management-as-a-service (IDaaS), come Azure Active Directory, Okta e altre, sono oggi molto diffuse è che forniscono il single sign on (SSO) alle applicazioni SaaS dal browser dell'utente. Inoltre, garantiscono una maggiore sicurezza grazie alla gestione di userid e password. L'utente accede semplicemente a un portale aziendale con icone che rappresentano le app e fa clic su un'icona per effettuare il login.
Sebbene questa funzionalità rappresenti un miglioramento rispetto a un login non gestito, esistono ancora rischi significativi per la sicurezza che è necessario conoscere.
Gestione delle password SaaS: Vaulting e Replay
Prima di tutto, una breve panoramica su come le applicazioni IDaaS gestiscono le credenziali dei siti web.
Le applicazioni SaaS aziendali più grandi e più diffuse, come Salesforce, Workday, Concur e molte altre centinaia, supportano la federazione delle identità, che semplifica notevolmente l'accesso all'applicazione e ne aumenta la sicurezza. Tuttavia, la stragrande maggioranza delle applicazioni SaaS sul mercato richiede una userid e una password per effettuare il login dal browser dell'utente: un'attività disordinata, costellata da password dimenticate, password troppo semplici e blocchi adesivi con password scritte.
I servizi IDaaS utilizzano due tecniche principali per occuparsi di questo aspetto per l'utente. In primo luogo, quando l'utente accede inizialmente a uno di questi siti "a riempimento di modulo", un'estensione per l'acquisizione della password nel browser chiede se desidera memorizzare le proprie credenziali nel caveau delle password del servizio IDaaS. In secondo luogo, la volta successiva che l'utente desidera accedere all'applicazione SaaS, l'estensione del browser comunica con il servizio IDaaS per riprodurre le credenziali dell'utente nei campi userid e password, effettuando così il login senza alcuna azione da parte dell'utente.
Le password che ci sono sfuggite
Il vaulting delle password semplifica notevolmente l'accesso a queste applicazioni, soprattutto rispetto a chi cerca di tenerne traccia da solo. Tuttavia, si tratta di un approccio alla sicurezza che non ha nulla a che vedere con le gomme da masticare e i fili che si spezzano, per cinque motivi.
- In primo luogo, significa che le credenziali dell'utente sono memorizzate nel servizio cloud del fornitore IDaaS, il che è un no per le politiche di sicurezza informatica di molte aziende.
- In secondo luogo, indipendentemente dalla crittografia delle credenziali nel cloud, queste devono essere trasmesse in chiaro all'applicazione SaaS durante il processo di replay. Non c'è modo di evitarlo. In terzo luogo, le pagine di login degli utenti delle app cambiano continuamente layout, quindi il provider IDaaS deve cercare di rimanere aggiornato con migliaia di queste modifiche in modo che il replay delle password funzioni correttamente.
- In quarto luogo, nella maggior parte dei casi l’utente conosce il proprio ID utente e la propria password per l’app. (Di certo li conosceva prima che gli venisse richiesto di accedere all’app tramite il portale utenti dell’azienda.) Ciò significa che può sempre aggirare il portale ed effettuare l’accesso direttamente. Se si tratta di una nuova app che entra in servizio, alcuni fornitori di IDaaS consentono all’amministratore di caricare le credenziali per conto dell’utente, in modo che quest’ultimo non ne sia a conoscenza e sia quindi obbligato a utilizzare il portale – ma questa soluzione funziona solo per l’onboarding di nuove app. Alcuni fornitori di IDaaS hanno una capacità limitata di modificare la password per poche app, e alcuni possono offuscare l’URL di accesso dell’app, ma si tratta di una minuscola minoranza. A peggiorare la situazione, browser come Chrome o componenti aggiuntivi come LastPass offrono comodamente la possibilità di salvare la password dell’utente al momento dell’accesso. E perché mai l’utente medio non dovrebbe voler memorizzare la password per non doverla inserire di nuovo?
Infine, e soprattutto, le applicazioni SaaS non sono integrate nel sistema aziendale di gestione del ciclo di vita delle identità. Cosa significa? Significa che se si licenzia un dipendente e si disattiva il suo account nell’AD DS on-premise, l’utente non potrà più accedere alla rete aziendale né alle sue risorse. Quando tale disattivazione si replica sul servizio IDaaS, l’utente non potrà accedere a nessuna risorsa cloud che richieda il servizio IDaaS, come le applicazioni federate (Salesforce, Office 365). Questo è un aspetto positivo e soddisfa i responsabili della sicurezza.
Ma le applicazioni SaaS per la compilazione di moduli non dipendono dalle credenziali aziendali come invece avviene per le app SaaS federate. Quando quell’account utente AD DS viene disabilitato o eliminato, nell’applicazione SaaS non accade nulla. L’applicazione non ha idea di cosa sia successo in azienda. A meno che qualcuno non intervenga esplicitamente per verificare a quali applicazioni l’utente ha accesso e le disabiliti manualmente una per una, l’utente può comunque accedervi. Perché? Tutto ciò di cui l’utente ha bisogno è il proprio ID utente, la password e l’URL di accesso dell’applicazione.
Vorrei sottolineare che questi problemi non sono imputabili al fornitore di servizi IDaaS; questi sta facendo del suo meglio, ricorrendo a varie tecniche di depistaggio, per mascherare le carenze intrinseche dello scenario di accesso alle applicazioni SaaS tramite compilazione di moduli.
In sintesi, il provisioning degli utenti alle applicazioni è relativamente semplice. Il de-provisioning è una questione completamente diversa.
Cosa possono fare le organizzazioni
Si tratta di un problema estremamente difficile da risolvere a posteriori. È necessario invece affrontarlo:
- Verificate le applicazioni SaaS a cui un utente ha accesso, memorizzate in un database centralizzato di diritti, in modo da sapere a cosa ognuno ha accesso. Si tratta di un problema di policy e di processi, più che di tecnologia.
- Utilizzare i Criteri di gruppo per disattivare il gestore di password di Chrome.
- Quando possibile, utilizza un'opzione che generi automaticamente la password dell'utente e la conservi in un archivio sicuro, in modo che l'utente non ne sia a conoscenza.
- Quando la vostra azienda sta valutando le applicazioni SaaS, il login federato deve essere un requisito, non una "cosa da avere". Assicuratevi che l'ISV lo sappia. Solo le richieste dei clienti (cioè le vendite) spingono gli ISV ad apportare modifiche.
I fornitori di IDaaS possono rappresentare un grande vantaggio per gli utenti, in quanto forniscono il SSO a molte applicazioni SaaS attraverso un unico portale utente e diversi fattori di forma. Sono anche un grande vantaggio per la sicurezza delle informazioni, perché forniscono un certo grado di gestione centralizzata di queste applicazioni. Tuttavia, è necessario adottare misure per renderla una soluzione sicura.
