Dribbble
La maggior parte delle violazioni dei dati inizia con un errore banale commesso da un dipendente stanco. Un ingegnere junior cerca di correggere un collegamento a un'immagine non funzionante su un server di staging. Frustrato dagli errori relativi alle autorizzazioni, modifica un'impostazione nella console AWS rendendo pubblico un intero bucket S3, poi torna a casa per il fine settimana. Tre giorni dopo, un ricercatore di sicurezza scrive all'amministratore delegato: due milioni di profili di clienti non crittografati sono liberamente accessibili su Internet.
Quando trasferisci la tua azienda nel cloud, l'hardware fisico è praticamente impenetrabile. Amazon e Microsoft proteggono perfettamente gli edifici e i rack dei server. La configurazione del software, invece, è interamente una tua responsabilità. Se hai bisogno di mettere in sicurezza un ambiente di distribuzione complesso, affidarti a un partner specializzato nell'integrazione cloud può aiutarti a prevenire errori critici prima che raggiungano la produzione.
Vediamo in che modo gli ambienti cloud possono esporre i dati aziendali. Analizzeremo gli errori di configurazione più pericolosi e le piattaforme software che permettono di prevenirli.
La trappola della responsabilità condivisa
I fondatori delle aziende spesso fraintendono le responsabilità legate al cloud. Acquistano servizi di hosting AWS e presumono che questo basti a proteggere automaticamente i loro database. È un'illusione che può avere conseguenze legali molto serie.
Sei tu a gestire le policy di identità, le porte di rete e le chiavi di crittografia dei dati. Se il tuo responsabile dello sviluppo lascia la porta 22 aperta a tutto Internet per accedere via SSH a un server mentre lavora da un bar, espone l'infrastruttura a un rischio concreto di violazione. Le botnet automatizzate scandagliano continuamente gli indirizzi IPv4 alla ricerca di porte aperte. Troveranno il server esposto nel giro di poche ore.
I provider cloud ti mettono a disposizione gli strumenti per costruire una forte difesa, ma sta a te configurarli correttamente. Se imposti un gruppo di sicurezza in modo che accetti traffico da 0.0.0.0/0, stai consentendo potenzialmente a chiunque su Internet di raggiungere il tuo database. Gli aggressori utilizzano script automatici per individuare proprio queste configurazioni.
Il disastro dei bucket di archiviazione pubblici
I bucket di archiviazione configurati in modo errato possono provocare gravissime esposizioni dei dati aziendali.
Per impostazione predefinita, i bucket AWS S3 e i contenitori di Azure Blob Storage sono privati. A volte gli sviluppatori li rendono pubblici manualmente perché incontrano difficoltà nel configurare correttamente le policy di accesso. Magari vogliono soltanto permettere a un'applicazione web di caricare un semplice logo. Selezionano l'opzione «Rendi pubblico», pensando di ripristinare la protezione in seguito. Spesso, però, non lo fanno.
Le revisioni manuali del codice non riescono a intercettare ogni modifica alle impostazioni di archiviazione. È necessario utilizzare strumenti per rilevare le configurazioni errate della sicurezza cloud.
Servono controlli automatizzati che analizzino i file di Infrastructure as Code. Se uno script Terraform tenta di distribuire un contenitore di archiviazione accessibile pubblicamente, la pipeline di distribuzione deve bloccarlo immediatamente. È inoltre importante applicare impostazioni come AWS Block Public Access a livello di account. Questa misura di protezione impedisce di rendere pubblico un bucket anche agli utenti con privilegi amministrativi.
Gestione incontrollata delle identità e degli accessi
L'identità è il nuovo perimetro di sicurezza. I firewall offrono una protezione limitata se gli sviluppatori dispongono di accesso amministrativo a tutte le risorse dell'account cloud.
I team di ingegneria assegnano spesso autorizzazioni troppo ampie per risparmiare tempo. Un data scientist deve leggere una sola tabella DynamoDB, ma il responsabile IT, per evitare di scrivere una policy IAM restrittiva, associa semplicemente AdministratorAccess al suo profilo. Due anni dopo, il data scientist apre un link di phishing ricevuto via email. Un aggressore ruba le chiavi di accesso AWS e può persino eliminare i backup di produzione, perché quelle credenziali glielo consentono.
L'escalation dei privilegi è un altro importante punto cieco. Considera l'autorizzazione AWS iam:PassRole. Se un account sviluppatore dispone di questo permesso, può associare un ruolo amministrativo a una normale istanza EC2, accedere alla macchina virtuale e arrivare a compromettere l'intero account AWS.
Queste strutture di identità diventano ancora più complesse durante le grandi migrazioni infrastrutturali. La nostra guida tecnica alla migrazione da AWS ad Azure spiega perché la corrispondenza tra i ruoli IAM di AWS e il controllo degli accessi basato sui ruoli di Azure (RBAC) richieda estrema precisione. Una mappatura errata può causare l'esposizione involontaria delle subnet aziendali interne.
Come valutare i software di rilevamento delle configurazioni errate nel cloud
Non è possibile monitorare manualmente tutte le modifiche alla configurazione del cloud.
Se la tua azienda gestisce 500 macchine virtuali, 80 database e 300 funzioni serverless, il controllo umano continuo diventa impraticabile. Hai bisogno di software che verifichino costantemente lo stato dell'ambiente.
Un comune software di rilevamento delle configurazioni errate del cloud analizza l'ambiente di produzione una volta al giorno. Se rileva un bucket pubblico, invia un avviso su Slack. Per le minacce moderne, tuttavia, questo approccio può essere troppo lento.
Se un ingegnere distribuisce una regola non sicura per un database alle 9:00 e lo scanner viene eseguito solo a mezzanotte, gli aggressori hanno a disposizione quindici ore per sottrarre i dati. I controlli di sicurezza devono essere anticipati nelle fasi di sviluppo, secondo l'approccio «shift left». Il software dovrebbe analizzare i file CloudFormation o Terraform già sulla macchina dello sviluppatore, prima ancora dell'approvazione della pull request.
Confronto tra i migliori strumenti di gestione delle configurazioni errate della sicurezza cloud
Non acquistare la prima piattaforma di sicurezza aziendale che trovi con una ricerca su Google.
Quando effettui un confronto tra gli strumenti per le configurazioni errate del cloud, valuta soprattutto la quantità di avvisi non pertinenti. Uno strumento che genera ogni giorno 4.000 email di avviso a bassa priorità finisce per diventare inutile. Gli ingegneri creeranno semplicemente un filtro per eliminarle automaticamente.
Una buona piattaforma deve dare priorità ai rischi operativi critici. L'assenza di un tag di fatturazione su un'istanza EC2 può essere segnalata come problema a bassa priorità. Un database accessibile pubblicamente che contiene password non crittografate, invece, deve attivare immediatamente un allarme, anche alle tre del mattino.
Verifica anche il supporto per più provider cloud. Una valida piattaforma di gestione delle configurazioni errate del cloud deve consentire di monitorare AWS, Azure e Google Cloud da un'unica dashboard centralizzata. Gli analisti della sicurezza non dovrebbero accedere a tre portali diversi solo per controllare le regole dei firewall.
Gestione della postura di sicurezza e audit di conformità
Nel settore della sicurezza, questa categoria di software è nota come CSPM, ovvero Cloud Security Posture Management.
Gli strumenti CSPM per rilevare le configurazioni errate della sicurezza cloud offrono al team di sicurezza una dashboard unificata. Mostrano quali server non utilizzano la crittografia, quali database accettano connessioni pubbliche e quali account dei dipendenti non hanno l'autenticazione a più fattori.
Queste piattaforme confrontano l'ambiente cloud con framework di conformità come HIPAA, SOC 2 e PCI DSS. Se un revisore chiede una prova della crittografia dei dati a riposo, il CSPM genera un report di conformità in tre secondi. Se una nuova distribuzione viola un requisito SOC 2, il CSPM blocca immediatamente il rilascio.
Credenziali incorporate nel codice e perdita dei file di stato
Gli sviluppatori a volte prendono scorciatoie molto rischiose. Mi è capitato di vedere ingegneri estremamente competenti incollare le password dei database direttamente nei file di configurazione e inviarli su GitHub, convinti che un repository privato fosse del tutto sicuro.
Poi un fornitore esterno ottiene accesso al repository. Oppure un dipendente scontento scarica il codice sorgente prima di lasciare l'azienda. Improvvisamente, le password dei database di produzione risultano compromesse.
La scansione automatizzata dei segreti deve essere eseguita a ogni commit. Se lo scanner rileva una stringa che somiglia a una chiave segreta AWS, deve bloccare l'invio del codice. Gli sviluppatori dovrebbero utilizzare strumenti dedicati come Azure Key Vault o AWS Secrets Manager.
Anche i file di stato di Terraform rappresentano una vulnerabilità importante. Terraform conserva le informazioni sull'infrastruttura cloud in un file JSON che può contenere password e chiavi API in chiaro. Se archivi il file di stato in un bucket S3 non protetto, chiunque abbia accesso in lettura può ottenere informazioni sensibili sull'intera infrastruttura. È fondamentale crittografare il bucket e limitarne l'accesso con policy IAM rigorose.
I rischi del servizio di metadati nel cloud
Ogni istanza EC2 di AWS dispone di un servizio di metadati accessibile tramite un indirizzo IP specifico all'interno della macchina virtuale.
Se la tua applicazione presenta una vulnerabilità chiamata Server-Side Request Forgery (SSRF), un aggressore può indurre il server web a interrogare il servizio di metadati. In determinate condizioni, il server può così esporre le credenziali IAM temporanee associate all'istanza. L'aggressore può usarle per tentare di accedere ad altre risorse dell'account AWS. Una vulnerabilità di questo tipo è stata coinvolta in una delle più gravi violazioni di dati bancari nella storia degli Stati Uniti.
Per bloccare questo attacco, bisogna imporre IMDSv2, che richiede un token di sessione specifico che gli attacchi SSRF non possono generare. Molte aziende non abilitano questa versione perché non ne comprendono i vantaggi. Il codice infrastrutturale dovrebbe impedire la distribuzione di istanze EC2 che consentono ancora IMDSv1.
Modernizzare in sicurezza il software legacy
Il software datato porta con sé numerosi rischi di sicurezza quando viene trasferito nel cloud.
Durante la migrazione delle applicazioni Windows legacy a .NET, è necessario ripensare l'intero modello di sicurezza. Una vecchia applicazione desktop Windows può presumere che la rete aziendale interna sia completamente affidabile e comunicare con il database tramite una connessione non crittografata.
Quando sposti questa logica applicativa in un moderno ambiente cloud Azure, non puoi più considerare affidabile la rete per impostazione predefinita. Devi imporre la crittografia TLS 1.3 sulle connessioni interne pertinenti, definire confini di rete virtuale rigorosi per evitare esposizioni involontarie a Internet e separare i server applicativi da quelli dei database utilizzando Network Security Group (NSG) restrittivi.
In Azure, le regole NSG seguono un sistema di priorità: una regola con priorità 100 viene valutata prima di una con priorità 200. Se uno sviluppatore junior crea una regola di priorità 100 che consente tutto il traffico in ingresso, le regole più restrittive con priorità inferiore potrebbero non avere effetto su quel traffico. Gli scanner automatizzati possono rilevare rapidamente questi conflitti.
Le app mobili come vettori di attacco
Un'applicazione mobile può diventare un punto di accesso alle risorse e ai dati custoditi nel cloud.
Vediamo aziende discutere per settimane di Flutter rispetto a React Native, concentrandosi sulle animazioni dell'interfaccia frontend e trascurando completamente la sicurezza delle API backend.
Se la tua app mobile comunica con un AWS API Gateway privo di un adeguato limite alle richieste e della convalida dei token JWT, un aggressore può aggirare del tutto l'applicazione. Gli basta scrivere uno script Python che invii richieste direttamente all'API cloud. Se il backend è configurato male, potrebbe scaricare l'intero database degli utenti in quattro minuti. È importante proteggere l'API con un Web Application Firewall (WAF), in modo da bloccare le richieste dannose prima che raggiungano le funzioni Lambda.
Assumere professionisti con le giuste competenze architetturali
Il software aziendale, da solo, non basta a eliminare le vulnerabilità del cloud.
Le piattaforme di sicurezza sono estremamente complesse. Se acquisti un grande strumento CSPM e lo affidi a un tecnico IT inesperto, potresti ritrovarti con regole di sicurezza importanti disattivate soltanto per ridurre il numero di avvisi.
Serve una persona che conosca a fondo l'Infrastructure as Code. Quando decidi di assumere un ingegnere AWS DevOps, investi nella disciplina architetturale necessaria a proteggere un ambiente di produzione. Un ingegnere DevOps senior definisce misure di protezione rigorose e scrive codice che impedisce agli altri sviluppatori di introdurre configurazioni pericolose.
Questi professionisti implementano modelli di accesso basati sul principio del privilegio minimo, impongono tag obbligatori per identificare i responsabili di ogni risorsa cloud e realizzano pipeline di integrazione continua che eseguono automaticamente controlli di sicurezza.
Costruire una cultura della sicurezza infrastrutturale
La sicurezza comporta un costo operativo significativo. Rallenta il rilascio delle funzionalità e può frustrare i product manager che desiderano distribuire rapidamente il codice.
È però un investimento necessario.
L'alternativa potrebbe essere dover spiegare al consiglio di amministrazione come un singolo bucket di archiviazione configurato male abbia danneggiato in una sola notte la reputazione dell'azienda. È indispensabile creare una cultura in cui le revisioni di sicurezza siano obbligatorie e gli ingegneri debbano giustificare ogni porta aperta e ogni ruolo IAM amministrativo.
Collaborare con una società esperta nello sviluppo software riduce le incertezze legate all'architettura cloud. Un partner specializzato mette a disposizione modelli di sicurezza preconfigurati, conosce le impostazioni predefinite più rischiose di AWS e Azure e progetta l'infrastruttura in modo difensivo fin dall'inizio. Non aspettare una violazione per scoprire che i file di configurazione sono fuori controllo. Metti in sicurezza il tuo cloud oggi stesso.