Sean Deuby

E nel caso delle password, ognuna di esse, soprattutto quelle dimenticate, rappresenta un piccolo rischio per la sicurezza che si aggira nell'ombra. Si può pensare di essersene liberati (o almeno di averli ridotti a una quantità gestibile), ma continuano a spuntare. E come tutti sappiamo, le applicazioni SaaS, che si tratti di applicazioni personali o sociali come Facebook o delle migliaia di applicazioni aziendali in uso oggi, hanno fatto sì che questo problema si sia, beh... moltiplicato 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 la propria userid e password per l'app. (Sicuramente le conosceva anche prima di dover accedere all'applicazione attraverso il portale utenti dell'azienda). Ciò significa che può sempre aggirare il portale e accedere direttamente. Se si tratta di una nuova app che sta per entrare in servizio, alcuni fornitori di IDaaS supportano l'amministratore che carica le credenziali dell'utente in modo che quest'ultimo non le conosca e debba quindi utilizzare il portale, ma questo funziona solo per l'onboarding di nuove app. Alcuni fornitori di IDaaS hanno una capacità limitata di cambiare la password per alcune app e alcuni possono offuscare l'URL di accesso dell'app, ma si tratta di una piccola minoranza. A peggiorare la situazione, browser come Chrome o add-in del browser come LastPass offrono facilmente la possibilità di salvare la password dell'utente al momento del login. E perché l'utente medio non dovrebbe voler memorizzare la password per non doverla inserire di nuovo?

Infine, cosa più importante, le applicazioni SaaS non sono legate al sistema di gestione del ciclo di vita dell'identità aziendale. Che cosa significa? Significa che se si licenzia un dipendente e si disabilita il suo account nell'AD DS on-premises, l'utente non può più accedere alla rete aziendale o alle sue risorse. Quando la disabilitazione si replica al servizio IDaaS, l'utente non può accedere alle risorse cloud che richiedono il servizio IDaaS, come le applicazioni federate (Salesforce, Office 365). Questo è un bene e rende felici gli addetti alla sicurezza.

Ma le applicazioni SaaS non dipendono dalle credenziali aziendali come le applicazioni SaaS federate. Quando l'account utente AD DS viene disattivato o eliminato, non succede nulla all'applicazione SaaS. Non ha idea di cosa sia successo in azienda. A meno che qualcuno non si occupi esplicitamente di controllare le app a cui l'utente ha accesso e le disabiliti manualmente in ogni app, l'utente può entrare. Perché? Tutto ciò di cui l'utente ha bisogno è il suo userid, la sua password e l'URL di accesso dell'app.

Devo precisare che questi problemi non sono colpa del fornitore di IDaaS, che sta facendo del suo meglio, utilizzando varie tecniche di fumo e specchi, per ovviare alle carenze intrinseche dello scenario di accesso alle app SaaS con riempimento di modulo.

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.
  • Se possibile, utilizzare un'opzione per generare automaticamente e salvare la password dell'utente in modo che non la conosca.
  • 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.