🏛️ Gobernanza y Organización Enterprise en Azure
Guía de diseño organizativo para grandes empresas basadas en el Cloud Adoption Framework (CAF) de Microsoft: estructura de Management Groups, fronteras de aislamiento en suscripciones, automatización de etiquetas (tags) y guardrails con Azure Policy e Iniciativas de Seguridad.
01. Estructura de Management Groups & Landing Zones (CAF)
El estándar de arquitectura de escala empresarial se organiza bajo una jerarquía de Management Groups (MG) que garantizan que toda nueva suscripción herede automáticamente los controles de seguridad y red desde su creación.
• Management: Suscripción de Log Analytics, SIEM (Microsoft Sentinel) y monitoreo.
• Connectivity: Suscripción para el Hub de red (ExpressRoute, Azure Firewall, NVA).
• Online: Suscripciones expuestas a Internet con ingress propio (App Gateway/WAF) aisladas de la red interna.
02. Azure Policy vs Azure RBAC: Control de Acceso vs Guardrails
RBAC y Azure Policy son mecanismos complementarios que operan sobre dimensiones completamente distintas del plano de control.
Azure RBAC
Responde a la pregunta: ¿Tiene permiso esta identidad para realizar esta acción?
- Evalúa la identidad (Usuario, Service Principal o Managed Identity).
- Asigna roles (Owner, Contributor, Reader) sobre un scope específico.
- No puede condicionar los atributos del recurso desplegado.
Azure Policy
Responde a la pregunta: ¿Cumple este recurso con las normas de configuración del estado?
- Evalúa las propiedades y la configuración del recurso.
- Funciona independientemente de quién ejecute la acción (incluso un Owner debe cumplir la policy).
- Aplica guardrails infranqueables (efecto
deny,audit,modify).
03. Tags Obligatorios & Restricción de Regiones
La asignación estratégica de políticas garantiza que la infraestructura cumpla con normas de residencia de datos y modelos de imputación de costos (Chargeback / Showback).
Restricción de Regiones
Se utiliza la política built-in "Allowed locations" asignada a nivel de Management Group raíz o Landing Zones con efecto deny. Previene que cualquier equipo aprovisione recursos fuera de las regiones geográficas autorizadas por cumplimiento (ej: solo eastus2 y brazilsouth).
Forzado de Tags Obligatorios
| Estrategia | Efecto de Azure Policy | Comportamiento & Recomendación |
|---|---|---|
| Bloqueo Estricto | Deny |
Rechaza la creación del Resource Group si no incluye las etiquetas requeridas (ej: cost-center, environment, owner). Ideal a nivel de Resource Group. |
| Herencia Automática | Modify |
Propaga automáticamente las etiquetas desde el Resource Group padre hacia los recursos hijos al momento del despliegue mediante una Managed Identity de remediación. Elimina la fricción operativa diaria. |
04. Iniciativas de Seguridad & Gestión de Exenciones
Iniciativas (Policy Sets)
Una Iniciativa agrupa múltiples definiciones de políticas bajo una única asignación con parámetros centralizados. Permite auditar e imponer baselines completos de cumplimiento como:
- Microsoft Cloud Security Benchmark (MCSB)
- CIS Microsoft Azure Foundations Benchmark
- HIPAA / PCI-DSS Compliance Sets
Proporciona un indicador de cumplimiento unificado (Score de Compliance) para toda la organización en lugar de auditar cientos de políticas individuales.
Policy Exemptions (Gestión Auditada de Excepciones)
Cuando un proyecto requiere alejarse del baseline de seguridad por razones operativas justificadas, se utilizan Policy Exemptions formalizadas en lugar de remover la política del ámbito.
Waiver (Exención de Riesgo)
La organización acepta explícitamente el riesgo de no cumplir con la política para ese recurso o suscripción particular.
Mitigated (Riesgo Mitigado)
El control de seguridad es satisfecho por un mecanismo alternativo (ej: un firewall de terceros en lugar del Azure Native Firewall).
💡 Requisito de Gobernanza: Todas las Policy Exemptions deben incluir una fecha de expiración obligatoria y quedar registradas en los logs de auditoría de Azure Resource Manager, asegurando revisiones periódicas de seguridad.