Hinweise zur Zugriffssteuerung

Unter diesem Thema sind Best Practices und wichtige Hinweise zur Verwaltung des sicheren Zugriffs auf Ihr Snowflake-Konto und die im Konto gespeicherten Daten zusammengefasst. Insbesondere werden allgemeine Hinweise zur Konfiguration der rollenbasierten Zugriffssteuerung gegeben, die den Zugriff auf Objekte basierend auf der Rolle eines Benutzers einschränkt.

Unter diesem Thema:

Verwenden der ACCOUNTADMIN-Rolle

Die Rolle Kontoadministrator (ACCOUNTADMIN) ist die mächtigste Rolle im System. Diese Rolle ist allein verantwortlich für die Konfiguration der Parameter auf Kontoebene. Benutzer mit der Rolle ACCOUNTADMIN können alle Objekte im Konto anzeigen und bearbeiten, Snowflake-Abrechnungsdaten und Credit-Daten anzeigen und verwalten und alle in Ausführung befindlichen SQL-Anweisungen stoppen.

In der standardmäßigen Zugriffssteuerungshierarchie sind die beiden anderen Administratorrollen dieser Rolle zugeordnet:

  • Die Rolle Sicherheitsadministrator (SECURITYADMIN) enthält die Berechtigungen zum Erstellen und Verwalten von Benutzern und Rollen.

  • Die Rolle Systemadministrator (SYSADMIN) beinhaltet die Berechtigungen zum Erstellen von Warehouses, Datenbanken und allen Datenbankobjekten (Schemas, Tabellen usw.).

Achtung

Wenn Ihr Konto bereitgestellt wird, wird dem ersten Benutzer standardmäßig die Rolle ACCOUNTADMIN zugewiesen. Dieser Benutzer sollte dann einen oder mehrere zusätzliche Benutzer anlegen, denen die Rolle SECURITYADMIN zugewiesen wird. Alle übrigen Benutzer sollten von einem der Benutzer mit der Rolle SECURITYADMIN erstellt werden.

Steuern der Zuweisung der Rolle ACCOUNTADMIN zu Benutzern

Wir empfehlen nachdrücklich, bei der Zuordnung der ACCOUNTADMIN-Rolle zu Benutzern die folgenden Vorsichtsmaßnahmen zu ergreifen:

  • Weisen Sie diese Rolle nur einer ausgewählten/begrenzten Anzahl von Personen in Ihrem Unternehmen zu.

  • Alle Benutzer, denen die Rolle ACCOUNTADMIN zugewiesen wurde, sollten außerdem zur Anmeldung die (mehrstufige Authentifizierung) (MFA) verwenden (weitere Details dazu finden Sie unter Konfigurieren der Zugriffssteuerung).

  • Ordnen Sie diese Rolle mindestens zwei Benutzern zu. Wir befolgen strenge Sicherheitsvorkehrungen, um ein vergessenes oder verlorenes Kennwort für Benutzer mit der Rolle ACCOUNTADMIN zurückzusetzen. Dieser Vorgang kann bis zu zwei Werktage dauern. Durch die Zuordnung der Rolle ACCOUNTADMIN zu mehr als einem Benutzer entfällt die Notwendigkeit, diesen Vorgang durchzuführen, da die Benutzer die Kennwörter der jeweils anderen Benutzer zurücksetzen können.

Tipp

Es hilft auch, wenn Sie ACCOUNTADMIN-Benutzer mit der E-Mail-Adresse einer echten Person verknüpfen, sodass der Snowflake-Support weiß, an wen er sich in einer dringenden Situation wenden kann.

Vermeiden der Verwendung der ACCOUNTADMIN-Rolle zum Erstellen von Objekten

Die Rolle ACCOUNTADMIN ist für die Durchführung von Ersteinrichtungsaufgaben im System und die tägliche Verwaltung von Objekten und Aufgaben auf Kontoebene vorgesehen. Daher sollte sie nicht verwendet werden, um Objekte in Ihrem Konto zu erstellen, es sei denn, Sie benötigen diese Objekte unbedingt, um den höchsten Grad an Sicherheit zu erhalten. Wenn Sie Objekte mit der Rolle ACCOUNTADMIN anlegen und möchten, dass Benutzer Zugriff auf diese Objekte haben, müssen Sie den Rollen dieser Benutzer explizit Berechtigungen auf die Objekte erteilen.

Wir empfehlen stattdessen, eine Rollenhierarchie zu erstellen, die auf die Geschäftsfunktionen in Ihrer Organisation abgestimmt ist, und diese Rollen schließlich der Rolle SYSADMIN zuzuweisen. Weitere Informationen dazu finden Sie unter Ausrichten des Objektzugriffs an den Geschäftsfunktionen (unter diesem Thema).

Tipp

Um zu verhindern, dass Kontoadministratoren versehentlich die ACCOUNTADMIN-Rolle zum Erstellen von Objekten verwenden, weisen Sie ihnen zusätzliche Rollen zu, und bestimmen Sie eine dieser Rollen als Standard (d. h. machen Sie ACCOUNTADMIN nicht zur Standardrolle für Benutzer im System).

Dies hindert sie nicht daran, die ACCOUNTADMIN-Rolle zum Erstellen von Objekten zu verwenden, aber es zwingt sie, ihre Rolle bei jeder Anmeldung explizit auf ACCOUNTADMIN zu ändern. Dies kann dazu beitragen, sie über den Zweck/Funktion von Rollen im System aufzuklären und sie zu ermutigen, zur entsprechenden Rolle für die Ausführung einer bestimmten Aufgabe zu wechseln, insbesondere wenn sie Aufgaben des Kontoadministrators ausführen müssen.

Vermeiden der Verwendung der ACCOUNTADMIN-Rolle für automatisierte Skripte

Wir empfehlen, für automatisierte Skripte eine andere Rolle als ACCOUNTADMIN zu verwenden. Wenn Sie, wie empfohlen, eine Rollenhierarchie unter der SYSADMIN-Rolle anlegen, können alle Operationen auf Warehouse- und Datenbankobjekten mit der SYSADMIN-Rolle oder den untergeordneten Rollen in der Hierarchie ausgeführt werden. Die einzigen Einschränkungen, auf die Sie stoßen würden, sind das Anlegen oder Ändern von Benutzern oder Rollen. Diese Operationen müssen von einem Benutzer mit der Rolle SECURITYADMIN oder einer anderen Rolle mit ausreichenden Objektberechtigungen ausgeführt werden.

Zugriff auf Datenbankobjekte

Alle sicherungsfähigen Datenbankobjekte (wie TABLE, FUNCTION, FILE FORMAT, STAGE, SEQUENCE usw.) sind in einem SCHEMA-Objekt einer DATABASE enthalten. Um auf Datenbankobjekte zugreifen zu können, muss den Benutzern zusätzlich zu den Berechtigungen für die spezifischen Datenbankobjekte die Berechtigung USAGE für die Containerdatenbank und das Schema erteilt werden.

Nehmen wir zum Beispiel an, dass mytable in mydb.myschema erstellt wird. Um mytable abzufragen, muss ein Benutzer mindestens über die folgenden Berechtigungen verfügen:

Datenbank

USAGE für mydb

Schema

USAGE für myschema

Tabelle

SELECT für mytable

Verwalten von benutzerdefinierten Rollen

Wenn eine benutzerdefinierte Rolle zum ersten Mal erstellt wird, existiert sie isoliert. Die Rolle muss allen Benutzern zugewiesen werden, die die mit der Rolle verbundenen Objektberechtigungen verwenden. Die benutzerdefinierte Rolle muss auch allen Rollen gewährt werden, die die von der benutzerdefinierten Rolle erstellten Objekte verwalten.

Wichtig

Standardmäßig kann nicht einmal die Rolle ACCOUNTADMIN Objekte ändern oder löschen, die von einer benutzerdefinierten Rolle erstellt wurden. Die benutzerdefinierte Rolle muss der Rolle ACCOUNTADMIN direkt zugewiesen werden oder vorzugsweise einer anderen Rolle in einer Hierarchie mit der SYSADMIN-Rolle als übergeordneter Rolle. Die Rolle SYSADMIN wird von der Rolle ACCOUNTADMIN verwaltet.

Anweisungen zum Erstellen einer Rollenhierarchie finden Sie unter Erstellen einer Rollenhierarchie.

Ausrichten des Objektzugriffs an den Geschäftsfunktionen

Erwägen Sie, die Vorteile der Rollenhierarchie und der Vererbung von Berechtigungen zu nutzen, um den Zugriff auf Datenbankobjekte mit den Geschäftsfunktionen in Ihrem Unternehmen abzustimmen. In einer Rollenhierarchie werden Rollen an andere Rollen vergeben, um eine Vererbungsbeziehung zu bilden. Berechtigungen, die Rollen auf einer niedrigeren Ebene erteilt werden, werden an Rollen auf einer höheren Ebene vererbt.

Als einfaches Beispiel nehmen wir an, dass zwei Datenbanken, d1 und d2, Daten enthalten, die von Business Analysten in Ihrem Unternehmen benötigt werden. Basierend auf ihren funktionalen Verantwortlichkeiten sollten Einsteigeranalysten Lesezugriff auf d1 haben, aber der Zugriff auf d2 sollte auf fortgeschrittene Analysten beschränkt sein. Ein empfohlener Ansatz zur Konfiguration der Sicherheit für diese Datenbanken besteht darin, eine Kombination aus Objektzugriffsrollen und Geschäftsfunktionsrollen für eine optimale Kontrolle zu erstellen.

Bemerkung

Es gibt keinen technischen Unterschied zwischen einer Objektzugriffsrolle und einer Geschäftsfunktionsrolle in Snowflake. Der Unterschied besteht darin, wie sie logisch verwendet werden, um Berechtigungen zusammenzustellen und Gruppen von Benutzern zuzuweisen.

So konfigurieren Sie den Zugriff in diesem Beispiel:

  1. Erstellen Sie als Sicherheitsadministrator (Benutzer mit der Rolle SECURITYADMIN) oder einer anderen Rolle mit der Berechtigung CREATE ROLE für das Konto die Rollen analyst_basic und analyst_adv. Diese Rollen entsprechen den Geschäftsfunktionen Ihres Unternehmens und dienen als Sammelrollen für alle Objektzugriffsrollen, die für diese Funktionen erforderlich sind. Da grundlegende Analystenfunktionen auch von erfahrenen Analysten benötigt werden, weisen Sie die Rolle analyst_basic der Rolle analyst_adv zu.

    Gewähren Sie dem Systemadministrator (SYSADMIN) die Rolle analyst_adv, indem Sie Best Practices für Rollenhierarchien befolgen. Systemadministratoren können dann allen Rollen in dieser Hierarchie Berechtigungen für Datenbankobjekte erteilen.

    CREATE ROLE analyst_basic;
    CREATE ROLE analyst_adv;
    
    GRANT ROLE analyst_basic TO ROLE analyst_adv;
    GRANT ROLE analyst_adv TO ROLE sysadmin;
    
  2. Verwenden Sie dieselbe Rolle wie in Schritt 1 und erstellen Sie Objektzugriffsrollen db1_read_only und db2_read_only. Weisen Sie diese Rollen den Geschäftsfunktionsrollen zu, die diese Rollen benötigen. Weisen Sie in diesem Fall die Rolle db1_read_only der Rolle analyst_basic zu, und weisen Sie die Rolle db2_read_only der Rolle analyst_adv zu.

    CREATE ROLE db1_read_only;
    CREATE ROLE db2_read_only;
    
    GRANT ROLE db1_read_only TO ROLE analyst_basic;
    GRANT ROLE db2_read_only TO ROLE analyst_adv;
    
  3. Gewähren Sie als Sicherheitsadministrator (Benutzer mit der Rolle SECURITYADMIN) oder einer anderen Rolle mit der Berechtigung MANAGE GRANTS für das Konto den Rollen db1_read_only und db2_read_only einen Nur-Lese-Zugriff auf die Datenbanken d1 bzw. d2. Weitere Informationen dazu finden Sie unter Erstellen von Nur-Lese-Rollen. Diese Rollen definieren einen Satz von Berechtigungen für den Zugriff auf Datenobjekte.

    GRANT <privileges> TO ROLE db1_read_only;
    GRANT <privileges> TO ROLE db2_read_only;
    
  4. Weisen Sie als Sicherheitsadministrator (Benutzer mit der Rolle SECURITYADMIN) oder einer anderen Rolle mit der Berechtigung MANAGE GRANTS für das Konto die Rollen der Geschäftsfunktion den Benutzern zu, die diese Funktionen ausführen:

    GRANT ROLE analyst_basic TO USER user1;
    GRANT ROLE analyst_adv TO USER user2;
    

Berechtigungen, die den (in der Rollenhierarchie) untergeordneten Objektzugriffsrollen db1_read_only und db2_read_only erteilt wurden, werden an die übergeordneten Geschäftsfunktionsrollen analyst_basic bzw. analyst_adv vererbt. Da analyst_basic der Rolle analyst_adv zugewiesen wurde, werden alle Berechtigungen, die db1_read_only oder analyst_basic zugewiesen wurden, an analyst_adv vererbt.

../_images/role-hierarchy-practical.png

Benutzer, denen die Rolle analyst_adv zugewiesen wurde, können sowohl auf db1 als auch auf db2 zugreifen. Benutzer, denen die Rolle analyst_basic zugewiesen wurde, können jedoch nur auf db1 zugreifen.

Zentralisieren der Berechtigungsverwaltung mithilfe von verwalteten Zugriffsschemas

Bei regulären (d. h. nicht verwalteten) Schemas in einer Datenbank können Objekteigentümers (d. h. Rollen mit der OWNERSHIP-Berechtigung für ein oder mehrere Objekte) anderen Rollen Zugriff auf ihre Objekte gewähren einschließlich der Option, diesen Rollen auch die Möglichkeit zu geben, Objektberechtigungen zu verwalten.

Verwenden Sie verwaltete Zugriffsschemas, um die Sicherheit von Objekten weiter zu erhöhen. In einem verwalteten Zugriffsschema verlieren Objekteigentümer die Möglichkeit, 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.

Weitere Informationen zu verwalteten Zugriffsschemas finden Sie unter Erstellen verwalteter Zugriffsschemas.

Vereinfachen der Berechtigungsverwaltung mithilfe von zukünftigen Zuweisungen

Zukünftige Zuweisungen ermöglichen die Definition eines anfänglichen Satzes von Berechtigungen für Objekte eines bestimmten Typs (z. B. Tabellen oder Ansichten) in einem angegebenen Schema. Wenn neue Objekte erstellt werden, werden die definierten Berechtigungen automatisch einer Rolle zugewiesen, wodurch die Verwaltung von Berechtigungen vereinfacht wird.

Stellen Sie sich das folgende Szenario vor, in dem einer bestimmten Rolle die Berechtigung SELECT für alle neuen, im Schema erstellten Tabellen erteilt wird. Zu einem späteren Zeitpunkt wird entschieden, die Berechtigung dieser Rolle wieder zu entziehen und stattdessen einer anderen Rolle zuzuweisen. Mit den Schlüsselwörtern ON FUTURE für neue Tabellen und dem Schlüsselwort ALL für vorhandene Tabellen sind einige SQL-Anweisungen erforderlich, um Berechtigungen für neue und vorhandene Tabellen zu erteilen und zu widerrufen. Beispiel:

-- Grant the SELECT privilege on all new (i.e. future) tables in a schema to role R1
GRANT SELECT ON FUTURE TABLES IN SCHEMA s1 TO ROLE r1;

-- / Create tables in the schema /

-- Grant the SELECT privilege on all new tables in a schema to role R2
GRANT SELECT ON FUTURE TABLES IN SCHEMA s1 TO ROLE r2;

-- Grant the SELECT privilege on all existing tables in a schema to role R2
GRANT SELECT ON ALL TABLES IN SCHEMA s1 TO ROLE r2;

-- Revoke the SELECT privilege on all new tables in a schema (i.e. future grant) from role R1
REVOKE SELECT ON FUTURE TABLES IN SCHEMA s1 FROM ROLE r1;

-- Revoke the SELECT privilege on all existing tables in a schema from role R1
REVOKE SELECT ON ALL TABLES IN SCHEMA s1 FROM ROLE r1;

Weitere Informationen zu zukünftigen Zuweisungen finden Sie unter Festlegen zukünftiger Zuweisungen für Objekte.

Anzeigen von Abfrageergebnissen

Ein Benutzer kann das Resultset einer Abfrage, die ein anderer Benutzer ausgeführt hat, nicht anzeigen. Dieses Verhalten ist beabsichtigt. Aus Sicherheitsgründen kann nur der Benutzer, der eine Abfrage ausgeführt hat, auf die Abfrageergebnisse zugreifen.

Bemerkung

Dieses Verhalten ist nicht mit dem Snowflake-Zugriffssteuerungsmodell für Objekte verbunden. Selbst ein Benutzer mit der Rolle ACCOUNTADMIN kann die Ergebnisse einer von einem anderen Benutzer ausgeführten Abfrage nicht anzeigen.

Erläuterungen zu geklonten Objekten und erteilten Berechtigungen

Durch das Klonen einer Datenbank, eines Schemas oder einer Tabelle wird eine Kopie des Quellobjekts erstellt. Das geklonte Objekt enthält eine Momentaufnahme der Daten, die im Quellobjekt vorhanden waren, als der Klon erstellt wurde.

Ein geklontes Objekt wird in Snowflake als neues Objekt angesehen. Alle Berechtigungen, die dem Quellobjekt erteilt wurden, werden nicht auf das geklonte Objekt übertragen. Ein geklontes Containerobjekt (eine Datenbank oder ein Schema) behält jedoch alle Berechtigungen, die für die im Quellobjekt enthaltenen Objekte erteilt werden. So behält beispielsweise ein geklontes Schema alle Berechtigungen, die für Tabellen, Ansichten, UDFs und andere Objekte im Quellschema erteilt werden.

Weitere Details zum Klonen finden Sie unter Hinweise zum Klonen und CREATE <Objekt> … CLONE.