Chiffrement et conformité

Vaks PM · Chiffrement, gestion des clés et DORA · juin 2026

Vue d'ensemble et responsabilité partagée

Vaks PM est une application web de gestion de projet conçue pour fonctionner entièrement sur une infrastructure contrôlée par l'organisation (on-premise : sur ses propres serveurs plutôt que sur un service en ligne tiers). Le chiffrement s'applique à quatre couches indépendantes, chacune protégeant une surface différente :

• Champs applicatifs. Un ensemble restreint de colonnes sensibles (par exemple les mots de passe de relais de messagerie, les graines d'authentification multifacteur et les identifiants d'authentification unique) sont chiffrés dans la base de données par l'application elle-même, à l'aide d'un chiffrement par enveloppe avec des clés propres à chaque locataire.
• Volumes des magasins de données. Les disques qui contiennent la base de données et le magasin d'objets sont chiffrés dans leur ensemble, de sorte que l'intégralité du jeu de données (pas seulement les quelques champs secrets) est protégée au repos.
• En transit. Le trafic est chiffré à la bordure publique (HTTPS) et sur les sauts internes entre l'application et ses dépendances.
• Sauvegardes. Les artefacts de sauvegarde sont chiffrés avant de quitter l'hôte.

Glossaire

Acronymes et termes employés tout au long de ce guide, définis ici une fois pour référence.

Correspondance des contrôles DORA

DORA (le Digital Operational Resilience Act, règlement UE 2022/2554) et ses normes techniques d'accompagnement sont fondés sur le risque plutôt que prescriptifs d'un produit particulier. Ils exigent le chiffrement des données au repos et en transit proportionné à la classification des données, ainsi qu'une politique de gestion des clés couvrant le cycle de vie des clés, la rotation et la séparation des tâches. Un HSM ou un KMS tiers n'est pas obligatoire pour la conformité.

« Intégré » = actif dans tout déploiement. « Activé par l'opérateur » = un contrôle que l'opérateur active/fournit depuis l'infrastructure. « KMS/HSM » = garde externe de la KEK, en option.

Classification des données et couches de chiffrement

Toutes les données ne sont pas protégées de la même façon. L'application chiffre un petit ensemble de secrets au niveau des champs ; le gros des données (données métier et données personnelles) repose sur le chiffrement des volumes et du transit, car il doit rester interrogeable. Le tableau ci-dessous indique quelle donnée se situe à quelle classification et quelle couche la protège.

Chiffrement par enveloppe (KEK → DEK → données)

L'application chiffre ses champs sensibles par chiffrement par enveloppe, un schéma de clés à deux couches :

• Une DEK (clé de chiffrement de données), AES-256-GCM, 32 octets, chiffre les champs réels. Il y a une DEK par locataire ; tous les secrets de ce locataire sont chiffrés sous sa DEK unique. La DEK n'est stockée dans la base de données du locataire que sous forme enveloppée (chiffrée), jamais en clair.
• Une KEK (clé de chiffrement de clés), AES-256-GCM, 32 octets, chiffre (« enveloppe ») la DEK. La KEK ne touche jamais les données elles-mêmes ; son unique rôle est de verrouiller et déverrouiller des DEK. Elle réside hors de la base de données, sous forme de fichier de clé monté ou dans un KMS/HSM externe.

Pour lire un secret, l'application déballe la DEK du locataire avec la KEK, puis déchiffre le champ avec la DEK. Pour en écrire un, elle fait l'inverse. Le schéma montre la relation.

Le détail opérationnel pas à pas du trousseau de clés local (générer et activer une KEK, le matériel de clé monté et la rotation) figure dans les guides de déploiement : Docker Swarm et Kubernetes.

Fournisseurs de garde des clés

La KEK est fournie par un fournisseur de clé, sélectionné par le paramètre CRYPTO_KEY_PROVIDER. Trois fournisseurs existent ; chaque clé stockée enregistre quel fournisseur l'a enveloppée, de sorte que les fournisseurs peuvent coexister pendant une migration. Le fournisseur par défaut, le trousseau de clés local, est pleinement conforme à DORA à lui seul ; les fournisseurs externes ajoutent une séparation des tâches stricte, dans laquelle aucun administrateur d'application ne peut exporter la clé.

Les variables de configuration du fournisseur (CRYPTO_KMS_*, CRYPTO_HSM_*), le sidecar de courtier de clés HSM et le placement de ces paramètres par orchestrateur sont configurés dans les guides de déploiement : Kubernetes et Docker Swarm.

Migrer la garde

Comme chaque clé stockée enregistre le fournisseur qui l'a enveloppée, une migration entre fournisseurs est en ligne et réversible : pas d'interruption, pas de rechiffrement des données. Le canevas :

1. Configurer le nouveau fournisseur et régler CRYPTO_KEY_PROVIDER sur kms ou hsm, puis redéployer les services. Les nouvelles DEK sont désormais enveloppées par le nouveau fournisseur ; les DEK existantes se déballent toujours via leur fournisseur actuel, un mélange est donc attendu et correct.
2. Dans Admin → Sécurité et conformité → Clés de chiffrement, cliquer sur Rotation KEK. Chaque DEK est déballée avec son fournisseur actuel et ré-enveloppée sous le nouveau. Répéter par locataire.
3. Surveiller la distribution des clés de données jusqu'à ce que chaque clé affiche le schéma du nouveau fournisseur, puis effectuer un contrôle de déchiffrement (se connecter, ou ouvrir une page de paramètres qui lit une valeur chiffrée).
4. Réversible : conserver disponible le matériel de clé du fournisseur précédent jusqu'à vérification. Le retour arrière consiste à remettre CRYPTO_KEY_PROVIDER et à relancer Rotation KEK.

Rotation des clés

Deux rotations distinctes existent, aux coûts très différents. Les deux sont pilotées depuis Admin → Sécurité et conformité → Clés de chiffrement et requièrent la permission crypto:manage ; les deux sont consignées dans le journal d'audit.

Procédure de rotation et d'incident

La réponse à une compromission présumée de clé dépend de la clé concernée. Consigner chaque incident ; le journal d'audit atteste de chaque opération de clé avec l'acteur, l'heure et le résultat.

Chiffrement des volumes au repos

Le chiffrement au niveau des champs ne protège que les secrets. Pour protéger l'intégralité du jeu de données sur disque (les fichiers de la base de données et les fichiers du magasin d'objets), les volumes de données eux-mêmes sont chiffrés. C'est la couche fournie par l'opérateur ; l'approche diffère selon l'orchestrateur.

Docker Swarm : LUKS2 avec déverrouillage lié au réseau (Clevis + Tang)

Sur la topologie Swarm autogérée, l'amorçage provisionne des volumes LUKS2 adossés à des fichiers pour les magasins de données. Deux volumes sont créés :

• le volume de données de la base de données, monté là où PostgreSQL conserve ses données (de sorte qu'il est chiffré avant que la base ne s'y initialise) ;
• le volume du magasin d'objets, monté là où le serveur S3 conserve ses objets.

Chaque volume est formaté avec le chiffrement aes-xts-plain64 et une clé de 512 bits. Seuls les volumes de données sont chiffrés, pas le disque système de l'hôte ni les autres charges de travail.

La difficulté du chiffrement au repos est de déverrouiller le volume au démarrage sans qu'un humain saisisse une phrase secrète. Vaks PM résout cela par le chiffrement de disque lié au réseau à l'aide de Clevis et de Tang :

• Un serveur Tang est un tout petit serveur de clés réseau sans état (il ne détient aucun secret propre à un client). Sur chaque hôte, il écoute sur un port de réseau interne ; les volumes d'un hôte sont liés aux serveurs Tang s'exécutant sur ses hôtes pairs (jamais lui-même).
• Clevis lie le volume LUKS à une politique. La politique utilise le partage de secret de Shamir (SSS) avec un seuil de 1 réparti sur les serveurs Tang pairs : le volume se déverrouille automatiquement tant qu'au moins un serveur Tang pair est joignable.
• Au démarrage, un petit assistant de déverrouillage et de montage s'exécute avant la base de données (et avant Docker pour le magasin d'objets), attend un serveur Tang pair, déverrouille le volume via Clevis et le monte. Les services applicatifs démarrent ensuite sur un volume déjà monté et déchiffré.

Les commandes d'amorçage exactes (installation de Tang, construction de la politique SSS de Clevis, formatage et liaison de chaque volume, et l'ordonnancement par rapport au démarrage de la base de données) figurent dans déploiement Docker Swarm. Cette section décrit ce que font ces étapes et la politique sous-jacente.

Kubernetes : StorageClass chiffrée

Sur Kubernetes, l'équivalent est une StorageClass chiffrée, déléguée à la plateforme : les volumes persistants de la base de données, du cache et du magasin d'objets sont provisionnés à partir d'une classe adossée au stockage par blocs à clés gérées du fournisseur cloud, à un pilote Container Storage Interface (CSI) avec chiffrement, ou à des nœuds dotés de disques chiffrés. Lorsque les dépendances sont externes/gérées (par exemple un service de base de données géré), utiliser le chiffrement au repos propre à ce fournisseur. C'est un choix au moment de l'installation : le modifier sur un cluster en service implique de migrer les données des volumes. Voir déploiement Kubernetes et le détail de la couche de chiffrement qu'il lie.

TLS interne et autorité de certification dédiée

Le chiffrement couvre la bordure publique (HTTPS sur le proxy inverse) ainsi que le trafic interne du produit. Trois flux internes sont chiffrés :

Une installation neuve exécute le TLS interne d'emblée avec des certificats auto-signés : le trafic est chiffré, mais l'identité du pair n'est pas vérifiée. Les remplacer par des certificats émis par la CA (autorité de certification) propre à l'organisation ajoute la vérification d'identité, qui protège contre un attaquant actif de type homme du milieu.

Spécification du certificat (les points clés)

• Un seul certificat partagé peut couvrir les composants internes, son SAN (autre nom du sujet) listant toutes les adresses IP des hôtes (Swarm) ou le nom de service de la base de données (Kubernetes), plus 127.0.0.1 / localhost. L'ancien champ Common Name n'est plus honoré, renseigner le SAN est donc obligatoire.
• Le Extended Key Usage doit être à la fois serverAuth et clientAuth. Le magasin de coordination utilise le mTLS (chaque nœud est à la fois serveur, puisqu'il écoute, et client, puisqu'il appelle ses pairs), donc un certificat serveur seul est rejeté. C'est l'erreur la plus fréquente : les CA d'entreprise émettent souvent des certificats serveur seuls.
• Type de clé RSA ≥ 2048 bits ou ECDSA P-256 ; signature SHA-256 minimum ; validité selon la politique de la CA (prévoir la rotation avant expiration).

Du CSR au déploiement

Produire un CSR (demande de signature de certificat) portant le SAN et le double EKU, le faire signer par la CA interne (en exigeant qu'elle préserve le SAN et l'EKU et qu'elle retourne la chaîne), et déployer trois fichiers PEM : le certificat feuille, sa clé privée (non chiffrée, permissions 600, possédée par l'utilisateur du service), et le certificat de la CA utilisé comme ancre de confiance. Sur Swarm, les fichiers sont placés sur chaque hôte sous /etc/vaks/ et les ancres de confiance sont repointées vers la CA un nœud à la fois, pour préserver la disponibilité. Sur Kubernetes, le certificat est fourni sous forme de Secret (ou émis par cert-manager) et l'application vérifie la base de données avec PG_TLS / PG_TLS_CA / PG_TLS_MODE.

Le placement des fichiers par orchestrateur, la fourniture d'une autorité de certification dédiée et les commandes de vérification sont traités dans les guides de déploiement : Docker Swarm et Kubernetes.

RGPD : effacement et portabilité

Le chiffrement protège la confidentialité des données ; le RGPD (le règlement général de l'UE sur la protection des données) régit la manière dont les données personnelles sont traitées. Vaks PM met en œuvre deux droits pertinents des personnes concernées sous forme de fonctions produit :

• Droit à l'effacement (Art. 17) par pseudonymisation. Supprimer les enregistrements d'une personne romprait les agrégats de temps, de finance et d'audit qui les référencent ; à la place, le produit écrase les données personnelles (le nom, l'e-mail et les autres identifiants sont remplacés par un pseudonyme non identifiant) tout en conservant intactes les clés étrangères. Les PII disparaissent ; les agrégats historiques survivent et l'intégrité du journal d'audit n'est pas affectée. L'opération est idempotente et auditée.
• Droit à la portabilité des données (Art. 20) par auto-export. Un utilisateur peut exporter ses propres données (profil, saisies de temps, allocations, commentaires, compétences et métadonnées de pièces jointes) sous forme de fichier structuré ; les secrets sont exclus. Un administrateur peut effectuer l'export pour le compte d'un utilisateur.

Ces fonctions et leur administration sont décrites dans le guide du produit : voir Produit : RGPD (anonymisation et portabilité).

Sauvegardes chiffrées

Les artefacts de sauvegarde sont chiffrés à la création avec age, un schéma asymétrique (à clé publique) : une clé de destinataire public se trouve sur l'hôte et scelle chaque artefact, tandis que la clé privée correspondante est conservée en séquestre hors du cluster. L'hôte peut donc créer des sauvegardes chiffrées mais ne peut pas, à lui seul, les déchiffrer.

Comme la KEK réside hors de la base de données, une sauvegarde de base de données ne contient que les DEK par locataire enveloppées plus du texte chiffré. La restaurer ne fonctionne que si le trousseau détient toujours la KEK qui a enveloppé ces DEK. Deux règles de coordination en découlent :

• Sauvegarder le matériel de clé séparément de la base de données (le matériel de la KEK et la clé privée age de sauvegarde), avec une rétention au moins aussi longue que les sauvegardes de base de données qui les référencent. Une sauvegarde de base de données seule ne peut pas être déchiffrée sans ses clés.
• Photographier un inventaire des clés aux côtés de chaque jeu de sauvegarde. Consigner sous quelle KEK les DEK ont été enveloppées et pour quel destinataire age les artefacts ont été scellés, afin qu'un futur opérateur sache exactement quelles clés une sauvegarde donnée requiert.

Récupération de verrouillage et séquestre

L'inventaire de séquestre que tout opérateur doit maintenir hors du cluster :

Liste de vérification

Confirmer que chaque couche est active avant de s'y fier :

• Chiffrement au niveau des champs. GET /admin/crypto/status (ou le panneau d'administration) retourne le fournisseur de KEK actif, la KEK active et la distribution des DEK par KEK. Après une rotation, confirmer que chaque DEK référence la KEK voulue. Le journal de démarrage de l'application liste aussi le trousseau de clés chargé et la clé active.
• Contrôle de déchiffrement. Se connecter, ou ouvrir une page de paramètres d'administration qui lit une valeur chiffrée (par exemple les paramètres de notification / SMTP), pour confirmer que les secrets se déchiffrent de bout en bout.
• Chiffrement des volumes (Swarm). Les volumes de données apparaissent comme des périphériques mappés par LUKS et se déverrouillent automatiquement au démarrage via Clevis/Tang ; confirmer que l'unité de déverrouillage et de montage s'est exécutée avant le démarrage de la base de données.
• Chiffrement des volumes (Kubernetes). Les volumes persistants sont liés à une StorageClass chiffrée ; confirmer la classe employée.
• TLS de bordure externe. Le nom d'hôte de l'organisation se charge en HTTPS avec un certificat valide.
• TLS interne. La base de données rapporte ssl on et affiche des connexions chiffrées ; le magasin de coordination se rapporte en bonne santé ; avec une CA dédiée, openssl verify contre la base de données retourne le code 0.
• Sauvegardes. Les artefacts de sauvegarde sont chiffrés pour le destinataire age configuré et expédiés hors du cluster ; un exercice de restauration réussit contre les clés mises en séquestre.
• Intégrité d'audit. L'ancre d'intégrité quotidienne se vérifie ; le point de terminaison de vérification ne rapporte aucune altération.

À voir aussi : L'application · Architecture technique · déploiement Docker Swarm · déploiement Kubernetes · Exploitation · Démo