Las misconfiguraciones en Azure están detrás de brechas millonarias. Storage público, IAM excesivo, logs desactivados: estos son los errores más comunes en PYMEs centroamericanas y cómo corregirlos antes del próximo ataque.
En el artículo anterior de esta serie vimos cómo las configuraciones incorrectas de Microsoft 365 abren la puerta a atacantes. Ahora subimos una capa: Azure, la plataforma de infraestructura cloud de Microsoft que aloja servidores, bases de datos, redes virtuales y aplicaciones de millones de organizaciones.
La transición a la nube promete agilidad y reducción de costos operativos. Lo que muchas organizaciones no anticipan es que también transfiere la responsabilidad de la seguridad de configuración al cliente. Microsoft asegura la infraestructura física y los servicios en sí; la configuración segura de los recursos que usted crea es su responsabilidad. Es lo que se llama el modelo de responsabilidad compartida, y mal entendido, genera las brechas más costosas del panorama actual.
Error 1: Cuentas de almacenamiento con acceso público habilitado
Las Storage Accounts de Azure (equivalente a los buckets S3 de AWS) son uno de los recursos mal configurados con más frecuencia. Por defecto, hasta hace relativamente poco, Azure permitía crear Storage Accounts con acceso público habilitado, donde cualquier persona en Internet podía listar y descargar el contenido del contenedor.
Herramientas automatizadas como BlobHunter y MicroBurst escanean sistemáticamente el espacio de nombres .blob.core.windows.net buscando cuentas de almacenamiento con acceso público. En minutos encuentran archivos de configuración, backups de bases de datos, logs de aplicación y documentos internos.
En 2023, una empresa de servicios financieros de la región perdió contratos y sufrió una multa regulatoria después de que un investigador de seguridad descubrió que su Storage Account contenía estados de cuenta de clientes accesibles públicamente.
Verificación y corrección:
# Azure CLI: listar Storage Accounts con acceso público
az storage account list --query "[?allowBlobPublicAccess==true].{Name:name, RG:resourceGroup}" --output table
# Deshabilitar acceso público en todas las Storage Accounts
az storage account update --name --resource-group --allow-blob-public-access falseError 2: Service Principals con permisos de propietario de suscripción
Los Service Principals son identidades de aplicación en Azure AD/Entra ID: lo que se usa cuando una aplicación, script o pipeline de CI/CD necesita autenticarse contra recursos de Azure. Son el equivalente a las cuentas de servicio en el mundo on-premises.
El error más común: por conveniencia, los equipos de desarrollo asignan el rol de Owner (Propietario) a nivel de suscripción a estos service principals. Así el pipeline de despliegue puede crear, modificar o eliminar cualquier recurso sin restricciones.
Si ese service principal es comprometido —y las credenciales de service principals frecuentemente terminan en repositorios de código, logs y variables de entorno de CI/CD— el atacante tiene control total sobre toda la infraestructura Azure de la organización. Puede crear recursos para minería de criptomonedas, exfiltrar datos, o simplemente eliminar todo.
Principio de mínimo privilegio en Azure:
- Asignar roles específicos para los recursos específicos que necesita cada service principal (ej. "Colaborador de Storage" solo en las Storage Accounts que usa esa aplicación).
- Usar Managed Identities en lugar de service principals con credenciales cuando sea posible — las managed identities no tienen secretos que puedan filtrarse.
- Revisar trimestralmente las asignaciones de roles con Azure Policy o Privileged Identity Management (PIM).
Error 3: Grupos de seguridad de red (NSG) demasiado permisivos
Los Network Security Groups son los firewalls de Azure. Definen qué tráfico puede entrar y salir de sus máquinas virtuales y subredes. La configuración incorrecta más peligrosa: permitir tráfico desde 0.0.0.0/0 (cualquier IP de Internet) hacia puertos de administración.
Los puertos más frecuentemente expuestos de forma inadvertida:
- Puerto 3389 (RDP): Si está abierto a Internet, en minutos aparecerá en escáneres automatizados y comenzarán los intentos de fuerza bruta.
- Puerto 22 (SSH): Similar al caso de RDP. Un servidor Linux con SSH expuesto a Internet recibe cientos o miles de intentos de login al día.
- Puerto 1433 (SQL Server): Una base de datos SQL directamente expuesta a Internet es un objetivo prioritario para exfiltración de datos.
La regla general: los puertos de administración nunca deben estar expuestos directamente a Internet. Deben accederse a través de Azure Bastion, VPN, o como mínimo con restricción a rangos de IP corporativos específicos.
# Identificar reglas NSG que permiten todo el Internet hacia puertos críticos
az network nsg list --query "
[].{NSG:name, RG:resourceGroup, Rules:securityRules[?
sourceAddressPrefix=='*' && direction=='Inbound' && access=='Allow'
].{Puerto:destinationPortRange, Prioridad:priority}
}" --output tableError 4: Key Vault sin control de acceso granular
Azure Key Vault es el servicio diseñado para almacenar secretos, claves de cifrado y certificados de forma segura. Paradójicamente, con frecuencia encontramos Key Vaults configurados de tal manera que prácticamente cualquier identidad en el tenant de Azure puede leer su contenido.
Los problemas más comunes:
- Políticas de acceso heredadas demasiado amplias: Un servicio principal creado hace años con acceso de "Obtener todos los secretos" que ya nadie usa pero nadie eliminó.
- Sin purge protection ni soft delete: Si un atacante obtiene acceso y elimina los secretos, sin estas protecciones no hay forma de recuperarlos.
- Acceso desde todas las redes: Key Vault debería aceptar conexiones únicamente desde las redes virtuales y IPs que efectivamente lo necesitan, no desde cualquier origen.
Error 5: Diagnósticos y logs no configurados
Este es el error que transforma un incidente manejable en una catástrofe forense: la ausencia de logs. Si Azure no registra quién accedió a qué, cuándo y desde dónde, cuando ocurre un incidente es imposible saber qué fue comprometido, cuánto tiempo estuvo el atacante dentro y qué datos fueron exfiltrados.
Los recursos de Azure que con más frecuencia encontramos sin logging habilitado:
- Storage Accounts (accesos a blobs)
- Key Vault (accesos a secretos)
- NSG Flow Logs (tráfico de red)
- Azure AD Sign-in logs (retención por defecto: solo 30 días en P1/P2, 7 días en planes básicos)
La solución es centralizar todos los logs en un Log Analytics Workspace y configurar Microsoft Sentinel (o una solución SIEM equivalente) para alertas automáticas sobre comportamientos anómalos.
Microsoft Defender for Cloud: su aliado gratuito
Microsoft ofrece Defender for Cloud (anteriormente Azure Security Center) con una capa gratuita que revisa automáticamente las configuraciones de sus recursos de Azure y genera recomendaciones priorizadas. Si tiene recursos en Azure y no ha revisado Defender for Cloud, hay una alta probabilidad de que tenga hallazgos críticos esperando.
Acceda desde el portal de Azure buscando "Microsoft Defender for Cloud". El panel de Secure Score muestra su postura actual y las acciones con mayor impacto. Es gratuito para evaluación básica; las capacidades avanzadas de detección de amenazas tienen costo pero justifican la inversión para cualquier organización con carga de trabajo significativa en Azure.
La configuración como proceso continuo, no como proyecto único
El error conceptual más común en la gestión de seguridad de Azure es tratarla como un proyecto: "lo configuramos bien y quedó listo." La nube cambia constantemente: se crean nuevos recursos, se modifican permisos, se conectan nuevas aplicaciones. Cada cambio puede introducir una nueva misconfiguration.
La seguridad de Azure requiere un proceso de revisión continua, que es exactamente lo que un Virtual CISO provee: vigilancia constante sobre la postura de seguridad, revisión de cambios y acompañamiento estratégico en las decisiones de arquitectura.
En el próximo artículo de la serie cambiamos de Microsoft a Linux: el sistema operativo que corre la mayoría de servidores web, contenedores y bases de datos del mundo, y cuyas vulnerabilidades se ignoran con más frecuencia de lo que debería.
Si usa Azure en su empresa y quiere saber cuál es su Secure Score real y qué misconfiguraciones específicas tiene, nuestro servicio de arquitectura segura en la nube incluye una revisión completa con informe y roadmap de remediación.