El bloque crítico para una consultora. Aquí está la mayor parte de las brechas de seguridad que se ven en cuentas reales de cliente. Mucho énfasis en políticas reutilizables, trazabilidad y respuesta a incidentes. Si haces solo bien este módulo, ya aportas más valor que la media de muchos equipos.
Objetivos de aprendizaje
Diseñar usuarios, grupos, roles y políticas IAM con criterio de mínimo privilegio.
Configurar roles cross-account para acceder a cuentas de cliente sin keys compartidas.
Configurar CloudTrail multi-región con integridad de logs.
Recolectar logs y métricas con CloudWatch y construir dashboards y alarmas útiles.
Aplicar AWS Config para detectar desviaciones de la configuración deseada.
Coordinar parcheo de flotas EC2 con Inspector y Patch Manager.
5.1 IAM: el lenguaje de los permisos
AWS IAM (Identity and Access Management) es el servicio que decide quién puede hacer qué en una cuenta. Todo lo demás depende de él. Es gratis y siempre está activo.
Las cuatro piezas
Concepto
Qué es
Cuándo usarlo
Usuario
Identidad humana o máquina con credenciales propias
Cada vez menos: SSO o roles federados son la forma moderna
Grupo
Conjunto de usuarios con permisos comunes
Para asignar permisos por equipo (devs, ops, finanzas)
Rol
Identidad que se "asume" temporalmente (sin credenciales fijas)
Para servicios (EC2, Lambda), cross-account, federación
Política
JSON que define permisos (Allow/Deny sobre Actions y Resources)
Se asocia a usuarios, grupos o roles
Anatomía de una política IAM
IAM policy — terminal
Una política tiene statements, cada uno con Effect (Allow/Deny), Action (qué se puede hacer), Resource (sobre qué ARN) y opcionalmente Condition (cuándo aplica). Las denegaciones siempre ganan a los permisos.
5.2 Mínimo privilegio en la práctica
Principio: cada identidad debe poder hacer exactamente lo que necesita y nada más. En la teoría todo el mundo está de acuerdo; en la práctica, la mayoría de cuentas reales están llenas de "Resource": "*" y políticas AdministratorAccess mal asignadas.
✗ Anti-patrón frecuente
Asignar AdministratorAccess al usuario de un dev "para no tener problemas". Una credencial filtrada compromete toda la cuenta. Cero auditabilidad fina.
✓ Patrón correcto
Política de permisos del rol justificada por trabajo concreto. Acceso elevado just-in-time con MFA cuando hace falta. Auditable, revocable y delimitado en alcance.
Cómo construir políticas de mínimo privilegio
Empieza permisivo y reduce es un anti-patrón. Empieza vacío y añade lo que las trazas de CloudTrail demuestren que el rol necesita.
Usa IAM Access Analyzer — analiza las trazas y sugiere políticas reales basadas en uso.
Restringe por Condition: solo desde la oficina (aws:SourceIp), solo con MFA, solo a recursos con cierta etiqueta.
Separa políticas reutilizables (managed) por rol: ReadOnly-Network, Deploy-App-Prod, etc.
Evita Resource: "*" salvo en read-only deliberado.
IAM Access Analyzer + CloudTrail es la combinación que más rinde: el primero te dice qué permisos sobran (o faltan); el segundo demuestra qué se ha usado realmente. Revisión trimestral de políticas = higiene básica.
5.3 Roles cross-account: el patrón de consultora
Patrón clave para una consultora con muchos clientes. Cada cliente tiene su cuenta AWS; tú accedes desde una cuenta organizativa propia asumiendo un rol en la cuenta del cliente. Cero keys compartidas, cero contraseñas duplicadas.
Cuenta CONSULTORA (123…) Cuenta CLIENTE-ACME (987…)
───────────────────────── ─────────────────────────
Usuarios IAM o SSO ──→ Rol "AcmeOperator"
(víctor@consultora.com) · Trust: cuenta consultora
· Permisos: lo justo para operar
· MFA obligatoria
· Sesiones de 1h máximo
aws sts assume-role \
--role-arn arn:aws:iam::987...:role/AcmeOperator \
--role-session-name victor-2026-05-20
Las credenciales devueltas son temporales (1h por defecto, configurable). Cada acción queda registrada en el CloudTrail del cliente con tu identidad de origen: trazabilidad completa de quién hizo qué desde qué cuenta.
Beneficio operativo: cuando una persona deja la consultora, basta con revocar su acceso en una cuenta (la consultora) y pierde acceso a todas las cuentas de cliente automáticamente. Ningún proceso de "ir cuenta por cliente a borrar el usuario".
5.4 CloudTrail: la caja negra
CloudTrail registra todas las llamadas a la API AWS que ocurren en la cuenta: quién, cuándo, desde dónde, qué hizo, sobre qué recurso. Es la fuente de verdad para auditoría y respuesta a incidentes.
Configuración mínima en cualquier cuenta
Trail multi-región (un solo trail registra todas las regiones).
Trail de organización si tienes AWS Organizations (un trail registra todas las cuentas).
Log file validation activada (firma criptográfica de la integridad).
Logs en bucket S3 separado, en otra cuenta si es posible, con política que impida borrarlos (compliance / forense).
Alertas en CloudWatch sobre eventos sensibles (creación de IAM, cambios en SG, asume root, etc.).
Sin CloudTrail no hay seguridad real: si pasa algo y no tienes trazas, no sabes qué pasó, quién fue ni si sigue ocurriendo. CloudTrail es lo primero que se configura en una cuenta — antes incluso de empezar a desplegar nada.
5.5 CloudWatch: métricas, logs y alarmas
CloudWatch es el servicio de observabilidad. Recoge métricas (CPU, red, métricas de aplicación), logs (de EC2, Lambda, ALB, lo que sea) y permite crear alarmas y dashboards.
📈 Metrics
Series temporales numéricas. AWS publica las suyas (CPU, latencia, IOPS); tú puedes publicar métricas propias (negocio, KPI).
📜 Logs
Recolección centralizada de logs vía CloudWatch Agent en EC2. Búsqueda con CloudWatch Logs Insights (lenguaje SQL-like).
🔔 Alarms
Umbrales sobre métricas o expresiones. Disparan acciones: SNS (correo, SMS), Auto Scaling, Lambda, Systems Manager.
📊 Dashboards
Paneles personalizables compartibles con el equipo o el cliente. Soportan widgets de métricas y logs.
Las cinco alarmas que toda cuenta de cliente debería tener
Coste anómalo: gasto del mes > X% del esperado (Budgets + alarma).
Login del root: cualquier uso del root dispara alerta inmediata.
Cambios en grupos IAM administrativos: adición de usuarios a grupos privilegiados.
Modificaciones de SG críticos: cambios en los Security Groups de DB o frontends.
EC2 con CPU/Memory saturada sostenida: indicador de incidente o de sub-dimensionamiento.
Practica · empareja necesidad con servicio
Pulsa una necesidad y luego el servicio que la cubre. Después, "Comprobar".
Saber quién borró un bucket S3 ayer a las 3 AM
Lanzar alerta cuando la CPU media de un ASG > 80% durante 15 min
Detectar automáticamente que alguien ha abierto un SG al 0.0.0.0/0
Encontrar EC2 con paquetes vulnerables conocidos (CVE)
CloudTrail
CloudWatch Alarms
AWS Config
Amazon Inspector
5.6 AWS Config: conformidad y deriva
Mientras CloudTrail registra las llamadas a la API, AWS Config evalúa el estado deseado de los recursos. Defines reglas — propias o gestionadas por AWS — y Config te dice qué recursos las cumplen y cuáles no.
Ejemplos de reglas típicas:
s3-bucket-public-read-prohibited — alerta si algún bucket es público.
encrypted-volumes — todos los EBS deben estar cifrados.
mfa-enabled-for-iam-console-access — los usuarios con consola necesitan MFA.
restricted-ssh — ningún SG abre el 22 al 0.0.0.0/0.
Una vez activado, Config envía a CloudWatch eventos de no conformidad — puedes lanzar Lambda para auto-corregir, mandar Slack al equipo de ops, etc.
5.7 Inspector y Patch Manager
Los últimos dos servicios del módulo cubren la pata hardening: detectar vulnerabilidades y mantener la flota EC2 parcheada.
🔍 Amazon Inspector
Escaneo continuo de vulnerabilidades en EC2 (paquetes con CVE) e imágenes de contenedor (ECR). Sin necesidad de instalar nada en la instancia — usa el agente SSM.
🩹 Patch Manager (SSM)
Define baselines de parches (qué se aplica, en qué SO, con qué severidad) y maintenance windows (cuándo). Aplica en lotes, con reintentos y reporte. Coordina parcheo en cientos de instancias sin un script propio.
Combo ganador para una consultora: Inspector descubre las vulnerabilidades del mes, Patch Manager aplica el baseline en la ventana acordada con el cliente, CloudWatch reporta el resultado. Trabajo de parcheo masivo automatizable y auditable.
5.8 El ciclo de respuesta a incidentes
Cuando todo lo anterior detecta algo — una alerta de CloudWatch, un evento sospechoso en CloudTrail, una desviación de Config — entra en juego este ciclo. Lo que distingue a una buena consultora no es no tener incidentes, es responder rápido y bien cuando los hay.
Ciclo de respuesta · cada fase se ilumina por turno
4 · ResolverParchear, restaurar, post-mortemcerrar y aprender
Practica el ciclo en frío. Una vez al trimestre, simula un incidente en tu sandbox: borra un objeto S3 protegido, modifica un SG, asume un rol con MFA fallida. Recorre las 4 fases con cronómetro. La primera vez te lleva una hora; al tercer ensayo, 10 minutos.
Práctica del módulo
Ejercicio 5.1 · Diseña los permisos de un dev en cuenta de cliente
Un desarrollador júnior necesita: leer logs en S3, lanzar y parar instancias en una VPC concreta, ver dashboards de CloudWatch. No debe: tocar IAM, modificar VPC ni borrar volúmenes. Esboza una política con statements Allow/Deny + Condition. Identifica qué no incluirías aunque se usara "Resource":"*".
Ejercicio 5.2 · Plan de observabilidad mínimo
Para una cuenta de cliente recién recibida, lista en orden de prioridad las 5 cosas que activarías el primer día. Justifica.
Sugerencia: 1) MFA en root + auditoría de usuarios; 2) CloudTrail multi-región con log validation; 3) AWS Config reglas mínimas (S3 público, EBS cifrado, MFA); 4) Budgets con alerta al 80%; 5) Alarmas CloudWatch para los 5 patrones del módulo.
Test de comprensión
1. ¿Cuál es la diferencia entre un usuario IAM y un rol IAM?
Son sinónimos.
El usuario tiene credenciales propias permanentes; el rol se asume temporalmente y entrega credenciales de corta duración.
El rol es para humanos y el usuario para servicios.
El rol no tiene políticas asociadas.
Respuesta correcta: B. Los roles son la forma moderna de dar acceso: sin keys permanentes, con sesiones cortas y auditables.
2. En una política IAM, una sentencia Deny y otra Allow para la misma acción coinciden. ¿Qué pasa?
Gana la Allow (suma de permisos).
Gana la Deny: las denegaciones siempre tienen precedencia.
Se pide confirmación al usuario.
Falla la política.
Respuesta correcta: B. Las denegaciones explícitas ganan a cualquier permiso.
3. ¿Qué servicio te dice quién hizo qué llamada a la API ayer a las 3:00?
CloudWatch
AWS Config
CloudTrail
Inspector
Respuesta correcta: C. CloudTrail registra todas las llamadas a la API. Es la fuente de auditoría.
4. Eres consultora y necesitas acceder a la cuenta AWS de un cliente sin compartir credenciales. ¿Qué patrón usas?
Te pasan su contraseña por correo.
Crean un usuario IAM en su cuenta con tus credenciales.
Configuran un rol IAM en su cuenta con trust hacia tu cuenta y MFA, y tú lo asumes vía STS.
Te dan acceso al root.
Respuesta correcta: C. Roles cross-account con STS es el patrón estándar: cero keys compartidas, sesiones cortas, trazabilidad completa.
Resumen del módulo
IAM: usuarios (cada vez menos), grupos, roles (lo moderno) y políticas JSON con Allow/Deny/Condition.
Mínimo privilegio: empieza vacío y añade según uso real; herramientas: IAM Access Analyzer + CloudTrail.
Roles cross-account: el patrón estándar de consultora — sin keys compartidas, sesiones STS temporales.
CloudTrail: multi-región, log validation, bucket en cuenta aparte. Sin él no hay auditoría.
CloudWatch: métricas + logs + alarmas + dashboards. Las 5 alarmas mínimas para cualquier cuenta.
AWS Config: estado deseado y detección de desviaciones. Inspector + Patch Manager para vulnerabilidades y parcheo.
Último módulo: la integración de todo en arquitecturas reales — alta disponibilidad, escalado y control de coste.