Firma przeprowadza długotrwałe analizy danych przechowywanych w Amazon S3. Zadania są uruchamiane na instancjach Amazon EC2 w prywatnej podsieci bez dostępu do internetu, korzystając z grupy Auto Scaling. Instancje EC2 i zasobniki S3 znajdują się na tym samym koncie AWS i używają punktu końcowego S3 gateway VPC z domyślną polityką. Rola profilu każdej instancji jawnie zezwala na s3:GetObject i s3:PutObject tylko dla wymaganych zasobników S3. Firma odkrywa, że jedna lub więcej instancji zostało skompromitowanych i eksfiltruje dane do zasobnika S3 poza organizacją AWS Organizations firmy. Inżynier bezpieczeństwa musi zatrzymać eksfiltrację, jednocześnie utrzymując działanie zadań przetwarzania. Które rozwiązanie spełni te wymagania?

Poprawna odpowiedź to aktualizacja polityki na punkcie końcowym S3 gateway. Dodanie warunków aws:ResourceOrgID i aws:PrincipalOrgID do polityki punktu końcowego VPC S3 gateway zapewni, że instancje EC2 będą mogły komunikować się tylko z zasobnikami S3 należącymi do tej samej organizacji AWS. Ponieważ instancje EC2 nie mają dostępu do internetu, cała komunikacja z S3 odbywa się przez ten punkt końcowy, co skutecznie uniemożliwi eksfiltrację danych do zasobników poza organizacją, jednocześnie pozwalając na kontynuację bieżących zadań. Aktualizacja polityki roli profilu instancji jest niewystarczająca, ponieważ rola ta już zezwala na s3:PutObject, a atakujący mógłby wykorzystać tę rolę do zapisu do zasobnika w tej samej organizacji, a następnie przenieść dane. Dodanie reguły Network ACL blokującej port 443 uniemożliwiłoby wszelką komunikację z S3, przerywając działanie zadań. Zastosowanie SCP na koncie AWS jest zbyt szerokie i nie jest najbardziej precyzyjnym rozwiązaniem w tym przypadku, ponieważ polityka punktu końcowego VPC jest bardziej granularna i bezpośrednio kontroluje dostęp z prywatnej podsieci.