Seguridad & Compliance
Seguridad en AWS: buenas prácticas y controles por prioridad
Qué controles de seguridad activar primero en AWS y en qué orden: identidad, trazabilidad, detección, cifrado y barreras preventivas. Metodología SysCu.
Respuesta corta
En AWS se empieza por la identidad y la trazabilidad: usuario root protegido, acceso de las personas con IAM Identity Center y MFA, sin claves de acceso de larga duración, y un trail de CloudTrail de organización guardado en una cuenta de logs aparte. Después se activan la detección y la postura (GuardDuty, Security Hub y AWS Config en todas las cuentas y regiones), el cifrado y el bloqueo del acceso público a los datos, y por último las barreras preventivas (SCPs) y la seguridad dentro del pipeline. El orden importa más que el número de herramientas.
¿Qué parte de la seguridad en AWS te corresponde a ti?
AWS trabaja con un modelo de responsabilidad compartida: protege la infraestructura sobre la que corren sus servicios (centros de datos, hardware, red global) y tú eres responsable de lo que configuras encima: quién tiene acceso y con qué permisos, qué datos se exponen, si se cifran, cómo se parchean las instancias EC2 y qué se registra. Cuanto más gestionado es el servicio (por ejemplo, RDS o Lambda frente a EC2), más parte asume AWS, pero los permisos y los datos siempre son tuyos.
Por eso los problemas que más encontramos al auditar no son fallos de AWS, sino de configuración: permisos más amplios de lo necesario, credenciales expuestas, software sin parchear, datos sin cifrar en tránsito, registros insuficientes y equipos sin un plan de respuesta.
¿Qué riesgos aparecen más al revisar una cuenta AWS?
| Riesgo | Qué puede provocar | Control que lo cierra |
|---|---|---|
| Permisos IAM excesivos | Que una credencial comprometida dé acceso a recursos críticos | Mínimo privilegio, IAM Access Analyzer, SCPs |
| Claves de acceso de larga duración | Acceso no autorizado si acaban en un repositorio, un log o un portátil | IAM Identity Center, roles, Secrets Manager |
| Datos expuestos | Fuga de datos desde buckets S3 o snapshots compartidos | Bloqueo de acceso público de S3, Access Analyzer, Macie |
| Sin registro de actividad | No poder saber qué pasó ni quién lo hizo tras un incidente | CloudTrail de organización en cuenta de logs |
| Software sin parchear | Vulnerabilidades conocidas (CVE) explotables | Amazon Inspector, Systems Manager Patch Manager |
| Sin plan de respuesta | Decisiones improvisadas y más tiempo de exposición | Runbooks, contactos de seguridad, simulacros |
¿Por dónde empiezo? Controles de seguridad en AWS por prioridad
Este es el orden que seguimos. Cada bloque se activa en todas las cuentas y regiones antes de pasar al siguiente: un control básico activo en todas partes protege más que diez a medias.
| Prioridad | Control | Servicio AWS | Por qué va aquí |
|---|---|---|---|
| 1. Primero | Usuario root con MFA, sin claves de acceso y sin uso diario | IAM, AWS Organizations | Es la credencial con más poder de la cuenta |
| 1. Primero | Acceso de personas con identidad centralizada, MFA y permisos por rol | IAM Identity Center | Elimina usuarios IAM con claves que nadie rota |
| 1. Primero | Registro de actividad en todas las regiones, con validación de integridad | CloudTrail (trail de organización) | Sin registro no hay detección ni análisis posterior |
| 1. Primero | Bloqueo del acceso público a S3 a nivel de cuenta | S3 Block Public Access | Evita la exposición accidental de datos |
| 2. Después | Detección de amenazas con administrador delegado | Amazon GuardDuty | Avisa de credenciales usadas de forma anómala o recursos comprometidos |
| 2. Después | Postura frente a un estándar y registro de configuración | Security Hub, AWS Config | Convierte las buenas prácticas en controles medibles |
| 2. Después | Revisión de accesos externos y permisos sin usar | IAM Access Analyzer | Aplica el mínimo privilegio con datos, no a ojo |
| 2. Después | Cifrado en reposo (EBS por defecto, claves propias para datos sensibles) y TLS en tránsito | AWS KMS, ACM | Protege los datos aunque falle otro control |
| 2. Después | Secretos fuera del código y escaneo de vulnerabilidades | Secrets Manager, Amazon Inspector | Cierra las dos vías de entrada más habituales |
| 3. Continuo | Barreras preventivas comunes a todas las cuentas | SCPs, AWS Control Tower | Impiden configuraciones peligrosas en lugar de detectarlas |
| 3. Continuo | Seguridad dentro del pipeline CI/CD | SAST, SCA, escaneo de secretos e imágenes | El fallo se detecta en el commit, no en la siguiente auditoría |
| 3. Continuo | Copias en otra cuenta, pruebas de restauración y runbooks de incidentes | AWS Backup | Asegura que puedes recuperarte, no solo detectar |
Identidad y acceso
El usuario root solo debe usarse para las pocas tareas que lo exigen: MFA activado, sin claves de acceso y con el correo asociado bajo control. Si usas AWS Organizations, el acceso root de las cuentas miembro se puede gestionar de forma centralizada y eliminar sus credenciales. Las personas entran por IAM Identity Center con MFA y conjuntos de permisos por función; las aplicaciones usan roles, nunca claves estáticas en el código.
Trazabilidad, detección y postura
El trail de CloudTrail de organización cubre todas las cuentas y regiones y se guarda en una cuenta de logs a la que los administradores de producción no pueden escribir ni borrar. Sobre esa base, GuardDuty detecta actividad sospechosa y Security Hub evalúa la configuración frente a AWS Foundational Security Best Practices o CIS AWS Foundations Benchmark, apoyándose en AWS Config. GuardDuty y Security Hub se gestionan desde una cuenta de administrador delegado, para ver todas las cuentas en un solo sitio.
Datos y cifrado
Los buckets S3 nuevos ya nacen con el acceso público bloqueado y cifrado por defecto, pero las cuentas antiguas pueden arrastrar excepciones: el bloqueo a nivel de cuenta las cierra todas. En EBS el cifrado por defecto es un ajuste por región que hay que activar. Para datos sensibles conviene usar claves de KMS gestionadas por el cliente, que permiten controlar quién puede descifrar y dejan registro de cada uso.
Barreras preventivas
Las SCPs de AWS Organizations limitan lo que se puede hacer en las cuentas miembro, por ejemplo usar regiones no aprobadas o desactivar CloudTrail y GuardDuty. No conceden permisos, solo los acotan, y no se aplican a la cuenta de administración, por lo que en ella no deben correr cargas de trabajo. Si la estructura multicuenta empieza a crecer, AWS Control Tower automatiza esta base; en cuándo conviene una Landing Zone explicamos cuándo compensa y cuándo es excesivo.
¿Sabes en qué punto de esta tabla está tu cuenta AWS?
Sesión de 30 minutos para entender tu infraestructura y, en 24h, un informe con mapa de costes, riesgos y quick wins priorizadas.
Solicitar diagnóstico gratuito¿Qué errores son habituales al aplicar estas buenas prácticas?
- Activar GuardDuty o Security Hub solo en la región principal. Una credencial filtrada se puede usar en cualquier región habilitada; la detección tiene que estar en todas.
- Guardar los logs en la misma cuenta que vigilan. Quien compromete la cuenta puede borrar el rastro. La cuenta de logs va aparte y con acceso restringido.
- Confiar en que una SCP «da» permisos. Solo los limita; el permiso efectivo sigue dependiendo de las políticas IAM.
- Mirar el panel de Security Hub sin dueño. Un hallazgo sin responsable ni plazo no se corrige. Cada control necesita alguien que lo atienda.
- Tener copias de seguridad que nunca se han restaurado. Hasta que no se prueba la restauración, no se sabe si sirven.
¿Cómo se lleva la seguridad al pipeline (DevSecOps)?
Auditar una vez detecta lo que hay hoy; meter los mismos controles en el flujo de entrega evita que vuelva a aparecer. En la práctica son cuatro piezas: análisis estático (SAST) y de dependencias (SCA) con escaneo de secretos en cada commit, escaneo de imágenes de contenedor antes de desplegar, políticas como código que hacen fallar el despliegue si incumple, y evidencias generadas por el propio pipeline. En el caso de la startup SaaS integramos análisis estático con SonarQube en cada commit, con aprobación y rollback automático antes de producción. El detalle técnico está en DevSecOps en GitLab + AWS.
¿Cómo lo aplica SysCu?
Trabajamos en tres fases, sobre tu cuenta actual y sin rehacerla:
- Descubrir: inventario de activos, revisión de accesos, superficie de ataque y análisis de brecha frente al marco que necesites (ISO 27001, RGPD, SOC 2 o ENS).
- Corregir: remediación ordenada por riesgo, empezando por los controles de mayor impacto y menor complejidad.
- Vigilar: alertas definidas, runbooks de respuesta y revisiones periódicas de la postura.
En el primer mes eso se traduce en: semana 1, arranque e inventario de activos críticos; semana 2, análisis de brecha; semana 3, plan de remediación priorizado; semana 4, primeros quick wins aplicados. Recibes un informe ejecutivo con mapa de riesgos, un plan de remediación priorizado por CVSS, las configuraciones de hardening documentadas y un panel de postura de seguridad. SysCu es AWS Partner y las certificaciones AWS del equipo se pueden verificar en Credly.
¿Cuánto cuesta y cómo se contrata?
Los controles de seguridad y el cumplimiento van dentro de DevOps Gestionado, desde 1.790€/mes sin IVA, con cuota fija y sin permanencia. Es el precio base para una infraestructura típica de pyme; más cuentas, Kubernetes, cumplimiento normativo o guardias 24/7 amplían la cuota, y el precio exacto se fija por escrito tras el diagnóstico. Si solo necesitas una auditoría puntual, se presupuesta como proyecto según el alcance: una auditoría completa de infraestructura cloud suele llevar de 3 a 4 semanas y el informe se entrega en los 5 días siguientes al cierre. Tienes el detalle en Seguridad & Compliance y en precios.
Comprobación rápida: diez preguntas sobre tu cuenta AWS
Si alguna respuesta es «no» o «no lo sé», ahí está tu siguiente tarea:
- ¿El usuario root tiene MFA y ninguna clave de acceso?
- ¿Las personas entran con IAM Identity Center y MFA, sin usuarios IAM con claves?
- ¿Hay un trail de CloudTrail que cubra todas las cuentas y regiones, guardado en otra cuenta?
- ¿El bloqueo de acceso público de S3 está activo a nivel de cuenta?
- ¿GuardDuty está activo en todas las cuentas y regiones?
- ¿Security Hub evalúa la cuenta frente a un estándar y alguien revisa los hallazgos?
- ¿El cifrado por defecto de EBS está activado en las regiones que usas?
- ¿Los secretos viven en Secrets Manager y no en el código ni en variables del pipeline?
- ¿Has restaurado alguna copia de seguridad en los últimos meses?
- ¿Existe un runbook escrito para una credencial filtrada?
Para una revisión más completa, con controles CIS, identidades, cifrado y plan de remediación, sigue la checklist de auditoría de seguridad cloud en AWS.
Validación técnica y evidencia recomendada
Para que este enfoque sea defendible ante dirección y equipos técnicos, conviene acompañar la implementación con pruebas repetibles, métricas comparables y un registro claro de decisiones.
Pruebas técnicas mínimas
- Escaneo de IaC, dependencias y secretos en pipeline antes de deploy.
- Validación de controles de acceso (mínimo privilegio y rotación).
- Prueba de respuesta a incidente con runbook y tiempos medidos.
- Revisión de controles críticos contra benchmark (CIS/ISO/NIST).
Protocolo de validación reproducible
| Fase | Objetivo | Método | Criterio de aceptación |
|---|---|---|---|
| Baseline | Conocer exposición real y deuda de seguridad | Inventario de activos + matriz de criticidad | Cobertura completa en sistemas críticos |
| Hipótesis | Priorizar riesgos con impacto de negocio | Ranking por probabilidad, impacto y coste de remediación | Backlog con SLA de cierre por severidad |
| Validación | Reducir superficie de ataque medible | Aplicar controles y repetir escaneo/pentest | Sin críticos abiertos y reducción de altos |
| Escalado | Convertir seguridad en capacidad continua | Policy as code en pipeline y auditoría periódica | Controles automáticos antes de deploy |
Datos que debes conservar como evidencia
| Métrica | Herramienta | Cadencia | Objetivo |
|---|---|---|---|
| Vulnerabilidades críticas abiertas | SAST/DAST/SCA | Diario | 0 en producción |
| Cobertura de controles | Security Hub / auditoría | Semanal | >= 85% |
| Tiempo de remediación | Ticketing | Semanal | < SLA acordado |
| Excepciones vigentes | Risk register | Semanal | Con fecha de cierre |
Dashboard mínimo recomendado
| Panel | Fuente | Actualización | Umbral operativo |
|---|---|---|---|
| Estado de vulnerabilidades | SAST/DAST/SCA | Diario | 0 críticas abiertas en producción |
| Cobertura IAM | Cloud IAM analyzer | Semanal | Sin permisos admin sin justificación |
| Cumplimiento base | CIS/ISO/NIST checks | Semanal | >= 85% en controles prioritarios |
| Excepciones y deuda | Risk register | Semanal | Todas con fecha y owner |
Curva de madurez esperada (referencial)
Esta visualización sirve como referencia operativa para 90 días. Debe ajustarse con tus datos reales, complejidad técnica y contexto de negocio.
Superficie de ataque y activos críticos identificados.
Controles prioritarios y cierres de críticos.
Remediación consistente y menor deuda crítica.
Controles automatizados en pipeline y operación.
Riesgos que invalidan resultados
- Convertir controles en checklist sin conexión con riesgo real.
- Abrir excepciones sin vencimiento y acumular deuda invisible.
- Separar seguridad de despliegue y detectar tarde los defectos.
- No practicar respuesta a incidentes antes de un evento real.
Recomendaciones de implementación real
- Evitar excepciones permanentes: toda excepción debe caducar.
- Conectar riesgo técnico con impacto de negocio para priorizar mejor.
- Automatizar cumplimiento en despliegue, no solo en auditorías puntuales.
- Versionar políticas y registrar cambios para trazabilidad completa.
Preguntas frecuentes que suele hacer un equipo técnico
¿Por dónde empezar si hay mucha deuda de seguridad?
Por activos críticos y vectores de ataque más probables. Prioriza identidad, secretos, exposición pública y dependencias vulnerables.
¿Cómo equilibrar cumplimiento y velocidad de entrega?
Moviendo controles al pipeline con policy as code y aprobaciones basadas en riesgo, no en burocracia manual.
¿Cada cuánto revisar controles de seguridad?
Los controles críticos deben revisarse de forma continua (diaria/semanal) y formalizar una revisión de gobierno al menos mensual.
Preguntas frecuentes
¿Cuáles son las buenas prácticas de seguridad más importantes en AWS?
Por orden: proteger el usuario root (MFA y sin claves de acceso), dar acceso a las personas con IAM Identity Center y MFA en lugar de usuarios IAM con claves de larga duración, registrar toda la actividad con un trail de CloudTrail de organización guardado en una cuenta de logs separada y bloquear el acceso público a S3 a nivel de cuenta. Después vienen la detección (GuardDuty), la postura (Security Hub y AWS Config), el cifrado y, por último, las barreras preventivas con SCPs y la seguridad dentro del pipeline.
¿GuardDuty, Security Hub y AWS Config hacen lo mismo?
No, se complementan. GuardDuty detecta actividad sospechosa analizando eventos de CloudTrail, registros de flujo de VPC y consultas DNS. AWS Config registra la configuración de los recursos y sus cambios, y la evalúa con reglas. Security Hub compara la configuración con estándares como AWS Foundational Security Best Practices o CIS AWS Foundations Benchmark y centraliza los hallazgos; para la mayoría de sus controles necesita que AWS Config esté registrando.
¿Una pyme necesita AWS Organizations y varias cuentas?
No es obligatorio, pero separar producción, entornos no productivos y una cuenta de logs y seguridad limita el alcance de un error o de una credencial filtrada, y permite aplicar SCPs como barrera común. Con pocas cargas basta una estructura sencilla; AWS Control Tower compensa cuando el número de cuentas y equipos empieza a crecer.
¿Aplicar estas buenas prácticas me certifica en ISO 27001, ENS o RGPD?
No. Los controles técnicos de AWS son una parte del cumplimiento, pero ISO 27001 o ENS exigen también políticas, procesos y evidencias, y la certificación la decide un organismo certificador acreditado, así que nadie puede garantizarla. Lo que sí se puede hacer es llegar a la auditoría con los controles implantados y las evidencias recopiladas.
¿Cuánto cuesta implantar la seguridad en AWS con SysCu?
Los controles de seguridad y el cumplimiento van dentro del plan DevOps Gestionado, desde 1.790€/mes sin IVA y sin permanencia, como cuota fija mensual para una infraestructura típica de pyme. Más cuentas, Kubernetes, cumplimiento normativo o guardias 24/7 amplían la cuota. Una auditoría suelta se presupuesta como proyecto según el alcance. El primer paso es un diagnóstico gratuito: sesión de 30 minutos e informe en 24h.
¿Cada cuánto hay que revisar la seguridad de una cuenta AWS?
La postura se vigila de forma continua con Security Hub, AWS Config y GuardDuty, que avisan cuando algo se desvía. Además conviene una revisión completa después de cada cambio importante: una migración, cuentas nuevas, un incidente o un requisito normativo nuevo.