Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Aurora PostgreSQL pg_columnmask Datenverschiebungsszenarien
pg_columnmaskDas Verhalten variiert bei verschiedenen Datenverschiebungsvorgängen, je nachdem, ob der Vorgang auf der Speicher-, logischen oder Anwendungsebene stattfindet. Operationen auf Speicherebene (wie das Klonen) verhalten sich anders als logische Operationen (z. B.pg_dump) und Operationen auf Anwendungsebene (wie FDW-Abfragen). In diesem Abschnitt wird das Maskierungsverhalten für gängige Szenarien wie Replikation, Backups, Exporte und Migrationen beschrieben und die jeweiligen Sicherheitsauswirkungen erläutert.
Themen
Aurora Global Database und Read Replicas
pg_columnmaskAurora-Richtlinien werden in Datenbanksystemtabellen innerhalb des Cluster-Volumes gespeichert. Alle Replikate greifen auf dieselben Richtlinien zu und geben konsistent maskierte Ergebnisse zurück. Bei Bereitstellungen von Aurora Global Database werden pg_columnmask Richtlinien AWS-Regionen zusammen mit anderen Datenbanksystemtabellen auf sekundäre Daten repliziert, wodurch ein konsistenter Datenschutz in allen Regionen gewährleistet wird. In Failover-Szenarien bleiben alle pg_columnmask Richtlinien intakt und funktionsfähig.
Datenbankklon und Snapshot-Wiederherstellung
Bei Aurora Fast Clone- und Snapshot-Wiederherstellungsvorgängen werden alle pg_columnmask Richtlinien, Rollen und Konfigurationen als Teil der Datenbanksystemtabellen beibehalten. Die geklonte oder wiederhergestellte Datenbank erbt alle vorhandenen Richtlinien aus dem Quellcluster. Nach dem Klonen oder Wiederherstellen behält jeder Datenbankcluster unabhängige Richtlinien bei. pg_columnmask
Logische Replikation
Während der ersten Synchronisation verwendet die logische Replikation standardmäßige SQL COPY-Operationen, und pg_columnmask Richtlinien werden auf der Grundlage der Berechtigungen des Replikationsbenutzers durchgesetzt. Während der laufenden CDC (Change Data Capture) werden keine Maskierungsrichtlinien angewendet und unmaskierte Daten werden über WAL-Datensätze repliziert. Benutzer mit pg_create_subscription Rechten können möglicherweise unmaskierte Daten exfiltrieren, indem sie die Replikation auf ein von ihnen kontrolliertes System einrichten.
Blau/Grün-Bereitstellungen
Bei der Wiederherstellung von Snapshots werden pg_columnmask Richtlinien automatisch berücksichtigt. Die grüne Umgebung beginnt mit einer identischen Kopie aller Richtlinien aus der blauen Umgebung. Bei der Replikation von blau nach grün werden Daten nicht maskiert. Nachfolgende Änderungen der Maskierungsrichtlinien (DDL-Befehle) auf dem blauen Cluster werden nicht auf den grünen Cluster repliziert und machen RDS-Bereitstellungen ungültig. blue/green
Zero-ETL- und CDC-Streams
Die Datenreplikation wird durch Richtlinien nicht beeinträchtigt. pg_columnmask Zero-ETL unterstützt die DDL-Replikation, aber keine pg_columnmask Replikations- oder RLS-Richtlinien. In Zero-ETL werden keine Maskierungsrichtlinien auf replizierte Daten angewendet.
AWS Database Migration Service
Die anfängliche Datensynchronisierung wird je nach dem für die DMS-Aufgabe ausgewählten Benutzer maskiert oder entlarvt. CDC-Daten werden immer demaskiert. pg_columnmaskVerwandte interne RLS-Richtlinien können zwar migriert werden, sie funktionieren jedoch nicht auf Zielen, die nicht pg_columnmask-fähig sind.
Datenexporte
pg_columnmaskbehandelt Exporte wie jede andere Abfrageoperation — die Maskierung wird auf der Grundlage der Berechtigungen des ausführenden Benutzers angewendet. Dies gilt für SQL-Befehle wie COPY, SELECT INTO, CREATE TABLE AS und die S3-Exportfunktion von Aurora PostgreSQL.
Anmerkung
Wenn maskierte Benutzer Daten exportieren, enthalten die resultierenden Dateien maskierte Werte, die bei der Wiederherstellung gegen Datenbankbeschränkungen verstoßen können.
Ansichten und materialisierte Ansichten
Beachten Sie bei der Verwendung von Ansichten die folgenden Überlegungen:
Reguläre Ansichten — Verwenden Sie immer
INVOKERSemantik. Die Maskierungsrichtlinien des aktuellen Benutzers gelten bei der Abfrage der Ansicht, unabhängig davon, wer die Ansicht erstellt hat.Materialisierte Ansichten — Bei der Aktualisierung gelten die Maskierungsrichtlinien des Besitzers der materialisierten Ansicht, nicht die Richtlinien des Benutzers, der die Aktualisierung durchführt. Wenn der Besitzer über Maskierungsrichtlinien verfügt, enthält die materialisierte Ansicht immer maskierte Daten.
Daten speichern und wiederherstellen
pg_dumparbeitet wie ein normaler Datenbankbenutzer und wendet Maskierungsrichtlinien an, die auf den Berechtigungen des verbindenden Benutzers basieren. Wenn ein maskierter Benutzer einen Speicherauszug durchführt, enthält die Sicherungsdatei maskierte Daten. pg_columnmaskRichtlinien sind im Dump als Teil des Datenbankschemas enthalten. Eine erfolgreiche Wiederherstellung setzt voraus, dass alle referenzierten Rollen in der Zieldatenbank vorhanden sind und dass die pg_columnmask Erweiterung auf dem Ziel installiert ist.
Anmerkung
pg_dumpUnterstützt ab PostgreSQL 18 die —no-policies Option, die sowohl Row Level Security (RLS) als auch pg_columnmask Maskierungsrichtlinien von Datenbank-Dumps ausschließt. Weitere Informationen finden Sie unter pg_dump.
Wrapper für ausländische Daten
Bei der Verwendung von Fremddaten-Wrappern werden Maskierungsrichtlinien auf Remotetabellen auf der Grundlage der Berechtigungen des zugewiesenen Benutzers auf dem Quellserver angewendet, nicht auf den Berechtigungen des lokalen abfragenden Benutzers. Sie können zwar über FDW auf maskierte Remotedaten zugreifen, aber Sie können DDM- oder RLS-Richtlinien nicht direkt für Fremdtabellen in Ihrer lokalen Datenbank erstellen.
