Cuando migras a AWS, es común escuchar que “la nube es segura”. Sin embargo, esa afirmación es cierta solo si comprendes y aplicas correctamente el modelo de responsabilidad compartida (Shared Responsibility Model). Este modelo delimita claramente qué aspectos de la seguridad, la disponibilidad y la confidencialidad son gestionados por AWS y cuáles quedan bajo tu responsabilidad como cliente.
No aclarar este reparto genera configuraciones erróneas, exposición de datos y, en el peor de los casos, incidentes de seguridad que podrían haberse evitado. En este artículo desglosamos el modelo, ofrecemos ejemplos concretos y te damos una lista de verificación para validar que estás cumpliendo con tu parte.
¿Qué es el modelo de responsabilidad compartida?
AWS divide la responsabilidad en dos grandes bloques:
- Seguridad de la nube (Security of the Cloud): AWS protege la infraestructura subyacente — hardware, software, redes y instalaciones que ejecutan los servicios.
- Seguridad en la nube (Security in the Cloud): Tú eres responsable de proteger todo lo que pones dentro de la nube: sistemas operativos, aplicaciones, datos, configuraciones de firewalls, gestión de identidades y accesos, cifrado, etc.
Esta distribución varía ligeramente según el tipo de servicio (IaaS, PaaS, SaaS). En servicios de nivel de infraestructura (EC2, S3, EBS) tu responsabilidad es mayor; en servicios administrados (RDS, Lambda, DynamoDB) AWS asume más tareas, pero nunca elimina tu deber de configurar correctamente los recursos.
Responsabilidades de AWS (Seguridad de la nube)
AWS se encarga de:
- Protección física de los data centers (vigilancia, control de acceso, protección ambiental).
- Seguridad del hardware y firmware (servidores, switches, dispositivos de red).
- Infraestructura de virtualización (hipervisores, aislamiento de instancias).
- Servicios de red básica (router, enlaces, protección contra DDoS a nivel de borde mediante AWS Shield Standard).
- Disponibilidad y resiliencia de los servicios gestionados (por ejemplo, replicación automática de datos en S3 o RDS).
En términos de seguridad, AWS ofrece servicios que tú puedes usar para proteger tu parte (KMS, IAM, GuardDuty, etc.), pero la configuración y el uso correcto de esos servicios es tu responsabilidad.
Tus responsabilidades (Seguridad en la nube)
Según el tipo de servicio, tu lista de tareas incluye, entre otras:
Para EC2, ECS, EKS (instancias y contenedores)
- Sistema operativo: parches, configuración segura, eliminación de servicios innecesarios.
- Gestión de parches y vulnerabilidades (uso de Systems Manager Patch Manager o herramientas externas).
- Firewalls a nivel de instancia (Security Groups) y de red (NACLs).
- Cifrado de discos EBS y volúmenes de instancia (usando KMS o herramientas propias).
- Gestión de credenciales y claves de acceso (IAM roles, Secrets Manager).
- Registro y monitorización (CloudTrail, VPC Flow Logs, CloudWatch Logs).
- Copias de seguridad y planes de recuperación de datos (snapshots, AMI, backup vaults).
Para S3
- Configuración de bloqueo de acceso público (Block Public Access).
- Políticas de bucket y listas de control de acceso (ACLs).
- Cifrado en reposo (SSE‑S3, SSE‑KMS, SSE‑C) y en tránsito (HTTPS).
- Control de versiones y MFA Delete.
- Registro de acceso (access logs) y replicación con cifrado.
Para RDS y Aurora
- Gestión de parches del motor de base de datos (si aplica).
- Configuración de grupos de seguridad y parámetros de red.
- Cifrado en reposo (KMS) y en tránsito (SSL).
- Gestión de cuentas y privilegios dentro de la base de datos.
- Copias de seguridad automáticas y snapshots manuales.
- Uso de IAM database authentication cuando sea posible.
Para servicios totalmente administrados (Lambda, DynamoDB, SNS, SQS)
- Configuración adecuada de permisos (policy de ejecución, roles).
- Control de acceso a los recursos (policy de los propios servicios, VPC endpoints si los usas).
- Manejo de variables de entorno sensibles (usando Secrets Manager o Parameter Store con cifrado).
- Registro y trazabilidad (CloudTrail, CloudWatch Logs, X‑Ray).
- Límites de concurrencia y cuotas para evitar denegación de servicio.
Resultado esperado: una lista de verificación práctica
Tras comprender el modelo, puedes aplicar esta checklist en cada nuevo recurso o revisión de arquitectura:
- ¿Qué tipo de servicio estoy usando? (EC2, S3, Lambda, RDS, etc.)
- ¿Cuál es la línea de responsabilidad según la documentación de AWS para ese servicio?
- He aplicado los parches y configuraciones de seguridad del sistema operativo o runtime?
- ¿Mis grupos de seguridad y NACLs siguen el principio de mínimo privilegio?
- ¿Los datos están cifrados en reposo y en tránsito usando KMS o mecanismos equivalentes?
- ¿He revisado que no haya permisos comodín (*) en políticas IAM o en políticas de bucket?
- ¿Activé el registro necesario (CloudTrail, VPC Flow Logs, logs de aplicación)?
- ¿Existe un plan de respaldo y recuperación probado?
- ¿Utilizo herramientas de detección (GuardDuty, Inspector, Security Hub) para validar mi configuración?
Bloque de código: verificar que un bucket S3 tenga bloqueo de acceso público
# AWS CLI: revisa el atributo BlockPublicSettings de un bucket
aws s3api get-public-access-block --bucket mi-bucket-prod --output json
Si el comando devuelve un error NoSuchPublicAccessBlockConfiguration, significa que el bloqueo no está configurado y deberías activarlo:
aws s3api put-public-access-block \
--bucket mi-bucket-prod \
--public-access-block-configuration "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"
Conclusión
El modelo de responsabilidad compartida no es un detalle menor: es la brújula que te indica dónde enfocar tus esfuerzos de seguridad. Dominarlo te permite construir en AWS con confianza, sabiendo exactamente qué debes proteger y qué puedes delegar a la nube.