Microsoft AZ-500: Gestión de claves, criptografía y certificados — Guía de estudio

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Forma parte de la Microsoft Azure Security Engineer Associate AZ-500 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Información general

La gestión de claves en Azure se centra en Azure Key Vault y Azure Managed HSM. Estos servicios proporcionan almacenamiento seguro de material criptográfico, API consistentes y operaciones auditables que sustentan el cifrado en reposo, en tránsito y la criptografía a nivel de aplicación. El objetivo operativo es separar la custodia de claves del tiempo de ejecución de la aplicación, minimizar el radio de impacto con autorizaciones y redes de alcance limitado, y aplicar la recuperabilidad y la rotación para reducir el riesgo de los secretos de larga duración.

Arquitectura y autorización de Azure Key Vault y Managed HSM

Arquitectura de Azure Key Vault

Composición del servicio: front-ends multiinquilino, particiones regionales para el plano de datos, aislamiento por inquilino y autenticación respaldada por Azure AD. Las claves están protegidas por software (nivel Standard) o por HSM (nivel Premium). Los secretos y certificados siempre están protegidos por software.
Niveles: Standard (claves de software) para uso general y eficiencia de costos; Premium (claves respaldadas por HSM) cuando se requiere protección equivalente a FIPS 140-2 Nivel 2/3 o un límite de HSM dedicado para el material de clave. Elija Premium para requisitos regulatorios o al usar claves con “RSA-HSM” o “EC-HSM”.
Eliminación temporal y protección contra purga: La eliminación temporal está siempre activada con una retención configurable (de 7 a 90 días, comúnmente 90). La protección contra purga, cuando está habilitada, impide la eliminación permanente del almacén o de los objetos hasta que transcurra el período de retención, incluso por parte de usuarios con privilegios elevados. Razonamiento operativo: habilite la protección contra purga en cualquier almacén que respalde claves administradas por el cliente (CMK). Sin ella, una purga accidental o maliciosa podría hacer que los datos dependientes (p. ej., almacenamiento o bases de datos cifradas con esa clave) sean irrecuperables.
Recuperación: Los objetos de almacén eliminados se pueden listar y recuperar; se admite la recuperación a nivel de almacén. Las copias de seguridad producen blobs cifrados que se pueden restaurar en almacenes compatibles en la misma región y nube de Azure. Razonamiento: exporte periódicamente copias de seguridad de las claves y protéjalas por separado; pruebe las restauraciones para validar el RTO.

Modelo de autorización

Modelos de permisos: Directivas de acceso del almacén (heredado) frente a RBAC de Azure (recomendado).
- Directivas de acceso: se definen por almacén; otorgan permisos granulares para claves, secretos y certificados. Son ideales cuando se necesitan derechos de tiempo de ejecución muy específicos por tipo de objeto para un pequeño conjunto de principales.
- RBAC de Azure: establezca el modelo de permisos del almacén en Control de acceso basado en roles de Azure para usar los roles del plano de datos de RBAC. Ventajas: ámbito a nivel de suscripción/grupo de recursos/almacén; asignaciones elegibles para PIM; gobernanza y auditoría centralizadas. Recomendado para nuevas implementaciones y para operaciones administrativas.
Roles de almacén integrados (ejemplos): Key Vault Administrator (gestión completa), Key Vault Crypto Officer (gestión de claves pero no de directivas de acceso), Key Vault Secrets Officer, Key Vault Certificates Officer, Key Vault Reader. Guía operativa:
- Use RBAC (p. ej., Key Vault Administrator) al delegar la configuración de modelos de acceso y ACL de red.
- Use una directiva de acceso o un rol RBAC del plano de datos como Key Vault Certificates Officer para la inserción/eliminación de certificados con privilegios mínimos en un único almacén.
Diseño del ámbito: Prefiera asignar RBAC en el ámbito del almacén para evitar el exceso de privilegios. Use el ámbito de grupo de recursos solo cuando varios almacenes compartan equipos de operadores idénticos; evite las asignaciones a nivel de suscripción para el acceso en tiempo de ejecución.

Managed HSM

Arquitectura y dominios de seguridad: Managed HSM es un clúster de HSM de inquilino único validado con FIPS 140-2 Nivel 3 por cliente. Un dominio de seguridad protege la portabilidad del material de clave del clúster; la copia de seguridad/restauración entre clústeres requiere un quórum de claves privadas del dominio de seguridad. Razonamiento: genere y deposite las claves del dominio entre distintos custodios; pruebe la restauración en un HSM de recuperación ante desastres (DR).
Modelo de roles: Integrado con RBAC de Azure. Los roles incluyen Managed HSM Administrator, Crypto Officer, Crypto User y Reader. Separación de responsabilidades: los administradores gestionan el clúster; los responsables de criptografía gestionan las claves; los usuarios de criptografía usan las claves para las operaciones.
Alta disponibilidad: Redundante regionalmente con múltiples particiones de HSM y un servicio respaldado por un SLA; redundancia de zona disponible en las regiones compatibles. Para la recuperación ante desastres entre regiones, confíe en las copias de seguridad y el dominio de seguridad.
Casos de uso: Procesamiento de pagos, firma de código, encapsulado de claves para el cifrado de sobre y cargas de trabajo reguladas que requieren límites de HSM de Nivel 3.

Objetos y ciclo de vida: claves, secretos, certificados y rotación

Claves, secretos, certificados

Claves: para operaciones criptográficas (firmar, verificar, envolver/desenvolver, cifrar/descifrar). Elija el tipo/tamaño de clave según la fortaleza del algoritmo y el rendimiento (p. ej., RSA 3072/4096 para cumplimiento normativo, o ECC P-256/P-384 para rendimiento).
Secretos: bytes/cadenas de texto arbitrarias como contraseñas, cadenas de conexión y tokens de API. No se utilizan para operaciones criptográficas.
Certificados: X.509 con claves privadas. Se almacenan como un objeto de certificado y un secreto correspondiente (PFX/PEM). Útiles para los ciclos de vida de TLS/MTLS y firma de código.

Operaciones de ciclo de vida y rotación

Versionado: cada operación de establecimiento o importación genera una versión inmutable. Las aplicaciones deben hacer referencia a secretos con versión para un comportamiento determinista o a URIs sin versión para la adopción automática de la última versión, según las necesidades de gestión de cambios.
Estrategias de rotación:
- Claves: prefiera URIs de clave sin versión para los servicios de Azure que las admitan (p. ej., Storage, SQL TDE, secretos gestionados por AKV). Rote añadiendo una nueva versión; los servicios se reasocian automáticamente cuando es compatible. Si un servicio requiere una versión anclada, automatice un paso de reconfiguración. Fuerce la rotación con políticas de rotación de AKV y alertas.
- Secretos: rote a través de Azure Automation, Functions o Logic Apps, desencadenados por notificaciones de Event Grid, o utilice la rotación nativa del proveedor (p. ej., rotación de SAS o contraseñas de bases de datos). Evite los secretos estáticos de larga duración reemplazándolos con identidades administradas siempre que sea posible.
- Certificados: defina políticas de certificado con “acciones de vigencia” (lifetime actions) para la autorrenovación antes del vencimiento; utilice emisores integrados para una renovación sin intervención manual.

Gestión de certificados

Importación/generación: importe PFX/PEM existentes (con clave privada) o genere un CSR y haga que Key Vault complete la emisión con una CA configurada.
Autorrenovación y emisores: configure emisores como DigiCert, GlobalSign o una CA empresarial de Microsoft a través de Key Vault. Habilite la autorrenovación con umbrales de notificación y renovación.
Integración de aplicaciones:
- App Service y Functions: utilice referencias de Key Vault con identidad administrada; la plataforma sincroniza automáticamente los secretos rotados.
- Application Gateway/WAF: haga referencia al ID del secreto del certificado desde Key Vault; el Gateway recoge las nuevas versiones automáticamente.
- AKS: monte certificados a través del driver CSI de Secrets Store y el proveedor de Azure Key Vault.

Ejemplo de asignación de RBAC para operaciones de certificados con privilegios mínimos:

az role assignment create \
  --assignee <userObjectId> \
  --role "Key Vault Certificates Officer" \
  --scope $(az keyvault show -n kv-prod --query id -o tsv)

Seguridad de red e integración de servicios

Redes de Key Vault

Reglas de firewall: establezca en «Redes seleccionadas» (Selected networks) para restringir a orígenes aprobados. Justificación: previene el tráfico con origen en internet incluso con tokens válidos.
Puntos de conexión de servicio de red virtual: permiten el tráfico desde subredes específicas sin IPs privadas. Fáciles de habilitar y reducen la exposición. Úselos cuando necesite un aislamiento rápido y no requiera cambios de DNS.
Puntos de conexión privados: asigne una IP privada al almacén en su VNet para una conectividad verdaderamente privada. Bloquee el acceso a la red pública. Justificación: el control de exfiltración más fuerte, requerido en entornos de alta confianza y cuando el tráfico saliente a internet está restringido.
Servicios de confianza: la opción «Permitir servicios de Microsoft de confianza» (Allow trusted Microsoft services) permite que servicios específicos de Azure accedan al almacén a pesar de las restricciones de red. Requerido para escenarios como el escaneo de claves de cifrado de Storage durante la rotación. Habilítelo de forma restringida y documente las dependencias.

Claves gestionadas por el cliente (CMK) y URIs de clave

Servicios compatibles: Azure Storage, SQL Database (TDE), Synapse, Databricks, cifrado en reposo de secretos de AKS, App Configuration, Event Hubs, Service Bus y Managed Disks a través de Disk Encryption Set.
Estrategia de URI de clave:
- URIs sin versión: prefiera cuando el servicio admita la reasociación automática con nuevas versiones de clave; permite una rotación fluida sin actualizaciones del servicio.
- URIs con versión: requeridas por algunos servicios; automatice una actualización de la configuración del servicio vinculada a los eventos de rotación.
Patrones de rotación:
- Rotación escalonada: cree una nueva versión de la clave; valide que el servicio puede acceder a ella; supervise los errores; luego, opcionalmente, deshabilite las versiones antiguas después de un período seguro.
- Impulsada por eventos: utilice Event Grid en eventos de nueva versión de clave (key-new-version) para desencadenar flujos de trabajo de validación o reconfiguración del servicio.

Integración del cifrado de sobre (envelope encryption)

Los servicios de Azure utilizan una clave de cifrado de datos (DEK) localmente (p. ej., AES-256) y una clave de cifrado de claves (KEK) en Key Vault/HSM para envolver la DEK. Operacionalmente, asegúrese de la disponibilidad de la KEK y del acceso a la red, ya que la pérdida o el bloqueo del acceso pueden detener las operaciones del servicio.

Ejemplo: envolver una DEK con una clave de AKV

# base64-encode a 32-byte DEK; wrap using RSA-OAEP
az keyvault key wrap-key \
  --vault-name kv-prod \
  --name app-kek \
  --algorithm RSA-OAEP \
  --value $(openssl rand -base64 32)

Criptografía, opciones de datos en reposo e higiene de secretos

Conceptos criptográficos básicos

Cifrado simétrico: una sola clave se usa para cifrar/descifrar (p. ej., AES-GCM/CTR). Rápido; ideal para datos masivos.
Cifrado asimétrico: pares de claves pública/privada (RSA/ECC) usados para el intercambio de claves y firmas. Más lento; ideal para establecer confianza y envolver las DEK.
Hashing: resumen unidireccional (p. ej., SHA-256). Para integridad; no es cifrado.
Firma: la clave privada produce una firma; la clave pública la verifica. No repudio e integridad.
Cifrado de sobre (Envelope encryption): combina una KEK asimétrica con una DEK simétrica para mejorar el rendimiento y aislar la custodia de claves.

Azure Disk Encryption y cifrado de almacenamiento

Cifrado predeterminado de Managed Disks: cifrado del lado del servidor (SSE) con claves administradas por la plataforma (PMK). Sobrecarga operativa mínima.
CMK con un Disk Encryption Set (DES): use un DES que haga referencia a una clave de Key Vault o Managed HSM para discos, instantáneas e imágenes. Justificación: control centralizado del ciclo de vida y revocación de claves; cumple con los requisitos de cumplimiento para el control del cliente.
ADE (Azure Disk Encryption): BitLocker (Windows) o dm-crypt (Linux) dentro del sistema operativo invitado. Úselo cuando necesite una postura de cifrado a nivel de sistema operativo, protectores de clave a nivel de disco vinculados al dominio o mandatos de cumplimiento existentes. Contrapartida operativa: mayor complejidad, gestión de extensiones e impacto potencial en el aprovisionamiento de VM.
Doble cifrado:
- Discos: combine SSE con PMK en la capa de infraestructura más una CMK a través de un DES para lograr dos capas de cifrado independientes.
- Cuentas de almacenamiento: use ámbitos de cifrado (encryption scopes) con CMK separadas por contenedor/carga de trabajo; combínelo con el cifrado de infraestructura donde esté disponible para tener dos capas.
Ámbitos de cifrado (Encryption scopes) (Azure Storage): defina ámbitos por contenedor o por blob con CMK distintas para aislar el riesgo del inquilino/carga de trabajo y permitir la rotación selectiva sin un impacto amplio.

Higiene de secretos y prácticas operativas

Identidades administradas (Managed identities): use identidades administradas asignadas por el sistema o por el usuario para que los recursos de Azure obtengan tokens para Key Vault y otros servicios, eliminando las credenciales incrustadas. Defina un alcance estricto para las directivas de acceso o RBAC.
Análisis de secretos: habilite el análisis de secretos de Microsoft Defender for DevOps y GitHub Advanced Security, y las protecciones de repositorio. Intégrelo con las pull requests para bloquear patrones de credenciales conocidos.
Canalizaciones (Pipelines) e IaC: use las integraciones de tareas de Key Vault en Azure Pipelines y las credenciales federadas basadas en OIDC de GitHub Actions para evitar secretos persistentes. No imprima secretos en los registros; enmascare las salidas. Rote cualquier material filtrado de inmediato.
Diseño de aplicaciones: prefiera referencias sin versión cuando sea seguro; almacene en caché mínimamente y gestione los errores 401/403 readquiriendo tokens y volviendo a obtener los secretos para dar soporte a los eventos de rotación.

Análisis Detallado de la Gestión de Certificados

Emisión basada en políticas: Defina el sujeto, los SANs, el uso de la clave, los EKUs, el tipo/tamaño de la clave y la configuración de reutilización de clave en una política de certificados de Key Vault. Justificación: postura de TLS consistente en todos los entornos.
Integración con emisores: Configure un perfil de CA en Key Vault. Para una PKI privada, integre con Microsoft ADCS a través de un emisor personalizado o use el Certificate Connector de Azure Key Vault. Las CA públicas permiten la renovación automatizada sin exponer las claves privadas fuera de AKV.
Operaciones de autorrenovación: Use acciones de ciclo de vida (p. ej., renovar 60 días antes de la expiración; notificar a los 90 días). Operacionalmente, alinee las ventanas de renovación con las congelaciones de cambios y asegúrese de que los servicios dependientes se sincronicen automáticamente.
Consumo por aplicaciones: Recupere como un secreto (PFX/PEM) o vincule por referencia en los servicios de la plataforma. Prefiera las vinculaciones nativas de la plataforma (App Service, Application Gateway) para una transición sin tiempo de inactividad a nuevas versiones. Para Kubernetes, monte mediante CSI para desencadenar reinicios progresivos en la rotación.

Escenario de un Problema Práctico

Siemens AG debe proteger la telemetría de IoT en Azure, forzar una custodia robusta de claves para los datos en reposo y automatizar la rotación de certificados y secretos en una flota distribuida globalmente.

Establecer límites para los almacenes y HSM

Cree Key Vaults Premium regionales para los secretos/certificados de las aplicaciones y un Managed HSM para las operaciones de KEK.
Justificación: Los almacenes Premium permiten claves respaldadas por HSM cuando es necesario; Managed HSM proporciona una garantía de Nivel 3 y una custodia de claves independiente para las operaciones de encapsulado (wrapping).

Forzar la recuperabilidad y las barreras de protección (guardrails)

Habilite la protección contra purga en todos los almacenes y en el Managed HSM; establezca la retención de eliminación temporal en 90 días. Aplique Azure Policy para auditar/denegar los almacenes sin protección contra purga.
Justificación: Previene la pérdida catastrófica de datos por purgas; la política asegura que no puedan ocurrir desviaciones.

Centralizar la autorización usando RBAC

Establezca los almacenes en el modelo de permisos de Azure RBAC. Asigne el rol Key Vault Administrator a un equipo de plataforma pequeño a través de PIM; asigne Key Vault Secrets Officer a los equipos de aplicaciones en el ámbito del almacén; asigne Managed HSM Crypto Officer a los ingenieros de seguridad.
Justificación: RBAC + PIM produce el mínimo privilegio, elevación de privilegios por tiempo limitado y auditoría consistente. La separación de responsabilidades impide que los administradores usen las claves.

Asegurar la red con puntos de conexión privados

Cree puntos de conexión privados en VNets de tipo hub; deshabilite el acceso a la red pública. Habilite los “servicios de confianza” solo para las cuentas de Storage que usan CMK.
Justificación: Los puntos de conexión privados eliminan la exposición pública y bloquean las rutas de exfiltración de datos, al tiempo que preservan los flujos necesarios de servicio a almacén.

Implementar CMK y estrategia de cifrado

Para Storage, defina ámbitos de cifrado por carga de trabajo con URIs de KEK sin versión en el almacén Premium; para Managed Disks, use Disk Encryption Sets con CMK del HSM. Habilite el cifrado a nivel de infraestructura para un doble cifrado.
Justificación: Las claves por carga de trabajo reducen el radio de impacto; los URIs sin versión permiten una rotación sin interrupciones; el doble cifrado satisface un cumplimiento normativo estricto.

Automatizar la rotación de claves y secretos

Configure políticas de rotación de claves de AKV (p. ej., expiración anual, rotar a los 9 meses) y notificaciones de Event Grid que desencadenen trabajos de validación. Use identidades administradas en los servicios; elimine las credenciales estáticas.
Justificación: La rotación predecible y automatizada reduce el riesgo de claves y secretos de larga duración; las identidades administradas reemplazan los frágiles secretos compartidos.

Operacionalizar los certificados

Use políticas de certificados de Key Vault con integración del emisor DigiCert; establezca la autorrenovación 60 días antes de la expiración. Vincule los certificados por referencia en Application Gateway y App Service.
Justificación: La renovación automatizada previene interrupciones y evita el manejo manual de claves; las vinculaciones de la plataforma recogen las nuevas versiones sin necesidad de redespliegues.

Validar y monitorizar

Habilite los registros de diagnóstico de Key Vault y Managed HSM hacia Log Analytics; alerte sobre intentos no autorizados, denegaciones del firewall y eventos de proximidad de expiración. Ejecute pruebas de restauración trimestrales para las copias de seguridad del almacén y del HSM usando el quórum del dominio de seguridad.
Justificación: La monitorización continua detecta configuraciones incorrectas o ataques con prontitud; las pruebas de restauración aseguran la recuperabilidad bajo presión.

← Seguridad de datos · Todos los dominios · Gestión de la postura de seguridad y gobernanza →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →