Luis Adán Muñoz es amigo mío y consultor de arquitectura cloud en Evolutio. Lo digo de entrada porque este artículo no pretende ser neutral: es una recomendación razonada. Su web, luisadanmunoz.es, lleva un tiempo publicando el tipo de material que más escasea en español sobre Azure: trabajo hecho en tenants reales, con los fallos incluidos.
1. Qué es la web
Se presenta con una frase que describe bien el contenido: construyo en Azure y lo cuento aquí. Los artículos se agrupan en tres áreas (noticias de Azure e IA con contexto, arquitectura y operación en Azure, y agentes con Microsoft Foundry), y hay además una sección de recursos: fichas por servicio con diseño, Terraform y errores habituales, organizadas por categorías (redes, identidad, seguridad, almacenamiento, monitorización, gobernanza, IA…). Tiene RSS y newsletter con un correo por artículo nuevo, sin más.
Su perfil público lo sitúa en Azure Landing Zones, gobierno, migraciones, redes, seguridad y operación con FinOps, automatizando con Terraform y con interés creciente en IA aplicada. La web refleja ese perfil: poco marketing y mucho procedimiento.
2. Lo que está publicando
En las últimas semanas el ritmo ha sido alto y el tema, bastante coherente. Estos son los textos recientes que aparecen en su portada:
| Fecha | Artículo | De qué trata |
|---|---|---|
| 29 oct | Auditar un tenant de Azure desde GitHub Actions… y que la remediación llegue como una PR | Auditoría automática contra CIS, WAF y MCSB, y remediación propuesta como código |
| 27 oct | Azure DevOps ya tiene pipelines. ¿Y si añadimos agentes de IA con ado-aw? | Diseño de una plataforma de agentes para una organización de Azure DevOps: MCP, permisos y un primer agente |
| 16 oct | Auditar Entra ID de verdad | Licencias, políticas y riesgo en un tenant grande, solo lectura |
| 16 oct | Acceder a un AKS privado con command invoke | kubectl sin VPN contra un clúster privado y los dos niveles de permisos implicados |
| 16 oct | Del consumo Azure de los clientes CSP a una lista de conversaciones | Usar el consumo por cliente como señal comercial |
| 13 oct | Portal de autoservicio con Entra ID, GDAP y Lighthouse | Peticiones del cliente, aprobación y ejecución delegada |
| 23 sep | Un segundo cerebro en Obsidian para un consultor de Azure | Un vault versionado, con guardrails de seguridad y conectado a Claude Code |
Hay dos que me parecen especialmente representativos, y los resumo con más detalle.
2.1 Auditar es fácil; que alguien apruebe el cambio, no
El último artículo parte de una tesis que comparto: auditar un tenant es un problema casi resuelto, porque hay herramientas gratuitas que escupen cientos de hallazgos. El cuello de botella es convertir cada hallazgo en un cambio que una persona se atreva a aprobar. Su respuesta es la pull request: explica qué cambia, por qué, qué puede romperse, dónde se aplica y cómo se revierte.
La arquitectura que describe tiene decisiones de criterio, no solo de herramienta:
- Auditar y remediar con identidades distintas. La de auditoría es de solo lectura; la de remediación solo puede tocar storage accounts y sus private endpoints, y solo tras aprobación. Autenticación por OIDC, sin secretos.
- Cuatro motores en paralelo (Prowler, PSRule for Azure, Azure Resource Graph con Defender for Cloud y Maester) y un trabajo final que normaliza severidades, elimina duplicados y mantiene un único issue con lo crítico y lo alto.
- Orden estricto al remediar: primero se crean el private endpoint y su DNS y, solo si funciona, se desactiva el acceso público. Con rollback acotado a lo que la propia herramienta creó.
- Nada de Azure Policy con
Modifydesde el primer día sobre un inventario sin sanear: cambiaría producción sin revisión previa. La prevención llega después. - Respeto al código: lo gestionado por IaC no se corrige por fuera, porque solo generaría deriva; se corrige en el código.
Lo que lo hace creíble son las cifras y los fallos. En su ejecución consolidada salieron 675 hallazgos (unos 16 críticos y 309 altos), con nueve storage accounts accesibles desde Internet. Prowler llegó a reportar 2.636 hallazgos que quedaron en 317 al eliminar duplicados entre marcos normativos. Y cuenta que en un intento PSRule devolvió cero hallazgos porque no estaba leyendo la entrada, lo que él mismo califica como el resultado más peligroso. El primer merge falló con un 403 por falta de permisos; el acceso público no se desactivó, así que el servicio no se vio afectado. Y termina con una sección de limitaciones: un solo tenant, un solo caso aplicado, una heurística de ubicación del private endpoint que puede equivocarse.
2.2 Una auditoría de identidad que desconfía de sí misma
El artículo sobre Entra ID es una auditoría de solo lectura de un tenant educativo con decenas de miles de cuentas. Sin identificar al cliente, deja varias ideas que valen para cualquier tenant:
- Tener una licencia asignada no es tener la funcionalidad. Hay que comprobar el estado, el origen y los planes deshabilitados.
- Cobertura de políticas frente a cobertura efectiva: unas 200 personas cubiertas por políticas de MFA, pero solo unas 30 con MFA exigido en todas las aplicaciones.
- Precisión al contar: trece Global Administrators que en realidad eran cuatro permanentes y nueve elegibles en PIM; sigue siendo mucho, pero no es lo mismo. Y «sin método» no equivale a «sin MFA registrado».
- El hallazgo más serio: cuentas con solo licencias básicas mostraban detecciones de riesgo reales, incluido un password spray activo con actividad minutos antes. La protección se aplicaba, pero con un problema de licenciamiento.
La parte metodológica es la más reutilizable: scripts que fallan pronto en lugar de producir un CSV vacío con apariencia válida, gestión de lotes y límites de la API, y cada afirmación respaldada por documentación oficial, hasta el punto de corregir conclusiones previas. Entrega tres scripts reutilizables y deja fuera de lo publicado el anexo con cuentas concretas.
3. Lo que une todos esos textos
Leídos juntos, hay un patrón que me parece más valioso que cualquier artículo suelto:
Es, además, una forma de escribir. Cada artículo da la decisión, la alternativa descartada y el motivo, y los números salen de ejecuciones reales. Eso conecta con algo que ya defendí al contar el segundo despliegue de una torre de control de IA: los fallos concretos enseñan más que la arquitectura limpia.
4. Dónde le veo recorrido
Desde fuera, y como opinión de amigo, tres ideas:
- El puente hacia el marco regulatorio. Sus auditorías ya mapean a CIS, ISO 27001, ENS, NIST o DORA a través de las herramientas. Un texto que explique qué evidencia de esas ejecuciones sirve ante un auditor sería muy útil en banca y sector público.
- Los agentes sobre Azure DevOps abren la pregunta de gobierno: qué puede hacer un agente, con qué identidad y qué queda registrado. Es el terreno de AgentOps, y su enfoque de permisos mínimos encaja.
- Seguir midiendo. Cuando las pull requests pendientes se vayan aprobando, cifras como la tasa de aceptación o el tiempo hasta el merge dirán si el modelo escala más allá de un tenant.
Mi recomendación para quien administra Azure: empieza por el artículo de auditoría con pull requests y por el de Entra ID. Son largos (14 y 18 minutos según su web), pero están escritos para que se puedan replicar.
Las opiniones expresadas en este artículo son personales. Luis Adán Muñoz es amigo del autor; los contenidos resumidos son los que figuran publicados en su web a fecha de consulta.
Fuentes
Consultadas el 30 de octubre de 2026. Las cifras proceden de los propios artículos citados y no han sido verificadas de forma independiente.
- Luis Adán Muñoz. luisadanmunoz.es (portada y sección Sobre mí)
- Auditar un tenant de Azure desde GitHub Actions… y que la remediación llegue como una PR (29 de octubre de 2026)
- Auditar Entra ID de verdad: licencias, políticas y riesgo que nadie estaba mirando (16 de octubre de 2026)