SaaS è diventato il percorso tradizionale e abituale per molti di utilizzare le applicazioni aziendali. I dati di Productiv, fornitore di software per aiutare le aziende a gestire la spesa delle loro applicazioni, hanno mostrato che in media una azienda ha utilizzato 342 applicazioni SaaS nel 2023.
Oltre alla quantità, i modi in cui le organizzazioni utilizzano i prodotti SaaS complicano la protezione dei dati sensibili dalle violazioni. Le organizzazioni fanno scelte in base al loro particolare settore, in merito a requisiti, obiettivi, mandati normativi e così via. Tutto questo significa che non esiste una lista di controllo di sicurezza SaaS one-and-done, one-size-fits-all. Possono però essere indicate alcune best practice e strategie di sicurezza SaaS applicabili alla maggior parte delle situazioni.
1. Scoprire e fare l’inventario delle applicazioni
Una delle cose che rende il SaaS così avvincente è la facilità con cui può essere messo al lavoro. Questa facilità è sia una benedizione che una maledizione. I nuovi utenti possono facilmente iniziare a utilizzare uno strumento, creando situazioni in cui l’utilizzo di un’applicazione può passare da una manciata di utenti a un utilizzo significativo, praticamente da un giorno all’altro.
Queste dinamiche di adozione complicano la gestione SaaS. Un sondaggio tra i professionisti IT per il report “2023 State of SaaSOps” di BetterCloud ha rilevato che fino al 65% dell’utilizzo delle applicazioni SaaS non è sanzionato, una forte indicazione di come la shadow IT rimanga ben viva
Per scoprire quali applicazioni SaaS sono in uso, un’azienda potrebbe utilizzare metodi sia automatizzati che manuali. Inoltre, è consigliato avere strategie per raccogliere e convalidare i dati di utilizzo. Si può migliorare il proprio inventario SaaS implementando altre attività di raccolta di dati. È possibile scegliere l’analisi dell’impatto aziendale, vale a dire, raccogliere informazioni sull’utilizzo delle applicazioni e sulle priorità relative ai fini della continuità aziendale, o la raccolta di prove per la risposta all’audit come meccanismi per raccogliere informazioni sulle applicazioni SaaS nell’ambiente. Mentre si raccolgono informazioni, si aggiungono i dati a un inventario in esecuzione o a un runbook associato all’uso aziendale di questi strumenti SaaS.
2. Implementazione del Single Sign-On
Trovare e registrare informazioni sull’utilizzo è importante, ma c’è anche bisogno di strategie che si auto-applichino. Un esempio particolarmente illustrativo di questo è il single sign-on (SSO).
Dal punto di vista dell’utente, una delle maggiori seccature con SaaS può essere la proliferazione delle identità tra le varie applicazioni aziendali in uso. Un utente potrebbe avere dozzine di combinazioni nome utente-password: questo è oneroso e crea anche sfide di gestione e rischi per la sicurezza, come gli utenti che condividono le password tra i servizi o i dipendenti che annotano le loro password.
Alcuni provider SaaS offrono la possibilità di integrarsi con un provider di identità esterno, come Active Directory o Entra ID di Microsoft. Questi sono in genere supportati attraverso meccanismi di federazione, tra cui Security Assertion Markup Language (SAML) e OpenID Connect (OIDC).
Non c’è bisogno di ricordare un’altra combinazione nome utente-password è direttamente vantaggioso per gli utenti, tanto che spesso possono loro stessi fare pressione per questa funzionalità. Questa pressione per supportare l’SSO da parte della community di utenti sottolinea l’utilizzo SaaS di cui il team di sicurezza potrebbe altrimenti non essere a conoscenza.
Lega anche i vincoli di autenticazione – per esempio, MFA e parametri di complessità delle password – oltre ad estendere l’accesso all’accesso al regno SaaS.
3. Abilitare l’autenticazione a più fattori
Uno dei principali meccanismi per abilitare MFA (MultiFactor Authentication) è attraverso la federazione dell’identità dell’utente al provider di identità esistente e utilizzato internamente. Tuttavia, questo non è l’unico modo. Alcune applicazioni SaaS non supportano direttamente SSO – per esempio, tramite SAML o OIDC – ma consentono comunque un’opzione per MFA attraverso uno o più meccanismi supportati, come una password o un testo time-based. Nelle situazioni in cui è supportato l’MFA, anche fare uso di tale funzione e farla rispettare in tutta la base di utenti può essere prezioso.
4. Valutare ed eseguire la supervisione
Proprio come si esaminano e si convalidano i fornitori dal punto di vista della supply chain, è importante valutare i fornitori e le applicazioni SaaS. Per capire l’utilizzo dell’applicazione, come in chi la sta usando e per quale scopo commerciale, nonché il profilo di sicurezza del provider. Vanno anche identificate le caratteristiche di sicurezza disponibili. Per esempio, ci sono funzionalità opzionali per la protezione dei dati e la privacy? Serve poi anche comprendere le ipotesi fondamentali integrate nel prodotto e quali elementi di protezione dell’uso sono di responsabilità di chi.
5. Impiegare la crittografia dei dati
La maggior parte dei canali utilizzati per la comunicazione con le applicazioni SaaS utilizza TLS per proteggere i dati in transito. Molti fornitori SaaS offrono anche una funzionalità di crittografia per proteggere i dati a riposo. Per alcuni provider, questa è una funzione predefinita; per altri, deve essere esplicitamente abilitata dal cliente. Se viene data l’opzione, è una buona idea abilitare le funzionalità di crittografia dei dati. Se i provider non offrono la crittografia, si può dire loro che questa è una funzione che si vuole aggiungere.
6. Considerare CASB
A seconda dei requisiti di sicurezza, potresti scegliere di valutare strumenti e controlli che aiutano ad estendere i requisiti di sicurezza nel cloud. In un contesto SaaS, considera le opzioni del broker di sicurezza dell’accesso al cloud. Con uno strumento CASB, un’organizzazione può sovrapporre controlli aggiuntivi non forniti nativamente dal provider SaaS. Per esempio, un CASB potrebbe fornire informazioni migliori su chi sta accedendo allo strumento, un migliore monitoraggio dell’utilizzo e una migliore protezione dei dati. È necessario prestare attenzione alle modalità di distribuzione CASB: TLS 1.3 ha aumentato la complessità associata ad alcuni modelli basati su proxy, mentre le modalità basate su API, in molti casi, richiedono il supporto del fornitore SaaS stesso, il che significa che un fornitore potrebbe non supportare tutti i prodotti sul mercato
7. Considerare SSPM
Un’altra opzione è la gestione della postura di sicurezza SaaS. SSPM è simile per certi versi alla gestione della postura di sicurezza del cloud. Con CSPM, ci si può assicurare in modo più efficace di far rispettare un determinato modello di sicurezza in più installazioni cloud. SSPM aumenta gli sforzi per garantire che la policy di sicurezza e l’applicazione siano impostate universalmente su piattaforme SaaS. I fornitori di strumenti SSPM hanno svolto il lavoro di tradurre specifici obiettivi di policy tecnica nella configurazione nativa di diversi servizi SaaS; possono quindi interrogare tali servizi per garantire che la configurazione sia nello stato desiderato. E avvertire se non lo è.
8. Mantenere la consapevolezza situazionale
Come sempre, bisogna monitorare l’uso del SaaS, esaminare i dati degli strumenti interni, incluso un CASB se lo si sta usando, così come qualsiasi registro o altra informazione fornita dai fornitori di servizi, per vedere dove e come stai usando SaaS.
È importante che i leader dell’IT e della sicurezza comprendano che un’offerta SaaS è uno strumento potente che richiede lo stesso grado di sicurezza di qualsiasi altra applicazione aziendale. Adottando queste best practice di sicurezza SaaS in combinazione con misure sistematiche di gestione del rischio e valutazioni di sicurezza in corso, le organizzazioni possono garantire che SaaS sia impiegato in modo sicuro dagli utenti e che l’utilizzo rimanga protetto.
