Amazon Redshift unterstützt UDFs ab Patch 198 nicht mehr die Erstellung von neuem Python. Das bestehende Python UDFs wird bis zum 30. Juni 2026 weiterhin funktionieren. Weitere Informationen finden Sie im [Blog-Posting](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
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.
# Datenbanksicherheit
Sie verwalten die Datenbanksicherheit, indem Sie steuern, welche Benutzer auf welche Datenbankobjekte zugreifen dürfen. Benutzern können Rollen oder Gruppen zugewiesen werden und die Berechtigungen, die Sie Benutzern, Rollen oder Gruppen gewähren, entscheiden darüber, auf welche Datenbankobjekte sie zugreifen können.
**Topics**
+ [Übersicht zur Sicherheit in Amazon Redshift](c_security-overview.md)
+ [Standardberechtigungen für Datenbankbenutzer](r_Privileges.md)
+ [superuser](r_superusers.md)
+ [Benutzer](r_Users.md)
+ [Gruppen](r_Groups.md)
+ [Schemata](r_Schemas_and_tables.md)
+ [Rollenbasierte Zugriffskontrolle (RBAC)](t_Roles.md)
+ [Sicherheit auf Zeilenebene](t_rls.md)
+ [Sicherheit von Metadaten](t_metadata_security.md)
+ [Dynamische Datenmaskierung](t_ddm.md)
+ [Bereichsbeschränkte Berechtigungen](t_scoped-permissions.md)
Der Zugriff auf Datenbankobjekte hängt von den Berechtigungen ab, die Sie Benutzern oder Rollen gewähren. Die folgenden Leitlinien den fassen zusammen, wie Datenbanksicherheit funktioniert:
+ Standardmäßig erhält nur der Besitzer eines Objekts Zugriffsberechtigungen.
+ Amazon-Redshift-Datenbankbenutzer sind benannte Benutzer, die eine Verbindung zu der Datenbank herstellen können. Benutzern können Zugriffsberechtigungen gewährt werden. Dies kann explizit erfolgen, indem die betreffenden Berechtigungen dem Benutzerkonto direkt gewährt werden, oder implizit, indem die betreffenden Berechtigungen einer Gruppe gewährt werden, der das Benutzerkonto angehört.
+ Eine Gruppe ist eine Menge von Benutzerkonten, denen zusammen Berechtigungen zugewiesen werden können, um so die Sicherheitswartung zu optimieren.
+ Schemata sind Mengen von Datenbanktabellen und anderen Datenbankobjekten. Schemata sind mit Verzeichnissen eines Dateisystems vergleichbar, sie ermöglichen jedoch keine Verschachtelung. Benutzern kann der Zugriff auf ein einzelnes Schema oder auf mehrere Schemata gewährt werden.
Darüber hinaus verwendet Amazon Redshift die folgenden Funktionen, um Ihnen eine genauere Kontrolle darüber zu ermöglichen, welche Benutzer auf die jeweiligen Datenbankobjekte zugreifen können:
+ Mit der rollenbasierten Zugriffskontrolle (RBAC) können Sie Rollen Berechtigungen zuweisen und dann auf Benutzer anwenden, sodass Sie die Berechtigungen für große Benutzergruppen kontrollieren können. Im Gegensatz zu Gruppen können Rollen Berechtigungen von anderen Rollen übernehmen.
Mit der Sicherheit auf Zeilenebene (RLS) können Sie Richtlinien definieren, die den Zugriff auf Zeilen Ihrer Wahl einschränken, und diese Richtlinien dann auf Benutzer oder Gruppen anwenden.
Die dynamische Datenmaskierung (DDM) schützt Ihre Daten zusätzlich, indem diese während der Abfragelaufzeit transformiert werden, sodass Sie Benutzern Zugriff auf Daten gewähren können, ohne vertrauliche Informationen offenzulegen.
Beispiele von Sicherheitsimplementierungen finden Sie unter [Beispiel zur Steuerung des Zugriffs durch Benutzer und Gruppen](t_user_group_examples.md).
Weitere Informationen zum Schutz Ihrer Daten finden Sie unter [Sicherheit in Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/iam-redshift-user-mgmt.html) im *Amazon-Redshift-Verwaltungshandbuch*.
# Übersicht zur Sicherheit in Amazon Redshift
Die Datenbanksicherheit in Amazon Redshift unterscheidet sich von anderen Sicherheitsfunktionen in Amazon Redshift. Neben der Datenbanksicherheit, die in diesem Abschnitt ausführlich beschrieben wird, bietet Amazon Redshift die folgenden Funktionen zur Verwaltung der Sicherheit:
+ **Anmeldeinformationen** — Der Zugriff auf Ihre Amazon Redshift AWS Management Console wird durch Ihre AWS Kontoberechtigungen gesteuert. Weitere Informationen finden Sie unter [Anmeldeinformationen](https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html).
+ **Zugriffsverwaltung** — Um den Zugriff auf bestimmte Amazon Redshift Redshift-Ressourcen zu kontrollieren, definieren Sie AWS Identity and Access Management (IAM-) Konten. Weitere Informationen finden Sie unter [Steuern des Zugriffs auf Amazon-Redshift-Ressourcen](https://docs.aws.amazon.com/redshift/latest/mgmt/iam-redshift-user-mgmt.html).
+ **Clustersicherheitsgruppen** – Um anderen Benutzern den eingehenden Zugriff auf einen Amazon-Redshift-Cluster zu gewähren, definieren Sie eine Clustersicherheitsgruppe und verknüpfen sie mit einem Cluster. Weitere Informationen finden Sie unter [Amazon-Redshift-Cluster-Sicherheitsgruppen](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-security-groups.html).
+ **VPC** – Sie können den Zugriff auf Ihren Cluster unter Verwendung einer virtuellen Netzwerkumgebung steuern, wenn Sie Ihren Cluster in einer Amazon Virtual Private Cloud (VPC) starten. Weitere Informationen finden Sie unter [Verwalten von Clustern in einer Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-clusters-vpc.html).
+ **Clusterverschlüsselung** – Sie können die Daten in allen von Benutzern erstellten Tabellen verschlüsseln, indem Sie beim Starten des Clusters die Clusterverschlüsselung aktivieren. Weitere Informationen finden Sie unter [Amazon-Redshift-Cluster](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html).
+ **SSL-Verbindungen** – Sie können Sie eine SSL-Verschlüsselung (Secure Sockets Layer) verwenden, wenn Sie die Verbindung zwischen Ihrem SQL-Client und Ihrem Cluster verschlüsseln möchten. Weitere Informationen finden Sie unter [Verbinden mit Ihrem Cluster über SSL](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-ssl-support.html).
+ **Ladedatenverschlüsselung** – Sie können die Dateien mit den Tabellenladedaten beim Hochladen zu Amazon S3 serverseitig oder clientseitig verschlüsseln. Wenn Sie serverseitig verschlüsselte Daten laden, führt Amazon S3 die Entschlüsselung transparent durch. Wenn Sie clientseitig verschlüsselte Daten laden, werden die Daten beim Laden der Tabelle mit dem Amazon-Redshift-Befehl COPY entschlüsselt. Weitere Informationen finden Sie unter [Hochladen verschlüsselter Daten in Amazon S3](t_uploading-encrypted-data.md).
+ **Daten während der Übertragung** — Um Ihre Daten bei der Übertragung innerhalb der AWS Cloud zu schützen, verwendet Amazon Redshift hardwarebeschleunigtes SSL für die Kommunikation mit Amazon S3 oder Amazon DynamoDB für KOPIER-, ENTLADEN-, Sicherungs- und Wiederherstellungsvorgänge.
+ **Zugriffssteuerung auf Spaltenebene** – Um die Zugriffssteuerung auf Spaltenebene für Daten in Amazon Redshift zu nutzen, verwenden Sie Gewähren- und Widerrufen-Anweisungen auf Spaltenebene, ohne ansichtsbasierte Zugriffssteuerung implementieren oder ein anderes System verwenden zu müssen.
+ **Sicherheitskontrolle auf Zeilenebene** – Um die Sicherheit von Daten in Amazon Redshift auf Zeilenebene zu kontrollieren, müssen Sie Richtlinien erstellen und Rollen oder Benutzern zuordnen, die den Zugriff auf die in der Richtlinie definierten Zeilen einschränken.
# Standardberechtigungen für Datenbankbenutzer
Wenn Sie ein Datenbankobjekt erstellen, sind Sie dessen Besitzer. Standardmäßig sind nur Superuser und der Besitzer eines Objekts berechtigt, Abfragen für dieses Objekt durchzuführen, es zu bearbeiten oder Berechtigungen dafür zu erteilen. Wenn Sie möchten, dass ein Benutzer ein Objekt verwenden darf, müssen Sie dem Benutzer (bzw. einer Gruppe, der der Benutzer angehört) die benötigten Berechtigungen erteilen. Datenbank-Superuser haben dieselben Berechtigungen wie die Besitzer von Datenbanken.
Amazon Redshift unterstützt die folgenden Berechtigungen: SELECT, INSERT, UPDATE, DELETE, REFERENCES, CREATE, TEMPORARY und USAGE. Für die verschiedenen Objekttypen kommen jeweils bestimmte Berechtigungen in Frage. Weitere Informationen zu den Berechtigungen für von Amazon Redshift unterstützte Datenbankobjekte finden Sie unter dem Befehl [GRANT](r_GRANT.md).
Nur der Eigentümer hat die Berechtigung zum Ändern oder Löschen eines Objekts.
Standardmäßig besitzen alle Benutzer CREATE- und USAGE-Berechtigungen für das Schema PUBLIC einer Datenbank. Um Benutzer daran zu hindern, Objekte im Schema PUBLIC einer Datenbank zu erstellen, verwenden Sie den Befehl REVOKE, um diese Berechtigung zu entfernen.
Um erteilte Berechtigungen zu widerrufen, verwenden Sie den Befehl [REVOKE](r_REVOKE.md). Die Berechtigungen des Besitzers des Objekts (wie DROP, GRANT und REVOKE) sind implizit und können nicht direkt erteilt oder widerrufen werden. Die Besitzer von Objekten können auch ihre eigenen Berechtigungen zurückziehen. Dies kann beispielsweise nützlich sein, um eine Tabelle für alle Benutzer (sich selbst eingeschlossen) vor Änderungen zu schützen, indem sie schreibgeschützt gemacht wird. Superuser behalten unabhängig von GRANT- und REVOKE-Befehlen stets alle Berechtigungen.
# Superuser
Datenbank-Superuser haben für alle Datenbanken dieselben Berechtigungen wie die Besitzer von Datenbanken.
Der *Admin*-Benutzer ist der Benutzer, den Sie beim Starten des Clusters erstellt haben, und wird als Superuser bezeichnet.
Sie müssen Superuser sein, um einen anderen Superuser zu erstellen.
Amazon-Redshift-Systemtabellen und Systemsichten sind entweder nur für Superuser sichtbar oder aber für alle Benutzer. Nur Superuser haben die Berechtigung, Abfragen über Systemtabellen und Systemsichten durchzuführen, die als „nur für Superuser sichtbar“ festgelegt sind. Weitere Informationen finden Sie unter [SYS-Überwachungsansichten](serverless_views-monitoring.md).
Superuser können alle Katalogtabellen anzeigen. Weitere Informationen finden Sie unter [Systemkatalogtabellen](c_intro_catalog_views.md).
Datenbank-Superuser umgehen alle Überprüfungen von Berechtigungen. Superuser behalten unabhängig von GRANT- und REVOKE-Befehlen stets alle Berechtigungen. Als Superuser sollten Sie vorsichtig vorgehen. Wir empfehlen, allgemeine Aufgaben unter Verwendung eines anderen Benutzerkontos und nicht als Superuser durchzuführen. Sie können eine Administratorrolle mit restriktiveren Berechtigungen erstellen. Weitere Informationen zum Erstellen von Rollen finden Sie unter [Rollenbasierte Zugriffskontrolle (RBAC)](t_Roles.md).
Um einen neuen Datenbank-Superuser zu erstellen, melden Sie sich an der Datenbank als ein Superuser an, führen den Befehl CREATE USER oder den Befehl ALTER USER mit der Berechtigung CREATEUSER aus.
```
CREATE USER adminuser CREATEUSER PASSWORD '1234Admin';
ALTER USER adminuser CREATEUSER;
```
Um einen Superuser zu erstellen, zu ändern oder zu löschen, verwenden Sie dieselben Befehle wie zur Verwaltung der Benutzer. Weitere Informationen finden Sie unter [Erstellen, Modifizieren und Löschen von Benutzern](r_Users-creatingaltering-and-deleting-users.md).
# Benutzer
Sie können Datenbankbenutzer mit den Amazon Redshift-SQL-Befehlen CREATE USER und ALTER USER erstellen und verwalten. Oder Sie können Ihren SQL-Client mit benutzerdefinierten Amazon-Redshift-JDBC- oder -ODBC-Treibern konfigurieren. Diese Treiber verwalten die Erstellung von Datenbankbenutzern und temporären Passwörtern als Teil der Datenbankanmeldung.
Die Treiber authentifizieren Datenbankbenutzer auf der Grundlage der (IAM AWS Identity and Access Management -) Authentifizierung. Wenn Sie Benutzeridentitäten bereits außerhalb von verwalten AWS, können Sie einen SAML 2.0-kompatiblen Identitätsanbieter (IdP) verwenden, um den Zugriff auf Amazon Redshift Redshift-Ressourcen zu verwalten. Sie verwenden eine IAM-Rolle, um Ihren IdP zu konfigurieren und Ihren Verbundbenutzern AWS zu ermöglichen, temporäre Datenbankanmeldedaten zu generieren und sich Amazon Redshift Redshift-Datenbanken anzumelden. Weitere Informationen finden Sie unter [Verwenden der IAM-Authentifizierung zur Erstellung von Benutzeranmeldeinformationen für die Datenbank](https://docs.aws.amazon.com/redshift/latest/mgmt/generating-user-credentials.html).
Amazon-Redshift-Benutzer können ausschließlich von Datenbank-Superusern erstellt und gelöscht werden. Benutzer werden bei der Amazon-Redshift-Anmeldung authentifiziert. Sie können Datenbanken und Datenbankobjekte (beispielsweise Tabellen) besitzen. Außerdem können sie für diese Objekte Benutzern, Gruppen und Schemata Berechtigungen erteilen, um zu steuern, wer auf welches Objekt zugreifen darf. Benutzer mit CREATE DATABASE-Rechten dürfen Datenbanken erstellen und können für diese Datenbanken Berechtigungen erteilen. Superuser haben für alle Datenbanken dieselben Berechtigungen wie deren Besitzer.
# Erstellen, Modifizieren und Löschen von Benutzern
Datenbankbenutzer gelten global im gesamten Data-Warehouse-Cluster (und nicht nur für einzelne Datenbanken).
+ Verwenden Sie den Befehl [CREATE USER](r_CREATE_USER.md), um einen neuen Benutzer zu erstellen.
+ Verwenden Sie den Befehl [CREATE USER](r_CREATE_USER.md) mit der Option CREATEUSER, um einen Superuser zu erstellen.
+ Mit dem Befehl [DROP USER](r_DROP_USER.md) können Sie einen bestehenden Benutzer entfernen.
+ Verwenden Sie den Befehl [ALTER USER](r_ALTER_USER.md), um einen Benutzer zu ändern und zum Beispiel ein neues Passwort festzulegen.
+ Führen Sie eine Abfrage wie folgt über der Katalogtabelle PG\$1USER aus, um eine Liste aller Benutzer anzuzeigen.
```
select * from pg_user;
usename | usesysid | usecreatedb | usesuper | usecatupd | passwd | valuntil | useconfig
------------+----------+-------------+----------+-----------+----------+----------+-----------
rdsdb | 1 | t | t | t | ******** | |
masteruser | 100 | t | t | f | ******** | |
dwuser | 101 | f | f | f | ******** | |
simpleuser | 102 | f | f | f | ******** | |
poweruser | 103 | f | t | f | ******** | |
dbuser | 104 | t | f | f | ******** | |
(6 rows)
```
# Gruppen
Gruppen sind eine Menge von Benutzern, die alle die Berechtigungen erhalten, die der Gruppe zugewiesen sind. Sie können Gruppen dazu verwenden, Berechtigungen zuzuweisen. Sie können beispielsweise verschiedene Gruppen für Vertrieb, Verwaltung und Support erstellen, und den Benutzern in diesen Gruppen den jeweils für ihre Aufgaben benötigten Datenzugriff erlauben. Sie können dann Berechtigungen auf der Ebene von Gruppen erteilen und zurücknehmen, und diese Änderungen gelten dann für alle Benutzer der Gruppe, mit Ausnahme der Superuser.
Führen Sie eine Abfrage wie folgt über der Systemkatalogtabelle PG\$1GROUP aus, um eine Liste aller Benutzergruppen anzuzeigen:
```
select * from pg_group;
```
Wenn Sie beispielsweise alle Datenbankbenutzer nach Gruppen auflisten möchten, führen Sie den folgenden SQL-Befehl aus.
```
SELECT u.usesysid
,g.groname
,u.usename
FROM pg_user u
LEFT JOIN pg_group g ON u.usesysid = ANY (g.grolist)
```
# Erstellen, Modifizieren und Löschen von Gruppen
Nur Superuser können Gruppen erstellen, ändern oder löschen.
Sie können folgende Aktionen ausführen:
+ Verwenden Sie den Befehl [CREATE GROUP](r_CREATE_GROUP.md), um eine neue Gruppe zu erstellen.
+ Mit dem Befehl [ALTER GROUP](r_ALTER_GROUP.md) können Sie einer bestehenden Gruppe Benutzer hinzufügen oder Benutzer aus der Gruppe entfernen.
+ Verwenden Sie den Befehl [DROP GROUP](r_DROP_GROUP.md), um eine Gruppe zu löschen. Mit diesem Befehl wird nur die Gruppe gelöscht, die Benutzer, die der Gruppe angehören, werden selbst nicht gelöscht.
# Beispiel zur Steuerung des Zugriffs durch Benutzer und Gruppen
In diesem Beispiel werden Benutzergruppen und Benutzer erstellt und anschließend werden ihnen verschiedene Berechtigungen für eine Amazon-Redshift-Datenbank erteilt, die sich mit einem Webanwendungsclient verbindet. In diesem Beispiel werden drei Gruppen von Benutzern zugrundegelegt: normale Benutzer der Webanwendung, Hauptbenutzer der Webanwendung und Webentwickler.
Weitere Informationen zum Entfernen eines Benutzers aus einer Gruppe finden Sie unter [ALTER GROUP](r_ALTER_GROUP.md).
1. Es werden die Gruppen erstellt, denen die verschiedenen Benutzer zugewiesen werden. Mit den folgenden Befehlen werden drei verschiedene Benutzergruppen erstellt:
```
create group webappusers;
create group webpowerusers;
create group webdevusers;
```
1. Es werden mehrere Datenbankbenutzer mit unterschiedlichen Berechtigungen erstellt und anschließend den Gruppen hinzugefügt.
1. Es werden zwei Benutzer erstellt und der Gruppe WEBAPPUSERS hinzugefügt:
```
create user webappuser1 password 'webAppuser1pass'
in group webappusers;
create user webappuser2 password 'webAppuser2pass'
in group webappusers;
```
1. Es wird ein Konto für einen Webentwickler erstellt und der Gruppe WEBDEVUSERS hinzugefügt:
```
create user webdevuser1 password 'webDevuser2pass'
in group webdevusers;
```
1. Erstellen Sie einen Superuser. Dieser Benutzer hat die Berechtigung, andere Benutzer zu erstellen:
```
create user webappadmin password 'webAppadminpass1'
createuser;
```
1. Es wird ein Schema erstellt, das mit den von der Webanwendung verwendeten Datenbanktabellen verknüpft wird. Anschließend wird den verschiedenen Benutzergruppen Zugriff auf dieses Schema gewährt:
1. Das WEBAPP-Schema wird erstellt:
```
create schema webapp;
```
1. Der Gruppe WEBAPPUSERS wird die USAGE-Berechtigung gewährt:
```
grant usage on schema webapp to group webappusers;
```
1. Der Gruppe WEBPOWERUSERS wird die USAGE-Berechtigung gewährt:
```
grant usage on schema webapp to group webpowerusers;
```
1. Der Gruppe WEBDEVUSERS wird die ALL-Berechtigung gewährt:
```
grant all on schema webapp to group webdevusers;
```
Nun sind die benötigten Benutzer und Gruppen eingerichtet. Sie können die Benutzer und Gruppen jetzt ändern.
1. Der folgende Befehl ändert beispielsweise den Parameter search\$1path für. WEBAPPUSER1
```
alter user webappuser1 set search_path to webapp, public;
```
Über SEARCH\$1PATH wird festgelegt, in welcher Reihenfolge die Schemata nach Datenbankobjekten wie Tabellen und Funktionen durchsucht werden, wenn ein Objekt nur über seinen einfachen Namen (ohne Angabe des Schemas) referenziert wird.
1. Sie können einer Gruppe auch Benutzer hinzufügen, nachdem Sie die Gruppe erstellt haben, z. B. indem Sie sie der Gruppe WEBAPPUSER2 WEBPOWERUSERS hinzufügen:
```
alter group webpowerusers add user webappuser2;
```
# Schemata
Eine Datenbank enthält einen oder mehrere benannte Schemata. Jedes Schema in einer Datenbank enthält Tabellen und andere Arten von benannten Objekten. Standardmäßig haben alle Datenbanken ein einziges Schema, mit dem Namen PUBLIC. Sie können Schemata verwenden, um Datenbankobjekte unter einem gemeinsamen Namen zusammenzufassen. Schemata sind mit Verzeichnissen eines Dateisystems vergleichbar, sie ermöglichen jedoch keine Verschachtelung.
Wenn Sie in einer Datenbank mehrere Schemata haben, können in den verschiedenen Schemas ansonsten identische Datenbankenobjekte mit demselben Namen verwendet werden, ohne dass dies zu einem Namenskonflikt führt. Es können beispielsweise das Schema MY\$1SCHEMA und das Schema YOUR\$1SCHEMA beide eine Tabelle mit dem Namen MYTABLE enthalten. Wenn Benutzer über geeignete Berechtigungen verfügen, können sie auf Objekte in verschiedenen Schemas in der Datenbank zugreifen.
Standardmäßig werden neu erstellte Objekte in dem ersten Schema im Suchpfad der Datenbank erstellt. Weitere Informationen finden Sie unter [Suchpfad](#c_Search_path) weiter oben in diesem Abschnitt.
Schemata können wie folgt dazu beitragen, in einer Mehrfachbenutzerumgebung Probleme in Zusammenhang mit der Strukturierung und der Ausführung paralleler Anweisungen zu vermeiden:
+ Schemata ermöglichen eine Zusammenarbeit von Entwicklern an derselben Datenbank, ohne dass Namenskonflikte auftreten.
+ Sie ermöglichen die Zusammenfassung von Datenbankobjekten zu logischen Einheiten, die besser verwaltet werden können.
+ Sie ermöglichen es Anwendungen, ihre Objekte in separaten Schemata abzulegen, ohne dass deren Namen zu einem Konflikt mit Objekten von anderen Anwendungen führen.
## Suchpfad
Der Suchpfad wird im Parameter „search\$1path“ als kommagetrennte Liste von Schemanamen definiert. Über den Suchpfad wird festgelegt, in welcher Reihenfolge die Schemas durchsucht werden, wenn ein Objekt, beispielsweise eine Tabelle oder eine Funktion, mit dem einfachen Namen (also ohne Kennzeichnung des Schemas) referenziert wird.
Wenn ein Objekt ohne Angabe eines Zielschemas erstellt wird, wird das Objekt in dem ersten Schema in dem Suchpfad angelegt. Wenn in verschiedenen Schemata Objekte mit demselben Namen vorhanden sind, werden Objektaufrufe ohne Schemaangabe als Verweis auf das erste Schema in dem Suchpfad interpretiert, das ein Objekt mit dem angegebenen Namen enthält.
Um das Standardschema für die aktuelle Sitzung zu ändern, führen Sie den Befehl [SET](r_SET.md) aus.
Weitere Informationen finden Sie in der [search\$1path](r_search_path.md)-Beschreibung in der Konfigurationsreferenz.
# Erstellen, Modifizieren und Löschen von Schemata
Alle Benutzer können Schemata erstellen und eigene Schemata ändern und löschen.
Sie können folgende Aktionen ausführen:
+ Verwenden Sie den Befehl [CREATE SCHEMA](r_CREATE_SCHEMA.md), um ein neues Schema zu erstellen.
+ Mit dem Befehl [ALTER SCHEMA](r_ALTER_SCHEMA.md) können Sie den Besitzer eines Schemas ändern.
+ Um ein Schema und alle enthaltenen Objekte zu löschen, führen Sie den Befehl [DROP SCHEMA](r_DROP_SCHEMA.md) aus.
+ Um eine Tabelle in einem Schema zu erstellen, verwenden Sie bei der Erstellung der Tabelle die Syntax *schema\$1name.tabellen\$1name*.
Führen Sie eine Abfrage wie folgt über der Katalogtabelle PG\$1NAMESPACE aus, um eine Liste aller Schemata anzuzeigen:
```
select * from pg_namespace;
```
Führen Sie eine Abfrage über der Katalogtabelle PG\$1TABLE\$1DEF aus, um eine Liste aller Tabellen in einem Schema anzuzeigen. Beispiel: Die folgende Abfrage gibt eine Liste der Tabellen im Schema PG\$1CATALOG zurück.
```
select distinct(tablename) from pg_table_def
where schemaname = 'pg_catalog';
```
# Schemabasierte Berechtigungen
Schemabasierte Berechtigungen werden vom Besitzer des Schemas festgelegt:
+ Standardmäßig besitzen alle Benutzer CREATE- und USAGE-Berechtigungen für das Schema PUBLIC einer Datenbank. Um Benutzer daran zu hindern, Objekte im Schema PUBLIC einer Datenbank zu erstellen, verwenden Sie den Befehl [REVOKE](r_REVOKE.md), um diese Berechtigung zu entfernen.
+ Benutzer können auf Objekte in Schemas, die sie nicht besitzen, nur dann zugreifen, wenn der Besitzer des jeweiligen Objekts ihnen die USAGE-Berechtigung erteilt hat.
+ Wenn Benutzern die CREATE-Berechtigung für ein Schema erteilt wird, das von einem anderen Benutzer erstellt wurde, sind diese Benutzer berechtigt, Objekte in diesem Schema zu erstellen.
# Rollenbasierte Zugriffskontrolle (RBAC)
Durch die Verwendung der rollenbasierten Zugriffssteuerung (RBAC) zum Verwalten von Datenbankberechtigungen in Amazon Redshift können Sie die Verwaltung von Sicherheitsberechtigungen in Amazon Redshift vereinfachen. Sie können den Zugriff auf sensible Daten sichern, indem Sie steuern, welche Aktionen Benutzer auf einer breit gefassten oder differenzierten Ebene ausführen können. Sie können auch den Benutzerzugriff auf Aufgaben steuern, die normalerweise auf Superuser beschränkt sind. Indem Sie verschiedenen Rollen unterschiedliche Berechtigungen zuweisen und sie verschiedenen Benutzern zuweisen, haben Sie eine genauere Kontrolle über den Benutzerzugriff.
Benutzer mit einer zugewiesenen Rolle können nur die Aufgaben ausführen, für die sie durch die ihnen zugewiesene Rolle autorisiert sind. Beispielsweise ist ein Benutzer, dem die Rolle mit den Berechtigungen CREATE TABLE und DROP TABLE zugewiesen ist, nur berechtigt, diese Aufgaben auszuführen. Sie können den Zugriff von Benutzern steuern, indem Sie verschiedenen Benutzern unterschiedliche Sicherheitsberechtigungen für den Zugriff auf Daten erteilen, die sie für ihre Arbeit benötigen.
RBAC wendet das Prinzip der geringsten Berechtigungen auf Benutzer basierend auf ihren Rollenanforderungen an, unabhängig von den beteiligten Objekttypen. Das Erteilen und Widerrufen von Berechtigungen erfolgt auf Rollenebene, ohne dass Berechtigungen für einzelne Datenbankobjekte aktualisiert werden müssen.
Mit RBAC können Sie Rollen mit Berechtigungen zum Ausführen von Befehlen erstellen, für die früher Superuser-Berechtigungen erforderlich waren. Benutzer können diese Befehle ausführen, sofern ihnen die Rolle zugewiesen wurde, die diese Berechtigungen enthält. Auf ähnliche Weise können Sie auch Rollen erstellen, um den Zugriff auf bestimmte Befehle zu beschränken, und die Rolle entweder Superusern oder Benutzern zuzuweisen, die mit der Rolle entsprechend autorisiert wurden.
Weitere Informationen zur Funktionsweise von Amazon Redshift RBAC finden Sie im folgenden Video.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/IhHQ7mZ-tp4)
# Rollenhierarchie
*Rollen* sind Sammlungen von Berechtigungen, die Sie einem Benutzer oder einer anderen Rolle zuweisen können. Sie können einer Rolle System- oder Datenbankberechtigungen zuweisen. Ein Benutzer erbt Berechtigungen von einer ihm zugewiesenen Rolle.
In RBAC können Benutzer verschachtelte Rollen haben. Sie können Rollen sowohl Benutzern als auch Rollen zuweisen. Wenn Sie einem Benutzer eine Rolle zuweisen, erteilen Sie dem Benutzer damit alle Berechtigungen, die diese Rolle beinhaltet. Wenn Sie einem Benutzer eine Rolle r1 gewähren, autorisieren Sie den Benutzer mit den Berechtigungen von r1. Der Benutzer hat jetzt Berechtigungen von r1 und auch alle vorhandenen Berechtigungen, die er bereits besitzt.
Wenn Sie eine Rolle (r1) einer anderen Rolle (r2) zuweisen, erteilen Sie r2 alle Berechtigungen von r1. Wenn Sie r2 für eine andere Rolle (r3) gewähren, sind die Berechtigungen von r3 die Vereinigung der Berechtigungen von r1 und r2. In der Rollenhierarchie erbt r2 die Berechtigungen von r1. Amazon Redshift propagiert Berechtigungen mit jeder Rollenautorisierung. Die Gewährung von r1 bis r2 und dann r2 bis r3 autorisiert r3 mit allen Berechtigungen der drei Rollen. Durch die Gewährung von r3 an einen Benutzer verfügt der Benutzer über alle Berechtigungen aus den drei Rollen.
Amazon Redshift lässt die Erstellung eines Rollenautorisierungszyklus nicht zu. Ein Rollenautorisierungszyklus findet statt, wenn eine verschachtelte Rolle wieder einer vorherigen Rolle in der Rollenhierarchie zugewiesen wird, z. B. wenn r3 wieder r1 zugewiesen wird. Weitere Informationen zum Erstellen von Rollen und Verwalten von Rollenzuweisungen finden Sie unter [Verwalten von Rollen in RBAC](r_roles-managing.md).
# Rollenzuweisung
Superuser und normale Benutzer mit der CREATE ROLE-Berechtigung können die CREATE ROLE-Anweisung verwenden, um Rollen zu erstellen. Superuser und Rollenadministratoren können die GRANT ROLE-Anweisung verwenden, um anderen eine Rolle zu gewähren. Sie können die REVOKE ROLE-Anweisung verwenden, um eine Rolle von anderen zu widerrufen, und die DROP ROLE-Anweisung, um Rollen zu löschen. Zu den Rollenadministratoren gehören Rollenbesitzer und Benutzer, denen die Rolle mit der Berechtigung ADMIN OPTION erteilt wurde.
Nur Superuser oder Rollenadministratoren können Rollen gewähren und widerrufen. Sie können eine oder mehrere Rollen einer oder mehreren Rollen oder Benutzern zuweisen oder die Zuweisung widerrufen. Verwenden Sie die Option WITH ADMIN OPTION in der GRANT ROLE-Anweisung, um allen Berechtigungsempfänger die Verwaltungsoptionen für alle gewährten Rollen bereitzustellen.
Amazon Redshift unterstützt verschiedene Kombinationen von Rollenzuweisungen, z. B. die Gewährung mehrerer Rollen oder das Zuweisen von Rollen zu mehreren Berechtigungsempfängern. WITH ADMIN OPTION gilt nur für Benutzer und nicht für Rollen. Verwenden Sie auf ähnliche Weise die Option WITH ADMIN OPTION in der REVOKE ROLE-Anweisung, um die Rolle und die Verwaltungsautorisierung des Berechtigungsempfängers zu widerrufen. Bei Verwendung mit der ADMIN OPTION wird nur die Verwaltungsautorisierung von der Rolle widerrufen.
Das folgende Beispiel widerruft die Verwaltungsautorisierung der Rolle `sample_role2` von `user2`.
```
REVOKE ADMIN OPTION FOR sample_role2 FROM user2;
```
Weitere Informationen zum Erstellen von Rollen und Verwalten von Rollenzuweisungen finden Sie unter [Verwalten von Rollen in RBAC](r_roles-managing.md).
# Systemdefinierte Amazon-Redshift-Rollen
Amazon Redshift bietet einige systemdefinierte Rollen, die mit bestimmten Berechtigungen definiert sind. Systemspezifische Rollen beginnen mit einem `sys:`-Präfix. Nur Benutzer mit entsprechendem Zugriff können systemdefinierte Rollen ändern oder benutzerdefinierte systemdefinierte Rollen erstellen. Sie können das `sys:`-Präfix nicht für eine benutzerdefinierte systemdefinierte Rolle verwenden.
In der folgenden Tabelle finden Sie eine Zusammenfassung der Rollen und deren Berechtigungen.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/r_roles-default.html)
## Systemdefinierte Rollen und Benutzer für die gemeinsame Nutzung von Daten
Amazon Redshift erstellt Rollen und Benutzer für den internen Gebrauch, die Datashares und Datashare-Verbrauchern entsprechen. Jeder interne Rollenname und Benutzername hat das reservierte Namespace-Präfix `ds:`. Diese haben das folgende Format:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/r_roles-default.html)
Für jeden Datashare wird eine Rolle für die gemeinsame Nutzung von Daten erstellt. Diese enthält alle Berechtigungen, die dem Datashare derzeit gewährt werden. Für jeden Datashare-Verbraucher wird ein Benutzer für die gemeinsame Nutzung von Daten erstellt. Diesem wird die Berechtigung für eine einzelne Rolle für die gemeinsame Nutzung von Daten erteilt. Für einen Benutzer, der mehreren Datashares hinzugefügt wird, wird für jeden Datashare ein Benutzer für die gemeinsame Nutzung von Daten erstellt.
Diese Benutzer und Rollen sind erforderlich, damit die gemeinsame Nutzung von Daten ordnungsgemäß funktioniert. Sie können nicht geändert oder gelöscht und nicht aufgerufen oder für Aufgaben verwendet werden, die von Kunden ausgeführt werden. Sie können diese ignorieren. Weitere Informationen finden Sie unter [Gemeinsame Nutzung von Daten über Cluster hinweg in Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/datashare-overview.html).
**Anmerkung**
Sie können das `ds:`-Präfix nicht verwenden, um benutzerdefinierte Rollen oder Benutzer zu erstellen.
# Systemberechtigungen für RBAC
Im Folgenden finden Sie eine Liste der Systemberechtigungen, die Sie einer Rolle gewähren oder entziehen können.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/r_roles-system-privileges.html)
# Datenbankobjektberechtigungen
Neben Systemberechtigungen enthält Amazon Redshift Datenbankobjektberechtigungen, die Zugriffsoptionen definieren. Hierzu gehören Optionen wie das Lesen von Daten in Tabellen und Ansichten, das Schreiben von Daten und das Erstellen und Entfernen von Tabellen. Weitere Informationen finden Sie unter [GRANT](r_GRANT.md).
Mithilfe von RBAC können Sie Rollen Datenbankobjektberechtigungen zuweisen, ähnlich wie das bei Systemberechtigungen möglich ist. Anschließend können Sie Benutzern Rollen zuweisen, Benutzer mit Systemberechtigungen autorisieren und Benutzer mit Datenbankberechtigungen autorisieren.
# ALTER DEFAULT PRIVILEGES für RBAC
Sie können die Anweisung ALTER DEFAULT PRIVILEGES verwenden, um den Standardsatz von Zugriffrechten zu definieren, die auf Objekte angewendet werden sollen, die vom angegebenen Benutzer in der Zukunft erstellt werden. Standardmäßig können Benutzer nur ihre eigenen Standardzugriffsrechte ändern. Mit RBAC können Sie die Standardzugriffsberechtigungen für Rollen festlegen. Weitere Informationen finden Sie unter [ALTER DEFAULT PRIVILEGES](r_ALTER_DEFAULT_PRIVILEGES.md)-Befehl.
Mithilfe von RBAC können Sie Rollen Datenbankobjektberechtigungen zuweisen, ähnlich wie das bei Systemberechtigungen möglich ist. Anschließend können Sie Benutzern Rollen zuweisen und Benutzer mit Systemberechtigungen und/oder Datenbankberechtigungen autorisieren.
# Überlegungen zur Rollennutzung in RBAC
Bei der Arbeit mit RBAC-Rollen sollten Sie Folgendes berücksichtigen:
+ Amazon Redshift lässt keine Zyklen von Rollenberechtigungen zu. Sie können nicht r1 für r2 gewähren und dann r2 für r1 zuweisen.
+ RBAC funktioniert sowohl für native Amazon-Redshift-Objekte als auch für Amazon Redshift Spectrum-Tabellen.
+ Als Amazon-Redshift-Administrator können Sie RBAC aktivieren, indem Sie Ihren Cluster auf den neuesten Wartungspatch aktualisieren, um loszulegen.
+ Nur Superuser und Benutzer mit der CREATE ROLE-Systemberechtigung können Rollen erstellen.
+ Nur Superuser und Rollenadministratoren können Rollen ändern oder löschen.
+ Ein Rollenname darf nicht mit einem Benutzernamen identisch sein.
+ Ein Rollenname darf keine unzulässigen Zeichen wie „:/\$1 n“ enthalten.
+ Ein Rollenname darf kein reserviertes Wort sein, beispielsweise PUBLIC.
+ Der Rollenname kann nicht mit dem reservierten Präfix für Standardrollen beginnen: `sys:`.
+ Sie können eine Rolle mit dem RESTRICT-Parameter nicht löschen, wenn sie einer anderen Rolle zugewiesen wird. Die Standardeinstellung ist RESTRICT. Amazon Redshift löst einen Fehler aus, wenn Sie versuchen, eine Rolle zu löschen, die eine andere Rolle geerbt hat.
+ Benutzer, die keine Administratorberechtigungen für eine Rolle haben, können eine Rolle nicht zuweisen oder widerrufen.
+ RBAC wird für Systemtabellen und Ansichten nicht vollständig unterstützt. RBAC-Berechtigungen für Systemtabellen und Systemansichten bleiben bei Upgrades, Downgrades oder Größenänderungen nicht erhalten. Wir empfehlen die Verwendung von [Systemdefinierte Amazon-Redshift-RollenSystemdefinierte Rollen und Benutzer für die gemeinsame Nutzung von Daten](r_roles-default.md) zur Verwaltung von Systemtabellen- und Anzeigeberechtigungen. Weitere Informationen zu Systemtabellen finden Sie unter [Referenz zu Systemtabellen und Ansichten](cm_chap_system-tables.md).
# Verwalten von Rollen in RBAC
Verwenden Sie die folgenden Befehle, um die unten aufgeführten Aktionen auszuführen:
+ Um eine Rolle zu erstellen, verwenden Sie den Befehl [CREATE ROLE](r_CREATE_ROLE.md).
+ Um eine Rolle umzubenennen oder den Besitzer der Rolle zu ändern, verwenden Sie den Befehl [ALTER ROLE](r_ALTER_ROLE.md).
+ Verwenden Sie zum Löschen einer Rolle den Befehl [DROP ROLE](r_DROP_ROLE.md).
+ Um einem Benutzer eine Rolle zuzuweisen, verwenden Sie den Befehl [GRANT](r_GRANT.md).
+ Um eine Rolle von einem Benutzer zu widerrufen, verwenden Sie den Befehl [REVOKE](r_REVOKE.md).
+ Um Systemberechtigungen für eine Rolle zu erteilen, verwenden Sie den Befehl [GRANT](r_GRANT.md).
+ Um Systemberechtigungen für eine Rolle zu entziehen, verwenden Sie den Befehl [REVOKE](r_REVOKE.md).
Eine Liste der Rollen in Ihrem Cluster oder Ihrer Arbeitsgruppe finden Sie unter [SVV\$1ROLES](r_SVV_ROLES.md).
# Tutorial: Rollen erstellen und Abfragen mit RBAC durchführen
Mit RBAC können Sie Rollen mit Berechtigungen zum Ausführen von Befehlen erstellen, für die früher Superuser-Berechtigungen erforderlich waren. Benutzer können diese Befehle ausführen, sofern ihnen die Rolle zugewiesen wurde, die diese Berechtigungen enthält.
In diesem Tutorial verwenden Sie die rollenbasierte Zugriffssteuerung (RBAC) zum Verwalten von Berechtigungen in einer von Ihnen erstellten Datenbank. Anschließend stellen Sie eine Verbindung zu der Datenbank her und fragen die Datenbank von zwei verschiedenen Rollen aus ab, um die Funktionalität von RBAC zu testen.
Die beiden Rollen, die Sie erstellen und verwenden, um die Datenbank abzufragen, sind `sales_ro` und `sales_rw`. Sie erstellen die `sales_ro`-Rolle und fragen Daten als Benutzer mit der `sales_ro`-Rolle ab. Der `sales_ro`-Benutzer kann nur den Befehl SELECT verwenden, nicht jedoch den Befehl UPDATE. Anschließend erstellen Sie die `sales_rw`-Rolle und fragen Daten als Benutzer mit der `sales_rw`-Rolle ab. Der `sales_rw`-Benutzer kann den Befehl SELECT und den Befehl UPDATE verwenden.
Auf ähnliche Weise können Sie auch Rollen erstellen, um den Zugriff auf bestimmte Befehle zu beschränken, und die Rolle entweder Superusern oder Benutzern zuzuweisen.
**Aufgaben**
+ [Voraussetzungen](#tutorial-rbac-prereqs)
+ [Schritt 1: Erstellen eines Administratorbenutzers](#tutorial-rbac-step1)
+ [Schritt 2: Einrichten von Schemata](#tutorial-rbac-step2)
+ [Schritt 3: Erstellen eines schreibgeschützten Benutzers](#tutorial-rbac-step3)
+ [Schritt 4: Abfragen der Daten als schreibgeschützter Benutzer](#tutorial-rbac-step4)
+ [Schritt 5: Erstellen eines Benutzers mit Lese- und Schreibberechtigungen](#tutorial-rbac-step5)
+ [Schritt 6: Abfragen der Daten als Benutzer mit der übernommenen schreibgeschützten Rolle](#tutorial-rbac-step6)
+ [Schritt 7: Erteilen von Aktualisierungs- und Einfügeberechtigungen für die Lese-/Schreib-Rolle](#tutorial-rbac-step7)
+ [Schritt 8: Abfragen der Daten als Benutzer mit Lese-/Schreibzugriff ab](#tutorial-rbac-step8)
+ [Schritt 9: Analysieren und Leeren von Tabellen in einer Datenbank als Administratorbenutzer](#tutorial-rbac-step9)
+ [Schritt 10: Kürzen von Tabellen als Benutzer mit Lese-/Schreibzugriff](#tutorial-rbac-step10)
+ [Systemfunktionen für RBAC (optional)](#tutorial-rbac-system-functions)
+ [Systemansichten für RBAC (optional)](#tutorial-rbac-system-views)
+ [Verwenden der Sicherheit auf Zeilenebene mit RBAC (optional)](#tutorial-rbac-rls)
## Voraussetzungen
+ Erstellen Sie einen Amazon-Redshift-Cluster oder eine Serverless-Arbeitsgruppe, der/die mit der TICKIT-Beispieldatenbank geladen ist. Informationen zum Erstellen einer Serverless-Arbeitsgruppe finden Sie unter [Erste Schritte mit Redshift Serverless Data Warehouses](https://docs.aws.amazon.com/redshift/latest/gsg/new-user-serverless.html). Informationen zum Erstellen eines Clusters finden Sie unter [Erstellen eines Amazon-Redshift-Beispielclusters](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-launch-sample-cluster.html). Weitere Informationen zur TICKIT-Beispieldatenbank finden Sie unter [Beispieldatenbank](c_sampledb.md).
+ Sie haben Zugriff auf einen Benutzer mit Superuser- oder Rollenadministratorberechtigungen. Nur Superuser oder Rollenadministratoren können Rollen zuweisen oder widerrufen. Weitere Informationen zu den für RBAC erforderlichen Berechtigungen finden Sie unter [Systemberechtigungen für RBAC](r_roles-system-privileges.md).
+ Überprüfen Sie das [Überlegungen zur Rollennutzung in RBAC](r_role-usage-notes.md).
## Schritt 1: Erstellen eines Administratorbenutzers
Um dieses Tutorial einzurichten, erstellen Sie eine Datenbankadministratorrolle und weisen sie in diesem Schritt einem Datenbankadministratorbenutzer zu. Sie müssen den Datenbankadministrator als Superuser oder Rollenadministrator erstellen.
Verwenden Sie den Amazon Redshift [Query Editor v2](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-using.html), um die Abfragen auszuführen.
1. Verwenden Sie das folgende Beispiel, um die Administratorrolle db\$1admin zu erstellen.
```
CREATE ROLE db_admin;
```
1. Im folgenden Beispiel wird ein Datenbankbenutzer mit dem Namen dbadmin erstellt.
```
CREATE USER dbadmin PASSWORD 'Test12345';
```
1. Verwenden Sie das folgende Beispiel, um der Rolle db\$1admin die vom System definierte Rolle mit dem Namen sys:dba zuzuweisen. Wenn dem Benutzer dbadmin die Rolle sys:dba zugewiesen wird, kann er Schemata und Tabellen erstellen. Weitere Informationen finden Sie unter [Systemdefinierte Amazon-Redshift-RollenSystemdefinierte Rollen und Benutzer für die gemeinsame Nutzung von Daten](r_roles-default.md).
## Schritt 2: Einrichten von Schemata
In diesem Schritt stellen Sie als Datenbankadministrator eine Verbindung zu Ihrer Datenbank her. Anschließend erstellen Sie zwei Schemata und fügen ihnen Daten hinzu.
1. Stellen Sie mit Query Editor v2 als Benutzer dbadmin eine Verbindung zur dev-Datenbank her. Weitere Informationen zum Herstellen einer Verbindung zu einer Datenbank finden Sie unter [Arbeiten mit Query Editor v2](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-using.html).
1. Verwenden Sie das folgende Beispiel, um die Vertriebs- und Marketing-Datenbankschemata zu erstellen.
```
CREATE SCHEMA sales;
CREATE SCHEMA marketing;
```
1. Verwenden Sie das folgende Beispiel, um Werte zu erstellen und in Tabellen im Vertriebsschema einzufügen.
```
CREATE TABLE sales.cat(
catid smallint,
catgroup varchar(10),
catname varchar(10),
catdesc varchar(50)
);
INSERT INTO sales.cat(SELECT * FROM category);
CREATE TABLE sales.dates(
dateid smallint,
caldate date,
day char(3),
week smallint,
month char(5),
qtr char(5),
year smallint,
holiday boolean
);
INSERT INTO sales.dates(SELECT * FROM date);
CREATE TABLE sales.events(
eventid integer,
venueid smallint,
catid smallint,
dateid smallint,
eventname varchar(200),
starttime timestamp
);
INSERT INTO sales.events(SELECT * FROM event);
CREATE TABLE sales.sale(
salesid integer,
listid integer,
sellerid integer,
buyerid integer,
eventid integer,
dateid smallint,
qtysold smallint,
pricepaid decimal(8,2),
commission decimal(8,2),
saletime timestamp
);
INSERT INTO sales.sale(SELECT * FROM sales);
```
1. Verwenden Sie das folgende Beispiel, um Werte zu erstellen und in Tabellen im Marketingschema einzufügen.
```
CREATE TABLE marketing.cat(
catid smallint,
catgroup varchar(10),
catname varchar(10),
catdesc varchar(50)
);
INSERT INTO marketing.cat(SELECT * FROM category);
CREATE TABLE marketing.dates(
dateid smallint,
caldate date,
day char(3),
week smallint,
month char(5),
qtr char(5),
year smallint,
holiday boolean
);
INSERT INTO marketing.dates(SELECT * FROM date);
CREATE TABLE marketing.events(
eventid integer,
venueid smallint,
catid smallint,
dateid smallint,
eventname varchar(200),
starttime timestamp
);
INSERT INTO marketing.events(SELECT * FROM event);
CREATE TABLE marketing.sale(
marketingid integer,
listid integer,
sellerid integer,
buyerid integer,
eventid integer,
dateid smallint,
qtysold smallint,
pricepaid decimal(8,2),
commission decimal(8,2),
saletime timestamp
);
INSERT INTO marketing.sale(SELECT * FROM marketing);
```
## Schritt 3: Erstellen eines schreibgeschützten Benutzers
In diesem Schritt erstellen Sie eine schreibgeschützte Rolle und einen Salesanalyst-Benutzer für die schreibgeschützte Rolle. Der Salesanalyst benötigt nur Lesezugriff auf die Tabellen im Vertriebsschema, um die ihm zugewiesene Aufgabe zu erfüllen, nämlich die Ereignisse zu finden, die zu den höchsten Provisionen geführt haben.
1. Verbindung zur Datenbank als dbadmin-Benutzer.
1. Verwenden Sie das folgende Beispiel, um die Rolle sales\$1ro zu erstellen.
```
CREATE ROLE sales_ro;
```
1. Verwenden Sie das folgende Beispiel, um den Salesanalyst-Benutzer zu erstellen.
```
CREATE USER salesanalyst PASSWORD 'Test12345';
```
1. Verwenden Sie das folgende Beispiel, um der Rolle sales\$1ro die Verwendung und den Auswahlzugriff auf Objekte des Vertriebsschemas zu gewähren.
```
GRANT USAGE ON SCHEMA sales TO ROLE sales_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA sales TO ROLE sales_ro;
```
1. Verwenden Sie das folgende Beispiel, um dem Salesanalyst-Benutzer die Rolle sales\$1ro zuzuweisen.
```
GRANT ROLE sales_ro TO salesanalyst;
```
## Schritt 4: Abfragen der Daten als schreibgeschützter Benutzer
In diesem Schritt fragt der Salesanalyst-Benutzer Daten aus dem Vertriebsschema ab. Anschließend versucht der Salesanalyst-Benutzer, eine Tabelle zu aktualisieren und Tabellen im Marketingschema zu lesen.
1. Verbindung zur Datenbank als Salesanalyst-Benutzer.
1. Verwenden Sie das folgende Beispiel, um die 10 Verkäufe mit den höchsten Provisionen zu finden.
```
SET SEARCH_PATH TO sales;
SELECT DISTINCT events.dateid, sale.commission, cat.catname
FROM sale, events, dates, cat
WHERE events.dateid=dates.dateid AND events.dateid=sale.dateid AND events.catid = cat.catid
ORDER BY 2 DESC LIMIT 10;
+--------+------------+----------+
| dateid | commission | catname |
+--------+------------+----------+
| 1880 | 1893.6 | Pop |
| 1880 | 1893.6 | Opera |
| 1880 | 1893.6 | Plays |
| 1880 | 1893.6 | Musicals |
| 1861 | 1500 | Plays |
| 2003 | 1500 | Pop |
| 1861 | 1500 | Opera |
| 2003 | 1500 | Plays |
| 1861 | 1500 | Musicals |
| 1861 | 1500 | Pop |
+--------+------------+----------+
```
1. Verwenden Sie das folgende Beispiel, um 10 Ereignisse aus der Tabelle „Ereignisse“ im Vertriebsschema auszuwählen.
```
SELECT * FROM sales.events LIMIT 10;
+---------+---------+-------+--------+--------------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+--------------------+---------------------+
| 4836 | 73 | 9 | 1871 | Soulfest | 2008-02-14 19:30:00 |
| 5739 | 41 | 9 | 1871 | Fab Faux | 2008-02-14 19:30:00 |
| 627 | 229 | 6 | 1872 | High Society | 2008-02-15 14:00:00 |
| 2563 | 246 | 7 | 1872 | Hamlet | 2008-02-15 20:00:00 |
| 7703 | 78 | 9 | 1872 | Feist | 2008-02-15 14:00:00 |
| 7903 | 90 | 9 | 1872 | Little Big Town | 2008-02-15 19:30:00 |
| 7925 | 101 | 9 | 1872 | Spoon | 2008-02-15 19:00:00 |
| 8113 | 17 | 9 | 1872 | Santana | 2008-02-15 15:00:00 |
| 463 | 303 | 8 | 1873 | Tristan und Isolde | 2008-02-16 19:00:00 |
| 613 | 236 | 6 | 1873 | Pal Joey | 2008-02-16 15:00:00 |
+---------+---------+-------+--------+--------------------+---------------------+
```
1. Führen Sie das folgende Beispiel aus, um zu versuchen, den Ereignisnamen für Event-ID 1 zu aktualisieren. Dieses Beispiel führt zu dem Fehler „Zugriff verweigert“, da der Salesanalyst-Benutzer nur über SELECT-Berechtigungen für die Ereignistabelle im Vertriebsschema verfügt. Um die Ereignistabelle zu aktualisieren, müssen Sie der Rolle sales\$1ro die UPDATE-Berechtigung gewähren. Weitere Informationen über das Erteilen von Berechtigungen zum Aktualisieren einer Tabelle finden Sie unter dem UPDATE-Parameter für [GRANT](r_GRANT.md). Weitere Informationen zur Verwendung des UPDATE-Befehls finden Sie unter [UPDATE](r_UPDATE.md).
```
UPDATE sales.events
SET eventname = 'Comment event'
WHERE eventid = 1;
ERROR: permission denied for relation events
```
1. Verwenden Sie das folgende Beispiel, um zu versuchen, alle Ereignisse aus der Ereignistabelle im Marketingschema auszuwählen. Dieses Beispiel führt zu dem Fehler „Zugriff verweigert“, da der Salesanalyst-Benutzer nur über SELECT-Berechtigungen für die Ereignistabelle im Vertriebsschema verfügt. Um Daten aus der Ereignistabelle im Marketingschema auszuwählen, müssen Sie der Rolle sales\$1ro SELECT-Berechtigungen für die Ereignistabelle im Marketingschema gewähren.
```
SELECT * FROM marketing.events;
ERROR: permission denied for schema marketing
```
## Schritt 5: Erstellen eines Benutzers mit Lese- und Schreibberechtigungen
In diesem Schritt erhält der Salesengineer, der für den Aufbau der Extract, Transform, Load (ETL)-Pipeline für die Datenverarbeitung im Vertriebsschema verantwortlich ist, nur Lesezugriff. Später erhält er jedoch Lese- und Schreibzugriff, um seine Aufgaben auszuführen.
1. Verbindung zur Datenbank als dbadmin-Benutzer.
1. Verwenden Sie das folgende Beispiel, um die Rolle sales\$1rw im Vertriebsschema zu erstellen.
```
CREATE ROLE sales_rw;
```
1. Verwenden Sie das folgende Beispiel, um den Salesengineer-Benutzer zu erstellen.
```
CREATE USER salesengineer PASSWORD 'Test12345';
```
1. Verwenden Sie das folgende Beispiel, um der Rolle sales\$1rw Nutzungs- und Auswahlberechtigungen für die Objekte des Vertriebsschemas zu gewähren, indem Sie ihr die Rolle sales\$1ro zuweisen. Weitere Informationen dazu, wie Rollen Berechtigungen in Amazon Redshift übernehmen, finden Sie unter [Rollenhierarchie](t_role_hierarchy.md).
```
GRANT ROLE sales_ro TO ROLE sales_rw;
```
1. Verwenden Sie das folgende Beispiel, um dem Salesengineer-Benutzer die Rolle sales\$1rw zuzuweisen.
```
GRANT ROLE sales_rw TO salesengineer;
```
## Schritt 6: Abfragen der Daten als Benutzer mit der übernommenen schreibgeschützten Rolle
In diesem Schritt versucht der Salesengineer-Benutzer, die Ereignistabelle zu aktualisieren, bevor ihm Leseberechtigungen erteilt werden.
1. Verbindung zur Datenbank als Salesengineer-Benutzer.
1. Der Salesengineer-Benutzer kann erfolgreich Daten aus der Ereignistabelle des Vertriebsschemas lesen. Verwenden Sie das folgende Beispiel, um das Ereignis mit der Event-ID 1 aus der Ereignistabelle im Vertriebsschema auszuwählen.
```
SELECT * FROM sales.events where eventid=1;
+---------+---------+-------+--------+-----------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+-----------------+---------------------+
| 1 | 305 | 8 | 1851 | Gotterdammerung | 2008-01-25 14:30:00 |
+---------+---------+-------+--------+-----------------+---------------------+
```
1. Verwenden Sie das folgende Beispiel, um zu versuchen, alle Ereignisse aus der Ereignistabelle im Marketingschema auszuwählen. Der Salesengineer-Benutzer hat keine Berechtigungen für Tabellen im Marketingschema, daher führt diese Abfrage zu dem Fehler „Zugriff verweigert“. Um Daten aus der Ereignistabelle im Marketingschema auszuwählen, müssen Sie der Rolle sales\$1rw SELECT-Berechtigungen für die Ereignistabelle im Marketingschema gewähren.
```
SELECT * FROM marketing.events;
ERROR: permission denied for schema marketing
```
1. Führen Sie das folgende Beispiel aus, um zu versuchen, den Ereignisnamen für Event-ID 1 zu aktualisieren. Dieses Beispiel führt zu dem Fehler „Zugriff verweigert“, da der Salesengineer-Benutzer nur über Auswahlberechtigungen für die Ereignistabelle im Vertriebsschema verfügt. Um die Ereignistabelle zu aktualisieren, müssen Sie der Rolle sales\$1rw UPDATE-Berechtigungen gewähren.
```
UPDATE sales.events
SET eventname = 'Comment event'
WHERE eventid = 1;
ERROR: permission denied for relation events
```
## Schritt 7: Erteilen von Aktualisierungs- und Einfügeberechtigungen für die Lese-/Schreib-Rolle
In diesem Schritt erteilen Sie der Rolle sales\$1rw Aktualisierungs- und Einfügeberechtigungen.
1. Verbindung zur Datenbank als dbadmin-Benutzer.
1. Verwenden Sie das folgende Beispiel, um der Rolle sales\$1rw die Berechtigungen UPDATE, INSERT und DELETE zu gewähren.
```
GRANT UPDATE, INSERT, ON ALL TABLES IN SCHEMA sales TO role sales_rw;
```
## Schritt 8: Abfragen der Daten als Benutzer mit Lese-/Schreibzugriff ab
In diesem Schritt aktualisiert der Salesengineer die Tabelle erfolgreich, nachdem seiner Rolle Einfüge- und Aktualisierungsberechtigungen erteilt wurden. Anschließend versucht der Salesengineer, die Ereignistabelle zu analysieren und zu leeren, was ihm jedoch nicht gelingt.
1. Verbindung zur Datenbank als salesengineer-Benutzer.
1. Führen Sie das folgende Beispiel aus, um zu versuchen, den Ereignisnamen für Event-ID 1 zu aktualisieren.
```
UPDATE sales.events
SET eventname = 'Comment event'
WHERE eventid = 1;
```
1. Um die in der vorherigen Abfrage vorgenommene Änderung anzuzeigen, verwenden Sie das folgende Beispiel, um das Ereignis mit der Event-ID 1 aus der Ereignistabelle im Vertriebsschema auszuwählen.
```
SELECT * FROM sales.events WHERE eventid=1;
+---------+---------+-------+--------+---------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+---------------+---------------------+
| 1 | 305 | 8 | 1851 | Comment event | 2008-01-25 14:30:00 |
+---------+---------+-------+--------+---------------+---------------------+
```
1. Verwenden Sie das folgende Beispiel, um die Tabelle der aktualisierten Ereignisse im Vertriebsschema zu analysieren. Dieses Beispiel führt zu dem Fehler „Zugriff verweigert“, da der salesengineer-Benutzer nicht über die erforderlichen Berechtigungen verfügt und nicht der Eigentümer der Ereignistabelle im Vertriebsschema ist. Um die Ereignistabelle zu analysieren, müssen Sie der Rolle sales\$1rw mithilfe des Befehls GRANT die ANALYZE-Berechtigung gewähren. Weitere Informationen zur Verwendung des ANALYZE-Befehls finden Sie unter [ANALYZE](r_ANALYZE.md).
```
ANALYZE sales.events;
ERROR: skipping "events" --- only table or database owner can analyze
```
1. Verwenden Sie das folgende Beispiel, um die aktualisierte Ereignistabelle zu leeren. Dieses Beispiel führt zu dem Fehler „Zugriff verweigert“, da der salesengineer-Benutzer nicht über die erforderlichen Berechtigungen verfügt und nicht der Eigentümer der Ereignistabelle im Vertriebsschema ist. Um die Ereignistabelle zu leeren, müssen Sie der Rolle sales\$1rw mithilfe des Befehls GRANT die VACUUM-Berechtigung gewähren. Weitere Informationen zum VACUUM-Befehl finden Sie unter [VACUUM](r_VACUUM_command.md).
```
VACUUM sales.events;
ERROR: skipping "events" --- only table or database owner can vacuum it
```
## Schritt 9: Analysieren und Leeren von Tabellen in einer Datenbank als Administratorbenutzer
In diesem Schritt analysiert der dbadmin-Benutzer alle Tabellen und leert sie. Der Benutzer hat Administratorrechte für diese Datenbank, so dass er diese Befehle ausführen kann.
1. Verbindung zur Datenbank als dbadmin-Benutzer.
1. Verwenden Sie das folgende Beispiel, um die Ereignistabelle im Vertriebsschema zu analysieren.
```
ANALYZE sales.events;
```
1. Verwenden Sie das folgende Beispiel, um die Ereignistabelle im Vertriebsschema zu leeren.
```
VACUUM sales.events;
```
1. Verwenden Sie das folgende Beispiel, um die Ereignistabelle im Marketingschema zu analysieren.
```
ANALYZE marketing.events;
```
1. Verwenden Sie das folgende Beispiel, um die Ereignistabelle im Marketingschema zu leeren.
```
VACUUM marketing.events;
```
## Schritt 10: Kürzen von Tabellen als Benutzer mit Lese-/Schreibzugriff
In diesem Schritt versucht der Salesengineer-Benutzer, die Ereignistabelle im Vertriebsschema zu kürzen, was jedoch nur gelingt, wenn ihm der Benutzer dbadmin die Rechte zum Kürzen erteilt.
1. Verbindung zur Datenbank als Salesengineer-Benutzer.
1. Verwenden Sie das folgende Beispiel, um zu versuchen, alle Zeilen aus der Ereignistabelle im Vertriebsschema zu löschen. Dieses Beispiel führt zu einem Fehler, da der Salesengineer-Benutzer nicht über die erforderlichen Berechtigungen verfügt und nicht der Eigentümer der Ereignistabelle im Vertriebsschema ist. Um die Ereignistabelle zu kürzen, müssen Sie der Rolle sales\$1rw mithilfe des Befehls GRANT die TRUNCATE-Berechtigung gewähren. Weitere Informationen zur Verwendung des TRUNCATE-Befehls finden Sie unter [TRUNCATE](r_TRUNCATE.md).
```
TRUNCATE sales.events;
ERROR: must be owner of relation events
```
1. Verbindung zur Datenbank als dbadmin-Benutzer.
1. Verwenden Sie das folgende Beispiel, um der Rolle sales\$1rw die Berechtigung zum Kürzen von Tabellen zu gewähren.
```
GRANT TRUNCATE TABLE TO role sales_rw;
```
1. Verbinden Sie sich mithilfe von Query Editor v2 als Salesengineer-Benutzer mit der Datenbank.
1. Verwenden Sie das folgende Beispiel, um die ersten 10 Ereignisse aus der Ereignistabelle im Vertriebsschema zu lesen.
```
SELECT * FROM sales.events ORDER BY eventid LIMIT 10;
+---------+---------+-------+--------+-----------------------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+-----------------------------+---------------------+
| 1 | 305 | 8 | 1851 | Comment event | 2008-01-25 14:30:00 |
| 2 | 306 | 8 | 2114 | Boris Godunov | 2008-10-15 20:00:00 |
| 3 | 302 | 8 | 1935 | Salome | 2008-04-19 14:30:00 |
| 4 | 309 | 8 | 2090 | La Cenerentola (Cinderella) | 2008-09-21 14:30:00 |
| 5 | 302 | 8 | 1982 | Il Trovatore | 2008-06-05 19:00:00 |
| 6 | 308 | 8 | 2109 | L Elisir d Amore | 2008-10-10 19:30:00 |
| 7 | 309 | 8 | 1891 | Doctor Atomic | 2008-03-06 14:00:00 |
| 8 | 302 | 8 | 1832 | The Magic Flute | 2008-01-06 20:00:00 |
| 9 | 308 | 8 | 2087 | The Fly | 2008-09-18 19:30:00 |
| 10 | 305 | 8 | 2079 | Rigoletto | 2008-09-10 15:00:00 |
+---------+---------+-------+--------+-----------------------------+---------------------+
```
1. Verwenden Sie das folgende Beispiel, um die Tabelle mit den Ereignissen im Vertriebsschema zu kürzen.
```
TRUNCATE sales.events;
```
1. Verwenden Sie das folgende Beispiel, um die Daten aus der Tabelle der aktualisierten Ereignisse im Vertriebsschema zu lesen.
```
SELECT * FROM sales.events ORDER BY eventid LIMIT 10;
+---------+---------+-------+--------+-----------------------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+-----------------------------+---------------------+
```
### Erstellen Sie schreibgeschützte und schreib- und leseberechtigte Rollen für das Marketingschema (optional)
In diesem Schritt erstellen Sie schreibgeschützte und schreib- und leseberechtigte Rollen für das Marketingschema.
1. Verbindung zur Datenbank als dbadmin-Benutzer.
1. Verwenden Sie das folgende Beispiel, um Rollen mit Lese-/Schreibzugriff für das Marketingschema zu erstellen.
```
CREATE ROLE marketing_ro;
CREATE ROLE marketing_rw;
GRANT USAGE ON SCHEMA marketing TO ROLE marketing_ro, ROLE marketing_rw;
GRANT SELECT ON ALL TABLES IN SCHEMA marketing TO ROLE marketing_ro;
GRANT ROLE marketing_ro TO ROLE marketing_rw;
GRANT INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA marketing TO ROLE marketing_rw;
CREATE USER marketinganalyst PASSWORD 'Test12345';
CREATE USER marketingengineer PASSWORD 'Test12345';
GRANT ROLE marketing_ro TO marketinganalyst;
GRANT ROLE marketing_rw TO marketingengineer;
```
## Systemfunktionen für RBAC (optional)
Amazon Redshift bietet zwei Funktionen zur Bereitstellung von Systeminformationen zur Benutzermitgliedschaft und Rollenmitgliedschaft in zusätzlichen Gruppen oder Rollen: role\$1is\$1member\$1of und user\$1is\$1member\$1of. Diese Funktionen stehen Superusern und regulären Benutzern zur Verfügung. Superuser können die Mitgliedschaft aller Rollen überprüfen. Reguläre Benutzer können die Mitgliedschaft nur für Rollen überprüfen, für die ihnen Zugriff gewährt wurde.
So verwenden Sie die Funktion role\$1is\$1member\$1of:
1. Verbindung zur Datenbank als Salesengineer-Benutzer.
1. Verwenden Sie das folgende Beispiel, um zu überprüfen, ob die Rolle sales\$1rw ein Mitglied der Rolle sales\$1ro ist.
```
SELECT role_is_member_of('sales_rw', 'sales_ro');
+-------------------+
| role_is_member_of |
+-------------------+
| true |
+-------------------+
```
1. Verwenden Sie das folgende Beispiel, um zu überprüfen, ob die Rolle sales\$1ro ein Mitglied der Rolle sales\$1rw ist.
```
SELECT role_is_member_of('sales_ro', 'sales_rw');
+-------------------+
| role_is_member_of |
+-------------------+
| false |
+-------------------+
```
So verwenden Sie die Funktion user\$1is\$1member\$1of:
1. Verbindung zur Datenbank als Salesengineer-Benutzer.
1. Im folgenden Beispiel wird versucht, die Mitgliedschaft des Salesanalyst-Benutzers Salesanalyst zu überprüfen. Diese Abfrage führt zu einem Fehler, da Salesengineer keinen Zugriff auf Salesanalyst hat. Um diesen Befehl erfolgreich auszuführen, stellen Sie als Salesanalyst-Benutzer eine Verbindung mit der Datenbank her und verwenden Sie das Beispiel.
```
SELECT user_is_member_of('salesanalyst', 'sales_ro');
ERROR
```
1. Verbinden Sie sich als Superuser mit der Datenbank.
1. Verwenden Sie das folgende Beispiel, um die Mitgliedschaft des Salesanalyst-Benutzers bei Anmeldung als Superuser zu überprüfen.
```
SELECT user_is_member_of('salesanalyst', 'sales_ro');
+-------------------+
| user_is_member_of |
+-------------------+
| true |
+-------------------+
```
1. Verbindung zur Datenbank als dbadmin-Benutzer.
1. Verwenden Sie das folgende Beispiel, um die Mitgliedschaft des Salesengineer-Benutzers zu überprüfen.
```
SELECT user_is_member_of('salesengineer', 'sales_ro');
+-------------------+
| user_is_member_of |
+-------------------+
| true |
+-------------------+
SELECT user_is_member_of('salesengineer', 'marketing_ro');
+-------------------+
| user_is_member_of |
+-------------------+
| false |
+-------------------+
SELECT user_is_member_of('marketinganalyst', 'sales_ro');
+-------------------+
| user_is_member_of |
+-------------------+
| false |
+-------------------+
```
## Systemansichten für RBAC (optional)
Verwenden Sie die Systemansichten für Amazon Redshift, um die Rollen, die Rollenzuweisung zu Benutzern, die Rollenhierarchie und die Rechte für Datenbankobjekte über Rollen anzuzeigen. Diese Ansichten sind für Superuser und normale Benutzer verfügbar. Superuser können alle Rollendetails überprüfen. Reguläre Benutzer können nur die Details von Rollen überprüfen, für die ihnen Zugriff gewährt wurde.
1. Verwenden Sie das folgende Beispiel, um eine Liste der Benutzer anzuzeigen, denen explizit Rollen in dem Cluster gewährt werden.
```
SELECT * FROM svv_user_grants;
```
1. Verwenden Sie das folgende Beispiel, um eine Liste der Rollen anzuzeigen, denen explizit Rollen in dem Cluster gewährt werden.
```
SELECT * FROM svv_role_grants;
```
Eine vollständige Liste der Systemansichten finden Sie unter [SVV-Metadatenansichten](svv_views.md).
## Verwenden der Sicherheit auf Zeilenebene mit RBAC (optional)
Mit Sicherheit auf Zeilenebene (RLS) in Amazon Redshift können Sie eine granulare Zugriffssteuerung für Ihre sensiblen Daten vornehmen. Weitere Informationen zu RLS finden Sie unter [Sicherheit auf Zeilenebene](t_rls.md).
In diesem Abschnitt erstellen Sie eine RLS-Richtlinie, die dem `salesengineer`-Benutzer die Berechtigung gibt, nur Zeilen in der `cat`-Tabelle anzuzeigen, die den `catdesc`-Wert „Major League Baseball“ haben. Anschließend fragen Sie die Datenbank als `salesengineer`-Benutzer ab.
1. Verbindung zur Datenbank als `salesengineer`-Benutzer.
1. Verwenden Sie das folgende Beispiel, um die ersten 5 Einträge der `cat`-Tabelle anzuzeigen.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+---------------------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+---------------------------------+
| 1 | Sports | MLB | Major League Baseball |
| 2 | Sports | NHL | National Hockey League |
| 3 | Sports | NFL | National Football League |
| 4 | Sports | NBA | National Basketball Association |
| 5 | Sports | MLS | Major League Soccer |
+-------+----------+---------+---------------------------------+
```
1. Verbindung zur Datenbank als `dbadmin`-Benutzer.
1. Verwenden Sie das folgende Beispiel, um eine RLS-Richtlinie für die `catdesc`-Spalte in der `cat`-Tabelle zu erstellen.
```
CREATE RLS POLICY policy_mlb_engineer
WITH (catdesc VARCHAR(50))
USING (catdesc = 'Major League Baseball');
```
1. Verwenden Sie das folgende Beispiel, um die RLS-Richtlinie an die `sales_rw`-Rolle anzufügen.
```
ATTACH RLS POLICY policy_mlb_engineer ON sales.cat TO ROLE sales_rw;
```
1. Verwenden Sie das folgende Beispiel, um die Tabelle so zu ändern, dass RLS aktiviert wird.
```
ALTER TABLE sales.cat ROW LEVEL SECURITY ON;
```
1. Verbindung zur Datenbank als `salesengineer`-Benutzer.
1. Verwenden Sie das folgende Beispiel, um zu versuchen, die ersten 5 Einträge der `cat`-Tabelle anzuzeigen. Beachten Sie, dass nur Einträge angezeigt werden, wenn die `catdesc`-Spalte `Major League Baseball` ist.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+-----------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+-----------------------+
| 1 | Sports | MLB | Major League Baseball |
+-------+----------+---------+-----------------------+
```
1. Verbindung zur Datenbank als `salesanalyst`-Benutzer.
1. Verwenden Sie das folgende Beispiel, um zu versuchen, die ersten 5 Einträge der `cat`-Tabelle anzuzeigen. Beachten Sie, dass keine Einträge angezeigt werden, da die Standardrichtlinie „Alle verweigern“ angewendet wird.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+-----------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+-----------------------+
```
1. Verbindung zur Datenbank als `dbadmin`-Benutzer.
1. Verwenden Sie das folgende Beispiel, um der `sales_ro`-Rolle die Berechtigung IGNORE RLS zu erteilen. Dadurch erhält der `salesanalyst`-Benutzer die Berechtigung, RLS-Richtlinien zu ignorieren, da er Mitglied der `sales_ro`-Rolle ist.
```
GRANT IGNORE RLS TO ROLE sales_ro;
```
1. Verbindung zur Datenbank als `salesanalyst`-Benutzer.
1. Verwenden Sie das folgende Beispiel, um die ersten 5 Einträge der `cat`-Tabelle anzuzeigen.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+---------------------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+---------------------------------+
| 1 | Sports | MLB | Major League Baseball |
| 2 | Sports | NHL | National Hockey League |
| 3 | Sports | NFL | National Football League |
| 4 | Sports | NBA | National Basketball Association |
| 5 | Sports | MLS | Major League Soccer |
+-------+----------+---------+---------------------------------+
```
1. Verbindung zur Datenbank als `dbadmin`-Benutzer.
1. Verwenden Sie das folgende Beispiel, um der `sales_ro`-Rolle die Berechtigung IGNORE RLS zu entziehen.
```
REVOKE IGNORE RLS FROM ROLE sales_ro;
```
1. Verbindung zur Datenbank als `salesanalyst`-Benutzer.
1. Verwenden Sie das folgende Beispiel, um zu versuchen, die ersten 5 Einträge der `cat`-Tabelle anzuzeigen. Beachten Sie, dass keine Einträge angezeigt werden, da die Standardrichtlinie „Alle verweigern“ angewendet wird.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+-----------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+-----------------------+
```
1. Verbindung zur Datenbank als `dbadmin`-Benutzer.
1. Verwenden Sie das folgende Beispiel, um die RLS-Richtlinie von der `cat`-Tabelle zu trennen.
```
DETACH RLS POLICY policy_mlb_engineer ON cat FROM ROLE sales_rw;
```
1. Verbindung zur Datenbank als `salesanalyst`-Benutzer.
1. Verwenden Sie das folgende Beispiel, um zu versuchen, die ersten 5 Einträge der `cat`-Tabelle anzuzeigen. Beachten Sie, dass keine Einträge angezeigt werden, da die Standardrichtlinie „Alle verweigern“ angewendet wird.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+---------------------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+---------------------------------+
| 1 | Sports | MLB | Major League Baseball |
| 2 | Sports | NHL | National Hockey League |
| 3 | Sports | NFL | National Football League |
| 4 | Sports | NBA | National Basketball Association |
| 5 | Sports | MLS | Major League Soccer |
+-------+----------+---------+---------------------------------+
```
1. Verbindung zur Datenbank als `dbadmin`-Benutzer.
1. Verwenden Sie das folgende Beispiel, um die RLS-Richtlinie zu verwerfen.
```
DROP RLS POLICY policy_mlb_engineer;
```
1. Verwenden Sie das folgende Beispiel, um RLS zu entfernen.
```
ALTER TABLE cat ROW LEVEL SECURITY OFF;
```
## Verwandte Themen
Weitere Informationen zu RBAC finden Sie in der folgenden Dokumentation:
+ [Rollenhierarchie](t_role_hierarchy.md)
+ [Rollenzuweisung](t_role_assignment.md)
+ [Datenbankobjektberechtigungen](r_roles-database-privileges.md)
+ [ALTER DEFAULT PRIVILEGES für RBAC](r_roles-alter-default-privileges.md)
# Sicherheit auf Zeilenebene
Mit Row-Level-Security (RLS) in Amazon Redshift können Sie eine granulare Zugriffssteuerung für Ihre sensiblen Daten vornehmen. Sie können entscheiden, welche Benutzer oder Rollen auf bestimmte Datensätze in Schemas oder Tabellen zugreifen können, basierend auf RLS-Richtlinien, die auf Datenbankobjektebene definiert sind. Zusätzlich zur Sicherheit auf Spaltenebene, bei der Sie Benutzern Berechtigungen für eine Teilmenge von Spalten erteilen können, verwenden Sie RLS-Richtlinien (Row-Level Security), um den Zugriff auf bestimmte Zeilen der sichtbaren Spalten weiter einzuschränken. Weitere Hinweise zur Sicherheit auf Spaltenebene finden Sie unter [Verwendungshinweise für die Zugriffskontrolle auf Spaltenebene](r_GRANT-usage-notes.md#r_GRANT-usage-notes-clp).
Wenn Sie RLS-Richtlinien (Row-Level Security) für Tabellen erzwingen, können Sie zurückgegebene Ergebnismengen einschränken, wenn Benutzer Abfragen ausführen.
Beim Erstellen von RLS-Richtlinien (Row-Level Security) können Sie Ausdrücke angeben, die bestimmen, ob Amazon Redshift vorhandene Zeilen in einer Tabelle in einer Abfrage zurückgibt. Durch das Erstellen von RLS-Richtlinien (Row-Level Security) zur Einschränkung des Zugriffs müssen Sie keine zusätzlichen Bedingungen in Ihren Abfragen hinzufügen oder externalisieren.
Beim Erstellen von RLS-Richtlinien (Row-Level Security) empfehlen wir, dass Sie einfache Richtlinien erstellen und komplexe Anweisungen in Richtlinien vermeiden. Verwenden Sie beim Definieren von RLS-Richtlinien (Row-Level Security) keine übermäßigen Tabellenverknüpfungen in der Richtliniendefinition, die auf Richtlinien basieren.
Wenn eine Richtlinie auf eine Nachschlagetabelle verweist, scannt Amazon Redshift diese weitere Tabelle zusätzlich zu der Tabelle, in der die Richtlinie enthalten ist. Es gibt Leistungsunterschiede zwischen derselben Abfrage für einen Benutzer mit angefügter RLS-Richtlinie und für einen Benutzer ohne angefügte Richtlinie.
# Verwenden von RLS-Richtlinien (Row-Level Security) in SQL-Anweisungen
Bei der Verwendung von RLS-Richtlinien (Row-Level Security) in SQL-Anweisungen wendet Amazon Redshift die folgenden Regeln an:
+ Amazon Redshift wendet RLS-Richtlinien (Row-Level Security) standardmäßig auf die SELECT-, UPDATE- und DELETE-Anweisungen an.
+ Für SELECT und UNLOAD filtert Amazon Redshift Zeilen gemäß Ihrer definierten Richtlinie.
+ Für UPDATE aktualisiert Amazon Redshift nur die Zeilen, die für Sie sichtbar sind. Wenn eine Richtlinie eine Teilmenge der Zeilen in einer Tabelle einschränkt, können Sie diese nicht aktualisieren.
+ Für DELETE können Sie nur die Zeilen löschen, die für Sie sichtbar sind. Wenn eine Richtlinie eine Teilmenge der Zeilen in einer Tabelle einschränkt, können Sie sie nicht löschen. Für TRUNCATE können Sie die Tabelle trotzdem abschneiden.
+ Bei CREATE TABLE LIKE erben Tabellen, die mit den LIKE-Optionen erstellt wurden, keine Berechtigungseinstellungen von der Quelltabelle. Ebenso erbt die Zieltabelle die RLS-Richtlinien (Row-Level Security) nicht von der Quelltabelle.
# Kombinieren mehrerer Richtlinien pro Benutzer
RLS in Amazon Redshift unterstützt das Anfügen mehrerer Richtlinien pro Benutzer und Objekt. Wenn für einen Benutzer mehrere Richtlinien definiert sind, wendet Amazon Redshift alle Richtlinien mit der UND- oder ODER-Syntax an, abhängig von der Einstellung RLS CONJUNCTION TYPE für die Tabelle. Weitere Informationen zu Verbindungstypen finden Sie unter [ALTER TABLE](r_ALTER_TABLE.md).
Ihnen können mehrere Richtlinien für eine Tabelle zugeordnet werden. Entweder sind Ihnen mehrere Richtlinien direkt zugeordnet, oder Sie gehören mehreren Rollen an, und den Rollen sind unterschiedliche Richtlinien zugeordnet.
Wenn mehrere Richtlinien den Zeilenzugriff in einer bestimmten Relation einschränken sollen, können Sie RLS CONJUNCTION TYPE der Relation auf AND setzen. Betrachten Sie das folgende Beispiel. Alice kann nur Sport-Ereignisse sehen, deren „Katzenname“ in der angegebenen Richtlinie „NBA“ ist.
```
-- Create an analyst role and grant it to a user named Alice.
CREATE ROLE analyst;
CREATE USER alice WITH PASSWORD 'Name_is_alice_1';
GRANT ROLE analyst TO alice;
-- Create an RLS policy that only lets the user see sports.
CREATE RLS POLICY policy_sports
WITH (catgroup VARCHAR(10))
USING (catgroup = 'Sports');
-- Create an RLS policy that only lets the user see NBA.
CREATE RLS POLICY policy_nba
WITH (catname VARCHAR(10))
USING (catname = 'NBA');
-- Attach both to the analyst role.
ATTACH RLS POLICY policy_sports ON category TO ROLE analyst;
ATTACH RLS POLICY policy_nba ON category TO ROLE analyst;
-- Activate RLS on the category table with AND CONJUNCTION TYPE.
ALTER TABLE category ROW LEVEL SECURITY ON CONJUNCTION TYPE AND;
-- Change session to Alice.
SET SESSION AUTHORIZATION alice;
-- Select all from the category table.
SELECT catgroup, catname
FROM category;
catgroup | catname
---------+---------
Sports | NBA
(1 row)
```
Wenn mehrere Richtlinien Benutzern ermöglichen sollen, mehr Zeilen in einer bestimmten Relation zu sehen, kann der Benutzer RLS CONJUNCTION TYPE der Relation auf OR setzen. Betrachten Sie das folgende Beispiel. Alice kann gemäß der angegebenen Richtlinie nur „Konzerte“ und „Sport“ sehen.
```
-- Create an analyst role and grant it to a user named Alice.
CREATE ROLE analyst;
CREATE USER alice WITH PASSWORD 'Name_is_alice_1';
GRANT ROLE analyst TO alice;
-- Create an RLS policy that only lets the user see concerts.
CREATE RLS POLICY policy_concerts
WITH (catgroup VARCHAR(10))
USING (catgroup = 'Concerts');
-- Create an RLS policy that only lets the user see sports.
CREATE RLS POLICY policy_sports
WITH (catgroup VARCHAR(10))
USING (catgroup = 'Sports');
-- Attach both to the analyst role.
ATTACH RLS POLICY policy_concerts ON category TO ROLE analyst;
ATTACH RLS POLICY policy_sports ON category TO ROLE analyst;
-- Activate RLS on the category table with OR CONJUNCTION TYPE.
ALTER TABLE category ROW LEVEL SECURITY ON CONJUNCTION TYPE OR;
-- Change session to Alice.
SET SESSION AUTHORIZATION alice;
-- Select all from the category table.
SELECT catgroup, count(*)
FROM category
GROUP BY catgroup ORDER BY catgroup;
catgroup | count
---------+-------
Concerts | 3
Sports | 5
(2 rows)
```
# Besitz und Verwaltung von RLS-Richtlinien (Row-Level Security)
Als Superuser, Sicherheitsadministrator oder Benutzer mit der Rolle sys:secadmin können Sie alle RLS-Richtlinien für Tabellen erstellen, ändern oder verwalten. RLS-Richtlinien können an Tabellen, Ansichten, Ansichten mit verspäteter Bindung () und materialisierte Ansichten (LBVs) angehängt werden. MVs Auf Objektebene können Sie die Sicherheit auf Zeilenebene ein- oder ausschalten, ohne die Schemadefinition für Tabellen zu ändern.
Um mit der Sicherheit auf Zeilenebene zu beginnen, können Sie die folgenden SQL-Anweisungen verwenden:
+ Verwenden Sie die ALTER TABLE-Anweisung, um RLS für eine Tabelle ein- oder auszuschalten. Weitere Informationen finden Sie unter [ALTER TABLE](r_ALTER_TABLE.md).
+ Verwenden Sie die ALTER MATERIALIZED VIEW-Anweisung um RLS für eine materialisierte Ansicht (MV) ein- oder auszuschalten. Weitere Informationen finden Sie unter [ALTER MATERIALIZED VIEW](r_ALTER_MATERIALIZED_VIEW.md).
+ Verwenden Sie die CREATE RLS POLICY-Anweisung, um eine RLS-Richtlinie (Row-Level Security) für eine oder mehrere Tabellen zu erstellen, und geben Sie einen oder mehrere Benutzer oder Rollen in der Richtlinie an.
Weitere Informationen finden Sie unter [CREATE RLS POLICY](r_CREATE_RLS_POLICY.md).
+ Verwenden Sie die Anweisung ALTER RLS POLICY, um die Richtlinie zu bearbeiten, z. B. die Richtliniendefinition zu ändern. Sie können dieselbe Richtlinie für mehrere Tabellen oder Ansichten verwenden.
Weitere Informationen finden Sie unter [ALTER RLS POLICY](r_ALTER_RLS_POLICY.md).
+ Verwenden Sie die Anweisung ATTACH RLS POLICY, um eine Richtlinie an eine oder mehrere Relationen, einen oder mehrere Benutzer oder Rollen anzufügen.
Weitere Informationen finden Sie unter [ATTACH RLS POLICY](r_ATTACH_RLS_POLICY.md).
+ Verwenden Sie die DETACH RLS POLICY-Anweisung, um eine Richtlinie von einer oder mehreren Relationen, von einem oder mehreren Benutzern oder von Rollen zu trennen.
Weitere Informationen finden Sie unter [DETACH RLS POLICY](r_DETACH_RLS_POLICY.md).
+ Verwenden Sie die DROP RLS POLICY-Anweisung, um eine Richtlinie zu entfernen.
Weitere Informationen finden Sie unter [DROP RLS POLICY](r_DROP_RLS_POLICY.md).
+ Verwenden Sie die GRANT- und REVOKE-Anweisungen, um SELECT-Berechtigungen für RLS-Richtlinien(Row-Level Security) , die auf Nachschlagetabellen verweisen, explizit zu erteilen und zu widerrufen. Weitere Informationen erhalten Sie unter [GRANT](r_GRANT.md) und [REVOKE](r_REVOKE.md).
Um die erstellten Richtlinien zu überwachen, kann sys:secadmin die [SVV\$1RLS\$1POLICY](r_SVV_RLS_POLICY.md) und [SVV\$1RLS\$1ATTACHED\$1POLICY](r_SVV_RLS_ATTACHED_POLICY.md) anzeigen.
Um RLS-geschützte Relationen aufzulisten, kann sys:secadmin [SVV\$1RLS\$1RELATION](r_SVV_RLS_RELATION.md) anzeigen.
Um die Anwendung von RLS-Richtlinien (Row-Level Security) auf Abfragen zu verfolgen, die auf RLS-geschützte Relationen verweisen, kann ein Superuser, sys:operator oder jeder Benutzer mit der Systemberechtigung ACCESS SYSTEM TABLE [SVV\$1RLS\$1APPLIED\$1POLICY](r_SVV_RLS_APPLIED_POLICY.md) anzeigen. Beachten Sie, dass sys:secadmin diese Berechtigungen standardmäßig nicht gewährt werden.
Um Benutzern vollen Zugriff auf eine RLS-geschützte Beziehung zu gewähren, können Sie die Berechtigung IGNORE RLS gewähren. Benutzern, die Superuser oder sys:secadmin sind, wird IGNORE RLS automatisch gewährt. Weitere Informationen finden Sie unter [GRANT](r_GRANT.md).
Um die RLS-Richtlinienfilter (Row-Level Security) einer Abfrage im EXPLAIN-Plan zur Fehlerbehebung bei RLS-bezogenen Abfragen zu erklären, können Sie jedem Benutzer die Berechtigung EXPLAIN RLS erteilen. Weitere Informationen erhalten Sie unter [GRANT](r_GRANT.md) und [EXPLAIN](r_EXPLAIN.md).
# Richtlinienabhängige Objekte und Prinzipien
Um die Sicherheit für Anwendungen zu gewährleisten und zu verhindern, dass Richtlinienobjekte veraltet oder ungültig werden, lässt Amazon Redshift das Entfernen oder Ändern von Objekten, auf die von RLS-Richtlinien verwiesen wird, nicht zu.
Im Folgenden werden Schema-Objektabhängigkeiten aufgelistet, die Amazon Redshift für RLS-Richtlinien (Row-Level Security) verfolgt.
+ Beim Verfolgen der Schemaobjektabhängigkeit für die Zieltabelle folgt Amazon Redshift diesen Regeln:
+ Amazon Redshift trennt die Richtlinie von einer Relation, einem Benutzer, einer Rolle oder einer Öffentlichkeit, wenn Sie eine Zieltabelle entfernen.
+ Wenn Sie den Namen einer Zieltabelle umbenennen, hat dies keine Auswirkungen auf die zugeordneten Richtlinien.
+ Sie können die Spalten der Zieltabelle, auf die in der Richtliniendefinition verwiesen wird, nur entfernen, wenn Sie zuerst die Richtlinie entfernen oder trennen. Dies gilt auch, wenn die Option CASCADE angegeben ist. Sie können andere Spalten in der Zieltabelle entfernen.
+ Sie können die referenzierten Spalten der Zieltabelle nicht umbenennen. Um verwiesene Spalten umzubenennen, trennen Sie zuerst die Richtlinie. Dies gilt auch, wenn die Option CASCADE angegeben ist.
+ Sie können den Typ der referenzierten Spalte nicht ändern, selbst wenn Sie die CASCADE-Option angeben.
+ Bei der Verfolgung der Schema-Objekt-Abhängigkeit für die Nachschlagetabelle folgt Amazon Redshift diesen Regeln:
+ Sie können eine Nachschlagetabelle nicht entfernen. Um eine Nachschlagetabelle zu entfernen, entfernen Sie zuerst die Richtlinie, in der auf die Nachschlagetabelle verwiesen wird.
+ Sie können eine Nachschlagetabelle nicht umbenennen. Um eine Nachschlagetabelle umzubenennen, entfernen Sie zunächst die Richtlinie, in der auf die Nachschlagetabelle verwiesen wird. Dies gilt auch, wenn die Option CASCADE angegeben ist.
+ Sie können die in der Richtliniendefinition verwendeten Spalten der Nachschlagetabelle nicht entfernen. Um die in der Richtliniendefinition verwendeten Nachschlagetabellenspalten zu entfernen, entfernen Sie zunächst die Richtlinie, in der die Nachschlagetabelle referenziert wird. Dies gilt auch, wenn die Option CASCADE in der ALTER TABLE DROP COLUMN-Anweisung angegeben ist. Sie können andere Spalten in der Nachschlagetabelle entfernen.
+ Sie können die referenzierten Spalten der Nachschlagetabelle nicht umbenennen. Um referenzierte Spalten umzubenennen, entfernen Sie zunächst die Richtlinie, in der auf die Nachschlagetabelle verwiesen wird. Dies gilt auch, wenn die Option CASCADE angegeben ist.
+ Sie können den Typ der referenzierten Spalte nicht ändern.
+ Wenn ein Benutzer oder eine Rolle entfernt wird, trennt Amazon Redshift automatisch alle dem Benutzer oder der Rolle zugeordneten Richtlinien.
+ Wenn Sie die CASCADE-Option in der DROP SCHEMA-Anweisung verwenden, entfernt Amazon Redshift auch die Relationen im Schema. Außerdem werden die Relationen in allen anderen Schemata entfernt, die von den Relationen des entfernten Schemas abhängig sind. Für eine Relation, die eine Nachschlagetabelle in einer Richtlinie ist, lässt Amazon Redshift die DROP SCHEMA DDL fehlschlagen. Für alle Relationen, die durch die DROP-SCHEMA-Anweisung entfernt werden, trennt Amazon Redshift alle Richtlinien, die diesen Relationen zugeordnet sind.
+ Sie können eine Suchfunktion (eine Funktion, auf die innerhalb einer Richtliniendefinition verwiesen wird) nur entfernen, wenn Sie auch die Richtlinie entfernen. Dies gilt auch, wenn die Option CASCADE angegeben ist.
+ Wenn eine Richtlinie an eine Tabelle angefügt wird, prüft Amazon Redshift, ob diese Tabelle eine Nachschlagetabelle in einer anderen Richtlinie ist. In diesem Fall lässt Amazon Redshift das Anhängen einer Richtlinie an diese Tabelle nicht zu.
+ Beim Erstellen einer RLS-Richtlinie (Row-Level Security) prüft Amazon Redshift, ob diese Tabelle eine Zieltabelle für eine andere RLS-Richtlinie ist. In diesem Fall lässt Amazon Redshift das Erstellen einer Richtlinie für diese Tabelle nicht zu.
## Beispiel
Das folgende Beispiel veranschaulicht, wie die Schemaabhängigkeit nachverfolgt wird.
```
-- The CREATE and ATTACH policy statements for `policy_events` references some
-- target and lookup tables.
-- Target tables are tickit_event_redshift and target_schema.target_event_table.
-- Lookup table is tickit_sales_redshift.
-- Policy `policy_events` has following dependencies:
-- table tickit_sales_redshift column eventid, qtysold
-- table tickit_event_redshift column eventid
-- table target_event_table column eventid
-- schema public and target_schema
CREATE RLS POLICY policy_events
WITH (eventid INTEGER)
USING (
eventid IN (SELECT eventid FROM tickit_sales_redshift WHERE qtysold <3)
);
ATTACH RLS POLICY policy_events ON tickit_event_redshift TO ROLE analyst;
ATTACH RLS POLICY policy_events ON target_schema.target_event_table TO ROLE consumer;
```
# Überlegungen zur Verwendung von RLS-Richtlinien und Einschränkungen
## Überlegungen
Im Folgenden finden Sie Überlegungen für das Arbeiten mit RLS-Richtlinien (Row-Level Security):
+ Amazon Redshift wendet RLS-Richtlinien (Row-Level Security) auf SELECT-, UPDATE- oder DELETE-Anweisungen an.
+ Amazon Redshift wendet keine RLS-Richtlinien (Row-Level Security) auf die Anweisungen INSERT, COPY, ALTER TABLE APPEND an.
+ RLS-Richtlinien können an Tabellen, Ansichten, Late Binding Views () und Materialized Views (LBVs) angehängt werden. MVs
+ Die Sicherheit auf Zeilenebene arbeitet mit der Sicherheit auf Spaltenebene zusammen, um Ihre Daten zu schützen.
+ Wenn RLS für die Quellrelation aktiviert ist, unterstützt Amazon Redshift die Anweisung ALTER TABLE APPEND für Superuser, Benutzer, denen ausdrücklich das Systemberechtigung IGNORE RLS gewährt wurde, oder die Rolle sys:secadmin. In diesem Fall können Sie die Anweisung ALTER TABLE APPEND ausführen, um Zeilen an eine Zieltabelle anzufügen, indem Sie Daten aus einer vorhandenen Quelltabelle verschieben. Amazon Redshift verschiebt alle Tupel aus der Quellrelation in die Zielrelation. Der RLS-Status der Zielrelation hat keinen Einfluss auf die Anweisung ALTER TABLE APPEND.
+ Um die Migration von anderen Data-Warehouse-Systemen zu erleichtern, können Sie benutzerdefinierte Sitzungskontextvariablen für eine Verbindung festlegen und abrufen, indem Sie den Variablennamen und -wert angeben.
Im folgenden Beispiel werden Sitzungskontextvariablen für eine Richtlinie für Sicherheit auf Zeilenebene (RLS) festgelegt.
```
-- Set a customized context variable.
SELECT set_config(‘app.category’, ‘Concerts’, FALSE);
-- Create a RLS policy using current_setting() to get the value of a customized context variable.
CREATE RLS POLICY policy_categories
WITH (catgroup VARCHAR(10))
USING (catgroup = current_setting('app.category', FALSE));
-- Set correct roles and attach the policy on the target table to one or more roles.
ATTACH RLS POLICY policy_categories ON tickit_category_redshift TO ROLE analyst, ROLE dbadmin;
```
Einzelheiten zum Festlegen und Abrufen angepasster Sitzungskontextvariablen finden Sie unter [SET](r_SET.md), [SET\$1CONFIG](r_SET_CONFIG.md), [ZEIGEN](r_SHOW.md), [CURRENT\$1SETTING](r_CURRENT_SETTING.md) und [RESET](r_RESET.md). Weitere Informationen zum Ändern der Serverkonfiguration im Allgemeinen finden Sie unter [Modifizieren der Serverkonfiguration](cm_chap_ConfigurationRef.md#t_Modifying_the_default_settings).
**Wichtig**
Bei der Verwendung von Sitzungskontextvariablen innerhalb von RLS-Richtlinien hängt die Sicherheitsrichtlinie von dem Benutzer oder der Rolle ab, der/die die Richtlinie aufruft. Achten Sie darauf, Schwachstellen zu vermeiden, wenn Sie Sitzungskontextvariablen in RLS-Richtlinien verwenden.
+ Wenn Sie den Sitzungsbenutzer mit SET SESSION AUTHORIZATION zwischen DECLARE und FETCH oder zwischen nachfolgenden FETCH-Anweisungen ändern, wird der bereits vorbereitete Plan nicht aktualisiert, der auf den Benutzerrichtlinien zum Zeitpunkt von DECLARE basiert. Vermeiden Sie einen Wechsel des Sitzungsbenutzers, wenn Cursor mit RLS-geschützten Tabellen verwendet werden.
+ Wenn die Basisobjekte innerhalb eines Ansichtsobjekts RLS-geschützt sind, werden Richtlinien, die dem die Abfrage ausführenden Benutzer angefügt sind, auf die entsprechenden Basisobjekte angewendet. Dies unterscheidet sich von den Berechtigungsprüfungen auf Objektebene, bei denen die Berechtigungen des Besitzers der Ansicht mit den Basisobjekten der Ansicht verglichen werden. Sie können die RLS-geschützten Relationen einer Abfrage in ihrer EXPLAIN-Planausgabe einsehen.
+ Wenn in einer RLS-Richtlinie einer einem Benutzer angefügten Relation auf eine benutzerdefinierte Funktion (User-defined function, UDF) verwiesen wird, muss der Benutzer über die Berechtigung EXECUTE für die UDF verfügen, um die Relation abzufragen.
+ Die Sicherheit auf Zeilenebene kann die Abfrageoptimierung einschränken. Wir empfehlen, die Abfrageleistung sorgfältig zu prüfen, bevor Sie RLS-geschützte Ansichten für große Datenmengen bereitstellen.
+ Sicherheitsrichtlinien auf Zeilenebene, die auf Late-Binding-Ansichten angewendet werden, können in Verbundtabellen übertragen werden. Diese RLS-Richtlinien sind möglicherweise in den Protokollen der externen Verarbeitungs-Engine sichtbar.
## Einschränkungen
Im Folgenden sind die Einschränkungen beim Arbeiten mit RLS-Richtlinien (Row-Level Security) aufgeführt:
+ RLS-Richtlinien können nicht an externe Tabellen und mehrere andere Beziehungstypen angefügt werden. Weitere Informationen finden Sie unter [ATTACH RLS POLICY](r_ATTACH_RLS_POLICY.md).
+ Amazon Redshift unterstützt SELECT-Anweisungen für bestimmte RLS-Richtlinien (Row-Level Security) mit Suchvorgängen, die komplexe Verknüpfungen aufweisen, unterstützt jedoch keine UPDATE- oder DELETE-Anweisungen. In Fällen mit UPDATE- oder DELETE-Anweisungen gibt Amazon Redshift den folgenden Fehler zurück:
```
ERROR: One of the RLS policies on target relation is not supported in UPDATE/DELETE.
```
+ Immer wenn in einer RLS-Richtlinie einer einem Benutzer angefügten Relation auf eine benutzerdefinierte Funktion (UDF) verwiesen wird, muss der Benutzer über die Berechtigung EXECUTE für die UDF verfügen, um die Relation abzufragen.
+ Korrelierte Unterabfragen werden nicht unterstützt. Amazon Redshift gibt den folgenden Fehler zurück:
```
ERROR: RLS policy could not be rewritten.
```
+ Amazon Redshift unterstützt keine Datenfreigabe mit RLS. Wenn bei einer Relation RLS für Datashares nicht deaktiviert ist, schlägt die Abfrage im Konsumenten-Cluster mit dem folgenden Fehler fehl:
```
RLS-protected relation "rls_protected_table" cannot be accessed via datasharing query.
```
Sie können RLS für Datashares deaktivieren, indem Sie den Befehl ALTER TABLE mit dem Parameter ROW LEVEL SECURITY OFF FOR DATASHARES verwenden. Weitere Informationen zur Verwendung von ALTER TABLE zum Aktivieren oder Deaktivieren von RLS finden Sie unter [ALTER TABLE](r_ALTER_TABLE.md).
+ Bei datenbankübergreifenden Abfragen blockiert Amazon Redshift den Lesezugriff auf RLS-geschützte Relationen. Benutzer mit der Berechtigung IGNORE RLS können mithilfe von datenbankübergreifenden Abfragen auf die geschützte Relation zugreifen. Wenn ein Benutzer ohne die Berechtigung IGNORE RLS über eine datenbankübergreifende Abfrage auf die RLS-geschützte Relation zugreift, wird der folgende Fehler angezeigt:
```
RLS-protected relation "rls_protected_table" cannot be accessed via cross-database query.
```
+ ALTER RLS POLICY unterstützt nur das Ändern einer RLS-Richtlinie mithilfe der USING (using\$1predicate\$1exp)-Klausel. Sie können eine RLS-Richtlinie nicht mit einer WITH-Klausel ändern, wenn Sie ALTER RLS POLICY ausführen.
+ Sie können keine Beziehungen abfragen, für die die Sicherheit auf Zeilenebene aktiviert ist, wenn die Werte für eine der folgenden Konfigurationsoptionen nicht dem Standardwert der Sitzung entsprechen:
+ `enable_case_sensitive_super_attribute`
+ `enable_case_sensitive_identifier`
+ `downcase_delimited_identifier`
Erwägen Sie, die Konfigurationsoptionen Ihrer Sitzung zurückzusetzen, wenn Sie versuchen, eine Beziehung mit aktivierter Sicherheit auf Zeilenebene abzufragen und die Meldung „Die RLS-geschützte Beziehung unterstützt keine Konfiguration auf Sitzungsebene, da die Berücksichtigung von Groß- und Kleinschreibung vom Standardwert abweicht“ angezeigt wird.
+ Wenn Ihr bereitgestellter Cluster oder Serverless-Namespace über Sicherheitsrichtlinien auf Zeilenebene verfügt, werden die folgenden Befehle für normale Benutzer blockiert:
```
ALTER SET enable_case_sensitive_super_attribute/enable_case_sensitive_identifier/downcase_delimited_identifier
```
Wenn Sie RLS-Richtlinien erstellen, empfehlen wir, die Einstellungen der Standardkonfigurationsoptionen für normale Benutzer so zu ändern, dass sie den Einstellungen der Sitzungskonfigurationsoptionen zum Zeitpunkt der Erstellung der Richtlinie entsprechen. Superuser und Benutzer mit der Berechtigung ALTER USER können dies mithilfe von Parametergruppeneinstellungen oder dem Befehl ALTER USER erreichen. Informationen zu Parametergruppen finden Sie unter [Amazon-Redshift-Parametergruppen](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html) im *Amazon-Redshift-Verwaltungshandbuch*. Informationen zum Befehl ALTER USER finden Sie unter [ALTER USER](r_ALTER_USER.md).
+ Ansichten und Late-Binding-Ansichten mit Sicherheitsrichtlinien auf Zeilenebene können nicht von normalen Benutzern mit dem Befehl [CREATE VIEW](r_CREATE_VIEW.md) ersetzt werden. Um Ansichten oder durch RLS-Richtlinien zu ersetzen, trennen Sie zunächst alle LBVs mit ihnen verknüpften RLS-Richtlinien, ersetzen Sie die Ansichten oder LBVs und fügen Sie die Richtlinien erneut an. Superuser und Benutzer mit dem `sys:secadmin permission` können CREATE VIEW für Ansichten oder LBVs mit RLS-Richtlinien verwenden, ohne die Richtlinien zu trennen.
+ Ansichten mit Sicherheitsrichtlinien auf Zeilenebene können nicht auf Systemtabellen und Systemansichten verweisen.
+ Eine Late-Binding-Ansicht, auf die von einer regulären Ansicht verwiesen wird, kann nicht durch RLS geschützt werden.
+ Auf RLS-geschützte Relationen und verschachtelte Daten aus Data Lakes kann nicht in derselben Abfrage zugegriffen werden.
# Bewährte Methoden für RLS-Leistung
Im Folgenden finden Sie bewährte Methoden, um eine bessere Leistung von Amazon Redshift auf Tabellen zu gewährleisten, die durch RLS geschützt sind.
## Sicherheit von Operatoren und Funktionen
Bei der Abfrage von RLS-geschützten Tabellen kann die Verwendung bestimmter Operatoren oder Funktionen zu Leistungseinbußen führen. Amazon Redshift klassifiziert Operatoren und Funktionen entweder als sicher oder unsicher für die Abfrage von RLS-geschützten Tabellen. Eine Funktion oder ein Operator wird als RLS-sicher eingestuft, wenn sie abhängig von den Eingaben keine beobachtbaren Nebenwirkungen hat. Insbesondere darf eine RLS-sichere Funktion oder ein Operator nicht einer der folgenden sein:
+ Gibt einen Eingabewert oder jeden vom Eingabewert abhängigen Wert mit oder ohne Fehlermeldung aus.
+ Schlägt fehl oder gibt Fehler zurück, die vom Eingabewert abhängen.
Zu den RLS-unsicheren Operatoren gehören:
+ Arithmetische Operatoren — \$1, -, /, \$1, %.
+ Textoperatoren – LIKE und SIMILAR TO.
+ Cast-Operatoren.
+ UDFs.
Verwenden Sie die folgende SELECT-Anweisung, um die Sicherheit von Operatoren und Funktionen zu überprüfen.
```
SELECT proname, proc_is_rls_safe(oid) FROM pg_proc;
```
Amazon Redshift schränkt die Reihenfolge der Auswertung von Benutzerprädikaten ein, die RLS-unsichere Operatoren und Funktionen enthalten, wenn Abfragen für RLS-geschützte Tabellen geplant werden. Abfragen, die auf RLS-unsichere Operatoren oder Funktionen verweisen, können beim Abfragen von RLS-geschützten Tabellen zu Leistungseinbußen führen. Die Leistung kann sich erheblich verschlechtern, wenn Amazon Redshift RLS-unsichere Prädikate nicht auf Basistabellen-Scans verschieben kann, um Sortierschlüssel zu nutzen.. Vermeiden Sie für eine bessere Leistung Abfragen mit RLS-unsicheren Prädikaten, die einen Sortierschlüssel nutzen. Um zu überprüfen, ob Amazon Redshift in der Lage ist, Operatoren und Funktionen weiterzugeben, können Sie EXPLAIN-Anweisungen in Kombination mit der Systemberechtigung EXPLAIN RLS verwenden.
## Ergebnis-Zwischenspeicherung
Um die Laufzeit von Abfragen zu reduzieren und die Systemleistung zu verbessern, stellt Amazon Redshift die Ergebnisse bestimmter Abfragetypen in den Speicher auf dem Führungsknoten.
Amazon Redshift verwendet zwischengespeicherte Ergebnisse für eine neue Abfrage, die RLS-geschützte Tabellen scannt, wenn alle Bedingungen für ungeschützte Tabellen zutreffen und wenn alle der folgenden Bedingungen zutreffen:
+ Die Tabellen oder Ansichten in der Richtlinie wurden nicht geändert.
+ Die Richtlinie verwendet keine Funktion, die jedes Mal ausgewertet werden muss, wenn sie ausgeführt wird, wie z. B. GETDATE oder CURRENT\$1USER.
Um eine bessere Leistung zu erzielen, sollten Sie die Verwendung von Richtlinienprädikaten vermeiden, die die oben genannten Bedingungen nicht erfüllen.
Weitere Informationen zum Zwischenspeichern von Ergebnissen in Amazon Redshift finden Sie unter [Ergebnis-Zwischenspeicherung](c_challenges_achieving_high_performance_queries.md#result-caching).
## Komplexe Richtlinien
Vermeiden Sie für eine bessere Leistung die Verwendung komplexer Richtlinien mit Unterabfragen, die mehrere Tabellen verknüpfen.
# Beispiel für Sicherheit auf Zeilenebene end-to-end
Im Folgenden finden Sie ein end-to-end Beispiel, das veranschaulicht, wie ein Superuser einige Benutzer und Rollen erstellt. Anschließend erstellt ein Benutzer mit der Rolle secadmin RLS-Richtlinien (Row-Level Security), fügt sie hinzu, löst sie auf und entfernt sie. In diesem Beispiel wird die Musterdatenbank tickit verwendet. Weitere Informationen finden Sie unter [Laden von Daten von Amazon S3 in Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-create-sample-db.html) im *Amazon-Redshift-Handbuch für Erste Schritte*.
```
-- Create users and roles referenced in the policy statements.
CREATE ROLE analyst;
CREATE ROLE consumer;
CREATE ROLE dbadmin;
CREATE ROLE auditor;
CREATE USER bob WITH PASSWORD 'Name_is_bob_1';
CREATE USER alice WITH PASSWORD 'Name_is_alice_1';
CREATE USER joe WITH PASSWORD 'Name_is_joe_1';
CREATE USER molly WITH PASSWORD 'Name_is_molly_1';
CREATE USER bruce WITH PASSWORD 'Name_is_bruce_1';
GRANT ROLE sys:secadmin TO bob;
GRANT ROLE analyst TO alice;
GRANT ROLE consumer TO joe;
GRANT ROLE dbadmin TO molly;
GRANT ROLE auditor TO bruce;
GRANT ALL ON TABLE tickit_category_redshift TO PUBLIC;
GRANT ALL ON TABLE tickit_sales_redshift TO PUBLIC;
GRANT ALL ON TABLE tickit_event_redshift TO PUBLIC;
-- Create table and schema referenced in the policy statements.
CREATE SCHEMA target_schema;
GRANT ALL ON SCHEMA target_schema TO PUBLIC;
CREATE TABLE target_schema.target_event_table (LIKE tickit_event_redshift);
GRANT ALL ON TABLE target_schema.target_event_table TO PUBLIC;
-- Change session to analyst alice.
SET SESSION AUTHORIZATION alice;
-- Check the tuples visible to analyst alice.
-- Should contain all 3 categories.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
CREATE RLS POLICY policy_concerts
WITH (catgroup VARCHAR(10))
USING (catgroup = 'Concerts');
SELECT poldb, polname, polalias, polatts, polqual, polenabled, polmodifiedby FROM svv_rls_policy WHERE poldb = CURRENT_DATABASE();
ATTACH RLS POLICY policy_concerts ON tickit_category_redshift TO ROLE analyst, ROLE dbadmin;
ALTER TABLE tickit_category_redshift ROW LEVEL SECURITY ON;
SELECT * FROM svv_rls_attached_policy;
-- Change session to analyst alice.
SET SESSION AUTHORIZATION alice;
-- Check that tuples with only `Concert` category will be visible to analyst alice.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to consumer joe.
SET SESSION AUTHORIZATION joe;
-- Although the policy is attached to a different role, no tuples will be
-- visible to consumer joe because the default deny all policy is applied.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to dbadmin molly.
SET SESSION AUTHORIZATION molly;
-- Check that tuples with only `Concert` category will be visible to dbadmin molly.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Check that EXPLAIN output contains RLS SecureScan to prevent disclosure of
-- sensitive information such as RLS filters.
EXPLAIN SELECT catgroup, count(*) FROM tickit_category_redshift GROUP BY catgroup ORDER BY catgroup;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
-- Grant IGNORE RLS permission so that RLS policies do not get applicable to role dbadmin.
GRANT IGNORE RLS TO ROLE dbadmin;
-- Grant EXPLAIN RLS permission so that anyone in role auditor can view complete EXPLAIN output.
GRANT EXPLAIN RLS TO ROLE auditor;
-- Change session to dbadmin molly.
SET SESSION AUTHORIZATION molly;
-- Check that all tuples are visible to dbadmin molly because `IGNORE RLS` is granted to role dbadmin.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to auditor bruce.
SET SESSION AUTHORIZATION bruce;
-- Check explain plan is visible to auditor bruce because `EXPLAIN RLS` is granted to role auditor.
EXPLAIN SELECT catgroup, count(*) FROM tickit_category_redshift GROUP BY catgroup ORDER BY catgroup;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
DETACH RLS POLICY policy_concerts ON tickit_category_redshift FROM ROLE analyst, ROLE dbadmin;
-- Change session to analyst alice.
SET SESSION AUTHORIZATION alice;
-- Check that no tuples are visible to analyst alice.
-- Although the policy is detached, no tuples will be visible to analyst alice
-- because of default deny all policy is applied if the table has RLS on.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
CREATE RLS POLICY policy_events
WITH (eventid INTEGER) AS ev
USING (
ev.eventid IN (SELECT eventid FROM tickit_sales_redshift WHERE qtysold <3)
);
ATTACH RLS POLICY policy_events ON tickit_event_redshift TO ROLE analyst;
ATTACH RLS POLICY policy_events ON target_schema.target_event_table TO ROLE consumer;
RESET SESSION AUTHORIZATION;
-- Can not cannot alter type of dependent column.
ALTER TABLE target_schema.target_event_table ALTER COLUMN eventid TYPE float;
ALTER TABLE tickit_event_redshift ALTER COLUMN eventid TYPE float;
ALTER TABLE tickit_sales_redshift ALTER COLUMN eventid TYPE float;
ALTER TABLE tickit_sales_redshift ALTER COLUMN qtysold TYPE float;
-- Can not cannot rename dependent column.
ALTER TABLE target_schema.target_event_table RENAME COLUMN eventid TO renamed_eventid;
ALTER TABLE tickit_event_redshift RENAME COLUMN eventid TO renamed_eventid;
ALTER TABLE tickit_sales_redshift RENAME COLUMN eventid TO renamed_eventid;
ALTER TABLE tickit_sales_redshift RENAME COLUMN qtysold TO renamed_qtysold;
-- Can not drop dependent column.
ALTER TABLE target_schema.target_event_table DROP COLUMN eventid CASCADE;
ALTER TABLE tickit_event_redshift DROP COLUMN eventid CASCADE;
ALTER TABLE tickit_sales_redshift DROP COLUMN eventid CASCADE;
ALTER TABLE tickit_sales_redshift DROP COLUMN qtysold CASCADE;
-- Can not drop lookup table.
DROP TABLE tickit_sales_redshift CASCADE;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
DROP RLS POLICY policy_concerts;
DROP RLS POLICY IF EXISTS policy_events;
ALTER TABLE tickit_category_redshift ROW LEVEL SECURITY OFF;
RESET SESSION AUTHORIZATION;
-- Drop users and roles.
DROP USER bob;
DROP USER alice;
DROP USER joe;
DROP USER molly;
DROP USER bruce;
DROP ROLE analyst;
DROP ROLE consumer;
DROP ROLE auditor FORCE;
DROP ROLE dbadmin FORCE;
```
# Sicherheit von Metadaten
Wie die Sicherheit von Amazon Redshift auf Zeilenebene bietet Ihnen die Metadatensicherheit eine genauere Kontrolle über Ihre Metadaten. Wenn die Metadatensicherheit für Ihren bereitgestellten Cluster oder Ihre Serverless-Arbeitsgruppe aktiviert ist, können Benutzer Metadaten für die Objekte sehen, für die sie Anzeigezugriff haben. Mithilfe der Metadatensicherheit können Sie die Sichtbarkeit nach Ihren Bedürfnissen trennen. Sie können beispielsweise ein einziges Data Warehouse verwenden, um Ihren gesamten Datenspeicher zu zentralisieren. Wenn Sie jedoch Daten für mehrere Sektoren speichern, kann die Verwaltung der Sicherheit schwierig werden. Wenn die Metadatensicherheit aktiviert ist, können Sie Ihre Sichtbarkeit konfigurieren. Benutzer eines Sektors können ihre Objekte besser einsehen, während Sie den Anzeigezugriff auf Benutzer eines anderen Sektors einschränken. Die Metadatensicherheit unterstützt alle Objekttypen, wie z. B. Schemata, Tabellen, Ansichten, materialisierte Ansichten, gespeicherte Prozeduren, benutzerdefinierte Funktionen und Machine-Learning-Modelle.
Benutzer können Metadaten von Objekten unter den folgenden Umständen sehen:
+ Wenn dem Benutzer Objektzugriff gewährt wurde.
+ Wenn Objektzugriff einer Gruppe oder Rolle gewährt wurde, zu der der Benutzer gehört.
+ Das Objekt ist öffentlich.
+ Der Benutzer ist der Eigentümer des Datenbankobjekts.
Verwenden Sie den Befehl [ALTER SYSTEM](https://docs.aws.amazon.com/redshift/latest/dg/r_ALTER_SYSTEM.html), um die Metadatensicherheit zu aktivieren. Im Folgenden finden Sie die Syntax für die Verwendung des Befehls ALTER SYSTEM mit Metadatensicherheit.
```
ALTER SYSTEM SET metadata_security=[true|t|on|false|f|off];
```
Wenn Sie die Metadatensicherheit aktivieren, können alle Benutzer, die über die erforderlichen Berechtigungen verfügen, die relevanten Metadaten der Objekte sehen, auf die sie Zugriff haben. Wenn Sie möchten, dass nur bestimmte Benutzer die Metadatensicherheit sehen können, gewähren Sie einer Rolle die `ACCESS CATALOG`-Berechtigung und weisen Sie die Rolle dann dem Benutzer zu. Weitere Informationen zur Verwendung von Rollen zur besseren Kontrolle der Sicherheit finden Sie unter [Rollenbasierte Zugriffskontrolle](https://docs.aws.amazon.com/redshift/latest/dg/t_Roles.html).
Das folgende Beispiel zeigt, wie Sie einer Rolle die `ACCESS CATALOG`-Berechtigung gewähren und die Rolle dann einem Benutzer zuweisen. Weitere Informationen zum Erteilen von Berechtigungen finden Sie unter dem [GRANT](https://docs.aws.amazon.com/redshift/latest/dg/r_GRANT.html)-Befehl.
```
CREATE ROLE sample_metadata_viewer;
GRANT ACCESS CATALOG TO ROLE sample_metadata_viewer;
GRANT ROLE sample_metadata_viewer to salesadmin;
```
Wenn Sie es vorziehen, bereits definierte Rollen zu verwenden, verfügen die [systemdefinierten Rollen](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html) `operator`, `secadmin`, `dba` und `superuser` alle über die erforderlichen Berechtigungen zum Anzeigen von Objektmetadaten. Standardmäßig können Superuser den vollständigen Katalog sehen.
```
GRANT ROLE operator to sample_user;
```
Wenn Sie Rollen zur Steuerung der Metadatensicherheit verwenden, haben Sie Zugriff auf alle Systemansichten und Funktionen, die mit der rollenbasierten Zugriffskontrolle einhergehen. Sie können beispielsweise die Ansicht [ SVV\$1ROLES](https://docs.aws.amazon.com/redshift/latest/dg/r_SVV_ROLES.html) abfragen, um alle Rollen anzuzeigen. Um zu sehen, ob ein Benutzer Mitglied einer Rolle oder Gruppe ist, verwenden Sie die Funktion [USER\$1IS\$1MEMBER\$1OF](https://docs.aws.amazon.com/redshift/latest/dg/r_USER_IS_MEMBER_OF.html). Eine vollständige Liste der SVV-Ansichten finden Sie unter [SVV-Metadatenansichten](https://docs.aws.amazon.com/redshift/latest/dg/svv_views.html). Eine Liste der Systeminformationsfunktionen finden Sie unter [Systeminformationsfunktionen](https://docs.aws.amazon.com/redshift/latest/dg/r_System_information_functions.html).
# Dynamische Datenmaskierung
**Anmerkung**
Amazon Redshift maskiert automatisch bestimmte Systemtabellenspalten, wenn Informationen zu Abfragen in Datenkatalogansichten protokolliert werden, um die Offenlegung sensibler Metadaten zu verhindern. Weitere Informationen finden Sie unter [Sichere Protokollierung](https://docs.aws.amazon.com/redshift/latest/mgmt/db-auditing-secure-logging.html) im *Managementleitfaden zu Amazon Redshift*.
Mit der dynamischen Datenmaskierung (Dynamic Data Masking, DDM) in Amazon Redshift können Sie sensible Daten in Ihrem Data Warehouse schützen. Sie können festlegen, wie Amazon Redshift den Benutzern sensible Daten zum Zeitpunkt der Abfrage anzeigt, ohne diese in der Datenbank zu transformieren. Sie kontrollieren den Zugriff auf Daten mithilfe von Maskierungsrichtlinien, die benutzerdefinierte Verschleierungsregeln auf einen bestimmten Benutzer oder eine bestimmte Rolle anwenden. Auf diese Weise können Sie auf sich ändernde Datenschutzanforderungen reagieren, ohne die zugrunde liegenden Daten zu ändern oder SQL-Abfragen zu bearbeiten.
Richtlinien für die dynamische Datenmaskierung sorgen dafür, dass Daten, die einem bestimmten Format entsprechen, verborgen, verschleiert oder pseudonymisiert werden. Wenn ein Maskierungsausdruck an eine Tabelle angefügt ist, wird er auf eine oder mehrere Spalten der Tabelle angewendet. Sie können die Maskierungsrichtlinien weiter modifizieren, um sie nur auf bestimmte Benutzer oder auf benutzerdefinierte Rollen anzuwenden, die Sie mit [Rollenbasierte Zugriffskontrolle (RBAC)](t_Roles.md) erstellen. Darüber hinaus können Sie DDM auf Zellebene anwenden, indem Sie beim Erstellen Ihrer Maskierungsrichtlinie bedingte Spalten verwenden. Weitere Informationen zur bedingten Maskierung finden Sie unter [Bedingte dynamische Datenmaskierung](t_ddm-conditional.md).
Sie können mehrere Maskierungsrichtlinien mit unterschiedlichen Verschleierungsgraden auf dieselbe Spalte in einer Tabelle anwenden und verschiedenen Rollen zuweisen. Um Konflikte zu vermeiden, wenn Sie verschiedene Rollen haben und unterschiedliche Richtlinien für eine Spalte gelten, können Sie Prioritäten für jede Anwendung festlegen. Auf diese Weise können Sie steuern, auf welche Daten ein bestimmter Benutzer oder eine bestimmte Rolle zugreifen kann. DDM-Richtlinien können Daten teilweise oder vollständig unkenntlich machen oder mithilfe von benutzerdefinierten Funktionen, die in SQL, Python oder mit AWS Lambda geschrieben wurden, hashen. Durch das Maskieren von Daten mithilfe von Hashes können Sie Verknüpfungen auf diese Daten anwenden, ohne auf potenziell sensible Informationen zugreifen zu müssen.
# SQL-Befehle für Richtlinien für die dynamische Datenmaskierung
Sie können die folgenden Aktionen ausführen, um dynamische Datenmaskierungsrichtlinien zu erstellen, anzuhängen, zu trennen und zu löschen:
+ Um eine DDM-Richtlinie zu erstellen, verwenden Sie den Befehl [ERSTELLEN EINER MASKIERUNGSRICHTLINIE](r_CREATE_MASKING_POLICY.md).
Im Folgenden finden Sie ein Beispiel für die Erstellung einer Maskierungsrichtlinie mithilfe einer SHA-2-Hash-Funktion.
```
CREATE MASKING POLICY hash_credit
WITH (credit_card varchar(256))
USING (sha2(credit_card + 'testSalt', 256));
```
+ Verwenden Sie den Befehl [ALTER MASKING POLICY](r_ALTER_MASKING_POLICY.md), um eine bestehende DDM-Richtlinie zu ändern.
Im Folgenden finden Sie ein Beispiel für das Ändern einer vorhandenen Maskierungsrichtlinie.
```
ALTER MASKING POLICY hash_credit
USING (sha2(credit_card + 'otherTestSalt', 256));
```
+ Um eine DDM-Richtlinie für eine Tabelle einem oder mehreren Benutzern oder Rollen anzufügen, verwenden Sie den Befehl [ANFÜGEN EINER MASKIERUNGSRICHTLINIE](r_ATTACH_MASKING_POLICY.md).
Im Folgenden finden Sie ein Beispiel für das Anhängen einer Maskierungsrichtlinie an ein Paar. column/role
```
ATTACH MASKING POLICY hash_credit
ON credit_cards (credit_card)
TO ROLE science_role
PRIORITY 30;
```
Die PRIORITY-Klausel bestimmt, welche Maskierungsrichtlinie für eine Benutzersitzung gilt, wenn derselben Spalte mehrere Richtlinien angefügt sind. Wenn der Benutzer im vorherigen Beispiel beispielsweise derselben Kreditkartenspalte eine weitere Maskierungsrichtlinie mit einer Priorität von 20 angefügt hat, gilt die Richtlinie von science\$1role, da sie eine höhere Priorität von 30 hat.
+ Um eine DDM-Richtlinie für eine Tabelle von einem oder mehreren Benutzern oder Rollen zu trennen, verwenden Sie den Befehl [TRENNEN EINER MASKIERUNGSRICHTLINIE](r_DETACH_MASKING_POLICY.md).
Im Folgenden finden Sie ein Beispiel für das Trennen einer Maskierungsrichtlinie von einem Paar. column/role
```
DETACH MASKING POLICY hash_credit
ON credit_cards(credit_card)
FROM ROLE science_role;
```
+ Um eine DDM-Richtlinie aus allen Datenbanken zu löschen, verwenden Sie den Befehl [ENTFERNEN EINER MASKIERUNGSRICHTLINIE](r_DROP_MASKING_POLICY.md)
Im Folgenden finden Sie ein Beispiel für das Löschen einer Maskierungsrichtlinie aus allen Datenbanken.
```
DROP MASKING POLICY hash_credit;
```
# Hierarchie der dynamischen Datenmaskierungsrichtlinien
Beachten Sie beim Anfügen mehrerer Maskierungsrichtlinien die folgenden Überlegungen:
+ Sie können mehrere Maskierungsrichtlinien an eine einzelne Spalte anfügen.
+ Wenn mehrere Maskierungsrichtlinien für eine Abfrage anwendbar sind, gilt die Richtlinie mit der höchsten Priorität, die der jeweiligen Spalte anfügt ist. Betrachten Sie das folgende Beispiel.
```
ATTACH MASKING POLICY partial_hash
ON credit_cards(address, credit_card)
TO ROLE analytics_role
PRIORITY 20;
ATTACH MASKING POLICY full_hash
ON credit_cards(credit_card, ssn)
TO ROLE auditor_role
PRIORITY 30;
SELECT address, credit_card, ssn
FROM credit_cards;
```
Beim Ausführen der SELECT-Anweisung wird Benutzern mit Analyse- und Auditorrolle die Adressspalte mit angewendeter Maskierungsrichtlinie `partial_hash` angezeigt. Sie sehen die Spalten „Credit Card“ (Kreditkarte) und „SSN“, auf die die Maskierungsrichtlinie `full_hash` angewendet wurde, da die Richtline `full_hash` in der Spalte „Credit Card“ (Kreditkarte) die höhere Priorität hat.
+ Wenn Sie beim Anfügen einer Maskierungsrichtlinie keine Priorität angeben, lautet die Standardpriorität 0.
+ Sie können derselben Spalte nicht zwei Richtlinien mit derselben Priorität zuordnen.
+ Sie können nicht derselben Kombination aus Benutzer und Spalte oder Rolle und Spalte zwei Richtlinien zuordnen.
+ Wenn mehrere Maskierungsrichtlinien auf demselben SUPER-Pfad angewendet werden können, obwohl sie demselben Benutzer oder derselben Rolle zugeordnet sind, wird nur der Anhang mit der höchsten Priorität wirksam. Betrachten Sie die folgenden Beispiele:
Das erste Beispiel zeigt zwei Maskierungsrichtlinien, die demselben Pfad zugeordnet sind, wobei die Richtlinie mit der höheren Priorität wirksam wird.
```
ATTACH MASKING POLICY hide_name
ON employees(col_person.name)
TO PUBLIC
PRIORITY 20;
ATTACH MASKING POLICY hide_last_name
ON employees(col_person.name.last)
TO PUBLIC
PRIORITY 30;
--Only the hide_last_name policy takes effect.
SELECT employees.col_person.name FROM employees;
```
Das zweite Beispiel zeigt zwei Maskierungsrichtlinien, die unterschiedlichen Pfaden im selben SUPER-Objekt zugeordnet sind, ohne dass es zu Konflikten zwischen den Richtlinien kommt. Beide Anhänge sind gleichzeitig gültig.
```
ATTACH MASKING POLICY hide_first_name
ON employees(col_person.name.first)
TO PUBLIC
PRIORITY 20;
ATTACH MASKING POLICY hide_last_name
ON employees(col_person.name.last)
TO PUBLIC
PRIORITY 20;
--Both col_person.name.first and col_person.name.last are masked.
SELECT employees.col_person.name FROM employees;
```
Um zu überprüfen, welche Maskierungsrichtlinie für einen bestimmten Benutzer und eine bestimmte Spalte oder eine Kombination aus Rolle und Spalte gilt, können Benutzer mit dieser [https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html)Rolle das Paar column/role oder Spalte/Benutzer in der Systemansicht nachschlagen. [SVV\$1ATTACHED\$1MASKING\$1POLICY](r_SVV_ATTACHED_MASKING_POLICY.md) Weitere Informationen finden Sie unter [Systemansichten für dynamische Datenmaskierung](r_ddm-svv.md).
# Verwendung dynamischer Datenmaskierung mit Pfaden des Datentyps SUPER
Amazon Redshift unterstützt das Anfügen dynamischer Datenmaskierungsrichtlinien an Pfade von Spalten des Typs SUPER. Weitere Informationen zum SUPER-Datentyp finden Sie unter [Halbstrukturierte Daten in Amazon Redshift](super-overview.md).
Beachten Sie beim Anfügen von Maskierungsrichtlinien an Pfade von Spalten des Typs SUPER Folgendes.
+ Beim Anfügen einer Maskierungsrichtlinie an einen Pfad in einer Spalte muss diese Spalte mit dem Datentyp SUPER definiert werden. Sie können Maskierungsrichtlinien nur auf *Skalarwerte* im SUPER-Pfad anwenden. Sie können Maskierungsrichtlinien nicht auf komplexe Strukturen oder Arrays anwenden.
+ Sie können unterschiedliche Maskierungsrichtlinien auf mehrere Skalarwerte in einer einzelnen SUPER-Spalte anwenden, sofern die SUPER-Pfade nicht miteinander in Konflikt stehen. Beispielsweise stehen die SUPER-Pfade `a.b` in `a.b.c` Konflikt, weil sie sich auf demselben Pfad befinden, wobei `a.b` das übergeordnete Element von `a.b.c` ist. Die SUPER-Pfade `a.b.c` und `a.b.d` stehen nicht im Konflikt.
+ Amazon Redshift kann erst überprüfen, ob die Pfade, denen eine Maskierungsrichtlinie angefügt wird, in den Daten existieren und den erwarteten Typ haben, wenn die Richtlinie zur Laufzeit der Benutzerabfrage angewendet wird. Wenn Sie beispielsweise eine Maskierungsrichtlinie anfügen, die TEXT-Werte mit einem SUPER-Pfad maskiert, der einen INT-Wert enthält, versucht Amazon Redshift, den Typ des Werts in dem Pfad umzuwandeln.
In solchen Situationen hängt das Verhalten von Amazon Redshift zur Laufzeit von Ihren Konfigurationseinstellungen für die Abfrage von SUPER-Objekten ab. Standardmäßig befindet sich Amazon Redshift im Lax-Modus und löst fehlende Pfade und ungültige Umwandlungen wie beim angegebenen `NULL` für den SUPER-Pfad auf. Weitere Informationen zu den Konfigurationseinstellungen im Zusammenhang mit SUPER finden Sie unter [SUPER-Konfigurationen](super-configurations.md).
+ SUPER ist ein Typ ohne Schema, was bedeutet, dass Amazon Redshift die Existenz des Werts in einem bestimmten SUPER-Pfad nicht bestätigen kann. Wenn Sie eine Maskierungsrichtlinie an einen SUPER-Pfad anfügen, der nicht existiert, und Amazon Redshift sich im Lax-Modus befindet, löst Amazon Redshift den Pfad zu einem `NULL`-Wert auf. Wir empfehlen, das erwartete Format von SUPER-Objekten und die Wahrscheinlichkeit, dass sie unerwartete Attribute aufweisen, zu berücksichtigen, wenn Sie Maskierungsrichtlinien an Pfade von SUPER-Spalten anfügen. Wenn Sie vermuten, dass Ihre SUPER-Spalte ein unerwartetes Schema enthält, sollten Sie erwägen, Ihre Maskierungsrichtlinien direkt an die SUPER-Spalte anzufügen. Sie können die Informationsfunktionen vom Typ SUPER verwenden, um Attribute und Typen zu überprüfen und um mit `OBJECT_TRANSFORM` die Werte zu maskieren. Weitere Informationen zu SUPER-Informationsfunktionen finden Sie unter [Funktionen für SUPER-Typinformationen](c_Type_Info_Functions.md).
## Beispiele
**Anfügen von Maskierungsrichtlinien an SUPER-Pfade**
Im folgenden Beispiel werden mehrere Maskierungsrichtlinien an mehrere SUPER-Pfade in einer Spalte angefügt.
```
CREATE TABLE employees (
col_person SUPER
);
INSERT INTO employees
VALUES
(
json_parse('
{
"name": {
"first": "John",
"last": "Doe"
},
"age": 25,
"ssn": "111-22-3333",
"company": "Company Inc."
}
')
),
(
json_parse('
{
"name": {
"first": "Jane",
"last": "Appleseed"
},
"age": 34,
"ssn": "444-55-7777",
"company": "Organization Org."
}
')
)
;
GRANT ALL ON ALL TABLES IN SCHEMA "public" TO PUBLIC;
-- Create the masking policies.
-- This policy converts the given name to all uppercase letters.
CREATE MASKING POLICY mask_first_name
WITH(first_name TEXT)
USING ( UPPER(first_name) );
-- This policy replaces the given name with the fixed string 'XXXX'.
CREATE MASKING POLICY mask_last_name
WITH(last_name TEXT)
USING ( 'XXXX'::TEXT );
-- This policy rounds down the given age to the nearest 10.
CREATE MASKING POLICY mask_age
WITH(age INT)
USING ( (FLOOR(age::FLOAT / 10) * 10)::INT );
-- This policy converts the first five digits of the given SSN to 'XXX-XX'.
CREATE MASKING POLICY mask_ssn
WITH(ssn TEXT)
USING ( 'XXX-XX-'::TEXT || SUBSTRING(ssn::TEXT FROM 8 FOR 4) );
-- Attach the masking policies to the employees table.
ATTACH MASKING POLICY mask_first_name
ON employees(col_person.name.first)
TO PUBLIC;
ATTACH MASKING POLICY mask_last_name
ON employees(col_person.name.last)
TO PUBLIC;
ATTACH MASKING POLICY mask_age
ON employees(col_person.age)
TO PUBLIC;
ATTACH MASKING POLICY mask_ssn
ON employees(col_person.ssn)
TO PUBLIC;
-- Verify that your masking policies are attached.
SELECT
policy_name,
TABLE_NAME,
priority,
input_columns,
output_columns
FROM
svv_attached_masking_policy;
policy_name | table_name | priority | input_columns | output_columns
-----------------+------------+----------+-----------------------------------+-----------------------------------
mask_age | employees | 0 | ["col_person.\"age\""] | ["col_person.\"age\""]
mask_first_name | employees | 0 | ["col_person.\"name\".\"first\""] | ["col_person.\"name\".\"first\""]
mask_last_name | employees | 0 | ["col_person.\"name\".\"last\""] | ["col_person.\"name\".\"last\""]
mask_ssn | employees | 0 | ["col_person.\"ssn\""] | ["col_person.\"ssn\""]
(4 rows)
-- Observe the masking policies taking effect.
SELECT col_person FROM employees ORDER BY col_person.age;
-- This result is formatted for ease of reading.
col_person
--------------------------------
{
"name": {
"first": "JOHN",
"last": "XXXX"
},
"age": 20,
"ssn": "XXX-XX-3333",
"company": "Company Inc."
}
{
"name": {
"first": "JANE",
"last": "XXXX"
},
"age": 30,
"ssn": "XXX-XX-7777",
"company": "Organization Org."
}
```
Im Folgenden finden Sie einige Beispiele für ungültige Maskierungsrichtlinien-Anhänge an SUPER-Pfade.
```
-- This attachment fails because there is already a policy
-- with equal priority attached to employees.name.last, which is
-- on the same SUPER path as employees.name.
ATTACH MASKING POLICY mask_ssn
ON employees(col_person.name)
TO PUBLIC;
ERROR: DDM policy "mask_last_name" is already attached on relation "employees" column "col_person."name"."last"" with same priority
-- Create a masking policy that masks DATETIME objects.
CREATE MASKING POLICY mask_date
WITH(INPUT DATETIME)
USING ( INPUT );
-- This attachment fails because SUPER type columns can't contain DATETIME objects.
ATTACH MASKING POLICY mask_date
ON employees(col_person.company)
TO PUBLIC;
ERROR: cannot attach masking policy for output of type "timestamp without time zone" to column "col_person."company"" of type "super
```
Im Folgenden finden Sie ein Beispiel für das Anfügen einer Maskierungsrichtlinie an einen SUPER-Pfad, der nicht existiert. Standardmäßig löst Amazon Redshift den Pfad zu `NULL` auf.
```
ATTACH MASKING POLICY mask_first_name
ON employees(col_person.not_exists)
TO PUBLIC;
SELECT col_person FROM employees LIMIT 1;
-- This result is formatted for ease of reading.
col_person
-----------------------------------
{
"name": {
"first": "JOHN",
"last": "XXXX"
},
"age": 20,
"ssn": "XXX-XX-3333",
"company": "Company Inc.",
"not_exists": null
}
```
# Bedingte dynamische Datenmaskierung
Sie können Daten auf Zellenebene maskieren, indem Sie Maskierungsrichtlinien mit bedingten Ausdrücken im Maskierungsausdruck erstellen. So können Sie beispielsweise eine Maskierungsrichtlinie erstellen, die abhängig vom Wert einer anderen Spalte in dieser Zeile unterschiedliche Masken auf einen Wert anwendet.
Im Folgenden finden Sie ein Beispiel für die Verwendung der bedingten Datenmaskierung, um eine Maskierungsrichtlinie zu erstellen und anzufügen, die in Betrugsfälle verwickelte Kreditkartennummern teilweise unkenntlich, während alle anderen Kreditkartennummern vollständig ausgeblendet werden. Für die Durchführung dieses Beispiels müssen Sie Superuser sein oder über die Rolle [https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html) verfügen.
```
--Create an analyst role.
CREATE ROLE analyst;
--Create a credit card table. The table contains an is_fraud boolean column,
--which is TRUE if the credit card number in that row was involved in a fraudulent transaction.
CREATE TABLE credit_cards (id INT, is_fraud BOOLEAN, credit_card_number VARCHAR(16));
--Create a function that partially redacts credit card numbers.
CREATE FUNCTION REDACT_CREDIT_CARD (credit_card VARCHAR(16))
RETURNS VARCHAR(16) IMMUTABLE
AS $$
import re
regexp = re.compile("^([0-9]{6})[0-9]{5,6}([0-9]{4})")
match = regexp.search(credit_card)
if match != None:
first = match.group(1)
last = match.group(2)
else:
first = "000000"
last = "0000"
return "{}XXXXX{}".format(first, last)
$$ LANGUAGE plpythonu;
--Create a masking policy that partially redacts credit card numbers if the is_fraud value for that row is TRUE,
--and otherwise blanks out the credit card number completely.
CREATE MASKING POLICY card_number_conditional_mask
WITH (fraudulent BOOLEAN, pan varchar(16))
USING (CASE WHEN fraudulent THEN REDACT_CREDIT_CARD(pan)
ELSE Null
END);
--Attach the masking policy to the credit_cards/analyst table/role pair.
ATTACH MASKING POLICY card_number_conditional_mask ON credit_cards (credit_card_number)
USING (is_fraud, credit_card_number)
TO ROLE analyst PRIORITY 100;
```
# Systemansichten für dynamische Datenmaskierung
Superuser, Benutzer mit der `sys:operator`-Rolle und Benutzer mit der Berechtigung ACCESS SYSTEM TABLE können auf die folgenden DDM-bezogenen Systemansichten zugreifen.
+ [SVV\$1MASKING\$1POLICY](r_SVV_MASKING_POLICY.md)
Verwenden Sie SVV\$1MASKING\$1POLICY, um alle auf dem Cluster oder der Arbeitsgruppe erstellten Maskierungsrichtlinien anzuzeigen.
+ [SVV\$1ATTACHED\$1MASKING\$1POLICY](r_SVV_ATTACHED_MASKING_POLICY.md)
Verwenden Sie SVV\$1ATTACHED\$1MASKING\$1POLICY, um alle Relationen und Rollen/Benutzer mit angefügten Richtlinien in der aktuell verbundenen Datenbank anzuzeigen.
+ [SYS\$1APPLIED\$1MASKING\$1POLICY\$1LOG](SYS_APPLIED_MASKING_POLICY_LOG.md)
Verwenden Sie SYS\$1APPLIED\$1MASKING\$1POLICY\$1LOG, um die Anwendung von Maskierungsrichtlinien auf Abfragen zu verfolgen, die auf geschützte DDM-Relationen verweisen.
Im Folgenden finden Sie einige Beispiele für Informationen, die Sie mithilfe von Systemansichten finden können.
```
--Select all policies associated with specific users, as opposed to roles
SELECT policy_name,
schema_name,
table_name,
grantee
FROM svv_attached_masking_policy
WHERE grantee_type = 'user';
--Select all policies attached to a specific user
SELECT policy_name,
schema_name,
table_name,
grantee
FROM svv_attached_masking_policy
WHERE grantee = 'target_grantee_name'
--Select all policies attached to a given table
SELECT policy_name,
schema_name,
table_name,
grantee
FROM svv_attached_masking_policy
WHERE table_name = 'target_table_name'
AND schema_name = 'target_schema_name';
--Select the highest priority policy attachment for a given role
SELECT samp.policy_name,
samp.priority,
samp.grantee,
smp.policy_expression
FROM svv_masking_policy AS smp
JOIN svv_attached_masking_policy AS samp
ON samp.policy_name = smp.policy_name
WHERE
samp.grantee_type = 'role' AND
samp.policy_name = mask_get_policy_for_role_on_column(
'target_schema_name',
'target_table_name',
'target_column_name',
'target_role_name')
ORDER BY samp.priority desc
LIMIT 1;
--See which policy a specific user will see on a specific column in a given relation
SELECT samp.policy_name,
samp.priority,
samp.grantee,
smp.policy_expression
FROM svv_masking_policy AS smp
JOIN svv_attached_masking_policy AS samp
ON samp.policy_name = smp.policy_name
WHERE
samp.grantee_type = 'role' AND
samp.policy_name = mask_get_policy_for_user_on_column(
'target_schema_name',
'target_table_name',
'target_column_name',
'target_user_name')
ORDER BY samp.priority desc;
--Select all policies attached to a given relation.
SELECT policy_name,
schema_name,
relation_name,
database_name
FROM sys_applied_masking_policy_log
WHERE relation_name = 'relation_name'
AND schema_name = 'schema_name';
```
# Hinweise zur dynamischen Datenmaskierung
Bei Verwendung der dynamischen Datenmaskierung ist Folgendes zu beachten:
+ Beim Abfragen von Objekten, die aus Tabellen erstellt wurden, wie z. B. Ansichten, werden den Benutzern Ergebnisse auf der Grundlage ihrer eigenen Maskierungsrichtlinien angezeigt, nicht basierend auf den Richtlinien des Benutzers, der die Objekte erstellt hat. Einem Benutzer mit der Analystenrolle, der eine von einem Benutzer mit der Rolle „secadmin“ erstellte Ansicht abfragt, würden beispielsweise Ergebnisse mit Maskierungsrichtlinien angezeigt, die der Analystenrolle angefügt sind.
+ Damit bei Verwendung des Befehls EXPLAIN keine sensiblen Maskierungsrichtlinienfilter offengelegt werden, können nur Benutzer mit der Berechtigung SYS\$1EXPLAIN\$1DDM Maskierungsrichtlinien sehen, die in EXPLAIN-Ausgaben angewendet wurden. Standardmäßig verfügen Benutzer nicht über die Berechtigung SYS\$1EXPLAIN\$1DDM.
Nachfolgend sehen Sie die Syntax zum Gewähren der Berechtigung für einen Benutzer oder eine Rolle.
```
GRANT EXPLAIN MASKING TO ROLE rolename
```
Weitere Informationen zum Befehl EXPLAIN finden Sie unter [EXPLAIN](r_EXPLAIN.md).
+ Benutzer mit unterschiedlichen Rollen können je nach verwendeten Filter- oder Join-Bedingungen unterschiedliche Ergebnisse sehen. So schlägt beispielsweise die Ausführung eines Befehls SELECT für eine Tabelle mit einem bestimmten Spaltenwert fehl, wenn für den Benutzer, der den Befehl ausführt, eine Maskierungsrichtlinie angewendet wurde, die diese Spalte verschleiert.
+ DDM-Richtlinien müssen vor allen Prädikatoperationen oder Projektionen angewendet werden. Die Maskierungsrichtlinien können Folgendes beinhalten:
+ Kostengünstige konstante Operationen wie die Umwandlung eines Werts in Null
+ Operationen zu moderaten Kosten wie HMAC-Hashing
+ Kostenintensive Operationen wie Aufrufe externer benutzerdefinierter Lambda-Funktionen
Daher empfehlen wir, wenn möglich einfache Maskierungsausdrücke zu verwenden.
+ Sie können DDM-Richtlinien für Rollen mit Sicherheitsrichtlinien auf Zeilenebene verwenden. Beachten Sie jedoch, dass RLS-Richtlinien vor DDM angewendet werden. Ein Ausdruck für die dynamische Datenmaskierung ist nicht in der Lage, eine Zeile zu lesen, die durch RLS geschützt wurde. Weitere Informationen zu RLS finden Sie unter [Sicherheit auf Zeilenebene](t_rls.md).
+ Wenn Sie den Befehl [COPY](r_COPY.md) zum Kopieren aus Parquet in geschützte Zieltabellen verwenden, sollten Sie in der COPY-Anweisung explizit Spalten angeben. Weitere Informationen zur Zuordnung von Spalten mit COPY finden Sie unter [Optionen für das Mapping von Spalten](copy-parameters-column-mapping.md).
+ DDM-Richtlinien können nicht an die folgenden Relationen angefügt werden:
+ Systemtabellen und Kataloge
+ Externe Tabellen
+ Datasharing-Tabellen
+ Datenbankübergreifende Relationen
+ Temporäre Tabellen
+ Korrelierte Abfragen
+ DDM-Richtlinien können Suchtabellen enthalten. Suchtabellen können in der USING-Klausel enthalten sein. Die folgenden Relationstypen können nicht als Suchtabellen verwendet werden:
+ Systemtabellen und Kataloge
+ Externe Tabellen
+ Datasharing-Tabellen
+ Ansichten, materialisierte Ansichten und Late-Binding-Ansichten.
+ Datenbankübergreifende Relationen
+ Temporäre Tabellen
+ Korrelierte Abfragen
Im Folgenden finden Sie ein Beispiel für das Anfügen einer Maskierungsrichtlinie an eine Suchtabelle.
```
--Create a masking policy referencing a lookup table
CREATE MASKING POLICY lookup_mask_credit_card WITH (credit_card TEXT) USING (
CASE
WHEN
credit_card IN (SELECT credit_card_lookup FROM credit_cards_lookup)
THEN '000000XXXX0000'
ELSE REDACT_CREDIT_CARD(credit_card)
END
);
--Provides access to the lookup table via a policy attached to a role
GRANT SELECT ON TABLE credit_cards_lookup TO MASKING POLICY lookup_mask_credit_card;
```
+ Sie können keine Maskierungsrichtlinie anfügen, die zu einer mit dem Typ und der Größe der Zielspalte nicht kompatiblen Ausgabe führen würde. So können Sie beispielsweise keine Maskierungsrichtlinie anfügen, die eine 12-stellige Zeichenfolge an eine VARCHAR (10)-Spalte ausgibt. Amazon Redshift unterstützt die folgenden Ausnahmen:
+ Eine Maskierungsrichtlinie mit dem Eingabetyp INTN kann an eine Richtlinie mit der Größe INTM angehängt werden, solange M < N ist. Beispielsweise kann eine BIGINT (INT8) -Eingaberichtlinie an eine smallint () -Spalte angehängt werden. INT4
+ Eine Maskierungsrichtlinie mit dem Eingabetyp NUMERIC oder DECIMAL kann immer an eine FLOAT-Spalte angefügt werden.
+ DDM-Richtlinien können nicht für die Freigabe von Daten verwendet werden. Wenn der Produzent der Datashare-Daten eine DDM-Richtlinie an eine Tabelle im Datashare anfügt, können Benutzer des Datenkonsumenten, die versuchen, die Tabelle abzufragen, nicht mehr auf die Tabelle zugreifen. Der Versuch, die Beziehung zu einem Datashare hinzuzufügen, schlägt auf dem produzentenseitigen Cluster oder Namespace mit dem folgenden Fehler fehl:
```
or a relation dependent on it is protected by a masking policy and cannot be added to a datashare
```
Wenn Sie eine Maskierungsrichtlinie an eine Beziehung auf Produzentenseite anhängen und die Beziehung bereits in einem Datashare enthalten ist, schlägt der Versuch, die Beziehung auf der Verbraucherseite abzufragen, mit dem folgenden Fehler fehl:
```
cross-cluster query of the masked relation is not supported.
```
Sie können DDM für Datashares deaktivieren, indem Sie den Befehl ALTER TABLE mit dem Parameter MASKING OFF FOR DATASHARES verwenden. Weitere Informationen finden Sie unter [ALTER TABLE](r_ALTER_TABLE.md).
+ Sie können keine Beziehungen abfragen, für über angefügte DDM-Richtlinien verfügen, wenn Ihre Werte für eine der folgenden Konfigurationsoptionen nicht dem Standardwert der Sitzung entsprechen:
+ `enable_case_sensitive_super_attribute`
+ `enable_case_sensitive_identifier`
+ `downcase_delimited_identifier`
Erwägen Sie, die Konfigurationsoptionen Ihrer Sitzung zurückzusetzen, wenn Sie versuchen, eine Beziehung mit einer angefügten DDM-Richtlinie abzufragen und die Meldung „Die DDM-geschützte Beziehung unterstützt keine Konfiguration auf Sitzungsebene, da die Berücksichtigung von Groß- und Kleinschreibung vom Standardwert abweicht“ angezeigt wird.
+ Wenn Ihr bereitgestellter Cluster oder Serverless-Namespace über Richtlinien zur dynamischen Datenmaskierung verfügt, werden die folgenden Befehle für normale Benutzer blockiert:
```
ALTER SET enable_case_sensitive_super_attribute/enable_case_sensitive_identifier/downcase_delimited_identifier
```
Wenn Sie DDM-Richtlinien erstellen, empfehlen wir, die Einstellungen der Standardkonfigurationsoptionen für normale Benutzer so zu ändern, dass sie den Einstellungen der Sitzungskonfigurationsoptionen zum Zeitpunkt der Erstellung der Richtlinie entsprechen. Superuser und Benutzer mit der Berechtigung ALTER USER können dies mithilfe von Parametergruppeneinstellungen oder dem Befehl ALTER USER erreichen. Informationen zu Parametergruppen finden Sie unter [Amazon-Redshift-Parametergruppen](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html) im *Amazon-Redshift-Verwaltungshandbuch*. Informationen zum Befehl ALTER USER finden Sie unter [ALTER USER](r_ALTER_USER.md).
+ Ansichten und Late-Binding-Ansichten mit DDM-Richtlinien auf Zeilenebene können nicht von normalen Benutzern mit dem Befehl [CREATE VIEW](r_CREATE_VIEW.md) ersetzt werden. Um Ansichten oder durch DDM-Richtlinien zu ersetzen, trennen Sie zunächst alle LBVs mit ihnen verknüpften DDM-Richtlinien, ersetzen Sie die Ansichten oder und fügen Sie die Richtlinien erneut an. LBVs Superuser und Benutzer mit der entsprechenden `sys:secadmin` Berechtigung können CREATE VIEW für Ansichten oder LBVs mit DDM-Richtlinien verwenden, ohne die Richtlinien zu trennen.
+ Ansichten mit angefügten DDM-Richtlinien können nicht auf Systemtabellen und Ansichten verweisen. Late-Binding-Ansichten können auf Systemtabellen und Ansichten verweisen.
+ Late-Binding-Ansichten mit angefügten DDM-Richtlinien können nicht auf verschachtelte Daten in Data Lakes verweisen, wie z. B. JSON-Dokumente.
+ Late-Binding-Ansichten können keine DDM-Richtlinien angefügt werden, wenn die Late-Binding-Ansicht von einer Ansicht referenziert wird.
+ DDM-Richtlinien, die an Late-Binding-Ansichten angefügt sind, werden anhand des Spaltennamens angefügt. Bei der Abfrage überprüft Amazon Redshift, ob alle Maskierungsrichtlinien, die an die Late-Binding-Ansicht angefügt sind, erfolgreich angewendet wurden und ob der Ausgabespaltentyp der Late-Binding-Ansicht mit den Typen in den angefügten Maskierungsrichtlinien übereinstimmt. Wenn die Überprüfung fehlschlägt, gibt Amazon Redshift einen Fehler für die Abfrage zurück.
+ Sie können benutzerdefinierte Sitzungskontextvariablen verwenden, wenn Sie DDM-Richtlinien erstellen. Im folgenden Beispiel werden Sitzungskontextvariablen für eine DDM-Richtlinie festgelegt.
```
-- Set a customized context variable.
SELECT set_config('app.city', 'XXXX', FALSE);
-- Create a MASKING policy using current_setting() to get the value of a customized context variable.
CREATE MASKING POLICY city_mask
WITH (city VARCHAR(30))
USING (current_setting('app.city')::VARCHAR(30));
-- Attach the policy on the target table to one or more roles.
ATTACH MASKING POLICY city_mask
ON tickit_users_redshift(city)
TO ROLE analyst, ROLE dbadmin;
```
Einzelheiten zum Festlegen und Abrufen angepasster Sitzungskontextvariablen finden Sie unter [SET](r_SET.md), [SET\$1CONFIG](r_SET_CONFIG.md), [ZEIGEN](r_SHOW.md), [CURRENT\$1SETTING](r_CURRENT_SETTING.md) und [RESET](r_RESET.md). Weitere Informationen zum Ändern der Serverkonfiguration im Allgemeinen finden Sie unter [Modifizieren der Serverkonfiguration](cm_chap_ConfigurationRef.md#t_Modifying_the_default_settings).
**Wichtig**
Bei der Verwendung von Sitzungskontextvariablen innerhalb von DDM-Richtlinien ist die Sicherheitsrichtlinie von dem Benutzer oder der Rolle abhängig, der/die die Richtlinie aufruft. Achten Sie darauf, Schwachstellen zu vermeiden, wenn Sie Sitzungskontextvariablen in DDM-Richtlinien verwenden.
# Beispiel für dynamische Datenmaskierung end-to-end
Das folgende end-to-end Beispiel zeigt, wie Sie Maskierungsrichtlinien erstellen und an eine Spalte anhängen können. Diese Richtlinien ermöglichen es Benutzern, auf eine Spalte zuzugreifen und unterschiedliche Werte zu sehen, je nachdem, welcher Grad der Verschleierung in den ihren Rollen zugeordneten Richtlinien festgelegt ist. Für die Durchführung dieses Beispiels müssen Sie Superuser sein oder über die Rolle [https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html) verfügen.
## Erstellen einer Maskierungsrichtlinie
Erstellen Sie zunächst eine Tabelle und füllen Sie sie mit Kreditkartenwerten.
```
--create the table
CREATE TABLE credit_cards (
customer_id INT,
credit_card TEXT
);
--populate the table with sample values
INSERT INTO credit_cards
VALUES
(100, '4532993817514842'),
(100, '4716002041425888'),
(102, '5243112427642649'),
(102, '6011720771834675'),
(102, '6011378662059710'),
(103, '373611968625635')
;
--run GRANT to grant permission to use the SELECT statement on the table
GRANT SELECT ON credit_cards TO PUBLIC;
--create two users
CREATE USER regular_user WITH PASSWORD '1234Test!';
CREATE USER analytics_user WITH PASSWORD '1234Test!';
--create the analytics_role role and grant it to analytics_user
--regular_user does not have a role
CREATE ROLE analytics_role;
GRANT ROLE analytics_role TO analytics_user;
```
Erstellen Sie dann eine Maskierungsrichtlinie, die auf die Analyserolle angewendet werden soll.
```
--create a masking policy that fully masks the credit card number
CREATE MASKING POLICY mask_credit_card_full
WITH (credit_card VARCHAR(256))
USING ('000000XXXX0000'::TEXT);
--create a user-defined function that partially obfuscates credit card data
CREATE FUNCTION REDACT_CREDIT_CARD (credit_card TEXT)
RETURNS TEXT IMMUTABLE
AS $$
import re
regexp = re.compile("^([0-9]{6})[0-9]{5,6}([0-9]{4})")
match = regexp.search(credit_card)
if match != None:
first = match.group(1)
last = match.group(2)
else:
first = "000000"
last = "0000"
return "{}XXXXX{}".format(first, last)
$$ LANGUAGE plpythonu;
--create a masking policy that applies the REDACT_CREDIT_CARD function
CREATE MASKING POLICY mask_credit_card_partial
WITH (credit_card VARCHAR(256))
USING (REDACT_CREDIT_CARD(credit_card));
--confirm the masking policies using the associated system views
SELECT * FROM svv_masking_policy;
SELECT * FROM svv_attached_masking_policy;
```
## Anfügen einer Maskierungsrichtlinie
Fügen Sie die Maskierungsrichtlinien der Kreditkartentabelle an.
```
--attach mask_credit_card_full to the credit card table as the default policy
--all users will see this masking policy unless a higher priority masking policy is attached to them or their role
ATTACH MASKING POLICY mask_credit_card_full
ON credit_cards(credit_card)
TO PUBLIC;
--attach mask_credit_card_partial to the analytics role
--users with the analytics role can see partial credit card information
ATTACH MASKING POLICY mask_credit_card_partial
ON credit_cards(credit_card)
TO ROLE analytics_role
PRIORITY 10;
--confirm the masking policies are applied to the table and role in the associated system view
SELECT * FROM svv_attached_masking_policy;
--confirm the full masking policy is in place for normal users by selecting from the credit card table as regular_user
SET SESSION AUTHORIZATION regular_user;
SELECT * FROM credit_cards;
--confirm the partial masking policy is in place for users with the analytics role by selecting from the credit card table as analytics_user
SET SESSION AUTHORIZATION analytics_user;
SELECT * FROM credit_cards;
```
## Ändern einer Maskierungsrichtlinie
Der folgende Abschnitt veranschaulicht die Änderung einer Richtlinie für die dynamische Datenmaskierung.
```
--reset session authorization to the default
RESET SESSION AUTHORIZATION;
--alter the mask_credit_card_full policy
ALTER MASKING POLICY mask_credit_card_full
USING ('00000000000000'::TEXT);
--confirm the full masking policy is in place after altering the policy, and that results are altered from '000000XXXX0000' to '00000000000000'
SELECT * FROM credit_cards;
```
## Trennen und Löschen einer Maskierungsrichtlinie
Im folgenden Abschnitt wird gezeigt, wie Sie Maskierungsrichtlinien trennen und löschen, indem Sie alle Richtlinien für die dynamische Datenmaskierung aus der Tabelle entfernen.
```
--reset session authorization to the default
RESET SESSION AUTHORIZATION;
--detach both masking policies from the credit_cards table
DETACH MASKING POLICY mask_credit_card_full
ON credit_cards(credit_card)
FROM PUBLIC;
DETACH MASKING POLICY mask_credit_card_partial
ON credit_cards(credit_card)
FROM ROLE analytics_role;
--drop both masking policies
DROP MASKING POLICY mask_credit_card_full;
DROP MASKING POLICY mask_credit_card_partial;
```
# Bereichsbeschränkte Berechtigungen
Mit bereichsbezogenen Berechtigungen können Sie einem Benutzer oder einer Rolle Berechtigungen für alle Objekte eines Typs innerhalb einer Datenbank oder eines Schemas gewähren. Benutzer und Rollen mit bereichsbezogenen Berechtigungen verfügen über die angegebenen Berechtigungen für alle aktuellen und künftigen Objekte innerhalb der Datenbank oder des Schemas.
Den Umfang der bereichsbezogenen Berechtigungen auf Datenbankebene finden Sie unter [SVV\$1DATABASE\$1PRIVILEGES](r_SVV_DATABASE_PRIVILEGES.md). Den Umfang der bereichsbezogenen Berechtigungen auf Schemaebene finden Sie unter [SVV\$1SCHEMA\$1PRIVILEGES](r_SVV_SCHEMA_PRIVILEGES.md).
Weitere Informationen zum Anwenden bereichsbezogener Berechtigungen finden Sie unter [GRANT](r_GRANT.md) und [REVOKE](r_REVOKE.md).
# Überlegungen zur Verwendung bereichsbezogener Berechtigungen
Beachten Sie bei der Verwendung bereichsbezogener Berechtigungen die folgenden Überlegungen:
+ Sie können bereichsbezogene Berechtigungen verwenden, um einem ausgewählten Benutzer oder einer ausgewählten Rolle Berechtigungen für einen Datenbank- oder Schemabereich zu gewähren oder zu widerrufen.
+ Sie können Benutzergruppen keine bereichsbezogenen Berechtigungen erteilen.
+ Durch das Gewähren oder Widerrufen bereichsbezogener Berechtigungen werden die Berechtigungen für alle derzeitigen und zukünftigen Objekte im Gültigkeitsbereich geändert.
+ Bereichsbezogene Berechtigungen gelten unabhängig von Berechtigungen auf Objektebene. Beispielsweise behält ein Benutzer in den beiden folgenden Fällen die Berechtigungen für eine Tabelle.
+ Dem Benutzer wird die SELECT-Berechtigung für die Tabelle schema1.table1 und die SELECT-Berechtigung für schema1 erteilt. Dem Benutzer wurde dann die SELECT-Berechtigung für alle Tabellen im Schema schema1 entzogen. Der Benutzer behält SELECT für schema1.table1 bei.
+ Dem Benutzer wird die SELECT-Berechtigung für die Tabelle schema1.table1 und die SELECT-Berechtigung für schema1 erteilt. Dem Benutzer wurde dann SELECT für schema1.table1 entzogen. Der Benutzer behält SELECT für schema1.table1 bei.
+ Um bereichsbezogene Berechtigungen zu gewähren oder zu widerrufen, müssen Sie mindestens eines der folgenden Kriterien erfüllen:
+ Superuser.
+ Benutzer mit der Option „Gewähren“ für diese Berechtigung. Weitere Informationen zu Gewährungsoptionen finden Sie unter dem Parameter WITH GRANT OPTION in [GRANT](r_GRANT.md).
+ Bereichsbezogene Berechtigungen können nur Objekten für die verbundene Datenbank oder für Datenbanken, die aus einem Datashare importiert wurden, gewährt oder entzogen werden.
+ Sie können bereichsbezogene Berechtigungen verwenden, um die Standardberechtigungen für eine Datenbank festzulegen, die aus einem Datashare erstellt wurde. Ein verbraucherseitiger Datashare-Benutzer, dem bereichsbezogene Berechtigungen für eine gemeinsam genutzte Datenbank gewährt werden, erhält diese Berechtigungen automatisch für jedes neue Objekt, das dem Datashare auf der Produzentenseite hinzugefügt wird.
+ Produzenten können einem Datashare bereichsbezogene Berechtigungen für Objekte innerhalb eines Schemas gewähren. (Vorschau)