FAQ chiffrement¶

Est-il possible d’activer un chiffrement au repos (côté base de donnée) ?¶

Le chiffrement au repos (data encryption at rest) est possible en plaçant les données de l’instance PostgreSQL sur un ou plusieurs systèmes de fichiers chiffrés. La création d’un système de fichiers chiffrés peut se faire avec l’outil cryptsetup.

Le chiffrement se fera de manière transparente pour PostgreSQL, mais il aura un impact sur les performances des accès disques. Les données déchiffrées seront chargées en mémoire. Ce qui signifie qu’un attaquant ayant obtenu accès au serveur hôte avec une instance PostgreSQL démarrée aura les mêmes capacités qu’avec une instance non chiffrée. Pour le dire autrement : le chiffrement au repos vous protège contre le vol de matériel ou le vol de sauvegardes des disques

Le chiffrement des partitions de stockage est transparent pour PostgreSQL, mais il ajoute une forte complexité pour les administrateurs de base de données. En particulier, les procédures d’arrêt et démarrage de l’instance PostgreSQL deviennent beaucoup plus complexes.

Voici par exemple les étapes pour démarrer une instance :

Ouvrir le système de fichier chiffré
Saisir le mot de passe de la clé de chiffrement
Monter la partition
Démarrer l’instance PostgreSQL

Il est donc nécessaire qu’un administrateur autorisé intervienne “à la main” pour démarrer chaque instance PostgreSQL. Cela signifie qu’en cas de reboot du serveur hôte, l’instance PostgreSQL ne sera pas redémarrée automatiquement. C’est donc incompatible avec des contraintes de haute disponbilité du service.

Par ailleurs, la gestion des clés de chiffrement est un aspect essentiel. Idéalement il faut installer un service de gestion de clés (Key Management Service ou KMS) pour y stocker les clés de chiffrement de chaque instance. On attribue un mot de passe personnel à chaque administrateur pour qu’il puisse rapatrier la clé de déchiffrement de l’instance depuis le KMS. Lorsqu’un administrateur quitte la société ou perd son mot de passe, on peut simplement supprimer ou modifier son compte sur le KMS sans avoir à changer la clé de chiffrement de la partition.

Est-il possible de chiffrer uniquement certaines colonnes de la bases de données ou par défaut certaines tables uniquement ?¶

Oui PostgreSQL propose une extension nommée pgcrypto qui contient un panel de fonctions de chiffrement/déchiffrement. Vous pouvez choisir de chiffrer simplement une colonne au sein d’une table.

https://docs.postgresql.fr/current/pgcrypto.html

Évidemment, la question des jointures et des index est centrale. Pour une colonne chiffrée, il n’est pas possible d’indexer les données réelles. Pour les jointures, tout dépend du modèle de données :

Si les clés primaires des tables sont des clés techniques (surrogate keys en anglais), c’est-à-dire des données artificielles ajoutées dans la table, alors ces clés n’ont aucun sens en dehors de la base de données et il n’est pas nécessaire de les chiffrer.
Si les clés primaires des tables sont des clés naturelles, donc des données réelles directement liées au sujet (par exemple le numéro de sécurité sociale) et que vous devez chiffrer ces informations, alors vous devrez revoir une grande partie des requêtes de l’application…

Pour les détails, voir : Documentation pgcrypto

Est-ce que ce type de chiffrement est totalement transparent pour l’applicatif ?¶

Le chiffrement au repos est transparent pour PostgreSQL et donc pour l’applicatif.

Le chiffrement interne avec pgcrypto doit être géré par l’application.

Est-ce qu’il risque d’y avoir des dégradations de performances notamment sur des requêtes avec jointures ?¶

Avec le chiffrement au repos, tant qu’une requête est traitée directement en mémoire, il n’y a pas d’impact négatif sur les performances. Si la requête provoque des accès aux données sur disques ( par exemple le scan séquentiel d’une table ), alors il y a un léger surcoût.

Avec le chiffrement interne, cela dépend du nombre de colonnes chiffrées, du volume de données et de la nature des requêtes. Si on imagine un cas simple où l’on chiffre une information précise au sein du modèle de donnée ( par exemple la colonne creditcard dans une table payments ), alors l’impact sur les performances est limité.

Comment peut-on nous visualiser ces données chiffrées pour débogage ou investigation ?¶

Tout dépend donc de la question « qui a la clé de chiffrement ? » :

Avec le chiffrement au repos, l’administrateur de l’instance PostgreSQL a de facto accès à toutes les données.
Avec le chiffrement interne, vous pouvez stocker la clé dans l’application et dans ce cas l’administrateur de l’application aura accès à toutes les données déchiffrées. En revanche, l’administrateur de l’instance PostgreSQL ne verra pas les données réelles.
Avec le chiffrement interne, vous pouvez aussi attribuer une clé unique à chaque utilisateur de l’application. Dans ce cas, ni l’administrateur de l’application, ni l’administrateur de PostgreSQL ne pourront lire les données réelles. Dans ce contexte, il est recommandé d’ajouter un tiers de confiance indépendant de l’utilisateur et de l’application qui conservera les clés de chaque utilisateur et pourra restituer une clé en cas de perte.

Comment chiffrer les sauvegardes ?¶

Avec le chiffrement interne, les données chiffrées sont exportées dans le dump et dans les sauvegarde PITR. Il n’est pas nécessaire d’appliquer un chiffrement supplémentaire.

Avec le chiffrement au repos : les données sont exportées en clair et doivent donc être chiffrées sur le serveur qui hébergent les sauvegardes. Plusieurs outils de sauvegardes gère automantiquement ce chiffrement des sauvegardes. On peut citer notamment PgBackrest qui utilise une phrase de passe et le chiffrement symétrique AES-256 pour chiffrer les sauvegardes avant de les placer sur le dépôt central.

Addendum : Ne pas confondre Chiffrement et Anonymisation¶

Dans le contexte actuel de mise en conformité avec les exigences du RGPD, le chiffrement est souvent considéré à tort comme une méthode d’anonymisation des données. En réalité, le chiffrement est une méthode de « pseudonymisation » c’est-à-dire une transformation des données personnelles en ayant recours à des informations externes (ici la clé et l’algorithme de chiffrement). Si un attaquant arrive à accéder à la fois aux données pseudonymisées et aux informations externes, alors il peut reconstruire les données réelles. Le RGPD reconnaît que la pseudonymisation (et donc le chiffrement) est une méthode de protection des données valables mais indique clairement (lien ci-dessous) que cela ne retire pas le caractère personnel de l’information.

https://www.privacy-regulation.eu/fr/r26.htm

En clair, les données chiffrées restent des données personnelles et demeurent soumises aux RGPD au même titre que les données réelles.

Au-delà de la protection des données contre le vol, si votre objectif est d’anonymiser vos données pour des usages moins critiques (tests d’intégration, développement, analytique, etc.) alors il est possible de masquer les informations sensibles avec des techniques d’anonymisation (randomisation, brassage, généralisation, etc.) qui vont libérer le jeu de données des contraintes RGPD. Nous avons développé l’extension PostgreSQL Anonymizer dans ce but et nous pouvons vous aider si vous avez des questions à ce sujet.

https://postgresql-anonymizer.readthedocs.io/en/latest/