Problema

En entornos Azure con varios equipos y suscripciones, mantener una visión consolidada de la configuración de seguridad es complicado. Los controles de Defender for Cloud son útiles, pero su coste y la necesidad de habilitar el servicio pueden ser un obstáculo para equipos con presupuestos ajustados o que operan en entornos de pruebas. El reto típico es disponer de una herramienta que, desde la línea de comandos, inspeccione la suscripción y detecte configuraciones inseguras en áreas críticas como RBAC, redes, almacenamiento, identidades, máquinas virtuales, cifrado y monitorización, sin depender de servicios pagos.

Causa

Los principales factores que provocan la falta de visibilidad son:

  1. Configuraciones dispersas – Cada recurso (NSG, Key Vault, VM, etc.) tiene su propio modelo de permisos y exposición. Cuando varios administradores gestionan recursos, es fácil que se asignen roles demasiado amplios o que se deje un puerto RDP abierto.
  2. Ausencia de automatización – La mayoría de los equipos revisan manualmente el portal o ejecutan scripts ad‑hoc. Sin una rutina automatizada, los cambios regresan a un estado inseguro antes de que se detecten.
  3. Dependencia de servicios pagos – Defender for Cloud ofrece un conjunto de políticas, pero su activación implica costes mensuales. En proyectos de bajo presupuesto o en pruebas de concepto, los equipos buscan alternativas gratuitas.
  4. Falta de estandarización en la salida – Los resultados de auditorías caseras suelen ser texto sin formato, lo que dificulta la integración con pipelines CI/CD o con sistemas de ticketing.

Solución

Una estrategia reutilizable consiste en combinar:

  • Una herramienta open‑source que recorra la suscripción mediante Azure CLI y aplique un catálogo de checks alineado con los controles de Defender for Cloud.
  • Salida estructurada (JSON) y presentación legible (tabla terminal) para que tanto humanos como scripts puedan consumir los resultados.
  • Ejecutarla bajo credenciales de usuario (az login) o mediante un Service Principal, lo que permite integrarla en pipelines de CI/CD o en jobs de Azure DevOps.

Pasos clave

  1. Instalar la herramienta – Clonar el repositorio oficial y asegurarse de que el entorno tenga az y jq disponibles.
  2. Autenticarse – Usar az login para cuentas interactivas o crear un Service Principal con permisos de lectura (Reader) y Microsoft.Authorization/roleAssignments/read para inspeccionar RBAC.
  3. Ejecutar la auditoría – Lanzar el comando principal que recorre los recursos y genera dos salidas: una tabla coloreada y un archivo JSON.
  4. Integrar en CI/CD – Añadir el paso a un pipeline y, opcionalmente, publicar el JSON como artefacto o enviarlo a un webhook de alerta.
  5. Actuar sobre los hallazgos – Automatizar la creación de tickets o la aplicación de remedios (por ejemplo, remover el rol Owner de grupos genéricos o cerrar reglas NSG que permitan tráfico 0.0.0.0/0).

Esta arquitectura es agnóstica al proveedor de la herramienta; cualquier auditor que siga el mismo patrón (CLI, JSON, tabla) puede sustituir al proyecto original sin romper el flujo.

Cuándo aplicar esta solución

  • Presupuestos limitados – Cuando no se desea activar Defender for Cloud por coste.
  • Entornos de desarrollo / pruebas – Necesidad de validar rápidamente la postura antes de pasar a producción.
  • Equipos que ya usan Azure CLI – La solución se apoya en az, evitando la curva de aprendizaje de nuevas APIs.
  • Necesidad de integración CI/CD – Cuando se requiere que la auditoría forme parte de pipelines de despliegue.
  • No aplicable – En suscripciones donde ya se tiene Defender for Cloud habilitado y se confía en sus alertas automáticas, o cuando se necesita cumplimiento de normativas que requieran certificaciones específicas no cubiertas por los checks genéricos.

Código

# Clonar el auditor
git clone https://github.com/neelkotnis/azure-security-auditor.git
cd azure-security-auditor

# Instalar dependencias (az CLI y jq deben estar ya instalados)
pip install -r requirements.txt

# Autenticación interactiva
az login

# O autenticación con Service Principal (reemplazar valores)
az login --service-principal -u <APP_ID> -p <PASSWORD> --tenant <TENANT_ID>

# Ejecutar auditoría contra la suscripción actual
python auditor.py --output json --output-table

# Guardar reporte JSON en archivo
python auditor.py --output json > azure_audit_report.json

Verificación

  1. Revisar la tabla – Cada fila debe indicar PASS o FAIL junto al recurso y la regla evaluada. Los colores verde/rojo facilitan la lectura rápida.
  2. Validar el JSON – Ejecutar jq '.' azure_audit_report.json y comprobar que la estructura contiene un array findings con campos resourceId, ruleId, severity y description.
  3. Correlacionar con Azure Portal – Seleccionar un resourceId que haya fallado y abrirlo en el portal para confirmar que la configuración reportada coincide con la realidad.
  4. Ejecutar de nuevo – Después de aplicar remedios, volver a lanzar el auditor. Todos los FAIL deberían haber desaparecido; cualquier nuevo FAIL indica un cambio inesperado.

Notas adicionales

  • Permisos mínimos – Un Service Principal con solo Reader y Microsoft.Authorization/roleAssignments/read es suficiente para la mayoría de los checks. Evite asignar privilegios de escritura a menos que la herramienta también realice correcciones automáticas.
  • Personalización de reglas – El proyecto permite añadir archivos YAML bajo rules/. Si su organización tiene políticas propias (por ejemplo, prohibir StandardSSD_LRS en entornos críticos), basta con crear una regla que evalúe la propiedad sku.name.
  • Gestión de secretos – Cuando se ejecuta en pipelines, almacene el APP_ID y PASSWORD en Azure Key Vault o en variables de entorno protegidas; nunca los codifique en el repositorio.
  • Escalabilidad – En suscripciones con miles de recursos, la auditoría puede tardar varios minutos. Considere usar la opción --parallel (si está disponible) o dividir la auditoría por grupos de recursos (--resource-group).
  • Comparación con Defender for Cloud – Si más adelante habilita Defender, compare los resultados: la herramienta open‑source suele detectar la mayoría de los mismos hallazgos, pero Defender agrega detección de amenazas en tiempo real que la auditoría estática no cubre. Mantener ambas capas brinda una visión más completa sin coste adicional.