En la seguridad de la información, confiar en una sola línea de defensa es riesgoso. Un atacante que logre sortear esa barrera tendría acceso libre a tus recursos. La estrategia de defensa en profundidad (Defense in Depth) consiste en colocar múltiples controles de seguridad en diferentes niveles, de modo que si uno falla, otros siguen protegiendo el sistema.
En AWS, puedes aplicar este principio en varias capas: red, identidad y acceso, protección de datos, seguridad de aplicaciones y monitoreo y respuesta. En este artículo recorremos cada capa, vemos los servicios y configuraciones clave, y te damos una lista de verificación para que revises tu arquitectura.
Capa 1: Seguridad de la red
La red es el perímetro externo de tu entorno. En AWS, la base es la VPC (Virtual Private Cloud) y sus componentes.
- VPC y subredes: Separa tus recursos en subredes públicas y privadas según su necesidad de acceso a Internet.
- Gateways: Usa Internet Gateway solo para subredes públicas; para acceso privado a servicios de AWS, usa VPC Endpoints (Gateway o Interface).
- Tablas de enrutamiento: Controla el flujo de tráfico entre subredes y hacia Internet o conexiones privadas (VPN, Direct Connect).
- Grupos de seguridad (Security Groups): Firewall stateful a nivel de instancia. Aplica el principio de mínimo privilegio: solo permite el tráfico necesario.
- Listas de control de acceso de red (NACLs): Firewall stateless a nivel de subred. Úsalas para bloquear rangos de IP conocidas como maliciosas o para añadir una capa adicional de filtrado.
- AWS WAF y AWS Shield: Protege aplicaciones web contra explotaciones comunes (OWASP Top 10) y ataques DDoS. WAF funciona con Application Load Balancer, API Gateway o CloudFront.
- AWS Network Firewall: Firewall stateful gestionado que puedes insertar en tus VPC para filtrar tráfico entre subredes o hacia Internet con reglas personalizadas (por ejemplo, usando listas de Suricata).
Ejemplo: configurar un Security Group restringido para una instancia web
# Crear un SG que solo permita HTTP y HTTPS desde el balanceador de carga y SSH desde una IP específica de administración aws ec2 create-security-group --group-id sg-0123456789abcdef0 --description "SG para servidores web" --vpc-id vpc-0123456789abcdef0 # Autorizar tráfico HTTP y HTTPS desde el ALB (asumiendo que el ALB tiene el SG sg-alb) aws ec2 authorize-security-group-ingress --group-id sg-0123456789abcdef0 --protocol tcp --port 80 --source-group sg-alb aws ec2 authorize-security-group-ingress --group-id sg-0123456789abcdef0 --protocol tcp --port 443 --source-group sg-alb # Acceso SSH solo desde la IP de la oficina (ejemplo: 203.0.113.0/24) aws ec2 authorize-security-group-ingress --group-id sg-0123456789abcdef0 --protocol tcp --port 22 --cidr 203.0.113.0/24Capa 2: Identidad y acceso (IAM)
Controlar quién puede hacer qué es fundamental. Incluso si un atacante llega a tu red, unos buenos controles IAM pueden limitar el daño.
- Principio de mínimo privilegio: Otorga solo los permisos necesarios para realizar una tarea.
- Roles de IAM: Usa roles para EC2, Lambda, ECS, etc., en lugar de credenciales estáticas.
- Políticas gestionadas y en línea: Prefiere políticas gestionadas de AWS cuando sea posible y revisa los permisos personales.
- MFA (Autenticación multifactor): Obligatorio para usuarios privilegiados y para el usuario raíz.
- IAM Identity Center (AWS SSO): Para acceso federado a múltiples cuentas y aplicaciones.
- Control de acceso a datos: Combina IAM con políticas de bucket (S3), políticas de clave (KMS) y políticas de base de datos (IAM database authentication).
- Rotación de credenciales: Usa Secrets Manager o Parameter Store para almacenar y rotar credenciales de bases de datos, API keys, etc.
Ejemplo: política de IAM de mínimo privilegio para un bucket S3 de lectura
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::mi-bucket-lectura", "arn:aws:s3:::mi-bucket-lectura/*" ] } ] }Capa 3: Protección de datos
Los datos son el activo más valioso. Cómo los almacenas, transmites y controlas el acceso a ellos determina el impacto de una posible brecha.
- Cifrado en reposo: Usa KMS para cifrar EBS, S3 (SSE‑KMS), RDS, etc.
- Cifrado en tránsito: Fuerza HTTPS/TLS en todas las comunicaciones (el listeners de ALB, CloudFront, conexiones a bases de datos).
- Control de acceso a datos: Además de IAM, usa listas de control de acceso (ACLs) y políticas de bucket para S3, y privilegios de base de datos para RDS/DynamoDB.
- Registro y auditoría: Habilita CloudTrail para registrar llamadas a la API, y S3 access logs para solicitudes de objetos.
- Protección contra eliminación accidental: En S3, activa MFA Delete y versionamiento; en RDS, usa snapshots automáticos y manuales.
Ejemplo: forzar cifrado SSE‑KMS en un bucket S3 mediante una política
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyUnencryptedPutObject", "Effect": "Deny", "Principal": "*", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::mi-bucket-seguro/*", "Condition": { "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" } } }, { "Sid": "DenyUnEncryptedBucketCreation", "Effect": "Deny", "Principal": "*", "Action": "s3:CreateBucket", "Resource": "arn:aws:s3:::mi-bucket-seguro", "Condition": { "StringNotEquals": { "s3:x-amz-bucket-server-side-encryption": "aws:kms" } } } ] }Capa 4: Seguridad de aplicaciones y cargas de trabajo
Incluso con una red y permisos seguros, las propias aplicaciones pueden tener vulnerabilidades. Esta capa se centra en reducir la superficie de ataque del software que ejecutas.
- Gestión de parches: Mantén los sistemas operativos y runtimes actualizados (uso de Systems Manager Patch Manager o procesos de CI/CD).
- Escaneo de imágenes de contenedores: Si usas ECR o EKS, escanea imágenes en busca de vulnerabilidades antes de desplegar.
- Principio de menor privilegio en aplicaciones: Ejecuta procesos con usuarios no raíz y limita los permisos de los roles de servicio.
- Web Application Firewall (WAF): Protege aplicaciones web contra inyecciones, cross-site scripting, etc.
- Secret management: Nunca guardes credenciales en código o variables de entorno sin cifrar; usa Secrets Manager o Parameter Store con cifrado KMS.
- Hardening de contenedores y funciones: Usa imágenes mínimas, limita capabilities en containers, y configura VPCs y security groups para funciones Lambda cuando sea necesario.
Ejemplo: política de ECR que solo permite imágenes escaneadas
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": "*", "Action": "ecr:PutImage", "Resource": "arn:aws:ecr:us-east-1:123456789012:repository/my-app", "Condition": { "Null": { "ecr:ScanFindings": "true" } } } ] }Capa 5: Monitoreo, alertas y respuesta a incidentes
Detectar un incidente tan pronto como ocurre reduce significativamente el daño. Esta capa combina recolección de logs, métricas, alarmas y procesos de respuesta.
- AWS CloudTrail: Registra todas las llamadas a la API de AWS. Esencial para auditoría y investigación forense.
- Amazon GuardDuty: Servicio de detección de amenazas basado en aprendizaje de máquina y fuentes de inteligencia de amenazas.
- Amazon Inspector: Evaluación automática de vulnerabilidades de software y configuraciones de red en instancias y contenedores.
- AWS Security Hub: Agrega hallazgos de GuardDuty, Inspector, Macie, y de partners, y los muestra en un panel unificado.
- Amazon CloudWatch y CloudWatch Logs: Métricas y logs de aplicaciones y servicios. Usa filtros de métricas y alarmas para detectar anomalías.
- VPC Flow Logs: Captura información sobre el tráfico IP que entra y sale de las interfaces de red en tu VPC.
- AWS Config: Evalúa la configuración de tus recursos contra reglas deseadas (por ejemplo, que todos los buckets S3 tengan bloqueo de acceso público).
- Respuesta automatizada: Usa Amazon EventBridge (o CloudWatch Events) para desencadenar funciones Lambda o pasos de Step Functions que realicen acciones de contención (por ejemplo, aislar una instancia comprometida).
Ejemplo: alarma de CloudWatch para una API Gateway con alta tasa de errores 5xx
aws cloudwatch put-metric-alarm \ --alarm-name "API-Gateway-High-5xx-Errors" \ --metric-name 5XXError \ --namespace AWS/ApiGateway \ --statistic Sum \ --period 300 \ --threshold 100 \ --comparison-operator GreaterThanThreshold \ --evaluation-periods 2 \ --alarm-actions arn:aws:sns:us-east-1:123456789012:alertas-seguridad \ --dimensions Name=ApiName,Value=mi-api-prodResultado esperado: lista de verificación de defensa en profundidad
Antes de considerar un entorno listo para producción, repasa esta checklist:
- Red: ¿Mis VPCs tienen subredes públicas y privadas adecuadas? ¿Los security groups y NACLs siguen el principio de mínimo privilegio? ¿Uso WAF, Shield y/o Network Firewall donde corresponde?
- Identidad y acceso: ¿Todos los usuarios tienen MFA activado? ¿Los roles y políticas siguen el menor privilegio? ¿Uso IAM Roles para recursos de cómputo en lugar de claves de acceso?
- Protección de datos: ¿Los datos sensibles están cifrados en reposo y en tránsito usando KMS? ¿Los buckets S3 tienen bloqueo de acceso público y versionamiento?
- Seguridad de aplicaciones: ¿Estoy aplicando gestión de parches? ¿Escaneo mis imágenes de contenedor? ¿Uso secretos gestionados?
- Monitoreo y respuesta: ¿CloudTrail está activado en todas las regiones? ¿Tengo GuardDuty y Security Hub habilitados? ¿Tengo alarmas para actividades inusuales (por ejemplo, cambios en grupos de seguridad, llamadas a la API de eliminación)?
- Respuesta y recuperación: ¿Tengo un plan de respuesta a incidentes probado? ¿Mis backups están cifrados y aislados (por ejemplo, en una cuenta diferente o con bloqueo de eliminación)?
Bloque de código: verificar que todos los security groups de una VPC tengan al menos una regla de entrada restringida (no 0.0.0.0/0 para puertos comunes)
# Lista todos los SGs en una VPC y muestra aquellos que permiten SSH (22) desde cualquier IP aws ec2 describe-security-groups --filters Name=vpc-id,Values=vpc-0123456789abcdef0 --query 'SecurityGroups[?IpPermissions[]?contains(IpRanges[?CidrIp==`0.0.0.0/0`].CidrIp, `true`) && contains(ToString(IpPermissions[?FromPort==`22` && ToPort==`22`].IpProtocol), `tcp`)].GroupId' --output textSi el comando devuelve resultados, esos SGs son demasiado permisivos y deberías ajustarlos.
✅ ResultadoEl resultado esperado o un tip extra.Conclusión
La defensa en profundidad en AWS no es una opción; es una necesidad para proteger tus cargas de trabajo frente a amenazas cada vez más sofisticadas. Al aplicar múltiples capas de control — red, identidad, datos, aplicaciones y monitoreo — reduces significativamente la probabilidad de que un atacante logre comprometer tu ambiente y aumentas tu capacidad para detectar y responder a incidentes.
Recuerda que la seguridad es un proceso continuo: revisa periódicamente tus configuraciones, actualiza tus controles y mantente al tanto de los nuevos servicios y características que AWS lanza para mejorar tu postura de seguridad.