Los 10 errores de configuración cloud más peligrosos en AWS y Azure

Cada semana aparecen nuevas brechas de seguridad en organizaciones de todos los tamaños, y la causa número uno no son los ataques sofisticados de día cero: son errores de configuración en entornos cloud. Según múltiples informes de la industria, más del 80% de las brechas en la nube se deben a configuraciones incorrectas, no a vulnerabilidades en la plataforma. En este artículo analizamos los 10 errores más peligrosos que encontramos recurrentemente en auditorías de AWS y Azure, con ejemplos reales, el impacto que pueden tener y cómo prevenirlos.

Por qué la configuración cloud es el nuevo perímetro

El modelo de seguridad tradicional se basaba en proteger el perímetro de la red: firewalls, DMZ, VPNs. En el mundo cloud, ese perímetro se ha disuelto. Los recursos se despliegan con un clic, las APIs están expuestas a Internet por defecto y un solo error de configuración puede dejar expuestos terabytes de datos sensibles al mundo entero.

El modelo de responsabilidad compartida es el concepto fundamental que toda organización debe entender antes de migrar a la nube. AWS, Azure y Google Cloud son responsables de la seguridad de la nube (infraestructura física, hipervisores, red global), pero el cliente es responsable de la seguridad en la nube (configuración de servicios, gestión de accesos, cifrado de datos, segmentación de red). Este matiz es crítico: si dejas un bucket S3 público o configuras un Security Group que permite todo el tráfico, la responsabilidad es enteramente tuya.

El problema se agrava con la velocidad de despliegue. En un centro de datos tradicional, aprovisionar un servidor llevaba semanas y pasaba por múltiples revisiones. En la nube, un desarrollador puede desplegar una instancia de base de datos expuesta a Internet en minutos, sin que seguridad se entere. La agilidad que hace atractiva la nube es también su mayor riesgo si no se acompaña de controles adecuados.

Los 10 errores más peligrosos

1. Buckets S3 y Blob Storage públicos

Este es probablemente el error de configuración cloud más mediático. Un bucket de Amazon S3 o un contenedor de Azure Blob Storage configurado con acceso público permite que cualquier persona en Internet pueda listar y descargar su contenido sin autenticación.

El caso más conocido es el de Capital One en 2019, donde un error de configuración en un WAF permitió a un atacante acceder a un bucket S3 con datos de más de 100 millones de clientes y solicitantes de tarjetas de crédito. Pero no es un caso aislado: Twitch, Accenture, Verizon y decenas de organismos gubernamentales han sufrido exposiciones similares.

Cómo prevenirlo: Activa S3 Block Public Access a nivel de cuenta. En Azure, desactiva el acceso público anónimo en las cuentas de almacenamiento. Usa AWS Config o Azure Policy para detectar y remediar automáticamente cualquier recurso de almacenamiento público. Implementa políticas de bucket que restrinjan explícitamente el acceso.

2. Políticas IAM excesivamente permisivas

La gestión de identidades y accesos es la piedra angular de la seguridad cloud, y sin embargo es donde más atajos se toman. Políticas con "Effect": "Allow", "Action": "*", "Resource": "*" otorgan permisos de administrador total sobre todos los recursos de la cuenta. Es el equivalente a dar las llaves maestras del edificio a todos los empleados.

Hemos visto en auditorías cuentas de servicio de aplicaciones con permisos de administrador completo cuando solo necesitaban leer de una tabla de DynamoDB. El principio de mínimo privilegio se conoce ampliamente pero se aplica con poca disciplina.

Cómo prevenirlo: Implementa políticas IAM granulares basadas en el principio de mínimo privilegio. Usa IAM Access Analyzer en AWS o Azure AD Privileged Identity Management para identificar permisos no utilizados. Revisa periódicamente las políticas y elimina los permisos innecesarios. Nunca utilices la cuenta root para operaciones cotidianas.

3. Security Groups y NSGs sin restricción

Los Security Groups de AWS y los Network Security Groups (NSG) de Azure son el firewall virtual de tus instancias. Un error frecuente es crear reglas que permiten tráfico entrante desde 0.0.0.0/0 (cualquier IP de Internet) en todos los puertos o en puertos sensibles como SSH (22), RDP (3389) o bases de datos (3306, 5432, 1433).

Este error convierte tus instancias en objetivos directos para escáneres automáticos que rastrean Internet continuamente buscando servicios expuestos. Un servidor RDP expuesto a Internet sin protección adicional puede ser comprometido en cuestión de horas mediante ataques de fuerza bruta.

Cómo prevenirlo: Restringe los Security Groups y NSGs al rango mínimo de IPs necesario. Usa bastion hosts o soluciones de acceso como AWS Systems Manager Session Manager o Azure Bastion para acceder a instancias sin exponer puertos de gestión. Implementa reglas automáticas que detecten y cierren Security Groups excesivamente abiertos.

4. Logging y monitorización desactivados

No puedes proteger lo que no puedes ver. Desactivar CloudTrail en AWS, Azure Monitor o los logs de diagnóstico en Azure elimina la capacidad de detectar actividad sospechosa, investigar incidentes y cumplir con requisitos regulatorios.

Hemos encontrado organizaciones donde CloudTrail estaba desactivado en varias regiones, dejando puntos ciegos que un atacante podría aprovechar para operar sin ser detectado. En otros casos, los logs estaban activados pero no se enviaban a ningún sistema de análisis, acumulando terabytes de datos que nadie revisaba.

Cómo prevenirlo: Activa CloudTrail en todas las regiones y configúralo para enviar logs a un bucket S3 centralizado con protección contra eliminación. En Azure, activa los logs de diagnóstico para todos los recursos críticos y envíalos a un Log Analytics Workspace. Implementa alertas para eventos de alto riesgo (cambios en IAM, accesos desde IPs inusuales, eliminación de recursos). Considera un servicio de ciberseguridad gestionada que monitorice tu entorno cloud 24/7.

5. Secretos hardcodeados en el código

API keys, contraseñas de bases de datos, tokens de acceso y certificados privados embebidos directamente en el código fuente, archivos de configuración o variables de entorno visibles. Es uno de los errores más comunes y más fácilmente explotables.

Un estudio de GitGuardian reveló que en 2023 se detectaron más de 12 millones de secretos expuestos en repositorios públicos de GitHub. Pero el problema no se limita a repos públicos: los repositorios privados también se comprometen, y un solo secreto filtrado puede dar acceso completo a la infraestructura cloud.

Cómo prevenirlo: Usa AWS Secrets Manager, Azure Key Vault o HashiCorp Vault para gestionar todos los secretos. Implementa herramientas de escaneo de secretos en el pipeline CI/CD (git-secrets, truffleHog, GitLeaks). Rota los secretos periódicamente y configura alertas para detectar su exposición. Nunca almacenes credenciales en el código, en archivos .env commiteados o en variables de entorno de texto plano.

6. Cifrado desactivado en reposo y tránsito

Muchos servicios cloud no activan el cifrado por defecto, o permiten desactivarlo. Bases de datos RDS sin cifrado, volúmenes EBS sin protección, comunicaciones HTTP sin TLS entre servicios internos. Si un atacante obtiene acceso a los datos, la ausencia de cifrado significa que puede leerlos directamente.

El cifrado en reposo protege contra el acceso físico no autorizado y contra ataques que comprometan el almacenamiento. El cifrado en tránsito protege contra la interceptación de comunicaciones entre servicios.

Cómo prevenirlo: Activa el cifrado por defecto en todos los servicios que lo soporten: EBS, RDS, S3 (SSE), Azure Storage, Azure SQL. Fuerza HTTPS en todos los endpoints y usa TLS 1.2 o superior para comunicaciones entre servicios. Implementa políticas que impidan la creación de recursos sin cifrado.

7. MFA no habilitado en cuentas root y de administrador

La cuenta root de AWS o el administrador global de Azure AD son las cuentas más poderosas de tu entorno cloud. Si un atacante compromete estas credenciales sin MFA, tiene control total sobre toda la infraestructura, la facturación y los datos. Es el mayor punto único de fallo en cualquier entorno cloud.

A pesar de que todos los proveedores cloud recomiendan enfáticamente activar MFA, seguimos encontrando organizaciones donde la cuenta root no tiene segundo factor de autenticación configurado.

Cómo prevenirlo: Activa MFA de hardware (YubiKey o similar) en la cuenta root de AWS. Habilita Azure AD MFA para todos los administradores globales. No uses la cuenta root para operaciones diarias; crea cuentas de administrador individuales con MFA. Configura alertas para cualquier uso de la cuenta root.

8. Snapshots y backups públicos

Las AMIs (Amazon Machine Images), snapshots de EBS y snapshots de RDS pueden compartirse públicamente, haciéndolos accesibles a cualquier cuenta de AWS. Lo mismo ocurre con los snapshots de discos y bases de datos en Azure. Un snapshot público puede contener datos de producción, credenciales, claves privadas y toda la configuración del sistema.

En 2020, investigadores de Cyble descubrieron miles de snapshots de EBS públicos conteniendo datos sensibles de empresas de todo el mundo, incluyendo credenciales de bases de datos, tokens de API y datos personales.

Cómo prevenirlo: Audita regularmente los permisos de tus snapshots y AMIs. Usa AWS Config con la regla ebs-snapshot-public-restorable-check para detectar snapshots públicos. En Azure, revisa los permisos de los discos gestionados y snapshots. Implementa políticas de Service Control Policies (SCPs) en AWS Organizations que impidan compartir snapshots públicamente.

9. Funciones Lambda y Azure Functions con permisos excesivos

Las funciones serverless son fantásticas para la agilidad del desarrollo, pero frecuentemente se configuran con roles IAM excesivamente amplios. Una función Lambda que solo necesita escribir en una cola SQS y leer de una tabla DynamoDB no debería tener permisos para acceder a S3, EC2 o IAM.

El riesgo es que si un atacante explota una vulnerabilidad en la función (inyección de código, deserialización insegura), hereda todos los permisos del rol asignado. Cuanto más amplios sean los permisos, mayor es el radio de explosión del compromiso.

Cómo prevenirlo: Crea roles IAM específicos para cada función con los permisos mínimos necesarios. Usa herramientas como AWS IAM Access Analyzer o Prowler para identificar funciones con permisos excesivos. Implementa revisiones de seguridad del código serverless antes del despliegue. Limita los tiempos de ejecución y los recursos asignados a cada función.

10. Falta de segmentación de red

Desplegar todos los recursos en una única VPC sin subnets diferenciadas, sin NACLs y sin controles de peering equivale a tener una red plana donde cualquier recurso comprometido puede comunicarse libremente con todos los demás. Un atacante que compromete una instancia web puede moverse lateralmente hasta alcanzar la base de datos de producción sin encontrar ningún obstáculo.

Cómo prevenirlo: Diseña tu arquitectura de red con subnets públicas y privadas claramente separadas. Coloca las bases de datos y servicios backend en subnets privadas sin acceso directo a Internet. Usa VPC Peering o AWS Transit Gateway con controles estrictos para la comunicación entre VPCs. Implementa NACLs como capa adicional de defensa sobre los Security Groups. En Azure, usa Virtual Networks con subnets segmentadas y NSGs por subnet.

Cómo detectar estos errores

Identificar errores de configuración en entornos cloud requiere una combinación de herramientas automatizadas y revisiones manuales especializadas.

AWS Config y Azure Policy permiten definir reglas de conformidad que evalúan continuamente la configuración de tus recursos y alertan cuando se desvían de los estándares definidos. Son herramientas nativas y deberían ser el punto de partida mínimo.

Cloud Security Posture Management (CSPM) engloba soluciones como AWS Security Hub, Microsoft Defender for Cloud, Prowler, ScoutSuite o Prisma Cloud que proporcionan una visión centralizada del estado de seguridad de tu entorno cloud, identificando misconfigurations, vulnerabilidades y desviaciones de cumplimiento.

Auditorías de seguridad cloud periódicas realizadas por equipos especializados como nuestro equipo de auditoría cloud aportan una perspectiva externa que complementa las herramientas automatizadas. Un auditor experimentado identifica riesgos contextuales, evalúa la arquitectura en su conjunto y descubre problemas que las herramientas automatizadas no detectan.

Framework de prevención

Detectar errores está bien, pero prevenirlos es mejor. Un framework de prevención robusto se construye sobre cuatro pilares.

Mínimo privilegio como cultura. No se trata solo de una política IAM: es una mentalidad que debe impregnar cada decisión de diseño. Cada recurso, cada función, cada usuario debe tener exactamente los permisos que necesita y nada más. Esto requiere disciplina y revisión continua.

Infraestructura como código (IaC). Terraform, CloudFormation o Bicep permiten definir la infraestructura de forma declarativa, versionable y auditable. Combinados con herramientas de análisis estático como Checkov, tfsec o Terrascan, permiten detectar errores de configuración antes de que lleguen a producción. La infraestructura no debería desplegarse nunca manualmente.

Seguridad en el pipeline CI/CD. Integra comprobaciones de seguridad en cada fase del pipeline de despliegue: escaneo de secretos en el código, análisis estático de IaC, validación de políticas y pruebas de seguridad automáticas. Si estás construyendo un pipeline seguro, nuestro servicio de SSDLC y DevSecOps puede ayudarte a integrarlo correctamente.

Pentesting cloud periódico. Las herramientas automatizadas cubren los errores conocidos, pero un pentest cloud realizado por profesionales descubre rutas de ataque que combinan múltiples debilidades menores en un compromiso grave. Recomendamos realizar pruebas de penetración cloud al menos una vez al año o tras cambios significativos en la arquitectura.

Conclusión

Los errores de configuración cloud no son errores menores: son la puerta de entrada más habitual para las brechas de seguridad en la nube. La buena noticia es que son prevenibles con las herramientas, los procesos y la mentalidad adecuados.

La clave está en combinar la automatización (políticas, IaC, CSPM) con la expertise humana (auditorías, pentesting, formación). Ninguna herramienta sustituye el criterio de un profesional de seguridad que entiende el contexto de tu negocio, y ningún profesional puede monitorizar manualmente miles de recursos cloud sin apoyo de herramientas.

Si gestionas infraestructura en AWS o Azure y no has realizado una auditoría de seguridad cloud recientemente, el momento de hacerlo es ahora. Cada día que pasa con una configuración insegura es un día de exposición innecesaria. Contacta con nuestro equipo para una evaluación de seguridad de tu entorno cloud.