Cuando alguien me dice "usamos AWS, estamos seguros", sé de inmediato que hay una conversación pendiente. AWS es uno de los proveedores de nube más seguros del mundo. Y al mismo tiempo, todos los años hay miles de brechas de datos en AWS. Las dos cosas son verdad al mismo tiempo — y el modelo de responsabilidad compartida explica exactamente por qué.
Entender esto no es preparación para el examen CCP. Es la base sin la cual no puedes tomar ninguna decisión de seguridad en la nube de forma correcta.
La analogía del apartamento
Imagina que rentas un apartamento en un edificio seguro:
🏢 Analogía
El edificio (AWS) es responsable de: la estructura del edificio, el sistema eléctrico, el ascensor, las cámaras del lobby, la seguridad de la entrada principal, el mantenimiento de las áreas comunes.
Pero tú eres responsable de: no dejar la puerta de tu apartamento abierta, no darle la llave a cualquiera, no dejar objetos de valor a la vista, cambiar la cerradura si pierdes una llave.
Si dejas la puerta abierta y te roban, el edificio no tiene la culpa. Aunque el lobby esté perfectamente vigilado.
AWS es el edificio. Tu cuenta, tus datos, tu configuración — eso es tu apartamento. Son dos responsabilidades distintas, y ninguna cubre a la otra.
Qué protege AWS y qué proteges tú
AWS protege — "Seguridad DE la nube"
Hardware físico de los data centers (servidores, switches, storage)
Infraestructura de red global (fibra, routers, DDoS a nivel de red)
Hipervisores y aislamiento entre clientes
Seguridad física: acceso biométrico, cámaras, guardias 24/7
Software de los servicios administrados (RDS, Lambda, S3 en su núcleo)
Parches del sistema operativo en servicios managed (RDS, ECS Fargate)
Disponibilidad y resiliencia de la infraestructura global
-
Certificaciones de cumplimiento: ISO 27001, SOC 2, PCI DSS (la infraestructura)
Tú proteges — "Seguridad EN la nube" Configuración de IAM: usuarios, roles, políticas, permisos
Configuración de red: Security Groups, NACLs, VPC, rutas
Cifrado de datos en tránsito y en reposo (tú decides si lo activas)
Parches del OS en EC2 (si usas instancias, tú las parcheas)
Configuración de S3: permisos de bucket, políticas, ACLs
Datos de clientes y su clasificación
Aplicaciones que despiegas: código, dependencias, vulnerabilidades
Configuración de logging: CloudTrail, VPC Flow Logs, S3 access logs
MFA, rotación de credenciales, gestión de API keys
⚠️
⚠️ El error más común
Pensar que porque AWS tiene ISO 27001 y SOC 2, tu cuenta también está certificada. No. Esas certificaciones cubren la infraestructura de AWS. Tu workload necesita su propio proceso de cumplimiento, con tus propias configuraciones.Cómo cambia según el tipo de servicio
Esto es lo que complica el modelo: la división de responsabilidad no es siempre la misma. Cambia dependiendo del tipo de servicio que uses.
Servicio Tipo OS / Plataforma App / Datos Red / Firewall EC2 IaaS Tú Tú Tú RDS PaaS AWS Tú Tú Lambda Serverless AWS Tú Compartido S3 Storage AWS Tú Tú EKS (K8s) Managed Compartido Tú Tú Fargate Serverless containers AWS Tú CompartidoLa regla general: mientras más "managed" sea el servicio, más responsabilidad asume AWS. Pero tus datos, tu configuración y tus permisos siempre son tuyo — sin importar qué servicio uses.
Casos reales donde la confusión sale cara
💥 Caso 1 — S3 bucket públicoUna empresa sube documentos de clientes a S3. Asumen que "AWS lo protege". Nadie revisa la configuración del bucket. Resulta que el bucket tiene acceso público activado — cualquiera en internet podía descargar los archivos con solo conocer la URL. AWS nunca falló. La configuración fue responsabilidad del equipo y nadie la auditó. Resultado: brecha de datos, multa por GDPR.
💥 Caso 2 — EC2 sin parchesUn equipo lanza instancias EC2 con Ubuntu. AWS garantiza que el hipervisor está seguro y actualizado. Pero el sistema operativo dentro de la instancia es responsabilidad del equipo. Nadie configura actualizaciones automáticas. Seis meses después, una vulnerabilidad conocida (con CVE y parche disponible) es explotada. AWS hizo su parte. El equipo no hizo la suya.
💥 Caso 3 — IAM con permisos de admin para todoUn desarrollador crea un usuario IAM con
AdministratorAccess"para que no haya problemas de permisos". Las credenciales quedan hardcodeadas en el código, se suben a GitHub. Un bot escanea GitHub, encuentra las keys, las usa para lanzar 500 instancias EC2 minando criptomonedas. Factura de $45,000 en 72 horas. AWS detectó el tráfico anómalo, pero la configuración IAM fue decisión del equipo.💡
💡 El patrón en los tres casos
AWS funcionó exactamente como debía. La infraestructura estuvo disponible y segura. El problema fue siempre en la capa de responsabilidad del cliente: configuración, permisos, actualizaciones. Eso es lo que el modelo de responsabilidad compartida intenta dejar claro desde el inicio.Lo que sí deberías tener siempre activo en tu cuenta
Si entiendes el modelo, sabes que estas configuraciones son tuya — AWS no las activa por ti:
# Controles mínimos que tú debes configurar (AWS no lo hace por ti)
>
> [ ] CloudTrail activado en todas las regiones → quién hizo qué y cuándo
> [ ] MFA en el root account → la cuenta más poderosa
> [ ] MFA en todos los usuarios IAM con consola → acceso humano protegido
> [ ] No usar el root account para operaciones → principio de mínimo privilegio
> [ ] GuardDuty activado → detección de amenazas en tu cuenta
> [ ] AWS Config activado → auditoría de configuración
> [ ] Security Hub activado → panel centralizado de hallazgos
> [ ] Alertas de billing → detectar actividad anómala por costo
> [ ] S3 Block Public Access a nivel de cuenta → evitar buckets accidentalmente públicos
> [ ] VPC Flow Logs activados → visibilidad de tráfico de red
> [ ] Rotación automática de secrets (Secrets Manager) → credenciales que no envejecen
✅
✅ La pregunta que debes hacerte siempre
Antes de asumir que un servicio AWS "ya viene seguro", pregúntate: ¿esto está en la capa de infraestructura o en la capa de configuración? Si es configuración, es tuya. Si no estás seguro, revisa la documentación del servicio en la sección "Security" — AWS siempre documenta qué protege y qué no.Por qué esto importa más allá de la certificación
El modelo de responsabilidad compartida aparece en el examen AWS CCP como pregunta de opción múltiple. Pero en el trabajo real, es la base de cada conversación de seguridad que vas a tener sobre infraestructura en la nube:
Cuando un cliente pregunta "¿está seguro en AWS?" — necesitas saber qué parte de "seguro" puedes garantizar tú y qué parte garantiza AWS.
Cuando haces una auditoría de seguridad — necesitas saber qué controles buscar en la cuenta del cliente vs. qué asumir que AWS ya maneja.
Cuando diseñas una arquitectura — necesitas saber qué servicio te da más control (EC2) vs. cuál te quita responsabilidad operativa (Fargate, RDS).
Cuando responder un incidente en la nube — necesitas saber exactamente dónde buscar: en tu configuración, no en la infraestructura de AWS.
Conclusión
AWS puede ser el proveedor de nube más seguro del mundo y al mismo tiempo alojar miles de cuentas mal configuradas. No hay contradicción. La seguridad de la infraestructura es de AWS. La seguridad de lo que construyes sobre esa infraestructura es tuya.
Entender eso no es opcional si trabajas en la nube. Es el punto de partida. Sin ese entendimiento, no sabes qué revisar, no sabes qué preguntar, y no sabes de quién es la culpa cuando algo sale mal.
⚠️
⚠️ Para recordar siempre
"AWS es responsable de la seguridad DE la nube. Tú eres responsable de la seguridad EN la nube."
Una letra cambia todo. De la nube vs. en la nube. Tatúatelo.Compartir 🐦 Twitter/X 💼 LinkedIn¿Te fue útil?
Mando contenido así cuando tengo algo que vale la pena.
Suscribirse ← Anterior MITRE ATT&CK: el mapa del crimen que todo profesional de seguridad debería conocer Todos los posts → Ver el blog completo byron.lainez © 2026 · Guatemala 🇬🇹
