Chiffrement serveur transparent avec clevis et tang - 1 - La théorie
Sommaire
Contexte
Un serveur en entreprise destiné à héberger la moindre donnée personnelle doit être chiffrée pour être conforme au RGPD. Un serveur chiffré c'est un serveur qui ne peut plus redémarrer de lui même puisque qu'il faut saisir le mot de passe ou fournir la clé permettant de déchiffrer ses partitions à chaque redémarrage. A moins d'être à coté, nous voilà à la merci de la première coupure d'éléctricité ou du premier redémarrage pour maintenance requis.
Des solutions existent pour contourner ce problème. pam_mount, par exemple, permet de monter une partition chiffrée automatiquement au moment où un utilisateur s'authentifie avec un mot de passe identique à celui de la partition monter. Cette solution pose pourtant plusieurs problèmes. D'abord la connexion à distance par mot de passe est à proscrire au profit de celle par clé ssh ce que pam_mount ne sait pas utiliser. D'autre part, pam_mount suppose que le système aie pu démarrer jusqu'à l'authentification utilisateur, ce qui ne permet par un chiffrement complet du système.
J'en étais là de mes recherches quand je suis tombé sur le couple tang/clevis qui permet d'utiliser le réseau pour déchiffrer automatiquement les partitions d'un serveur au démarrage.
Comprendre les conséquences de ce que l'on fait
La sécurité du chiffrement devient dépendante de la sécurité de votre réseau
La solution présentée ici consiste en un serveur (Tang) installé sur le réseau (public ou interne) et un client (clevis) installé sur le serveur chiffrée dont on souhaite automatiser le déchiffrement au démarrage. Cela signifie que tant que la machine chiffrée aura accès au serveur Tang elle déchiffrera automatiquement sa partition au démarrage.
Il est donc important de s'assurer que le serveur Tang ne répondra aux requêtes que si la machine est bien là ou elle est censé être. Par exemple si le serveur Tang répond aux requêtes sur une ip publique, il faudra bloquer les requêtes qui ne viennent pas de l'ip par laquelle le client est connecté à Internet. Faute de quoi dans le cas où la machine chiffrée est volée et connectée à Internet depuis la connection Internet du voleur, le serveur démarrera et déchiffrera sa partition pour le plus grand bonheur du vouleur.
La même nécessité de contrôle se pose en interne si le serveur utilise une connexion VPN pour se connecter au réseau sur lequel le serveur Tang écoute : La machine volé se connectant au réseau VPN sera également en mesure de contacter Tang pour s'auto-déchiffrer. Dans ce cas la limitation devra être appliqué sur la connexion au VPN en s'assurant que le certificat VPN lié à la machine cliente n'est accepté que depuis une IP bien précise.
Le démarrage du serveur devient dépendant du bon fonctionnement du réseau
Si un problème réseau (connectivité, DNS ...) empêche le client clevis de contacter le serveur Tang au démarrage, le serveur ne pourra plus démarrer correctement. Si l'on utilise Clevis pour déchiffrer une partition de données, on pourra sans doute se connecter au serveur et la monter manuellement et relancer les services qui n'ont pu l'être. Si on utilise Clevis pour monter la partition système on risque de se retrouver avec un serveur inaccessible sans intervention sur site.
On comprend donc la nécessité de mettre en place plusieurs serveur Tang sur notre réseau pour s'assurer qu'on moins l'un d'entre eux sera toujours disponible. Comme nous le verront au moment de passer à la pratique, Clevis intégre cet aspect dans son fonctionnement.
Comment ça marche ?
On voit également que la requête se fait en http ce qui veux dire qu'elle n'est pas chiffrée. Normalement ce devrait être rédibitoire : pourquoi se donner la peine de chiffrer une partition si c'est pour faire circuler le mot de passe en clair sur le réseau ? Sauf que ce n'est pas comme ça que marche clevis. Clevis crée une ressource locale chiffrée contenant le mot de passe de la partition. Seul les élements destinées à reconstituer cette ressource circulent sur le réseau.