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

Un accès bloqué, une clé introuvable

Un poste chiffré sans clé de récupération centralisée n'est pas un actif sécurisé : c'est un futur incident de disponibilité. Quand un MacBook refuse de démarrer après une mise à jour macOS ratée, ou quand un collaborateur oublie son PIN BitLocker en déplacement, la question n'est plus "avons-nous activé le chiffrement ?" mais "où est la clé, et qui peut l'utiliser dans les dix prochaines minutes ?"

En Suisse, l'obligation de protection des données personnelles portées par la nouvelle loi sur la protection des données (nLPD) impose des mesures techniques appropriées pour les données traitées sur les endpoints. Le chiffrement du disque est l'une de ces mesures. Sa gestion — activation, rotation, archivage sécurisé des clés de récupération — doit être documentée et opérationnelle.

Fonctionnement technique des trois solutions

FileVault 2 (macOS)

FileVault 2 chiffre le volume principal en XTS-AES-128 via le T2 ou l'Apple Silicon Secure Enclave. Dès l'activation, macOS génère une clé de récupération personnelle (PRK) de 24 caractères. Sans MDM, cette clé reste côté utilisateur — et se perd. Avec Apple Business Manager (ABM) couplé à un MDM compatible (Jamf, Mosyle, Microsoft Intune, Kandji…), le payload FileVault du profil de configuration active l'Institutional Recovery Key ou le dépôt automatique de la PRK dans la console MDM. La clé est alors stockée chiffrée côté serveur MDM et récupérable par un administrateur authentifié.

Point critique : si le Mac n'est pas supervisé via ABM, le MDM ne peut pas forcer le dépôt de la PRK. Le supervisé est donc une condition préalable, pas une option.

BitLocker (Windows)

BitLocker chiffre les volumes NTFS en AES-XTS 128 ou 256 bits, avec le TPM 2.0 comme gardien de la VMK (Volume Master Key). Deux voies de récupération centralisée coexistent :

• Active Directory / Azure AD (Entra ID) : via GPO ou profil Intune, la clé de récupération (48 chiffres) est automatiquement escrow dans l'objet ordinateur AD ou dans le portail Entra. C'est la méthode standard pour les parcs Windows 11 23H2 déployés via Autopilot.
• MBAM (Microsoft BitLocker Administration and Monitoring) : solution on-premise historique, en fin de vie, à remplacer par le workflow Intune.

Avec Intune, le rapport de chiffrement (Devices → Encryption report) affiche l'état de chiffrement de chaque endpoint et permet d'extraire la clé de récupération pour un appareil donné, sous réserve d'un rôle RBAC approprié. L'accès à cette clé est journalisé dans les audit logs Entra ID.

LUKS (Linux)

Linux Unified Key Setup (LUKS) opère au niveau block device via dm-crypt, typiquement en AES-XTS-plain64 256 bits. LUKS supporte huit slots de clé (LUKS1) ou 32 (LUKS2) : en pratique, slot 0 = passphrase utilisateur, slot 1 = clé de récupération générée aléatoirement (512 bits, encodée base64 ou hex).

La centralisation des clés LUKS est moins standardisée. Trois approches terrain :

• FleetDM + script post-enrôlement : un script shell génère la clé de récupération via cryptsetup luksAddKey, l'exfiltre en HTTPS vers un coffre-fort (HashiCorp Vault, Bitwarden Secrets Manager), puis supprime la passphrase temporaire.
• Tang + Clevis : protocole réseau permettant le déverrouillage automatique au démarrage si le serveur Tang est joignable (réseau interne ou VPN). Sans réseau, la passphrase manuelle reste le fallback.
• Sauvegarde du header LUKS : cryptsetup luksHeaderBackup /dev/sda3 --header-backup-file header.bin stocké dans un coffre. Permet de reconstruire l'accès si le header est corrompu.

Architecture de récupération centralisée : ce qu'il faut mettre en place

Séparation des rôles

La clé de récupération ne doit pas être accessible à l'utilisateur final du poste — sinon elle ne protège plus contre le vol d'identité ou le contournement intentionnel. La chaîne recommandée :

1. Génération : automatique à l'enrôlement MDM ou au premier chiffrement.
2. Dépôt (escrow) : console MDM (Intune, Jamf) ou coffre-fort secret dédié, chiffré au repos.
3. Accès à la clé : réservé aux rôles Help Desk Senior / RSSI, sous authentification forte (MFA, FIDO2) et avec journalisation.
4. Rotation : déclenchée après chaque utilisation d'une clé de récupération, pour éviter la réutilisation.

Le CIS Benchmark macOS 14 Sonoma (section 3.6) et le CIS Benchmark Windows 11 (section 18.9.11) détaillent les valeurs de configuration attendues pour BitLocker et FileVault dans un contexte d'entreprise.

Journalisation des accès aux clés

Chaque consultation d'une clé de récupération doit générer un événement d'audit horodaté (UTC+1/CEST selon la saison) contenant : identifiant du technicien, identifiant de l'appareil (serial number), justification du ticket. Dans Intune, ces événements apparaissent dans les audit logs Entra ID (catégorie KeyManagement). Dans Jamf Pro, le log d'accès FileVault est accessible sous Settings → Logs. Pour LUKS + Vault, le audit log HashiCorp Vault ou le SIEM doit couvrir les lectures de secret.

Rotation automatique des clés

Après récupération d'accès, la clé utilisée est compromise (le technicien la connaît, le ticket est peut-être visible). Procédure de rotation :

• FileVault : commande MDM RotateFileVaultKey (commande MDM Apple, disponible sur macOS 10.15+). La nouvelle PRK est automatiquement escrowed dans le MDM.
• BitLocker : script PowerShell Manage-bde -protectors -delete C: -type recoverypassword suivi de Manage-bde -protectors -add C: -recoverypassword, puis synchronisation Intune. Ou via Intune Remediation.
• LUKS : cryptsetup luksChangeKey pour le slot de récupération, puis réenvoi de la nouvelle clé au coffre.

Cadre légal suisse et implications pratiques

La nLPD (entrée en vigueur le 01.09.2023) et son ordonnance d'exécution OPDo imposent des mesures techniques et organisationnelles (TOM) proportionnées à la sensibilité des données. Le chiffrement des endpoints portant des données personnelles (dossiers RH, données clients, comptabilité) est aujourd'hui une TOM de base attendue par le Préposé fédéral à la protection des données (PFPDT).

Deux obligations découlent directement de la gestion des clés :

• Disponibilité : l'absence de clé de récupération peut constituer une perte de données personnelles (violation de disponibilité), déclenchant potentiellement l'obligation de notification au PFPDT si le risque pour les personnes concernées est vraisemblable (art. 24 nLPD, délai 72h).
• Confidentialité : une clé de récupération stockée en clair dans un ticket Jira, un canal Slack ou un fichier Excel constitue elle-même une violation de données. Le stockage doit être chiffré et l'accès contrôlé.

Pour les entreprises régulées (banques, assurances), la FINMA attend dans sa circulaire 2023/1 que les clés cryptographiques sensibles soient gérées selon une politique documentée, avec séparation des rôles et audit trail.

En cas d'incident ou de doute sur une violation, le signalement au Centre national pour la cybersécurité (NCSC) reste possible et recommandé même hors obligation légale formelle.

Cas pratique : Fiduciaire romande, 45 endpoints

Contexte : Cabinet fiduciaire basé à Lausanne, 38 collaborateurs + 7 prestataires externes. Parc mixte : 22 MacBook Pro (macOS 14 Sonoma), 18 PC Windows 11 23H2, 5 postes Ubuntu 22.04 LTS utilisés par les développeurs d'outils internes. Données traitées : dossiers clients avec numéros AVS, données salariales, déclarations fiscales. Budget IT externalisé à un MSP local.

État initial : FileVault activé sur 14/22 Mac (activation manuelle, PRK notée dans un fichier texte sur le NAS), BitLocker activé via GPO sur 15/18 PC (clés dans AD on-premise non synchronisé avec Entra ID), LUKS non configuré sur les postes Ubuntu. Aucune procédure de rotation, aucun audit trail d'accès aux clés.

Procédure de remédiation déployée sur 6 semaines

1. Semaine 1 — Inventaire : Le MSP extrait via Intune l'état de chiffrement des 18 PC (Devices → Encryption report). Pour les Mac, audit via script osquery déployé par FleetDM : SELECT * FROM disk_encryption WHERE encrypted = 0;. Résultat : 8 Mac non chiffrés, 3 Mac avec PRK inconnue.
2. Semaine 2 — ABM + MDM : Les 22 Mac sont supervisés via Apple Business Manager (token ABM déjà en place). Profil FileVault poussé via MDM avec payload com.apple.MCX.FileVault2 : dépôt automatique de la PRK activé (Defer = false, ForceEnableInSetupAssistant = true). Les 8 Mac non chiffrés démarrent le chiffrement au prochain login utilisateur, PRK escrowed automatiquement.
3. Semaine 3 — BitLocker + Intune : Activation de la synchronisation BitLocker vers Entra ID via profil Endpoint Security → Disk Encryption. Les 18 PC reçoivent le profil ; les clés existantes sont sauvegardées dans Entra ID en moins de 48h. La GPO on-premise est conservée pour compatibilité mais les clés primaires sont désormais dans Intune.
4. Semaine 4 — LUKS : Script post-enrôlement FleetDM déployé sur les 5 Ubuntu : génère une passphrase 64 caractères (openssl rand), l'ajoute au slot 1 LUKS, la POSTe en TLS vers HashiCorp Vault Cloud (HCP) avec auth AppRole. Le slot 0 (passphrase utilisateur) est supprimé — seul le slot 1 (récupération) et le slot 2 (passphrase IT) subsistent.
5. Semaine 5 — Accès et RBAC : Dans Intune, création d'un rôle custom Help Desk Encryption avec permission Read BitLocker keys uniquement. Dans Jamf, rôle limité à la lecture de la PRK FileVault. Dans Vault, policy granulaire : path "secret/luks/*" { capabilities = ["read"] } pour le groupe IT-Support. MFA obligatoire sur tous ces comptes.
6. Semaine 6 — Procédure et test : Simulation : un MacBook Pro est mis en mode Recovery, la PRK est demandée via le ticketing (Freshservice). Le technicien consulte la PRK dans Jamf (audit log généré), déverrouille le Mac, puis déclenche la rotation via commande MDM. Durée totale : 8 minutes. La procédure est documentée dans le runbook IT et validée par le responsable compliance du cabinet. Coût total de la remédiation MSP : CHF 4 800 (40h × CHF 120/h).

Résultat : 100 % des endpoints chiffrés, 100 % des clés de récupération centralisées et auditables, rotation automatique post-utilisation documentée. Le cabinet peut désormais démontrer la conformité nLPD sur cet axe lors d'un audit ou d'une due diligence client.

Récapitulatif opérationnel

• Pré-requis ABM/Autopilot : Tout Mac destiné à être géré doit être supervisé via Apple Business Manager avant enrôlement MDM. Sans supervision, le dépôt automatique de la PRK FileVault n'est pas possible.
• Profil FileVault : Activer le payload com.apple.MCX.FileVault2 avec Defer = false et dépôt PRK activé. Vérifier dans la console MDM que chaque Mac a bien une PRK escrowed (colonne FileVault Key dans l'inventaire).
• BitLocker + Intune : Déployer le profil Endpoint Security → Disk Encryption avec AES-XTS 256 bits et escrow obligatoire dans Entra ID. Vérifier l'Encryption report Intune hebdomadairement — les appareils non conformes doivent générer une alerte.
• LUKS : Générer une clé de récupération aléatoire (≥ 256 bits) au slot 1 dès l'enrôlement, stocker dans un coffre-fort secret (Vault, Bitwarden Secrets Manager) via API TLS. Sauvegarder le header LUKS séparément (luksHeaderBackup).
• RBAC strict : L'accès aux clés de récupération doit être restreint à 1-3 personnes maximum, sous MFA obligatoire, avec journalisation de chaque accès.
• Rotation systématique : Chaque clé consultée est considérée compromise. Déclencher la rotation immédiatement après toute récupération d'accès.
• Test semestriel : Simuler une récupération complète (MacBook, PC, poste Linux) et mesurer le délai de résolution. Objectif : < 15 minutes par endpoint. Documenter dans le registre des tests de résilience.
• Documentation nLPD : Le registre des activités de traitement doit mentionner le chiffrement des endpoints comme mesure technique, avec référence à la procédure de gestion des clés.
• Pas de clé en clair : Interdire explicitement le stockage de clés de récupération dans les tickets de support, e-mails, canaux de messagerie instantanée ou fichiers non chiffrés.
• Endpoints hors MDM : Les appareils personnels (BYOD) ne doivent pas porter de données sensibles si leur chiffrement et la récupération de clé ne peuvent pas être vérifiés et contrôlés.

Un tableau de bord MDM centralisé — qu'il s'agisse d'Intune, Jamf, ou d'une plateforme comme celle proposée par SynGuard — doit afficher en temps réel l'état de chiffrement et la présence d'une clé escrowed pour chaque endpoint. L'absence de l'un ou l'autre doit déclencher une alerte automatique, pas un audit trimestriel.

Sources

• Loi fédérale sur la protection des données (nLPD) — fedlex.admin.ch — Texte consolidé de la nLPD en vigueur depuis le 01.09.2023.
• Ordonnance sur la protection des données (OPDo) — fedlex.admin.ch — Mesures techniques et organisationnelles exigées pour le traitement de données personnelles.
• CIS Benchmarks — cisecurity.org — Référentiels de configuration pour macOS 14, Windows 11 et Linux, incluant les recommandations de chiffrement disque.
• Signalement d'incidents — NCSC (ncsc.admin.ch) — Portail officiel de signalement des cyberincidents pour les entreprises suisses.
• Préposé fédéral à la protection des données et à la transparence (PFPDT) — Autorité de surveillance nLPD, lignes directrices sur les mesures techniques de protection.