Scenari di architetture sicure

Scenario: Un’istanza EC2 esegue un’applicazione web che deve leggere oggetti da uno specifico bucket S3. Il team di sicurezza richiede che sull’istanza non vengano memorizzate credenziali a lungo termine e che l’accesso segua il principio del privilegio minimo. Soluzione: Crei un ruolo IAM con una policy che consenta solo s3:GetObject sull’ARN del bucket specifico. Colleghi il ruolo all’istanza EC2 come profilo dell’istanza. L’applicazione utilizza il servizio di metadati dell’istanza (IMDS) per recuperare automaticamente credenziali temporanee: non sono necessarie chiavi memorizzate.

Scenario: Un’azienda memorizza dati personali identificabili dei clienti in un database RDS PostgreSQL. Il team di conformità richiede la crittografia a riposo con la possibilità di verificare l’utilizzo delle chiavi. Soluzione: Abiliti la crittografia RDS tramite AWS KMS utilizzando una Customer Managed Key (CMK). La CMK consente al team di sicurezza di controllare la rotazione delle chiavi, visualizzarne l’utilizzo in CloudTrail e revocare l’accesso se necessario. Nota: la crittografia deve essere abilitata durante la creazione dell’istanza RDS; non è possibile crittografare direttamente un’istanza RDS esistente non crittografata. Per crittografare un database esistente, crei uno snapshot, lo copi abilitando la crittografia e ripristini il database dallo snapshot crittografato.

Scenario: Uno sviluppatore ha reso accidentalmente pubblico un bucket S3, esponendo dati dei clienti. Il team di sicurezza vuole garantire che nessun bucket S3 dell’account possa mai essere reso pubblico, anche se uno sviluppatore ci prova. Soluzione: Abiliti S3 Block Public Access a livello di account. Questa impostazione prevale su qualsiasi policy o ACL a livello di bucket che conceda l’accesso pubblico, indipendentemente dalla configurazione dei singoli team. La combini con una regola AWS Config (s3-bucket-public-read-prohibited) per rilevare continuamente e segnalare i bucket non conformi.

Scenario: Un’azienda vuole garantire che il database RDS sia accessibile solo dai propri server applicativi e non da Internet. Soluzione: Inserisca RDS in una subnet privata senza una route verso un internet gateway. Crei un gruppo di sicurezza per RDS che consenta il traffico in ingresso sulla porta 5432 (PostgreSQL) solo dal gruppo di sicurezza dei server applicativi, non da alcun intervallo di indirizzi IP. In questo modo, anche se un server applicativo viene compromesso, l’attaccante non può raggiungere il database dall’esterno della VPC e il movimento laterale è limitato dalle regole dei gruppi di sicurezza.

Scenario: Il codice dell’applicazione contiene attualmente le credenziali del database hardcoded nei file di configurazione. L’audit di sicurezza segnala questo aspetto come un rischio critico. Soluzione: Memorizzi le credenziali in AWS Secrets Manager e configuri la rotazione automatica (Secrets Manager dispone di funzioni Lambda integrate per la rotazione di RDS). Aggiorni l’applicazione affinché recuperi le credenziali da Secrets Manager durante l’esecuzione utilizzando l’SDK. L’applicazione riceve automaticamente credenziali aggiornate senza richiedere un deployment a ogni rotazione. Abiliti il modello di rotazione dei segreti RDS per una rotazione delle credenziali completamente gestita e senza downtime.

Scenario: Un’azienda vuole rilevare se le credenziali di un account AWS sono state compromesse e vengono utilizzate da posizioni inaspettate. Soluzione: Abiliti Amazon GuardDuty in tutte le Regioni. GuardDuty analizza gli eventi CloudTrail, i log VPC Flow e i log DNS utilizzando il machine learning per rilevare anomalie: chiamate API provenienti da aree geografiche insolite, modelli di mining di Bitcoin su EC2, comunicazioni con nodi di uscita Tor o modelli di esfiltrazione delle credenziali. GuardDuty genera finding che possono attivare regole EventBridge per notificare automaticamente il team di sicurezza tramite SNS o creare un ticket di supporto.

Scenario: Un’applicazione web eseguita dietro un ALB sta ricevendo attacchi di SQL injection. Non è possibile modificare immediatamente l’applicazione. Soluzione: Associ AWS WAF all’ALB. Implementi il gruppo di regole AWS Managed Rules for Common Threats (Core Rule Set + gruppo di regole SQL Database), che include il rilevamento predefinito delle SQL injection. WAF ispeziona le richieste HTTP prima che raggiungano l’ALB e blocca quelle che corrispondono a modelli di attacco: non è necessaria alcuna modifica al codice dell’applicazione. Abiliti inoltre il logging di WAF verso Kinesis Firehose per l’analisi della sicurezza.

Scenario: Un account di sicurezza centrale necessita di accesso in sola lettura a tutti gli account dei carichi di lavoro di un’AWS Organisation per eseguire audit di sicurezza. Soluzione: In ogni account dei carichi di lavoro, crei un ruolo IAM con una policy di attendibilità che consenta all’account di sicurezza, identificato dall’ID dell’account, di assumerlo. Alleghi una policy di sola lettura (ad esempio, la policy gestita da AWS SecurityAudit). Il team di sicurezza dell’account centrale utilizza STS AssumeRole per assumere temporaneamente il ruolo in ciascun account dei carichi di lavoro. Questa soluzione segue il principio del privilegio minimo: negli account dei carichi di lavoro non vengono creati utenti IAM permanenti.

Scenario: Un’azienda utilizza AWS Organizations e vuole impedire a qualsiasi account di un’unità organizzativa non di produzione di avviare istanze GPU costose. Soluzione: Crei una Service Control Policy (SCP) che neghi ec2:RunInstances per le famiglie di istanze GPU (p3, p4, g4, g5) e la colleghi all’unità organizzativa non di produzione. Le SCP si applicano anche agli utenti root e agli utenti IAM con livello di amministratore negli account membri: fungono da guardrail che nessuna identità nell’account può eludere. In questo modo si previene una spesa elevata accidentale o dannosa negli account di sviluppo e test.

Scenario: Una società di servizi finanziari deve dimostrare agli auditor che tutte le chiamate API AWS vengono registrate, sono a prova di manomissione e vengono conservate per 7 anni. Soluzione: Crei un trail AWS CloudTrail multi-Regione che recapiti i log in un bucket S3 dedicato di un account di logging. Abiliti la convalida dell’integrità dei file di log (file digest crittografici che rilevano la manomissione dei log). Imposti una policy S3 Object Lock in modalità Compliance con un periodo di conservazione di 7 anni sul bucket di logging. In questo modo i log non possono essere eliminati o modificati, nemmeno dall’utente root, per il periodo di conservazione richiesto.

Scenario: Le istanze EC2 in una VPC privata devono accedere a S3 senza che il traffico attraversi Internet. Attualmente viene utilizzato un NAT Gateway e i costi sono elevati a causa delle tariffe di elaborazione dati del NAT Gateway. Soluzione: Crei un S3 Gateway VPC Endpoint. Aggiunga alla tabella di routing della subnet privata una voce che indirizzi la prefix list di S3 verso l’endpoint. Il traffico verso S3 rimane interamente all’interno della rete backbone AWS: non sono necessari né un NAT Gateway né un internet gateway. Gli S3 Gateway Endpoint sono gratuiti, a differenza degli Interface Endpoint, che hanno un costo orario per AZ. Questa soluzione migliora inoltre la sicurezza rimuovendo l’accesso a S3 dal percorso attraverso Internet.

Verifichi la Sua comprensione dei concetti di AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione ha affrontato scenari riguardanti: ruoli IAM e profili di istanza per accedere a EC2 senza credenziali, Secrets Manager per la rotazione automatica delle credenziali del database, AWS WAF per bloccare gli attacchi di injection senza modifiche al codice e CloudTrail con S3 Object Lock per log di conformità a prova di manomissione. Ora affronteremo scenari di architetture resilienti e ad alta disponibilità.