La seguridad en la nube es una responsabilidad compartida, no un blindaje automático.
El espejismo de la seguridad heredada
Existe una creencia peligrosa en los pasillos de muchas empresas: que por el simple hecho de migrar a Amazon Web Services (AWS) o Microsoft Azure, los datos están blindados automáticamente. Es lo que llamo el ‘espejismo de la seguridad heredada’. Si bien es cierto que estos gigantes gastan miles de millones en proteger sus centros de datos físicos, la configuración de lo que vive dentro de ellos es responsabilidad exclusiva del cliente. Según datos recientes de Gartner, hasta el 99% de los fallos de seguridad en la nube hasta 2025 serán culpa del usuario, no del proveedor.
No estamos hablando de ataques sofisticados de estados-nación. La mayoría de las veces, el desastre comienza con un clic mal dado o una política de permisos demasiado generosa. En este análisis, vamos a diseccionar los diez errores de configuración más críticos que están dejando la puerta abierta a los atacantes en las dos plataformas líderes del mercado.
1. Cubetas de S3 y contenedores de Blob con acceso público
Es el error clásico que se niega a morir. En AWS, un bucket de S3 configurado como público permite que cualquier persona con la URL (o que use herramientas de escaneo automatizado) descargue su contenido. En Azure, el acceso anónimo a los contenedores de Blob causa el mismo estrago. A pesar de que ambos proveedores han introducido bloqueos de acceso público por defecto, la necesidad de ‘probar algo rápido’ lleva a los ingenieros a desactivar estas protecciones y, a menudo, olvidan reactivarlas. El resultado: bases de datos enteras de clientes y secretos corporativos expuestos en texto plano.
2. La ausencia de MFA en cuentas con privilegios
Parece básico, pero las estadísticas de 2024 de Microsoft indican que una cantidad alarmante de cuentas de administrador global en Azure AD todavía no tienen habilitada la autenticación de múltiples factores (MFA). En AWS, dejar la cuenta ‘Root’ sin MFA es como dejar las llaves de la caja fuerte puestas en la cerradura. Los atacantes no necesitan hackear sistemas complejos si pueden simplemente robar una contraseña mediante phishing y entrar por la puerta principal con privilegios totales.
3. El principio de ‘máximo privilegio’ en IAM
La gestión de identidades y accesos (IAM) es el verdadero perímetro en la nube. El error común es asignar políticas de ‘AdministratorAccess’ a desarrolladores o servicios que solo necesitan leer un archivo específico. En Azure, esto se manifiesta al asignar roles de ‘Propietario’ o ‘Colaborador’ a nivel de suscripción de forma innecesaria. Esta falta de granularidad significa que, si una sola credencial se ve comprometida, el atacante tiene control total sobre toda la infraestructura, permitiéndole el movimiento lateral y la exfiltración masiva.
4. Grupos de seguridad y NSGs demasiado permisivos
Abrir el puerto 22 (SSH) o el 3389 (RDP) a todo el internet (0.0.0.0/0) es una invitación abierta a ataques de fuerza bruta. Tanto en los Security Groups de AWS como en los Network Security Groups (NSG) de Azure, las reglas de entrada deben ser lo más restrictivas posible. Es preferible usar soluciones como AWS Systems Manager Session Manager o Azure Bastion, que permiten la administración remota sin exponer puertos críticos a la red pública.
5. Secretos y claves de acceso en el código fuente
Es una práctica nefasta pero frecuente: subir claves de acceso de AWS o cadenas de conexión de Azure SQL directamente a repositorios de GitHub o integrarlas en el código de la aplicación. Los bots de los atacantes escanean repositorios públicos en segundos. Una vez que obtienen una clave de acceso de larga duración, pueden operar de forma persistente. La solución siempre debe ser el uso de servicios de gestión de secretos como AWS Secrets Manager o Azure Key Vault.
6. Falta de cifrado en reposo y en tránsito
Aunque el cifrado por defecto es ahora más común, muchas organizaciones todavía gestionan volúmenes de EBS en AWS o discos administrados en Azure que no están cifrados. Peor aún es el tráfico interno que viaja en HTTP plano. Si un atacante logra posicionarse dentro de la red virtual, puede capturar datos sensibles en movimiento. El estándar hoy debe ser cifrar todo, idealmente utilizando llaves gestionadas por el cliente (CMK) para mantener el control soberano sobre los datos.
7. Registro y monitoreo desactivados o ignorados
Si no estás mirando, no sabes que te están robando. Desactivar AWS CloudTrail o no configurar los logs de actividad en Azure es como apagar las cámaras de seguridad. Sin estos registros, es imposible realizar un análisis forense tras un incidente. Además, no basta con generar los logs; es vital configurar alertas automáticas para eventos sospechosos, como la creación de nuevos usuarios con privilegios elevados o cambios en las políticas de red.
8. Desconocimiento del Modelo de Responsabilidad Compartida
Muchos equipos de TI asumen que el proveedor se encarga de los parches del sistema operativo en sus instancias EC2 o máquinas virtuales de Azure. Error. En el modelo IaaS (Infraestructura como Servicio), el parcheo del SO, la configuración del firewall de la instancia y la protección del endpoint son responsabilidad tuya. Ignorar esto deja máquinas vulnerables a exploits conocidos que los atacantes aprovechan para ganar acceso inicial.
9. Exposición de metadatos de la instancia (SSRF)
Los servicios de metadatos de las instancias (como el endpoint 169.254.169.254) son minas de oro para los atacantes que explotan vulnerabilidades de Server-Side Request Forgery (SSRF). Si un atacante puede engañar a tu aplicación para que consulte ese endpoint, puede obtener tokens de seguridad temporales con los permisos de la instancia. En AWS, es crítico migrar a IMDSv2, que requiere una sesión orientada a tokens, y en Azure, asegurar que las identidades gestionadas tengan solo los permisos mínimos necesarios.
10. Huérfanos de red y recursos olvidados
La agilidad de la nube permite crear recursos en segundos, pero a menudo olvidamos borrarlos. Instancias de prueba, bases de datos temporales o snapshots antiguos que quedan ‘huérfanos’ suelen tener configuraciones de seguridad laxas y no reciben parches. Estos recursos olvidados se convierten en puntos de entrada silenciosos para los atacantes, que los utilizan como base de operaciones dentro de tu entorno sin levantar sospechas.
Análisis técnico: La complejidad como enemiga
La raíz de estos problemas no es la negligencia pura, sino la complejidad abrumadora. Un entorno empresarial típico puede tener miles de recursos repartidos en múltiples regiones y cuentas. La ‘deriva de configuración’ ocurre cuando los cambios manuales se acumulan y se alejan de la línea base de seguridad. Por eso, la respuesta no es solo educación, sino automatización. Implementar herramientas de Cloud Security Posture Management (CSPM) es hoy una necesidad, no un lujo. Estas herramientas escanean continuamente el entorno y alertan (o incluso corrigen automáticamente) cuando un bucket se vuelve público o una cuenta pierde su MFA.
Hacia una postura de seguridad resiliente
La seguridad en la nube no es un destino, es un proceso iterativo de vigilancia. Para las empresas que operan en AWS y Azure, el enfoque debe pasar de la confianza ciega a la verificación constante. Adoptar una arquitectura de Zero Trust, donde cada identidad y cada flujo de red sea verificado explícitamente, es el único camino para mitigar los riesgos inherentes a la infraestructura moderna.
Preguntas Frecuentes (FAQs)
¿Es más seguro AWS o Azure para mis datos sensibles?
Ambos proveedores ofrecen niveles de seguridad física y de infraestructura equivalentes y de clase mundial. La seguridad final depende de cómo configures los servicios. AWS suele tener controles más granulares y complejos, mientras que Azure ofrece una integración más nativa con identidades corporativas a través de Entra ID (antes Azure AD). La elección debe basarse en la experiencia de tu equipo técnico.
¿Cómo puedo saber si tengo buckets de S3 expuestos actualmente?
En la consola de AWS, puedes usar el servicio ‘S3 Storage Lens’ o revisar el panel de ‘Block Public Access’ a nivel de cuenta. También existen herramientas de código abierto como ‘Prowler’ que realizan auditorías completas de seguridad siguiendo los benchmarks de CIS y te alertarán sobre cualquier recurso expuesto al público.
¿El cifrado por defecto de los proveedores es suficiente?
Para cumplir con normativas básicas, sí. Sin embargo, para una seguridad robusta, se recomienda usar llaves gestionadas por el cliente (Customer Managed Keys). Esto te permite revocar el acceso a los datos de forma independiente al proveedor y tener un registro de auditoría mucho más detallado sobre quién y cuándo se descifró la información.
