Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Scénarios de déplacement de données pg_columnmask dans Aurora PostgreSQL

pg_columnmaskle comportement varie selon les différentes opérations de déplacement de données selon que l'opération a lieu au niveau de la couche de stockage, de la logique ou de l'application. Les opérations au niveau du stockage (telles que le clonage) se comportent différemment des opérations logiques (telles quepg_dump) et des opérations au niveau des applications (telles que les requêtes FDW). Cette section décrit le comportement de masquage pour les scénarios courants, notamment la réplication, les sauvegardes, les exportations et les migrations, et explique les implications de sécurité de chacun d'entre eux.

Base de données globale Aurora et répliques de lecture

Les pg_columnmask politiques Aurora sont stockées dans les tables du système de base de données au sein du volume du cluster. Toutes les répliques ont accès aux mêmes politiques et renvoient des résultats systématiquement masqués. Pour les déploiements de la base de données globale Aurora, les pg_columnmask politiques sont répliquées vers les tables secondaires Régions AWS ainsi que vers les autres tables du système de base de données, garantissant ainsi une protection des données cohérente dans toutes les régions. Pendant les scénarios de basculement, toutes les pg_columnmask politiques restent intactes et fonctionnelles.

Clone de base de données et restauration de snapshots

Les opérations de clonage rapide et de restauration de snapshots d'Aurora préservent toutes les pg_columnmask politiques, tous les rôles et toutes les configurations dans les tables du système de base de données. La base de données clonée ou restaurée hérite de toutes les politiques existantes du cluster source. Après le clonage ou la restauration, chaque cluster de bases de données applique des pg_columnmask politiques indépendantes.

Réplication logique

Lors de la synchronisation initiale, la réplication logique utilise des opérations SQL COPY standard, et pg_columnmask les politiques sont appliquées en fonction des autorisations de l'utilisateur de réplication. Pendant le CDC (capture des données de modification) en cours, les politiques de masquage ne sont pas appliquées et les données démasquées sont répliquées via des enregistrements WAL. Les utilisateurs dotés de pg_create_subscription privilèges peuvent potentiellement exfiltrer des données non masquées en configurant la réplication vers un système qu'ils contrôlent.

Déploiements bleu/vert

Lors de la restauration des instantanés, les pg_columnmask politiques sont automatiquement incluses. L'environnement vert commence par une copie identique de toutes les politiques de l'environnement bleu. Lors de la réplication du bleu au vert, les données ne sont pas masquées. Les modifications ultérieures de la politique de masquage (commandes DDL) sur le cluster bleu ne sont pas répliquées sur le cluster vert et invalident les déploiements RDS. blue/green

Streams Zero-ETL et CDC

La réplication des données n'est pas affectée par pg_columnmask les politiques. Zero-ETL prend en charge la réplication DDL mais ne réplique pg_columnmask pas les politiques RLS. Aucune politique de masquage n'est appliquée aux données répliquées dans Zero-ETL.

AWS Database Migration Service

La synchronisation initiale des données est masquée ou démasquée en fonction de l'utilisateur sélectionné pour la tâche DMS. Les données du CDC sont toujours démasquées. Bien que les politiques RLS internes pg_columnmask associées puissent être migrées, elles ne fonctionneront pas sur les cibles non activées par pg_columnmask.

Exportations de données

pg_columnmasktraite les exportations comme toute autre opération de requête : le masquage est appliqué en fonction des autorisations de l'utilisateur exécutant. Cela s'applique aux commandes SQL telles que COPY, SELECT INTO, CREATE TABLE AS et à la fonctionnalité d'exportation S3 d'Aurora PostgreSQL.

Vues et vues matérialisées

Tenez compte des considérations suivantes lorsque vous utilisez des vues :

Déchargement et restauration de données

pg_dumpfonctionne comme un utilisateur normal de la base de données et applique des politiques de masquage en fonction des autorisations de l'utilisateur qui se connecte. Si un utilisateur masqué effectue un vidage, le fichier de sauvegarde contient des données masquées. pg_columnmaskles politiques sont incluses dans le dump en tant que partie intégrante du schéma de base de données. Une restauration réussie nécessite que tous les rôles référencés existent dans la base de données cible et que l'pg_columnmaskextension soit installée sur la cible.

Enveloppeur de données étrangères

Lorsque vous utilisez des enveloppeurs de données étrangers, les politiques de masquage sur les tables distantes sont appliquées en fonction des autorisations de l'utilisateur mappé sur le serveur source, et non des autorisations de l'utilisateur demandeur local. Bien que vous puissiez accéder aux données distantes masquées via FDW, vous ne pouvez pas créer de politiques DDM ou RLS directement sur les tables étrangères de votre base de données locale.