Conformità SOC 2 per container e cloud

Chi si occupa di gestire o proteggere ambienti cloud o container, molto probabilmente non attende con ansia la preparazione di un report SOC 2. La conformità SOC 2, infatti, può essere noiosa.

Tuttavia, se si considera che il rispetto delle regole SOC 2 aiuta a evitare penali e multe che potrebbero essere comminate a causa di violazioni, il valore del tempo e degli sforzi impiegati diventa evidente. Avvisando per tempo di potenziali problemi di conformità, i report SOC 2 consentono di correggere tutto quello che non va prima che si trasformi in un enorme rischio.

In questo articolo, spieghiamo alcune nozioni importanti sulla conformità SOC 2 da tenere presenti se si lavora in ambiente basato su cloud e su container. Come vedremo, sebbene le regole SOC 2 non forniscano delle linee guida specifiche su come proteggere i dati all’interno di questi ambienti, esistono alcune migliori prassi che i team possono rispettare quando si preparano alla realizzazione dei report e allo svolgimento dei controlli SOC in questi contesti.

Cos’è il SOC 2?

Il SOC 2 è una serie di criteri a cui le aziende dovrebbero aderire quando gestiscono i dati dei clienti. Fa parte del quadro System and Organization Controls (SOC) sviluppato dall’American Institute of Certified Public Accountants (AICPA).

Sono previsti tre tipi di controlli SOC: SOC 1, che si occupa di rendicontazione finanziaria, SOC 2 e SOC 3, che si concentrano sulla disponibilità e la sicurezza dei sistemi. Tuttavia, tra di essi SOC 2 ha assunto un’importanza via via maggiore per il moderno cloud computing, perché ha implicazioni importanti per le architetture cloud-centriche quali SaaS, che per natura sono caratterizzate dall’archiviazione e dal trattamento di dati di clienti su infrastrutture o applicazioni di terze parti.

Quali sono i requisiti previsti dal SOC 2?

La conformità SOC 2 si orienta attorno a cinque cosiddetti criteri dei servizi: sicurezza, disponibilità, integrità dell’elaborazione, riservatezza e privacy.

Per risultare conformi a SOC 2, quindi, le aziende devono essere in grado di dimostrare la loro aderenza ai seguenti principi:

Sicurezza: Devono applicare tutte le protezioni ragionevoli in applicazioni, reti e infrastrutture.
Disponibilità: Usando tecniche e prassi quali il recovery di emergenza, devono mantenere la disponibilità dei sistemi.
Integrità dell’elaborazione: Devono monitorare l’elaborazione dei dati per garantirne la precisione e far fronte ai problemi di qualità.
Riservatezza: Devono mantenere protetti i dati sensibili (ovvero protetti dagli usi illeciti, dalle manipolazioni e dagli abusi) utilizzando metodi quali il controllo degli accessi e la crittografia.
Privacy: Devono mantenere i dati privati (ovvero, devono renderli accessibili solo per gli utenti autorizzati) utilizzando autenticazione, controllo degli accessi e crittografia.

Per maggiori dettagli sui criteri dei servizi, è possibile consultare la documentazione dell’AICPA sui criteri dei servizi. La documentazione specifica alcuni “controlli” che le aziende dovrebbero applicare per soddisfare i criteri dei servizi.

Come funzionano i report SOC 2?

Per dimostrare la conformità SOC 2, le aziende preparano un report volto a descrivere in che modo le loro architetture IT e i loro processi di gestione si conformano ai cinque criteri.

Contrariamente a molti altri quadri di conformità, tuttavia, SOC 2 è celebre per la sua mancanza di specificità nell’indicare quali informazioni devono essere inserite nei report. Lascia alle aziende il compito di interpretare il modo in cui i criteri devono essere applicati ai propri ambienti.

Chi deve ottenere la conformità SOC 2?

Dal momento che i criteri SOC 2 sono stati sviluppati da un’organizzazione indipendente e non da un’agenzia normativa, non vige alcun obbligo di legge relativo alla conformità. Non sono neppure previste penali.

Tuttavia, molte aziende preparano volontariamente i report SOC 2 come un mezzo per identificare i rischi che potrebbero portare a violazioni di altri quadri di conformità. Per esempio, un audit SOC 2 potrebbe rilevare un controllo degli accessi troppo debole per alcuni dati dei clienti in un’applicazione, oppure una mancanza di crittografia nel trasporto dei dati degli utenti nella rete. Problemi come questi potrebbero trasformarsi in violazioni di quadri normativi di conformità quali l’HIPAA o il GDPR, in base al tipo di dati coinvolti. Rilevando il problema attraverso il report SOC 2, è possibile affrontarlo prima che diventi una violazione normativa.

Allo stesso modo, le aziende potrebbero utilizzare i report SOC 2 per dimostrare la conformità con le migliori prassi di sicurezza a clienti o partner. I provider dei cloud pubblici utilizzano i report SOC 2 proprio per questa motivazione.

Controlli SOC 2 per container e cloud

In generale, solo due gruppi di controlli di sicurezza SOC 2 si riferiscono ai container e al cloud. I primi sono i controlli degli accessi logici e fisici, i secondi sono i controlli delle operazioni del sistema.

Presentiamo di seguito questi controlli in sintesi e spieghiamo cosa comportano per container e cloud.

Controlli degli accessi logici e fisici

Si tratta di sei controlli rilevanti per i container e gli ambienti cloud:

CC6.1: All’interno delle immagini dei container e in ambienti di runtime, devono essere previsti strumenti di protezione da eventi di sicurezza quali l’escalation dei privilegi. Strumenti come Kubernetes RBAC possono essere di grande aiuto.
CC6.2: I tentativi di accesso non autorizzati devono essere rilevati e bloccati. I registri di controllo di Kubernetes consentono di rilevare queste circostanze.
CC6.3: Evitare che i tentativi di accesso riescano a sconfiggere i meccanismi di controllo. Anche in questo caso, i registri di controllo di Kubernetes possono essere molto utili.
CC6.6: È necessario rilevare le connessioni di rete non autorizzate. Strumenti per il monitoraggio delle reti e le policy di rete Kubernetes sono quello che serve. Oltre alle service mesh, che sono in grado di limitare le interazioni tra i microservizi.
CC6.7: I dati segreti (come le password) devono essere gestiti in modo sicuro. Proteggere etcd di Kubernetes è importante per questa finalità. Allo stesso modo, bisogna evitare di scrivere le informazioni segrete come hard coded nelle immagini dei container o nelle distribuzioni.
CC6.8: Rilevare i software dannosi nelle immagini dei container e impedirne la distribuzione. La scansione delle immagini dei container è una risorsa fondamentale per questo compito.

Controlli delle operazioni di sistema

Nella famiglia dei controlli delle operazioni di sistema ricadono due controlli:

CC7.2: Rilevare le anomalie che potrebbero indicare eventi di sicurezza. A questo scopo, è conveniente raccogliere e analizzare i registri dei container, i registri di controllo di Kubernetes, i registri OS dei nodi e altre sorgenti di dati simili in tempo reale.
CC7.3: Valutare gli eventi di sicurezza per comprenderne l’impatto. La capacità di correlare diverse sorgenti di dati (ad esempio i registri dei container, i registri di controllo di Kubernetes, i registri dei server dei nodi) è fondamentale, poiché consente di interpretare le relazioni tra gli eventi di sicurezza e di individuare la causa dei rischi.

Conclusione

Anche se un’azienda non è legalmente tenuta a conformarsi ai controlli di sicurezza SOC 2, il tempo e gli sforzi limitati necessari per svolgerli vengono ampiamente ripagati, poiché consentono di gestire tempestivamente i problemi di conformità prima che si trasformino in sanzioni normative. SOC 2 è anche un valido strumento per dimostrare il proprio impegno per la sicurezza e la privacy dei dati ai propri clienti.

E, in termini di sicurezza dei container, le regole SOC 2 non sono particolarmente complesse né estensive. Ecco un’altra ragione per cui la conformità SOC 2 rappresenta una grande opportunità per le aziende che gestiscono infrastrutture cloud native.