Chiffrement disque FileVault, BitLocker, LUKS : récupération centralisée des clés

Intro

Un employé quitte l'entreprise un vendredi, son MacBook Pro est retourné verrouillé, et la clé FileVault personnelle n'a jamais été escrowée nulle part. Lundi matin, 80 Go de données comptables sont inaccessibles. Ce scénario, reproductible à l'identique avec BitLocker sur Windows ou LUKS sur une station Linux de développeur, arrive plusieurs fois par an dans des PME romandes qui ont activé le chiffrement sans en gérer le cycle de vie.

Pourquoi le chiffrement disque est obligatoire — et insuffisant sans escrow

Le chiffrement intégral du disque (Full Disk Encryption, FDE) figure dans le CIS Controls v8 au contrôle 3.6 (Encrypt Data on End-User Devices) et dans l'axe Protect du NIST Cybersecurity Framework. En Suisse, la nouvelle loi sur la protection des données (nLPD) impose des mesures techniques proportionnées pour protéger les données personnelles dès leur collecte. Un disque non chiffré sur un laptop perdu constitue une violation de données notifiable au Préposé fédéral à la protection des données et à la transparence (PFPDT) si les données concernées sont sensibles (santé, finances, données judiciaires).

Mais activer FileVault ou BitLocker sans centraliser la clé de récupération ne fait que déplacer le risque : de la confidentialité vers la disponibilité. La clé générée lors du premier chiffrement est la seule issue de secours si le mot de passe utilisateur est oublié, si le TPM est effacé, ou si l'OS est réinstallé. Sans escrow, le RSSI dépend entièrement de la présence du collaborateur et de sa bonne mémoire.

Les trois vecteurs de perte de clé les plus fréquents

• Départ de collaborateur : la clé personnelle part avec lui, stockée dans un fichier texte ou jamais sauvegardée.
• Réinstallation OS : macOS Sonoma ou Windows 11 réinstallé proprement regénère une nouvelle clé qui n'est jamais transmise au MDM.
• TPM reset / remplacement carte mère : sous BitLocker, le TPM stocke le volume master key protector ; toute modification matérielle peut déclencher un recovery au boot suivant.

FileVault : escrow via Apple Business Manager et MDM

Sur macOS 11 et supérieur, FileVault 2 utilise XTS-AES-128 sur le volume de données et XTS-AES-256 sur le volume système (Apple Silicon). La clé de récupération personnelle (PRK) est un UUID de 24 caractères. L'escrow institutionnel passe par le MDM via le profil com.apple.security.FDE.

Mécanisme d'escrow MDM

Quand un Mac est supervisé via Apple Business Manager (ABM) et inscrit dans un MDM (Jamf, Kandji, Mosyle, ou une solution maison via le protocole MDM Apple), la commande SecurityInfo retourne l'état FDE et la PRK peut être escrowée automatiquement via la clé de configuration DeferForceAtUserLoginMaxBypassAttempts combinée à ShowRecoveryKey: false. Le flux :

1. Le Mac s'inscrit en DEP/ABM ; le profil FDE est poussé avec Escrow: true.
2. À la première connexion utilisateur post-chiffrement, la PRK est envoyée chiffrée (RSA-2048 certificat du MDM) vers le serveur MDM.
3. Le RSSI consulte la PRK depuis la console MDM avec authentification forte (MFA).
4. Après usage de la PRK pour une récupération, elle doit être régénérée (RotateFileVaultKey MDM command) — sans quoi la même clé pourrait être rejouée.

Piège fréquent : les Macs Intel avec FileVault activé avant l'inscription MDM n'ont pas de PRK escrowée. Il faut désactiver/réactiver FileVault après l'inscription pour forcer l'escrow. Sur Apple Silicon, le Secure Enclave garantit que la clé ne quitte jamais le SoC sous forme claire — seul le wrapping RSA transite.

Rotation et audit

La CIS Benchmark macOS 14 (Sonoma) v1.0.0 recommande de vérifier que la PRK n'est pas présentée à l'utilisateur final (ShowRecoveryKey: false) et que la rotation est planifiée au moins annuellement ou après chaque usage. Stockez les accès aux PRK dans votre SIEM : qui a consulté quelle clé, quand, pour quel ticket.

BitLocker : escrow via Active Directory, Intune ou MBAM

BitLocker opère sur Windows 10/11 Pro et Enterprise avec AES-256-XTS (recommandé CIS Benchmark Windows 11 v2.0.0, section 18.9.11). La clé de récupération est un nombre de 48 chiffres (Recovery Key ID + Recovery Password).

Trois options d'escrow selon l'architecture

• Active Directory (AD DS) : GPO Computer Configuration > Administrative Templates > Windows Components > BitLocker > Fixed Data Drives > Store BitLocker recovery information to AD DS. La clé est stockée dans l'objet ordinateur AD. Accessible via Get-ADComputer -Filter * -Properties msFVE-RecoveryInformation. Inconvénient : AD doit être disponible au moment du chiffrement, et l'accès admin AD donne accès à toutes les clés.
• Microsoft Intune (Endpoint Manager) : pour un parc en Hybrid Azure AD Join ou Azure AD Join. La clé est escrowée dans le tenant Azure AD et visible sous Devices > [Device] > Recovery Keys. Prérequis : policy BitLocker déployée via Intune avec RequireDeviceEncryption: Enabled et AllowWarningForOtherDiskEncryption: Blocked. Compatible Windows Autopilot.
• MBAM (Microsoft BitLocker Administration and Monitoring) : solution on-premise historique, en fin de vie. À migrer vers Intune ou une solution MDM tiers.

Windows Autopilot et BitLocker silencieux

Avec Autopilot en mode Self-Deploying ou User-Driven sur matériel TPM 2.0, BitLocker peut être activé silencieusement pendant l'OOBE. La clé est automatiquement escrowée dans Azure AD/Intune avant la fin du provisioning. Ce flux élimine le scénario du disque chiffré sans clé. Vérifiez que la policy Intune inclut EncryptionMethod: XtsAes256 et non la valeur par défaut AES-CBC-128.

Accès d'urgence et délégation

Dans Intune, le rôle RBAC Help Desk Operator peut être restreint pour afficher les clés BitLocker sans droits d'admin global. Journalisez chaque consultation dans Azure AD Audit Logs (Event ID 88 dans le log Microsoft-Windows-BitLocker-API/Management).

LUKS : escrow centralisé sur Linux avec FleetDM et Tang/Clevis

LUKS (Linux Unified Key Setup) v2 est le standard de chiffrement disque sous Linux. Il utilise AES-256 avec XTS comme mode par défaut. Contrairement à FileVault et BitLocker, il n'existe pas de mécanisme natif d'escrow vers un MDM. Deux approches coexistent dans les parcs Linux d'entreprise.

Tang/Clevis : déchiffrement réseau automatique

Tang est un serveur de déchiffrement réseau (protocole McCallum-Relyea, TCP port 80 ou 443). Clevis est le client côté endpoint. Lors du boot, le disque LUKS se déchiffre automatiquement si le serveur Tang est joignable. Si l'endpoint est hors réseau d'entreprise, le déchiffrement échoue — ce qui constitue un contrôle d'accès géographique intéressant pour les postes fixes (serveurs, stations de travail). Configuration minimale :

1. Installer Tang sur un serveur interne : dnf install tang, générer les clés (tangd-keygen /etc/tang), activer le socket tangd.socket.
2. Sur le client : clevis luks bind -d /dev/sda3 tang '{"url":"https://tang.interne.example.ch"}'.
3. Ajouter clevis-luks-askpass au initramfs : dracut -fv.
4. La passphrase LUKS maître doit être escrowée séparément (voir ci-dessous).

Escrow de la passphrase LUKS via FleetDM

FleetDM (open source, protocole osquery) ne gère pas nativement l'escrow LUKS, mais son API permet d'automatiser un workflow : un script post-provisioning chiffre la passphrase LUKS avec la clé publique RSA du RSSI (stockée dans HashiCorp Vault ou un KMS interne), envoie le blob chiffré via l'API FleetDM, et le log est archivé. Cette approche est moins intégrée que BitLocker/Intune mais reste auditables. Une alternative opérationnelle consiste à stocker la passphrase LUKS dans un gestionnaire de secrets d'entreprise (Vault, CyberArk, Bitwarden Secrets Manager) avec RBAC strict et journalisation.

Cas pratique : MSP romand de 60 endpoints mixtes

Contexte : un MSP vaudois (Lausanne) gérant l'infrastructure de 8 clients PME dispose d'un parc interne de 60 endpoints — 35 MacBook Pro M2/M3 (macOS 14 Sonoma), 20 PC Windows 11 23H2, 5 stations Ubuntu 22.04. Les techniciens travaillent en remote, les machines sont toutes supervisées via ABM pour les Macs et Azure AD Join pour les PC. Aucun serveur on-premise. Budget IT interne : CHF 18 000/an hors licences.

Problème initial

En février 2024, un technicien senior quitte le MSP. Son MacBook Pro (35 Go de configurations clients, scripts, credentials vault local) est retourné. FileVault était actif mais la PRK n'avait jamais été escrowée : le MDM Jamf était configuré sans profil FDE. Récupération impossible. Coût estimé : 3 jours de travail pour reconstituer les accès clients depuis d'autres sources — soit environ CHF 2 400 au tarif journalier interne.

Architecture déployée

1. Macs (35 endpoints) : profil MDM FDE poussé via Jamf avec Escrow: true, ShowRecoveryKey: false, rotation automatique de la PRK après chaque consultation. Les 35 Macs ont été désinscrits/réinscrits en un weekend pour forcer l'escrow (2 techniciens, 4h de travail, CHF 800 de temps interne).
2. Windows 11 (20 endpoints) : Autopilot mode User-Driven avec policy Intune BitLocker XTS-AES-256. Les clés sont visibles dans le portail Intune sous le rôle restreint Help Desk. Rotation annuelle planifiée via script PowerShell (BackupToAAD-BitLockerKeyProtector) déclenché par une tâche planifiée chaque 365 jours.
3. Ubuntu 22.04 (5 stations) : LUKS v2 + Clevis/Tang sur un serveur Tang hébergé dans le réseau virtuel Azure (Standard B1s, CHF 12/mois). Passphrases maîtres stockées dans Azure Key Vault (accès RBAC limité à 2 personnes). FleetDM utilisé pour auditer l'état LUKS via une requête osquery : SELECT slot, key_iterations FROM disk_encryption WHERE encrypted = 1.

Résultat après 6 mois

Taux de couverture escrow : 100 % (60/60 endpoints). Deux incidents de récupération traités en moins de 15 minutes (vs. impossible auparavant). Coût total du déploiement : CHF 3 200 (temps interne + licence Jamf Pro pro-ratisée + VM Tang). ROI positif dès le premier incident évité.

Récapitulatif opérationnel

• Inventoriez l'état du chiffrement avant tout déploiement d'escrow : MDM query, fdesetup status (macOS), manage-bde -status (Windows), lsblk -o NAME,FSTYPE (Linux). Ciblez 100 % de couverture.
• Supervisez les Macs via ABM avant d'activer FileVault : un Mac non supervisé au moment du chiffrement ne peut pas escrower sa PRK automatiquement. Réinscription obligatoire sinon.
• Désactivez l'affichage de la clé à l'utilisateur (ShowRecoveryKey: false sur macOS, AllowWarningForOtherDiskEncryption: Blocked sur Intune) pour éviter que la clé soit notée sur un Post-it.
• Forcez XTS-AES-256 partout où c'est disponible : macOS Apple Silicon (natif), Windows 11 via policy Intune/GPO, LUKS v2 (--cipher aes-xts-plain64 --key-size 512).
• Journalisez chaque consultation de clé : qui, quand, pour quel device, quel ticket. SIEM ou au minimum un log Azure AD/Jamf exporté mensuellement.
• Planifiez la rotation des clés après chaque usage de récupération et au minimum annuellement. Une clé consultée reste valide — ne supposez pas qu'elle a été rendue inutilisable.
• Testez la récupération au moins une fois par an : choisissez un endpoint de test, simulez un boot en recovery, utilisez la clé escrowée. Documentez la procédure dans votre runbook.
• Intégrez le chiffrement dans votre processus de départ : le jour J du départ d'un collaborateur, vérifiez que la clé est bien escrowée AVANT de récupérer la machine. Si ce n'est pas le cas, demandez la clé personnelle en présence du RH.
• Documentez la conformité nLPD : tenez un registre des traitements mentionnant le chiffrement FDE comme mesure technique (art. 8 nLPD). En cas de perte de device, le chiffrement actif réduit significativement l'obligation de notification au PFPDT.

SynGuard propose des audits de couverture FDE et d'architecture d'escrow pour les parcs mixtes macOS/Windows/Linux en Suisse romande.

Sources

• nLPD — Loi fédérale sur la protection des données (Fedlex) — texte consolidé de la nouvelle LPD en vigueur depuis le 01.09.2023.
• PFPDT — Préposé fédéral à la protection des données et à la transparence — autorité de surveillance, guidance sur les violations de données.
• CIS Controls v8 — Center for Internet Security — contrôle 3.6 sur le chiffrement des endpoints.
• NIST Cybersecurity Framework — fonction Protect, catégorie Data Security (PR.DS).
• NCSC — Conseils pour les entreprises (ncsc.admin.ch) — recommandations suisses sur la protection des données et la cybersécurité des PME.