Control de acceso de S3: políticas de bucket y ACL

S3 ofrece varios mecanismos de control de acceso que se solapan: políticas de IAM (basadas en identidades, controlan lo que pueden hacer los principales), políticas de buckets (políticas JSON basadas en recursos aplicadas al bucket), listas de control de acceso (ACL) (concesiones heredadas por objeto o bucket) y S3 Block Public Access (anulación a nivel de cuenta o bucket que bloquea cualquier acceso público independientemente de las demás políticas). Actualmente, para la mayoría de los casos de uso, el enfoque recomendado consiste en combinar políticas de buckets con Block Public Access; las ACL se consideran heredadas.

Una política de bucket es un documento JSON asociado directamente al bucket de S3. Especifica qué principals (usuarios y roles de IAM, cuentas de AWS, servicios o el público) pueden realizar qué acciones en qué recursos (el bucket o prefijos de claves específicos). Las políticas de bucket permiten el acceso entre cuentas sin necesidad de roles de IAM: puede conceder directamente en la política del bucket a un rol de IAM de otra cuenta de AWS acceso de lectura a objetos específicos. Cada bucket puede tener una política y el tamaño máximo es de 20 KB.

Para servir contenido público (por ejemplo, recursos de un sitio web estático o conjuntos de datos públicos), puede hacer que los objetos sean legibles públicamente mediante una política de bucket. Primero, deshabilite Block Public Access en el nivel del bucket y, después, añada una instrucción de política de bucket con Principal: '*' y Action: s3:GetObject. Es necesario combinar la desactivación de la configuración Block Public Access con el permiso Allow de la política del bucket; habilitar solo uno de los dos no funcionará. Defina siempre el alcance de Resource para un prefijo específico en lugar de para todo el bucket, salvo que desee intencionadamente hacer públicos todos los objetos.

S3 Block Public Access es una protección con cuatro configuraciones que prevalecen sobre las políticas de bucket y las ACL: BlockPublicAcls (rechaza las solicitudes para establecer ACL públicas), IgnorePublicAcls (ignora las ACL públicas existentes), BlockPublicPolicy (rechaza las políticas de bucket que conceden acceso público) y RestrictPublicBuckets (restringe el acceso en función de una política pública). Las cuatro configuraciones están habilitadas de forma predeterminada. También puede habilitar Block Public Access en el nivel de la cuenta, lo que lo bloquea para todos los buckets independientemente de la configuración individual de cada uno; es ideal para evitar la exposición pública accidental.

Las ACL de S3 son el mecanismo de control de acceso original y son anteriores a IAM. Una ACL concede permisos predefinidos (READ, WRITE, FULL_CONTROL) a cuentas de AWS o grupos predefinidos (todos los usuarios, usuarios de AWS autenticados y entrega de registros). Las ACL se pueden aplicar en el nivel del bucket o de cada objeto. Actualmente, AWS recomienda deshabilitar las ACL (la configuración de S3 «Bucket Owner Enforced» hace que el propietario del bucket sea el propietario de todos los objetos y deshabilita las ACL) y utilizar políticas de bucket e IAM. Las ACL todavía se evalúan en el examen SAA-C03 como concepto heredado.

Al servir contenido de S3 mediante CloudFront, desea que el bucket sea privado, pero que CloudFront pueda obtener los objetos. Use Origin Access Control (OAC), el reemplazo moderno de Origin Access Identity (OAI). OAC crea una identidad de CloudFront a la que concede el permiso s3:GetObject en la política del bucket, mientras mantiene habilitado Block Public Access. De este modo, los usuarios deben pasar por CloudFront (para el almacenamiento en caché, WAF y HTTPS) y no pueden acceder directamente al bucket; este es un patrón habitual de arquitectura segura en el examen SAA-C03.

Hay dos formas de conceder a otra cuenta de AWS acceso a su bucket de S3. Opción 1 — Política de bucket: añada una instrucción con el ARN de la cuenta externa como Principal y las acciones de S3 deseadas. Los usuarios y roles de IAM de la cuenta externa siguen necesitando permisos de IAM para llamar a S3, y la política del bucket también debe concederles el permiso Allow. Opción 2 — Rol de IAM con política de confianza: cree un rol en su cuenta en el que confíe la cuenta externa; las identidades de la cuenta externa asumen el rol y obtienen los permisos del bucket. La política de bucket es más sencilla para escenarios de solo lectura; los roles son mejores para el acceso operativo.

Cross-Origin Resource Sharing (CORS) permite que una aplicación web alojada en un dominio realice solicitudes fetch de JavaScript a un bucket de S3 situado en otro dominio. Sin una configuración de CORS, los navegadores bloquean estas solicitudes por motivos de seguridad. Debe añadir al bucket una configuración de CORS que especifique los orígenes, métodos HTTP y encabezados permitidos. CORS suele ser necesario cuando una SPA de React alojada en example.com obtiene imágenes o archivos directamente de la URL de un bucket de S3.

Una URL prefirmada concede acceso durante un tiempo limitado a un objeto privado de S3 (para GET o PUT) sin cambiar ningún permiso del bucket ni del objeto. La URL incluye sus credenciales y un tiempo de expiración; cualquiera que tenga la URL puede acceder al objeto hasta que caduque. Use URL prefirmadas para permitir que los usuarios autenticados de su aplicación descarguen archivos privados, permitir que los clientes carguen archivos directamente en S3 sin pasar por su backend o compartir informes temporalmente. La expiración puede variar entre 1 segundo y 7 días (al usar credenciales temporales de STS, el máximo es de 12 horas).

Use condiciones en la política del bucket para añadir seguridad basada en el contexto. Patrones habituales: aws:SourceIp restringe el acceso a rangos de IP específicos (por ejemplo, puntos de enlace de VPC o redes corporativas); aws:SecureTransport: true obliga a usar HTTPS al denegar las solicitudes mediante HTTP (una práctica recomendada para todos los buckets que almacenan datos confidenciales); s3:x-amz-server-side-encryption garantiza que los objetos se carguen con cifrado del lado del servidor; y aws:PrincipalOrgID restringe el acceso a principals de su organización de AWS, lo que evita la extracción de datos hacia cuentas externas.

De forma predeterminada, las instancias de EC2 en una subred privada acceden a S3 a través de Internet (mediante una puerta de enlace NAT), lo que genera costes de NAT y expone el tráfico a la Internet pública. Los S3 Gateway Endpoints proporcionan conectividad privada a S3 desde una VPC sin una puerta de enlace NAT y sin costes adicionales. Debe añadir el Gateway Endpoint a la tabla de enrutamiento; el tráfico hacia S3 se enruta automáticamente a través de la red privada de AWS. También puede añadir condiciones a la política del bucket mediante aws:SourceVpce para restringir el acceso únicamente a las solicitudes que pasen por el punto de enlace.

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección ha aprendido que las políticas de bucket son documentos JSON basados en recursos que controlan el acceso entre cuentas y de los servicios a S3, que S3 Block Public Access es una protección que evita la exposición pública accidental y que las URL prefirmadas, los puntos de enlace de VPC y las configuraciones de CORS permiten abordar de forma segura patrones de acceso específicos. A continuación, veremos el versionado de S3, MFA Delete y la replicación.