Компания выполняет длительную аналитику данных, хранящихся в Amazon S3. Задания выполняются на инстансах Amazon EC2 в частной подсети без доступа к интернету, используя группу Auto Scaling. Инстансы EC2 и бакеты S3 находятся в одном аккаунте AWS и используют S3 gateway VPC endpoint с политикой по умолчанию. Роль профиля каждого инстанса явно разрешает s3:GetObject и s3:PutObject только для необходимых бакетов S3. Компания обнаруживает, что один или несколько инстансов скомпрометированы и эксфильтруют данные в бакет S3 за пределами организации AWS Organizations компании. Инженер по безопасности должен остановить эксфильтрацию, сохраняя при этом работоспособность процессов обработки. Какое решение соответствует этим требованиям?

Правильный ответ — обновить политику на S3 gateway endpoint. Политика конечной точки шлюза S3 контролирует доступ к S3 из VPC. Добавление условий aws:ResourceOrgID и aws:PrincipalOrgID гарантирует, что запросы S3 могут быть выполнены только для ресурсов S3, принадлежащих организации, и только субъектами (инстансами EC2), принадлежащими той же организации. Это эффективно предотвращает эксфильтрацию данных в бакеты S3 за пределами организации, поскольку инстансы не смогут получить доступ к внешним бакетам, даже если они скомпрометированы. При этом сохраняется доступ к внутренним бакетам S3, необходимый для работы аналитики. Обновление политики роли профиля инстанса не поможет, так как скомпрометированный инстанс может использовать свои учетные данные для доступа к внешним бакетам, если политика бакета S3 это позволяет. Добавление правила в сетевой ACL блокирует весь исходящий трафик S3, нарушая работу аналитики. Применение SCP к аккаунту AWS — это более широкое решение, которое может быть эффективным, но политика конечной точки шлюза S3 является более точным и немедленным контролем для трафика из VPC к S3.