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

Position recommandée

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.

Besoin, cas d’usage et périmètre de la recommandation

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.

Critères de décision et options possibles

Pour Architecture BitLocker sans conflits, je commence par trois résultats concrets: désigner une autorité par réglage, déployer silent encryption de façon prédictible et prouver escrow et récupération. Ils doivent être observables avant de comparer les méthodes disponibles.

L’architecture cible suit Authority → CSP → Engine → Recovery. Chaque composant a un propriétaire clair, un état vérifiable et une méthode de retour arrière; cette répartition évite qu’une seconde politique masque le résultat de la première.

Le pilote contrôle notamment une autorité par setting, chiffrement conforme et protection active. La généralisation ne commence qu’après une période stable et après vérification des exceptions propres aux populations visées.

La recommandation devient mesurable lorsqu’elle relie le besoin à une cible vérifiable. Les résultats attendus sont désigner une autorité par réglage, déployer silent encryption de façon prédictible et prouver escrow et récupération. Les responsabilités se répartissent ainsi: Authority: Une policy possède chaque setting. CSP: BitLocker CSP remet l’intention à Windows. Engine: Windows évalue matériel et volume. Recovery: Entra conserve la clé avec accès audité. Cette répartition permet d’attribuer chaque écart au bon propriétaire et d’éviter qu’un second profil, une ancienne autorité ou une exception silencieuse ne produise un résultat apparemment correct mais impossible à exploiter dans la durée.

Les écarts « Conflict dans Intune », « Silent ne démarre pas », « Erreur sur volume déjà chiffré » et « Clé absente Entra » servent de tests de décision. Pour chacun, la preuve indiquée dans la matrice doit permettre de choisir entre correction, exception temporaire et retour arrière. Le pilote surveille également les points suivants: ne jamais exposer une clé, pas de modification manuelle FVE/PolicyManager, policy removal ne déchiffre pas et contrôler les volumes déjà chiffrés. La valeur cible, le mode de distribution, les contrôles et la sortie de secours sont ainsi évalués ensemble.

Architecture cible et répartition des responsabilités

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, gouvernance et préparation

La préparation de Architecture BitLocker sans conflits couvre 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. Le propriétaire de chaque composant et la population pilote sont définis avant la création de la configuration.

L’état initial est mesuré avec matrice des settings, rapport per-setting, Get-BitLockerVolume, TPM/SecureBoot/WinRE. Il servira de point de comparaison pendant le pilote et lors d’un éventuel retour arrière.

• 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

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.

Configuration recommandée et déploiement par étapes

La méthode retenue pour Architecture BitLocker sans conflits se déploie par les étapes « Construire la matrice d’autorité », « Créer la policy cible », « Migrer un groupe pilote », « Tester la récupération ». Chaque passage produit un résultat vérifiable avant l’ouverture du suivant.

Paramètres, commandes et automatisation

Les commandes et valeurs de cette section servent à vérifier matrice des settings, rapport per-setting, Get-BitLockerVolume, TPM/SecureBoot/WinRE. Chaque exemple précise l’état attendu et les éléments à comparer dans le service.

Le contexte d’exécution, les permissions et les effets sur Authority, CSP, Engine, Recovery doivent rester explicites lorsque la configuration est automatisée.

# Collecte de diagnostic
$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, indicateurs et critères GO / NO-GO

La décision repose sur une autorité par setting, chiffrement conforme, protection active et protecteurs attendus. Ces indicateurs couvrent le résultat technique, l’état du service et l’effet réel sur la population pilote.

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

Exploitation, journaux et contrôle continu

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

Exceptions, erreurs connues et traitement

Les exceptions à prévoir pour Architecture BitLocker sans conflits apparaissent notamment sous la forme Conflict dans Intune, Silent ne démarre pas, Erreur sur volume déjà chiffré, Clé absente Entra. La preuve associée indique s’il faut corriger la configuration ou conserver une exception documentée.

Coût de maintien des exceptions

Une exception à Architecture BitLocker sans conflits crée une charge récurrente: elle doit être identifiée, surveillée et réévaluée jusqu’à sa suppression. Sans propriétaire ni date de revue, cette charge finit par devenir une configuration parallèle difficile à tester.

Rollback, gestion du changement et points de vigilance

Le rollback de Architecture BitLocker sans conflits restaure explicitement l’affectation, la valeur ou l’autorité précédente. Les actions et points de vigilance ci-dessous précisent ce qui doit être contrôlé après ce retour.