Una empresa ejecuta análisis de larga duración sobre datos almacenados en Amazon S3. Los trabajos se ejecutan en instancias de Amazon EC2 en una subred privada sin acceso a internet, utilizando un grupo de Auto Scaling. Las instancias EC2 y los buckets de S3 están en la misma cuenta de AWS y usan un VPC endpoint de gateway de S3 con la política predeterminada. El rol del perfil de cada instancia permite explícitamente s3:GetObject y s3:PutObject solo para los buckets de S3 requeridos. La empresa descubre que una o más instancias están comprometidas y están exfiltrando datos a un bucket de S3 fuera de la organización de AWS Organizations de la empresa. Un ingeniero de seguridad debe detener la exfiltración manteniendo los trabajos de procesamiento operativos. ¿Qué solución cumplirá estos requisitos?

Actualizar la política del S3 gateway endpoint es la solución correcta porque los endpoints de gateway controlan el acceso a S3 desde la VPC. Al añadir las condiciones aws:ResourceOrgID y aws:PrincipalOrgID a la política del endpoint, se asegura que las instancias solo puedan acceder a buckets de S3 dentro de la misma AWS Organization, bloqueando la exfiltración a buckets externos. Actualizar la política del rol de instancia no es suficiente porque la instancia comprometida podría usar credenciales temporales o de otra forma eludir esta política para acceder a buckets externos si el endpoint de gateway lo permite. Agregar una regla de ACL de red bloquearía todo el tráfico saliente en el puerto 443, interrumpiendo las operaciones legítimas a S3. Aplicar una SCP a la cuenta de AWS no es efectivo en este escenario porque las SCPs se aplican a nivel de cuenta o UO, y la exfiltración ya está ocurriendo desde una instancia comprometida dentro de la cuenta. La SCP no puede restringir el acceso a buckets fuera de la organización si la política del endpoint de gateway lo permite.