D1 · Identidad, Gobernanza y Monitoreo

Key Vault, Secretos y Claves

Azure Key Vault centraliza secretos, claves criptográficas y certificados. El AZ-305 evalúa el diseño: qué tier elegir según requisitos de HSM y compliance, cómo dar acceso (RBAC vs policies), cuántos vaults, y cómo proteger contra borrado.

Contenido

Secretos, claves y certificados
Standard vs Premium vs Managed HSM
Modelos de acceso: RBAC vs access policies
Protección: soft delete, purge, red
Patrones de diseño y rotación
Tabla de decisión

Secretos, claves y certificados

Secrets

•Strings sensibles: connection strings, passwords, API keys
•La app los LEE — Key Vault los almacena cifrados
•Versionado automático al actualizar
•Mejor aún: eliminar el secreto usando Managed Identity

Keys

•Claves criptográficas RSA/EC — NUNCA salen del vault
•Operaciones dentro del vault: encrypt, decrypt, sign, wrap
•Base de Customer-Managed Keys (CMK) para Storage/SQL/Disks
•Soporte BYOK (Bring Your Own Key) desde HSM on-prem

Certificates

•Ciclo de vida completo de certificados X.509
•Auto-renovación con CAs integradas (DigiCert, GlobalSign)
•App Service/App Gateway los consumen directamente
•Notificaciones de expiración

Standard vs Premium vs Managed HSM

Oferta	Protección de claves	Cuándo elegirla
Key Vault Standard	Claves protegidas por software	Default para secretos, certs y claves sin requisito HSM
Key Vault Premium	Claves respaldadas por HSM FIPS 140-2 Level 2 (multi-tenant)	Compliance que exige HSM (CMK con HSM, PCI). Mismo API, costo moderado
Managed HSM	HSM dedicado single-tenant, FIPS 140-2 Level 3, dominio de seguridad propio	Regulación estricta (banca, gobierno): control total del dominio criptográfico, claves nunca compartidas con otros tenants
Dedicated HSM / Cloud HSM	Appliance HSM dedicado (Thales)	Lift-and-shift de apps que hablan PKCS#11 directamente — sin integración con servicios Azure

Señales en el examen

"FIPS 140-2 Level 2" → Key Vault Premium. "FIPS 140-2 Level 3" o "single-tenant HSM" → Managed HSM. "Solo secretos de aplicación" → Standard basta.

Modelos de acceso: Azure RBAC vs access policies

Azure RBAC (recomendado)

•Roles de data plane: Key Vault Administrator, Secrets User, Crypto Officer...
•Granularidad hasta el secreto individual (scope por objeto)
•Integra con PIM, Conditional Access, deny assignments
•Gobernanza unificada con el resto de Azure
•Default en vaults nuevos y lo que el examen espera como respuesta

Access policies (legacy)

•Lista por-vault de identidades con permisos (get, list, set...)
•Sin granularidad por objeto — permisos sobre TODO el vault por tipo
•Sin PIM ni herencia de management group
•Solo mantener en vaults existentes no migrados

¿Cuántos vaults?

Recomendación: un vault por aplicación, por ambiente, por región. El vault es el límite de seguridad y de throttling — compartir un vault entre apps mezcla blast radius, límites de requests y permisos. Vaults son gratis (pagas por operaciones), no hay razón de costo para compartirlos.

Protección: soft delete, purge protection, red

Borrado y recuperación

• Soft delete (obligatorio): objetos/vault borrados recuperables 7-90 días
• Purge protection: impide el borrado definitivo durante la retención — NADIE puede purgar, ni Microsoft. Irreversible una vez activado
• Obligatorio activar purge protection si el vault guarda CMKs (si purgas la clave, los datos cifrados se pierden para siempre)

Red y resiliencia

• Private Endpoint + deshabilitar acceso público para tráfico solo-VNet
• "Allow trusted Microsoft services" para que servicios Azure accedan pese al firewall
• Replicación automática dentro de la región y a la región emparejada — failover de lectura gestionado por Microsoft
• Logging de auditoría con diagnostic settings (quién accedió a qué secreto)

Patrones de diseño y rotación

Patrón	Cómo
App lee secretos sin credenciales	Managed Identity + rol Key Vault Secrets User
App Service consume secretos transparentemente	Key Vault references en app settings (@Microsoft.KeyVault(...))
AKS consume secretos	Secrets Store CSI Driver con workload identity
Cifrado de Storage/SQL/Disks con clave propia	CMK: clave en Key Vault + managed identity del servicio con permisos wrap/unwrap
Rotación de claves automática	Rotation policy en la clave (auto-rotate) + servicios apuntando a la versión "latest"
Rotación de secretos de terceros	Event Grid (evento near-expiry) → Function que rota en el sistema externo y actualiza el secreto
Cero secretos	El mejor secreto es el que no existe: Managed Identity para todo lo que lo soporte

Tabla de decisión

Requisito	Diseño
Guardar connection strings de una app	Key Vault Standard + Managed Identity + RBAC
CMK con HSM FIPS 140-2 Level 2	Key Vault Premium
Banca exige HSM single-tenant Level 3	Managed HSM
Evitar pérdida de CMKs por purga accidental/maliciosa	Soft delete + purge protection
El vault solo accesible desde la VNet	Private Endpoint + denegar acceso público
Granularidad de permisos por secreto individual	Modelo RBAC (no access policies)
Apps separadas sin compartir blast radius	Un vault por app/ambiente/región
Certificado TLS que se renueva solo	Key Vault certificate con CA integrada y auto-renewal

¿Entendiste este tema?

Pon a prueba lo que acabas de aprender

Un banco diseña el cifrado de sus datos en Azure: las claves de cifrado deben (1) estar en un HSM validado FIPS 140-2 Level 3 de tenant único, (2) ser irrecuperablemente protegidas contra purga, y (3) usarse como Customer-Managed Keys para Storage y SQL. ¿Qué solución eliges?

Inicia sesión para llevar tu progreso.

AnteriorDiseño de MonitoreoIdentidad, Gobernanza y Monitoreo SiguienteDiseño de Datos RelacionalesAlmacenamiento de Datos