Microsoft AZ-801: Cifrado, certificados y PKI — Guía de estudio

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Forma parte de la Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Descripción general

El cifrado y la infraestructura de clave pública (PKI) forman la base de confianza de un entorno híbrido centrado en Windows Server. Los administradores deben ser capaces de fortalecer los datos en reposo con BitLocker y EFS, establecer y operar una PKI empresarial con AD CS y un Online Responder, automatizar el ciclo de vida de los certificados mediante plantillas e inscripción automática, e integrar la gestión de certificados nativa de la nube a través de Azure Key Vault. Las siguientes secciones detallan la arquitectura, los requisitos previos, los patrones de implementación y los controles operativos que aparecen sistemáticamente en los entornos híbridos de Windows Server del mundo real.

BitLocker y EFS en Windows Server

BitLocker Drive Encryption protege los volúmenes utilizando una combinación del TPM y protectores de clave. TPM 2.0 es la recomendación de base actual; TPM 1.2 sigue siendo compatible, pero TPM 2.0 con UEFI y Secure Boot proporciona una vinculación más fuerte de la cadena de arranque a los Registros de configuración de la plataforma (PCR) del TPM. Para los servidores, exija TPM+PIN en los volúmenes del sistema operativo para añadir un factor en línea, mitigando los ataques de arranque en frío y sin conexión. Configure esto a través de la Directiva de grupo en BitLocker Drive Encryption (Require additional authentication at startup; Allow enhanced PINs for startup). Donde no existe un TPM, es posible usar una clave de inicio USB, pero es inferior desde el punto de vista operativo y menos segura.

La gobernanza de la clave de recuperación es obligatoria. En entornos de AD DS, deposite la información de recuperación en los objetos de equipo (msFVE-RecoveryInformation) a través de la Directiva de grupo (Choose how BitLocker-protected operating system drives can be recovered; Back up recovery passwords and key packages to AD DS). En escenarios de unión a Azure AD, las claves de recuperación se depositan en el objeto de dispositivo de Azure AD y pueden ser descubiertas por administradores autorizados en el panel de Dispositivos; las directivas de Intune pueden exigir el depósito en Azure AD. Valide el depósito antes de habilitar el cifrado a gran escala.

Network Unlock elimina la introducción manual del PIN para los servidores unidos al dominio en subredes seguras del centro de datos durante los reinicios desatendidos. Los requisitos previos incluyen volúmenes del SO protegidos por TPM, firmware UEFI, conectividad por cable sin control de acceso 802.1X en el prearranque, accesibilidad de la difusión (broadcast) de DHCP y un servidor de Windows Deployment Services con la característica Network Unlock y un certificado de autenticación de servidor emitido desde una CA empresarial utilizando la plantilla Network Unlock. Configure las GPO de BitLocker para habilitar Network Unlock y asegúrese de que el servidor WDS pueda alcanzar los OCSP/CRL de la CA. Network Unlock no se aplica a hosts móviles o inalámbricos.

El preaprovisionamiento acelera las implementaciones a gran escala cifrando el espacio usado desde una fase tan temprana como Windows PE durante la creación de imágenes. En las secuencias de tareas de MDT/Configuration Manager, utilice el paso Pre-provision BitLocker (manage-bde -on C: -used -skiphardwaretest) para comenzar el cifrado antes de que se implemente el SO completo; cambie a la protección completa después de la unión al dominio y la aplicación de directivas.

Gestione BitLocker de forma centralizada con Microsoft Endpoint Manager. Intune (MDM) impone el cifrado silencioso con protectores de solo TPM para los dispositivos unidos a Azure AD y deposita las claves en Azure AD; exigir un PIN de inicio impide el cifrado silencioso y requiere la interacción del usuario. Para servidores unidos al dominio y entornos mixtos, utilice Configuration Manager BitLocker Management (el sucesor de MBAM) para informes de cumplimiento, depósito, portales y rotación de claves. Diseñe siempre para un depósito auditable y una asignación de propietarios.

EFS es un cifrado por archivo vinculado a los certificados EFS del usuario. Se genera una clave de cifrado de archivo (FEK) por cada archivo y se cifra con la clave pública EFS del usuario. En ausencia de una CA empresarial, Windows emite un certificado EFS autofirmado, lo que impide la recuperación y el control central. En implementaciones empresariales, emita certificados EFS desde AD CS utilizando la plantilla Basic EFS y designe Agentes de recuperación de datos (DRA) a través de GPO (Public Key Policies, Encrypting File System) para garantizar la recuperabilidad de los archivos cifrados por el usuario. La herramienta de línea de comandos cipher sigue siendo esencial: cipher /e y /d cifran o descifran; cipher /r genera pares de claves de DRA; cipher /u actualiza los archivos cifrados para que usen el certificado EFS actual. Utilice BitLocker para la protección a nivel de volumen y EFS solo cuando se requiera una separación por usuario o por archivo, reconociendo que EFS requiere el inicio de sesión del usuario y la disponibilidad del certificado.

Jerarquía de AD CS y Online Responder

Una PKI empresarial resiliente utiliza una jerarquía de CA por niveles. La CA raíz sin conexión es el ancla de confianza y debe estar aislada física y lógicamente, encendiéndose solo para firmar solicitudes de CA subordinadas y publicar las CRL. Utilice una validez prolongada (por ejemplo, de 10 a 20 años), tamaños de clave RSA grandes (al menos 4096 donde sea factible) y publique los CDP/AIA en URL de alta disponibilidad y con rutas consistentes. Nunca emita certificados de entidad final desde la raíz.

Las CA subordinadas (de emisión) están unidas al dominio, se mantienen en línea y tienen una vida útil corta (por ejemplo, de 3 a 5 años) con un uso de claves y EKU restringidos. Emiten certificados de equipo, usuario y servicio, y publican CRL frecuentes con superposición para evitar interrupciones durante los retrasos en la publicación. Prefiera claves privadas respaldadas por HSM en las CA de emisión para reducir el riesgo de exfiltración de claves. Configure restricciones basadas en el registro o en políticas sobre las plantillas y la emisión para aplicar el principio de privilegio mínimo.

La comprobación de la revocación debe ser rápida y fiable. Un Online Responder (OCSP) reduce la latencia del cliente al responder a consultas de estado por certificado en lugar de descargar las CRL completas. Instale el servicio de rol Online Responder, inscriba a los respondedores para obtener un certificado de firma de respuestas OCSP a través de una plantilla v3 dedicada y configure una configuración de revocación que apunte a la CA de emisión y sus CRL utilizando el proveedor de revocación basado en CRL de Microsoft. Asegúrese de que la CA incluya una URL de OCSP en la extensión de acceso a la información de la autoridad (AIA) para que los clientes sepan dónde consultar.

Para obtener escalabilidad y resiliencia, implemente un array de OCSP. Designe un controlador del array para replicar las configuraciones de revocación a los respondedores miembros. Balancee la carga del array utilizando Windows NLB o un balanceador de carga externo con un sondeo de estado que confirme la capacidad de respuesta de OCSP y la vigencia de los certificados de firma. Fije periodos de vida cortos para los certificados de firma de OCSP y utilice la inscripción automática para su renovación a fin de minimizar la exposición al riesgo. Supervise la actualidad de la CRL y el tiempo de vida de la caché de OCSP para evitar respuestas obsoletas.

Plantillas, inscripción automática, archivo de claves e itinerancia de credenciales

Las plantillas de certificado rigen las restricciones de la solicitud, el nombre del sujeto, los usos de la clave y los requisitos de emisión. Las plantillas de versión 2 (introducidas con Windows Server 2003 Enterprise) permiten la personalización y admiten la inscripción automática con claves basadas en CSP. Las plantillas de versión 3 (Windows Server 2008 y posteriores) añaden soporte para CNG, ECC y algoritmos de Suite B. Elija v3 cuando necesite CNG/ECC; elija v2 para obtener la máxima compatibilidad con sistemas heredados. Vincule las plantillas a un único conjunto de CA de emisión para contener el radio de impacto.

La inscripción automática convierte el ciclo de vida de los certificados en un proceso automatizado controlado por políticas. Configure la Directiva de grupo en Configuración del equipo o Configuración de usuario, Configuración de Windows, Configuración de seguridad, Directivas de clave pública, Cliente de Servicios de certificados – Inscripción automática. Habilítela con las opciones Renovar certificados expirados, Actualizar certificados que usan plantillas de certificado y Quitar certificados revocados/expirados. La inscripción automática requiere permisos en la plantilla: las entidades de seguridad deben tener permisos de Lectura (Read) e Inscripción automática (Autoenroll); el permiso de Inscripción (Enroll) es suficiente solo para la inscripción manual. Delimite el alcance por grupos de seguridad para evitar la emisión inesperada de certificados y controlar el volumen.

El archivo de claves protege los datos si se pierde una clave privada. Habilite la opción Archivar la clave privada de cifrado del sujeto en la plantilla para certificados de solo cifrado (por ejemplo, EFS, S/MIME). Designe Agentes de recuperación de claves (KRA) emitiéndoles certificados KRA desde la plantilla de Agente de recuperación de claves y configure la CA para que archive las claves. La recuperación se limita a los tipos de clave archivables; tradicionalmente, se admite el Intercambio de claves RSA (CSP heredado), mientras que el archivo de claves privadas CNG/ECC no es compatible con la función de archivo de claves de AD CS. No habilite el archivo para plantillas de solo firma.

La itinerancia de credenciales (Credential Roaming) sincroniza los certificados de usuario, las claves privadas y las claves maestras de DPAPI entre dispositivos unidos al dominio almacenándolos en AD. Habilítela mediante la Directiva de grupo en Configuración de usuario, Plantillas administrativas, Sistema, Itinerancia de credenciales, y limite el alcance a usuarios de confianza. Esto mejora la experiencia del usuario para certificados de EFS, S/MIME y de autenticación de cliente en múltiples máquinas sin necesidad de perfiles móviles. Valide la compatibilidad del esquema de directorio y planifique la interacción con Windows Hello for Business y administradores de credenciales de terceros para evitar conflictos o duplicaciones.

Ciclo de vida de TLS/SSL e integración con Azure Key Vault

El TLS moderno depende de la semántica correcta de los certificados. Incluya siempre el EKU de autenticación de servidor y prefiera firmas SHA-256 o más potentes con claves RSA de al menos 2048 bits o curvas ECC apropiadas. El Nombre alternativo del sujeto (SAN) debe enumerar todos los nombres de host que utilizan los clientes; el obsoleto CN del sujeto por sí solo es insuficiente para los clientes modernos. Los certificados comodín (*.contoso.com) simplifican los despliegues de múltiples hosts en una zona DNS, pero no coinciden con nombres de varios niveles (app.dev.contoso.com) ni con zonas diferentes; evalúe cuidadosamente la concentración de riesgos cuando las claves privadas de los comodines se despliegan de forma generalizada. Para necesidades de múltiples zonas, prefiera certificados SAN o múltiples certificados específicos.

Estandarice las CSR con certreq o IIS, mantenga políticas de custodia de claves y automatice la renovación mucho antes de la fecha de caducidad (NotAfter) para permitir despliegues por fases y la propagación de OCSP/CRL. En servidores web unidos a un dominio, la inscripción automática con una plantilla de servidor web v3 puede automatizar la emisión y la renovación; utilice el suministro del nombre del sujeto en la solicitud con las aprobaciones adecuadas. Aplique configuraciones de servidor que solo admitan TLS 1.2/1.3, habilite los conjuntos de cifrado ECDHE para la confidencialidad directa (forward secrecy) y elimine los cifrados SHA-1 obsoletos y los de grado de exportación.

Azure Key Vault extiende el ciclo de vida de los certificados a la nube. Puede importar certificados PFX/PEM existentes, generar nuevos con una autoridad de certificación integrada en Key Vault (por ejemplo, DigiCert) utilizando una directiva de certificado, y configurar la rotación automática para que Key Vault solicite la renovación y mantenga la última versión. El objeto de certificado encapsula una clave y un secreto de Key Vault, permitiendo flujos de trabajo con PFX exportables o claves no exportables respaldadas por HSM según la directiva. Las aplicaciones y los servicios recuperan las versiones actuales a través de RBAC o directivas de acceso e identidades administradas. Las referencias de Key Vault permiten que servicios como Azure App Service y Azure Functions obtengan certificados y secretos por referencia sin incrustarlos en la configuración. Para cargas de trabajo de Windows Server en Azure o híbridas, utilice la extensión de VM de Azure Key Vault o una automatización personalizada con identidades administradas para obtener e instalar certificados actualizados en el almacén de certificados de Windows y desencadenar reinicios de servicios, asegurando renovaciones sin intervención (zero-touch) en servidores web, proxies inversos y puertas de enlace de aplicaciones.

Escenario de problema práctico

Adobe Inc. debe estandarizar el cifrado y la PKI en dos centros de datos locales (on-premises) y en cargas de trabajo de Windows Server alojadas en Azure. Requieren reinicios de servidor desatendidos en los centros de datos, renovaciones automáticas de certificados web, recuperación de cifrado por archivo y una fricción mínima para el usuario.

1. Construir una PKI de dos niveles con una CA raíz sin conexión (offline) y dos CA emisoras en línea

• Por qué: Una CA raíz sin conexión crea un ancla de confianza de alta seguridad, mientras que las CA emisoras de corta duración limitan la exposición y soportan la alta disponibilidad. La jerarquía permite la separación de funciones, el alcance escalable de las plantillas y la publicación segura de CRL/AIA.

2. Desplegar un arreglo de OCSP Online Responder detrás de un balanceador de carga

• Por qué: OCSP proporciona respuestas de revocación de baja latencia para servidores web y de aplicaciones a escala. Un arreglo con balanceo de carga y comprobaciones de estado evita puntos únicos de fallo y asegura que los clientes obtengan un estado actualizado sin descargar grandes CRL.

3. Crear plantillas de certificado v3 para Servidor web, Firma de respuesta OCSP y Autenticación de equipo; plantillas v2 para EFS y S/MIME con archivado de claves

• Por qué: v3 habilita CNG/ECC para el TLS moderno y la firma de respondedores; v2 maximiza la compatibilidad de clientes para EFS/S/MIME y admite el archivado de claves para las claves de cifrado. El alcance de las plantillas impone la emisión con el mínimo privilegio.

4. Habilitar la inscripción automática a través de la Directiva de grupo y asignar permisos de Lectura/Inscripción automática en las plantillas a grupos de seguridad con alcance definido

• Por qué: La inscripción automática elimina los pasos manuales, gestiona las renovaciones antes del vencimiento y limpia los certificados revocados/caducados. El alcance mediante grupos de seguridad evita la sobreemisión y se adhiere al principio de mínimo privilegio.

5. Implementar BitLocker en todos los servidores con TPM+PIN para los volúmenes del SO; depositar las claves de recuperación en AD DS

• Por qué: TPM+PIN aumenta la resistencia a los ataques sin conexión; el depósito en AD DS garantiza la recuperabilidad. Los servidores cumplen los objetivos de tiempo de actividad al tiempo que aseguran una auditabilidad de la custodia de claves a nivel de cumplimiento normativo.

6. Configurar el Desbloqueo de red utilizando WDS con la característica de Desbloqueo de red en las subredes del centro de datos

• Por qué: Se habilitan los reinicios desatendidos después de la aplicación de parches sin acceso a la consola local, manteniendo los controles de seguridad de TPM+PIN fuera del centro de datos. UEFI+TPM y DHCP por cable cumplen los prerrequisitos técnicos.

7. Gestionar la postura de BitLocker con la administración e informes de BitLocker de Configuration Manager

• Por qué: Configuration Manager proporciona una cobertura de servidor madura, paneles de cumplimiento y flujos de trabajo de autoservicio/recuperación, reduciendo la sobrecarga operativa en un entorno mixto local y de Azure.

8. Emitir certificados EFS desde AD CS y configurar los DRA a través de GPO; exigir a los usuarios que hagan una copia de seguridad de sus certificados EFS

• Por qué: La emisión centralizada junto con los DRA garantizan la continuidad del negocio para el cifrado a nivel de archivo. Las claves de los DRA se controlan estrictamente para evitar abusos, manteniendo al mismo tiempo las opciones de recuperación.

9. Centralizar los certificados TLS para cargas de trabajo orientadas a Internet en Azure Key Vault con integración de CA administrada y rotación automática; distribuirlos a Windows Server mediante la automatización de identidades administradas

• Por qué: Key Vault descarga la tarea de renovación, centraliza los secretos, soporta el control de versiones y permite un despliegue seguro y automatizado en los servidores. La rotación automática elimina los vencimientos y se alinea con las operaciones sin intervención (zero-touch).

10. Habilitar el Roaming de credenciales para un conjunto definido de usuarios que requieren EFS y S/MIME en múltiples dispositivos

• Por qué: El Roaming de credenciales sincroniza los certificados y las claves DPAPI, asegurando que los usuarios puedan descifrar y firmar en diferentes estaciones de trabajo sin necesidad de exportar/importar manualmente, lo que mejora la productividad y reduce los tickets de soporte.

← Azure Arc y gestión de servidores híbridos · Todos los dominios · Actualización y gestión de parches de Windows Server →

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

Explorar Microsoft →