La empresa utiliza una organización de AWS Organizations para administrar las cuentas de desarrollador. Todos los datos deben cifrarse en tránsito, pero varios buckets de S3 en las cuentas de desarrollador actualmente permiten solicitudes sin cifrar (no SSL). Un ingeniero de DevOps debe aplicar TLS (SSL) para los datos en tránsito para cada bucket de S3 existente en las cuentas de la organización. ¿Qué enfoque satisface este requisito?

La opción correcta aborda directamente el requisito de aplicar TLS (SSL) para S3. Habilitar AWS Config en la organización con la regla administrada s3-bucket-ssl-requests-only permite identificar los buckets que no cumplen con la política. El runbook de automatización de Systems Manager, utilizando la clave de condición aws:SecureTransport con un valor false, asegura que se deniegue el acceso a S3 si la solicitud no utiliza HTTPS, forzando así el cifrado en tránsito. Las opciones que involucran AWS Network Firewall son incorrectas porque Network Firewall opera a nivel de red y no puede inspeccionar o forzar el uso de SSL para solicitudes específicas de S3 a nivel de aplicación. Además, bloquear el puerto 80 no fuerza SSL; simplemente bloquea el tráfico HTTP no cifrado, pero no garantiza que las solicitudes a S3 se realicen a través de HTTPS. La opción incorrecta de AWS Config y Systems Manager que usa s3:x-amz-server-side-encryption-aws-kms-key-id se refiere al cifrado en reposo (server-side encryption), no al cifrado en tránsito (SSL/TLS).