AZ-900
Deep Dive
Políticas, bloqueos, etiquetas y compliance. La gobernanza es cómo una organización mantiene control, visibilidad y cumplimiento sobre todos sus recursos de Azure, especialmente a escala.
Contenido
Gobernanza cloud es el conjunto de procesos, políticas y herramientas que aseguran que los recursos de Azure se usen de forma controlada, segura, consistente y alineada con los requisitos del negocio y regulatorios.
Sin gobernanza: cada equipo despliega lo que quiere, donde quiere, sin tags, sin encriptación, sin control de costos. Con gobernanza: todo recurso cumple las reglas automáticamente.
Problema sin gobernanza
Herramientas de gobernanza
Resultado con gobernanza
Los Management Groups permiten organizar múltiples suscripciones en una jerarquía y aplicar políticas y RBAC a toda la jerarquía con una sola asignación.
Jerarquía completa de Azure
Caso real: empresa multinacional
Root MG: política "todos los recursos deben tener tag cost-center" → aplica a TODA la empresa
MG Europa: política "datos solo en regiones europeas" → cumplimiento GDPR para divisiones EU
MG Producción: política "solo SKUs Premium, encriptación obligatoria" → solo afecta prod
Subscription Dev: política heredada + "permitir SKUs básicos para testing" → dev más flexible
Azure Policy define reglas que los recursos deben cumplir. Se evalúan en tiempo real y pueden auditar, denegar o corregir automáticamente los recursos no conformes.
Efectos de una política
Rechaza la operación si no cumple la regla. El recurso no se crea.
Registra el incumplimiento pero NO bloquea. Útil para visibilidad antes de enforce.
Agrega campos al recurso automáticamente (ej: agregar un tag que falta).
Despliega un recurso de soporte si no existe (ej: activar logging automáticamente).
Modifica propiedades del recurso para hacerlo compliant (ej: habilitar encriptación).
Ejemplos de políticas reales
Encriptación obligatoria en Storage
Si storage sin encriptación → Deny
Caso: Cumplimiento GDPR, HIPAA, ISO 27001
VMs solo en regiones aprobadas
Si región ∉ {WestEurope, NorthEurope} → Deny
Caso: Residencia de datos europeos
Tags obligatorios
Si recurso sin tag "environment" → Deny
Caso: Billing por proyecto/ambiente
SKUs de VM aprobados
Si VM SKU ∉ {B-series, D-series} → Deny
Caso: Control de costos: bloquear VMs caras
Logging habilitado
Si VM sin diagnósticos → DeployIfNotExists logging
Caso: Observabilidad y auditoría obligatoria
HTTPS obligatorio en App Service
Si App Service acepta HTTP → Modify a HTTPS-only
Caso: Seguridad en tránsito
Initiative (Policy Set)
Una Initiative es un grupo de políticas relacionadas que se asignan juntas. Ejemplo: "Cumplimiento PCI-DSS" = 30 políticas individuales (encriptación, logging, acceso, etc.) agrupadas en una sola initiative. Se asigna la initiative una vez y aplica todas las políticas.
Los Resource Locks protegen recursos contra borrado o modificación accidental, independientemente de los permisos RBAC del usuario. Incluso un Owner no puede borrar un recurso con lock, sin primero quitarlo.
CanNotDelete
Los usuarios con acceso pueden leer y modificar el recurso, pero NO pueden eliminarlo. La operación de borrado falla aunque el usuario sea Owner.
Casos de uso
ReadOnly
Los usuarios solo pueden leer el recurso. No pueden modificarlo ni eliminarlo. Similar a asignar Reader a todos, pero a nivel de recurso.
Casos de uso
Herencia de locks
Los locks se heredan hacia abajo. Un lock en un Resource Group protege todos los recursos dentro de ese RG. Un lock en una Subscription protege todos los RGs y recursos de esa Subscription.Para quitar un lock: el usuario necesita permiso específico en Microsoft.Authorization/locks/delete. Esto es intencional — incluso un Owner no puede saltarse el proceso de quitar el lock explícitamente.
Azure tiene más de 90 certificaciones de compliance. Heredas muchas de ellas al usar Azure, pero la responsabilidad compartida significa que tú también debes configurar correctamente.
ISO 27001
Estándar internacional de gestión de seguridad de la información. Aplica a casi todos los sectores.
Aplica: Universal
SOC 1 / SOC 2 / SOC 3
Controles de auditoría de sistemas y organizaciones. SOC 2 evalúa seguridad, disponibilidad, integridad, confidencialidad y privacidad.
Aplica: SaaS, servicios financieros
GDPR
Reglamento General de Protección de Datos de la Unión Europea. Aplica a datos de ciudadanos europeos, independientemente de dónde esté la empresa.
Aplica: EU / datos europeos
HIPAA
Health Insurance Portability and Accountability Act. Protección de datos de salud en EE.UU. Requiere BAA (Business Associate Agreement) con Microsoft.
Aplica: Salud (USA)
PCI DSS
Payment Card Industry Data Security Standard. Para empresas que procesan, almacenan o transmiten datos de tarjetas de crédito/débito.
Aplica: E-commerce, fintech, retail
FedRAMP
Federal Risk and Authorization Management Program. Para servicios cloud usados por el gobierno federal de EE.UU.
Aplica: Gobierno USA
Microsoft Purview Compliance Portal
Dashboard central de compliance en Azure. Muestra el Compliance Score: un puntaje de 0-100 que indica qué tan bien cumple tu tenant con los marcos seleccionados.
Compliance Score
Puntaje general + desglose por marco
Assessment details
Qué controles pasan/fallan y por qué
Improvement actions
Pasos concretos para subir el score
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
¿Qué herramienta de Azure permite definir reglas que impidan crear recursos sin etiquetas de departamento en toda la organización?