Seguridad en AWS: IAM y buckets S3 bajo control

1. Introducción

Seguridad en AWS IAM y S3 es, probablemente, el área de la nube que más incidentes de exposición de datos ha causado en los últimos años. Cada semana aparecen informes sobre buckets abiertos, credenciales filtradas o usuarios con permisos excesivos que terminan comprometiendo cuentas enteras. La buena noticia es que, en la mayoría de los casos, se trata de errores evitables si se aplican criterios claros de seguridad en AWS IAM y S3 desde el primer día.

Este artículo no es un manual teórico: es una guía práctica con políticas reales, comandos de AWS CLI que puedes ejecutar en tu cuenta de pruebas y un flujo de auditoría que replica lo que haría un especialista en ciberseguridad dentro del ámbito de la seguridad en AWS IAM y S3. Si trabajas con infraestructura cloud, devops o administración de sistemas, esto te va a ahorrar más de un susto.

2. Seguridad en AWS IAM y S3: conceptos que debes dominar

IAM (Identity and Access Management) es el servicio encargado de gestionar identidades, grupos, roles y permisos dentro de una cuenta de AWS. Prácticamente toda operación en la plataforma pasa por una evaluación de políticas de IAM, lo que lo convierte en el primer foco de cualquier trabajo de seguridad en AWS IAM y S3. Por su parte, S3 (Simple Storage Service) es el servicio de almacenamiento de objetos, uno de los más utilizados del mundo y también uno de los más mal configurados.

Cuando hablamos de seguridad en AWS IAM y S3 nos referimos a proteger ambas piezas de forma coordinada: identidades con los permisos justos y buckets con políticas que solo permitan el acceso necesario. El error más común es tratar cada servicio por separado y olvidar que un bucket público se vuelve crítico si la clave de acceso que lo escribe tiene privilegios de administrador sobre toda la cuenta. La combinación de ambos problemas convierte un incidente menor en una fuga de datos masiva.

Conviene recordar el modelo de responsabilidad compartida: AWS protege la infraestructura física y lógica, pero la configuración de IAM, las políticas de S3, la encriptación y el monitoreo quedan en tu lado de la frontera. La seguridad en AWS IAM y S3 depende de ambas partes, y delegar esa responsabilidad en la nube es el primer paso hacia un incidente grave.

3. IAM: políticas, roles y el principio de mínimos privilegios

El principio de mínimos privilegios es la base de la seguridad en AWS IAM y S3. Consiste en conceder únicamente los permisos necesarios para realizar una tarea concreta, ni uno más. En la práctica, esto se traduce en políticas JSON bien definidas que limitan acciones y recursos de forma explícita y en una revisión periódica de cada política adjunta a usuarios y roles. No hacerlo es exactamente lo que permite que una única clave filtrada dé acceso a toda la cuenta.

3.1 Un ejemplo de política IAM para la seguridad en AWS IAM y S3

Imagina un rol para una aplicación que solo debe leer logs de un bucket concreto. La política debería ser tan restrictiva como esta, que es el patrón que yo utilizo en todas mis evaluaciones de seguridad en AWS IAM y S3:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::logs-produccion",
        "arn:aws:s3:::logs-produccion/*"
      ]
    }
  ]
}

Fig. 1 – Política IAM con mínimos privilegios para lectura de un único bucket de logs.

Fíjate en los detalles: la acción está limitada a GetObject y ListBucket, y el recurso apunta a un ARN concreto en lugar de un comodín. Un error habitual es usar «Action»: «*» o un recurso como «arn:aws:s3:::*», que anula cualquier otra protección que puedas haber configurado. Además de políticas bien escritas, la seguridad en AWS IAM y S3 pasa por buenas prácticas como activar MFA para todos los usuarios, rotar las claves de acceso cada 90 días y usar roles temporales (STS) en lugar de credenciales de larga duración.

3.2 Usuarios, roles y políticas gestionadas

Una buena estructura de IAM separa usuarios (personas) de roles (máquinas o servicios). Los roles se asumen de forma temporal mediante STS, lo que reduce enormemente el riesgo de claves filtradas en código o en documentación interna. Para las políticas, conviene partir de las gestionadas por AWS y crear versiones propias solo cuando sea necesario. Cada vez que tengas que ampliar un permiso, pregúntate si existe una alternativa con menos alcance: esa es la mentalidad que define la seguridad en AWS IAM y S3 en organizaciones maduras.

4. S3: buckets públicos, políticas y controles de acceso

S3 ofrece varios niveles de control de acceso: bucket policies, ACL, políticas de IAM y bloques de acceso público. La combinación incorrecta de estas capas es la causa número uno de fugas de datos, y revisar cada capa por separado forma parte fundamental de la seguridad en AWS IAM y S3. Un caso típico que he encontrado en auditorías reales:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadAccidental",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::backups-ventas-2024/*"
    }
  ]
}

Fig. 2 – Bucket policy que permite lectura pública de todos los backups del bucket.

Con «Principal»: «*» cualquier persona del mundo puede descargar los objetos de ese bucket. Este patrón aparece en auditorías más de lo que imaginas, a menudo porque alguien copió una política de ejemplo de un foro sin entenderla. Y eso es precisamente lo que la seguridad en AWS IAM y S3 trata de evitar: políticas heredadas que nadie revisa y que convierten datos internos en contenido accesible.

La primera barrera defensiva es activar el bloqueo de acceso público (Public Access Block) en todos los buckets, y desactivarlo solo cuando exista una razón de negocio documentada y aprobada. Conviene también activar el versionado para protegerte frente a borrados o ransomware, y la encriptación por defecto (SSE-S3 o SSE-KMS). Estas medidas son baratas y elevan notablemente el nivel de seguridad en AWS IAM y S3 sin afectar al rendimiento de tus aplicaciones ni a la experiencia de los usuarios finales.

Tabla 1. Errores frecuentes que comprometen la seguridad en AWS IAM y S3
Error	Riesgo	Mitigación
Bucket con lectura pública	Exposición total de los datos	Activar Public Access Block y revisar bucket policies
Usuarios con política AdministradorAccess	Control total de la cuenta	Aplicar mínimos privilegios y roles temporales
Claves de acceso sin rotación	Compromiso persistente	Rotación cada 90 días y AWS Secrets Manager
Usuarios IAM sin MFA	Robo de credenciales	MFA obligatoria para consola y CLI
Versionado desactivado	Pérdida de datos y ransomware	Habilitar versionado y reglas de ciclo de vida

5. Auditoría práctica con AWS CLI

La mejor manera de comprobar el estado real de una cuenta es ejecutar una auditoría manual con AWS CLI. Estos son los comandos que utilizo en cualquier revisión inicial de seguridad en AWS IAM y S3, y que puedes copiar tal cual en tu terminal:

aws sts get-caller-identity

aws s3api list-buckets --query "Buckets[*].Name"

aws iam list-attached-user-policies --user-name devops

aws iam get-policy-version \
  --policy-arn arn:aws:iam::123456789012:policy/DevOps \
  --version-id v1

aws s3api get-bucket-policy --bucket backups-ventas-2024
aws s3api get-bucket-acl --bucket backups-ventas-2024
aws s3api get-public-access-block --bucket backups-ventas-2024

Fig. 3 – Comandos esenciales de AWS CLI para auditar la seguridad en AWS IAM y S3.

El primer comando, aws sts get-caller-identity, es el punto de partida obligatorio: te dice con qué identidad estás trabajando y evita auditar la cuenta equivocada. Después revisa quién tiene políticas adjuntas, qué versión se aplica y, sobre todo, el estado de los buckets: política, ACL y bloqueo de acceso público. Si cualquiera de los últimos comandos devuelve datos inesperados, ya tienes tu primera vulnerabilidad localizada para el informe.

Para una revisión más profunda puedes escribir un pequeño script con Python y boto3 que recorra todos los buckets y reporte los que tienen acceso público o carecen de bloqueo. Este tipo de automatización complementa cualquier programa de seguridad en AWS IAM y S3:

import boto3

s3 = boto3.client('s3')
for bucket in s3.list_buckets()['Buckets']:
    nombre = bucket['Name']
    try:
        pa = s3.get_public_access_block(Bucket=nombre)
        bloqueado = pa['PublicAccessBlockConfiguration']
        if not bloqueado['BlockPublicPolicy']:
            print('REVISAR:', nombre)
    except Exception:
        print('SIN CONTROL:', nombre)

Fig. 4 – Script Python para detectar buckets sin bloqueo de acceso público.

Una auditoría completa de seguridad en AWS IAM y S3 incluye también revisar los CloudTrail de eventos de IAM, comprobar qué identidades han asumido roles elevados en los últimos 90 días y verificar la rotación de claves. La documentación oficial de Amazon recoge todo el detalle: te recomiendo partir de la guía de seguridad de AWS IAM y de las mejores prácticas de seguridad de Amazon S3. También el blog de seguridad de AWS suele publicar análisis de incidentes reales para aprender de los errores de los demás.

6. Relación con auditorías técnicas y análisis de riesgos

La seguridad en AWS IAM y S3 no es un ejercicio aislado: forma parte de un programa más amplio de auditoría técnica y gestión de riesgos. Cada hallazgo de una revisión de IAM o de buckets debe registrarse con su probabilidad, su impacto y el coste estimado de remediación, igual que se hace con cualquier otro activo de la organización. Es la única forma de que la dirección entienda por qué invertir en hardening cloud es prioritario y de cuantificar el coste real de no aplicar seguridad en AWS IAM y S3.

7. Conclusión

La seguridad en AWS IAM y S3 está al alcance de cualquier equipo que dedique tiempo a entender las políticas y a auditarse con regularidad. Los grandes incidentes no ocurren por técnicas sofisticadas: la seguridad en AWS IAM y S3 se pierde con permisos mal concedidos, buckets mal configurados y claves que nunca se rotan. Aplicar mínimos privilegios, bloquear el acceso público, activar MFA y ejecutar auditorías periódicas con los comandos que has visto reduce el riesgo de forma drástica.

Mi recomendación es clara: agenda una revisión de seguridad en AWS IAM y S3 cada trimestre, documenta los hallazgos y remedia primero lo que tenga mayor impacto. La nube no es insegura por defecto; es insegura cuando nadie la revisa.

¿Necesitas ayuda con Seguridad en AWS IAM y S3?

En Jaymon Security ayudamos a las organizaciones a proteger sus sistemas. Desde auditorías de seguridad hasta implementación de SIEM/SOC, nuestro equipo de expertos diseña soluciones a medida.

Contacta con nosotros para una evaluación gratuita de tu infraestructura.