Fundamentos de seguridad en AWS: IAM, VPC y el modelo de responsabilidad compartida

El modelo de responsabilidad compartida

La seguridad en AWS opera sobre un principio fundamental que confunde a muchas organizaciones: AWS es responsable de la seguridad de la nube; tú eres responsable de la seguridad en la nube. AWS protege los centros de datos físicos, el hipervisor, la infraestructura de los servicios gestionados y la red subyacente. Tú eres responsable de todo lo que construyes encima: tus datos, tus aplicaciones, tus configuraciones de IAM, tus reglas de grupos de seguridad, tus elecciones de cifrado y tu registro de logs.

Este límite se desplaza según el tipo de servicio:

• IaaS (EC2): tú gestionas el sistema operativo, el entorno de ejecución, la aplicación y los datos
• PaaS (RDS, Lambda): AWS gestiona el sistema operativo y el entorno de ejecución; tú gestionas la aplicación y los datos
• SaaS (Amazon WorkMail): AWS gestiona casi todo; tú gestionas el acceso y los datos

Configurar mal tu lado del límite —un bucket de S3 dejado público, un rol de IAM con permisos excesivos, un grupo de seguridad abierto a 0.0.0.0/0— es tu responsabilidad, por muy segura que sea la infraestructura de AWS.

IAM: el control de seguridad más crítico de AWS

AWS Identity and Access Management (IAM) controla quién puede hacer qué en cada servicio de AWS. Hacer bien IAM es lo más impactante que puedes hacer por la seguridad de AWS.

Protección de la cuenta raíz

La cuenta raíz de AWS tiene acceso sin restricciones a todo y no puede bloquearse mediante políticas. Protégela:

• Activa MFA de hardware en la cuenta raíz inmediatamente después de crear la cuenta
• No crees claves de acceso para la raíz, jamás
• Usa la raíz solo para tareas que la requieran específicamente (facturación, ajustes de la cuenta, cambios en el plan de soporte)
• Configura alertas de facturación a través de CloudWatch para detectar un uso inesperado

Usuarios, roles y políticas de IAM

Para los usuarios humanos, prefiere IAM Identity Center (antes SSO) con identidades federadas de tu directorio corporativo frente a los usuarios de IAM individuales. Para las identidades de máquina (instancias EC2, funciones Lambda, tareas ECS), usa siempre roles de IAM en lugar de claves de acceso codificadas: los roles proporcionan credenciales temporales que rotan automáticamente.

Escribe las políticas aplicando el principio de mínimo privilegio:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::my-app-bucket/*"
  }]
}

Usa IAM Access Analyzer para identificar políticas con permisos excesivos y accesos externos a tus recursos. Ejecuta informes de credenciales con regularidad (aws iam generate-credential-report) para auditar claves de acceso y usuarios sin usar.

Políticas de control de servicios (SCP)

En AWS Organizations, las SCP actúan como límites máximos de permisos en cuentas u OU completas. Úsalas para imponer barreras de seguridad en toda la organización:

• Denegar la desactivación de CloudTrail
• Restringir qué regiones pueden usarse
• Impedir la creación de buckets de S3 públicos
• Exigir MFA para operaciones sensibles

VPC: aislamiento de red en AWS

Una Virtual Private Cloud (VPC) es tu red privada dentro de AWS. Diséñala con la seguridad en mente desde el principio:

Diseño de subredes

Separa los recursos en niveles de subred públicos, privados y de datos:

• Subredes públicas: solo balanceadores de carga y NAT Gateways; nada más
• Subredes privadas: servidores de aplicaciones, funciones Lambda, tareas ECS; sin acceso directo a internet
• Subredes de datos: bases de datos RDS, ElastiCache y otros almacenes de datos; sin ninguna ruta a internet

Los recursos de las subredes privadas alcanzan internet a través de un NAT Gateway (solo para salida). El tráfico entrante de internet solo debería entrar a través de un balanceador de carga en la subred pública.

Grupos de seguridad frente a NACL

Los grupos de seguridad son cortafuegos con estado asociados a recursos individuales: si permites el puerto 443 de entrada, el tráfico de retorno se permite automáticamente. Aplica el principio de mínimo privilegio: cuando sea posible, especifica como origen ID de grupos de seguridad concretos en lugar de rangos de IP.

Las ACL de red (NACL) no tienen estado y se aplican a nivel de subred: deben definirse tanto las reglas de entrada como las de salida. Usa las NACL para controles amplios a nivel de subred y los grupos de seguridad para la granularidad por recurso.

VPC Flow Logs

Activa VPC Flow Logs en todas las subredes y envíalos a CloudWatch Logs o S3. Los flow logs capturan las IP de origen/destino, los puertos, el protocolo y las decisiones de aceptación/rechazo: esenciales para el análisis forense y la detección de anomalías.

Registro y monitorización: la pila de visibilidad de seguridad

• CloudTrail: registra cada llamada a la API de AWS: quién hizo qué, cuándo y desde dónde. Actívalo en todas las regiones, activa la validación de archivos de log y envíalo a un bucket de S3 con una SCP que impida su eliminación. Esto no es negociable.
• AWS Config: registra los cambios de configuración de los recursos de AWS y los evalúa frente a reglas de cumplimiento
• Amazon GuardDuty: detección de amenazas basada en aprendizaje automático que analiza CloudTrail, VPC Flow Logs y logs de DNS para detectar el compromiso de credenciales, el compromiso de instancias y el reconocimiento
• AWS Security Hub: agrega hallazgos de GuardDuty, Config, Inspector y herramientas de terceros en una única consola con puntuación según los benchmarks de CIS

Seguridad de S3

Los buckets de S3 expuestos públicamente siguen siendo una de las causas más comunes de filtraciones de datos en la nube. Aplica a nivel de cuenta:

• Activa S3 Block Public Access a nivel de cuenta: esto anula cualquier ajuste a nivel de bucket
• Activa el cifrado predeterminado (SSE-S3 o SSE-KMS) en todos los buckets
• Activa S3 Object Lock para los buckets que contengan logs de auditoría, para impedir su eliminación
• Usa políticas de bucket para exigir solo HTTPS: aws:SecureTransport: false → Deny
• Audita los permisos de los buckets con regularidad con Macie para el descubrimiento de datos sensibles