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.
# Sicherheit in Amazon Aurora PostgreSQL
Eine allgemeine Übersicht über die Aurora-Sicherheit finden Sie unter [Sicherheit in Amazon Aurora](UsingWithRDS.md). Sie können die Sicherheit für Amazon Aurora PostgreSQL auf mehreren Ebenen verwalten:
+ Um zu kontrollieren, wer Amazon RDS-Managementaktionen auf Aurora PostgreSQL-DB-Clustern und DB-Instances ausführen kann, verwenden Sie AWS Identity and Access Management (IAM). IAM übernimmt die Authentifizierung der Benutzeridentität, bevor der Benutzer auf den Service zugreifen kann. Außerdem übernimmt IAM auch die Autorisierung, d. h., ob der Benutzer für die Vorgänge berechtigt ist, die er versucht auszuführen. Die IAM-Datenbankauthentifizierung ist eine zusätzliche Authentifizierungsmethode, die Sie beim Erstellen Ihres Aurora-PostgreSQL-DB-Clusters auswählen können. Weitere Informationen finden Sie unter [Identity and Access Management für Amazon Aurora](UsingWithRDS.IAM.md).
Wenn Sie IAM mit Ihrem Aurora PostgreSQL-DB-Cluster verwenden, melden Sie sich zuerst AWS-Managementkonsole mit Ihren IAM-Anmeldeinformationen an, bevor Sie die Amazon RDS-Konsole unter öffnen. [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)
+ Stellen Sie sicher, dass Sie Aurora-DB-Cluster in einer Virtual Private Cloud (VPC) basierend auf dem Amazon-VPC-Service erstellen. Mithilfe einer VPC-Sicherheitsgruppe können Sie steuern, welche Geräte und Amazon EC2-Instances Verbindungen zum Endpunkt und Port der DB-Instance für Aurora-DB-Cluster in einer VPC herstellen können. Sie können diese Endpunkt- und Portverbindungen mithilfe von Secure Sockets Layer (SSL) herstellen. Zusätzlich können Firewall-Regeln in Ihrem Unternehmen steuern, ob in Ihrem Unternehmen verwendete Geräte Verbindungen mit einer DB-Instance herstellen dürfen. Weitere Informationen zu finden Sie unter. VPCs [Amazon VPC und Amazon Aurora](USER_VPC.md)
Die unterstützte VPC-Tenancy hängt von der DB-Instance-Klasse ab, die von Ihren Aurora-PostgreSQL-DB-Clustern verwendet wird. Mit `default`-VPC-Tenancy, läuft der DB-Cluster auf gemeinsam genutzter Hardware. Mit `dedicated`-VPC-Tenancy läuft der DB-Cluster auf einer dedizierten Hardware-Instance. Die DB-Instance-Klassen mit Spitzenlastleistung unterstützen nur die Standard-VPC-Tenancy. Die DB-Instance-Klassen mit Spitzenlastleistung umfassen die DB-Instance-Klassen db.t3 und db.t4g. Alle anderen Aurora-PostgreSQL-DB-Instance-Klassen unterstützen sowohl die Standard- als auch die dedizierte VPC-Tenancy.
Weitere Informationen zu Instance-Klassen finden Sie unter [Amazon Aurora Aurora-DB-Instance-Klassen](Concepts.DBInstanceClass.md). Weitere Informationen über die `default`- und `dedicated`-VPC-Tenancy finden Sie unter [Dedicated Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-instance.html) im *Amazon Elastic Compute Cloud-Benutzerhandbuch*.
+ Wenn Sie den PostgreSQL-Datenbanken, die auf Ihrem Amazon-Aurora-DB-Cluster ausgeführt werden, Berechtigungen erteilen möchten, können Sie den gleichen allgemeinen Ansatz wie bei eigenständigen Instances von PostgreSQL verwenden. Befehle wie `CREATE ROLE`, `ALTER ROLE`, `GRANT` und `REVOKE` funktionieren genau wie auf On-Premises-Datenbanken. Gleiches gilt für das direkte Ändern von Datenbanken, Schemas und Tabellen.
PostgreSQL verwaltet Berechtigungen mithilfe von *Rollen*. Die Rolle `rds_superuser` ist die Rolle mit den meisten Berechtigungen in einem Aurora-PostgreSQL-DB-Cluster. Diese Rolle wird automatisch erstellt und dem Benutzer gewährt, der den DB-Cluster erstellt (das Hauptbenutzerkonto, standardmäßig `postgres`). Weitere Informationen hierzu finden Sie unter [Grundlegendes zu PostgreSQL-Rollen und -Berechtigungen](Appendix.PostgreSQL.CommonDBATasks.Roles.md).
Alle verfügbaren Aurora PostgreSQL-Versionen, einschließlich der Versionen 10, 11, 12, 13, 14 und höher, unterstützen den Salted Challenge Response Authentication Mechanism (SCRAM) für Passwörter als Alternative zu Message Digest (). MD5 Wir empfehlen die Verwendung von SCRAM, da es sicherer ist als. MD5 Weitere Informationen, einschließlich der Migration von Datenbankbenutzerkennwörtern von MD5 zu SCRAM, finden Sie unter. [Verwenden von SCRAM für die PostgreSQL-Passwortverschlüsselung](PostgreSQL_Password_Encryption_configuration.md)
# Grundlegendes zu PostgreSQL-Rollen und -Berechtigungen
Wenn Sie mit dem eine Aurora PostgreSQL-DB-Cluster-RDS erstellen AWS-Managementkonsole, wird gleichzeitig ein Administratorkonto erstellt. Der Name lautet standardmäßig `postgres`, wie im folgenden Screenshot gezeigt:
![\[Die Standardanmelde-Identität für Anmeldeinformationen auf der Seite Create database (Datenbank erstellen) lautet postgres.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/default-login-identity-apg-rpg.png)
Sie können einen anderen Namen auswählen, anstatt den Standard (`postgres`) beizubehalten. In diesem Fall muss der von Ihnen gewählte Name mit einem Buchstaben beginnen und zwischen 1 und 16 alphanumerische Zeichen umfassen. Der Einfachheit halber verwenden wir für das Hauptbenutzerkonto den Standardwert (`postgres`) in diesem Handbuch.
Wenn Sie den `create-db-cluster` AWS CLI anstelle von verwenden AWS-Managementkonsole, erstellen Sie den Benutzernamen, indem Sie ihn zusammen mit dem `master-username` Parameter übergeben. Weitere Informationen finden Sie unter [Schritt 2: Erstellen eines DB-Clusters von Aurora PostgreSQL](CHAP_GettingStartedAurora.AuroraPostgreSQL.FullConfig.md#CHAP_GettingStarted.AuroraPostgreSQL.CreateDBCluster).
Unabhängig davon AWS-Managementkonsole, ob Sie die AWS CLI, oder die Amazon RDS-API verwenden und ob Sie den `postgres` Standardnamen verwenden oder einen anderen Namen wählen, ist dieses erste Datenbankbenutzerkonto Mitglied der `rds_superuser` Gruppe und verfügt über `rds_superuser` Berechtigungen.
**Topics**
+ [Die Rolle „rds\$1superuser“ verstehen](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md)
+ [Steuern des Benutzerzugriffs auf die PostgreSQL−Datenbank](Appendix.PostgreSQL.CommonDBATasks.Access.md)
+ [Delegieren und Steuern der Benutzerpasswortverwaltung](Appendix.PostgreSQL.CommonDBATasks.RestrictPasswordMgmt.md)
+ [Verwenden von SCRAM für die PostgreSQL-Passwortverschlüsselung](PostgreSQL_Password_Encryption_configuration.md)
# Die Rolle „rds\$1superuser“ verstehen
In PostgreSQL kann eine *Rolle* einen Benutzer, eine Gruppe oder einen Satz bestimmter Berechtigungen definieren, die einer Gruppe oder einem Benutzer für verschiedene Objekte in der Datenbank gewährt werden. PostgreSQL-Befehle für `CREATE USER` und `CREATE GROUP` wurden durch den allgemeineren Befehl `CREATE ROLE` mit bestimmten Eigenschaften zur Unterscheidung von Datenbankbenutzern ersetzt. Einen Datenbankbenutzer kann man sich als Rolle mit der LOGIN-Berechtigung vorstellen.
**Anmerkung**
Die Befehle `CREATE USER` und `CREATE GROUP` können weiterhin verwendet werden. Weitere Informationen dazu finden Sie im Abschnitt [Datenbankrollen](https://www.postgresql.org/docs/current/user-manag.html) der PostgreSQL-Dokumentation.
Der `postgres`-Benutzer ist der Datenbankbenutzer mit den meisten Berechtigungen auf Ihrem Aurora-PostgreSQL-DB-Cluster. Er verfügt über die Eigenschaften, die durch die folgende `CREATE ROLE`-Anweisung definiert sind.
```
CREATE ROLE postgres WITH LOGIN NOSUPERUSER INHERIT CREATEDB CREATEROLE NOREPLICATION VALID UNTIL 'infinity'
```
Die Eigenschaften `NOSUPERUSER`, `NOREPLICATION`, `INHERIT` und `VALID UNTIL 'infinity'` sind die Standardoptionen für CREATE ROLE, sofern nicht anders angegeben.
Standardmäßig verfügt `postgres` über Berechtigungen, die der `rds_superuser`-Rolle gewährt wurden, und über Berechtigungen zum Erstellen von Rollen und Datenbanken. Die `rds_superuser`-Rolle erlaubt dem `postgres`-Benutzer, folgende Aktionen auszuführen:
+ Erweiterungen für die Verwendung mit Aurora PostgreSQL. Weitere Informationen finden Sie unter [Arbeiten mit Erweiterungen und Fremddaten-Wrappern](Appendix.PostgreSQL.CommonDBATasks.md).
+ Rollen für Benutzer erstellen und Benutzern Berechtigungen gewähren. Weitere Informationen dazu finden Sie im Abschnitt [CREATE ROLE](https://www.postgresql.org/docs/current/sql-createrole.html) und [GRANT](https://www.postgresql.org/docs/14/sql-grant.html) der PostgreSQL-Dokumentation.
+ Datenbanken erstellen. Weitere Informationen finden Sie im Abschnitt [CREATE DATABASE](https://www.postgresql.org/docs/14/sql-createdatabase.html) der PostgreSQL-Dokumentation.
+ Gewähren Sie `rds_superuser`-Berechtigungen anderen Benutzerrollen, die nicht über diese Berechtigungen verfügen, und widerrufen Sie diese Berechtigungen bei Bedarf. Es wird empfohlen, diese Rolle nur denjenigen Benutzern zu gewähren, die Superuser-Aufgaben ausführen. Mit anderen Worten, Sie können diese Rolle Datenbankadministratoren (DBAs) oder Systemadministratoren zuweisen.
+ Die `rds_replication`-Rolle Datenbankbenutzern gewähren (oder entziehen), die nicht über die `rds_superuser`-Rolle verfügen.
+ Die `rds_password`-Rolle Datenbankbenutzern gewähren (oder entziehen), die nicht über die `rds_superuser`-Rolle verfügen.
+ Statusinformationen über alle Datenbankverbindungen über die Ansicht `pg_stat_activity` abrufen. Bei Bedarf kann `rds_superuser` alle Verbindungen mit `pg_terminate_backend` oder `pg_cancel_backend` stoppen.
In der `CREATE ROLE postgres...`-Anweisung können Sie sehen, dass die `postgres`-Benutzerrolle PostgreSQL ausdrücklich `superuser`-Berechtigungen verweigert. Aurora PostgreSQL ist ein verwalteter Service, sodass Sie nicht auf das Host-Betriebssystem zugreifen können und keine Verbindung mit dem `superuser`-PostgreSQL-Konto herstellen können. Viele der Aufgaben, die `superuser`-Zugriff auf einem eigenständigem PostgreSQL erfordern, werden von Aurora automatisch verwaltet.
Weitere Informationen zum Gewähren von Berechtigungen finden Sie unter [GRANT](http://www.postgresql.org/docs/current/sql-grant.html) in der PostgreSQL-Dokumentation.
Die `rds_superuser`-Rolle ist eine von mehreren *vordefinierten* Rollen in einem Aurora-PostgreSQL-DB-Cluster.
**Anmerkung**
In PostgreSQL 13 und früheren Versionen werden *vordefinierte Rollen* als *Standardrollen* bezeichnet.
In der folgenden Liste finden Sie einige der anderen vordefinierten Rollen, die automatisch für einen neuen Aurora-PostgreSQL-DB-Cluster erstellt werden. Vordefinierte Rollen und ihre Berechtigungen können nicht geändert werden. Sie können Berechtigungen für diese vordefinierten Rollen nicht löschen, umbenennen oder ändern. Jeder entsprechende Versuch führt zu einem Fehler.
+ **rds\$1passwort** – Eine Rolle, die Passwörter ändern und Passwortbeschränkungen für Datenbankbenutzer einrichten kann. Die `rds_superuser`-Rolle erhält diese Rolle standardmäßig und kann die Rolle Datenbankbenutzern gewähren. Weitere Informationen finden Sie unter [Steuern des Benutzerzugriffs auf die PostgreSQL−DatenbankSteuern des Benutzerzugriffs auf PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Access.md).
+ In Versionen von RDS für PostgreSQL, die höher sind als 14, kann die `rds_password`-Rolle Passwörter ändern und Passwortbeschränkungen für Datenbankbenutzer und Benutzer mit der `rds_superuser`-Rolle einrichten. Ab Version 14 und höher von RDS für PostgreSQL kann die `rds_password`-Rolle Passwörter ändern und Passwortbeschränkungen nur für Datenbankbenutzer einrichten. Nur Benutzer mit der `rds_superuser`-Rolle können diese Aktionen für andere Benutzer mit der `rds_superuser`-Rolle ausführen.
+ **rdsadmin** – Eine Rolle, die erstellt wurde, um viele der Verwaltungsaufgaben zu erledigen, die der Administrator mit `superuser`-Berechtigungen für eine eigenständige PostgreSQL-Datenbank ausführt. Diese Rolle wird intern von Aurora PostgreSQL für viele Verwaltungsaufgaben verwendet.
# Anzeigen von Rollen und deren Berechtigungen
Sie können vordefinierte Rollen und deren Berechtigungen in Ihrer DB-Instance von RDS für PostgreSQL je nach PostgreSQL-Version mit unterschiedlichen Befehlen anzeigen. Wenn Sie alle vordefinierten Rollen anzeigen möchten, können Sie eine Verbindung zu Ihrer DB-Instance von RDS für PostgreSQL herstellen und die folgenden Befehle mit `psql` ausführen.
**Für `psql` 15 und frühere Versionen**
Stellen Sie eine Verbindung zu Ihrer DB-Instance von RDS für PostgreSQL her und verwenden Sie den `\du`-Befehl in psql:
```
postgres=> \du
List of roles
Role name | Attributes | Member of
-----------------+------------------------------------------------------------+------------------------------------------------------
postgres | Create role, Create DB +| {rds_superuser}
| Password valid until infinity |
rds_ad | Cannot login | {}
rds_iam | Cannot login | {}
rds_password | Cannot login | {}
rds_replication | Cannot login | {}
rds_superuser | Cannot login | {pg_monitor,pg_signal_backend,rds_password,rds_replication}
rdsadmin | Superuser, Create role, Create DB, Replication, Bypass RLS+| {}
| Password valid until infinity |
```
**Für `psql` 16 und höhere Versionen**
```
postgres=> \drg+
List of role grants
Role name | Member of | Options | Grantor
---------------+-----------------------------+---------------------+----------
postgres | rds_superuser | INHERIT, SET | rdsadmin
rds_superuser | pg_checkpoint | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_monitor | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_signal_backend | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_use_reserved_connections | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_password | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_replication | ADMIN, INHERIT, SET | rdsadmin
```
Wenn Sie die Rollenmitgliedschaft ohne Versionsabhängigkeit überprüfen möchten, können Sie die folgende SQL-Abfrage verwenden:
```
SELECT m.rolname AS "Role name", r.rolname AS "Member of"
FROM pg_catalog.pg_roles m
JOIN pg_catalog.pg_auth_members pam ON (pam.member = m.oid)
LEFT JOIN pg_catalog.pg_roles r ON (pam.roleid = r.oid)
LEFT JOIN pg_catalog.pg_roles g ON (pam.grantor = g.oid)
WHERE m.rolname !~ '^pg_'
ORDER BY 1, 2;
```
In der Ausgabe sehen Sie, dass `rds_superuser` keine Datenbankbenutzerrolle ist (sie kann sich nicht anmelden), aber über die Berechtigungen vieler anderer Rollen verfügt. Sie können auch sehen, dass dieser Datenbankbenutzer `postgres` Mitglied der `rds_superuser`-Rolle ist. Wie bereits erwähnt, ist `postgres` der Standardwert auf der Seite **Create database** (Datenbank erstellen) der Amazon-RDS-Konsole. Wenn Sie einen anderen Namen gewählt haben, wird dieser Name stattdessen in der Rollenliste angezeigt.
**Anmerkung**
Aurora-PostgreSQL-Versionen 15.2 und 14.7 führten ein restriktives Verhalten der `rds_superuser`-Rolle ein. Einem Aurora PostgreSQL-Benutzer muss die `CONNECT`-Berechtigung für die entsprechende Datenbank zugewiesen werden, um eine Verbindung herzustellen, auch wenn dem Benutzer die `rds_superuser`-Rolle zugewiesen ist. Vor den Versionen 14.7 und 15.2 von Aurora PostgreSQL konnte ein Benutzer eine Verbindung zu jeder Datenbank und Systemtabelle herstellen, wenn dem Benutzer die `rds_superuser`-Rolle zugewiesen war. Dieses restriktive Verhalten steht im Einklang mit den AWS Verpflichtungen von Amazon Aurora zur kontinuierlichen Verbesserung der Sicherheit.
Bitte aktualisieren Sie die entsprechende Logik in Ihren Anwendungen, falls die oben genannte Erweiterung Auswirkungen hat.
# Steuern des Benutzerzugriffs auf die PostgreSQL−Datenbank
Neue Datenbanken in PostgreSQL werden immer mit Standardberechtigungen im `public`-Schema der Datenbank erstellt, mit dem alle Datenbankbenutzer und -rollen Objekte erstellen können. Diese Berechtigungen ermöglichen es Datenbankbenutzern, eine Verbindung mit der Datenbank herzustellen und während der Verbindung temporäre Tabellen zu erstellen.
Es wird empfohlen, diese `public`-Standardberechtigungen zu widerrufen, um den Benutzerzugriff auf die Datenbank-Instances, die Sie auf Ihrem Primärknoten des Aurora-PostgreSQL-DB-Clusters erstellen, besser kontrollieren können. Danach erteilen Sie Datenbankbenutzern auf einer detaillierteren Basis spezifische Berechtigungen, wie im Folgenden gezeigt.
**So richten Sie Rollen und Berechtigungen für eine neue Datenbank-Instance ein**
Angenommen, Sie richten eine Datenbank für einen neu erstellten Aurora-PostgreSQL-DB-Cluster ein, die von mehreren Forschenden verwendet wird, die alle Lese-/Schreibzugriff auf die Datenbank benötigen.
1. Verwenden Sie `psql` (oder pgAdmin) zum Herstellen einer Verbindung mit dem primären Aurora-PostgreSQL-DB-Cluster:
```
psql --host=your-cluster-instance-1.666666666666.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
Geben Sie bei der Aufforderung Ihr Passwort ein. Der `psql`-Client verbindet und zeigt die standardmäßige administrative Verbindungsdatenbank `postgres=>` als Eingabeaufforderung an.
1. Gehen Sie wie folgt vor, um zu verhindern, dass Datenbankbenutzer Objekte im `public`-Schema erstellen:
```
postgres=> REVOKE CREATE ON SCHEMA public FROM PUBLIC;
REVOKE
```
1. Als Nächstes erstellen Sie eine neue Datenbank-Instance:
```
postgres=> CREATE DATABASE lab_db;
CREATE DATABASE
```
1. Widerrufen Sie alle Berechtigungen aus dem `PUBLIC`-Schema in dieser neuen Datenbank.
```
postgres=> REVOKE ALL ON DATABASE lab_db FROM public;
REVOKE
```
1. Erstellen Sie eine Rolle für Datenbankbenutzer.
```
postgres=> CREATE ROLE lab_tech;
CREATE ROLE
```
1. Geben Sie Datenbankbenutzern mit dieser Rolle die Möglichkeit, eine Verbindung mit der Datenbank herzustellen.
```
postgres=> GRANT CONNECT ON DATABASE lab_db TO lab_tech;
GRANT
```
1. Gewähren Sie allen Benutzern mit der `lab_tech`-Rolle alle Berechtigungen für diese Datenbank.
```
postgres=> GRANT ALL PRIVILEGES ON DATABASE lab_db TO lab_tech;
GRANT
```
1. Erstellen Sie Datenbankbenutzer wie folgt:
```
postgres=> CREATE ROLE lab_user1 LOGIN PASSWORD 'change_me';
CREATE ROLE
postgres=> CREATE ROLE lab_user2 LOGIN PASSWORD 'change_me';
CREATE ROLE
```
1. Gewähren Sie diesen beiden Benutzern die Berechtigungen, die mit der lab\$1tech-Rolle verknüpft sind:
```
postgres=> GRANT lab_tech TO lab_user1;
GRANT ROLE
postgres=> GRANT lab_tech TO lab_user2;
GRANT ROLE
```
An dieser Stelle können `lab_user1` und `lab_user2` eine Verbindung mit der `lab_db`-Datenbank herstellen. Dieses Beispiel folgt nicht den bewährten Methoden für den Unternehmensgebrauch, darunter das Erstellen mehrerer Datenbank-Instances, verschiedener Schemas und das Erteilen eingeschränkter Berechtigungen. Umfassende Informationen und zusätzliche Szenarien finden Sie unter [Verwalten von PostgreSQL-Benutzern und -Rollen](https://aws.amazon.com/blogs//database/managing-postgresql-users-and-roles/).
Weitere Informationen zu Berechtigungen in PostgreSQL-Datenbanken finden Sie unter dem Befehl [GRANT](https://www.postgresql.org/docs/current/static/sql-grant.html) in der PostgreSQL-Dokumentation.
# Delegieren und Steuern der Benutzerpasswortverwaltung
Als DBA sollten Sie ggf. die Verwaltung von Benutzerpasswörtern delegieren. Oder Sie möchten verhindern, dass Datenbankbenutzer ihre Passwörter ändern oder Passwortbeschränkungen wie die Lebensdauer des Passworts neu konfigurieren. Um sicherzustellen, dass nur die von Ihnen ausgewählten Datenbankbenutzer Passworteinstellungen ändern können, können Sie die Funktion zur eingeschränkten Passwortverwaltung aktivieren. Wenn Sie diese Funktion aktivieren, können nur die Datenbankbenutzer, denen die `rds_password`-Rolle gewährt wurde, Passwörter verwalten.
**Anmerkung**
Um die eingeschränkte Passwortverwaltung nutzen zu können, muss Ihr DB-Cluster von Aurora PostgreSQL Amazon Aurora PostgreSQL 10.6 oder höher ausführen.
Standardmäßig lautet diese Funktion `off`, wie im Folgenden gezeigt:
```
postgres=> SHOW rds.restrict_password_commands;
rds.restrict_password_commands
--------------------------------
off
(1 row)
```
Zum Aktivieren dieser Funktion verwenden Sie eine benutzerdefinierte Parametergruppe und ändern die Einstellung für `rds.restrict_password_commands` in 1. Stellen Sie sicher, dass Sie Ihre primäre DB-Instance von Aurora PostgreSQL neu starten, damit die Einstellung wirksam wird.
Wenn diese Funktion aktiv ist, werden für die folgenden SQL-Befehle `rds_password`-Berechtigungen benötigt:
```
CREATE ROLE myrole WITH PASSWORD 'mypassword';
CREATE ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword';
ALTER ROLE myrole VALID UNTIL '2023-01-01';
ALTER ROLE myrole RENAME TO myrole2;
```
Das Umbenennen einer Rolle (`ALTER ROLE myrole RENAME TO newname`) ist ebenfalls eingeschränkt, wenn das Passwort den MD5 Hash-Algorithmus verwendet.
Wenn diese Funktion aktiv ist, generiert jeder Versuch, einen dieser SQL-Befehle ohne die `rds_password`-Rollenberechtigungen auszuführen, den folgenden Fehler:
```
ERROR: must be a member of rds_password to alter passwords
```
Wir empfehlen, dass Sie die `rds_password`-Berechtigung nur wenigen Rollen zuweisen, die Sie ausschließlich für die Passwortverwaltung verwenden. Wenn Sie `rds_password`-Berechtigungen für Datenbankbenutzer erteilen, die keine `rds_superuser`-Berechtigungen haben, müssen Sie ihnen auch das `CREATEROLE`-Attribut erteilen.
Stellen Sie sicher, dass Sie die Passwortanforderungen wie Ablaufdatum und erforderliche Komplexität auf Kundenseite überprüfen. Wenn Sie Ihr eigenes clientseitiges Dienstprogramm für passwortbezogene Änderungen verwenden, muss das Dienstprogramm Mitglied von `rds_password` sein und über `CREATE ROLE`-Berechtigungen verfügen.
# Verwenden von SCRAM für die PostgreSQL-Passwortverschlüsselung
Der *Salted Challenge Response Authentication Mechanism (SCRAM)* ist eine Alternative zum standardmäßigen Message Digest (MD5) -Algorithmus von PostgreSQL zur Verschlüsselung von Passwörtern. Der SCRAM-Authentifizierungsmechanismus gilt als sicherer als. MD5 Weitere Informationen zu diesen beiden verschiedenen Ansätzen zur Sicherung von Passwörtern finden Sie unter [Passwortauthentifizierung](https://www.postgresql.org/docs/14/auth-password.html) in der PostgreSQL-Dokumentation.
Wir empfehlen, SCRAM statt MD5 als Kennwortverschlüsselungsschema für Ihren Aurora PostgreSQL-DB-Cluster zu verwenden. SCRAM wird in Aurora-PostgreSQL-Version 10 und allen höheren Haupt- und Nebenversionen unterstützt. Es ist ein kryptografischer Challenge-Response-Mechanismus, der den scram–sha-256-Algorithmus zur Passwortauthentifizierung und -verschlüsselung nutzt.
Möglicherweise müssen Sie Bibliotheken aktualisieren, damit Ihre Clientanwendungen SCRAM unterstützen können. JDBC-Versionen vor 42.2.0 unterstützen SCRAM beispielsweise nicht. Weitere Informationen finden Sie unter [PostgreSQL-JDBC-Treiber](https://jdbc.postgresql.org/changelogs/2018-01-17-42.2.0-release/) in der Dokumentation zu PostgreSQL-JDBC-Treibern. Für eine Liste anderer PostgreSQL-Treiber und SCRAM-Unterstützung siehe die [Treiberliste](https://wiki.postgresql.org/wiki/List_of_drivers) in der PostgreSQL-Dokumentation.
Aurora PostgreSQL Version 14 und höhere Versionen unterstützen scram-sha-256 standardmäßig zur Passwortverschlüsselung für neue DB-Cluster. Für diese Versionen ist der `password_encryption`-Wert der standardmäßigen DB-Cluster-Parametergruppe (`default.aurora-postgresql14`) auf scram-sha-256 festgelegt. Für Aurora Serverless v1 wird SCRAM nicht unterstützt.
## Einrichtung des Aurora PostgreSQL-DB-Clusters , die SCRAM benötigt
Bei Aurora PostgreSQL 14.3 und höheren Versionen können Sie verlangen, dass der Aurora-PostgreSQL-DB-Cluster nur Passwörter akzeptiert, die den scram-sha-256-Algorithmus verwenden.
**Wichtig**
Wenn Sie bei vorhandenen RDS-Proxys mit PostgreSQL-Datenbanken die Datenbankauthentifizierung so ändern, dass nur `SCRAM` verwendet wird, ist der Proxy für bis zu 60 Sekunden nicht verfügbar. Um das Problem zu vermeiden, führen Sie einen der folgenden Schritte aus:
Stellen Sie sicher, dass die Datenbank sowohl die `SCRAM`- als auch die `MD5`-Authentifizierung zulässt.
Wenn Sie nur die `SCRAM`-Authentifizierung verwenden möchten, erstellen Sie einen neuen Proxy, migrieren Sie Ihren Anwendungsdatenverkehr auf den neuen Proxy und löschen Sie dann den zuvor mit der Datenbank verknüpften Proxy.
Bevor Sie Änderungen an Ihrem System vornehmen, vergewissern Sie sich, dass Sie den folgenden Prozess komplett verstehen:
+ Sammeln Sie Informationen über alle Rollen und Passwortverschlüsselung für alle Datenbankbenutzer.
+ Überprüfen Sie die Parametereinstellungen für Ihren Aurora-PostgreSQL-DB-Cluster für die Parameter, die die Passwortverschlüsselung steuern.
+ Wenn Ihr Aurora-PostgreSQL-DB-Cluster eine Standardparametergruppe verwendet, müssen Sie eine benutzerdefinierte DB-Cluster-Parametergruppe erstellen und sie auf Ihren Aurora-PostgreSQL-DB-Cluster anwenden, damit Sie bei Bedarf Parameter ändern können. Wenn Ihr Aurora-PostgreSQL-DB-Cluster eine benutzerdefinierte Parametergruppe verwendet, können Sie die erforderlichen Parameter bei Bedarf später im Prozess ändern.
+ Ändern Sie den Parameter `password_encryption` in `scram-sha-256`.
+ Informieren Sie alle Datenbankbenutzer, dass sie ihre Passwörter aktualisieren müssen. Wiederholen Sie diesen Schritt für Ihr `postgres`-Konto. Die neuen Passwörter werden mit dem scram-sha-256-Algorithmus verschlüsselt und gespeichert.
+ Stellen Sie sicher, dass alle Passwörter mit diesem Verschlüsselungstyp verschlüsselt sind.
+ Wenn alle Passwörter scram-sha-256 verwenden, können Sie den `rds.accepted_password_auth_method`-Parameter von `md5+scram` in `scram-sha-256` ändern.
**Warnung**
Nachdem Sie `rds.accepted_password_auth_method` nur in scram-sha-256 geändert haben, können Benutzer (Rollen) mit `md5`-verschlüsselten Passwörtern keine Verbindung herstellen.
### Machen Sie sich bereit, SCRAM für Ihren Aurora PostgreSQL-DB-Cluster ( PostgreSQL-DB-Instance) zu benötigen
Bevor Sie Änderungen an Ihrem Aurora-PostgreSQL-DB-Cluster, vornehmen, überprüfen Sie alle vorhandenen Datenbankbenutzerkonten. Überprüfen Sie auch die Art der Verschlüsselung, die für Passwörter verwendet wird. Sie können für diese Aufgaben die `rds_tools`-Erweiterung verwenden. Weitere Informationen darüber, welche PostgreSQL-Versionen `rds_tools` unterstützen, finden Sie unter [Erweiterungsversionen für Amazon RDS für PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html).
**So erhalten Sie eine Liste der Datenbankbenutzer (Rollen) und Passwortverschlüsselungsmethoden**
1. Verwenden Sie `psql` zum Herstellen einer Verbindung mit der primären Instance Ihres Aurora-PostgreSQL-DB-Clusters , wie im Folgenden gezeigt.
```
psql --host=cluster-name-instance-1.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Installieren Sie die `rds_tools`-Erweiterung.
```
postgres=> CREATE EXTENSION rds_tools;
CREATE EXTENSION
```
1. Rufen Sie eine Auflistung der Rollen und Verschlüsselungsmethoden ab.
```
postgres=> SELECT * FROM
rds_tools.role_password_encryption_type();
```
Die Ausgabe entspricht weitgehend der folgenden.
```
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | md5
user_465 | md5
postgres | md5
(8 rows)
```
### Erstellen einer benutzerdefinierten DB-Cluster-Parametergruppe
**Anmerkung**
Wenn Ihr Aurora-PostgreSQL-DB-Cluster bereits eine benutzerdefinierte Parametergruppe verwendet, müssen Sie keine neue erstellen.
Eine Übersicht über Parametergruppen für Aurora finden Sie unter [Eine DB-Cluster-Parametergruppe in Amazon Aurora erstellen](USER_WorkingWithParamGroups.CreatingCluster.md).
Der für Passwörter verwendete Passwortverschlüsselungstyp wird in einem Parameter, `password_encryption`, festgelegt. Die Verschlüsselung, die der Aurora-PostgreSQL-DB-Cluster zulässt, wird in einem anderen Parameter, `rds.accepted_password_auth_method`, festgelegt. Wenn Sie den Standardwert eines dieser Parameter ändern, müssen Sie eine benutzerdefinierte DB-Cluster-Parametergruppe erstellen und auf Ihren Cluster anwenden.
Weitere Informationen finden Sie unter [Eine DB-Cluster-Parametergruppe in Amazon Aurora erstellen](USER_WorkingWithParamGroups.CreatingCluster.md).
Sie können jetzt die benutzerdefinierte Parametergruppe Ihrer DB-Instance zuordnen.
**Um eine benutzerdefinierte DB-Cluster-Parametergruppe zu erstellen,**
1. Verwenden Sie den CLI-Befehl `[create-db-cluster-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster-parameter-group.html)` zum Erstellen der benutzerdefinierten Parametergruppe für den Cluster. Folgendes Beispiel verwendet `aurora-postgresql13` als Quelle für diese benutzerdefinierte Parametergruppe.
Für Linux, macOS oder Unix:
```
aws rds create-db-cluster-parameter-group --db-cluster-parameter-group-name 'docs-lab-scram-passwords' \
--db-parameter-group-family aurora-postgresql13 --description 'Custom DB cluster parameter group for SCRAM'
```
Für Windows:
```
aws rds create-db-cluster-parameter-group --db-cluster-parameter-group-name "docs-lab-scram-passwords" ^
--db-parameter-group-family aurora-postgresql13 --description "Custom DB cluster parameter group for SCRAM"
```
Sie können jetzt die benutzerdefinierte Parametergruppe Ihrem Cluster zuordnen.
1. Verwenden Sie den CLI-Befehl `[modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)` zum Anwenden dieser benutzerdefinierten Parametergruppe auf Ihren Aurora-PostgreSQL-DB-Cluster.
Für Linux, macOS oder Unix:
```
aws rds modify-db-cluster --db-cluster-identifier 'your-instance-name' \
--db-cluster-parameter-group-name "docs-lab-scram-passwords
```
Für Windows:
```
aws rds modify-db-cluster --db-cluster-identifier "your-instance-name" ^
--db-cluster-parameter-group-name "docs-lab-scram-passwords
```
Zum erneuten Synchronisieren Ihres Aurora-PostgreSQL-DB-Clusters mit Ihrer benutzerdefinierten DB-Cluster-Parametergruppe starten Sie die primäre und alle anderen Instances des Clusters neu.
### Konfigurieren der Passwortverschlüsselung für die Verwendung von SCRAM
Der Passwortverschlüsselungsmechanismus, der von einem Aurora-PostgreSQL-DB-Cluster verwendet wird, ist in der DB-Cluster-Parametergruppe auf den Parameter `password_encryption` festgelegt. Zulässige Werte sind keine Angabe, `md5` oder `scram-sha-256`. Der Standardwert hängt von der Version von Aurora PostgreSQL wie folgt ab:
+ Aurora PostgreSQL 14 – Der Standardwert ist `scram-sha-256`.
+ Aurora PostgreSQL 13 – Der Standardwert ist `md5`.
Mit einer benutzerdefinierten DB-Cluster-Parametergruppe , die Ihrem Aurora-PostgreSQL-DB-Cluster angefügt ist, können Sie die Werte für den Passwortverschlüsselungsparameter ändern.
![\[Im Folgenden zeigt die RDS-Konsole die Standardwerte für die password_encryption-Parameter für Aurora PostgreSQL.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/apg-pwd-encryption-md5-scram-1.png)
**So ändern Sie die Passwortverschlüsselungseinstellung in scram-sha-256**
+ Ändern Sie den Wert der Passwortverschlüsselung in scram-sha-256, wie nachfolgend gezeigt. Die Änderung kann sofort angewendet werden, da der Parameter dynamisch ist. Daher ist kein Neustart erforderlich, damit die Änderung wirksam wird.
Für Linux, macOS oder Unix:
```
aws rds modify-db-cluster-parameter-group --db-cluster-parameter-group-name \
'docs-lab-scram-passwords' --parameters 'ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate'
```
Für Windows:
```
aws rds modify-db-parameter-group --db-parameter-group-name ^
"docs-lab-scram-passwords" --parameters "ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate"
```
### Migrieren von Passwörtern für Benutzerrollen zu SCRAM
Sie können Passwörter für Benutzerrollen wie folgt zu SCRAM migrieren.
**Um Datenbankbenutzer- (Rollen-) Passwörter von MD5 zu SCRAM zu migrieren**
1. Melden Sie sich als Administratorbenutzer an (Standardbenutzer `postgres`), wie nachfolgend gezeigt.
```
psql --host=cluster-name-instance-1.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Überprüfen Sie die Einstellung des `password_encryption`-Parameters auf der DB-Instance von RDS für PostgreSQL mithilfe des folgenden Befehls.
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
md5
(1 row)
```
1. Ändern Sie den Wert dieses Parameters in scram-sha-256. Weitere Informationen finden Sie unter [Konfigurieren der Passwortverschlüsselung für die Verwendung von SCRAM](#PostgreSQL_Password_Encryption_configuration.configure-password-encryption).
1. Überprüfen Sie den Wert erneut, um sicherzustellen, dass er jetzt auf `scram-sha-256` festgelegt ist. Gehen Sie dazu wie folgt vor.
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
scram-sha-256
(1 row)
```
1. Bitten Sie alle Datenbankbenutzer, ihre Passwörter zu ändern. Stellen Sie sicher, dass Sie auch Ihr eigenes Passwort für das `postgres`-Konto ändern (der Datenbankbenutzer mit `rds_superuser`-Berechtigungen).
```
labdb=> ALTER ROLE postgres WITH LOGIN PASSWORD 'change_me';
ALTER ROLE
```
1. Wiederholen Sie den Vorgang für alle Datenbanken auf dem Aurora-PostgreSQL-DB-Cluster.
### Ändern des Parameters, um SCRAM zu erfordern
Dies ist der letzte Schritt in diesem Prozess. Nachdem Sie die Änderung im folgenden Verfahren vorgenommen haben, können sich Benutzerkonten (Rollen), die nach wie vor die `md5`-Verschlüsselung für Passwörter verwenden, nicht beim Aurora-PostgreSQL-DB-Cluster anmelden.
Die `rds.accepted_password_auth_method` gibt die Verschlüsselungsmethode an, die der Aurora-PostgreSQL-DB-Cluster als Benutzerpasswort beim Anmeldevorgang akzeptiert. Der Standardwert ist `md5+scram`, was bedeutet, dass eine der beiden Methoden akzeptiert wird. Im folgenden Bild finden Sie die Standardeinstellung für diesen Parameter.
![\[Die RDS-Konsole, die die Standardwerte und die zulässigen Werte für den rds.accepted_password_auth_method-Parameter zeigt.\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/pwd-encryption-md5-scram-2.png)
Die zulässigen Werte für diesen Parameter sind `md5+scram` oder nur `scram`. Durch Ändern dieses Parameterwerts in `scram` wird er erforderlich.
**So ändern Sie den Parameterwert, sodass eine SCRAM-Authentifizierung für Passwörter erforderlich ist**
1. Stellen Sie sicher, dass alle Datenbank-Benutzerpasswörter für alle Datenbanken auf Ihrem Aurora-PostgreSQL-DB-Cluster `scram-sha-256` für die Passwortverschlüsselung verwenden. Fragen Sie hierzu `rds_tools` für die Rolle (Benutzer) und den Verschlüsselungstyp wie folgt ab.
```
postgres=> SELECT * FROM rds_tools.role_password_encryption_type();
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | scram-sha-256
user_465 | scram-sha-256
postgres | scram-sha-256
( rows)
```
1. Wiederholen Sie die Abfrage auf allen DB-Instances Ihres Aurora-PostgreSQL-DB-Clusters.
Wenn alle Passwörter scram-sha-256 verwenden, können Sie fortfahren.
1. Ändern Sie den Wert der akzeptierten Passwortauthentifizierung in scram-sha-256 wie folgt.
Für Linux, macOS oder Unix:
```
aws rds modify-db-cluster-parameter-group --db-cluster-parameter-group-name 'docs-lab-scram-passwords' \
--parameters 'ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate'
```
Für Windows:
```
aws rds modify-db-cluster-parameter-group --db-cluster-parameter-group-name "docs-lab-scram-passwords" ^
--parameters "ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate"
```
## Sicherung von Aurora-PostgreSQL-Daten mit SSL/TLS
Amazon RDS unterstützt Secure Socket Layer (SSL) und Transport Layer Security (TLS) Verschlüsselung für Aurora PostgreSQL DB-Cluster. Verwenden von SSL/TLS, you can encrypt a connection between your applications and your Aurora PostgreSQL DB clusters. You can also force all connections to your Aurora PostgreSQL DB cluster to use SSL/TLS Amazon Aurora PostgreSQL unterstützt jetzt Transport Layer Security (TLS) in den Versionen 1.1 und 1.2. Wir empfehlen die Verwendung von TLS 1.2 für verschlüsselte Verbindungen. Wir haben Unterstützung für TLSv1 .3 aus den folgenden Versionen von Aurora PostgreSQL hinzugefügt:
+ 15.3 und alle höheren Versionen
+ 14.8 und höhere 14-Versionen
+ 13.11 und höhere 13-Versionen
+ 12.15 und höhere 12-Versionen
+ 11.20 und höhere 11-Versionen
Allgemeine Informationen zur SSL/TLS Unterstützung und zu PostgreSQL-Datenbanken finden Sie unter [SSL-Unterstützung](https://www.postgresql.org/docs/current/libpq-ssl.html) in der PostgreSQL-Dokumentation. Informationen zur Verwendung einer SSL/TLS Verbindung über JDBC finden Sie unter [Konfiguration des Clients in der](https://jdbc.postgresql.org/documentation/head/ssl-client.html) PostgreSQL-Dokumentation.
**Topics**
+ [SSL/TLS Verbindung zu einem Aurora PostgreSQL-DB-Cluster erforderlich](#AuroraPostgreSQL.Security.SSL.Requiring)
+ [Ermitteln des SSL/TLS Verbindungsstatus](#AuroraPostgreSQL.Security.SSL.Status)
+ [Konfigurieren von Chiffrier-Suiten für Verbindungen mit Aurora-PostgreSQL-DB-Clustern](#AuroraPostgreSQL.Security.SSL.ConfiguringCipherSuites)
SSL/TLS-Unterstützung ist in allen AWS Regionen für Aurora PostgreSQL verfügbar. Amazon RDS erstellt ein SSL/TLS Zertifikat für Ihren Aurora PostgreSQL-DB-Cluster, wenn der DB-Cluster erstellt wird. Wenn Sie die SSL/TLS Zertifikatsüberprüfung aktivieren, enthält das SSL/TLS Zertifikat den DB-Cluster-Endpunkt als Common Name (CN) für das SSL/TLS Zertifikat zum Schutz vor Spoofing-Angriffen.
**Um sich mit einem Aurora PostgreSQL DB-Cluster über SSL/TLS zu verbinden**
1. Laden Sie das Zertifikat herunter.
Informationen zum Herunterladen von Zertifikaten finden Sie unter [Wird verwendet SSL/TLS , um eine Verbindung zu einer zu verschlüsseln](UsingWithRDS.SSL.md).
1. Importieren Sie das Zertifikat in Ihr Betriebssystem.
1. Verbinden Sie sich mit Ihrem Aurora PostgreSQL DB-Cluster über SSL/TLS.
Wenn Sie eine Verbindung über SSL/TLS herstellen, kann Ihr Client wählen, ob er die Zertifikatskette überprüfen möchte oder nicht. Wenn Ihre Verbindungsparameter `sslmode=verify-ca` oder `sslmode=verify-full` angeben, verlangt Ihr Client, dass sich die RDS CA-Zertifikate im Trust Store befinden oder von der Verbindungs-URL referenziert werden. Diese Anforderung dient zur Prüfung der Zertifikatskette, die Ihr Datenbankzertifikat signiert.
Wenn ein Client, z. B. psql oder JDBC, mit SSL/TLS Support konfiguriert ist, versucht der Client standardmäßig zunächst, eine Verbindung mit der Datenbank herzustellen. SSL/TLS Wenn der Client keine Verbindung herstellen kann mit. SSL/TLS, it reverts to connecting without SSL/TLS Standardmäßig ist die `sslmode`-Option für JDBC- und libpq-basierte Clients auf `prefer` festgelegt.
Verwenden Sie den Parameter `sslrootcert`, um auf das Zertifikat zu verweisen, beispielsweise `sslrootcert=rds-ssl-ca-cert.pem`.
Das folgende Beispiel zeigt psql zur Herstellung einer Verbindung mit einem Aurora-PostgreSQL-DB-Cluster:
```
$ psql -h testpg.cdhmuqifdpib.us-east-1.rds.amazonaws.com -p 5432 \
"dbname=testpg user=testuser sslrootcert=rds-ca-2015-root.pem sslmode=verify-full"
```
### SSL/TLS Verbindung zu einem Aurora PostgreSQL-DB-Cluster erforderlich
Verwenden `rds.force_ssl` Sie Parameter, um SSL/TLS Verbindungen zu Ihrem Aurora PostgreSQL-DB-Cluster zu benötigen.
+ Um SSL/TLS Verbindungen zu benötigen, setzen Sie den `rds.force_ssl` Parameterwert auf 1 (ein).
+ Um die erforderlichen SSL/TLS Verbindungen auszuschalten, setzen Sie den `rds.force_ssl` Parameterwert auf 0 (aus).
Der Standardwert dieses Parameters hängt von der Aurora-PostgreSQL-Version ab:
+ Für Aurora-PostgreSQL-Versionen 17 und höher: Der Standardwert ist 1 (on).
+ Für Aurora-PostgreSQL-Versionen 16 und niedriger: Der Standardwert ist 0 (off).
**Anmerkung**
Wenn Sie ein Hauptversions-Upgrade von Aurora-PostgreSQL-Version 16 oder früher auf Version 17 oder höher durchführen, ändert sich der Standardwert des Parameters von 0 (off) auf 1 (on). Diese Änderung kann zu Verbindungsfehlern bei Anwendungen führen, die nicht für SSL konfiguriert sind. Sie können zum vorherigen Standardverhalten zurückkehren, indem Sie diesen Parameter auf 0 (off) setzen.
Weitere Informationen zur Handhabung von Parametern finden Sie unter [Parametergruppen für Amazon Aurora](USER_WorkingWithParamGroups.md).
Durch die Aktualisierung des `rds.force_ssl` Parameters wird auch der `ssl` PostgreSQL-Parameter auf 1 (on) gesetzt und die `pg_hba.conf` Datei Ihres DB-Clusters so geändert, dass sie die neue Konfiguration unterstützt. SSL/TLS
Wenn der `rds.force_ssl` Parameter für einen DB-Cluster auf 1 gesetzt ist, erhalten Sie beim Herstellen der Verbindung eine Ausgabe, die der folgenden ähnelt, was darauf hinweist, dass dies jetzt erforderlich SSL/TLS ist:
```
$ psql postgres -h SOMEHOST.amazonaws.com -p 8192 -U someuser
psql (9.3.12, server 9.4.4)
WARNING: psql major version 9.3, server major version 9.4.
Some psql features might not work.
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.
postgres=>
```
### Ermitteln des SSL/TLS Verbindungsstatus
Der Verschlüsselungsstatus Ihrer Verbindung wird auf dem Anmelde-Banner angezeigt, wenn Sie sich mit dem DB-Cluster verbinden:
```
Password for user master:
psql (9.3.12)
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.
postgres=>
```
Sie können die `sslinfo` Erweiterung auch laden und dann die `ssl_is_used()` Funktion aufrufen, um festzustellen, ob sie verwendet SSL/TLS wird. Die Funktion gibt `t` zurück, wenn die Verbindung SSL/TLS verwendet, andernfalls gibt sie `f` zurück.
```
postgres=> create extension sslinfo;
CREATE EXTENSION
postgres=> select ssl_is_used();
ssl_is_used
---------
t
(1 row)
```
Sie können den Befehl `select ssl_cipher()` verwenden, um die SSL/TLS-Verschlüsselung zu bestimmen:
```
postgres=> select ssl_cipher();
ssl_cipher
--------------------
DHE-RSA-AES256-SHA
(1 row)
```
Wenn Sie `set rds.force_ssl` aktivieren und Ihren DB-Cluster neu starten, werden Nicht-SSL-Verbindungen abgelehnt, und die folgende Mitteilung wird angezeigt:
```
$ export PGSSLMODE=disable
$ psql postgres -h SOMEHOST.amazonaws.com -p 8192 -U someuser
psql: FATAL: no pg_hba.conf entry for host "host.ip", user "someuser", database "postgres", SSL off
$
```
Informationen zur Option `sslmode` finden Sie unter [Datenbankverbindung-Steuerungsfunktionen](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNECT-SSLMODE) in der PostgreSQL-Dokumentation.
### Konfigurieren von Chiffrier-Suiten für Verbindungen mit Aurora-PostgreSQL-DB-Clustern
Durch die Verwendung von konfigurierbaren Chiffrier-Suiten können Sie mehr Kontrolle über die Sicherheit Ihrer Datenbankverbindungen haben. Sie können eine Liste von Cipher Suites angeben, die Sie für sichere SSL/TLS Client-Verbindungen zu Ihrer Datenbank zulassen möchten. Mit konfigurierbaren Chiffrier-Suiten können Sie die Verbindungsverschlüsselung steuern, die Ihr Datenbankserver akzeptiert. Dies hilft, die Verwendung von unsicheren oder veralteten Chiffren zu verhindern.
Konfigurierbare Chiffrier-Suiten werden in Aurora PostgreSQL Version 11.8 und höher unterstützt.
Um die Liste der zulässigen Chiffren für die Verschlüsselung von Verbindungen anzugeben, ändern Sie die `ssl_ciphers`-Cluster-Parameter. Setzen Sie den `ssl_ciphers` Parameter mithilfe der, der oder der RDS-API auf eine Zeichenfolge mit kommagetrennten Chiffrierwerten in einer Cluster-Parametergruppe. AWS-Managementkonsole AWS CLI Um Cluster-Parameter festzulegen, siehe [Ändern von Parametern in einer DB-Cluster-Parametergruppe in Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md).
Die folgende Tabelle zeigt die unterstützten Verschlüsselungen für die gültigen Versionen der Aurora-PostgreSQL-Engine.
| Engine-Versionen für Aurora PostgreSQL | Unterstützte Verschlüsselungen | TLS 1.1 | TLS 1.2 | TLS 1.3 |
| --- | --- | --- | --- | --- |
| 9.6, 10.20 und niedriger, 11.15 und niedriger, 12.10 und niedriger, 13.6 und niedriger | DHE-RSA- -SHA AES128 DHE-RSA- AES128 - SHA256 DHE-RSA- -GCM- AES128 SHA256 AES256DHE-RSA-SHA DHE-RSA- AES256 - SHA256 DHE-RSA- -GCM- AES256 SHA384 AES256ECDHE-ECDSA-SHA ECDHE-ECDSA- -GCM- AES256 SHA384 ECDHE-RSA- - AES256 SHA384 ECDHE-RSA- AES128 -SHA ECDHE-RSA- - AES128 SHA256 ECDHE-RSA- -GCM AES128 - SHA256 AES256ECDHE-RSA-SHA ECDHE-RSA- AES256 -GCM- SHA384 | Ja Nein Nein Nein Nein Nein Ja Nein Nein Ja Nein Nein Ja Nein | Nein Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja | Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein |
| 10.21, 11.16, 12.11, 13.7, 14.3 und 14.4 | ECDHE-RSA- AES128 -SCHÄTZE\$1ECDHE-RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 TLS\$1RSA\$1MIT\$1AES\$1256\$1GCM\$1 SHA384 TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA TLS\$1RSA\$1MIT\$1AES\$1128\$1GCM\$1 SHA256 TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1MIT\$1 \$1 \$1 CHACHA20 POLY1305 SHA256 | Ja Nein Ja Nein Ja Nein Ja Nein Nein Ja Nein Ja Nein | Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja | Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein |
| 10.22, 11.17, 12.12, 13.8, 14.5 und 15.2 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1MIT\$1AES\$1128\$1CBC\$1 SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 TLS\$1RSA\$1MIT\$1AES\$1256\$1GCM\$1 SHA384 TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA TLS\$1RSA\$1MIT\$1AES\$1128\$1GCM\$1 SHA256 TLS\$1RSA\$1MIT\$1AES\$1128\$1CBC\$1 SHA256 TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1MIT\$1 \$1 \$1 CHACHA20 POLY1305 SHA256 | Ja Nein Nein Ja Nein Ja Nein Nein Ja Nein Nein Ja Nein Ja Ja Nein | Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja | Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein |
| 11.20, 12.15, 13.11, 14.8, 15.3, 16.1 und höher | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1MIT\$1AES\$1128\$1CBC\$1 SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 TLS\$1RSA\$1MIT\$1AES\$1256\$1GCM\$1 SHA384 TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA TLS\$1RSA\$1MIT\$1AES\$1128\$1GCM\$1 SHA256 TLS\$1RSA\$1MIT\$1AES\$1128\$1CBC\$1 SHA256 TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1MIT\$1 \$1 \$1 CHACHA20 POLY1305 SHA256 TLS\$1AES\$1128\$1GCM\$1 SHA256 TLS\$1AES\$1256\$1GCM\$1 SHA384 | Ja Nein Nein Ja Nein Ja Nein Nein Ja Nein Nein Ja Nein Ja Ja Nein Nein Nein | Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Nein Nein | Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Nein Ja Ja |
Sie können auch den CLI-Befehl [describe-engine-default-cluster-parameters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-engine-default-cluster-parameters.html) verwenden, um zu ermitteln, welche Cipher Suites derzeit für eine bestimmte Parametergruppenfamilie unterstützt werden. Im folgenden Beispiel wird veranschaulicht, wie Sie die zulässigen Werte für `ssl_cipher`-Cluster-Parameter für Aurora PostgreSQL 11 abrufen.
```
aws rds describe-engine-default-cluster-parameters --db-parameter-group-family aurora-postgresql11
...some output truncated...
{
"ParameterName": "ssl_ciphers",
"Description": "Sets the list of allowed TLS ciphers to be used on secure connections.",
"Source": "engine-default",
"ApplyType": "dynamic",
"DataType": "list",
"AllowedValues": "DHE-RSA-AES128-SHA,DHE-RSA-AES128-SHA256,DHE-RSA-AES128-GCM-SHA256,DHE-RSA-AES256-SHA,DHE-RSA-AES256-SHA256,DHE-RSA-AES256-GCM-SHA384,
ECDHE-RSA-AES128-SHA,ECDHE-RSA-AES128-SHA256,ECDHE-RSA-AES128-GCM-SHA256,ECDHE-RSA-AES256-SHA,ECDHE-RSA-AES256-SHA384,ECDHE-RSA-AES256-GCM-SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
"IsModifiable": true,
"MinimumEngineVersion": "11.8",
"SupportedEngineModes": [
"provisioned"
]
},
...some output truncated...
```
Der Parameter `ssl_ciphers` ist standardmäßig auf alle zulässigen Verschlüsselungssuites eingestellt. Weitere Informationen zu Chiffren finden Sie in der [ssl\$1ciphers](https://www.postgresql.org/docs/current/runtime-config-connection.html#GUC-SSL-CIPHERS)-Variablen in der PostgreSQL-Dokumentation.
# Dynamische Maskierung mit Aurora PostgreSQL verwenden
Dynamische Datenmaskierung ist eine Sicherheitsfunktion, die sensible Daten in Aurora PostgreSQL-Datenbanken schützt, indem gesteuert wird, wie Daten Benutzern bei Abfragen angezeigt werden. Aurora implementiert es über die `pg_columnmask` Erweiterung. `pg_columnmask`bietet Datenschutz auf Spaltenebene, der die systemeigenen Sicherheits- und granularen Zugriffskontrollmechanismen von PostgreSQL auf Zeilenebene ergänzt.
Mit erstellen Sie Maskierungsrichtlinien`pg_columnmask`, die die Datentransparenz auf der Grundlage von Benutzerrollen festlegen. Wenn Benutzer Tabellen mit Maskierungsrichtlinien abfragen, wendet Aurora PostgreSQL zur Abfragezeit die entsprechende Maskierungsfunktion an, die auf der Rolle und der Richtliniengewichtung des Benutzers basiert. Die zugrunde liegenden Daten bleiben unverändert im Speicher.
`pg_columnmask`unterstützt die folgenden Funktionen:
+ **Integrierte und benutzerdefinierte Maskierungsfunktionen** — Verwenden Sie vorgefertigte Funktionen für gängige Muster wie E-Mail- und Textmaskierung oder erstellen Sie Ihre eigenen benutzerdefinierten Funktionen zum Schutz sensibler Daten (PII) mithilfe von SQL-basierten Maskierungsrichtlinien.
+ **Mehrere Maskierungsstrategien** — Verbergen Sie Informationen vollständig, ersetzen Sie Teilwerte durch Platzhalter oder definieren Sie benutzerdefinierte Maskierungsansätze.
+ **Priorisierung von Richtlinien** — Definieren Sie mehrere Richtlinien für eine einzelne Spalte. Verwenden Sie Gewichtungen, um zu bestimmen, welche Maskierungsrichtlinie verwendet werden soll, wenn mehrere Richtlinien für eine Spalte gelten. Aurora PostgreSQL wendet Richtlinien an, die auf Gewicht und Benutzerrollenzugehörigkeit basieren.
`pg_columnmask`ist auf Aurora PostgreSQL Version 16.10 und höher und Version 17.6 und höher verfügbar. Es ist ohne zusätzliche Kosten verfügbar.
# Erste Schritte mit dynamischer Maskierung
Um Daten dynamisch zu maskieren, installieren Sie die `pg_columnmask` Erweiterung in Ihrer Datenbank und erstellen Maskierungsrichtlinien für Ihre Tabellen. Der Einrichtungsprozess umfasst die Überprüfung der Voraussetzungen, die Installation der Erweiterung, die Rollenkonfiguration, die Erstellung von Richtlinien und die Überprüfung von Validierungstests.
## Installation und Konfiguration von Erweiterungen
Stellen Sie mit dem RDS Console Query Editor oder einem PostgreSQL-Client wie psql mit rds\$1superuser (Masteruser) -Anmeldeinformationen eine Connect zu Ihrem Aurora PostgreSQL-Cluster her.
Führen Sie den Befehl zur Erstellung der Erweiterung aus, um die Funktionalität zu aktivieren: `pg_columnmask`
```
CREATE EXTENSION pg_columnmask;
```
Mit diesem Befehl wird die `pg_columnmask` Erweiterung installiert, die erforderlichen Katalogtabellen erstellt und die integrierten Maskierungsfunktionen registriert. Die Installation der Erweiterung ist datenbankspezifisch, was bedeutet, dass Sie sie in jeder Datenbank, in der die Funktionalität benötigt wird, separat installieren müssen.
**Anmerkung**
Bei Verbindungen, die vor der Installation dieser Erweiterung hergestellt wurden, werden weiterhin unmaskierte Daten angezeigt. Schließen Sie und stellen Sie die Verbindung erneut her, um dieses Problem zu beheben.
Überprüfen Sie die Installation der Erweiterung, indem Sie die verfügbaren Maskierungsfunktionen überprüfen:
```
SELECT proname FROM pg_proc
WHERE pronamespace = 'pgcolumnmask'::regnamespace AND proname LIKE 'mask_%';
proname
--------Output --------
mask_email
mask_text
mask_timestamp
(3 rows)
```
# Verfahren zur Verwaltung von Datenmaskierungsrichtlinien
Sie können Maskierungsrichtlinien mithilfe der von der Erweiterung bereitgestellten Verfahren verwalten. `pg_columnmask` Um Maskierungsrichtlinien zu erstellen, zu ändern oder zu löschen, benötigen Sie eines der folgenden Rechte:
+ Besitzer der Tabelle, für die Sie die `pg_columnmask` Richtlinie erstellen.
+ Mitglied von`rds_superuser`.
+ Mitglied der durch den `pgcolumnmask.policy_admin_rolname` Parameter festgelegten Rolle des `pg_columnmask` Policy-Managers.
Mit dem folgenden Befehl wird eine Tabelle erstellt, die in nachfolgenden Abschnitten verwendet wird:
```
CREATE TABLE public.customers (
id SERIAL PRIMARY KEY,
name TEXT,
phone TEXT,
address TEXT,
email TEXT
);
```
## CREATE\$1MASKING\$1POLICY
Das folgende Verfahren erstellt eine neue Maskierungsrichtlinie für eine Benutzertabelle:
**Syntax**
```
create_masking_policy(
policy_name,
table_name,
masking_expressions,
roles,
weight)
```
**Argumente**
| Parameter | Datatype | Description |
| --- | --- | --- |
| policy\$1name | NAME | Der Name der Maskierungsrichtlinie. Muss pro Tabelle eindeutig sein. |
| table\$1name | REGCLASS | Der qualified/unqualified Name oder die OID der Tabelle, auf die die Maskierungsrichtlinie angewendet werden soll. |
| masking\$1expressions | JSONB | JSON-Objekt, das Paare aus Spaltennamen und Maskierungsfunktionen enthält. Jeder Schlüssel ist ein Spaltenname und sein Wert ist der Maskierungsausdruck, der auf diese Spalte angewendet werden soll. |
| roles | NAME [] | Die Rollen, für die diese Maskierungsrichtlinie gilt. Die Standardeinstellung ist PUBLIC. |
| weight | INT | Gewicht der Maskierungsrichtlinie. Wenn für die Anfrage eines bestimmten Benutzers mehrere Richtlinien gelten, wird die Richtlinie mit der höchsten Gewichtung (höhere Ganzzahl) auf jede maskierte Spalte angewendet. Standard = 0. Keine zwei Maskierungsrichtlinien in der Tabelle können dieselbe Gewichtung haben. |
**Rückgabetyp**
Keine
**Example beim Erstellen einer Maskierungsrichtlinie, die die E-Mail-Spalte für die Rolle maskiert: `test_user`**
```
CALL pgcolumnmask.create_masking_policy(
'customer_mask',
'public.customers',
JSON_OBJECT('{
"email", "pgcolumnmask.mask_email(email)"
}')::JSONB,
ARRAY['test_user'],
100
);
```
## ALTER\$1MASKING\$1POLICY
Dieses Verfahren ändert eine bestehende Maskierungsrichtlinie. `ALTER_MASKING_POLICY`kann die Maskierungsausdrücke der Richtlinie, die Gruppe der Rollen, für die die Richtlinie gilt, und die Gewichtung der Maskierungsrichtlinie ändern. Wenn einer dieser Parameter weggelassen wird, bleibt der entsprechende Teil der Richtlinie unverändert.
**Syntax**
```
alter_masking_policy(
policy_name,
table_name,
masking_expressions,
roles,
weight)
```
**Argumente**
| Parameter | Datatype | Description |
| --- | --- | --- |
| policy\$1name | NAME | Bestehender Name der Maskierungsrichtlinie. |
| table\$1name | REGCLASS | Die qualified/unqualified Name-OID der Tabelle, die die Maskierungsrichtlinie enthält. |
| masking\$1expressions | JSONB | Neues JSON-Objekt mit Spaltennamen und Maskierungsfunktionspaaren oder andernfalls NULL. |
| roles | NAME [] | Die Liste der neuen Rollen, für die diese Maskierungsrichtlinie gilt, andernfalls NULL. |
| weight | INT | Neue Gewichtung für die Maskierungsrichtlinie oder andernfalls NULL. |
**Rückgabetyp**
Keine
**Example zum Hinzufügen der Analystenrolle zu einer vorhandenen Maskierungsrichtlinie, ohne andere Richtlinienattribute zu ändern.**
```
CALL pgcolumnmask.alter_masking_policy(
'customer_mask',
'public.customers',
NULL,
ARRAY['test_user', 'analyst'],
NULL
);
-- Alter the weight of the policy without altering other details
CALL pgcolumnmask.alter_masking_policy(
'customer_mask',
'customers',
NULL,
NULL,
4
);
```
## DROP\$1MASKING\$1POLICY
Durch dieses Verfahren wird eine bestehende Maskierungsrichtlinie entfernt.
**Syntax**
```
drop_masking_policy(
policy_name,
table_name)
```
**Argumente**
| Parameter | Datatype | Description |
| --- | --- | --- |
| policy\$1name | NAME | Bestehender Name der Maskierungsrichtlinie. |
| table\$1name | REGCLASS | Die qualified/unqualified Name-OID der Tabelle, die die Maskierungsrichtlinie enthält. |
**Rückgabetyp**
Keine
**Example beim Löschen der Maskierungsrichtlinie customer\$1mask**
```
-- Drop a masking policy
CALL pgcolumnmask.drop_masking_policy(
'customer_mask',
'public.customers',
);
```
# Umgehen von Identifikatoren in der DDL-Prozedur für Maskierungsrichtlinien
Bei der Erstellung von Datenmaskierungsrichtlinien mit Identifikatoren in Anführungszeichen ist ein korrektes Escaping erforderlich, um sicherzustellen, dass die Objektverweise und die Richtlinien korrekt angewendet werden. Um Bezeichner in Anführungszeichen innerhalb der Verfahren zur Verwaltung von `pg_columnmask` Maskierungsrichtlinien zu verwenden, gehen Sie wie folgt vor:
+ **Richtlinienname** — Muss in doppelte Anführungszeichen gesetzt werden.
+ **Tabellenname** — Sowohl der Schemaname als auch der Tabellenname müssen bei Bedarf einzeln in doppelte Anführungszeichen gesetzt werden.
+ **Maskierungsausdrücke** — Spalten- und Funktionsnamen in Maskierungsausdrücken müssen in doppelte Anführungszeichen eingeschlossen werden, und die Anführungszeichen selbst müssen mit einem umgekehrten Schrägstrich maskiert werden.
+ **Rollen** — Das Array der Rollennamen wird automatisch in Anführungszeichen gesetzt. Der Rollenname sollte genau dem Namen entsprechen, wie er unter angegeben ist, `pg_roles` einschließlich Groß- und Kleinschreibung.
**Example der Syntax mit Escape-Zeichen und Anführungszeichen**
Dieses Beispiel zeigt die richtige Syntax für Escapes und Anführungszeichen bei der Erstellung von Maskierungsrichtlinien für Tabellen, Spalten, Funktionen und Rollen, die Namen in Groß- und Kleinschreibung verwenden oder Bezeichner in Anführungszeichen in Aurora PostgreSQL erfordern.
```
-- Create a table and columns with mixed case name
CREATE TABLE public."Employees" (
"Name" TEXT,
"Email" TEXT,
ssn VARCHAR(20)
);
-- Create a role with mixed case name
CREATE ROLE "Masked_user";
-- Create a function with mixed case name
CREATE OR REPLACE FUNCTION public."MaskEmail"(text)
RETURNS character varying
LANGUAGE plpgsql
IMMUTABLE PARALLEL SAFE
AS $$ BEGIN
RETURN 'XXXXXXXX'::text;
END $$;
-- Now use these objects with mixed case names in
-- masking policy management procedures
CALL pgcolumnmask.create_masking_policy(
'"Policy1"', -- policy name should be surrounded with double quotes for quoting
'public."Employees"', -- table and schema name should be individually
-- surrounded with double quotes for quoting
JSON_OBJECT('{
"\"Email\"", "\"MaskEmail\"(\"Email\")"
}')::JSONB, -- masking expression should have double quotes around function names
-- and columns names etc when needed. Also the double quotes itself
-- should be escaped using \ (backslash) since this is a JSON string
ARRAY['Masked_user'], -- Rolename do not need quoting
-- (this behaviour may change in future release)
100
);
SELECT * FROM pgcolumnmask.pg_columnmask_policies
WHERE tablename = 'Employees';
-[ RECORD 1 ]-----+-------------------------------------
schemaname | public
tablename | Employees
policyname | Policy1
roles | {Masked_user}
masked_columns | {Email}
masking_functions | {"(\"MaskEmail\"(\"Email\"))::text"}
weight | 100
```
## Administrative Ansichten
Sie können die gesamte `pg_columnmask` Richtlinie in der öffentlich zugänglichen `pgcolumnmask.pg_columnmask_policies` Verwaltungsansicht überprüfen. Die folgenden Informationen sind in dieser Ansicht verfügbar. Die Ansicht gibt nur die Maskierungsrichtlinien zurück, die dem aktuellen Benutzer gehören.
| Name der Spalte | Datentyp | Beschreibung |
| --- | --- | --- |
| schemaname | NAME | Schema der Beziehung, an die die Richtlinie angehängt ist |
| tablename | NAME | Name der Beziehung, an die die Richtlinie angehängt ist |
| Name der Richtlinie | NAME | Name der Maskierungsrichtlinie. Alle Maskierungsrichtlinien haben eindeutige Namen |
| Rollen | TEXT [] | Rolle, für die die Richtlinie gilt. |
| masked\$1columns | TEXT [] | Maskierte Spalten |
| maskierende Funktionen | TEXT [] | Maskierungsfunktionen |
| Gewichtung | INT | Gewicht der beigefügten Richtlinie |
# Vordefinierte Datenmaskierungsfunktionen
`pg_columnmask`Die Erweiterung bietet integrierte Hilfsfunktionen, die in der Sprache C geschrieben sind (für eine schnellere Ausführung) und als Maskierungsausdruck für `pg_columnmask` Richtlinien verwendet werden können.
**mask\$1text**
Eine Funktion zum Maskieren von Textdaten mit konfigurierbaren Sichtbarkeitsoptionen.
**Argumente**
| Parameter | Datatype | Description |
| --- | --- | --- |
| input | TEXT | Die ursprüngliche Textzeichenfolge, die maskiert werden soll |
| mask\$1char | CHAR (1) | Für die Maskierung verwendetes Zeichen (Standard: 'X') |
| visible\$1prefix | INT | Anzahl der Zeichen am Anfang des Eingabetextes, die unmaskiert bleiben (Standard: 0) |
| visible\$1suffix | INT | Anzahl der Zeichen am Ende des Eingabetextes, die unmaskiert bleiben (Standard: 0) |
| use\$1hash\$1mask | BOOLEAN | Bei TRUE wird anstelle von mask\$1char eine Hash-basierte Maskierung verwendet (Standard: FALSE) |
**Example der Verwendung verschiedener Maskierungsoptionen**
Maskiert die gesamte Eingabezeichenfolge mit dem Standardzeichen 'X'
```
postgres=> SELECT pgcolumnmask.mask_text('Hello World');
mask_text
-------------
XXXXXXXXXXX
```
Verwenden Sie das `mask_char` Argument, um Texteingaben mit einem anderen Zeichen zu maskieren
```
postgres=> SELECT pgcolumnmask.mask_text('Hello World', '*');
mask_text
-------------
***********
```
Verwenden Sie `visible_prefix` und `visible_suffix` -Parameter, um zu steuern, wie viele Zeichen am Anfang und Ende des Textes unmaskiert bleiben
```
postgres=> SELECT pgcolumnmask.mask_text('Hello World', '*', 5, 1);
mask_text
-------------
Hello*****d
```
Wenn wahr, `use_hash_mask` wird die Eingabezeichenfolge mit zufälligen Zeichen maskiert, `mask_char` das Argument wird ignoriert, aber trotzdem `visible_prefix` berücksichtigt `visible_suffix`
```
postgres=> SELECT pgcolumnmask.mask_text('Hello World', '*', 2, 2, true);
mask_text
-------------
Hex36dOHild
```
**mask\$1timestamp**
| Parameter | Datatype | Description |
| --- | --- | --- |
| ts\$1to\$1mask | TIMESTAMP (ZEITSTEMPEL) | Der ursprüngliche Zeitstempel, der maskiert werden soll |
| mask\$1part | TEXT | Gibt an, welcher Teil des Zeitstempels maskiert werden soll (Standard: 'all') Gültige Werte: 'Jahr', 'Monat', 'Tag', 'Stunde', 'Minute', 'Sekunde', 'alles' |
| mask\$1value | TIMESTAMP (ZEITSTEMPEL) | Der Zeitstempelwert, der für die Maskierung verwendet werden soll (Standard: '1900-01-01 00:00:00 ') |
**Example Verwendung von `mask_timestamps`**
Diese Beispiele veranschaulichen die vollständige Maskierung des Zeitstempels auf einen Standardwert, die teilweise Maskierung bestimmter Zeitstempelkomponenten (nur Jahr) und die Maskierung mit einem benutzerdefinierten Ersatzwert.
Maskiert den Eingabewert vollständig mit dem Standardzeitstempel
```
postgres=> SELECT pgcolumnmask.mask_timestamp('2023-06-15 14:30:00');
mask_timestamp
---------------------
1900-01-01 00:00:00
```
Um nur einen Teil des Zeitstempels zu maskieren, zum Beispiel nur das Jahr
```
postgres=> SELECT pgcolumnmask.mask_timestamp('2023-06-15 14:30:00', 'year');
mask_timestamp
---------------------
1900-06-15 14:30:00
```
Um den maskierten Wert für den Zeitstempel zu ändern, verwenden Sie das Argument `mask_value`
```
postgres=> SELECT pgcolumnmask.mask_timestamp('2023-06-15 14:30:00', 'all', '2012-12-12 12:12:12');
mask_timestamp
---------------------
2012-12-12 12:12:12
```
**mask\$1timestamp**
Eine Funktion zum Maskieren von E-Mail-Adressen unter Beibehaltung der E-Mail-Struktur.
| Parameter | Datatype | Description |
| --- | --- | --- |
| input | TEXT | Die ursprüngliche E-Mail-Adresse, die maskiert werden soll |
| mask\$1char | CHAR (1) | Für die Maskierung verwendetes Zeichen (Standard: 'X') |
| mask\$1local | BOOLEAN | Bei TRUE wird der lokale Teil der E-Mail (vor @) maskiert (Standard: TRUE) |
| mask\$1domain | BOOLEAN | Bei TRUE wird der Domänenteil der E-Mail (nach @) maskiert (Standard: TRUE) |
**Example Verwendung von `mask_email`**
Diese Beispiele veranschaulichen die vollständige E-Mail-Maskierung, benutzerdefinierte Maskenzeichen und die selektive Maskierung entweder des lokalen Teils oder des Domainteils der E-Mail-Adresse.
Vollständige Maskierung
```
postgres=> SELECT pgcolumnmask.mask_email('user@example.com');
mask_email
------------------
XXXX@XXXXXXX.com
```
Dient `mask_char` zum Ändern des für die Maskierung verwendeten Zeichens
```
postgres=> SELECT pgcolumnmask.mask_email('user@example.com', '*');
mask_email
------------------
****@*******.com
```
Verwenden Sie `mask_local` und`mask_domain`, um die Maskierung auf lokaler Ebene und in der Domäne zu steuern
```
postgres=> SELECT pgcolumnmask.mask_email('user@example.com', '*', true, false);
mask_email
------------------
****@example.com
postgres=> SELECT pgcolumnmask.mask_email('user@example.com', '*', false, true);
mask_email
------------------
user@*******.com
```
# Implementierung von pg\$1columnmask in einem Workflow end-to-end
In diesem Abschnitt wird eine vollständige Implementierung der `pg_columnmask` Verwendung einer Beispieltabelle für Mitarbeiter mit sensiblen Daten demonstriert. Sie erfahren, wie Sie benutzerdefinierte Maskierungsfunktionen erstellen, mehrere Maskierungsrichtlinien mit unterschiedlichen Gewichtungsstufen für verschiedene Rollen (Praktikant, Support, Analyst) definieren und beobachten, wie Benutzer mit einer oder mehreren Rollenmitgliedschaften unterschiedliche Ebenen maskierter Daten sehen. Die Beispiele behandeln auch das Maskierungsverhalten in DML-Anweisungen mit RETURNING-Klauseln, Trigger für Tabellen im Vergleich zu Ansichten und Policy-Management-Operationen wie Umbenennen, Ändern von Gewichtungen und Bereinigung.
1. Erstellen Sie eine Beispieltabelle mit einigen sensiblen Daten:
```
CREATE SCHEMA hr;
CREATE TABLE hr.employees (
id INT PRIMARY KEY,
name TEXT NOT NULL,
email TEXT,
ssn TEXT,
salary NUMERIC(10,2)
);
INSERT INTO hr.employees VALUES
(1, 'John Doe', 'john.doe@example.com', '123-45-6789', 50000.00),
(2, 'Jane Smith', 'jane.smith@example.com', '987-65-4321', 60000.00);
```
1. Erstellen Sie benutzerdefinierte Maskierungsfunktionen:
```
CREATE OR REPLACE FUNCTION public.mask_ssn(ssn TEXT)
RETURNS TEXT AS $$
BEGIN
RETURN 'XXX-XX-' || RIGHT(ssn, 4);
END;
$$ LANGUAGE plpgsql;
CREATE OR REPLACE FUNCTION public.mask_salary(salary NUMERIC, multiplier NUMERIC DEFAULT 0.0)
RETURNS NUMERIC AS $$
BEGIN
RETURN salary * multiplier;
END;
$$ LANGUAGE plpgsql;
```
1. Erstellen Sie mehrere Richtlinien mit unterschiedlichen Maskierungsstufen, die auf den Benutzerrollen basieren:
```
-- Create different roles
CREATE ROLE analyst_role;
CREATE ROLE support_role;
CREATE ROLE intern_role;
GRANT USAGE ON SCHEMA hr TO analyst_role, support_role, intern_role;
GRANT SELECT ON hr.employees TO analyst_role, support_role, intern_role;
----------------------------------------------------------------------
-- Low-Weight Policy (Intern)
CALL pgcolumnmask.create_masking_policy(
'employee_mask_strict',
'hr.employees',
JSON_BUILD_OBJECT('name', 'pgcolumnmask.mask_text(name, ''*'')',
'email', 'pgcolumnmask.mask_email(email)',
'ssn', 'pgcolumnmask.mask_text(ssn, ''*'')',
'salary', 'public.mask_salary(salary)')::JSONB,
ARRAY['intern_role'],
10 -- Lowest weight
);
----------------------------------------------------------------------
-- Medium-Weight Policy (Support)
CALL pgcolumnmask.create_masking_policy(
'employee_mask_moderate',
'hr.employees',
JSON_BUILD_OBJECT('email', 'pgcolumnmask.mask_email(email, ''#'')',
'ssn', 'public.mask_ssn(ssn)',
'salary', 'public.mask_salary(salary)')::JSONB,
ARRAY['support_role'],
50 -- Medium weight
);
----------------------------------------------------------------------
-- High-Weight Policy (Analyst)
CALL pgcolumnmask.create_masking_policy(
'employee_mask_light',
'hr.employees',
JSON_BUILD_OBJECT('ssn', 'public.mask_ssn(ssn)',
'salary', 'public.mask_salary(salary, 0.9)')::JSONB,
ARRAY['analyst_role'],
100 -- Highest weight
);
```
1. Die folgenden Beispiele zeigen, wie verschiedene Benutzer Daten auf der Grundlage ihrer Rollenzugehörigkeit und der Gewichtung ihrer Richtlinien sehen.
```
-- Create users
CREATE USER sarah_intern;
GRANT intern_role TO sarah_intern;
CREATE USER lisa_support;
GRANT support_role TO lisa_support;
CREATE USER mike_analyst;
GRANT analyst_role TO mike_analyst;
CREATE USER ethan_support_intern;
GRANT support_role, intern_role TO ethan_support_intern;
CREATE USER john_analyst_intern;
GRANT analyst_role, intern_role TO john_analyst_intern;
```
Als Praktikant (strengste Maskierung):
```
SET ROLE sarah_intern;
SELECT * FROM hr.employees;
id | name | email | ssn | salary
----+------------+------------------------+-------------+--------
1 | ******** | XXXXXXXX@XXXXXXX.com | *********** | 0.00
2 | ********** | XXXXXXXXXX@XXXXXXX.com | *********** | 0.00
```
Als Support-Benutzer (moderate Maskierung):
```
SET ROLE lisa_support;
SELECT * FROM hr.employees;
id | name | email | ssn | salary
----+------------+------------------------+-------------+--------
1 | John Doe | ########@#######.com | XXX-XX-6789 | 0.00
2 | Jane Smith | ##########@#######.com | XXX-XX-4321 | 0.00
```
Als Analyst (leichteste Maskierung):
```
SET ROLE mike_analyst;
SELECT * FROM hr.employees;
id | name | email | ssn | salary
----+------------+------------------------+-------------+----------
1 | John Doe | john.doe@example.com | XXX-XX-6789 | 45000.00
2 | Jane Smith | jane.smith@example.com | XXX-XX-4321 | 54000.00
```
Als ethan\$1support\$1intern-Benutzer, der sowohl Praktikant als auch Support-Benutzer ist:
```
SET ROLE ethan_support_intern;
-- masking policies appliable to this user: employee_mask_strict and employee_mask_moderate
-- id : unmasked because no masking policy appliable on ethan_support_intern
-- masks these columns
-- name : masked because of employee_mask_strict policy
-- email, ssn, salary : both employee_mask_strict and employee_mask_moderate mask these columns
-- but employee_mask_moderate will be use because of higher weight
SELECT * FROM hr.employees;
id | name | email | ssn | salary
----+------------+------------------------+-------------+--------
1 | ******** | ########@#######.com | XXX-XX-6789 | 0.00
2 | ********** | ##########@#######.com | XXX-XX-4321 | 0.00
```
Als john\$1analyst\$1intern, der sowohl Praktikant als auch Analyst ist:
```
SET ROLE john_analyst_intern;
-- masking policies appliable to this user: employee_mask_strict and employee_mask_light
-- id : unmasked because no masking policy appliable on john_analyst_intern
-- masks these columns
-- name, email : masked because of employee_mask_strict
-- ssn, salary : both employee_mask_strict and employee_mask_light mask these columns
-- but employee_mask_light will be use because of higher weight
SELECT * FROM hr.employees;
id | name | email | ssn | salary
----+------------+------------------------+-------------+----------
1 | ******** | XXXXXXXX@XXXXXXX.com | XXX-XX-6789 | 45000.00
2 | ********** | XXXXXXXXXX@XXXXXXX.com | XXX-XX-4321 | 54000.00
```
# Grundlegendes zum Maskierungsverhalten bei DML-Vorgängen
`pg_columnmask`gilt konsistent für alle DML-Operationen, einschließlich INSERT-, UPDATE-, DELETE- und MERGE-Anweisungen. Wenn Sie diese Operationen ausführen, maskiert Aurora PostgreSQL Daten nach einem Kernprinzip: Alle aus dem Speicher gelesenen Daten werden gemäß den geltenden Richtlinien des aktuellen Benutzers maskiert.
Die Maskierung wirkt sich auf einige der folgenden Abfragekomponenten aus, z. B.:
+ WHERE-Klauseln
+ JOIN-Bedingungen
+ Unterabfragen
+ RETURNING-Klausen
Alle diese Komponenten arbeiten mit maskierten Werten, nicht mit den Originaldaten. Daten werden zwar unmaskiert in den Speicher geschrieben, Benutzer sehen jedoch nur ihre maskierte Ansicht, wenn sie sie zurücklesen.
Aurora PostgreSQL erzwingt alle Datenbankeinschränkungen (NOT NULL, UNIQUE, CHECK, FOREIGN KEY) für die tatsächlich gespeicherten Werte, nicht für maskierte Werte. Dies kann gelegentlich zu offensichtlichen Inkonsistenzen führen, wenn die Maskierungsfunktionen nicht sorgfältig entworfen wurden.
Die Maskierung funktioniert zusammen mit Berechtigungen auf Spaltenebene:
+ Benutzer ohne SELECT-Rechte können keine Spalten lesen
+ Benutzern mit SELECT-Rechten werden maskierte Werte gemäß ihren geltenden Richtlinien angezeigt
# Verstehen des Maskierungsverhaltens in Triggerfunktionen
Wenn `pg_columnmask` Richtlinien auf Tabellen angewendet werden, ist es wichtig zu verstehen, wie Maskierung mit Triggerfunktionen interagiert. Trigger sind Datenbankfunktionen, die automatisch als Reaktion auf bestimmte Ereignisse in einer Tabelle ausgeführt werden, z. B. INSERT-, UPDATE- oder DELETE-Operationen.
Standardmäßig wendet DDM je nach Triggertyp unterschiedliche Maskierungsregeln an:
Tabellentrigger
**Übergangstabellen sind unmaskiert** — Triggerfunktionen für Tabellen haben Zugriff auf unmaskierte Daten in ihren Übergangstabellen sowohl für alte als auch für neue Zeilenversionen
Tabellenbesitzer erstellen Trigger und sind Eigentümer der Daten, sodass sie vollen Zugriff haben, um ihre Tabellen effektiv zu verwalten
Trigger anzeigen (STATT Trigger)
**Übergangstabellen sind maskiert** — Triggerfunktionen in Ansichten sehen maskierte Daten entsprechend den Berechtigungen des aktuellen Benutzers
Eigentümer von Ansichten können sich von Besitzern von Basistabellen unterscheiden und sollten die Maskierungsrichtlinien für die zugrunde liegenden Tabellen beachten
Zwei Konfigurationsparameter auf Serverebene steuern das Triggerverhalten bei maskierten Tabellen. Diese können nur gesetzt werden durch: `rds_superuser`
+ **Trigger für maskierte Tabellen einschränken** — Verhindert die Ausführung von Triggern, wenn ein maskierter Benutzer DML-Operationen an Tabellen mit entsprechenden Maskierungsrichtlinien ausführt.
+ **Trigger für Ansichten mit maskierten Tabellen einschränken:** — Verhindert die Ausführung von Triggern für Ansichten, wenn die Ansichtsdefinition Tabellen mit Maskierungsrichtlinien enthält, die für den aktuellen Benutzer gelten.
**Example der Unterschiede zwischen der Funktionsanwendung auf Tabelle und Ansicht**
Im folgenden Beispiel wird eine Triggerfunktion erstellt, die alte und neue Zeilenwerte ausgibt. Anschließend wird veranschaulicht, wie sich dieselbe Funktion, wenn sie an eine Tabelle angehängt wird, anders verhält als bei einer Ansicht.
```
-- Create trigger function
CREATE OR REPLACE FUNCTION print_changes()
RETURNS TRIGGER AS
$$
BEGIN
RAISE NOTICE 'Old row: name=%, email=%, ssn=%, salary=%',
OLD.name, OLD.email, OLD.ssn, OLD.salary;
RAISE NOTICE 'New row: name=%, email=%, ssn=%, salary=%',
NEW.name, NEW.email, NEW.ssn, NEW.salary;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
-- Create trigger
CREATE TRIGGER print_changes_trigger
BEFORE UPDATE ON hr.employees
FOR EACH ROW
EXECUTE FUNCTION print_changes();
-- Grant update to analyst role
GRANT UPDATE ON hr.employees TO analyst_role;
-- Unmasked data must be seen inside trigger even for masked user for the OLD and NEW
-- row passed to trigger function
BEGIN;
SET ROLE mike_analyst;
UPDATE hr.employees SET id = id + 10 RETURNING *;
NOTICE: Old row: name=John Doe, email=john.doe@example.com, ssn=123-45-6789, salary=50000.00
NOTICE: New row: name=John Doe, email=john.doe@example.com, ssn=123-45-6789, salary=50000.00
NOTICE: Old row: name=Jane Smith, email=jane.smith@example.com, ssn=987-65-4321, salary=60000.00
NOTICE: New row: name=Jane Smith, email=jane.smith@example.com, ssn=987-65-4321, salary=60000.00
id | name | email | ssn | salary
----+------------+------------------------+-------------+----------
11 | John Doe | john.doe@example.com | XXX-XX-6789 | 45000.00
12 | Jane Smith | jane.smith@example.com | XXX-XX-4321 | 54000.00
(2 rows)
ROLLBACK;
-- Triggers on views (which are supposed to see masked data for new/old row)
CREATE VIEW hr.view_over_employees AS SELECT * FROM hr.employees;
GRANT UPDATE, SELECT ON hr.view_over_employees TO analyst_role;
-- Create trigger for this view
CREATE TRIGGER print_changes_trigger
INSTEAD OF UPDATE ON hr.view_over_employees
FOR EACH ROW
EXECUTE FUNCTION print_changes();
-- Masked new and old rows should be passed to trigger if trigger is on view
BEGIN;
SET ROLE mike_analyst;
UPDATE hr.view_over_employees SET id = id + 10 RETURNING *;
NOTICE: Old row: name=John Doe, email=john.doe@example.com, ssn=XXX-XX-6789, salary=45000.00
NOTICE: New row: name=John Doe, email=john.doe@example.com, ssn=XXX-XX-6789, salary=45000.00
NOTICE: Old row: name=Jane Smith, email=jane.smith@example.com, ssn=XXX-XX-4321, salary=54000.00
NOTICE: New row: name=Jane Smith, email=jane.smith@example.com, ssn=XXX-XX-4321, salary=54000.00
id | name | email | ssn | salary
----+------------+------------------------+-------------+----------
11 | John Doe | john.doe@example.com | XXX-XX-6789 | 45000.00
12 | Jane Smith | jane.smith@example.com | XXX-XX-4321 | 54000.00
(2 rows)
ROLLBACK;
```
Wir empfehlen, das Verhalten des Triggers zu überprüfen, bevor Sie Trigger in maskierten Tabellen implementieren. Tabellen-Trigger haben Zugriff auf unmaskierte Daten in Übergangstabellen, während View-Trigger maskierte Daten sehen.
**Example der Maskierungsrichtlinie beim Umbenennen**
Das folgende Beispiel zeigt, wie vorhandene Richtlinien mithilfe des `rename_masking_policy` Verfahrens umbenannt werden.
```
-- Rename the strict policy
CALL pgcolumnmask.rename_masking_policy(
'employee_mask_strict',
'hr.employees',
'intern_protection_policy'
);
-- Verify the rename
SELECT policyname, roles, weight
FROM pgcolumnmask.pg_columnmask_policies
WHERE tablename = 'employees'
ORDER BY weight DESC;
policyname | roles | weight
--------------------------+----------------+--------
employee_mask_light | {analyst_role} | 100
employee_mask_moderate | {support_role} | 50
intern_protection_policy | {intern_role} | 10
```
**Example der Änderung des politischen Gewichts**
Das folgende Beispiel zeigt, wie das Gewicht von Policen geändert werden kann, um ihr Gewicht zu ändern.
```
-- Change weight of moderate policy
CALL pgcolumnmask.alter_masking_policy(
'employee_mask_moderate'::NAME,
'hr.employees'::REGCLASS,
NULL, -- Keep existing masking expressions
NULL, -- Keep existing roles
75 -- New weight
);
-- Verify the changes
SELECT policyname, roles, weight
FROM pgcolumnmask.pg_columnmask_policies
WHERE tablename = 'employees'
ORDER BY weight DESC;
policyname | roles | weight
--------------------------+----------------+--------
employee_mask_light | {analyst_role} | 100
employee_mask_moderate | {support_role} | 75
intern_protection_policy | {intern_role} | 10
```
**Example des Aufräumens**
Das folgende Beispiel zeigt, wie alle Richtlinien, Tabellen und Benutzer gelöscht werden.
```
-- Drop policies
CALL pgcolumnmask.drop_masking_policy(
'intern_protection_policy',
'hr.employees'
);
CALL pgcolumnmask.drop_masking_policy(
'employee_mask_moderate',
'hr.employees'
);
CALL pgcolumnmask.drop_masking_policy(
'employee_mask_light',
'hr.employees'
);
-- Drop table and functions
DROP VIEW IF EXISTS hr.view_over_employees;
DROP TABLE IF EXISTS hr.employees;
DROP SCHEMA IF EXISTS hr;
DROP FUNCTION IF EXISTS public.mask_ssn(text);
DROP FUNCTION IF EXISTS public.mask_salary(numeric, numeric);
-- Drop users
DROP USER sarah_intern, lisa_support, mike_analyst,
ethan_support_intern, john_analyst_intern;
DROP ROLE intern_role, support_role, analyst_role;
```
# Verwaltungsrolle für Maskierungsrichtlinien konfigurieren
Die PostgreSQL-Erweiterung zur Spaltenmaskierung ermöglicht es Ihnen`pg_columnmask`, die Verwaltung von Maskierungsrichtlinien an eine bestimmte Rolle zu delegieren, anstatt Tabellenbesitzerrechte zu verlangen`rds_superuser`. Dies ermöglicht eine genauere Kontrolle darüber, wer Maskierungsrichtlinien erstellen, ändern und löschen kann.
Gehen Sie wie folgt vor, um die Rolle zu konfigurieren, der Verwaltungsrechte für Maskierungsrichtlinien zugewiesen werden sollen:
1. Erstellen Sie die Rolle des Richtlinienadministrators — Erstellen Sie als Nächstes eine neue Rolle`rds_superuser`, die für die Verwaltung von Maskierungsrichtlinien zuständig ist:
```
CREATE ROLE mask_admin NOLOGIN;
```
1. PostgreSQL-Parameter konfigurieren — Legen Sie in Ihrer benutzerdefinierten DB-Cluster-Parametergruppe den `pgcolumnmask.policy_admin_rolname` Engine-Konfigurationsparameter auf den Namen der Rolle fest, die Sie erstellt haben:
```
pgcolumnmask.policy_admin_rolname = mask_admin
```
Diese Engine-Konfigurationsparameter können in einer DB-Cluster-Parametergruppe festgelegt werden und erfordern keinen Instance-Neustart. Einzelheiten zur Aktualisierung des Parameters finden Sie unter[Ändern von Parametern in einer DB-Cluster-Parametergruppe in Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md).
1. Weisen Sie Benutzern die Rolle zu. Weisen Sie die `mask_admin` Rolle den Benutzern zu`rds_superuser`, die in der Lage sein sollten, Maskierungsrichtlinien zu verwalten:
```
CREATE USER alice LOGIN;
CREATE USER bob LOGIN;
GRANT mask_admin TO alice, bob;
```
Stellen Sie außerdem sicher, dass die Benutzer über die USAGE-Rechte für die Schemas verfügen, in denen sie Maskierungsrichtlinien verwalten werden:
```
GRANT USAGE ON SCHEMA hr TO alice, bob;
```
Wenn Benutzer `alice` nun `bob` eine Verbindung zur Datenbank herstellen, können sie die `pg_columnmask` Standarderweiterungsfunktionen verwenden, um Maskierungsrichtlinien für alle Tabellen in allen Schemas zu erstellen, zu ändern und zu löschen, für die sie `USAGE` Berechtigungen für das Schema haben.
# Bewährte Methoden für die sichere Implementierung von pg\$1columnmask
Der folgende Abschnitt enthält bewährte Sicherheitsmethoden für die Implementierung `pg_columnmask` in Ihrer Aurora PostgreSQL-Umgebung. Folgen Sie diesen Empfehlungen, um:
+ Richten Sie eine sichere, rollenbasierte Architektur für die Zugriffskontrolle ein
+ Entwickeln Sie Maskierungsfunktionen, die Sicherheitslücken verhindern
+ Verstehen und kontrollieren Sie das Triggerverhalten mit maskierten Daten
## Rollenbasierte Sicherheitsarchitektur
Definieren Sie eine Rollenhierarchie, um Zugriffskontrollen in Ihrer Datenbank zu implementieren. Aurora PostgreSQL `pg_columnmask` erweitert diese Kontrollen, indem es eine zusätzliche Ebene für die feinkörnige Datenmaskierung innerhalb dieser Rollen bereitstellt.
Erstellen Sie spezielle Rollen, die auf die Unternehmensfunktionen abgestimmt sind, anstatt einzelnen Benutzern Berechtigungen zu gewähren. Dieser Ansatz bietet eine bessere Überprüfbarkeit und vereinfacht das Berechtigungsmanagement, wenn sich Ihre Organisationsstruktur weiterentwickelt.
**Example der Schaffung einer organisatorischen Rollenhierarchie**
Im folgenden Beispiel wird eine organisatorische Rollenhierarchie mit speziellen Rollen für verschiedene Funktionen erstellt und anschließend einzelnen Benutzern die entsprechenden Rollen zugewiesen. In diesem Beispiel werden zuerst Organisationsrollen (analyst\$1role, support\$1role) erstellt, dann wird einzelnen Benutzern die Mitgliedschaft in diesen Rollen gewährt. Diese Struktur ermöglicht es Ihnen, Berechtigungen auf Rollenebene und nicht für jeden einzelnen Benutzer zu verwalten.
```
-- Create organizational role hierarchy
CREATE ROLE data_admin_role;
CREATE ROLE security_admin_role;
CREATE ROLE analyst_role;
CREATE ROLE support_role;
CREATE ROLE developer_role;
-- Specify security_admin_role as masking policy manager in the DB cluster parameter
-- group pgcolumnmask.policy_admin_rolname = 'security_admin_role'
-- Create specific users and assign to appropriate roles
CREATE USER security_manager;
CREATE USER data_analyst1, data_analyst2;
CREATE USER support_agent1, support_agent2;
GRANT security_admin_role TO security_manager;
GRANT analyst_role TO data_analyst1, data_analyst2;
GRANT support_role TO support_agent1, support_agent2;
```
Implementieren Sie das Prinzip der geringsten Rechte, indem Sie nur die für jede Rolle erforderlichen Mindestberechtigungen gewähren. Vermeiden Sie die Gewährung umfassender Berechtigungen, die ausgenutzt werden könnten, wenn Anmeldeinformationen kompromittiert werden.
```
-- Grant specific table permissions rather than schema-wide access
GRANT SELECT ON sensitive_data.customers TO analyst_role;
GRANT SELECT ON sensitive_data.transactions TO analyst_role;
-- Do not grant: GRANT ALL ON SCHEMA sensitive_data TO analyst_role;
```
Richtlinienadministratoren benötigen `USAGE` Rechte für Schemas, in denen sie Maskierungsrichtlinien verwalten. Gewähren Sie diese Rechte selektiv und folgen Sie dabei dem Prinzip der geringsten Rechte. Führen Sie regelmäßige Überprüfungen der Schemazugriffsberechtigungen durch, um sicherzustellen, dass nur autorisiertes Personal über die Funktionen zur Richtlinienverwaltung verfügt.
Die Konfiguration der Rollenparameter des Policy-Administrators ist nur auf Datenbankadministratoren beschränkt. Dieser Parameter kann nicht auf Datenbank- oder Sitzungsebene geändert werden, wodurch verhindert wird, dass Benutzer ohne Benutzerrechte die Zuweisungen von Richtlinienadministratoren außer Kraft setzen. Diese Einschränkung stellt sicher, dass die Kontrolle der Maskierungsrichtlinien zentralisiert und sicher bleibt.
Weisen Sie die Rolle des Richtlinienadministrators bestimmten Personen und nicht Gruppen zu. Dieser gezielte Ansatz gewährleistet einen selektiven Zugriff auf die Verwaltung von Maskierungsrichtlinien, da Richtlinienadministratoren alle Tabellen in der Datenbank maskieren können.
## Entwicklung sicherer Maskierungsfunktionen
Entwickeln Sie Maskierungsfunktionen unter Verwendung von Semantik für frühe Bindungen, um eine korrekte Nachverfolgung von Abhängigkeiten sicherzustellen und Sicherheitslücken bei späten Bindungen zu vermeiden, z. B. die Änderung von Suchpfaden während der Laufzeit. Es wird empfohlen, die `BEGIN ATOMIC` Syntax für SQL-Funktionen zu verwenden, um die Validierung während der Kompilierung (d. h. frühes Binden) und das Abhängigkeitsmanagement zu ermöglichen.
```
-- Example - Secure masking function with early binding
CREATE OR REPLACE FUNCTION secure_mask_ssn(input_ssn TEXT)
RETURNS TEXT
LANGUAGE SQL
IMMUTABLE PARALLEL SAFE STRICT
BEGIN ATOMIC
SELECT CASE
WHEN input_ssn IS NULL THEN NULL
WHEN length(input_ssn) < 4 THEN repeat('X', length(input_ssn))
ELSE repeat('X', length(input_ssn) - 4) || right(input_ssn, 4)
END;
END;
```
Alternativ können Sie Funktionen erstellen, die immun gegen Änderungen des Suchpfads sind, indem Sie alle Objektreferenzen explizit per Schema qualifizieren und so ein konsistentes Verhalten über verschiedene Benutzersitzungen hinweg sicherstellen.
```
-- Function immune to search path changes
CREATE OR REPLACE FUNCTION data_masking.secure_phone_mask(phone_number TEXT)
RETURNS TEXT
LANGUAGE SQL
IMMUTABLE PARALLEL SAFE STRICT
AS $$
SELECT CASE
WHEN phone_number IS NULL THEN NULL
WHEN public.length(public.regexp_replace(phone_number, '[^0-9]', '', 'g')) < 10 THEN 'XXX-XXX-XXXX'
ELSE public.regexp_replace(
phone_number,
'([0-9]{3})[0-9]{3}([0-9]{4})',
public.concat('\1-XXX-\2')
)
END;
$$;
```
Implementieren Sie die Eingabevalidierung innerhalb von Maskierungsfunktionen, um Sonderfälle zu behandeln und unerwartetes Verhalten zu verhindern. Schließen Sie immer die NULL-Behandlung ein und validieren Sie die Eingabeformate, um ein konsistentes Maskierungsverhalten sicherzustellen.
```
-- Robust masking function with comprehensive input validation
CREATE OR REPLACE FUNCTION secure_mask_phone(phone_number TEXT)
RETURNS TEXT
LANGUAGE SQL
IMMUTABLE PARALLEL SAFE STRICT
BEGIN ATOMIC
SELECT CASE
WHEN phone_number IS NULL THEN NULL
WHEN length(trim(phone_number)) = 0 THEN phone_number
WHEN length(regexp_replace(phone_number, '[^0-9]', '', 'g')) < 10 THEN 'XXX-XXX-XXXX'
ELSE regexp_replace(phone_number, '([0-9]{3})[0-9]{3}([0-9]{4})', '\1-XXX-\2')
END;
END;
```
## DML löst Verhalten mit pg\$1columnmask aus
Bei Tabellentriggern werden Übergangstabellen vollständig demaskiert. Bei View-Triggern (IOT) werden Übergangstabellen entsprechend den Anzeigeberechtigungen des aktuellen Benutzers maskiert.
Tabellentrigger werden mit pg\$1columnmask ausgelöst
Triggern wird eine Übergangstabelle übergeben, die die alte und die neue Version der Zeilen enthält, die durch die auslösende DML-Abfrage geändert wurden. Je nachdem, wann der Trigger ausgelöst wird, füllt Aurora PostgreSQL die alten und neuen Zeilen auf. Ein `BEFORE INSERT` Trigger hat beispielsweise nur neue Versionen der Zeilen und leere alte Versionen, weil es keine alte Version gibt, auf die verwiesen werden kann.
`pg_columnmask`maskiert keine Übergangstabellen innerhalb von Triggern für Tabellen. Trigger können maskierte Spalten in ihrem Hauptteil verwenden, und es werden unmaskierte Daten angezeigt. Der Ersteller des Triggers sollte sicherstellen, wie der Trigger für einen Benutzer ausgeführt wird. Das folgende Beispiel funktioniert in diesem Fall korrekt.
```
-- Example for table trigger uses masked column in its definition
-- Create a table and insert some rows
CREATE TABLE public.credit_card_table (
name TEXT,
credit_card_no VARCHAR(16),
is_fraud BOOL
);
INSERT INTO public.credit_card_table (name, credit_card_no, is_fraud)
VALUES
('John Doe', '4532015112830366', false),
('Jane Smith', '5410000000000000', true),
('Brad Smith', '1234567891234567', true);
-- Create a role which will see masked data and grant it privileges
CREATE ROLE intern_user;
GRANT SELECT, DELETE ON public.credit_card_table TO intern_user;
-- Trigger which will silenty skip delete of non fraudelent credit cards
CREATE OR REPLACE FUNCTION prevent_non_fraud_delete()
RETURNS TRIGGER AS
$$
BEGIN
IF OLD.is_fraud = false THEN
RETURN NULL;
END IF;
RETURN OLD;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER prevent_non_fraud_delete
BEFORE DELETE ON credit_card_table
FOR EACH ROW
EXECUTE FUNCTION prevent_non_fraud_delete();
CREATE OR REPLACE FUNCTION public.return_false()
RETURNS BOOLEAN
LANGUAGE SQL
IMMUTABLE PARALLEL SAFE STRICT
BEGIN ATOMIC
SELECT false;
END;
-- A masking policy that masks both credit card number and is_fraud column.
-- If we apply masking inside trigger then prevent_non_fraud_delete trigger will
-- allow deleting more rows to masked user (even non fraud ones).
CALL pgcolumnmask.create_masking_policy(
'mask_credit_card_no_&_is_fraud'::NAME,
'public.credit_card_table'::REGCLASS,
JSON_BUILD_OBJECT('credit_card_no', 'pgcolumnmask.mask_text(credit_card_no)',
'is_fraud', 'public.return_false()')::JSONB,
ARRAY['intern_user']::NAME[],
10::INT
);
-- Test trigger behaviour using intern_user
BEGIN;
SET ROLE intern_user;
-- credit card number & is_fraud is completely masked from intern_user
SELECT * FROM public.credit_card_table;
name | credit_card_no | is_fraud
------------+------------------+----------
John Doe | XXXXXXXXXXXXXXXX | f
Jane Smith | XXXXXXXXXXXXXXXX | f
Brad Smith | XXXXXXXXXXXXXXXX | f
(3 rows)
-- The delete trigger lets the intern user delete rows for Jane and Brad even though
-- intern_user sees their is_fraud = false, but the table trigger works with original
-- unmasked value
DELETE FROM public.credit_card_table RETURNING *;
name | credit_card_no | is_fraud
------------+------------------+----------
Jane Smith | XXXXXXXXXXXXXXXX | f
Brad Smith | XXXXXXXXXXXXXXXX | f
(2 rows)
COMMIT;
```
Der Trigger-Ersteller gibt unmaskierte Daten an den Benutzer weiter, wenn er nicht vorsichtig mit den Anweisungen umgeht, die er in seinem Triggertext verwendet. Wenn Sie beispielsweise a verwenden, wird `RAISE NOTICE ‘%’, masked_column;` die Spalte an den aktuellen Benutzer ausgegeben.
```
-- Example showing table trigger leaking column value to current user
CREATE OR REPLACE FUNCTION leaky_trigger_func()
RETURNS TRIGGER AS
$$
BEGIN
RAISE NOTICE 'Old credit card number was: %', OLD.credit_card_no;
RAISE NOTICE 'New credit card number is %', NEW.credit_card_no;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER leaky_trigger
AFTER UPDATE ON public.credit_card_table
FOR EACH ROW
EXECUTE FUNCTION leaky_trigger_func();
-- Grant update on column is_fraud to auditor role
-- auditor will NOT HAVE PERMISSION TO READ DATA
CREATE ROLE auditor;
GRANT UPDATE (is_fraud) ON public.credit_card_table TO auditor;
-- Also add auditor role to existing masking policy on credit card table
CALL pgcolumnmask.alter_masking_policy(
'mask_credit_card_no_&_is_fraud'::NAME,
'public.credit_card_table'::REGCLASS,
NULL::JSONB,
ARRAY['intern_user', 'auditor']::NAME[],
NULL::INT
);
-- Log in as auditor
-- [auditor]
-- Update will fail if trying to read data from the table
UPDATE public.credit_card_table
SET is_fraud = true
WHERE credit_card_no = '4532015112830366';
ERROR: permission denied for table cc_table
-- [auditor]
-- But leaky update trigger will still print the entire row even though
-- current user does not have permission to select from public.credit_card_table
UPDATE public.credit_card_table SET is_fraud = true;
NOTICE: Old credit_card_no was: 4532015112830366
NOTICE: New credit_card_no is 4532015112830366
```
Wird bei Ansichten mit pg\$1columnmask ausgelöst (anstelle von Triggern)
Trigger können nur für Ansichten in PostgreSQL erstellt werden. Sie werden für die Ausführung von DML-Anweisungen in Ansichten verwendet, die nicht aktualisierbar sind. Transittabellen werden immer intern maskiert und nicht innerhalb von Triggern (IOT), da die in der View-Abfrage verwendete View und die Basistabellen unterschiedliche Besitzer haben können. In diesem Fall können für Basistabellen einige Maskierungsrichtlinien gelten, die für den Eigentümer der Ansicht gelten, und der Eigentümer der Ansicht muss in seinen Triggern immer maskierte Daten aus Basistabellen sehen. Dies unterscheidet sich von Triggern für Tabellen, da in diesem Fall der Trigger-Ersteller und die Daten in den Tabellen demselben Benutzer gehören, was hier nicht der Fall ist.
```
-- Create a view over credit card table
CREATE OR REPLACE VIEW public.credit_card_view
AS
SELECT * FROM public.credit_card_table;
-- Truncate credit card table and insert fresh data
TRUNCATE TABLE public.credit_card_table;
INSERT INTO public.credit_card_table (name, credit_card_no, is_fraud)
VALUES
('John Doe', '4532015112830366', false),
('Jane Smith', '5410000000000000', true),
('Brad Smith', '1234567891234567', true);
CREATE OR REPLACE FUNCTION public.print_changes()
RETURNS TRIGGER AS
$$
BEGIN
RAISE NOTICE 'Old row: name=%, credit card number=%, is fraud=%',
OLD.name, OLD.credit_card_no, OLD.is_fraud;
RAISE NOTICE 'New row: name=%, credit card number=%, is fraud=%',
NEW.name, NEW.credit_card_no, NEW.is_fraud;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER print_changes_trigger
INSTEAD OF UPDATE ON public.credit_card_view
FOR EACH ROW
EXECUTE FUNCTION public.print_changes();
GRANT SELECT, UPDATE ON public.credit_card_view TO auditor;
-- [auditor]
-- Login as auditor role
BEGIN;
-- Any data coming out from the table will be masked in instead of triggers
-- according to masking policies applicable to current user
UPDATE public.credit_card_view
SET name = CONCAT(name, '_new_name')
RETURNING *;
NOTICE: Old row: name=John Doe, credit card number=XXXXXXXXXXXXXXXX, is fraud=f
NOTICE: New row: name=John Doe_new_name, credit card number=XXXXXXXXXXXXXXXX, is fraud=f
NOTICE: Old row: name=Jane Smith, credit card number=XXXXXXXXXXXXXXXX, is fraud=f
NOTICE: New row: name=Jane Smith_new_name, credit card number=XXXXXXXXXXXXXXXX, is fraud=f
NOTICE: Old row: name=Brad Smith, credit card number=XXXXXXXXXXXXXXXX, is fraud=f
NOTICE: New row: name=Brad Smith_new_name, credit card number=XXXXXXXXXXXXXXXX, is fraud=f
name | credit_card_no | is_fraud
---------------------+------------------+----------
John Doe_new_name | XXXXXXXXXXXXXXXX | f
Jane Smith_new_name | XXXXXXXXXXXXXXXX | f
Brad Smith_new_name | XXXXXXXXXXXXXXXX | f
-- Any new data going into the table using INSERT or UPDATE command will be unmasked
UPDATE public.credit_card_view
SET credit_card_no = '9876987698769876'
RETURNING *;
NOTICE: Old row: name=John Doe, credit card number=XXXXXXXXXXXXXXXX, is fraud=f
NOTICE: New row: name=John Doe, credit card number=9876987698769876, is fraud=f
NOTICE: Old row: name=Jane Smith, credit card number=XXXXXXXXXXXXXXXX, is fraud=f
NOTICE: New row: name=Jane Smith, credit card number=9876987698769876, is fraud=f
NOTICE: Old row: name=Brad Smith, credit card number=XXXXXXXXXXXXXXXX, is fraud=f
NOTICE: New row: name=Brad Smith, credit card number=9876987698769876, is fraud=f
name | credit_card_no | is_fraud
------------+------------------+----------
John Doe | 9876987698769876 | f
Jane Smith | 9876987698769876 | f
Brad Smith | 9876987698769876 | f
COMMIT;
```
Datenbank-/Benutzerebene zur Steuerung des GuCs Triggerverhaltens
Zwei Konfigurationsparameter steuern das Trigger-Ausführungsverhalten für Benutzer mit entsprechenden Maskierungsrichtlinien. Verwenden Sie diese Parameter, um zu verhindern, dass Trigger in maskierten Tabellen oder Ansichten ausgeführt werden, wenn zusätzliche Sicherheitseinschränkungen erforderlich sind. Beide Parameter sind standardmäßig deaktiviert, sodass Trigger normal ausgeführt werden können.
**Erster GUC: Beschränkung der Triggerauslösung für maskierte Tabellen**
Spezifikationen:
+ Name: `pgcolumnmask.restrict_dml_triggers_for_masked_users`
+ Typ: `boolean`
+ Standard: `false` (Trigger dürfen ausgeführt werden)
Wenn dieser Wert auf TRUE gesetzt ist, wird die Ausführung von Triggern in maskierten Tabellen für maskierte Benutzer verhindert. `pg_columnmask`durchläuft den Fehler.
**Zweiter GUC: Einschränkung beim Auslösen von Triggern für Ansichten mit maskierten Tabellen**
Spezifikationen:
+ Name: `pgcolumnmask.restrict_iot_triggers_for_masked_users`
+ Typ: `boolean`
+ Standard: `false` (Trigger dürfen ausgeführt werden)
Wenn der Wert auf TRUE gesetzt ist, wird die Ausführung von Triggern in Ansichten verhindert, deren Definition maskierte Tabellen für maskierte Benutzer enthält.
Diese Parameter funktionieren unabhängig voneinander und sind wie standardmäßige Datenbankkonfigurationsparameter konfigurierbar.
# Aurora PostgreSQL pg\$1columnmask Datenverschiebungsszenarien
`pg_columnmask`Das 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.
**Topics**
+ [Aurora Global Database und Read Replicas](#AuroraPostgreSQL.Security.DynamicMasking.DataMovement.RR)
+ [Datenbankklon und Snapshot-Wiederherstellung](#AuroraPostgreSQL.Security.DynamicMasking.DataMovement.Clones)
+ [Logische Replikation](#AuroraPostgreSQL.Security.DynamicMasking.DataMovement.LogRep)
+ [Blau/Grün-Bereitstellungen](#AuroraPostgreSQL.Security.DynamicMasking.DataMovement.BlueGreen)
+ [Zero-ETL- und CDC-Streams](#AuroraPostgreSQL.Security.DynamicMasking.DataMovement.ZETL)
+ [AWS Database Migration Service](#AuroraPostgreSQL.Security.DynamicMasking.DataMovement.DMS)
+ [Datenexporte](#AuroraPostgreSQL.Security.DynamicMasking.DataMovement.DataExport)
+ [Ansichten und materialisierte Ansichten](#AuroraPostgreSQL.Security.DynamicMasking.DataMovement.Views)
+ [Daten speichern und wiederherstellen](#AuroraPostgreSQL.Security.DynamicMasking.DataMovement.DDR)
+ [Wrapper für ausländische Daten](#AuroraPostgreSQL.Security.DynamicMasking.DataMovement.FDQ)
## Aurora Global Database und Read Replicas
`pg_columnmask`Aurora-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_columnmask`Verwandte interne RLS-Richtlinien können zwar migriert werden, sie funktionieren jedoch nicht auf Zielen, die nicht pg\$1columnmask-fähig sind.
## Datenexporte
`pg_columnmask`behandelt 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 `INVOKER` Semantik. 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_dump`arbeitet 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_columnmask`Richtlinien 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_dump`Unterstü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\$1dump.](https://www.postgresql.org/docs/current/app-pgdump.html)
## 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.