Se stai utilizzando AWS, è facile pensare che la sicurezza del tuo cloud sia completamente gestita – ma questa è una pericolosa illusione. AWS si occupa della sicurezza della propria infrastruttura, ma la sicurezza all’interno di un ambiente cloud rimane una responsabilità del cliente.
Pensa alla sicurezza di AWS come alla protezione di un edificio: AWS fornisce muri solidi e un tetto robusto, ma spetta al cliente gestire le serrature, installare i sistemi di allarme e assicurarsi che i beni di valore non siano esposti.
Comprendere il modello di responsabilità condivisa di AWS
AWS opera su un modello di responsabilità condivisa. In termini semplici:
- AWS è responsabile della sicurezza dell’infrastruttura sottostante (ad esempio, hardware, rete, data center) – i “muri e il tetto”.
- Il cliente è responsabile della sicurezza dei propri dati, applicazioni e configurazioni all’interno di AWS – le “serrature e gli allarmi”.
Comprendere questa distinzione è essenziale per mantenere un ambiente AWS sicuro.
5 vulnerabilità reali di AWS che devi affrontare
Esaminiamo alcune vulnerabilità reali che ricadono sotto la responsabilità del cliente e cosa si può fare per mitigarle.
Server-side request forgery (SSRF)
Le applicazioni ospitate in AWS sono ancora vulnerabili ad attacchi come l’SSRF, dove gli attaccanti ingannano un server facendogli effettuare richieste per loro conto. Questi attacchi possono portare ad accessi non autorizzati ai dati e ulteriori sfruttamenti.
Per difendersi dall’SSRF:
- Scansiona e correggi regolarmente le vulnerabilità nelle applicazioni.
- Abilita AWS IMDSv2, che fornisce un ulteriore livello di sicurezza contro gli attacchi SSRF. AWS offre questa protezione, ma la configurazione è responsabilità del cliente.
Debolezze nel controllo degli accessi
AWS Identity and Access Management (IAM) consente ai clienti di gestire chi può accedere a quali risorse – ma è efficace solo quanto la sua implementazione. I clienti sono responsabili di garantire che utenti e sistemi abbiano accesso solo alle risorse di cui hanno realmente bisogno.
Errori comuni includono:
- Ruoli eccessivamente permissivi e accessi.
- Controlli di sicurezza mancanti.
- Bucket S3 accidentalmente pubblici.
Esposizioni di dati
I clienti AWS sono responsabili della sicurezza dei dati che memorizzano nel cloud – e di come le loro applicazioni accedono a tali dati.
Ad esempio, se la tua applicazione si connette a un AWS Relational Database Service (RDS), il cliente deve garantire che l’applicazione non esponga dati sensibili agli attaccanti. Una semplice vulnerabilità come un Insecure Direct Object Reference (IDOR) potrebbe consentire a un attaccante con un account utente di accedere ai dati appartenenti a tutti gli altri utenti.
Gestione delle patch
Quasi superfluo dirlo, ma AWS non applica patch ai server! I clienti che distribuiscono istanze EC2 sono completamente responsabili di mantenere aggiornati il sistema operativo (OS) e il software.
Prendiamo come esempio Redis distribuito su Ubuntu 24.04 – il cliente è responsabile di applicare patch alle vulnerabilità sia nel software (Redis) che nel sistema operativo (Ubuntu).
In questo blog, chiariremo cosa AWS non protegge, evidenzieremo le vulnerabilità reali e come strumenti di scansione della sicurezza cloud come Intruder possono aiutare.
Fonte: The Hackers News
Ricevi le ultime attualità sul mondo tech!
