Llegamos a una infraestructura Azure que lleva dos o tres años creciendo. Hay decenas —a veces cientos— de recursos. Terraform existe, aunque nadie puede afirmar cuánto controla. Vemos varios pipelines, Azure Monitor habilitado, copias de seguridad en verde y una lista considerable de recomendaciones en Defender for Cloud. La aplicación funciona y la factura llega puntualmente.
Sobre el papel no hay ningún incendio. Pero todavía no sabemos algo fundamental: qué pasaría si mañana fallase una pieza crítica.
Durante las primeras 48 horas no intentaríamos modernizar la plataforma, migrar servicios ni desplegar Kubernetes. Tampoco empezaríamos corrigiendo al azar lo primero que aparezca en el portal. El objetivo inicial es construir un mapa suficientemente preciso del sistema para distinguir criticidad, dependencias, exposición, operabilidad y riesgo.
Una primera auditoría de Azure no busca producir cien hallazgos. Busca responder qué sostiene producción, quién puede modificarlo, qué está expuesto, qué puede reconstruirse, qué puede recuperarse, qué señales existen durante un incidente y dónde se consume dinero. Primero entender, después priorizar y solo entonces cambiar.
Antes de tocar Azure: entender qué estamos operando
Una auditoría técnica no debería empezar abriendo Azure Portal al azar. Primero hablamos con quienes construyen, operan y responden por el producto. Queremos saber qué servicios generan ingresos, qué clientes dependen de ellos, qué SLO o compromisos contractuales existen, qué entornos hay, cuáles contienen datos reales y cuándo se concentra el uso. También preguntamos por ventanas de mantenimiento, requisitos regulatorios, integraciones externas e incidentes recientes.
La razón es sencilla: un recurso Azure no tiene criticidad por sí mismo; la hereda del servicio que sostiene. Una VM pequeña y olvidada puede ser más crítica que un clúster completo si ejecuta el único agente que procesa pagos o resuelve DNS interno. Un Storage Account con poco tráfico puede contener los documentos sin los que una operación no puede continuar.
La primera señal preocupante no es una decisión técnica concreta. Es que negocio y tecnología describan dos mapas distintos. Si el equipo comercial promete recuperación en una hora, pero operaciones entiende que restaurar producción puede llevar un día, ya existe un riesgo aunque todos los recursos aparezcan sanos.
La acción posterior no consiste todavía en rediseñar. Consiste en acordar una lista corta de workloads, owners, dependencias y objetivos de servicio. Ese inventario de negocio será el criterio con el que evaluaremos el resto.
Primeras 2 horas: construir el mapa
Empezamos por el tenant de Microsoft Entra ID: identidades administrativas, Global Administrators, cuentas personales, invitados, cuentas de servicio, MFA, Conditional Access, service principals y managed identities. No pretendemos completar una auditoría de identidad en dos horas. Buscamos riesgos evidentes y, sobre todo, entender cuál es la raíz de confianza del entorno.
Después recorremos management groups, subscriptions y herencia de políticas. Observamos la separación entre producción y no producción, quién es propietario de cada subscription y si quedan subscriptions antiguas sin propósito claro. Tener producción, desarrollo y sandbox juntos no es automáticamente incorrecto; sí exige entender por qué el aislamiento, los límites de cuota, el coste y el control de acceso se resolvieron así.
Los Resource Groups revelan parte del modelo operativo. Buscamos agrupaciones por lifecycle, workload o equipo; recursos compartidos que se eliminarían junto a componentes temporales; grupos históricos sin owner; y nombres que ya no representan lo que contienen. Una taxonomía imperfecta es manejable. Un lifecycle impredecible aumenta el riesgo de cambio.
Finalmente consultamos Azure Resource Graph y los repositorios para obtener un inventario rápido de compute, App Service, Functions, Container Apps o AKS; SQL y bases gestionadas; Storage, Cosmos DB, Service Bus y Event Grid; Key Vault; networking; y observabilidad. No hacemos un catálogo de servicios. Reconstruimos relaciones: entrada de tráfico, procesamiento, persistencia, integraciones y salida.
Una señal especialmente útil es la discrepancia: recursos que nadie menciona, componentes críticos que no aparecen en diagramas o un entorno que el inventario llama dev pero recibe tráfico de clientes. Ante eso no borramos ni renombramos. Registramos la incógnita y buscamos evidencias en DNS, métricas, Activity Log, configuración y pipelines.
Identidad y RBAC: quién puede hacer qué
En Azure, “funciona porque tiene permisos” y “tiene exactamente los permisos que necesita” son estados muy distintos. Revisamos asignaciones de Owner, Contributor y User Access Administrator; roles personalizados; scope; herencia; asignaciones directas frente a grupos; identidades sin uso y credenciales próximas a expirar. Cuando existe PIM, comprobamos qué privilegios son elegibles, cuáles siguen siendo permanentes y cómo se activan y revisan.
El alcance importa tanto como el rol. Un pipeline que solo despliega un Resource Group no debería ser Contributor de toda la subscription por comodidad. Puede funcionar durante años, pero una credencial filtrada o un workflow modificado tendría un blast radius innecesario. La corrección sería crear una identidad por responsabilidad, conceder el rol mínimo al scope mínimo y, cuando el servicio lo permita, sustituir secretos duraderos por federación de identidades o managed identity.
También distinguimos el control plane del data plane. Ser Contributor de un Storage Account no equivale necesariamente a poder leer blobs; y conceder un rol de datos puede exponer información aunque el usuario apenas gestione recursos. Los roles personalizados con *, las asignaciones a usuarios individuales y los service principals sin owner son señales de deuda.
Aplicar least privilege no significa retirar permisos durante la inspección y arriesgar un despliegue. Primero capturamos uso y dependencias, proponemos un modelo objetivo, probamos con una identidad controlada y revocamos de forma gradual. En acceso privilegiado, la velocidad sin trazabilidad suele crear un incidente distinto del que pretendía evitar.
Qué está expuesto a Internet
Construimos una vista de Public IPs, endpoints públicos, NSGs, firewalls de servicio y rutas de entrada. Buscamos reglas 0.0.0.0/0, SSH y RDP, bases de datos públicas, Storage Accounts, App Services, registries, Key Vault y reglas de Azure SQL. Después verificamos si la exposición es realmente necesaria y qué controles compensatorios existen.
Internet → Public IP → VM:22
frente a
Engineer → VPN / Bastion / acceso Zero Trust → red privada → VM“Tiene firewall” no demuestra aislamiento. Una regla puede permitir todo Internet, una excepción histórica puede abarcar una red completa y un Private Endpoint no deshabilita por sí solo el acceso público del servicio. Además, Private Link introduce DNS, zonas privadas y rutas cuya resolución debemos validar desde cada red consumidora.
No recomendamos privatizarlo todo por principio. Un endpoint web público detrás de WAF, autenticación y protección DDoS puede ser exactamente el diseño correcto. Private Endpoints añaden coste y complejidad operativa; son valiosos cuando reducen un riesgo real o cumplen un requisito. El hallazgo no es “existe una Public IP”, sino “una interfaz administrativa está expuesta sin una razón y sin controles proporcionales”.
Si encontramos exposición crítica, la siguiente acción es contenerla con un cambio pequeño, reversible y probado: restringir origen, retirar un puerto administrativo o deshabilitar acceso público después de comprobar la ruta privada. El rediseño completo de red viene después.
Networking: entender antes de cambiar
Revisamos VNets, espacios de direcciones, subnets, peerings, topologías hub-and-spoke, VPN o ExpressRoute, Private Link, tablas de rutas, Azure Firewall, NSGs, NAT Gateway, DNS y egress. Nos interesa tanto el diagrama previsto como el tráfico real.
Los patrones que más preocupan son rangos solapados, VNets creadas sin planificación, mallas de peering difíciles de razonar, dependencias con IPs fijas, resolución DNS distinta según el origen y salida a Internet sin ownership. Son decisiones que parecen locales hasta que bloquean una adquisición, una conexión híbrida o una nueva región.
Networking suele ser una de las áreas más caras de corregir porque atraviesa identidades, aplicaciones, datos y terceros. Si el DNS privado es frágil, no cambiamos una zona durante la auditoría. Documentamos flujos, consultamos logs cuando existen, validamos desde puntos concretos y diseñamos la migración con convivencia temporal. La prioridad es hacer visible el camino de cada dependencia antes de alterar ese camino.
¿Puede reconstruirse la infraestructura?
La pregunta central es deliberadamente incómoda:
Si perdiéramos mañana esta subscription, ¿cuánto de la plataforma podríamos reconstruir desde Git?
Revisamos Terraform, Bicep, ARM o Pulumi; estructura de módulos; versiones; providers; backend remoto; locking; separación y protección del state; imports; planes; drift y cambios manuales. También comprobamos cómo se crean DNS, permisos, certificados, diagnostic settings, pipelines, variables y configuraciones de servicio. Estos bordes suelen quedar fuera del repositorio aunque el núcleo figure como IaC.
Infraestructura creada con Terraform no equivale a infraestructura reproducible. Puede haber un state inaccesible, módulos que dependen de valores copiados a mano o cambios en portal que nunca llegaron al código. El configuration drift no es solo una diferencia estética: convierte cada plan en una negociación sobre cuál es la fuente de verdad.
No importamos toda la subscription durante las primeras 48 horas. Clasificamos cobertura y riesgo, ejecutamos planes no destructivos cuando es seguro y elegimos un workload representativo para probar el proceso. Una estrategia de Terraform en Azure brownfield necesita fases, ownership y criterios de importación; no un gran commit imposible de revisar.
CI/CD: cómo llega el código a producción
Seguimos un cambio real desde commit hasta producción en GitHub Actions, Azure DevOps, GitLab CI o el sistema existente. Comprobamos branch protection, revisiones, environments, approvals, artefactos, procedencia de imágenes, secretos, permisos de runners, promoción entre entornos y rollback. Queremos saber si se construye una vez y se promociona el mismo artefacto, o si cada entorno recompila algo distinto.
Nos preocupan despliegues manuales, scripts conocidos por una persona, secretos estáticos, pipelines duplicados, imágenes latest, runners persistentes sin aislamiento y cambios de infraestructura desde portal. También preguntamos cuándo se ejecutó el último rollback y qué parte se validó. Un procedimiento escrito pero nunca ensayado sigue siendo una hipótesis.
Un pipeline verde solo demuestra que el pipeline terminó. No demuestra que el servicio esté sano.
Por eso buscamos smoke tests, health checks, métricas de negocio, despliegues progresivos y criterios automáticos o humanos para detener una release. Si falta ese cierre, el primer quick win puede ser verificar una transacción crítica después del despliegue, antes de plantear una reingeniería completa de CI/CD y DevOps.
Secrets y Key Vault: reducir credenciales estáticas
Inventariamos secretos en Key Vault, variables de pipeline, .env, repositorios, configuración de aplicaciones y Kubernetes Secrets cuando aplica. Revisamos expiración, rotación, certificados, access policies frente a Azure RBAC y el uso de managed identities.
El objetivo no es marcar la casilla “usa Key Vault”. Es reducir cuántos secretos estáticos existen, cuántos sistemas pueden leerlos y cuántas personas deben coordinarlos. Una aplicación con managed identity que obtiene solo el secreto necesario elimina la credencial de arranque que, de otro modo, habría que proteger y rotar.
Las señales más serias son credenciales en Git, secretos compartidos por varios workloads, certificados sin owner y expiraciones que pueden detener producción. Primero rotamos material potencialmente expuesto y comprobamos consumidores. Después diseñamos automatización, separación por aplicación, RBAC de datos y protección ante borrado. Rotar sin conocer dependencias puede causar el mismo downtime que pretendemos prevenir.
Backups: verde no significa recuperable
Revisamos Azure Backup, Recovery Services Vault, SQL PITR, backups de PostgreSQL, redundancia de Storage, snapshots, retención, soft delete, geo-redundancia e inmutabilidad cuando el riesgo lo justifica. Pero el indicador decisivo no es la última tarea completada: es la última restauración validada.
Backup success ≠ recovery success. Preguntamos cuándo se restauró por última vez, cuánto tardó, quién lo hizo, si existe runbook y cómo se validaron los datos. El objeto de recuperación no es una base aislada, sino el servicio completo.
RPO expresa la pérdida de datos tolerable; RTO, cuánto tiempo puede estar indisponible el servicio. Un backup cada 24 horas no demuestra por sí solo RPO = 24 h, porque pueden existir logs transaccionales u otros mecanismos. Tampoco que una base se restaure en 30 minutos implica RTO = 30 min: faltan infraestructura, identidades, DNS, secretos, aplicaciones, replay seguro de eventos y validación.
La respuesta madura es un ejercicio acotado. Restauramos en un entorno aislado, medimos el tiempo total, validamos una transacción de negocio y registramos cada improvisación. Si este riesgo ya está materializado, una revisión de continuidad y operación Azure debe convertir la prueba en una rutina repetible.
Observabilidad: ¿podemos entender un incidente?
Revisamos Azure Monitor, Log Analytics, Application Insights, Managed Prometheus, Grafana, diagnostic settings, alertas, action groups, dashboards, trazas, correlation IDs y synthetic checks. Preguntamos qué alerta despierta a alguien, cuáles se ignoran y cuánto se tarda en llegar desde “el servicio va lento” hasta una causa probable.
Monitorizar CPU, memoria y disponibilidad de recursos no basta si nadie ve la experiencia del usuario. Buscamos señales de servicio: tasa de errores, latencia por operación, colas, saturación, fallos de dependencias y transacciones sintéticas. A la vez, revisamos cardinalidad, retención y volumen de ingesta: demasiados logs sin propósito degradan la investigación y elevan el coste de Log Analytics.
Monitoring avisa de que algo cambió; observability aporta el contexto para entender por qué. La corrección no es crear cincuenta alertas. Es definir el health model del workload, conectar unas pocas señales accionables con ownership y probar que el aviso llega. La observabilidad y práctica SRE empieza por reducir tiempo de diagnóstico, no por acumular dashboards.
FinOps: seguir el dinero
En Azure Cost Management examinamos coste por subscription, Resource Group, servicio, región y tag; budgets y alertas; reservas, Savings Plans y Azure Hybrid Benefit cuando aplican; además de compute, bases, discos, Storage, Log Analytics, red, egress y backups. Comparamos tendencia y cambio de uso, no solo el total mensual.
Buscamos entornos no productivos activos 24/7, VMs sobredimensionadas, discos sin adjuntar, snapshots históricos, bases con capacidad o tiers que no corresponden a demanda, logs excesivos, recursos huérfanos y costes sin owner. Una anomalía sin contexto puede ser crecimiento saludable; por eso vinculamos gasto con producto, cliente o capacidad.
FinOps no es bajar la factura a cualquier precio.
Una reserva puede ahorrar sobre una base estable, mientras un Savings Plan ofrece flexibilidad para uso elegible más dinámico; ninguno arregla recursos innecesarios. Y reducir redundancia, retención o capacidad crítica para alcanzar un objetivo mensual puede transferir coste financiero a riesgo operativo. La decisión debe equilibrar coste, rendimiento, resiliencia y velocidad. Si la atribución todavía no existe, el primer paso de FinOps en Azure es crear ownership y un baseline defendible.
Azure Policy, Defender y governance
Revisamos Azure Policy, initiatives, assignments, exemptions y efectos; Defender for Cloud, recomendaciones y Secure Score; requisitos regulatorios; resource locks; políticas de tags, regiones o SKUs; y cobertura de diagnostic settings. La pregunta no es cuántas políticas existen, sino cuáles previenen, despliegan o auditan controles relevantes sin bloquear la entrega legítima.
Secure Score no es una auditoría. Es una señal agregada y útil para orientar investigación. Puede haber recomendaciones irrelevantes, excepciones justificadas, controles compensatorios y riesgos de negocio que el score no conoce. En 2026 conviven además experiencias de score distintas entre Azure Portal y Microsoft Defender Portal; perseguir un número sin comprender el modelo puede distorsionar prioridades.
Una policy en modo audit que nadie revisa produce cumplimiento aparente. Una policy deny desplegada sin analizar recursos existentes puede romper delivery. Primero agrupamos findings por riesgo y workload, documentamos excepciones con owner y caducidad, y ensayamos los controles. Después promovemos gradualmente de audit a deny o deploy-if-not-exists cuando sea seguro.
Dependencias y single points of failure
Buscamos una VM única, una instancia de base de datos sin réplica adecuada, dependencia de una zona, gateways, NAT, DNS, certificados, integraciones y SaaS externos. La pregunta que corta el ruido es: ¿qué componente puede detener completamente el servicio y qué ocurriría realmente si desapareciese?
Alta disponibilidad y disaster recovery resuelven fallos distintos. Distribuir instancias entre Availability Zones puede tolerar el fallo de una zona, pero no necesariamente una región, una eliminación lógica, una credencial comprometida o una release corrupta. Replicar datos también puede replicar corrupción. Evaluamos failure modes concretos contra objetivos de negocio, no contra una arquitectura ideal abstracta.
Si encontramos un SPOF, no siempre se duplica de inmediato. Medimos probabilidad, impacto, tiempo de sustitución y coste. Para un servicio interno puede bastar un runbook y automatización de reconstrucción; para el camino de facturación puede requerir redundancia, failover probado y un diseño regional. La resiliencia proporcional es más operable que la redundancia indiscriminada.
Bus factor y operabilidad
Investigamos quién puede desplegar, recuperar, administrar acceso privilegiado y explicar DNS, networking, Terraform y backups. Revisamos runbooks, ADRs, diagramas, documentación, ownership y rutas de escalado. No evaluamos a personas: evaluamos si el sistema permite que el equipo actúe sin depender de memoria privada.
Si mañana la persona principal de infraestructura no pudiera trabajar durante dos semanas, ¿podría operar el resto del equipo?
Una respuesta negativa suele aparecer en tareas aparentemente pequeñas: el certificado que solo alguien sabe renovar, el pipeline que requiere un token personal o el restore cuyos pasos viven en el historial de un chat. El siguiente paso es seleccionar las operaciones de mayor impacto, hacer que otra persona las ejecute con supervisión y transformar las lagunas en automatización o runbooks. Reducir el bus factor en DevOps es una medida de continuidad, no una crítica al especialista que sostiene la plataforma.
No todo lo que encontramos es un problema
Una auditoría madura no compite por generar más findings. Una Public IP puede estar justificada. Una única subscription puede encajar con el tamaño y el aislamiento requerido. No usar AKS puede ser una excelente decisión. No tener Azure Firewall o no desplegar Private Endpoints para cada servicio puede evitar coste y complejidad sin aumentar materialmente el riesgo.
Una solución menos elegante puede ser la adecuada si el equipo la entiende, cumple sus objetivos y puede operarla. La pregunta correcta es: ¿esta decisión sigue teniendo sentido para el negocio y la plataforma que tenemos hoy?
Por eso cada hallazgo debe incluir evidencia, escenario de impacto, probabilidad, control existente y recomendación proporcional. “No sigue nuestra arquitectura de referencia” no es impacto. Si no podemos explicar qué fallo previene una propuesta, todavía no deberíamos pedir al equipo que la implemente.
Qué deberíamos tener después de 48 horas
Al final no esperamos una nueva arquitectura. Esperamos cuatro artefactos útiles: un mapa de servicios y dependencias; un risk register priorizado; quick wins con cambios pequeños y reversibles; y structural issues que requieren proyecto, presupuesto o decisiones de negocio. Añadimos una quinta categoría explícita: unknowns.
| Finding | Impacto | Probabilidad | Prioridad |
|---|---|---|---|
| Restore de la base nunca probado | Crítico | Media | Crítica |
| Interfaz administrativa abierta a Internet | Crítico | Alta | Crítica |
| Service principal Contributor a subscription | Alto | Media | Alta |
| Certificado productivo sin owner y próximo a expirar | Alto | Alta | Crítica |
| Única dependencia de base en una zona | Alto | Media | Alta |
| Terraform drift en networking productivo | Alto | Media | Alta |
| Rollback de aplicación no ensayado | Alto | Media | Alta |
| Alertas sin action group operativo | Medio | Alta | Alta |
| Egress y DNS privado sin diagrama ni owner | Medio | Media | Media |
| VMs de desarrollo sobredimensionadas | Bajo | Alta | Media |
| Retención de logs sin criterio | Bajo | Alta | Media |
| RTO regional todavía desconocido | Desconocido | Desconocida | Investigar |
Saber lo que todavía no sabemos también forma parte de una buena auditoría. Un unknown con owner, evidencia pendiente y fecha de resolución es más honesto que convertir una suposición en una recomendación.
Prioridad: no corregir 100 cosas a la vez
Usamos una clasificación operativa sencilla. P0 es riesgo inmediato de pérdida de datos, compromiso o caída crítica y activa contención. P1 es riesgo alto con owner y fecha cercana. P2 es deuda que reduce la capacidad del equipo, aunque no rompa producción mañana. P3 agrupa optimizaciones de eficiencia, coste o experiencia.
La etiqueta no se asigna solo por severidad técnica. Incluye criticidad del workload, exposición, controles compensatorios, probabilidad y reversibilidad de la corrección. Diez tareas P1 abiertas a la vez no son una prioridad; son otro backlog. Limitamos trabajo en curso y validamos cada cambio antes de iniciar el siguiente bloque.
Las 20 preguntas que debería poder responder cualquier equipo que opere Azure
- ¿Qué workloads sostienen producción y quién es owner de cada uno?
- ¿Qué ocurre con el servicio si falla una zona o la región principal?
- ¿Qué RPO está acordado para cada conjunto de datos crítico?
- ¿Qué RTO incluye restauración, configuración y validación completa?
- ¿Cuándo fue la última restauración real y qué demostró?
- ¿Qué recursos y configuraciones no están definidos como código?
- ¿Quién tiene Owner, User Access Administrator o privilegios equivalentes, y por qué?
- ¿Qué workloads e interfaces administrativas están expuestos públicamente?
- ¿En cuántos lugares viven credenciales estáticas?
- ¿Podemos rotarlas sin downtime y sin coordinación manual frágil?
- ¿Qué alerta detecta una degradación percibida por clientes?
- ¿Cuánto cuesta cada producto, equipo y entorno, con qué owner?
- ¿Qué cambio de uso explica el crecimiento de la factura del último mes?
- ¿Podemos hacer rollback con el mismo proceso que despliega?
- ¿Qué operación crítica depende de una sola persona?
- ¿Qué componentes son single points of failure y qué impacto tienen?
- ¿Qué cambios de producción siguen realizándose manualmente?
- ¿Cuánto tardamos en pasar de una alerta a una causa probable?
- ¿Qué porcentaje de producción puede reconstruirse desde Git en un entorno vacío?
- Si Azure sufriera un fallo importante mañana, ¿quién decidiría qué hacer y con qué runbook?
Si varias respuestas empiezan por “creemos”, ya tenemos un orden de investigación. No hace falta resolver las veinte en dos días; hace falta distinguir hechos, supuestos e incógnitas.
Las primeras 48 horas deberían producir claridad
Después de dos días deberíamos entender suficientemente bien qué es crítico, dónde está el riesgo, qué puede romperse, qué puede recuperarse, qué depende de personas, dónde se gasta dinero y qué merece atención primero. Eso permite decidir si el paso siguiente es contener una exposición, ensayar recovery, reducir privilegios, recuperar control mediante IaC o plantear un proyecto estructural.
Las primeras 48 horas no deberían producir una nueva arquitectura. Deberían producir claridad.
Una infraestructura no necesita ser perfecta. Necesita ser comprensible, operable y proporcional al negocio que sostiene.
Fuentes técnicas oficiales
Este enfoque se apoya en documentación vigente de Microsoft sobre Azure Well-Architected Framework, buenas prácticas de Azure RBAC, Privileged Identity Management, Azure Private Endpoint, fiabilidad de Azure Backup, Azure Monitor, seguridad de Key Vault, Azure Policy y recomendaciones de Defender for Cloud.
