Konfigurieren der Zugriffssteuerung

Unter diesem Thema wird beschrieben, wie Sie die Sicherheit auf Objektebene mit den vom System definierten Rollen (bereitgestellt von Snowflake) und benutzerdefinierten Rollen (optional) konfigurieren.

Unter diesem Thema:

Kontoadministration

Festlegen zusätzlicher Benutzer als Kontoadministratoren

Standardmäßig hat jedes Konto einen Benutzer, der als Kontoadministrator festgelegt wurde (d. h. der Benutzer hat die systemdefinierte ACCOUNTADMIN-Rolle erhalten). Wir empfehlen, mindestens einen weiteren Benutzer als Kontoadministrator zu bestimmen. Auf diese Weise wird sichergestellt, dass Ihr Konto immer mindestens einen Benutzer hat, der Aufgaben auf Kontoebene ausführen kann, insbesondere wenn sich einer Ihrer Kontoadministratoren nicht anmelden kann.

Für diese zusätzlichen Kontoadministratoren können Sie wählen, ob Sie neue Benutzer anlegen oder bestehende Benutzer benennen möchten. Achten Sie aber darauf, Folgendes anzugeben:

  • Gewähren Sie den Benutzern die ACCOUNTADMIN-Rolle, aber legen Sie diese Rolle nicht als Standard fest. Benennen Sie stattdessen eine untergeordnete administrative Rolle (z. B. SYSADMIN) oder eine benutzerdefinierte Rolle als Standard. Dadurch wird verhindert, dass Kontoadministratoren versehentlich die ACCOUNTADMIN-Rolle zum Erstellen von Objekten verwenden.

  • Stellen Sie sicher, dass für jeden Benutzer eine E-Mail-Adresse angegeben ist (erforderlich für die mehrstufige Authentifizierung).

Weisen Sie beispielsweise einem vorhandenen Benutzer mit dem Namen user2 die Rollen ACCOUNTADMIN und SYSADMIN zu, und geben Sie SYSADMIN als Standardrolle an:

GRANT ROLE ACCOUNTADMIN, SYSADMIN TO USER user2;

ALTER USER user2 SET EMAIL='user2@domain.com', DEFAULT_ROLE=SYSADMIN;

Aktivieren von MFA für jeden Kontoadministrator

Um die höchste Sicherheitsstufe für Ihr Snowflake-Konto sicherzustellen, empfehlen wir dringend, dass jeder Benutzer, der sensible Daten ändern oder anzeigen kann, zur Anmeldung die mehrstufige Authentifizierung (MFA) verwenden muss.

Diese Empfehlung gilt insbesondere für Benutzer mit der Rolle ACCOUNTADMIN, kann aber auch auf Benutzer mit den Rollen SECURITYADMIN und SYSADMIN ausgedehnt werden.

Weitere Details dazu finden Sie unter Hinweise zur Zugriffssteuerung und Mehrstufige Authentifizierung (MFA).

Erstellen einer Rollenhierarchie

Wenn Sie benutzerdefinierte Rollen erstellen, sollten Sie die Erstellung einer Rollenhierarchie in Betracht ziehen, die letztendlich einer Administratorrolle auf höchster Stufe zugeordnet ist. Im Allgemeinen funktioniert die Rolle SYSADMIN gut als Rolle, der alle anderen Rollen einer Hierarchie zugewiesen sind. Beachten Sie jedoch, dass jede Rolle mit ausreichenden Berechtigungen diese Funktion übernehmen könnte. Die SYSADMIN-Rolle ist eine vom System definierte Rolle, die über Berechtigungen verfügt, um Warehouses, Datenbanken und Datenbankobjekte in einem Konto zu erstellen und diese Berechtigungen anderen Rollen zu erteilen. In der Standardsystemhierarchie verwaltet die oberste Rolle ACCOUNTADMIN die Rolle des Systemadministrators.

Sie legen eine Rollenhierarchie an, indem Sie eine Rolle einer zweiten Rolle zuweisen. Sie können diese zweite Rolle dann einer dritten Rolle zuweisen. Die mit einer Rolle verbundenen Berechtigungen werden an alle Rollen vererbt, die in der Hierarchie über dieser Rolle liegen.

So können Sie beispielsweise eine benutzerdefinierte Rolle mit allen Berechtigungen für ein bestimmtes Schema erstellen:

  1. Erteilen Sie dieser Rolle die folgenden Berechtigungen:

    • USAGE für die Datenbank, die das Schema enthält.

    • ALL für das Schema, das die abzufragenden Tabellen enthält.

    • USAGE für ein Warehouse, das zur Ausführung von Abfragen auf die Tabellen im Schema verwendet wird.

  2. Erstellen Sie die Hierarchie der Rollen. Vergeben Sie die benutzerdefinierte Rolle an die SYSADMIN-Rolle. Die übergeordneten Rollen erben die Objektberechtigungen, die jeder untergeordneten Rolle zugeordnet sind.

  3. Vergeben Sie die benutzerdefinierte Rolle an jeden Benutzer, der die angegebenen Berechtigungen benötigt.

Jeder Benutzer mit der Rolle kann jedes beliebige Objekt im Schema erstellen und verwenden. Die folgende Abbildung veranschaulicht die Rollenhierarchie und die Berechtigungen, über die jede Rolle verfügt:

Role hierarchy and privileges granted to each role

Bemerkung

In den folgenden Abschnitten finden Sie eine schrittweise Anleitung zum Erstellen einer benutzerdefinierten Rolle namens custom in einer Basisrollenhierarchie. Diese custom-Rolle ermöglicht es Benutzern, Objekte in einem Schema zu erstellen und diese Objekte zu verwalten (als Objekteigentümer). Die Rolle hat keine Berechtigungen für bestehende Objekte im Schema, obwohl diese durch Erteilung von zusätzlichen Berechtigungen auf Schema- oder Objektebene vergeben werden können.

Führen Sie die SQL-Anweisungen in diesem Abschnitt als Benutzer mit der Rolle SECURITYADMIN (oder höher) aus.

Benutzerdefinierte Rolle erstellen

  1. Erstellen Sie die Rolle custom:

    CREATE ROLE custom
       COMMENT = 'This role has all privileges on schema_1';
    
  2. Erteilen Sie der Rolle custom die folgenden Objektberechtigungen:

    • USAGE für die Datenbank, die das Schema enthält (database_a). Um beliebige Objekte in einem Schema verwenden zu können, muss eine Rolle auch die Berechtigung USAGE für die Container-Datenbank haben.

    • ALL [ PRIVILEGES ] für das Schema (schema_1).

    • USAGE für das Warehouse, das für das Ausführen von Abfragen verwendet wird (warehouse_1). Benutzer mit dieser Rolle können auf diesem Warehouse Abfragen ausführen.

    GRANT USAGE
      ON DATABASE database_a
      TO ROLE custom;
    
    GRANT ALL
      ON SCHEMA database_a.schema_1
      TO ROLE custom;
    
    GRANT USAGE
      ON WAREHOUSE warehouse_1
      TO ROLE custom;
    

Rolle einer anderen Rolle zuweisen

Ordnen Sie die Rolle einer übergeordneten Rolle der Rollenhierarchie zu. In diesem Beispiel wird die Rolle custom der Rolle SYSADMIN zugewiesen. Die SYSADMIN-Rolle erbt alle Objektberechtigungen, die der Rolle custom erteilt wurden:

GRANT ROLE custom
   TO ROLE sysadmin;

Bemerkung

In einem komplexeren Beispiel können Sie die Rolle custom einer anderen untergeordneten Rolle von SYSADMIN (oder einer anderen Administratorrolle, z. B. einer benutzerdefinierten Rolle mit ausreichenden Berechtigungen zum Erstellen von Datenbanken) zuweisen. Die SYSADMIN-Rolle würde die kombinierten Berechtigungen erben, die der Rolle custom und seiner übergeordneten Rolle erteilt wurden. Wenn die Rolle, die sich in der Hierarchie über der Rolle custom befindet, irgendwelche Objekte besitzt, dann würde die Rollenhierarchie sicherstellen, dass Mitglieder der Rolle SYSADMIN auch diese Objekte (indirekt) besitzen und sie wie erwartet verwalten können.

Rolle einem Benutzer zuweisen

  1. Verwenden Sie die ALTER USER, um den zu ändernden Benutzer zu deaktivieren. Dadurch werden alle vorhandenen Sitzungen des Benutzers zwangsweise geschlossen, während Sie die Änderungen an diesem Benutzer vornehmen. Mit dem folgenden Befehl wird beispielsweise der Benutzer Bonnie Smith (bsmith) deaktiviert:

    ALTER USER bsmith SET DISABLED=TRUE;
    
  2. Weisen Sie die Rolle custom einem Benutzer zu:

    GRANT ROLE custom
       TO USER bsmith;
    
  3. Legen Sie die Standardrolle für den Benutzer fest. Der folgende Befehl definiert die Standardrolle für Benutzer Bonnie Smith:

    ALTER USER bsmith
       SET DEFAULT_ROLE = custom;
    
  4. Aktivieren Sie den Benutzer mit dem Befehl ALTER USER, damit sich der Benutzer wieder anmelden kann, jetzt mit der neuen Standardrolle. Beispiel:

    ALTER USER bsmith SET DISABLED=false;
    

Anzeigen der erteilten Berechtigungen

Um die aktuelle einem Objekt erteilten Berechtigungen anzuzeigen, können Sie den Befehl SHOW GRANTS ausführen. Um die aktuellen Berechtigungen für ein Schema anzuzeigen, führen Sie den folgenden Befehl aus:

SHOW GRANTS ON SCHEMA <database_name>.<schema_name>;

Führen Sie beispielsweise den folgenden Befehl aus, um die Berechtigungen für database_a.schema_1 anzuzeigen, die in Benutzerdefinierte Rolle erstellen erteilt wurden:

SHOW GRANTS ON SCHEMA database_a.schema_1;

Snowflake gibt die folgenden Ergebnisse zurück:

+-------------------------------+--------------------+------------+---------------------+------------+--------------+--------------+--------------+
| created_on                    | privilege          | granted_on | name                | granted_to | grantee_name | grant_option | granted_by   |
|-------------------------------+--------------------+------------+---------------------+------------+--------------+--------------+--------------|
| 2016-08-24 12:35:08.000 -0700 | OWNERSHIP          | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | SYSADMIN     | true         | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE FILE FORMAT | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE FUNCTION    | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE SEQUENCE    | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE STAGE       | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE TABLE       | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE VIEW        | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | MODIFY             | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | MONITOR            | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | USAGE              | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
+-------------------------------+--------------------+------------+---------------------+------------+--------------+--------------+--------------+

Sie können auch den Befehl SHOW GRANTS ausführen, um die Berechtigungen anzuzeigen, die eine Rolle aktuell besitzt, oder die Rollen, die einem Benutzer aktuell zugewiesen sind:

SHOW GRANTS TO ROLE <role_name>;
SHOW GRANTS TO USER <user_name>;

Führen Sie beispielsweise den folgenden Befehl aus, um die Berechtigungen anzuzeigen, die der Rolle custom erteilt wurden, die in Benutzerdefinierte Rolle erstellen erstellt wurde:

SHOW GRANTS TO ROLE custom;

Snowflake gibt die folgenden Ergebnisse zurück:

+-------------------------------+--------------------+------------+---------------------+------------+--------------+--------------+--------------+
| created_on                    | privilege          | granted_on | name                | granted_to | grantee_name | grant_option | granted_by   |
|-------------------------------+--------------------+------------+---------------------+------------+--------------+--------------+--------------|
| 2016-11-22 12:34:29.000 -0800 | USAGE              | DATABASE   | DATABASE_A          | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE FILE FORMAT | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE FUNCTION    | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE SEQUENCE    | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE STAGE       | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE TABLE       | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | CREATE VIEW        | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | MODIFY             | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | MONITOR            | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | USAGE              | SCHEMA     | DATABASE_A.SCHEMA_1 | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
| 2016-11-22 12:34:30.000 -0800 | USAGE              | WAREHOUSE  | WAREHOUSE_1         | ROLE       | CUSTOM       | false        | ACCOUNTADMIN |
+-------------------------------+--------------------+------------+---------------------+------------+--------------+--------------+--------------+

Bemerkung

Das Ausführen des Befehls SHOW GRANTS für ein bestimmtes Objekt erfordert die gleichen Objektberechtigungen wie das Ausführen des Befehls SHOW für diesen Objekttyp.

Das Ausführen des Befehls SHOW GRANTS auf einer Tabelle erfordert beispielsweise die folgenden Berechtigungen für die Tabelle sowie für die Container-Datenbank und das Schema:

Datenbank

USAGE

Schema

USAGE

Tabelle

jede Berechtigung

Erstellen von Nur-Lese-Rollen

Angenommen, Sie benötigen eine Rolle, die sich auf die Abfrage der Tabellen in einem bestimmten Schema beschränkt (z. B. database_a.schema_1). Benutzer, die Befehle mit dieser Rolle ausführen, können die Tabellendaten nicht aktualisieren, keine zusätzlichen Datenbankobjekte erstellen und auch keine Tabellen löschen.

In diesem Szenario können Sie eine benutzerdefinierte Rolle mit eingeschränktem Zugriff auf das Schema und seine Tabellen erstellen. Sie würden dann den Benutzern, die schreibgeschützten Zugriff auf das Schema und die Tabellen benötigen, die Nur-Lese-Rolle zuweisen. Diese Benutzer können mit der eingeschränkten Standardrolle arbeiten, ohne sich Gedanken darüber zu machen, ob sie Schemaobjekte versehentlich ändern oder löschen.

Bemerkung

Führen Sie die SQL-Anweisungen in diesem Abschnitt als Benutzer mit der Rolle SECURITYADMIN (oder höher) aus.

  1. Erstellen Sie die benutzerdefinierte Rolle read_only_rl:

    CREATE ROLE read_only_rl
       COMMENT = 'This role is limited to querying tables in schema_1';
    
  2. Wenn Sie eine Rollenhierarchie implementiert haben (empfohlen), ordnen Sie die Rolle einer übergeordneten Rolle in einer Rollenhierarchie zu. In diesem Beispiel wird die Rolle read_only_rl der Rolle SYSADMIN zugewiesen. Die SYSADMIN-Rolle erbt alle Objektberechtigungen, die der Rolle read_only_rl erteilt wurden:

    GRANT ROLE read_only_rl
       TO ROLE sysadmin;
    
  3. Erteilen Sie der Rolle read_only_rl die folgenden Objektberechtigungen:

    • USAGE für die Datenbank, die das Schema enthält (database_a).

    • USAGE für das Schema, das die abzufragenden Tabellen enthält (schema_1). Um Objekte in einem Schema verwenden zu können, muss eine Rolle auch die Berechtigung USAGE für die Datenbank und das Schema haben:

    • SELECT für alle vorhandenen Tabellen.

    • USAGE für das Warehouse, das zur Ausführung von Abfragen auf den Tabellen verwendet wird (warehouse_1). Benutzer mit dieser Rolle können auf diesem Warehouse Abfragen ausführen.

    GRANT USAGE
      ON DATABASE database_a
      TO ROLE read_only_rl;
    
    GRANT USAGE
      ON SCHEMA database_a.schema_1
      TO ROLE read_only_rl;
    
    GRANT SELECT
      ON ALL TABLES IN SCHEMA database_a.schema_1
      TO ROLE read_only_rl;
    
    GRANT USAGE
      ON WAREHOUSE warehouse_1
      TO ROLE read_only_rl;
    

    Bemerkung

    Die GRANT SELECT ON ALL TABLES IN SCHEMA <Schema>-Anweisung gilt nur für bestehende Tabellen. Der Nur-Lese-Rolle muss die Berechtigung SELECT für alle Tabellen erteilt werden, die danach im Schema angelegt werden. Beispiel:

    GRANT SELECT
      ON TABLE database_a.schema_1.table_new
      TO ROLE read_only_rl;
    
  4. Verwenden Sie die ALTER USER, um den zu ändernden Benutzer zu deaktivieren. Dadurch werden alle vorhandenen Sitzungen des Benutzers zwangsweise geschlossen, während Sie die Änderungen an diesem Benutzer vornehmen. Mit dem folgenden Befehl wird beispielsweise der Benutzer Bonnie Smith (bsmith) deaktiviert:

    ALTER USER bsmith SET DISABLED=TRUE;
    
  5. Weisen Sie die Rolle read_only_rl einem Benutzer zu:

    GRANT ROLE read_only_rl
       TO USER bsmith;
    
  6. Legen Sie die Standardrolle für den Benutzer fest. Der folgende Befehl definiert die Standardrolle für Benutzer Bonnie Smith:

    ALTER USER bsmith
       SET DEFAULT_ROLE = read_only_rl;
    
  7. Aktivieren Sie den Benutzer mit dem Befehl ALTER USER, damit sich der Benutzer wieder anmelden kann, jetzt mit der neuen Standardrolle. Beispiel:

    ALTER USER bsmith SET DISABLED=false;
    

Festlegen zukünftiger Zuweisungen für Objekte

Zukünftige Zuweisungen ermöglichen die Definition eines ersten Satzes von Berechtigungen, die für neue (d. h. zukünftige) Objekte eines bestimmten Typs (z. B. Tabellen oder Ansichten) in einer Datenbank oder einem Schema erteilt werden sollen. Wenn neue Objekte erstellt werden, werden die definierten Berechtigungen automatisch einer angegebenen Rolle erteilt.

Zukünftige Zuweisungen definieren nur den anfänglichen Satz an Berechtigungen, die neuen Objekten eines angegebenen Typs erteilt werden. Nachdem ein einzelnes Objekt erstellt wurde, können Administratoren explizit zusätzliche Berechtigungen erteilen oder Berechtigungen für das Objekt widerrufen. Dies ermöglicht eine differenzierte Zugriffssteuerung über alle Objekte des Schemas bzw. der Datenbank.

Hinweise

  • Zukünftige Zuweisungen, die für ein Objekt auf Datenbankebene definiert sind, gelten für alle Objekte dieses Typs, die in Zukunft erstellt werden. Weitere Informationen finden Sie unter Definieren zukünftiger Zuweisungen für Datenbank- oder Schemaobjekte (unter diesem Thema).

  • Sie müssen zukünftige Zuwendungen für jeden Objekttyp (Schemata, Tabellen, Ansichten, Streams usw.) einzeln definieren. Weitere Informationen dazu finden Sie unter Definieren zukünftiger Zuweisungen für vorhandene Datenbank- oder Schemaobjekte (in diesem Thema).

  • Die mit zukünftigen Berechtigungen definierten Zuweisungen werden automatisch zum Zeitpunkt der Objekterstellung erteilt.

  • Wenn zukünftige Zuweisungen sowohl auf Datenbank- als auch auf Schemaebene definiert werden, haben die Zuweisungen auf Schemaebene Vorrang vor den Zuweisungen auf Datenbankebene, und die Zuweisungen auf Datenbankebene werden ignoriert.

  • Zukünftige Zuweisungen auf Datenbankebene gelten sowohl für reguläre als auch für verwaltete Zugriffsschemas. Weitere Informationen dazu finden Sie unter Sicherheitsberechtigungen zum Verwalten zukünftiger Zuweisungen (unter diesem Thema).

Sicherheitsberechtigungen zum Verwalten zukünftiger Zuweisungen

Die globale Berechtigung MANAGE GRANTS ist erforderlich, um Berechtigungen für zukünftige Objekte auf Datenbankebene zu erteilen oder zu widerrufen. Standardmäßig haben nur die Rollen SECURITYADMIN und ACCOUNTADMIN die Berechtigung MANAGE GRANTS.

Der Schemaeigentümer (d. h. die Rolle mit der OWNERSHIP-Berechtigung für das Schema) kann Berechtigungen für Objekte im Schema, einschließlich zukünftiger Zuweisungen erteilen.

Zukünftige Zuweisungen für Datenbank- oder Schemaobjekte

Sie können zukünftige Berechtigungen für Datenbank- oder Schemaobjekte mit dem Befehl GRANT <Berechtigungen> … TO ROLE mit den Schlüsselwörtern ON FUTURE zuweisen.

Codebeispiel zum Festlegen zukünftiger Zuweisungen auf Datenbankebene:

use role accountadmin;

-- Grant the USAGE privilege on all future schemas in a database to role R1
grant usage on future schemas in database DB1 to role R1;

Codebeispiel zum Festlegen zukünftiger Zuweisungen auf Schemaebene:

use role accountadmin;

-- Grant the SELECT privilege on all future tables in a schema to role R1
GRANT SELECT ON FUTURE TABLES IN SCHEMA DB1.schema1 TO ROLE R1;

-- Grants the SELECT and INSERT privileges on all future tables in a schema to R1
grant select,insert on future tables in schema DB1.schema1 to role R1;

Zukünftige Zuweisungen für Datenbank- oder Schemaobjekte

Zukünftige Zuweisungen beziehen sich nur auf neue Objekte. Sie müssen einer Rolle für vorhandene Objekte mit dem Befehl GRANT <Berechtigungen> … TO ROLE explizit die gewünschten Berechtigungen erteilen.

Codebeispiel:

use role accountadmin;

-- Grant the USAGE privilege on all existing schemas in a database to role R1
grant usage on all schemas in database DB1 to role R1;

-- Grant the SELECT privilege on all existing tables in a schema to role R1
grant select on all tables in schema DB1.schema1 to role R1

Zukünftige Zuweisungen für Datenbank- oder Schemaobjekte

Sie können zukünftige Berechtigungen für Datenbankobjekte mit dem Befehl REVOKE <Berechtigungen> … FROM ROLE und den Schlüsselwörtern ON FUTURE widerrufen.

Bemerkung

Durch das Widerrufen zukünftiger Berechtigungen für Datenbankobjekte werden nur Berechtigungen entfernt, die für zukünftige Objekte eines bestimmten Typs gewährt wurden, und nicht für vorhandene Objekte. Berechtigungen, die vorhandenen Objekten erteilt werden, bleiben erhalten.

Codebeispiel:

use role accountadmin;

-- Revoke the USAGE privilege on all existing schemas in a database from role R1
revoke usage on all schemas in database DB1 from role R1;

-- Revoke the SELECT and INSERT privilages on tables in a schema from the role R1
revoke select,insert on future tables in schema DB1.schema1 from role R1;

Verwalten zukünftiger Zuweisungen über die Weboberfläche

Sie können zukünftige Zuweisungen auch über die Weboberfläche definieren:

  • Für Datenbankobjekte: Klicken Sie auf Databases Databases tab » <Datenbankname> » <Objekttyp> » <Objektname> » Grant Privileges.

  • Für Schemaobjekte: Klicken Sie auf Databases Databases tab » <Datenbankname> » Schemas » <Schemaname> » Grant Privileges.

Einschränkungen

Die folgenden Einschränkungen gelten für zukünftige Zuweisungen auf Datenbank- oder Schemaebene:

  • Zukünftige Zuweisungen werden nicht unterstützt für:

    • Datenfreigabe (Data Sharing)

    • Datenreplikation

  • Zukünftige Zuweisungen werden für benannte Stagingbereiche mit den folgenden Einschränkungen unterstützt:

    • Die Berechtigung WRITE kann nicht ohne die Berechtigung READ angegeben werden.

    • Die Berechtigung READ kann nicht widerrufen werden, wenn die Berechtigung WRITE vorhanden ist.

    • Für interne Stagingbereiche werden nur zukünftige Zuweisungen mit den Berechtigungen READ oder WRITE materialisiert.

    • Für externe Stagingbereiche werden nur zukünftige Zuweisungen mit den USAGE-Berechtigungen materialisiert.

  • Zukünftige Zuweisungen werden nicht angewendet, wenn eine Tabelle umbenannt oder ausgetauscht wird.

  • Für jeden sicherungsfähigen Objekttyp ist nicht mehr als eine zukünftige Zuweisungen der Berechtigung OWNERSHIP zulässig.

  • Zukünftige Berechtigungen auf Datenbankebene mit OWNERSHIP-Berechtigungen für Objekte von verwalteten Zugriffsschemas in der Datenbank sind nicht betroffen.

  • Wenn eine Datenbank geklont wird, kopieren die Schemas in der geklonten Datenbank die zukünftigen Berechtigungen aus den Quellschemas. Auf diese Weise wird die Konsistenz mit den regulären Objektzuweisungen beibehalten, bei denen nicht die Berechtigungen des Quellobjekts (d. h. der Datenbank) in den Klon kopiert werden, sondern die Berechtigungen für alle untergeordneten Objekte (d. h. Schemas in der Datenbank).

Erstellen verwalteter Zugriffsschemas

Verwaltete Zugriffsschemas verbessern die Sicherheit, indem die Verwaltung von Berechtigungen für Objekte gesperrt wird.

In regulären (d. h. nicht verwalteten) Schemas können Objekteigentümer (d. h. eine Rolle mit der OWNERSHIP-Berechtigung für ein Objekt) anderen Rollen Zugriff auf ihre Objekte gewähren einschließlich der Option, diesen Rollen auch die Möglichkeit zu geben, Objektberechtigungen zu verwalten.

Mit verwalteten Zugriffsschemas haben Objekteigentümer nun keine Möglichkeit mehr, Berechtigungsentscheidungen zu treffen. Nur der Schemaeigentümer (d. h. die Rolle mit der OWNERSHIP-Berechtigung für das Schema) oder eine Rolle mit der Berechtigung MANAGE GRANTS kann Berechtigungen für Objekte im Schema, einschließlich zukünftiger Zuweisungen erteilen, wodurch die Berechtigungsverwaltung zentralisiert wird.

Sie können eine Netzwerkrichtlinie entweder über die Weboberfläche oder mit SQL erstellen:

Weboberfläche

Klicken Sie auf Databases Databases tab » <DB-Name> » Schemas » Create Schema.

SQL

Führen Sie eine CREATE SCHEMA-Anweisung mit den Schlüsselwörtern WITH MANAGED ACCESS aus.

Sie können ein reguläres Schema in ein verwaltetes Zugriffsschema (oder umgekehrt) ändern, indem Sie entweder die Weboberfläche oder SQL verwenden:

Weboberfläche

Klicken Sie auf Databases Databases tab » <DB-Name> » Schemas » <Schemaname> » Alter a schema.

SQL

Führen Sie eine ALTER SCHEMA-Anweisung mit den Schlüsselwörtern ENABLE | DISABLE MANAGED ACCESS aus.

In der folgenden Tabelle wird angegeben, welche Rollen Objektberechtigungen in einem regulären oder verwalteten Zugriffsschema verwalten können:

Rolle

Kann Objektberechtigungen in einem regulären Schema erteilen

Kann Objektberechtigungen in einem verwalteten Zugriffsschema erteilen

SYSADMIN

Nein

Nein

SECURITYADMIN oder höher

Ja

Ja

Datenbankeigentümer

Nein

Nein

Schemaeigentümer

Nein

Ja

Objekteigentümer

Ja

Nein

Eine beliebige Rolle mit der Berechtigung MANAGE GRANTS

Ja

Ja

Aktivieren der Überwachung des Nutzungs- und Abrechnungsverlaufs durch Nichtkontoadministratoren

Snowflake bietet umfangreiche Kontonutzungs- und Abrechnungsinformationen zu Datenspeicherung und -transfer sowie zu Warehouse-Nutzung und -Auslastung:

Weboberfläche

Klicken Sie auf Account Account tab » Billing & Usage.

SQL

Fragen Sie Folgendes ab:

Standardmäßig können diese Informationen jedoch nur von Kontoadministratoren abgerufen/angezeigt werden. Um Benutzern, die keine Kontoadministratoren sind, den Zugriff auf diese Informationen zu ermöglichen, bietet Snowflake die globale Berechtigung MONITOR USAGE. Wenn einer Rolle die MONITOR USAGE-Berechtigung erteilt wird, können alle Benutzer, denen die Rolle zugewiesen wurde, auf diese historischen/nutzungsbezogenen Informationen zuzugreifen.

Darüber hinaus geben die Befehle SHOW DATABASES und SHOW WAREHOUSES bei dieser Berechtigung die Listen aller Datenbanken und Warehouses im Konto zurück, unabhängig von anderen Berechtigungen.

So erteilen Sie beispielsweise diese Berechtigung der Rolle custom:

GRANT MONITOR USAGE ON ACCOUNT TO ROLE custom;