Post actualizado el día octubre 27, 2026 by DeiviSanzPlay
Si acabas de abrir tu primera cuenta de AWS para alojar una web o probar un servicio, hay una verdad incómoda que conviene asumir desde el minuto uno: la seguridad en la nube no viene activada por defecto. AWS te entrega herramientas potentes, pero la configuración inicial es responsabilidad tuya. Esta guía práctica está pensada para quien nunca ha tocado un panel de AWS y quiere evitar los fallos más habituales.
Entiende el modelo de responsabilidad compartida antes de tocar nada
AWS protege la infraestructura física (centros de datos, hipervisores, red troncal). Tú proteges lo que construyes encima: usuarios, permisos, datos, configuraciones de red y cifrado. Según la documentación oficial de AWS, este reparto se conoce como modelo de responsabilidad compartida, y muchos incidentes reales ocurren porque el cliente asume que «Amazon ya lo protege». No es así: un bucket S3 con lectura pública es tu decisión, no un fallo de AWS.
Los cuatro ajustes que deberías hacer en tu primera semana
1. Deja de usar la cuenta raíz para el día a día
El usuario root tiene acceso total e ilimitado. Crea un usuario administrador en IAM, actívalo con MFA (autenticación multifactor) y guarda las credenciales de la raíz en un lugar físico seguro. Un error común entre principiantes es trabajar siempre con la cuenta raíz porque «es la que crearon al registrarse». Si esa contraseña se filtra, el atacante puede borrar toda tu infraestructura o minar criptomonedas con tu factura.
2. Activa MFA también en los usuarios IAM con privilegios
MFA es la medida con mejor relación coste-beneficio. AWS soporta aplicaciones TOTP (Google Authenticator, Authy) y llaves físicas. No lo dejes para después: el panel de Security Hub o el propio IAM te avisa cuando hay usuarios sin MFA, y es una de las primeras comprobaciones que hace cualquier auditor.
3. Aplica el principio de mínimo privilegio desde el principio
No asignes AdministratorAccess a todo el mundo «para que funcione». Empieza con políticas gestionadas limitadas y ajusta según necesidad. Una práctica útil es usar roles en lugar de claves de acceso estáticas para servicios como EC2 o Lambda: las credenciales temporales rotan solas y no acaban en un archivo de texto dentro de un repositorio.
4. Revisa la exposición de S3 y Security Groups
Dos configuraciones causan la mayoría de sustos en cuentas nuevas: buckets S3 con acceso público (a veces por una política mal copiada) y security groups con el puerto 22 o 3389 abierto a 0.0.0.0/0. Usa el bloqueo de acceso público de S3 a nivel de cuenta y restringe los grupos de seguridad a rangos IP concretos o a un bastión. AWS Config y Security Hub pueden alertarte de estas exposiciones, pero no las corrigen por ti.
Un caso real que se repite: la clave de acceso en GitHub
Un patrón que aparece una y otra vez: un desarrollador pega un script con sus claves de AWS en un repositorio público de GitHub para pedir ayuda. En cuestión de minutos, bots que escanean commits buscan exactamente ese patrón y empiezan a lanzar instancias EC2 para minería. La factura llega días después. La solución no es solo borrar el commit: hay que rotar las claves inmediatamente, revisar CloudTrail para ver qué se hizo y activar alertas de gasto. Herramientas como GitGuardian o el propio escaneo de secretos de GitHub ayudan, pero la disciplina de no subir credenciales es la verdadera defensa.
Qué no cubre esta guía (y conviene saberlo)
Esta introducción no sustituye una auditoría ni una arquitectura de seguridad completa. No entra en cifrado con KMS, WAF, GuardDuty, redes privadas con VPC peering o cumplimiento normativo (ISO 27001, ENS, RGPD). Tampoco resuelve la seguridad de las aplicaciones que despliegas: AWS protege la infraestructura, no las vulnerabilidades de tu código. Si manejas datos personales o sanitarios, necesitarás asesoramiento especializado y probablemente un socio certificado.
Rutina mínima de revisión mensual
- Comprobar usuarios IAM sin MFA y claves de acceso antiguas.
- Revisar buckets S3 y grupos de seguridad expuestos.
- Mirar CloudTrail en busca de eventos inusuales (creación de usuarios, cambios de política).
- Configurar alertas de facturación: un pico repentino puede indicar uso no autorizado.
- Activar AWS Security Hub en la región principal para tener un panel único de hallazgos.
Según estudios del sector, una parte importante de las brechas en la nube se debe a configuraciones incorrectas más que a ataques sofisticados. La buena noticia para un principiante es que la mayoría de esos fallos se evitan con los ajustes descritos y un poco de constancia.
Perfiles verificables: Sitio web
Publicado el 27 de October de 2026. Última revisión: 27 de October de 2026.
