Een bedrijf voert langlopende analyses uit op gegevens die zijn opgeslagen in Amazon S3. De jobs draaien op Amazon EC2-instances in een privé-subnet zonder internettoegang, met behulp van een Auto Scaling group. De EC2-instances en S3-buckets bevinden zich in hetzelfde AWS-account en gebruiken een S3 gateway VPC endpoint met het standaardbeleid. Het profiel van elke instance staat expliciet s3:GetObject en s3:PutObject alleen toe voor de vereiste S3-buckets. Het bedrijf ontdekt dat een of meer instances zijn gecompromitteerd en gegevens exfiltreren naar een S3-bucket buiten de AWS Organizations-organisatie van het bedrijf. Een beveiligingsengineer moet de exfiltratie stoppen terwijl de verwerkingsjobs operationeel blijven. Welke oplossing voldoet aan deze vereisten?

Het bijwerken van het beleid op het S3 gateway endpoint met aws:ResourceOrgID en aws:PrincipalOrgID zorgt ervoor dat S3-acties alleen zijn toegestaan als de bron (de S3-bucket) en de principal (de EC2-instance) binnen dezelfde AWS Organizations-organisatie vallen. Dit voorkomt exfiltratie naar externe buckets, terwijl de legitieme verwerking binnen de organisatie operationeel blijft. Het bijwerken van het instance profile role met alleen aws:ResourceOrgID is onvoldoende, omdat dit alleen de bron beperkt en niet de bestemming van de data. Een netwerk-ACL-regel op poort 443 blokkeert alle S3-communicatie, waardoor de verwerkingsjobs stoppen. Een Service Control Policy (SCP) is een organisatiebreed beleid en kan niet worden toegepast op een specifiek VPC endpoint, bovendien zou het de EC2-instances niet direct beïnvloeden om exfiltratie te stoppen zonder de verwerking te onderbreken.