PostgreSQL Anonymizer 3.2 corrige des problèmes de sécurité et bloque le masquage exécuté comme superutilisateur. Une mise à niveau doit donc examiner les rôles des traitements existants, leurs sauvegardes et leurs résultats, plutôt que neutraliser la protection pour conserver les anciens scripts.
Bien dater l’annonce et identifier le composant
Le communiqué de PostgreSQL Anonymizer 3.2 est daté du 4 septembre 2026 ; PostgreSQL.org l’a republié le 9 septembre. L’événement est l’annonce du 4 septembre, sans heure de disponibilité supposée. PostgreSQL Anonymizer est une extension : ses correctifs et ses préconditions ne décrivent pas indistinctement tout PostgreSQL. [annonce PostgreSQL.org]
La version 3.2 annonce le blocage du masquage exécuté par un superutilisateur et la migration progressive de pseudo_* vers seeded_*, selon l’annonce de l’éditeur.
Un rapport indépendant décrit deux chemins distincts d’élévation de privilèges reproduits sur 3.1.3 : le premier concerne le propriétaire d’une table sans second acteur privilégié ; le second exige qu’un opérateur privilégié importe un fichier de règles dont le contenu a été influencé par un attaquant. Ces préconditions ne permettent ni d’affirmer une exploitation active, ni d’établir toutes les versions concernées. [rapport 665]
Inventorier les traitements et les rôles
Un rôle est une identité à laquelle PostgreSQL attache des permissions ; un superutilisateur dispose de privilèges qui dépassent ceux d’un rôle applicatif courant. La pseudonymisation remplace une valeur par une autre afin de limiter son identification directe. Son déterminisme signifie qu’avec les mêmes paramètres une même entrée peut produire une même sortie ; une collision est le cas où des entrées distinctes produisent une même valeur. La locale est le paramètre de langue et de région qui influence certains formats. Le masquage statique modifie des données, la réplique produit une copie et l’export produit un jeu externe : ces modes ne se qualifient pas avec les mêmes droits.
Commencez par documenter la version d’extension, le mode de masquage et l’identité effective, sans exécuter de traitement ni modifier une base de production. Ne désactivez pas anon.nosuperuser pour contourner la nouvelle garde.
| Environnement | Version | Mode | Rôle effectif | Propriétaire | Opération | Permission à confirmer | Preuve |
|---|---|---|---|---|---|---|---|
| À renseigner | À vérifier | Statique, réplique ou export | À vérifier | À désigner | À décrire | À confirmer | À joindre |
Qualifier un rôle dédié en test
Les permissions minimales se déduisent des fonctions réellement utilisées et de la documentation de la version cible ; il n’existe pas de commande universelle d’attribution des droits (GRANT) adaptée à tous les traitements. Un plan proposé, non exécuté, commence par une restauration de test autorisée et des données synthétiques. Il vérifie exécution, erreurs, sauvegarde et récupération, puis conserve un retour arrière fondé sur une restauration validée, pas sur une désactivation de garde ou une bascule improvisée.
Ce plan inclut aussi relations, valeurs nulles, collisions et répétition : vérifier qu’une relation reste exploitable, qu’une valeur nulle garde le comportement attendu, que les collisions sont mesurées et que les résultats répétés correspondent à la propriété recherchée. Le déterminisme ne garantit pas l’anonymat. [documentation des fonctions]
Exemple exclusivement synthétique : trois personnes fictives P01, P02 et P03 portent respectivement Personne_A, Personne_B et Personne_A dans un champ nom ; P03 a une valeur facultative nulle. Deux commandes fictives C01 et C02 sont reliées à P01 et P02. La locale, les mêmes paramètres et la même valeur de départ (« graine ») sont consignés pour les répétitions. Aucun de ces enregistrements n’est réel.
| Cas | Attendu | Preuve |
|---|---|---|
| Relations C01→P01 et C02→P02 | Références cohérentes après traitement | NON EXÉCUTÉ |
| Valeur nulle P03 | Comportement documenté et conservé | NON EXÉCUTÉ |
| Collision Personne_A / Personne_B | Collision mesurée, non supposée absente | NON EXÉCUTÉ |
| Répétition mêmes graine et paramètres | Résultat comparé pour le déterminisme voulu | NON EXÉCUTÉ |
| Ancien et nouveau nom de fonction | Comparés sans imposer l’égalité des valeurs | NON EXÉCUTÉ |
| Contraintes du schéma | Résultat contrôlé | NON EXÉCUTÉ |
Traiter le correctif comme un changement contrôlé
La nouvelle famille seeded_* remplace progressivement pseudo_*, qui sont conservées pour compatibilité en 3.2 mais dépréciées, donc destinées à être retirées ultérieurement. Aucune correspondance de valeurs identiques ne doit être supposée. Vérifiez locale, fonctions disponibles et résultats attendus dans la version cible. [annonce 3.2]
Plan proposé et non exécuté : inventaire ; sauvegarde de la configuration, des rôles et des données synthétiques ; restauration isolée ; validation d’un rôle dédié ; tests ; décision d’arrêt ou de bascule ; retour arrière éprouvé par restauration. Il ne s’agit pas d’un retour aveugle à une version antérieure de l’extension. Pour le cadre de continuité et reprise, voir le plan de continuité et de reprise.
Le propriétaire du traitement définit les résultats attendus ; l’administrateur valide les droits et la restauration ; l’équipe qui utilise les données confirme que les relations et contraintes restent exploitables. Un échec de restauration, une permission inexpliquée ou une incohérence de données suspend la bascule. Ce petit jeu permet de vérifier la méthode : il ne mesure pas le risque global de collision ni la résistance à la réidentification sur des données réelles. Consulter la documentation correspondant à la version installée reste nécessaire ; les pages latest peuvent évoluer.