Skip to main content

Chiffrement des disques – BitLocker et LUKS : conformité et gestion des clés

S'applique à : Medulla
Version : Toutes versions
Environnement : SaaS / On-Premise
Catégorie : Sécurité / Conformité / Chiffrement

Medulla permet de mettre en place une politique de conformité du chiffrement des disques en s'appuyant sur les modules Packages et Convergence.

Le principe consiste à déployer un package contenant un script capable de contrôler l'état du chiffrement de la machine et d'activer automatiquement le chiffrement lorsqu'il est absent.

Cette approche peut être utilisée avec :

  • BitLocker pour les postes Windows ;
  • LUKS pour les postes Linux.

Principe de fonctionnement :
Medulla assure le ciblage, le déploiement, l'exécution et la réexécution du package. Le script embarqué dans le package assure le contrôle de conformité et l'activation du chiffrement lorsque cela est nécessaire.

Comment mettre automatiquement en conformité un poste ?

Un package Medulla peut exécuter un script de contrôle et d'activation du chiffrement.

Sous Windows, le script peut notamment s'appuyer sur :

Get-BitLockerVolume
manage-bde
Enable-BitLocker

Sous Linux, la logique peut être construite autour des outils de gestion de LUKS, notamment :

cryptsetup

Le script doit être idempotent afin de pouvoir être exécuté régulièrement sans modifier inutilement une machine déjà conforme.

Le fonctionnement peut être le suivant :

  1. Medulla exécute le package sur la machine ciblée ;
  2. le script contrôle l'état réel du chiffrement ;
  3. si le disque est correctement chiffré, aucune action n'est effectuée ;
  4. si le chiffrement est absent, le script l'active selon la politique définie ;
  5. le script contrôle le résultat et retourne son statut dans les logs d'exécution.

Exemple :
Une politique peut cibler l'ensemble des postes Windows 11 concernés. Le package est exécuté sur ces machines et son script détermine lui-même si BitLocker est déjà actif avant d'effectuer une action.

Comment maintenir cette conformité dans le temps ?

Le module Convergence applicative peut être associé au package afin d'assurer son exécution régulière.

La logique de conformité repose alors sur deux niveaux :

Composant Rôle
Medulla Packages / Convergence Ciblage, distribution et exécution régulière du package
Script de conformité Détection de l'état réel du chiffrement et action corrective si nécessaire

La Convergence Medulla s'appuie actuellement sur l'inventaire logiciel pour déterminer la présence d'un package. L'état du chiffrement n'étant pas aujourd'hui un critère natif de cet inventaire, le contrôle chiffré / non chiffré est effectué directement par le script.

Comment cibler les machines concernées ?

Les groupes dynamiques Medulla permettent de cibler les machines à partir des informations disponibles dans l'inventaire, par exemple :

  • le système d'exploitation ;
  • la version du système ;
  • les logiciels et leurs versions ;
  • les autres critères disponibles dans l'inventaire.

On peut ainsi appliquer la politique de chiffrement à un groupe de machines concernées, puis laisser le script déterminer lesquelles nécessitent effectivement une action.

Évolution possible :
L'ajout de l'état du chiffrement comme donnée d'inventaire permettrait à terme de construire directement des groupes dynamiques tels que « postes non chiffrés ». Ce critère n'est pas disponible nativement actuellement.

Quelles informations BitLocker peuvent être contrôlées ?

Le code du module de supervision des postes Windows prévoit déjà une interrogation de BitLocker à l'aide de :

Get-BitLockerVolume

Les informations prévues comprennent notamment :

  • le statut de protection du volume (ProtectionStatus) ;
  • le pourcentage de chiffrement ;
  • la détection d'un chiffrement incomplet ;
  • la présence d'un protecteur TPM ;
  • le type de protecteur utilisé, par exemple Tpm ou RecoveryPassword.

Ce module de supervision n'étant pas encore implémenté en production, la solution disponible aujourd'hui consiste à effectuer ce contrôle directement dans le script du package.

Et pour LUKS sous Linux ?

La même architecture peut être utilisée sous Linux :

Medulla → Package → Script de contrôle → LUKS / cryptsetup.

La détection LUKS n'étant pas actuellement intégrée à l'inventaire Medulla, le script doit effectuer le contrôle de l'état du chiffrement et appliquer, si nécessaire, la politique définie.

La gestion des clés est-elle incluse ?

La mise en conformité peut être orchestrée par Medulla, mais la conservation centralisée des clés de récupération doit actuellement être associée à un système d'escrow externe.

Le script de chiffrement peut ainsi être conçu pour sauvegarder la clé dans le système retenu par l'organisation.

Pour BitLocker, il est par exemple possible d'utiliser un mécanisme d'escrow dans Active Directory ou une solution externe de gestion des clés.

Pour LUKS, la gestion des clés ou passphrases doit de la même manière être confiée à un système sécurisé adapté.

Sécurité :
Les clés de récupération et passphrases ne doivent pas être enregistrées en clair dans les packages, scripts ou journaux d'exécution Medulla.

Synthèse

Besoin Solution avec Medulla
Cibler les postes concernés Groupes Medulla
Contrôler BitLocker Script PowerShell déployé par Packages
Contrôler LUKS Script Linux déployé par Packages
Activer le chiffrement s'il est absent Script de mise en conformité via Packages
Réexécuter régulièrement le contrôle Packages / Convergence
Contrôler uniquement les machines non conformes Contrôle effectué par le script sur chaque machine ciblée
Remonter le résultat de l'action Logs d'exécution du package
Stocker les clés de récupération Escrow Active Directory ou solution sécurisée externe

En résumé :
Oui, une politique de mise en conformité BitLocker ou LUKS peut être mise en place avec Medulla. Medulla assure le ciblage des machines, le déploiement du package et l'exécution régulière du contrôle. Un script personnalisé vérifie l'état du chiffrement et l'active lorsqu'il est absent.

La gestion centralisée des clés de récupération n'est pas intégrée actuellement : elle doit être associée à un mécanisme d'escrow tel qu'Active Directory ou à une solution sécurisée externe.

Back to top