Déployer BitLocker avec Intune sans conflits de stratégies

Résumé

Endpoint Security Disk encryption, Settings Catalog, security baselines, GPO et MECM peuvent exposer des paramètres BitLocker similaires. Intune ne résout pas automatiquement un conflit entre deux configuration policies : je construis une matrice de propriété par setting.

Le chiffrement silencieux dépend du TPM, d’UEFI/Secure Boot, de WinRE, du type de jointure et des paramètres d’authentification. La policy doit être conçue pour l’état existant, notamment les volumes déjà chiffrés.

Le succès comprend chiffrement, protecteur attendu, escrow Entra et processus de récupération testé. Une clé de récupération n’est jamais copiée dans un journal ou un ticket.

Endpoint Security Disk encryption, Settings Catalog, security baselines, GPO et MECM peuvent exposer des paramètres BitLocker similaires. Intune ne résout pas automatiquement un conflit entre deux configuration policies : je construis une matrice de propriété par setting.

Contexte, objectif et périmètre

Les migrations accumulent souvent ancien profil Endpoint Security, baseline, Settings Catalog et GPO FVE. Deux profils qui affichent Succeeded globalement peuvent encore viser différemment un setting ou un appareil.

Déchiffrer tout un parc pour aligner une méthode est une opération lourde et rarement la première réponse. Je documente l’état existant, les capacités de changement in-place et le besoin métier avant décision.

Je traite « Architecture BitLocker sans conflits » comme une chaîne de preuves et non comme une succession de boutons à cliquer. Une action n’est considérée comme réussie que lorsque le résultat est visible au niveau attendu : configuration du service, état reçu par le poste, traitement local, puis remontée cohérente dans les outils d’administration. Cette séparation évite de confondre une affectation valide avec une exécution terminée.

Je conserve systématiquement les heures en UTC et en heure locale, l’identité de l’appareil, le contexte utilisateur ou système, la version de Windows et la version des composants concernés. Sans ces repères, deux événements semblables peuvent appartenir à des cycles différents. Les exemples de journaux sont anonymisés et les identifiants techniques doivent l’être avant tout partage.

La configuration recommandée n’est pas une valeur universelle. Elle constitue un point de départ argumenté, à rapprocher des licences, des contraintes réseau, des responsabilités de support et de la maturité opérationnelle. Lorsque plusieurs méthodes existent, je privilégie celle qui réduit les autorités concurrentes et rend le résultat le plus facilement vérifiable.

Le passage en production suit une progression explicite : validation technique isolée, pilote métier, extension contrôlée puis généralisation. Chaque vague dispose de critères GO et NO-GO, d’une durée d’observation et d’un propriétaire capable d’arrêter ou de revenir en arrière sans attendre une décision improvisée.

• Objectif : désigner une autorité par réglage
• Objectif : déployer silent encryption de façon prédictible
• Objectif : prouver escrow et récupération
• Périmètre : volumes OS Windows 11 gérés
• Périmètre : Endpoint Security/Intune et migration GPO
• Périmètre : TPM-only ou scénarios d’authentification explicitement choisis

Architecture et fonctionnement général

Je recommande Endpoint Security Disk encryption lorsque l’équipe sécurité exploite BitLocker, car la surface est dédiée et le reporting est proche. Settings Catalog reste légitime si la gouvernance centralise tous les settings, mais pas simultanément pour les mêmes nœuds.

Le CSP applique les paramètres, puis le moteur BitLocker décide selon l’état du volume. Les branches PolicyManager et FVE sont des preuves de diagnostic, pas des points de configuration manuelle.

L’escrow est un flux séparé du chiffrement. Je compare l’identifiant du protecteur local au bon objet Entra et je limite les rôles capables d’afficher la clé.

Prérequis techniques et préparation

Avant toute mise en œuvre, je fige le périmètre de test et je capture l’état initial. Cette photographie comprend les versions, les affectations, les autorités de gestion, les dépendances et les exceptions connues. Elle sert autant à interpréter le résultat qu’à construire le retour arrière.

Je vérifie les prérequis sur un appareil réellement représentatif. Une console qui autorise la création d’un profil ne prouve ni l’éligibilité du poste, ni la disponibilité effective de la fonctionnalité dans le tenant. Les prérequis réseau, licence, identité et système doivent tous être confirmés.

• Windows et licence supportés
• TPM prêt, UEFI et Secure Boot
• WinRE actif
• Entra join/hybrid join selon scénario
• inventaire des policies BitLocker/GPO
• RBAC recovery key minimal
• procédure de récupération testée

Procédure de mise en œuvre

La procédure suivante est volontairement découpée en points de contrôle. Je ne poursuis pas lorsqu’un résultat attendu manque : continuer masquerait la première divergence et produirait des symptômes secondaires plus difficiles à interpréter.

Les noms de groupes, profils, applications et fichiers sont des exemples. Je les remplace par les conventions de l’organisation, je documente la population ciblée et je conserve une preuve avant/après pour chaque changement.

Choisir la surface et éviter les conflits

Endpoint Security, Settings Catalog et baselines utilisent désormais des settings issus du même contenu autoritatif pour de nombreux scénarios. Le fait qu’ils affichent les mêmes noms n’autorise pas leur superposition.

Les compliance policies évaluent un état ; elles ne doivent pas être utilisées comme substitut confus à la configuration. Je sépare exigence d’accès, configuration et preuve de chiffrement.

Pendant la migration GPO, je contrôle gpresult, PolicyManager et FVE. Je ne supprime pas les valeurs FVE manuellement : je retire la policy propriétaire et laisse le moteur appliquer l’état supporté.

Silent encryption et état existant

TPM présent ne signifie pas prêt. Je contrôle TpmReady, firmware, Secure Boot, WinRE et erreurs TPM. Un paramètre de PIN au démarrage peut rendre l’expérience non silencieuse.

Un volume déjà chiffré avec une méthode différente peut retourner une erreur plutôt que changer in-place. Je décide si la méthode existante reste acceptable ou si un déchiffrement pilote est justifié.

Le système peut avoir activé Device Encryption avant Intune. Je conserve alors l’historique et je vérifie la propriété des protecteurs et l’escrow avant de modifier la policy.

Recovery, rotation et séparation des rôles

L’accès aux clés est une opération sensible et auditée. Je limite les rôles, impose une justification de ticket et évite toute copie dans les outils non prévus.

Je teste la récupération sur un appareil de laboratoire, puis la rotation après usage si le processus la prévoit. Le nouvel identifiant doit apparaître localement et dans Entra.

Le rollback d’une policy ne signifie pas déchiffrer. Le chiffrement protège encore les données ; je restaure d’abord l’autorité et les protecteurs attendus, puis je décide séparément du volume.

Scripts, commandes et exemples de lecture

Les commandes présentées servent à observer ou illustrer le fonctionnement. Les scripts de diagnostic restent de niveau 1, avec arrêt sur erreur et gestion globale de l’exception. Ils ne modifient pas le poste. Une remédiation serait au minimum de niveau 2, avec mode de simulation, journalisation adaptée au test et comportement de rollback explicitement validé.

Je lis toujours la sortie avec le contexte d’exécution. Une commande lancée dans la session de l’utilisateur ne voit pas nécessairement les mêmes certificats, chemins, variables, applications ou ruches de registre qu’un processus exécuté par l’Intune Management Extension sous SYSTEM.

# Exemple pédagogique non testé — niveau 1
$ErrorActionPreference = 'Stop'
try {
  $v = Get-BitLockerVolume -MountPoint 'C:'
  [pscustomobject]@{ VolumeStatus=$v.VolumeStatus; ProtectionStatus=$v.ProtectionStatus; EncryptionMethod=$v.EncryptionMethod; ProtectorTypes=($v.KeyProtector.KeyProtectorType -join ',') }
  Get-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\BitLocker' -ErrorAction SilentlyContinue
}
catch { Write-Error "Contrôle BitLocker impossible : $($_.Exception.Message)"; exit 1 }

Validation et critères de contrôle

Je valide d’abord le résultat technique sur le poste, puis sa remontée dans le service. Le portail peut conserver un état ancien pendant un certain temps ; inversement, un état vert dans la console ne dispense pas de contrôler l’artefact local réellement attendu.

Le critère GO exige un résultat reproductible, une absence de régression sur les fonctions voisines, une documentation à jour et un retour arrière démontré. Le critère NO-GO s’applique dès qu’une dépendance n’est pas maîtrisée, qu’une partie du parc réagit différemment ou que l’état final ne peut pas être prouvé.

• une autorité par setting
• chiffrement conforme
• protection active
• protecteurs attendus
• escrow confirmé
• récupération testée
• RBAC et audit validés

Journaux, diagnostic et constitution des preuves

Je corrèle DM-EDP, Microsoft-Windows-BitLocker/BitLocker Management, BitLocker-API/Management et System pour TPM. Les rapports Intune sont lus setting par setting.

Les branches HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\BitLocker, Providers et HKLM\SOFTWARE\Policies\Microsoft\FVE aident à reconnaître les autorités, mais ne doivent pas être éditées comme remédiation.

• matrice des settings
• rapport per-setting
• Get-BitLockerVolume
• TPM/SecureBoot/WinRE
• protecteur attendu
• escrow sur bon objet
• journaux BitLocker et DM-EDP

Dépannage : symptômes, preuves et corrections

Je pars de la colonne Symptôme, mais je ne choisis jamais une correction sur ce seul indice. La colonne Preuve indique l’élément qui doit confirmer la cause. Si cette preuve manque, l’hypothèse reste ouverte et l’action proposée ne doit pas être appliquée comme une recette automatique.

Après correction, je reproduis le scénario initial et je compare les mêmes points de mesure. Un changement de symptôme n’est pas toujours une résolution : il peut simplement indiquer que le traitement progresse jusqu’à une nouvelle phase. La chronologie complète reste donc la référence.

Retour arrière et points de vigilance

Le retour arrière ne consiste pas seulement à retirer une affectation. Je restaure l’autorité précédente, la configuration ou la version attendue, puis je vérifie que le poste a effectivement reçu et appliqué ce nouvel état. Les caches et délais de remontée sont documentés au lieu d’être interprétés comme une absence de rollback.

Je conserve les preuves du pilote, le motif de la décision et les écarts rencontrés. Si le service cloud ou une interface évolue, je réévalue les étapes avant une nouvelle vague. Aucun succès obtenu uniquement sur le poste de développement ne constitue une validation de production.

• Rollback : retirer la policy cible du pilote
• Rollback : restaurer l’ancienne autorité documentée
• Rollback : ne déchiffrer qu’avec décision et fenêtre approuvées
• Vigilance : ne jamais exposer une clé
• Vigilance : pas de modification manuelle FVE/PolicyManager
• Vigilance : policy removal ne déchiffre pas
• Vigilance : contrôler les volumes déjà chiffrés