PostgreSQLLa base de données la plus sophistiquée au monde.
Documentation PostgreSQL 13.18 » Administration du serveur » Réplication logique » Sécurité

30.7. Sécurité

Un utilisateur capable de modifier le schéma des tables côté souscription peut exécuter un code arbitraire en tant que superutilisateur. Limitez le propriétaire et le droit TRIGGER sur de telles tables aux rôles pour lesquels les superutilisateurs ont confiance. De plus, si les utilisateurs sans confiance peuvent créer des tables, utilisez seulement des publications qui listent explicitement les tables. Autrement dit, créez une souscription FOR ALL TABLES uniquement quand les superutilisateurs ont confiance dans tous les utilisateurs qui ont le droit de créer une table permanente sur le publieur ou l'abonné.

Le rôle utilisée pour la réplication doit avoir l'attribut REPLICATION (ou être un superutilisateur). Si le rôle ne dispose pas des attributs SUPERUSER et BYPASSRLS, les politiques de sécurité niveau ligne du publieur peuvent s'exécuter. Si le rôle n'a pas confiance en tous les propriétaires de tables, incluez options=-crow_security=off dans la chaîne de connexion ;: si un propriétaire de table ajoute ensuite une politique de sécurité ligne, cette configuration imposera un arrêt de la réplication plutôt qu'une exécution de la politique. L'accès de ce rôle à l'instance doit avoir été déclaré dans pg_hba.conf et ce rôle doit avoir l'attribut LOGIN.

Pour être capable de copier les données originales de la table, le rôle utilisé pour la connexion de réplication doit avoir le droit SELECT sur une table publiée (ou être un superutilisateur).

Pour créer une publication, l'utilisateur doit avoir le droit CREATE pour la base de données.

Pour ajouter des tables à une publication, l'utilisateur doit être propriétaire de ces tables. Pour créer une publication qui publie toutes les tables automatiquement, l'utilisateur doit avoir les droits de super utilisateur.

Pour créer un abonnement, l'utilisateur doit avoir les droits de super utilisateur.

Le processus apply lié à un abonnement tournera sur la base de données locale avec les droits d'un superutilisateur.

Les droits ne sont vérifiés qu'une seule fois, au démarrage de la connexion de réplication. Ils ne sont pas re-vérifiés lorsqu'un changement est lu depuis l'éditeur, et ils ne sont pas re-vérifiés non plus à chaque application d'un changement.