Volver al blogCiberseguridad9 min

Hardening de AWS: checklist de seguridad cloud para startups y pymes

Checklist de hardening de AWS para startups y pymes: cuenta root, IAM Identity Center, CloudTrail, GuardDuty, S3, red y backups inmutables, por prioridad.

Hardening de AWS: checklist de seguridad cloud para startups y pymes

Endurecer (hacer hardening de) una cuenta de AWS significa cerrar las configuraciones por defecto o heredadas que un atacante puede aprovechar: proteger la cuenta root, usar inicio de sesión único con MFA en vez de usuarios IAM con llaves permanentes, registrar toda la actividad con CloudTrail, activar detección de amenazas con GuardDuty, bloquear el acceso público a S3 y a las bases de datos, y tener backups que nadie pueda borrar. Este checklist ordena esas tareas en día 1, semana 1 y mes 1 para que una startup o pyme pueda avanzar sin detener el desarrollo.

Qué es el hardening de AWS y por qué es tu responsabilidad

El hardening de AWS es el proceso de configurar identidades, red, almacenamiento, registros y backups de tus cuentas para reducir la superficie de ataque y detectar abusos a tiempo. AWS opera con un modelo de responsabilidad compartida: AWS protege la infraestructura física y los servicios, pero quién tiene acceso, qué está expuesto a internet y cómo se configuran tus recursos es responsabilidad tuya.

En empresas pequeñas los problemas se repiten: la cuenta se creó con el correo personal del fundador, hay access keys de hace años en el portátil de un ex desarrollador, una base de datos quedó pública "para probar" y nadie revisa los logs. Ninguno requiere un ataque sofisticado para ser explotado. Si tu backend corre en AWS (como describimos en backend para apps móviles con Node.js, Firebase y AWS), este checklist aplica directamente.

Identidad y acceso: la base de todo

  • Cuenta root: usa un correo corporativo de grupo (no personal), contraseña larga en un gestor, MFA (idealmente una llave física) y ninguna access key. AWS ya exige MFA para root por defecto, pero tienes que registrarlo. Usa root solo para las pocas tareas que lo requieren.
  • IAM Identity Center (antes AWS SSO): las personas acceden con inicio de sesión único y credenciales temporales, conectado a tu proveedor de identidad (Google Workspace, Microsoft Entra ID u otro) y con MFA obligatorio. Elimina los usuarios IAM con contraseña de consola.
  • Sin llaves de acceso de larga duración: las aplicaciones usan roles de IAM; los pipelines de CI usan OIDC para obtener credenciales temporales (lo explicamos en nuestra guía de DevSecOps en CI/CD). Si alguna llave debe existir, rótala y monitorea su uso.
  • Mínimo privilegio: conjuntos de permisos por función (desarrollo, operaciones, solo lectura, costos) en lugar de AdministratorAccess para todos. IAM Access Analyzer ayuda a detectar accesos externos y permisos sin uso.

Multi-cuenta con AWS Organizations y SCPs

Una sola cuenta para producción, pruebas y experimentos es un riesgo: un error en desarrollo puede afectar a producción y los permisos se mezclan. Con AWS Organizations separas al menos producción, no producción, seguridad/logs y backups. Las Service Control Policies (SCPs) fijan límites que ni un administrador de la cuenta puede saltar, por ejemplo:

  • Impedir desactivar CloudTrail, GuardDuty o AWS Config.
  • Restringir las regiones permitidas a las que realmente usas.
  • Bloquear la salida de una cuenta de la organización.

Organizations también permite gestionar de forma centralizada el acceso root de las cuentas miembro y eliminar sus credenciales root, de modo que solo la cuenta de administración pueda ejecutar tareas privilegiadas.

Registro, detección y postura de seguridad

  • CloudTrail: un trail de organización multirregión que envíe los eventos a un bucket en la cuenta de logs, con validación de integridad y cifrado. Sin esto, después de un incidente no sabrás qué pasó.
  • GuardDuty: detección de amenazas gestionada que analiza actividad de cuentas, red y cargas de trabajo (credenciales usadas desde ubicaciones anómalas, minería de criptomonedas, comunicación con infraestructura maliciosa). Actívalo en todas las cuentas y regiones.
  • AWS Config: inventario y registro histórico de la configuración de tus recursos; es la base para evaluar reglas de cumplimiento.
  • Security Hub y Security Hub CSPM: desde 2025, AWS separó el servicio original, ahora llamado Security Hub CSPM (gestión de postura con estándares como AWS Foundational Security Best Practices y CIS AWS Foundations Benchmark), del nuevo Security Hub, que correlaciona hallazgos de GuardDuty, Inspector, Macie y CSPM para priorizar riesgos. Para una pyme, activar CSPM con el estándar de AWS y el de CIS es una forma rápida de obtener una lista de configuraciones a corregir.

Datos, red y cómputo

  • S3 Block Public Access activado a nivel de cuenta (u organización). Los buckets nuevos ya no son públicos por defecto, pero un cambio de política puede abrirlos; el bloqueo a nivel de cuenta lo impide. Para sitios estáticos, usa CloudFront con acceso privado al bucket.
  • Cifrado con KMS en EBS (cifrado por defecto), RDS, S3 y backups, con rotación de llaves y políticas que limiten quién puede usarlas.
  • Security groups: ninguna regla 0.0.0.0/0 hacia puertos de administración (22, 3389) ni de bases de datos. Para administrar servidores, usa AWS Systems Manager Session Manager en lugar de SSH expuesto.
  • IMDSv2 obligatorio en EC2. Desde 2024 puedes fijarlo como predeterminado a nivel de cuenta por región; reduce el robo de credenciales del rol de la instancia mediante fallas de tipo SSRF.
  • RDS no público, en subredes privadas, con cifrado y actualizaciones menores automáticas.
  • VPC Flow Logs en las VPC de producción para investigar tráfico sospechoso.

Backups que resisten un ataque

Si un atacante obtiene permisos de administrador en tu cuenta, puede borrar instancias, snapshots y buckets. AWS Backup centraliza las copias, y AWS Backup Vault Lock en modo compliance hace que, una vez vencido el periodo de gracia (mínimo tres días), nadie, ni el usuario root ni AWS, pueda borrar los respaldos antes de que termine su retención. Combínalo con copias en una cuenta de backups separada y prueba restauraciones periódicamente. Es la misma lógica que aplicamos frente al ransomware en pymes.

Costos y alertas como señal de seguridad

Una factura de AWS que se dispara de un día para otro suele ser el primer síntoma de credenciales robadas usadas para minar criptomonedas. Configura AWS Budgets con alertas por correo y Cost Anomaly Detection, y envía las alertas de GuardDuty y de uso de la cuenta root a un canal que alguien revise (correo de grupo, Slack o Teams). Una alerta que nadie lee equivale a no tener alerta. Define también quién responde y cómo, con un plan de respuesta a incidentes.

Checklist priorizado: día 1, semana 1, mes 1

CuándoTarea
Día 1MFA en root, eliminar access keys de root, correo de root corporativo
Día 1S3 Block Public Access a nivel de cuenta
Día 1Activar GuardDuty y un trail de CloudTrail multirregión
Día 1AWS Budgets y Cost Anomaly Detection con alertas
Día 1Cerrar 0.0.0.0/0 en puertos 22, 3389 y de bases de datos
Semana 1IAM Identity Center con MFA; eliminar usuarios IAM y llaves sin uso
Semana 1Security Hub CSPM con AWS Foundational Security Best Practices y CIS; AWS Config
Semana 1IMDSv2 por defecto; RDS privado; cifrado por defecto en EBS
Semana 1Alertas de uso de root y de GuardDuty a un canal monitoreado
Mes 1AWS Organizations con cuentas separadas y SCPs de protección
Mes 1AWS Backup con Vault Lock y prueba de restauración
Mes 1OIDC para CI/CD; revisión de mínimo privilegio con Access Analyzer
Mes 1Session Manager en lugar de SSH; VPC Flow Logs

Las referencias para ir más allá son el pilar de seguridad del AWS Well-Architected Framework y el CIS AWS Foundations Benchmark. CIS publica versiones nuevas periódicamente; Security Hub CSPM evalúa automáticamente buena parte de sus controles. Si quieres una revisión externa de tu cuenta frente a estos marcos, es parte de nuestro servicio de ciberseguridad.

Preguntas frecuentes

¿AWS ya es seguro por defecto?

AWS protege la infraestructura física y los servicios, y ha mejorado varios valores por defecto, como buckets S3 privados y MFA exigido para root. Pero la configuración de identidades, permisos, red, registros y backups es responsabilidad del cliente según el modelo de responsabilidad compartida. La mayoría de incidentes en la nube vienen de credenciales filtradas o recursos mal configurados, no de fallas de AWS.

¿Cuánto cuesta activar GuardDuty, Security Hub y CloudTrail?

CloudTrail incluye el historial de eventos de administración sin costo y cobra por trails adicionales y eventos de datos. GuardDuty y Security Hub se cobran según el volumen de eventos y recursos analizados, y GuardDuty ofrece una prueba gratuita de 30 días que muestra el costo estimado. Para cuentas pequeñas el costo suele ser moderado, pero revisa la calculadora de precios de AWS.

¿Qué es el CIS AWS Foundations Benchmark?

Es una guía de configuración segura para cuentas de AWS publicada por el Center for Internet Security, con controles verificables sobre identidad, registros, monitoreo, almacenamiento y red. Es una referencia de la industria para auditorías y se puede evaluar automáticamente con Security Hub CSPM, que hoy admite varias versiones del benchmark.

¿Necesito varias cuentas de AWS si soy una startup pequeña?

Es muy recomendable separar al menos producción del resto. Con AWS Organizations, crear cuentas adicionales no tiene costo propio, y la separación limita el impacto de un error o de credenciales comprometidas en desarrollo. Una cuenta dedicada a logs y otra a backups protegen la evidencia y las copias si la cuenta de producción es comprometida.

¿Cada cuánto debo revisar la seguridad de mi cuenta de AWS?

Los hallazgos de GuardDuty y Security Hub deben revisarse de forma continua, idealmente con alertas automáticas. Una revisión completa de permisos, cuentas y configuraciones conviene al menos cada trimestre, y una auditoría externa o prueba de intrusión cloud una vez al año o tras cambios grandes de arquitectura.

Conclusión

El hardening de AWS no exige un equipo de seguridad dedicado: exige orden. Protege root, mueve a las personas a Identity Center con MFA, elimina llaves permanentes, registra todo con CloudTrail, activa GuardDuty y Security Hub CSPM, bloquea lo público y guarda backups inmutables. Con el checklist de día 1, semana 1 y mes 1 avanzas sin frenar el producto.

En MisterProSoft revisamos tu cuenta de AWS frente al CIS Benchmark y Well-Architected, corregimos configuraciones e implementamos detección y backups. Conoce nuestro servicio de ciberseguridad o agenda una consulta gratuita.

Fuentes y referencias

Artículos Relacionados

¿Sabes qué tan expuesta está tu empresa hoy?

Pentesting de apps y APIs, seguridad de IA, hardening cloud y cumplimiento LOPDP. Te enviamos un alcance con precio cerrado en menos de 48 horas.