Chiffrement intégral vs chiffrement par conteneur : toutes les données doivent-elles être chiffrées ?

La note du Président de l’Université de Lille (ou même le RSSI du CNRS) demande le chiffrement des postes de travail, notamment les portables qui sont exposés au vol ou à la perte. L’objectif principal est la protection des données en cas de perte physique du matériel.

Deux approches sont possibles :

• le chiffrement intégral du disque (BitLocker / FileVault / LUKS) ;
• le chiffrement par conteneur (VeraCrypt, LUKS sur partition dédiée) réservé aux données sensibles.

Le PIT recommande le chiffrement intégral pour les portables, conformément à la directive (II.901/SGDSN/ANSSI). Pour les postes fixes en zone contrôlée, une approche par conteneur chiffré peut être discutée au cas par cas.

Quid de la récupération de données en cas de crash sur un disque chiffré ?

C’est une inquiétude fondée. Sur un disque chiffré intégralement, un crash matériel (contrôleur, secteurs défectueux) rend effectivement la récupération beaucoup plus difficile voire impossible, là où un disque non chiffré permet souvent du file carving partiel.

La réponse à ce risque n’est pas de renoncer au chiffrement, mais de s’assurer que la stratégie de sauvegarde est robuste : les clés de récupération (BitLocker, FileVault) doivent être sauvegardées (et le seront de façon centralisée), et les données critiques doivent être sur un espace sauvegardé ... et non uniquement sur le poste. Le chiffrement protège contre la fuite ; la sauvegarde protège contre la perte. Les deux sont complémentaires, pas contradictoires.

Concernant les tests de crash simulé : c’est une demande légitime. Le PIT n’a pas actuellement documenté les procédures de récupération avec clé de secours et les scénarios de défaillance testés. Nous avions sollicité la DGDNum de l’Université de Lille sur ce dernier point mais nous n’avons pas obtenu de retour.

Mais pourquoi dois-je chiffrer mon poste ?

Le chiffrement protège essentiellement vos données contre deux types de risques : la perte ou le vol de votre ordinateur professionnel. Sans cela, un tiers peut accéder directement aux données du disque. Avec le chiffrement, les données restent inaccessibles sans authentification.

Pourquoi la clé de recouvrement doit-elle être stockée localement et pas dans le cloud ? Pourquoi utiliser un conteneur chiffré en plus de Nextcloud ?

La clé de recouvrement est critique. Elle permet un accès complet aux données du poste. Si elle est stockée dans un espace cloud personnel (Nextcloud ULille ou sDrive) ou non maitrisé (cloud public), une compromission de ce compte pourrait permettre d’accéder aux données. Elle doit donc être conservée dans un environnement maîtrisé par l’établissement.

Dans le cas de Nextcloud ULille ou de sDrive du CNRS, ces outils sécurisent l’accès aux fichiers, mais ne ils garantissent pas toujours un chiffrement de bout en bout indépendant de l’infrastructure. Un conteneur chiffré (comme Zed, édité par Prim’X) permet de protéger les données même en cas de compromission du service de stockage.

Le stockage de données sensibles dans des outils tels que Nextcloud opéré par l’Université de Lille ou encore leur instance de GitLab est-il compatible avec les exigences de confidentialité en environnement réglementé (en l’occurrence, dans un contexte ZRR) ?

Le PIT n’a pas tous les éléments techniques relatifs à l’installation de ces outils, ni les dispositions de sécurité mises en oeuvre. Nous supposons qu’il y a un socle de sécurité minimal qui a été mis en oeuvre ... en l’occurence, ce que l’on appelle du "chiffrement au repos" pour le serveur hébergeant le service et les données associées. Ce mécanisme ne protège pas contre une compromission de GitLab ou un accès administrateur aux données contenues dans un partage Nextcloud. Le premier réflexe à adopter est donc de ne pas stocker de secrets (identifiants, mots de passe, clés de recouvrement, etc.) dans ces outils. Maintenant, dans le cas particulier de GitLab, il n’existe que deux outils qui permettent de chiffrer certains fichiers sensibles.

Le premier d’entre eux est git-crypt. Il permet de réaliser un chiffrement sélectif de fichiers. C’est l’outil le plus mature pour du chiffrement transparent côté client. git-crypt chiffre les fichiers en AES-256 en mode CTR avec un IV synthétique dérivé du SHA-1 HMAC du fichier.

C’est transparent pour l’utilisateur : il travaille en clair localement, et les fichiers sont chiffrés automatiquement au moment du push. Côté serveur GitLab, les fichiers sont stockés chiffrés : si quelqu’un dump la base GitLab ou accède aux dépôts via le système de fichiers, il ne voit que du bruit.

Le gros avantage c’est que ça s’intègre dans le workflow git existant sans rien changer pour vous au quotidien. Mais git-crypt n’est pas le meilleur outil pour chiffrer la totalité des fichiers d’un dépôt. Là où git-crypt excelle, c’est quand la majorité du dépôt est public, mais que quelques fichiers doivent être chiffrés.

Il y a aussi des limitations importantes à connaître : git-crypt ne chiffre pas les noms de fichiers, les messages de commit, les cibles de liens symboliques ni les autres métadonnées. Et git-crypt ne supporte pas la révocation d’accès à un dépôt chiffré auquel l’accès a été précédemment accordé : si un collaborateur part et qu’il avait la clé, vous ne pouvez pas la faire tourner proprement sans recréer le dépôt !!!

La seconde solution proposée est git-remote-gcrypt. git-remote-gcrypt permet de chiffrer un dépôt entier. L’objectif affiché est de fournir un stockage git confidentiel et authentifié en utilisant des hôtes ou services de fichiers non fiables. L’outil va donc chiffrer tout le contenu du dépôt (fichiers, historique, métadonnées) avec GPG avant de le pousser vers le(s) remote(s).

Cette solution a néanmoins un gros bottleneck : chaque git push effectivement fait un —force, et git-remote-gcrypt peut décider de re-packer le remote sans prévenir, ce qui signifie que le push peut soudainement prendre beaucoup plus longtemps ... et donc il peut y avoir des problèmes de performance, en particulier avec des dépôts de taille importante.

Aucune de ces solutions n’est donc parfaitement adaptée à un usage à l’échelle du CRIStAL, et il faut être honnête là-dessus. La gestion des clés GPG et des .gitattributes sur chaque projet est un exercice relativement contraignant. git-crypt reste néanmoins l’option la plus adaptée pour des projets identifiés comme sensibles (au sens PPST) ... surtout pour les équipes de recherche qui manipulent des IRR dans leur code (modèles d’IA, datasets, clés, configs).