¿Qué es una auditoría de seguridad AWS?
Una auditoría de seguridad AWS revisa cómo está configurada tu cuenta de nube: quién tiene acceso, qué está expuesto a internet, qué se registra y si tus respaldos sobreviven a un ataque. Se hace con permisos de solo lectura y termina en hallazgos priorizados, cada uno con su corrección y la evidencia de que quedó cerrado.
AWS lo explica con su modelo de responsabilidad compartida. AWS protege la infraestructura que corre sus servicios: es la seguridad «de» la nube. Tú respondes por la seguridad «en» la nube: tus usuarios y permisos, tus datos y su cifrado, el sistema operativo de tus servidores EC2 y sus reglas de firewall. Ninguna configuración por defecto hace ese trabajo por ti.
¿Qué revisa una auditoría de seguridad AWS?
Una revisión seria sigue el orden en que ocurre un ataque: primero la identidad, que es la llave de todo, y al final tu capacidad de recuperarte. Estas son las diez áreas que recorre el módulo de nube de Security OS, con 49 controles en total:
| Área | Qué se revisa | Por qué importa |
|---|---|---|
| Cuenta raíz | MFA activo, que no existan llaves de acceso de la raíz, correo y teléfono de recuperación bajo control | La raíz tiene acceso total, incluida la facturación |
| Identidades y MFA | MFA en cada usuario con contraseña de consola, llaves sin rotar en 90 días, credenciales sin uso en 45 días, políticas con permisos totales | Una llave filtrada es una de las entradas más comunes a una cuenta |
| Detección y registro | CloudTrail multirregión con validación de archivos, GuardDuty, Security Hub y AWS Config encendidos, y alguien que lea sus alertas | Sin registro no hay forma de saber qué pasó |
| Alertas de costo | Presupuestos con aviso de gasto real y pronosticado | Un gasto inesperado puede ser la primera señal de abuso, como minería de criptomonedas |
| Almacenamiento | Bloqueo de acceso público en S3, TLS obligatorio, cifrado por defecto en EBS | Un bucket público expone datos sin que nadie tenga que entrar a nada |
| Bases de datos | RDS sin acceso público, cifrado, respaldos automáticos y protección contra borrado | La base de datos es lo que el atacante quiere llevarse |
| Red | Grupos de seguridad sin 0.0.0.0/0 en puertos de administración (22, 3389), IMDSv2, registros de flujo de VPC | Un puerto de administración abierto es una invitación permanente |
| Secretos | Contraseñas y llaves en Secrets Manager con rotación, no en variables de entorno ni en el código | Un secreto en texto plano se copia junto con el código |
| Respaldo anti-ransomware | Bóveda con AWS Backup Vault Lock, copia en otra cuenta o región, prueba de restauración | Un ransomware intenta borrar primero los respaldos |
| Políticas de organización | AWS Organizations con SCPs que limitan lo que se puede hacer en cada cuenta | Ponen un techo que ni un usuario con permisos de administrador puede rebasar |
Las referencias de cada control son públicas. El CIS AWS Foundations Benchmark reúne las configuraciones mínimas de una cuenta; AWS Security Hub CSPM soporta sus versiones 5.0.0, 3.0.0, 1.4.0 y 1.2.0, y AWS recomienda usar la 5.0.0. El pilar de seguridad de AWS Well-Architected da el marco de diseño, y el estándar AWS Foundational Security Best Practices suma controles por servicio.
Cuatro detalles que suelen pasar desapercibidos
- El historial de eventos de CloudTrail guarda solo los últimos 90 días de eventos de administración. Si no tienes un trail o un almacén de eventos, lo que pasó hace cuatro meses ya no se puede investigar.
- AWS recomienda no crear llaves de acceso para la cuenta raíz y exige MFA en la raíz de todo tipo de cuenta. Una llave raíz vieja dentro de un script es de los hallazgos más graves.
- GuardDuty analiza los eventos de CloudTrail, los registros de flujo de VPC y los registros de DNS para detectar credenciales comprometidas, minería de criptomonedas o robo de datos. Encenderlo no sirve si nadie atiende lo que reporta.
- Las SCPs no otorgan permisos: solo marcan el máximo. Tampoco afectan a la cuenta de administración de la organización, por eso esa cuenta no debe correr aplicaciones.
¿Qué acceso necesita el auditor y cuánto tarda?
Solo lectura. AWS tiene una política administrada, SecurityAudit, pensada para software que audita la configuración de una cuenta: lee metadatos de seguridad y no cambia nada. Security OS trabaja así. Se conecta con un rol de solo lectura que tú creas y quitas cuando quieras, y lee configuraciones y metadatos: quién tiene acceso, qué está abierto, cómo se respalda. No lee el contenido de tus bases de datos ni de tus archivos.
Si alguien te pide credenciales de administrador para «auditar», es una señal de alerta. Corregir es otra fase, con otro permiso, y cada cambio se autoriza por separado.
El tiempo depende del tamaño: cuántas cuentas, cuántas regiones y cuántos recursos tienes, y si usas AWS Organizations. La revisión automática de los controles es la parte rápida. Lo que toma más tiempo es lo que vale: confirmar cada hallazgo, ordenarlo por riesgo real y preparar su corrección sin romper producción. En Security OS acordamos alcance y tiempos antes de empezar, y la primera corrida deja tu línea base.
¿Qué debe entregarte una auditoría de seguridad AWS?
Un PDF con 300 alertas no es una auditoría: es trabajo pendiente. Exige estas cuatro cosas:
- Hallazgos priorizados por riesgo, no ordenados por servicio. Primero lo que permite entrar o borrar, después lo demás.
- Para cada hallazgo, la corrección preparada: qué se cambia, por qué y cómo se revierte si algo falla.
- Un comparativo antes y después, control por control, generado por el mismo motor de auditoría. Sin eso, una mejora de seguridad es una opinión.
- Una línea base para medir la siguiente corrida. Si alguien abre un puerto el martes, te enteras el martes.
AWS es el primer módulo. Si además quieres revisar repositorios, servidores y el código de la aplicación, eso es una auditoría de seguridad informática completa. Y si tienes servidores EC2 o VPS con Linux, la guía de hardening de servidores cubre la parte que AWS deja de tu lado.
¿Cómo hace Security OS la auditoría de AWS?
- Conectar: das acceso de solo lectura a tu cuenta. Ese acceso no puede cambiar nada y lo retiras cuando quieras.
- Auditar: el auditor de nube recorre las diez áreas y registra el estado de cada uno de los 49 controles. Recibes hallazgos priorizados y tu línea base.
- Corregir: el remediador prepara cada corrección con el antes, el cambio y cómo revertirlo. Tú la autorizas, se aplica y queda registrada.
- Vigilar: el motor vuelve a correr la misma auditoría y el analista de alertas traduce lo que reporta la nube a lenguaje humano: qué pasó, quién fue y qué hacer.
Lo que no hacemos también cuenta. Security OS no es un SOC 24/7 con analistas mirando pantallas, no certifica ISO 27001 ni SOC 2 y no hace pentest. Audita, corrige con tu autorización y lo prueba con evidencia, que es justo lo que después te piden en una auditoría de certificación. Para ver qué vulnerabilidades importan esta semana, revisa las alertas de seguridad, o conoce Security OS completo.
Cuéntanos cuántas cuentas y regiones usas. Te respondemos con el alcance del diagnóstico y su precio antes de empezar.
Solicitar diagnóstico de AWSPreguntas frecuentes
¿Qué es una auditoría de seguridad AWS?
Es una revisión de la configuración de tu cuenta de AWS: identidades y MFA, registro y detección, almacenamiento, bases de datos, red, secretos y respaldos. Termina en hallazgos priorizados, cada uno con su corrección y evidencia de cierre.
¿Necesitan acceso de administrador a mi cuenta de AWS?
No. La auditoría corre con un rol de solo lectura, del tipo de la política administrada SecurityAudit. Las correcciones se aplican una por una, con tu autorización, y quedan registradas.
¿AWS no se encarga de la seguridad?
De la seguridad de la nube sí: centros de datos, hardware y virtualización. La seguridad en la nube, es decir tus usuarios, permisos, datos, red y servidores, te toca a ti según el modelo de responsabilidad compartida.
¿Qué es el CIS AWS Foundations Benchmark?
Es un conjunto de configuraciones mínimas de seguridad para cuentas de AWS, publicado por el Center for Internet Security. Security Hub CSPM evalúa las versiones 5.0.0, 3.0.0, 1.4.0 y 1.2.0; AWS recomienda la 5.0.0.
¿Cuánto tarda una auditoría de seguridad AWS?
Depende de cuántas cuentas, regiones y recursos tengas. La revisión automática es rápida; confirmar, priorizar y preparar cada corrección es lo que toma tiempo. Alcance y tiempos se acuerdan antes de empezar.
¿Sirve para ISO 27001 o SOC 2?
Security OS no certifica, pero deja ordenada la evidencia técnica que esas auditorías piden: el estado de cada control antes y después de corregirlo.
¿Qué hago si ya tuve un incidente en AWS?
Actúa rápido: el historial de eventos de CloudTrail solo guarda 90 días. El agente forense de Security OS reconstruye la línea de tiempo y preserva la evidencia antes de que expire.
Fuentes
- AWS: Shared Responsibility Model
- AWS Well-Architected Framework: Security Pillar
- AWS Security Hub CSPM: CIS AWS Foundations Benchmark
- AWS Security Hub CSPM: AWS Foundational Security Best Practices
- AWS IAM: Root user best practices
- AWS CloudTrail: Working with event history
- Amazon GuardDuty: What is GuardDuty
- AWS Backup Vault Lock
- AWS Organizations: Service control policies
- AWS Budgets: Managing your costs
- AWS managed policy: SecurityAudit
Escrita por Samuel Hinojosa y el equipo de seguridad de WITS · Actualizada el 25 oct 2026 · Markdown
