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 des Kontoadministrators (d. h. Benutzer mit der Systemrolle ACCOUNTADMIN) ist die einflussreichste Rolle im System. Diese Rolle ist allein verantwortlich für die Konfiguration der Parameter auf Kontoebene. Benutzer mit der Rolle ACCOUNTADMIN können Snowflake-Abrechnungsdaten und Credit-Daten anzeigen und verwalten sowie alle in Ausführung befindlichen SQL-Anweisungen stoppen.

Beachten Sie, dass ACCOUNTADMIN keine Superuser-Rolle ist. Diese Rolle erlaubt nur dann das Anzeigen und Verwalten von Objekten im Konto, wenn diese Rolle oder eine Rolle, die in einer Rollenhierarchie untergeordnet ist, über ausreichende Berechtigungen für die Objekte verfügt.

In der Systemrollenhierarchie sind die anderen Administratorrollen untergeordnete Rollen dieser Rolle:

  • Die Rolle des Benutzeradministrators (USERADMIN) umfasst die Berechtigung zum Erstellen und Verwalten von Benutzern und Rollen (vorausgesetzt, die Eigentümerschaft dieser Rollen oder Benutzer wurde nicht an eine andere Rolle übertragen).

  • Die Rolle des Sicherheitsadministrators (d. h. Benutzer mit der Systemrolle SECURITYADMIN) enthält die globale Berechtigung MANAGE GRANTS, um Berechtigungen für Objekte im Konto zu erteilen oder zu entziehen. Die Rolle USERADMIN ist in der standardmäßigen Zugriffssteuerungshierarchie eine untergeordnete Rolle dieser Rolle.

  • 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 USERADMIN zugewiesen wird. Alle übrigen Benutzer sollten von einem der Benutzer mit der Rolle USERADMIN oder eine anderen Rolle mit der globalen CREATE USER-Berechtigung 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 Datenbank und Schema des Containers erteilt werden.

Angenommen, mytable wird 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 kundenspezifischen Rollen

Wenn eine kundenspezifische 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 kundenspezifische Rolle muss auch allen Rollen zugewiesen werden, die die von der kundenspezifischen Rolle erstellten Objekte verwalten.

Wichtig

Standardmäßig kann nicht einmal die Rolle ACCOUNTADMIN Objekte ändern oder löschen, die von einer kundenspezifischen Rolle erstellt wurden. Die kundenspezifische 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 von Rollenhierarchien 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.

Für eine optimale Flexibilität bei der Steuerung des Zugriffs auf Datenbankobjekte erstellen Sie eine Kombination von Objekt-Zugriffsrollen mit unterschiedlichen Berechtigungen auf Objekte und weisen diese entsprechend den Funktionsrollen zu:

  • Erteilen Sie Berechtigungen für Datenbankobjekte oder Kontenobjekte (z. B. Warehouse) für Zugriffsrollen.

  • Weisen Sie Zugriffsrollen funktionale Rollen zu, um eine Rollenhierarchie zu erstellen. Diese Rollen entsprechen den Geschäftsfunktionen Ihres Unternehmens und dienen als Sammelrollen für alle Zugriffsrollen, die für diese Funktionen erforderlich sind.

    Weisen Sie gegebenenfalls übergeordneten Funktionsrollen in einer Eltern-Kind-Beziehung untergeordnete Funktionsrollen zu, wobei die übergeordneten Rollen Geschäftsfunktionen abbilden, die die Berechtigungen der untergeordneten Rollen subsumieren sollen.

    Folgen Sie Best Practices für Rollenhierarchien, und weisen Sie der Rolle Systemadministrator (SYSADMIN) die funktionalen Rollen der höchsten Ebene in einer Rollenhierarchie zu. Systemadministratoren können dann allen Rollen in dieser Hierarchie Berechtigungen für Datenbankobjekte erteilen:

Bemerkung

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

Beispiel

Als einfaches Beispiel nehmen wir an, dass zwei Datenbanken in einem Konto, fin und hr, jeweils Lohnabrechnungs- und Mitarbeiterdaten enthalten. Buchhalter und Analysten in Ihrem Unternehmen benötigen unterschiedliche Berechtigungen für die Objekte in diesen Datenbanken, um ihre Geschäftsfunktionen ausführen zu können. Buchhalter sollten Lese-/Schreibzugriff auf fin haben, benötigen aber möglicherweise nur Lesezugriff auf hr, da die Mitarbeiter der Personalabteilung die Daten in dieser Datenbank pflegen. Analysten benötigen möglicherweise einen Nur-Lese-Zugriff auf beide Datenbanken.

Berechtigungen für vorhandene Datenbankobjekte werden über die folgende Hierarchie von Zugriffsrollen und Funktionsrollen erteilt:

Bemerkung

Wenn jeder Datenbank neue Objekte hinzugefügt werden, sollten Sie in Erwägung ziehen, den Rollen automatisch Berechtigungen für diese Objekte auf der Basis des Objekttyps (z. B. Schema, Tabelle oder Ansicht) zu erteilen. Weitere Informationen dazu finden Sie unter Vereinfachen der Berechtigungsverwaltung mithilfe von zukünftigen Zuweisungen (unter diesem Thema).

Kundenspezifische Rolle

Beschreibung

Berechtigungen

db_hr_r

Zugriffsrolle, die den Nur-Lese-Zugriff auf Tabellen in der Datenbank hr erlaubt.

USAGE auf Datenbank hr.

USAGE auf allen Schemas in der Datenbank hr.

SELECT auf allen Tabellen in der Datenbank hr.

db_fin_r

Zugriffsrolle, die den Nur-Lese-Zugriff auf Tabellen in der Datenbank fin erlaubt.

USAGE auf Datenbank fin.

USAGE auf allen Schemas in der Datenbank fin.

SELECT auf allen Tabellen in der Datenbank fin.

db_fin_rw

Zugriffsrolle, die Lese-/Schreibzugriff auf Tabellen in der Datenbank fin erlaubt.

USAGE auf Datenbank fin.

USAGE auf allen Schemas in der Datenbank fin.

SELECT, INSERT, UPDATE, DELETE auf allen Tabellen in der Datenbank fin.

accountant

Funktionale Rolle für Buchhalter in Ihrer Organisation.

N/A

analyst

Funktionale Rolle für Analysten in Ihrer Organisation.

N/A

Die folgende Abbildung zeigt die Rollenhierarchie für dieses Beispiel:

Example: Hierarchy of access and functional roles

So konfigurieren Sie die Zugriffssteuerung für dieses Beispiel:

  1. Erstellen Sie als Benutzeradministrator (Benutzer mit der Rolle USERADMIN) oder als Benutzer mit einer anderen Rolle, die über die Berechtigung CREATE ROLE für das Konto verfügt, die Zugriffsrollen und funktionalen Rollen aus diesem Beispiel:

    CREATE ROLE db_hr_r;
    CREATE ROLE db_fin_r;
    CREATE ROLE db_fin_rw;
    CREATE ROLE accountant;
    CREATE ROLE analyst;
    
    Copy
  2. Erteilen Sie als Sicherheitsadministrator (Benutzer mit der Rolle SECURITYADMIN) oder als Benutzer mit einer anderen Rolle, die über die Berechtigung MANAGE GRANTS für das Konto verfügt, den Zugriffsrollen die jeweils erforderlichen minimalen Berechtigungen:

    -- Grant read-only permissions on database HR to db_hr_r role.
    GRANT USAGE ON DATABASE hr TO ROLE db_hr_r;
    GRANT USAGE ON ALL SCHEMAS IN DATABASE hr TO ROLE db_hr_r;
    GRANT SELECT ON ALL TABLES IN DATABASE hr TO ROLE db_hr_r;
    
    -- Grant read-only permissions on database FIN to db_fin_r role.
    GRANT USAGE ON DATABASE fin TO ROLE db_fin_r;
    GRANT USAGE ON ALL SCHEMAS IN DATABASE fin TO ROLE db_fin_r;
    GRANT SELECT ON ALL TABLES IN DATABASE fin TO ROLE db_fin_r;
    
    -- Grant read-write permissions on database FIN to db_fin_rw role.
    GRANT USAGE ON DATABASE fin TO ROLE db_fin_rw;
    GRANT USAGE ON ALL SCHEMAS IN DATABASE fin TO ROLE db_fin_rw;
    GRANT SELECT,INSERT,UPDATE,DELETE ON ALL TABLES IN DATABASE fin TO ROLE db_fin_rw;
    
    Copy
  3. Weisen Sie als Sicherheitsadministrator (Benutzer mit der Rolle SECURITYADMIN) oder als Benutzer mit einer anderen Rolle, die über die Berechtigung MANAGE GRANTS für das Konto verfügt, der funktionalen Rolle accountant die Zugriffsrolle db_fin_rw zu und der funktionalen Rolle analyst die Zugriffsrollen db_hr_r und db_fin_r:

    GRANT ROLE db_fin_rw TO ROLE accountant;
    GRANT ROLE db_hr_r TO ROLE analyst;
    GRANT ROLE db_fin_r TO ROLE analyst;
    
    Copy
  4. Weisen Sie als Sicherheitsadministrator (Benutzer mit der Rolle SECURITYADMIN) oder als Benutzer mit einer anderen Rolle, die über die Berechtigung MANAGE GRANTS für das Konto verfügt, der Systemadministratorrolle SYSADMIN die Rollen analyst und accountant zu:

    GRANT ROLE accountant,analyst TO ROLE sysadmin;
    
    Copy
  5. Weisen Sie als Sicherheitsadministrator (Benutzer mit der Rolle SECURITYADMIN) oder als Benutzer mit einer anderen Rolle, die über die Berechtigung MANAGE GRANTS für das Konto verfügt, die Geschäftsfunktionsrollen den Benutzern zu, die diese Geschäftsfunktionen in Ihrer Organisation ausführen: In diesem Beispiel wird die funktionale Rolle analyst dem Benutzer user1 zugewiesen und die funktionale Rolle accountant dem Benutzer user2.

    GRANT ROLE accountant TO USER user1;
    GRANT ROLE analyst TO USER user2;
    
    Copy

Verwalten des Datenbankobjektzugriffs mithilfe von Datenbankrollen

Datenbankrollen entsprechen im Wesentlichen den üblichen Rollen, die auf Kontoebene erstellt werden (d. h. kundenspezifische Kontorollen), mit Ausnahme ihres Geltungsbereichs: Um SQL-Aktionen auf Objekte innerhalb einer Datenbank zu ermöglichen, können einer Datenbankrolle derselben Datenbank Berechtigungen erteilt werden.

Datenbankrollen sind für die folgenden Anwendungsfälle vorgesehen:

Einfache Verwaltung

Datenbankeigentümer können den Zugriff auf sicherungsfähige Objekte in ihren eigenen Datenbanken unabhängig voneinander verwalten. Datenbankeigentümer können die folgenden Aktionen ausführen:

  • Datenbankrollen erstellen und verwalten.

  • Datenbankrollen Berechtigungen zuweisen.

    Die den Datenbankrollen erteilten Berechtigungen für Objekte müssen sich auf Objekte beziehen, die in der Datenbank enthalten sind, in der die Rolle existiert. Berechtigungen für Objekte in einer Datenbank (z. B. Tabellen oder Ansichten) können nicht Datenbankrollen einer anderen Datenbank erteilt werden.

    Jede Berechtigung, einschließlich OWNERSHIP, kann Datenbankrollen für Objekte in einer Datenbank erteilt werden. Beachten Sie, dass die OWNERSHIP-Berechtigung für die Datenbank selbst nur einer Kontorolle erteilt werden kann.

  • Rollenhierarchie und Vererbung von Berechtigungen erstellen oder erweitern. Datenbankrollen können anderen Datenbankrollen innerhalb derselben Datenbank zugewiesen werden, und dann können die höchsten Datenbankrollen in der Rollenhierarchie einer Datenbank Kontorollen zugewiesen werden. Weitere Informationen dazu finden Sie unter Rollenhierarchie und Vererbung von Berechtigungen.

    Beachten Sie, dass durch das Zuweisen einer Datenbankrolle zu einer Kontorolle implizit die USAGE-Berechtigung für die Datenbank erteilt wird, die die Datenbankrolle zu dieser Kontorolle enthält. Ein explizites Erteilen der USAGE-Berechtigung für die Datenbank ist nicht erforderlich.

Data Sharing (Datenfreigabe)

Datenanbieter, die das Snowflake-Feature Secure Data Sharing verwenden, können die sicherungsfähigen Objekte einer Freigabe segmentieren, indem sie mehrere Datenbankrollen in der freizugebenden Datenbank erstellen und jeder Datenbankrolle Berechtigungen für eine Teilmenge der Objekte in der Datenbank erteilen. Nach dem Erstellen einer Datenbank aus einer Freigabe, die Datenbankrollen enthält, weisen die Datenverbraucher diese Datenbankrollen einer oder mehreren Kontorollen des eigenen Kontos zu.

Wenn keine Datenbankrollen verwendet werden, erteilen die Kontoadministratoren der Datenverbraucherkonten den Rollen nur die Berechtigung IMPORTED PRIVILEGES, wodurch ihre Benutzer Zugriff auf alle Datenbanken und Datenbankobjekte (Tabellen, sichere Ansichten usw.) einer Freigabe erhalten. Es gibt keine Option, bei der verschiedenen Benutzergruppen eines Datenverbraucherkontos der Zugriff auf Teilmengen der freigegebenen Objekte gestattet wird. Bei diesem Alles-oder-Nichts-Ansatz müssen Datenanbieter mehrere Freigaben erstellen, um den Zugriff auf verschiedene Objekte in denselben Datenbanken zu ermöglichen.

Beachten Sie, dass Datenbankrollen nicht direkt in einer Sitzung aktiviert werden können. Zuweisen von Datenbankrollen zu Kontorollen, die in einer Sitzung aktiviert werden können.

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.

Beachten Sie, dass eine Rolle mit der globalen Berechtigung MANAGE GRANTS der aktuellen (Berechtigungsgeber-)Rolle keine zusätzlichen Berechtigungen erteilen kann.

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

Vereinfachen der Berechtigungsverwaltung mithilfe von zukünftigen Berechtigungszuweisungen

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;
Copy

Weitere Informationen zu zukünftigen Zuweisungen finden Sie unter Festlegen zukünftiger Berechtigungszuweisungen zu Objekten.

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.