Konfigurieren der Zugriffssteuerung

Unter diesem Thema wird beschrieben, wie Sie in Ihrem Konto die Sicherheit der Zugriffssteuerung für sicherungsfähige Objekte 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:

  • Weisen Sie den Benutzern die ACCOUNTADMIN-Rolle zu, aber legen Sie diese Rolle nicht als Standard fest. Legen Sie stattdessen eine untergeordnete administrative Rolle (z. B. SYSADMIN) oder eine benutzerdefinierte Rolle als Standardrolle fest. 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 von benutzerdefinierten Rollen

Um das allgemeinen Prinzip der „niedrigsten Berechtigung“ zu befolgen, empfehlen wir das Erstellen von benutzerdefinierten Rollen, die sich an den Geschäftsfunktionen Ihres Unternehmens orientieren, um SQL-Aktionen nur auf einer begrenzten Menge von sicherungsfähigen Objekten zuzulassen.

Der Workflow ist wie folgt:

  1. Erstellen Sie eine benutzerdefinierte Rolle.

  2. Erteilen Sie der Rolle die erforderlichen Berechtigungen.

  3. Weisen Sie die Rolle einem oder mehreren Benutzern zu, die die Berechtigungen benötigen, die der Rolle erteilt wurden, damit diese Benutzer SQL-Aktionen für ihre geschäftlichen Anforderungen ausführen können.

  4. Weisen Sie die Rolle einer anderen Rolle zu, um eine Rollenhierarchie zu erstellen oder zu erweitern. Dieser Schritt ist zwar nicht erforderlich, wird aber dringend empfohlen. Weitere Informationen dazu finden Sie unter Erstellen einer Rollenhierarchie (unter diesem Thema).

Dieser Abschnitt bietet eine Anleitung zum Erstellen einer Rolle mit dem Namen r1 und zum Zuweisen der folgenden Berechtigungen zu dieser Rolle. Mit diesen Berechtigungen kann ein Benutzer, der die Rolle in einer Sitzung aktiviert, eine einzelne Tabelle wie d1.s1.t1 abfragen:

Berechtigung

Objekt

Anmerkungen

USAGE

Warehouse w1

Datenbank d1

Schema s1

Um ein Objekt (z. B. eine Tabelle oder eine Ansicht) abzufragen, muss eine Rolle die USAGE-Berechtigung für ein Warehouse haben. Das Warehouse stellt die Computeressourcen für die Ausführung der Abfrage bereit.

Um beliebige Objekte in einem Schema verwenden zu können, muss eine Rolle auch die USAGE-Berechtigung für Datenbank und Schema des Containers haben.

SELECT

Tabellen-t1

Nachdem eine Rolle erstellt wurde, können ihr zusätzliche Berechtigungen erteilt werden, damit Benutzer mit dieser Rolle zusätzliche SQL-Aktionen auf demselben oder auf zusätzlichen Objekten ausführen können.

Rolle erstellen

  1. Erstellen Sie mit CREATE USER die Rolle r1.

    Nur Benutzeradministratoren (d. h. Benutzer mit der Rolle USERADMIN oder höher) oder eine andere Rolle mit der Berechtigung CREATE ROLE für das Konto können Rollen erstellen.

    CREATE ROLE r1
       COMMENT = 'This role has all privileges on schema_1';
    

Rolle Berechtigungen erteilen

  1. Erteilen Sie der Rolle r1 die in der Tabelle weiter oben in diesem Abschnitt definierten Berechtigungen.

    Dieser Befehl kann nur von einer Rolle mit der globalen Berechtigung MANAGE GRANTS oder einer höheren Rolle ausgeführt werden. Standardmäßig verfügt nur die Rolle SECURITYADMIN über die Berechtigung MANAGE GRANTS.

    GRANT USAGE
      ON WAREHOUSE w1
      TO ROLE r1;
    
    GRANT USAGE
      ON DATABASE d1
      TO ROLE r1;
    
    GRANT USAGE
      ON SCHEMA d1.s1
      TO ROLE r1;
    
    GRANT SELECT
      ON TABLE d1.s1.t1
      TO ROLE r1;
    

Benutzern die Rolle zuweisen

  1. Weisen Sie Rolle r1 dem Benutzer smith zu.

    Nur die Rolle mit der Berechtigung OWNERSHIP für den Benutzer, eine Rolle mit der globalen Berechtigung MANAGE GRANTS oder eine Rolle, die in der Rollenhierarchie höher steht als eine dieser Rollen, kann diesen Befehl ausführen.

    GRANT ROLE r1
       TO USER smith;
    
  2. Optional können Sie die neue benutzerdefinierte Rolle als Standardrolle für den Benutzer festlegen. Wenn sich der Benutzer das nächste Mal bei Snowflake anmeldet, ist die Standardrolle automatisch in der Sitzung aktiv.

    Dieser Befehl kann nur von der Rolle mit OWNERSHIP-Berechtigung für einen Benutzer oder von einer höheren Rolle ausgeführt werden.

    Mit dem folgenden Befehl wird die Standardrolle für den Benutzer smith festgelegt:

    ALTER USER smith
       SET DEFAULT_ROLE = r1;
    

Erstellen von Nur-Lese-Rollen

Angenommen, Sie benötigen eine Rolle, die sich auf die Abfrage aller Tabellen in einem bestimmten Schema beschränkt (z. B. d1.s1). Benutzer, die Befehle mithilfe dieser Rolle ausführen, können die Tabellendaten nicht aktualisieren, keine zusätzlichen Datenbankobjekte erstellen oder Tabellen löschen. Die Rolle beschränkt sich auf die Abfrage von Tabellendaten.

Um eine Nur-Lese-Rolle zu erstellen, führen Sie die grundlegenden Schritte aus, die unter Erstellen von benutzerdefinierten Rollen (unter diesem Thema) beschrieben sind. Erteilen Sie im Abschnitt Rolle Berechtigungen erteilen der Nur-Lese-Rolle (in dieser Anleitung read_only genannt) die folgenden Objektberechtigungen:

Berechtigung

Objekt

Anmerkungen

USAGE

Warehouse

Um ein Objekt (z. B. eine Tabelle oder eine Ansicht) abzufragen, muss eine Rolle die USAGE-Berechtigung für ein Warehouse haben. Das Warehouse stellt die Computeressourcen für die Ausführung der Abfrage bereit.

SELECT

Tabelle

Um beliebige Objekte in einem Schema verwenden zu können, muss eine Rolle auch die USAGE-Berechtigung für Datenbank und Schema des Containers haben.

Die GRANT <Berechtigung>-Anweisungen lauten wie folgt:

GRANT USAGE
  ON DATABASE d1
  TO ROLE read_only;

GRANT USAGE
  ON SCHEMA d1.s1
  TO ROLE read_only;

GRANT SELECT
  ON ALL TABLES IN SCHEMA d1.s1
  TO ROLE read_only;

GRANT USAGE
  ON WAREHOUSE w1
  TO ROLE read_only;

Bemerkung

Mit der Anweisung GRANT SELECT ON ALL TABLES IN SCHEMA <Schema> wird die SELECT-Berechtigung nur für alle vorhandenen Tabellen erteilt. Um der Rolle die SELECT-Berechtigung für alle zukünftigen Tabellen zu erteilen, führen Sie die folgende Anweisung aus:

GRANT SELECT ON FUTURE TABLES IN SCHEMA d1.s1 TO ROLE read_only;

Erstellen einer Rollenhierarchie

Wenn Sie benutzerdefinierte Rollen erstellen, sollten Sie eine Rollenhierarchie erstellen, die letztendlich einer Administratorrolle auf höchster Ebene zugeordnet ist. Im Allgemeinen funktioniert die SYSADMIN-Rolle 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.

Die folgende Abbildung veranschaulicht beispielhaft die Rollenhierarchie und die Berechtigungen, über die jede Rolle verfügt:

Role hierarchy and privileges granted to each role

Rolle einer anderen Rolle zuweisen

Weisen Sie die Rolle einer in der Rollenhierarchie übergeordneten Rolle zu. In diesem Beispiel wird die Rolle r1, die in Erstellen von benutzerdefinierten Rollen (unter diesem Thema) erstellt wurde, der Rolle SYSADMIN zugewiesen. Die SYSADMIN-Rolle erbt alle Objektberechtigungen, die der Rolle r1 erteilt wurden:

GRANT ROLE r1
   TO ROLE sysadmin;

Bemerkung

In einem komplexeren Beispiel können Sie die custom-Rolle einer anderen untergeordneten SYSADMIN-Rolle (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 custom-Rolle und seiner übergeordneten Rolle erteilt wurden. Wenn die Rolle, die sich in der Hierarchie über der custom-Rolle befindet, irgendwelche Objekte besitzt, dann würde die Rollenhierarchie sicherstellen, dass Mitglieder der SYSADMIN-Rolle diese Objekte ebenfalls (indirekt) besitzen und sie wie erwartet verwalten können.

Anzeigen der erteilten Berechtigungen

Um die aktuelle einem Objekt erteilten Berechtigungen anzuzeigen, können Sie den Befehl SHOW GRANTS ausführen.

Bemerkung

Das Ausführen des Befehls SHOW GRANTS für ein bestimmtes Objekt erfordert die gleichen Objektberechtigungen wie die Ausführung 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

Um beispielsweise 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 unter Erstellen von benutzerdefinierten Rollen (unter diesem Thema) 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    |
|-------------------------------+-----------------------+------------+----------------------+------------+--------------------------+--------------+---------------|
| 2022-03-07 09:04:23.635 -0800 | USAGE                 | SCHEMA     | D1.S1                | ROLE       | R1                       | false        | SECURITYADMIN |
+-------------------------------+-----------------------+------------+----------------------+------------+--------------------------+--------------+---------------+

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 r1 erteilt wurden, die unter Erstellen von benutzerdefinierten Rollen (unter diesem Thema) erstellt wurde:

SHOW GRANTS TO ROLE r1;

Snowflake gibt die folgenden Ergebnisse zurück:

+-------------------------------+-----------+------------+----------------------+------------+--------------+--------------+---------------+
| created_on                    | privilege | granted_on | name                 | granted_to | grantee_name | grant_option | granted_by    |
|-------------------------------+-----------+------------+----------------------+------------+--------------+--------------+---------------|
| 2022-03-07 09:08:43.773 -0800 | USAGE     | DATABASE   | D1                   | ROLE       | R1           | false        | SECURITYADMIN |
| 2022-03-07 09:08:55.253 -0800 | USAGE     | SCHEMA     | D1.S1                | ROLE       | R1           | false        | SECURITYADMIN |
| 2022-03-07 09:09:07.206 -0800 | SELECT    | TABLE      | D1.S1.T1             | ROLE       | R1           | false        | SECURITYADMIN |
| 2022-03-07 09:08:34.838 -0800 | USAGE     | WAREHOUSE  | W1                   | ROLE       | R1           | false        | SECURITYADMIN |
+-------------------------------+-----------+------------+----------------------+------------+--------------+--------------+---------------+

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 Zuweisungen für jeden Objekttyp (Schemas, 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 folgenden Berechtigungen sind erforderlich, um Berechtigungen für zukünftige Objekte zu erteilen oder zu entziehen:

Datenbankebene

Die globale Berechtigung MANAGE GRANTS ist erforderlich, um Berechtigungen für zukünftige Objekte einer Datenbank zu erteilen oder zu entziehen. Nur die Systemrollen SECURITYADMIN und ACCOUNTADMIN haben die MANAGE GRANTS-Berechtigung. Diese Berechtigung kann jedoch benutzerdefinierten Rollen erteilt werden.

Schemaebene

In verwalteten Zugriffsschemas (d. h. Schemas, die mit der CREATE SCHEMA … WITH MANAGED ACCESS-Syntax erstellt wurden) kann nur der Schemaeigentümer (d. h. die Rolle mit der Berechtigung OWNERSHIP für das Schema) Berechtigungen für zukünftige Objekte des Schemas erteilen oder entziehen.

Bei Standardschemas ist die globale Berechtigung MANAGE GRANTS erforderlich, um Berechtigungen für zukünftige Objekte des Schemas zu erteilen oder zu entziehen.

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 d1 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 d1.s1 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 d1.s1 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 d1 to role r1;

-- Grant the SELECT privilege on all existing tables in a schema to role r1
grant select on all tables in schema d1.s1 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 d1 from role r1;

-- Revoke the SELECT and INSERT privileges on tables in a schema from the role r1
revoke select,insert on future tables in schema d1.s1 from role r1;

Verwalten zukünftiger Zuweisungen über die Weboberfläche

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

Berechtigungen auf zukünftige Datenbankobjekte
  1. Klicken Sie auf Databases Databases tab.

  2. Klicken Sie auf die Zeile einer spezifischen Rolle. Der Sicherheitsbereich wird geöffnet.

  3. Klicken Sie auf die Schaltfläche Grant Privileges. Das Dialogfenster Grant Privileges wird geöffnet.

  4. Wählen Sie in der Dropdown-Liste Grant privileges on die Option future Objekttyp aus, um zukünftige Grants für neue Objekte eines bestimmten Objekttyps zu definieren.

  5. Wählen Sie in den übrigen Dropdown-Listen die Berechtigungen aus, die Sie den neuen Objekten des angegebenen Typs erteilen möchten, sowie die Rolle, der die Berechtigungen erteilt werden sollen.

  6. Klicken Sie auf die Schaltfläche Grant Privileges.

Berechtigungen auf zukünftige Schemaobjekte
  1. Klicken Sie auf Databases Databases tab » <DB-Name> » Schemas

  2. Klicken Sie auf die Zeile eines spezifischen Schemas. Der Sicherheitsbereich wird geöffnet.

  3. Klicken Sie auf die Schaltfläche Grant Privileges. Das Dialogfenster Grant Privileges wird geöffnet.

  4. Wählen Sie in der Dropdown-Liste Grant privileges on die Option future Objekttyp aus, um zukünftige Grants für neue Objekte eines bestimmten Objekttyps zu definieren.

  5. Wählen Sie in den übrigen Dropdown-Listen die Berechtigungen aus, die Sie den neuen Objekten des angegebenen Typs erteilen möchten, sowie die Rolle, der die Berechtigungen erteilt werden sollen.

  6. Klicken Sie auf die Schaltfläche 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 nur eine zukünftige Zuweisungen der OWNERSHIP-Berechtigung 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 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:

Classic Web Interface

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:

Classic Web Interface

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

Jede Rolle mit der Berechtigung MANAGE GRANTS

Ja

Ja

Möglichkeit zur Überwachung des Nutzungs- und Abrechnungsverlaufs durch Nichtkontoadministratoren über die klassische Weboberfläche

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

Snowsight

Select Admin » Usage.

Classic Web Interface

Klicken Sie auf Account Account tab » Billing & Usage.

SQL

Fragen Sie Folgendes ab:

Standardmäßig können diese Informationen nur von Kontoadministratoren abgerufen/angezeigt werden.

Bemerkung

Derzeit können Nutzungs- und Abrechnungsinformationen in Snowsight nur von Kontoadministratoren angezeigt werden. Es ist nicht möglich, anderen Rollen die Berechtigung zur Anzeige dieser Informationen zu erteilen.

Damit Benutzer, die keine Kontoadministratoren sind, auf diese Informationen zugreifen bzw. sie anzeigen können, erteilen Sie einer systemdefinierten oder benutzerdefinierten Rolle die folgenden Berechtigungen. Wenn einer Rolle die Berechtigungen erteilt werden, können alle Benutzer, denen die Rolle zugewiesen wurde, auf diese historischen/nutzungsbezogenen Informationen zuzugreifen.

Berechtigung

Objekt

Beschreibung

MONITOR USAGE

Konto (d. h. globale Berechtigung)

Ermöglicht Benutzern, denen die Rolle zugewiesen wurde, Nutzungs- und Abrechnungsinformationen auf der Weboberfläche anzuzeigen und die entsprechenden Tabellenfunktionen im Information Schema abzufragen.

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.

IMPORTED PRIVILEGES

snowflake-Datenbank

Ermöglicht Benutzern, denen die Rolle zugewiesen wurde, die Abfrage aller ACCOUNT USAGE-Ansichten, einschließlich der Ansichten mit Nutzungs- und Abrechnungsinformationen.

Weitere Informationen dazu finden Sie unter Aktivieren der Nutzung der Snowflake-Datenbank für andere Rollen.

Erteilen Sie beispielsweise der Rolle custom folgende Berechtigungen:

GRANT MONITOR USAGE ON ACCOUNT TO ROLE custom;

GRANT IMPORTED PRIVILEGES ON DATABASE snowflake TO ROLE custom;
Zurück zum Anfang