Microsoft AZ-801: Chiffrement, certificats et PKI — Guide d'étude

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

Fait partie du Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Le chiffrement et l’infrastructure à clé publique (PKI) constituent le fondement de la confiance d’un environnement hybride centré sur Windows Server. Les administrateurs doivent être capables de renforcer la protection des données au repos avec BitLocker et EFS, d’établir et d’exploiter une PKI d’entreprise avec AD CS et un Répondeur en ligne, d’automatiser le cycle de vie des certificats via des modèles et l’inscription automatique, et d’intégrer la gestion des certificats native du cloud via Azure Key Vault. Les sections suivantes détaillent l’architecture, les prérequis, les modèles de déploiement et les contrôles opérationnels qui apparaissent systématiquement dans les parcs hybrides Windows Server en conditions réelles.

BitLocker et EFS sur Windows Server

Le chiffrement de lecteur BitLocker protège les volumes en utilisant une combinaison du TPM et de protecteurs de clé. TPM 2.0 est la recommandation de base actuelle ; TPM 1.2 reste pris en charge, mais TPM 2.0 avec UEFI et Secure Boot fournit une liaison plus forte de la chaîne de démarrage aux registres de configuration de plateforme (PCR) du TPM. Pour les serveurs, exigez un TPM+PIN sur les volumes du système d’exploitation pour ajouter un facteur en ligne, atténuant ainsi les attaques par démarrage à froid et hors ligne. Configurez cela via une stratégie de groupe sous Chiffrement de lecteur BitLocker (Exiger une authentification supplémentaire au démarrage ; Autoriser les codes confidentiels améliorés pour le démarrage). En l’absence de TPM, une clé de démarrage USB est possible mais inférieure sur le plan opérationnel et moins sécurisée.

La gouvernance des clés de récupération est obligatoire. Dans les environnements AD DS, séquestrez les informations de récupération dans les objets ordinateur (msFVE-RecoveryInformation) via une stratégie de groupe (Choisir comment les lecteurs de système d’exploitation protégés par BitLocker peuvent être récupérés ; Sauvegarder les mots de passe de récupération et les packages de clés dans AD DS). Dans les scénarios de jonction à Azure AD, les clés de récupération sont séquestrées dans l’objet appareil Azure AD et sont détectables par les administrateurs autorisés dans le panneau Appareils ; les stratégies Intune peuvent exiger la séquestration dans Azure AD. Validez la séquestration avant d’activer le chiffrement à grande échelle.

Le déverrouillage réseau élimine la saisie manuelle du code PIN pour les serveurs joints à un domaine dans des sous-réseaux de datacenter sécurisés lors des redémarrages non surveillés. Les prérequis incluent des volumes de système d’exploitation protégés par TPM, un firmware UEFI, une connectivité filaire sans blocage 802.1X au prédémarrage, la joignabilité des diffusions DHCP, et un serveur Windows Deployment Services avec la fonctionnalité de déverrouillage réseau et un certificat d’authentification serveur émis par une autorité de certification d’entreprise utilisant le modèle Déverrouillage réseau. Configurez les GPO BitLocker pour activer le déverrouillage réseau et assurez-vous que l’OCSP/CRL de l’autorité de certification est joignable par le serveur WDS. Le déverrouillage réseau ne s’applique pas aux hôtes mobiles ou sans fil.

Le pré-provisionnement accélère les déploiements à grande échelle en chiffrant l’espace utilisé dès la phase Windows PE lors de la création d’images. Dans les séquences de tâches MDT/Configuration Manager, utilisez l’étape Pré-provisionner BitLocker (

undefined

) pour commencer le chiffrement avant le déploiement complet de l’OS ; passez à la protection complète après la jonction au domaine et l’application des stratégies.

Gérez BitLocker de manière centralisée avec Microsoft Endpoint Manager. Intune (MDM) impose le chiffrement silencieux avec des protecteurs TPM uniquement pour les appareils joints à Azure AD et séquestre les clés dans Azure AD ; l’exigence d’un code PIN de démarrage empêche le chiffrement silencieux et nécessite une interaction de l’utilisateur. Pour les serveurs joints à un domaine et les parcs mixtes, utilisez Configuration Manager BitLocker Management (le successeur de MBAM) pour les rapports de conformité, la séquestration, les portails et la rotation des clés. Concevez toujours en prévoyant une séquestration auditable et un mappage des propriétaires.

EFS est un chiffrement par fichier lié aux certificats EFS de l’utilisateur. Une clé de chiffrement de fichier (FEK) est générée par fichier et chiffrée avec la clé publique EFS de l’utilisateur. En l’absence d’une autorité de certification d’entreprise, Windows émet un certificat EFS auto-signé, ce qui entrave la récupération et le contrôle centralisé. Dans les déploiements d’entreprise, émettez des certificats EFS depuis AD CS en utilisant le modèle EFS de base, et désignez des agents de récupération de données (DRA) via GPO (Stratégies de clé publique, Système de fichiers EFS) pour garantir la récupérabilité des fichiers chiffrés par les utilisateurs. L’outil en ligne de commande cipher reste essentiel :

undefined

chiffrent ou déchiffrent ;

undefined

génère des paires de clés DRA ;

undefined

met à jour les fichiers chiffrés pour utiliser le certificat EFS actuel. Utilisez BitLocker pour la protection au niveau du volume et EFS uniquement lorsqu’une séparation par utilisateur ou par fichier est requise, en reconnaissant qu’EFS nécessite une ouverture de session utilisateur et la disponibilité du certificat.

Hiérarchie AD CS et Répondeur en ligne

Une PKI d’entreprise résiliente utilise une hiérarchie d’autorités de certification (CA) à plusieurs niveaux. L’autorité de certification racine hors ligne est l’ancre de confiance et doit être isolée physiquement et logiquement, mise sous tension uniquement pour signer les demandes des autorités de certification subordonnées et publier les listes de révocation de certificats (CRL). Utilisez une longue durée de validité (par exemple, 10 à 20 ans), de grandes tailles de clé RSA (au moins 4096 si possible), et publiez les CDP/AIA sur des URL hautement disponibles avec des chemins cohérents. N’émettez jamais de certificats d’entité finale depuis la racine.

Les autorités de certification subordonnées (d’émission) sont jointes au domaine, en ligne et ont une durée de vie courte (par exemple, 3 à 5 ans) avec une utilisation de clé et des EKU contraints. Elles émettent des certificats d’ordinateur, d’utilisateur et de service, et publient des CRL fréquentes avec chevauchement pour éviter les pannes lors des retards de publication. Préférez les clés privées sauvegardées par HSM sur les autorités de certification d’émission pour réduire le risque d’exfiltration de clés. Configurez des restrictions basées sur le registre ou les stratégies sur les modèles et l’émission pour appliquer le principe de moindre privilège.

La vérification de la révocation doit être rapide et fiable. Un Répondeur en ligne (OCSP) réduit la latence du client en répondant aux requêtes de statut par certificat au lieu de télécharger des CRL complètes. Installez le service de rôle Répondeur en ligne, inscrivez les répondeurs pour un certificat de signature de réponse OCSP via un modèle v3 dédié, et configurez une Configuration de révocation qui pointe vers l’AC d’émission et ses CRL en utilisant le Fournisseur de révocation basé sur les CRL de Microsoft. Assurez-vous que l’AC inclut une URL OCSP dans l’extension Authority Information Access pour que les clients sachent où envoyer leurs requêtes.

Pour la mise à l’échelle et la résilience, déployez une batterie de répondeurs OCSP. Désignez un contrôleur de batterie pour répliquer les configurations de révocation vers les répondeurs membres. Équilibrez la charge de la batterie en utilisant Windows NLB ou un équilibreur de charge externe avec une sonde de santé qui confirme la réactivité OCSP et la fraîcheur des certificats de signature. Imposez des durées de vie courtes pour les certificats de signature OCSP et l’inscription automatique pour le renouvellement afin de minimiser l’exposition au risque. Surveillez la fraîcheur des CRL et la durée de vie du cache OCSP pour éviter les réponses obsolètes.

Modèles, inscription automatique, archivage de clé et itinérance des informations d’identification

Les modèles de certificat régissent les contraintes de demande, le nom du sujet, les utilisations de clé et les exigences d’émission. Les modèles de version 2 (introduits avec Windows Server 2003 Enterprise) permettent la personnalisation et prennent en charge l’inscription automatique avec des clés basées sur CSP. Les modèles de version 3 (Windows Server 2008 et versions ultérieures) ajoutent le support de CNG, ECC et des algorithmes de la Suite B. Choisissez la v3 lorsque vous avez besoin de CNG/ECC ; choisissez la v2 pour une compatibilité maximale avec les systèmes hérités. Liez les modèles à un ensemble unique d’AC d’émission pour contenir le rayon d’impact.

L’inscription automatique transforme le cycle de vie des certificats en un mécanisme piloté par les stratégies. Configurez la Stratégie de groupe sous Configuration ordinateur ou Configuration utilisateur, Paramètres Windows, Paramètres de sécurité, Stratégies de clé publique, Client des services de certificats – Inscription automatique. Activez-la avec les options Renouveler les certificats expirés, Mettre à jour les certificats qui utilisent des modèles de certificat, et Supprimer les certificats révoqués/expirés. L’inscription automatique nécessite des autorisations sur le modèle : les principaux doivent avoir les autorisations Lecture et Inscription automatique ; l’autorisation Inscrire suffit pour l’inscription manuelle uniquement. Appliquez une portée par groupes de sécurité pour éviter l’émission inattendue de certificats et contrôler le volume.

L’archivage de clé protège les données si une clé privée est perdue. Activez l’option Archiver la clé privée de chiffrement du sujet sur le modèle pour les certificats de chiffrement uniquement (par exemple, EFS, S/MIME). Désignez des Agents de récupération de clé (KRA) en leur émettant des certificats KRA à partir du modèle Agent de récupération de clé et configurez l’AC pour archiver les clés. La récupération est limitée aux types de clés archivables ; traditionnellement, l’échange de clés RSA (CSP hérité) est pris en charge, tandis que l’archivage de clés privées CNG/ECC n’est pas pris en charge par l’archivage de clés AD CS. N’activez pas l’archivage pour les modèles de signature uniquement.

L’itinérance des informations d’identification synchronise les certificats utilisateur, les clés privées et les clés maîtresses DPAPI sur les appareils joints au domaine en les stockant dans AD. Activez-la via la Stratégie de groupe sous Configuration utilisateur, Modèles d’administration, Système, Itinérance des informations d’identification, et définissez la portée aux utilisateurs de confiance. Cela améliore l’expérience utilisateur pour les certificats EFS, S/MIME et d’authentification client sur plusieurs machines sans profils itinérants. Validez la prise en charge du schéma d’annuaire et planifiez l’interaction avec Windows Hello for Business et les gestionnaires d’informations d’identification tiers pour éviter les conflits ou la duplication.

Cycle de vie TLS/SSL et intégration avec Azure Key Vault

Le TLS moderne dépend d’une sémantique de certificat correcte. Incluez toujours l’EKU d’authentification serveur, et préférez les signatures SHA-256 ou plus fortes avec des clés RSA d’au moins 2048 bits ou des courbes ECC appropriées. Le nom alternatif du sujet (SAN) doit lister chaque nom d’hôte que les clients utilisent ; l’ancien nom commun (CN) du sujet seul est insuffisant pour les clients modernes. Les certificats génériques (*.contoso.com) simplifient les déploiements multi-hôtes dans une seule zone DNS mais ne correspondent pas aux noms à plusieurs niveaux (app.dev.contoso.com) ou à des zones différentes ; évaluez soigneusement la concentration des risques lorsque les clés privées génériques sont déployées à grande échelle. Pour les besoins multi-zones, préférez les certificats SAN ou plusieurs certificats ciblés.

Standardisez les CSR avec certreq ou IIS, maintenez des politiques de garde des clés et automatisez le renouvellement bien avant la date d’expiration (NotAfter) pour permettre des déploiements progressifs et la propagation des OCSP/CRL. Sur les serveurs web joints au domaine, l’inscription automatique avec un modèle de serveur web v3 peut automatiser l’émission et le renouvellement ; utilisez la fourniture du nom du sujet dans la requête avec les approbations appropriées. Appliquez des configurations de serveur TLS 1.2/1.3 uniquement, activez les suites de chiffrement ECDHE pour la confidentialité persistante (forward secrecy) et supprimez les chiffrements SHA-1 et de qualité exportation obsolètes.

Azure Key Vault étend le cycle de vie des certificats au cloud. Vous pouvez importer des certificats PFX/PEM existants, en générer de nouveaux avec une autorité de certification intégrée à Key Vault (par exemple, DigiCert) en utilisant une politique de certificat, et définir la rotation automatique pour que Key Vault demande le renouvellement et conserve la dernière version. L’objet certificat encapsule une clé et un secret Key Vault, permettant des flux de travail PFX exportables ou des clés non exportables adossées à un HSM selon la politique. Les applications et les services récupèrent les versions actuelles via le RBAC ou des stratégies d’accès et des identités managées. Les références Key Vault permettent à des services tels qu’Azure App Service et Azure Functions d’extraire des certificats et des secrets par référence sans les intégrer dans la configuration. Pour les charges de travail Windows Server dans Azure ou en mode hybride, utilisez l’extension de machine virtuelle Azure Key Vault ou une automatisation personnalisée avec des identités managées pour récupérer et installer les certificats mis à jour dans le magasin de certificats Windows et déclencher des redémarrages de service, garantissant des renouvellements sans intervention sur les serveurs web, les proxys inverses et les passerelles d’application.

Scénario de problème pratique

Adobe Inc. doit standardiser le chiffrement et la PKI sur deux centres de données sur site et des charges de travail Windows Server hébergées sur Azure. Ils exigent des redémarrages de serveur sans surveillance dans les centres de données, des renouvellements automatisés de certificats web, une récupération du chiffrement par fichier et une friction minimale pour l’utilisateur.

Construire une PKI à deux niveaux avec une autorité de certification racine hors ligne et deux autorités de certification d’émission en ligne

Pourquoi : Une autorité de certification racine hors ligne crée une ancre de confiance à haute assurance, tandis que des autorités de certification d’émission à courte durée de vie limitent l’exposition et supportent la haute disponibilité. La hiérarchie permet la séparation des tâches, une portée de modèle évolutive et une publication sûre des CRL/AIA.

Déployer un réseau de répondeurs OCSP en ligne derrière un équilibreur de charge

Pourquoi : L’OCSP fournit des réponses de révocation à faible latence pour les serveurs web et d’application à grande échelle. Un réseau avec un équilibrage de charge et des vérifications de l’état (health checks) prévient les points de défaillance uniques et garantit que les clients obtiennent un statut à jour sans télécharger de grandes CRL.

Créer des modèles de certificat v3 pour Serveur Web, Signature de Réponse OCSP et Authentification d’ordinateur ; des modèles v2 pour EFS et S/MIME avec archivage de clé

Pourquoi : La v3 active CNG/ECC pour le TLS moderne et la signature des répondeurs ; la v2 maximise la compatibilité client pour EFS/S/MIME et supporte l’archivage de clé pour les clés de chiffrement. La portée des modèles applique l’émission selon le principe du moindre privilège.

Activer l’inscription automatique via une stratégie de groupe (GPO) et attribuer les permissions Lecture/Inscription automatique sur les modèles à des groupes de sécurité délimités

Pourquoi : L’inscription automatique supprime les étapes manuelles, gère les renouvellements avant l’expiration et nettoie les certificats révoqués/expirés. La portée par groupe de sécurité évite l’émission excessive et respecte le principe du moindre privilège.

Mettre en œuvre BitLocker sur tous les serveurs avec TPM+PIN pour les volumes du système d’exploitation ; mettre sous séquestre les clés de récupération dans AD DS

Pourquoi : TPM+PIN augmente la résistance aux attaques hors ligne ; la mise sous séquestre dans AD DS garantit la récupérabilité. Les serveurs atteignent les objectifs de disponibilité tout en assurant une auditabilité de niveau conformité de la garde des clés.

Configurer Network Unlock en utilisant WDS avec la fonctionnalité Network Unlock dans les sous-réseaux du centre de données

Pourquoi : Les redémarrages sans surveillance après l’application de correctifs sans accès à la console locale sont activés tout en conservant les contrôles de sécurité TPM+PIN en dehors du centre de données. UEFI+TPM et un DHCP filaire répondent aux prérequis techniques.

Gérer la posture BitLocker avec la Gestion BitLocker de Configuration Manager et ses rapports

Pourquoi : Configuration Manager fournit une couverture de serveur mature, des tableaux de bord de conformité et des flux de travail de libre-service/récupération, réduisant la charge opérationnelle dans un environnement mixte sur site et Azure.

Émettre des certificats EFS depuis AD CS et configurer les agents de récupération de données (DRA) via GPO ; exiger des utilisateurs qu’ils sauvegardent leurs certificats EFS

Pourquoi : L’émission centralisée ainsi que les DRA garantissent la continuité des activités pour le chiffrement au niveau fichier. Les clés DRA sont étroitement contrôlées pour prévenir les abus tout en maintenant des options de récupération.

Centraliser les certificats TLS pour les charges de travail exposées sur Internet dans Azure Key Vault avec une intégration d’autorité de certification managée et une rotation automatique ; distribuer aux serveurs Windows Server via une automatisation par identité managée

Pourquoi : Key Vault délègue le renouvellement, centralise les secrets, supporte le versionnage et permet un déploiement sécurisé et automatisé sur les serveurs. La rotation automatique élimine les expirations et s’aligne avec les opérations sans intervention.

Activer l’Itinérance des informations d’identification (Credential Roaming) pour un ensemble délimité d’utilisateurs qui ont besoin d’EFS et de S/MIME sur plusieurs appareils

Pourquoi : L’Itinérance des informations d’identification synchronise les certificats et les clés DPAPI, garantissant que les utilisateurs peuvent déchiffrer et signer sur plusieurs postes de travail sans exportation/importation manuelle, améliorant la productivité et réduisant les tickets de support.

← Azure Arc et gestion des serveurs hybrides · Tous les domaines · Mise à jour et gestion des correctifs de Windows Server →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →