Un'azienda esegue analisi a lungo termine su dati archiviati in Amazon S3. I job vengono eseguiti su istanze Amazon EC2 in una sottorete privata senza accesso a Internet, utilizzando un gruppo con scalabilità automatica. Le istanze EC2 e i bucket S3 si trovano nello stesso account AWS e utilizzano un VPC endpoint gateway S3 con la policy predefinita. Il ruolo del profilo di ciascuna istanza consente esplicitamente s3:GetObject e s3:PutObject solo per i bucket S3 richiesti. L'azienda scopre che una o più istanze sono compromesse e stanno esfiltrando dati verso un bucket S3 al di fuori dell'organizzazione AWS Organizations dell'azienda. Un ingegnere della sicurezza deve bloccare l'esfiltrazione mantenendo operativi i job di elaborazione. Quale soluzione soddisferà questi requisiti?

L'aggiornamento della policy sull'endpoint gateway S3 è la soluzione più efficace perché controlla l'accesso a S3 direttamente dalla sottorete privata, dove risiedono le istanze EC2. Utilizzando le chiavi di condizione aws:ResourceOrgID e aws:PrincipalOrgID, si garantisce che le operazioni S3 siano consentite solo se sia il bucket di destinazione che l'entità che effettua la richiesta appartengono alla stessa organizzazione AWS, bloccando così l'esfiltrazione verso bucket esterni senza interrompere i job legittimi. Aggiornare la policy del ruolo del profilo dell'istanza non è sufficiente perché, se un'istanza è compromessa, un attaccante potrebbe comunque tentare di esfiltrare dati verso un bucket esterno. Aggiungere una regola ACL di rete per bloccare la porta 443 impedirebbe tutte le comunicazioni S3, inclusi i job legittimi. Applicare una Service Control Policy (SCP) sull'account AWS è una buona pratica di sicurezza generale, ma non è la soluzione più granulare per questo scenario specifico di esfiltrazione da un endpoint gateway S3 e potrebbe non essere immediatamente applicabile a livello di endpoint.