Sicurezza dello storage cloud e rischi di esposizione dei dati

Il cloud object storage — AWS S3, Azure Blob Storage e Google Cloud Storage (GCS) — archivia i file come oggetti in namespace piatti chiamati bucket o container. A differenza dei file system tradizionali, le autorizzazioni sono controllate tramite policy associate a bucket e oggetti, anziché tramite ACL del file system. L'object storage è ideale per grandi quantità di dati, ma richiede una configurazione accurata delle autorizzazioni, perché un singolo bucket configurato erroneamente può esporre terabyte di dati sensibili a Internet.

La vulnerabilità più comune del cloud storage è un bucket accessibile pubblicamente — un bucket di storage la cui policy di accesso consente l'accesso anonimo in lettura (o in scrittura). Questa configurazione errata ha causato decine di violazioni gravi: Verizon (14 milioni di record dei clienti), FedEx (119.000 passaporti), Capital One (100 milioni di richieste di carte di credito). Gli aggressori utilizzano scanner automatizzati per individuare i bucket pubblici in base a tutti i pattern di denominazione degli account AWS noti, quindi l'individuazione diventa banale una volta presente la configurazione errata.

Il cloud storage utilizza due tipi di controlli degli accessi che possono entrare in conflitto. Le policy dei bucket sono documenti JSON associati al bucket che definiscono quali principal possono eseguire determinate azioni. Le Access Control List (ACL) sono concessioni di autorizzazioni legacy a livello di singolo oggetto. AWS consiglia di disabilitare le ACL a favore delle policy dei bucket, per garantire coerenza. Quando sono presenti entrambe, prevale la policy più permissiva — ciò significa che un'ACL eccessivamente permissiva può concedere l'accesso pubblico anche se la policy del bucket lo limita.

I provider di cloud storage offrono la crittografia lato server per gli oggetti archiviati. SSE-S3 (AWS) utilizza automaticamente chiavi gestite da AWS. SSE-KMS utilizza chiavi gestite dal cliente in AWS Key Management Service, offrendo tracce di audit più complete (ogni decrittografia viene registrata in CloudTrail) e il controllo della rotazione delle chiavi. SSE-C utilizza chiavi fornite dal cliente, che le gestisce interamente al di fuori di AWS. Per i dati sensibili, SSE-KMS con chiavi gestite dal cliente offre il massimo livello di controllo e di evidenze di conformità.

Anche i dati correttamente crittografati a riposo possono essere esposti se vengono trasmessi tramite canali non crittografati. Tutte le API di cloud storage devono essere accessibili esclusivamente tramite HTTPS/TLS. Per S3, le policy dei bucket possono imporre HTTPS negando le richieste con aws:SecureTransport: false. Gli URL prefirmati — URL autenticati temporanei che concedono l'accesso agli oggetti per un periodo limitato — devono sempre utilizzare HTTPS e avere tempi di scadenza brevi, per ridurre al minimo la finestra di esposizione in caso di intercettazione.

Non tutti i dati richiedono lo stesso livello di protezione. I dati sensibili (PII, PHI, documenti finanziari) devono essere archiviati in bucket crittografati e con accesso limitato, con il logging di audit abilitato. I dati meno sensibili possono avere un accesso più ampio. Le etichette di classificazione dei dati devono essere applicate alla creazione dell'oggetto e utilizzate per instradare automaticamente i dati verso uno storage configurato in modo appropriato. Le policy che spostano automaticamente i dati verso uno storage più sicuro in base ai tag di classificazione riducono il rischio che dati sensibili finiscano in bucket con scarsa sicurezza.

Il logging degli accessi è fondamentale per rilevare accessi non autorizzati a posteriori e per gli audit di conformità. I log degli accessi ad AWS S3 e il logging degli eventi dati di CloudTrail registrano ogni chiamata API a livello di oggetto — chi ha richiesto un oggetto, da quale IP e a che ora. Il logging diagnostico di Azure Blob e gli audit log di GCS offrono funzionalità analoghe. Senza questi log, quando viene scoperta una violazione dei dati non esistono prove forensi, rendendo impossibile determinare l'entità dell'esposizione.

Il cloud storage viene spesso condiviso tra account (sviluppo, staging, produzione, partner di terze parti). Un accesso tra account configurato senza la dovuta attenzione può concedere autorizzazioni eccessive. Le buone pratiche includono: utilizzare ID account espliciti nelle policy dei bucket anziché principal jolly, utilizzare gli AWS Organizations SCP per limitare gli account esterni ai quali può essere concesso l'accesso, verificare regolarmente le concessioni tra account e preferire AWS PrivateLink all'accesso tramite Internet pubblico per i trasferimenti di dati tra account.

Il versioning degli oggetti conserva tutte le versioni di un oggetto, comprese quelle eliminate. Questo protegge da eliminazioni accidentali, dalla crittografia degli oggetti da parte di ransomware e dalle minacce interne. Per i dati critici, combini il versioning con Object Lock (l'equivalente di S3 Glacier Vault Lock) — una policy WORM (Write Once, Read Many) che impedisce qualsiasi eliminazione o modifica durante un periodo di conservazione definito. Object Lock può soddisfare i requisiti normativi relativi ai record immutabili nei settori finanziario e sanitario.

Gli strumenti di Cloud Security Posture Management (CSPM) analizzano automaticamente le configurazioni del cloud storage confrontandole con i benchmark di sicurezza. I controlli CSPM includono: esistono bucket accessibili pubblicamente? La crittografia a riposo è abilitata? Il logging è abilitato? Il versioning è abilitato sui bucket critici? Le policy dei bucket sono eccessivamente permissive? Strumenti CSPM come Prisma Cloud, Wiz e AWS Security Hub offrono un monitoraggio continuo della conformità e segnalano le variazioni della configurazione prima che siano gli aggressori a individuarle.

Gli URL prefirmati concedono un accesso a tempo agli oggetti specifici senza richiedere al destinatario credenziali AWS. Sono utili per condividere file con soggetti esterni. I rischi per la sicurezza includono: URL con tempi di scadenza eccessivamente lunghi, che restano validi oltre il periodo di condivisione previsto; URL inoltrati dai destinatari al di fuori del pubblico previsto; e token incorporati negli URL che compaiono nei log dei server. Imposti sempre il tempo di scadenza più breve possibile ed eviti di registrare nei log gli URL prefirmati.

Verifichi la Sua comprensione dei concetti di CompTIA Security+ (SY0-701) trattati in questa lezione.

In questa lezione ha imparato che: le configurazioni errate dei bucket pubblici sono la causa più comune delle violazioni dei dati nel cloud storage, SSE-KMS offre il massimo controllo sulla crittografia, con logging di audit tramite CloudTrail e il versioning degli oggetti combinato con Object Lock protegge dal ransomware e dall'eliminazione da parte di utenti interni dei dati critici. Ora esamineremo l'identità nel cloud con i ruoli IAM e gli account di servizio.