I problemi di sicurezza AWS continuano a fare notizia, e il pattern è notevolmente coerente: la piattaforma cloud stessa è raramente la causa radice. Secondo il Cloud Security Index 2026 di Intruder, la configurazione errata colpisce dall’80% al 98% degli account cloud tra i provider, e AWS è leader in cinque delle sei categorie di configurazione errata. I problemi di sicurezza AWS più comuni — bucket S3 pubblici, IAM eccessivamente permissivo, MFA mancante, servizi esposti — sono problemi di configurazione lato cliente, non difetti della piattaforma AWS.
Questa guida copre i principali problemi di sicurezza AWS e come prevenirli — mappando i problemi che appaiono più frequentemente nei rapporti sulle violazioni 2025-2026 e negli audit CIS AWS Foundations Benchmark, spiegando perché ciascuno persiste e mostrando come prevenirne ciascuno prima che diventi una violazione. Inizia dal modello di responsabilità condivisa AWS, perché quel confine è dove la maggior parte dei rischi di sicurezza AWS inizia davvero.
Comprendere il modello di responsabilità condivisa AWS
Quando si discutono i problemi di sicurezza AWS, il concetto fondamentale è il modello di responsabilità condivisa AWS. Questo modello definisce chi protegge cosa nell’ecosistema AWS, e un numero sorprendente di problemi di sicurezza AWS non nasce da vulnerabilità della piattaforma ma da una comprensione errata o un’applicazione errata di questo confine.
Che cos’è il modello di responsabilità condivisa AWS
Il modello di responsabilità condivisa AWS delinea chiaramente quali aspetti dell’ambiente AWS protegge e quali cadono sotto il controllo del cliente:
- AWS è responsabile della sicurezza DEL cloud — l’infrastruttura cloud globale, i data center fisici, l’hardware di rete, gli hypervisor e i livelli di servizio fondamentali.
- Voi, il cliente, siete responsabili della sicurezza NEL cloud — le vostre applicazioni, dati, policy IAM, configurazioni, controlli di accesso, cifratura e patching di tutto ciò che distribuite o gestite.
Sebbene il modello sembri semplice, molti problemi di sicurezza AWS derivano da presupposti errati su dove finiscono le responsabilità di AWS e dove iniziano quelle del cliente.
Responsabilità di AWS: sicurezza DEL cloud
AWS protegge l’infrastruttura centrale che supporta tutti i suoi servizi:
- Sicurezza fisica dei data center
- Sistemi di alimentazione, rete e HVAC ridondanti
- Segmentazione di rete e mitigazione DDoS
- Hypervisor e livelli di servizio fondamentali
AWS monitora, testa e auditare continuamente questa infrastruttura per mantenere certificazioni di conformità tra cui ISO 27001, SOC 1/2/3 e PCI DSS. Tuttavia, anche con questa solida base, le lacune di sicurezza si verificano ancora se il livello del cliente non è adeguatamente protetto.
Responsabilità del cliente: sicurezza NEL cloud
I clienti sono responsabili della protezione delle loro applicazioni cloud, dati e configurazioni:
- Configurazione appropriata di servizi come S3, EC2 e RDS
- Policy e ruoli Identity and Access Management (IAM)
- Sicurezza a livello di applicazione, come la validazione dell’input e la codifica sicura (vedi le nostre migliori pratiche di sicurezza Node.js e il nostro approfondimento sulla sicurezza Node.js in produzione per i controlli a livello di applicazione che completano il vostro hardening AWS)
- Patching e manutenzione di sistemi operativi e stack software
- Protezione dei dati sensibili tramite cifratura a riposo e in transito
Se potete crearlo, gestirlo o configurarlo in AWS, probabilmente siete responsabili della sua protezione. Qui è dove si verifica la stragrande maggioranza dei problemi di sicurezza AWS. Un bucket S3 mal configurato che consente l’accesso pubblico in lettura o scrittura non è colpa di AWS — è una configurazione errata lato cliente.
L’equivoco che porta al rischio
Un numero significativo di problemi di sicurezza AWS non è causato da attacchi sofisticati o exploit zero-day. Sono causati da errori umani e da una comprensione errata del modello di responsabilità. Molte organizzazioni operano ancora sotto la falsa convinzione che AWS “si occupi di tutto”, il che non è vero.
Esempi comuni includono:
- Fughe di bucket S3 — accesso pubblico abilitato senza controlli, esponendo dati sensibili.
- Abuso di ruoli IAM — policy eccessivamente permissive come
"Action": "*","Resource": "*"aprono la porta all’escalation di privilegi. - Istanze EC2 non patchate — sistemi operativi obsoleti con CVE noti che gli attaccanti sfruttano entro pochi minuti dalla scoperta.
Presumere che AWS gestirà la sicurezza a tutti i livelli è una mentalità pericolosa e un percorso diretto verso fallimenti di sicurezza prevenibili.
Un’analogia del mondo reale
Pensate ad AWS come a un edificio di appartamenti sicuro. AWS assicura che le serrature della porta d’ingresso funzionino, che gli allarmi antincendio funzionino e che l’edificio abbia sicurezza 24/7. Una volta affittato un appartamento (un account cloud o una risorsa), è vostro compito chiudere le finestre, abbassare le tapparelle e installare una cassaforte se necessario. Ignorare queste responsabilità porta a violazioni, proprio come lasciare la porta d’ingresso aperta invita al furto.
Perché l’istruzione è critica
Gli ambienti cloud si muovono velocemente e i cicli di deployment sono brevi. Senza una formazione adeguata sulle responsabilità AWS, anche ingegneri ben intenzionati possono introdurre seri rischi di sicurezza AWS lasciando servizi esposti o mal configurati. AWS introduce regolarmente nuovi servizi e funzionalità, e il mancato adattamento porta spesso a pratiche obsolete — un’altra fonte di sfide di sicurezza cloud.
Principali problemi di sicurezza AWS nel 2025-2026
Nonostante AWS sia una delle piattaforme cloud più sicure disponibili, i rischi di sicurezza AWS si verificano ancora frequentemente — non a causa di difetti della piattaforma, ma a causa di come gli utenti configurano e gestiscono i loro ambienti cloud. Di seguito sono i problemi più urgenti e comunemente incontrati, con implicazioni del mondo reale e strategie preventive.
1. Bucket S3 mal configurati
Il rischio di sicurezza AWS più infame è la configurazione errata dei bucket Amazon S3. Queste risorse di archiviazione sono potenti ma pericolose se non adeguatamente protette.
In molte violazioni, i bucket S3 sono stati impostati involontariamente per consentire l’accesso pubblico, il che significa che chiunque abbia l’URL può leggere, e a volte scrivere, dati. Verizon e Accenture hanno entrambi subito fughe di dati di alto profilo a causa di questo problema.
Aggiornamento importante: Dal 5 aprile 2023, AWS abilita S3 Block Public Access e disabilita le ACL per impostazione predefinita per i nuovi bucket. Tuttavia, questa impostazione predefinita non è retroattiva. I bucket creati prima di quella data mantengono le impostazioni di accesso pubblico originali a meno che non si abiliti esplicitamente Block Public Access. I bucket pre-2023 rimangono una fonte comune di fughe di dati S3.
Leggete il caso Verizon e il caso Accenture.
Perché succede
- Permessi predefiniti o ereditati sui bucket pre-2023
- Mancanza di visibilità sulle impostazioni di accesso pubblico
- Ignorare gli avvisi di policy di accesso AWS
Come prevenirlo
- Abilitare S3 Block Public Access a livello di account — questo copre tutti i bucket, inclusi i pre-2023
- Usare AWS Config per monitorare i bucket aperti
- Applicare policy di bucket che seguano il principio del privilegio minimo
- Abilitare la cifratura predefinita per i bucket S3
2. Policy IAM eccessivamente permissive
Un altro vettore comune per i problemi di sicurezza AWS è l’uso di policy IAM ampie o permissive. Molti team assegnano policy con "Effect": "Allow", "Action": "*", "Resource": "*" — che concede effettivamente accesso illimitato.
Questa configurazione crea una bomba a orologeria di sicurezza, consentendo ad attori interni o esterni di elevare i loro privilegi o accedere a risorse non previste. Secondo il Cloud Security Index 2026, IAM Policy Allows Privilege Escalation colpisce l’83% degli account AWS, e IAM Access Key Not Rotated colpisce il 71%.
I risultati includono
- Acquisizione completa dell’account
- Accesso non autorizzato ai dati
- Movimento laterale tra i servizi
Migliori pratiche
- Implementare accesso a privilegio minimo — iniziare senza permessi e aggiungere solo ciò che è necessario
- Auditare regolarmente ruoli e policy IAM con IAM Access Analyzer
- Usare AWS Identity Center (precedentemente SSO) per l’accesso umano centralizzato
- Evitare di allegare policy direttamente agli utenti; usare ruoli invece
3. MFA mancante su utenti root e IAM
L’autenticazione multi-fattore (MFA) è uno dei controlli più semplici ed efficaci in AWS, ma rimane sotto-applicata. Il Cloud Security Index 2026 ha rilevato che Root Access Not Centrally Managed colpisce il 72% degli account AWS.
L’account root AWS ha accesso completo e illimitato a ogni risorsa nell’account. Se un attaccante compromette le credenziali root senza MFA, l’account è effettivamente perso. Lo stesso vale per gli utenti IAM con privilegi amministrativi.
Come prevenirlo
- Abilitare MFA sull’account root immediatamente e archiviare i codici di recupero in modo sicuro
- Applicare MFA per tutti gli utenti IAM, specialmente quelli con accesso admin o in scrittura
- Usare AWS Identity Center per applicare MFA centralmente in tutta l’organizzazione
- Disabilitare o rimuovere le chiavi di accesso IAM per l’utente root — root dovrebbe usare solo console + MFA
4. Mancanza di cifratura
Trascurare la cifratura è un grave problema di sicurezza AWS. Non cifrare i dati a riposo o in transito apre la porta all’intercettazione, alla manipolazione e all’esposizione. AWS fornisce servizi come KMS (Key Management Service) e TLS per i dati in transito, ma la cifratura non è sempre applicata per impostazione predefinita.
Dove la cifratura viene spesso saltata
- Volumi EBS
- Snapshot RDS
- Variabili di ambiente Lambda
- Oggetti S3 nei bucket pre-2023
Consigli di mitigazione
- Abilitare la cifratura predefinita per S3, EBS e RDS a livello di account o servizio
- Usare chiavi gestite dal cliente (CMK) per un controllo più rigoroso sulla rotazione e l’accesso alle chiavi
- Ruotare regolarmente le chiavi di cifratura tramite KMS
- Applicare TLS in transito per tutte le chiamate API e le connessioni al database
5. API insicure e endpoint esposti
Man mano che le organizzazioni adottano architetture microservizi e serverless, la superficie di attacco per i rischi di sicurezza AWS aumenta. API Gateway e gli endpoint Lambda sono i modi principali in cui questa superficie cresce.
Le API non protette o scarsamente autenticate possono essere scoperte e sfruttate da attaccanti che utilizzano strumenti di scansione automatizzati. Una volta trovate, possono essere usate per l’estrazione di dati, attacchi brute-force o interruzione dei servizi. Il Cloud Security Index 2026 ha rilevato che il 76% degli account AWS ha almeno un servizio pubblicamente esposto.
Fattori contribuenti
- Nessuna autenticazione o uso debole di chiavi API
- Mancanza di limitazione della velocità o throttling
- Policy CORS eccessivamente esposte
Proteggete le vostre API mediante
- Abilitare Amazon Cognito o autenticazione basata su IAM
- Implementare regole WAF (Web Application Firewall)
- Monitorare con AWS CloudWatch e GuardDuty
- Applicare limitazione della velocità e throttling delle richieste a livello di API Gateway
6. Istanze EC2 e AMI non patchate
Anche con AWS che gestisce l’infrastruttura fisica, le istanze EC2 rimangono responsabilità del cliente. Rappresentano una delle fonti più comuni di rischi di sicurezza AWS a causa di una cattiva gestione delle patch.
Quando le istanze eseguono sistemi operativi obsoleti o software vulnerabile, gli attaccanti possono sfruttare i CVE (Common Vulnerabilities and Exposures) noti. Queste vulnerabilità sono spesso bersagliate entro pochi minuti dalla scoperta.
Cause tipiche
- Usare vecchie AMI senza aggiornamenti
- Mancanza di automazione per il patching
- Ignorare i bollettini di sicurezza del fornitore
Correggere mediante
- Usare AWS Systems Manager Patch Manager per automatizzare il patching
- Aggiornare e ruotare regolarmente le AMI
- Applicare aggiornamenti di sicurezza automatici dove possibile
- Iscriversi agli AWS Security Bulletins
7. Trascurare il principio del privilegio minimo
Troppo spesso, le organizzazioni concedono a utenti e servizi più accesso del necessario. Che sia accidentale o malevolo, questo aumenta la probabilità di abuso. È un contributo silenzioso ma critico ai rischi di sicurezza AWS.
Le conseguenze includono
- Escalation di privilegi da parte di attori delle minacce
- Fuga di dati da ruoli con ambito eccessivo
- Aumento del blast radius in caso di compromissione
Per risolvere questo
- Rivedere regolarmente i permessi IAM con IAM Access Analyzer
- Usare limiti di permesso e controllo degli accessi basato su attributi (ABAC)
- Integrare l’applicazione del privilegio minimo nei vostri pipeline CI/CD
- Adottare una postura deny-by-default e aggiungere permessi solo quando giustificato
8. Security group e ACL di rete mal configurati
Uno dei rischi di sicurezza AWS più sottili ma pericolosi coinvolge security group e liste di controllo degli accessi di rete (ACL) mal configurati all’interno dell’Amazon VPC.
Molte organizzazioni lasciano porte ampiamente aperte, specialmente SSH (porta 22), RDP (porta 3389), o blocchi CIDR interi come 0.0.0.0/0. Il Cloud Security Index 2026 ha rilevato che Permissive Ingress to Sensitive Ports colpisce l’84% degli account AWS, e VPC Subnet Auto-Assigns Public IP colpisce il 72%.
Cosa va spesso storto
- Abuso delle regole “allow all”
- Dimenticare di limitare il traffico in uscita
- Non segmentare correttamente i servizi interni
- Assegnare automaticamente IP pubblici a subnet che dovrebbero essere private
Salvaguardie chiave
- Applicare l’approccio default deny e consentire solo le porte necessarie da CIDR noti
- Usare i log di flusso VPC per auditare i modelli di traffico
- Implementare Network Firewall e PrivateLink per i servizi sensibili
- Disabilitare l’assegnazione automatica di IP pubblici sulle subnet private
Migliori pratiche di sicurezza AWS
Prevenire i rischi di sicurezza AWS non richiede di reinventare la ruota. Richiede coerenza, visibilità e adesione a migliori pratiche collaudate. Implementando proattivamente le strategie seguenti, le organizzazioni possono ridurre drasticamente la probabilità di configurazioni errate e fallimenti di conformità.
Applicare il principio del privilegio minimo
Una causa radice ricorrente dei rischi di sicurezza AWS è l’accesso eccessivo. Seguite sempre il principio del privilegio minimo: gli utenti e i servizi dovrebbero ottenere solo i permessi di cui hanno assolutamente bisogno. Usate ruoli IAM, limiti di permesso e controlli di accesso granulari per limitare ciò che ogni entità può fare.
Consiglio: Usate IAM Access Analyzer per rilevare e correggere accessi non intenzionali.
Abilitare logging e monitoraggio continuo
Molte organizzazioni soffrono di rilevamento tardivo delle violazioni perché mancano di visibilità adeguata. Abilitare AWS CloudTrail, Amazon GuardDuty e AWS Config vi consente di tracciare l’attività nel vostro ambiente, rilevare anomalie e mantenere la conformità con politiche interne e regolamenti esterni.
Vantaggio chiave: Ricevete avvisi in tempo reale sui rischi di sicurezza AWS potenziali prima che escalino.
Automatizzare i controlli di sicurezza
Le revisioni manuali non possono scalare negli ambienti cloud. Usare AWS Config Rules, Inspector e Security Hub può applicare automaticamente le configurazioni di sicurezza di base. Questi strumenti rilevano configurazioni errate di sicurezza come porte aperte, cifratura mancante o risorse accessibili pubblicamente.
Bonus: Integrate questi controlli nei pipeline CI/CD per il rilevamento precoce durante lo sviluppo.
Cifrare tutto — sempre
La cifratura è una delle forme di difesa più semplici ma più efficaci. Assicuratevi che tutti i dati a riposo e in transito siano cifrati utilizzando AWS Key Management Service (KMS) o chiavi gestite dal cliente. Abilitate la cifratura predefinita per servizi come S3, RDS e volumi EBS.
Promemoria: La mancanza di cifratura è un tema ricorrente negli incidenti di sicurezza AWS di alto profilo.
Auditare e ruotare regolarmente le credenziali
Le credenziali vecchie e le chiavi non ruotate aumentano il rischio di compromissione. Il Cloud Security Index 2026 ha rilevato che IAM Access Key Not Rotated colpisce il 71% degli account AWS. Auditate regolarmente gli utenti IAM, disabilitate gli account non utilizzati e ruotate i secret con AWS Secrets Manager.
Per una visione più ampia a livello di programma su come operazionalizzare queste pratiche, consultate la nostra guida sui servizi di sicurezza cloud gestiti. Se state costruendo anche workload AI su AWS, la nostra guida sulla sicurezza LLM per AI agentico copre i rischi aggiuntivi introdotti dai gateway AI e dagli agenti.
Strumenti e risorse per rafforzare la sicurezza AWS
Quando si tratta di minimizzare i rischi di sicurezza AWS, gli strumenti giusti fanno la differenza. AWS fornisce un robusto ecosistema di servizi nativi che vi consente di scegliere quelli più adatti alle vostre esigenze.
AWS Security Hub
AWS Security Hub aggrega i risultati di più servizi — GuardDuty, Inspector e strumenti di terze parti — in un’unica dashboard. Utilizza standard del settore come CIS AWS Foundations Benchmark per valutare il vostro ambiente e identificare rischi di sicurezza AWS critici.
Vantaggi principali
- Visibilità unificata su account AWS
- Controlli di conformità automatizzati
- Integrazione con sistemi di ticketing e strumenti SOAR
Amazon GuardDuty
Questo servizio di rilevamento delle minacce utilizza machine learning per identificare attività anomale, inclusi scan di porte, tentativi di compromissione delle credenziali e accesso da indirizzi IP malevoli. È una delle prime linee di difesa contro le minacce in tempo reale in AWS.
Perché usarlo
- Nessun impatto sulle prestazioni
- Rileva compromissione dell’account, abuso di EC2 e altro
- Invia avvisi azionabili tramite EventBridge
AWS Config e Config Rules
Le configurazioni errate di sicurezza possono essere rilevate precocemente con AWS Config. Questo strumento traccia le modifiche alle vostre risorse AWS e le valuta rispetto a regole predefinite o personalizzate. Potete identificare problemi di sicurezza come bucket S3 pubblici o volumi non cifrati in tempo quasi reale.
Casi d’uso
- Rilevamento di drift rispetto alle configurazioni di base
- Rimedio automatizzato con funzioni Lambda
- Tracce di audit per la governance
IAM Access Analyzer
Uno dei rischi di sicurezza AWS più comuni è l’accesso eccessivamente permissivo. IAM Access Analyzer vi aiuta a scoprire risorse condivise esternamente o con permessi troppo ampi.
Funzionalità principali
- Scansiona ruoli, policy e condivisioni di risorse IAM
- Segnala permessi eccessivi
- Integrazione con AWS Organizations
CloudTrail e CloudWatch
Per l’analisi forense e il monitoraggio delle attività, CloudTrail registra ogni chiamata API effettuata nel vostro ambiente AWS. CloudWatch fornisce capacità di monitoraggio e avviso.
Insieme vi consentono di
- Rilevare tentativi di accesso non autorizzati
- Configurare allarmi su azioni specifiche legate alla sicurezza
- Soddisfare i requisiti di audit e conformità
AWS Trusted Advisor
AWS Trusted Advisor fornisce insights basati sulle migliori pratiche AWS, inclusi controlli di configurazione di sicurezza come porte esposte, MFA su account root e utilizzo IAM.
Rilevanza
- Integrato nei piani AWS Business e Enterprise Support
- Copre sicurezza, costi, tolleranza ai guasti e prestazioni
- Aiuta a priorizzare le attività di rimedio
Esempi del mondo reale di problemi di sicurezza AWS
Comprendere la teoria è una cosa; vedere le conseguenze nel mondo reale rende le lezioni molto più concrete. Questi incidenti sono tutti derivati da rischi di sicurezza AWS che potevano essere evitati con pratiche migliori.
Violazione dei dati Capital One (2019): Configurazione errata IAM e SSRF
Uno dei problemi di sicurezza AWS più infami della storia ha coinvolto Capital One, dove un ex dipendente AWS ha sfruttato una vulnerabilità per accedere a oltre 100 milioni di record di clienti.
Cosa è andato storto
- Un’istanza EC2 aveva un ruolo IAM eccessivamente permissivo, consentendo l’accesso a bucket S3 sensibili.
- L’attaccante ha usato server-side request forgery (SSRF) per indurre l’istanza a emettere credenziali.
- Il logging non era completamente centralizzato, ritardando il rilevamento.
Lezione appresa: Rivedete sempre i ruoli IAM, applicate il principio del privilegio minimo e monitorate i pattern di richiesta anomali.
Esposizione S3 di Accenture (2017): Bucket pubblici che esponevano dati sensibili
La società di consulenza IT globale Accenture ha lasciato diversi bucket S3 accessibili pubblicamente, contenenti chiavi di accesso interne, dati API e credenziali di clienti. Queste configurazioni errate derivavano dalla mancanza di policy di accesso a livello di bucket e monitoraggio.
Correzione: Usate policy di bucket S3 con controlli di accesso rigorosi e sfruttate AWS Config per rilevare esposizioni pubbliche in tempo reale.
Fuga di Booz Allen Hamilton (2017): Bucket S3 aperto con dati governativi
Un’altra grande società di consulenza, Booz Allen Hamilton, ha esposto involontariamente file militari classificati e credenziali a causa di un bucket S3 aperto. La violazione è stata scoperta da ricercatori di sicurezza, non da strumenti di monitoraggio interni.
Lezione appresa: Nessuna risorsa dovrebbe essere esposta a Internet senza una decisione deliberata e auditata. Le policy default-deny e gli strumenti di rimedio automatizzato possono prevenire rischi di sicurezza AWS simili.
Fuga di credenziali della supply chain (2026): Gateway AI espone credenziali AWS
Nel 2026, la società di threat intelligence CloudSEK ha tracciato un attacco alla supply chain attraverso una libreria di gateway AI popolare, esponendo credenziali cloud, chiavi SSH e token Kubernetes in oltre 2.500 organizzazioni e circa 434.000 pipeline CI/CD. Sebbene non sia un difetto della piattaforma AWS, l’incidente mostra come le credenziali AWS possano fuoriuscire attraverso strumenti di terze parti — un promemoria che la gestione dei secret e l’igiene delle credenziali contano oltre la console AWS.
Lezione appresa: Archiviate le credenziali AWS in un secrets manager, mai in file di ambiente commitati nei repository, e ruotate le chiavi regolarmente. Trattate le librerie di terze parti con accesso alle vostre credenziali cloud come parte della vostra superficie di attacco.
Checklist di sicurezza AWS
Usate questa checklist per auditare il vostro ambiente AWS rispetto ai rischi di sicurezza AWS più comuni:
- Abilitare S3 Block Public Access a livello di account (copre i bucket pre-2023)
- Applicare MFA sull’account root e tutti gli utenti IAM con accesso in scrittura
- Applicare IAM a privilegio minimo — nessuna policy
"Action": "*", "Resource": "*" - Abilitare la cifratura predefinita per S3, EBS e RDS
- Limitare i security group — nessun
0.0.0.0/0su SSH, RDP o porte database - Disabilitare l’assegnazione automatica di IP pubblici sulle subnet private
- Abilitare CloudTrail in tutte le regioni per il logging delle chiamate API
- Abilitare GuardDuty per il rilevamento delle minacce
- Abilitare AWS Config con le regole CIS AWS Foundations Benchmark
- Eseguire Security Hub per aggregare i risultati tra gli account
- Ruotare le chiavi di accesso IAM almeno ogni 90 giorni
- Usare AWS Secrets Manager per i secret dell’applicazione, non file
.envnei repository - Patchare le istanze EC2 con Systems Manager Patch Manager
- Iscriversi agli AWS Security Bulletins e agire sui CVE critici
Domande frequenti
Quali sono i problemi di sicurezza AWS più comuni?
I problemi di sicurezza AWS più comuni sono la configurazione errata dei bucket S3, le policy IAM eccessivamente permissive, la mancanza di MFA su utenti root e IAM, i dati non cifrati a riposo e in transito, le API e gli endpoint esposti, le istanze EC2 non patchate e i security group e le ACL di rete mal configurati. La maggior parte di questi deriva da errori di configurazione lato cliente, non da difetti della piattaforma AWS.
Che cos’è il modello di responsabilità condivisa AWS?
Il modello di responsabilità condivisa AWS definisce chi protegge cosa: AWS è responsabile della sicurezza DEL cloud (data center fisici, hardware di rete, hypervisor, servizi fondamentali), mentre il cliente è responsabile della sicurezza NEL cloud (applicazioni, dati, IAM, configurazioni, cifratura, patching). La maggior parte dei problemi di sicurezza AWS deriva da una comprensione errata di questo confine.
Come si prevengono i problemi di sicurezza AWS?
Prevenire i problemi di sicurezza AWS applicando IAM a privilegio minimo, abilitando MFA per tutti gli utenti, abilitando S3 Block Public Access a livello di account, cifrando i dati a riposo e in transito, monitorando continuamente con CloudTrail e GuardDuty, automatizzando i controlli di sicurezza con AWS Config e Security Hub, e ruotando regolarmente le chiavi di accesso IAM e i secret.
AWS è sicuro per impostazione predefinita?
AWS non è insicuro per impostazione predefinita, ma non è nemmeno completamente sicuro per impostazione predefinita. AWS protegge l’infrastruttura sottostante, ma molti servizi — bucket S3 creati prima di aprile 2023, policy IAM, security group e impostazioni di cifratura — richiedono che il cliente applichi configurazioni sicure. Le impostazioni predefinite sono migliorate, ma la configurazione errata lato cliente rimane la causa principale delle violazioni AWS.
Cos’è stata la violazione Capital One AWS?
La violazione Capital One del 2019 ha esposto oltre 100 milioni di record di clienti. Un attaccante ha sfruttato una vulnerabilità server-side request forgery (SSRF) su un’istanza EC2 con un ruolo IAM eccessivamente permissivo, quindi ha utilizzato le credenziali dell’istanza per leggere dati S3 sensibili. La causa radice è stata una combinazione di SSRF, permessi IAM eccessivi e rilevamento ritardato — tutti problemi di sicurezza AWS lato cliente.
AWS Block Public Access previene le fughe S3 per impostazione predefinita?
Dal 5 aprile 2023, AWS abilita S3 Block Public Access e disabilita le ACL per impostazione predefinita per i nuovi bucket. Tuttavia, questa impostazione predefinita non è retroattiva — i bucket creati prima di quella data mantengono le impostazioni di accesso pubblico originali a meno che non si abiliti esplicitamente Block Public Access a livello di account o bucket. I bucket pre-2023 rimangono una fonte comune di fughe di dati S3.
Conclusione
Proteggere il vostro ambiente AWS richiede più del semplice affidarsi alle protezioni integrate di AWS. Come ha dimostrato questa guida, i problemi di sicurezza AWS più comuni nel 2025-2026 — configurazione errata S3, IAM eccessivamente permissivo, MFA mancante, servizi esposti, istanze non patchate e controlli di rete deboli — sono problemi lato cliente che la disciplina lato cliente può prevenire. Iniziate con il modello di responsabilità condivisa AWS, applicate il privilegio minimo, cifrate tutto, automatizzate i controlli di sicurezza e trattate le credenziali come parte della vostra superficie di attacco. La checklist sopra è un punto di partenza pratico; eseguitela sui vostri account oggi.
Se avete bisogno di aiuto per rafforzare il vostro ambiente AWS o costruire workload cloud sicuri, HDWEBSOFT offre servizi di sviluppo AWS e servizi di cybersicurezza per aiutarvi a raggiungere questo obiettivo.
