Snowflake-Sitzungen und Sitzungsrichtlinien

Unter diesem Thema werden Snowflake-Sitzungen und Sitzungsrichtlinien beschrieben sowie eine Anleitung zum Konfigurieren von Sitzungsrichtlinien auf Konto- oder Benutzerebene bereitgestellt.

Unter diesem Thema:

Snowflake-Sitzungen

Eine Sitzung beginnt, wenn ein Benutzer eine Verbindung zu Snowflake hergestellt und sich erfolgreich über einen programmgesteuerten Snowflake-Client, Snowsight oder die klassische Weboberfläche authentifiziert hat. Eine Sitzung ist unabhängig von einer Sitzung des Identitätsanbieters (d. h. IdP). Wenn die Snowflake-Sitzung abläuft, aber die IdP-Sitzung aktiv bleibt, kann sich ein Benutzer bei Snowflake anmelden, ohne seine Anmeldeinformationen erneut eingeben zu müssen (d. h. stille Authentifizierung).

Bei fortgesetzter Benutzeraktivität bleibt eine Sitzung auf unbestimmte Zeit aufrechterhalten. Nach einer Zeit der Inaktivität in der Sitzung, die als Sitzungstimeout bei Leerlauf bezeichnet wird, muss sich der Benutzer erneut bei Snowflake authentifizieren. Das Sitzungstimeout bei Leerlauf hat einen Höchstwert von vier Stunden, wobei dieser Wert über eine Sitzungsrichtlinie geändert werden kann. Das Sitzungstimeout bei Leerlauf gilt für Folgendes:

Snowflake empfiehlt, bestehende Sitzungen nach Möglichkeit wiederzuverwenden und die Verbindung zu Snowflake zu schließen, wenn eine Sitzung nicht mehr benötigt wird.

Snowsight-Sitzungen

Snowflake erstellt für jedes Arbeitsblatt in Snowsight eine neue Sitzung. Eine Arbeitsblattsitzung setzt die Sitzungsrichtlinie durch, die für den Benutzer gilt, der das Arbeitsblatt erstellt.

Vorsicht

Aktive Abfragen werden nicht abgebrochen, wenn die Sitzung endet und der Benutzer abgemeldet wird, auch wenn der Parameter ABORT_DETACHED_QUERY auf „true“ gesetzt ist.

Sitzungen der klassischen Konsole

Jedes Mal, wenn ein neues Arbeitsblatt erstellt wird, erstellt Snowflake auf der Registerkarte Worksheets Registerkarte „Arbeitsblatt“ eine neue Sitzung. Jedes Arbeitsblatt ist auf eine maximale Leerlaufzeit von 4 Stunden beschränkt, wobei das Leerlauf-Timeout wird für jedes Arbeitsblatt separat erfasst.

Wenn ein Arbeitsblatt geschlossen wird, endet die Benutzersitzung für dieses Arbeitsblatt.

Nach Ablauf des 4-Stunden-Zeitlimits für ein beliebiges offenes Arbeitsblatt meldet Snowflake den Benutzer bei der Weboberfläche ab.

Bemerkung

Beachten Sie, dass bei passivem Verhalten wie dem Blättern durch das Abfrage-Resultset oder das Sortieren eines Datasets der Leerlauf-Timeout-Tracker der Sitzung nicht zurückgesetzt wird.

Um zu verhindern, dass eine Sitzung zu früh geschlossen und von der klassischen Weboberfläche abgemeldet wird, müssen Sie alle benötigten SQL-Anweisungen in einer lokalen Datei speichern und alle offenen, nicht verwendeten Arbeitsblätter schließen.

Sitzungsrichtlinien

Eine Sitzungsrichtlinie definiert das Sitzungstimeout nach Leerlauf in Minuten und bietet die Option, den für das Leerlauf-Timeout definierten Standardwert von 4 Stunden zu überschreiben.

Die Sitzungsrichtlinie kann für ein Konto oder einen Benutzer mit konfigurierbaren Timeoutperioden nach Leerlauf festgelegt werden, um Compliance-Anforderungen zu erfüllen. Wenn ein Benutzer mit einer Sitzungsrichtlinie sowohl auf Konto- als auch auf Benutzerebene verbunden ist, hat die Sitzungsrichtlinie auf Benutzerebene Vorrang. Nachdem die Sitzungsrichtlinie für das Konto oder den Benutzer festgelegt wurde, setzt Snowflake die Sitzungsrichtlinie durch.

Es gibt zwei Eigenschaften, die das Verhalten der Sitzungsrichtlinie bestimmen:

  • SESSION_IDLE_TIMEOUT_MINS für programmgesteuerte Clients und Snowflake-Clients

  • SESSION_UI_IDLE_TIMEOUT_MINS für die klassische Weboberfläche und für Snowsight.

Die Timeout-Periode beginnt nach erfolgreicher Authentifizierung bei Snowflake. Ist keine Sitzungsrichtlinie festgelegt, verwendet Snowflake einen Standardwert von 240 Minuten (d. h. 4 Stunden). Der minimale konfigurierbare Wert für das Leerlauf-Timeout einer Sitzungsrichtlinie ist 5 Minuten. Nach Ablauf des Sitzungstimeouts muss sich der Benutzer erneut bei Snowflake authentifizieren. Snowflake setzt jedoch keine der durch Kundenspezifischer Logout-Endpunkt definierten Einstellungen durch.

Weitere Informationen dazu finden Sie unter:

Hinweise

  • Wenn ein Client die Option CLIENT_SESSION_KEEP_ALIVE unterstützt und die Option auf TRUE gesetzt ist, behält der Client die Snowflake-Sitzung auf unbestimmte Zeit bei, solange die Verbindung zu Snowflake aktiv ist. Wenn die Option dagegen auf FALSE gesetzt ist, endet die Sitzung nach 4 Stunden. Wenn möglich, sollten Sie diese Option vermeiden, da sie zu vielen offenen Sitzungen führen kann und die Ressourcen stärker beansprucht, was zu Beeinträchtigungen der Leistung führen kann.

  • Sie können den CLIENT_SESSION_KEEP_ALIVE_HEARTBEAT_FREQUENCY-Parameter verwenden, um die Anzahl der Sekunden anzugeben, die zwischen den Versuchen des Clients liegen, das Token für die Sitzung zu aktualisieren. Die Weboberflächensitzung kann aktualisiert werden, wenn Snowflake-Objekte weiter verwendet werden, z. B. bei der Ausführung von DDL- und DML-Anweisungen. Snowflake führt alle 30 Sekunden eine Prüfung auf dieses Verhalten aus.

  • Beim Erstellen eines neuen Arbeitsblatts oder beim Öffnen eines vorhandenen Arbeitsblatts wird weiterhin die bestehende Benutzersitzung verwendet, wobei jedoch das Leerlauf-Sitzungstimeout auf 0 zurückgesetzt wird.

  • Verfolgen der Nutzung von Sitzungsrichtlinien:

    • Fragen Sie die Account Usage-Ansicht SESSION_POLICIES ab, um eine Zeile für jede Sitzungsrichtlinie in Ihrem Snowflake-Konto zurückzugeben.

    • Verwenden Sie die Information Schema-Tabellenfunktion POLICY_REFERENCES, um eine Zeile für jeden Benutzer zurückzugeben, der der angegebenen Sitzungsrichtlinie zugeordnet ist, und eine Zeile für die dem Snowflake-Konto zugeordnete Sitzungsrichtlinie.

      Derzeit wird nur die folgende Syntax für Sitzungsrichtlinien unterstützt:

      POLICY_REFERENCES( POLICY_NAME => '<session_policy_name>' )
      
      Copy

      Wobei session_policy_name der vollqualifizierte Name der Sitzungsrichtlinie ist.

      Führen Sie zum Beispiel die folgende Abfrage aus, um eine Zeile für jeden Benutzer zurückzugeben, dem die Sitzungsrichtlinie mit dem Namen session_policy_prod_1 zugewiesen ist, die in der Datenbank mit dem Namen my_db und dem Schema mit dem Namen my_schema gespeichert ist:

      SELECT *
      FROM TABLE(
        MY_DB.INFORMATION_SCHEMA.POLICY_REFERENCES(
          POLICY_NAME => 'my_db.my_schema.session_policy_prod_1'
        )
      );
      
      Copy

Einschränkungen

Zukünftige Berechtigungszuweisungen:

Zukünftige Berechtigungszuweisungen zu Sitzungsrichtlinien werden nicht unterstützt.

Als Problemumgehung können Sie einer kundenspezifischen Rolle die Berechtigung APPLYSESSION POLICY zuweisen, damit diese Rolle Sitzungsrichtlinien auf ein Snowflake-Konto anwenden kann.

Implementieren einer Sitzungsrichtlinie

Die folgenden Schritte sind eine repräsentative Anleitung für die Implementierung einer Sitzungsrichtlinie.

Bei diesen Schritten wird von einem zentralen Verwaltungsansatz ausgegangen, bei dem eine kundenspezifische Rolle mit dem Namen policy_admin Eigentümer der Sitzungsrichtlinie ist (d. h. die Berechtigung OWNERSHIP für die Sitzungsrichtlinie hat) und für die Festlegung der Sitzungsrichtlinie für ein Konto oder einen Benutzer verantwortlich ist (d. h. die Berechtigung APPLY SESSION POLICY ON ACCOUNT oder die Berechtigung APPLY SESSION POLICY ON USER hat).

Bemerkung

Um eine Richtlinie für ein Konto festzulegen, muss die kundenspezifische Rolle policy_admin über die folgenden Berechtigungen verfügen:

  • USAGE für Datenbank und Schema, die die Sitzungsrichtlinie enthalten

  • CREATE SESSION POLICY für das Schema, das die Sitzungsrichtlinie enthält

Gehen Sie folgendermaßen vor, um eine Sitzungsrichtlinie zu implementieren.

Schritt 1: Kundenspezifische Rolle POLICY_ADMIN erstellen

Erstellen Sie eine kundenspezifische Rolle, mit der Benutzer Sitzungsrichtlinien erstellen und verwalten können. Unter diesem Thema wird die kundenspezifische Rolle als policy_admin bezeichnet, obwohl die Rolle jeden beliebigen Namen haben kann.

Wenn die kundenspezifische Rolle bereits vorhanden ist, fahren Sie mit dem nächsten Schritt fort.

Erstellen Sie andernfalls die kundenspezifische Rolle POLICY_ADMIN.

USE ROLE USERADMIN;

CREATE ROLE policy_admin;
Copy

Schritt 2: Kundenspezifischer Rolle POLICY_ADMIN Berechtigungen zuweisen

Wenn die kundenspezifische Rolle POLICY_ADMIN nicht bereits über die folgenden Berechtigungen verfügt, weisen Sie ihr folgende Berechtigungen zu:

  • USAGE für Datenbank und Schema, die die Sitzungsrichtlinie enthalten wird

  • CREATE SESSION POLICY für das Schema, das die Sitzungsrichtlinie enthalten wird

  • APPLY SESSION POLICY für das Konto

  • APPLY SESSION POLICY für jeden Benutzer, wenn Sitzungsrichtlinien auf Benutzerebene eingerichtet werden sollen

USE ROLE SECURITYADMIN;

GRANT USAGE ON DATABASE mydb TO ROLE policy_admin;

GRANT USAGE, CREATE SESSION POLICY ON SCHEMA mydb.policies TO ROLE policy_admin;

GRANT APPLY SESSION POLICY ON ACCOUNT TO ROLE policy_admin;
Copy

Wenn Sie eine Sitzungsrichtlinie mit einem einzelnen Benutzer verknüpfen:

GRANT APPLY SESSION POLICY ON USER jsmith TO ROLE policy_admin;
Copy

Weitere Informationen dazu finden Sie unter Übersicht der DDL-Befehle, Operationen und Berechtigungen.

Schritt 3: Neue Sitzungsrichtlinie erstellen

Erstellen Sie mit der kundenspezifischen Rolle POLICY_ADMIN eine neue Sitzungsrichtlinie, bei der der Wert für das Leerlauf-Timeout von programmgesteuerten Clients, Snowflake-Clients und der Weboberfläche jeweils 60 Minuten beträgt. Weitere Informationen dazu finden Sie unter CREATE SESSION POLICY.

USE ROLE POLICY_ADMIN;

CREATE SESSION POLICY mydb.policies.session_policy_prod_1
  SESSION_IDLE_TIMEOUT_MINS = 60
  SESSION_UI_IDLE_TIMEOUT_MINS = 60
  COMMENT = 'Session policy for the prod_1 environment'
;
Copy

Wobei:

mydb.policies.session_policy_prod_1

Der vollqualifizierte Name der Sitzungsrichtlinie.

session_idle_timeout_mins = 60

Das Leerlauf-Timeout in Minuten für Snowflake-Clients und programmgesteuerte Clients.

session_ui_idle_timeout_mins = 30

Das Leerlauf-Timeout in Minuten für die Snowflake-Weboberfläche.

comment = 'Session policy for the prod_1 environment'

Ein Kommentar, der den Zweck der Sitzungsrichtlinie angibt.

Schritt 4: Sitzungsrichtlinie für ein Konto oder einen Benutzer festlegen

Unter Verwendung der kundenspezifischen Rolle POLICY_ADMIN legen Sie mit dem Befehl ALTER ACCOUNT die Richtlinie für ein Konto oder mit dem Befehl ALTER USER die Richtlinie für einen Benutzer (z. B. Benutzername jsmith) fest.

USE ROLE policy_admin;

ALTER ACCOUNT SET SESSION POLICY mydb.policies.session_policy_prod_1;

ALTER USER jsmith SET SESSION POLICY my_database.my_schema.session_policy_prod_1_jsmith;
Copy

Wichtig

Um eine Sitzungsrichtlinie zu ersetzen, die bereits für ein Konto oder einen Benutzer festgelegt ist, heben Sie zuerst die Sitzungsrichtlinie auf, und legen Sie dann die neue Sitzungsrichtlinie für das Konto oder den Benutzer fest. Beispiel:

ALTER ACCOUNT UNSET session policy;

ALTER ACCOUNT SET SESSION POLICY mydb.policies.session_policy_prod_2;
Copy

Schritt 5: Sitzungsrichtlinie in Zielkonto replizieren

Eine Sitzungsrichtlinie und deren Referenzen (d. h. Zuweisungen zu einem Benutzer oder dem Konto) können mithilfe der Datenbankreplikation und der Kontoreplikation vom Quellkonto in das Zielkonto repliziert werden. Weitere Informationen dazu finden Sie unter:

Verwalten von Sitzungsrichtlinien

Übersicht zu Berechtigungen für Sitzungsrichtlinien

Snowflake unterstützt die folgenden Berechtigungen für Sitzungsrichtlinien, um zu bestimmen, ob Benutzer Sitzungsrichtlinien erstellen, festlegen und besitzen können.

Beachten Sie, dass für die Bearbeitung eines Objekts in einem Schema auch die Berechtigung USAGE für die übergeordnete Datenbank und das Schema erforderlich ist.

Berechtigung

Verwendung

CREATE

Ermöglicht das Erstellen einer neuen Sitzungsrichtlinie in einem Schema.

APPLY SESSION POLICY

Ermöglicht das Anwenden einer Sitzungsrichtlinie auf Konto- oder Benutzerebene.

OWNERSHIP

Gewährt volle Kontrolle über die Sitzungsrichtlinie. Erforderlich, um die meisten Eigenschaften einer Sitzungsrichtlinie zu ändern.

Übersicht der DDL-Befehle, Operationen und Berechtigungen

In der folgenden Tabelle wird die Beziehung zwischen den DDL-Operationen für Sitzungsrichtlinien und den dafür erforderlichen Berechtigungen zusammengefasst.

Operation

Erforderliche Berechtigung

Sitzungsrichtlinie erstellen

Eine Rolle mit CREATESESSIONPOLICY-Berechtigung für das Schema.

Sitzungsrichtlinie ändern

Eine Rolle mit OWNERSHIP-Berechtigung für die Sitzungsrichtlinie.

Sitzungsrichtlinie löschen

Eine Rolle mit OWNERSHIP-Berechtigung für die Sitzungsrichtlinie.

Sitzungsrichtlinie beschreiben

Eine Rolle mit OWNERSHIP-Berechtigung für die Sitzungsrichtlinie oder . mit APPLY SESSION POLICY-Berechtigung für das Konto.

Sitzungsrichtlinien anzeigen

Eine Rolle mit OWNERSHIP-Berechtigung für die Sitzungsrichtlinie oder . mit APPLY SESSION POLICY-Berechtigung für das Konto.

Sitzungsrichtlinie festlegen/aufheben

Bei Konten eine Rolle mit der Berechtigung APPLY SESSION POLICY für das Konto und der Berechtigung OWNERSHIP für die Sitzungsrichtlinie oder eine Rolle mit der Berechtigung APPLY SESSION POLICY für das Konto und der Berechtigung APPLY ON SESSION POLICY für eine bestimmte Sitzungsrichtlinie.

Bei Benutzern eine Rolle mit der Berechtigung APPLY SESSION POLICY ON USER <Name_des_Benutzers>.

Übersicht zu DDL für Sitzungsrichtlinien

Snowflake bietet die folgenden DDL-Befehle zum Verwalten von Sitzungsrichtlinienobjekten:

Um eine Sitzungsrichtlinie für das Konto festzulegen oder aufzuheben, führen Sie den Befehl ALTER ACCOUNT wie unten gezeigt aus.

ALTER ACCOUNT SET SESSION POLICY mydb.policies.session_policy_prod_1;
Copy
ALTER ACCOUNT UNSET SESSION POLICY;
Copy

Um eine Sitzungsrichtlinie auf Benutzerebene festzulegen oder aufzuheben, führen Sie den Befehl ALTER USER wie unten gezeigt aus.

ALTER USER jsmith SET SESSION POLICY mydb.policies.session_policy_prod_1_jsmith;
Copy
ALTER USER jsmith UNSET SESSION POLICY;
Copy

Problembehandlung für Sitzungsrichtlinien

  • Wenn einem Konto oder einem Benutzer eine Sitzungsrichtlinie zugewiesen ist und die Datenbank oder das Schema, die bzw. das die Sitzungsrichtlinie enthält, gelöscht wird, und dann dem Konto oder dem Benutzer eine neue Sitzungsrichtlinie zugewiesen wird, ist der Benutzer nicht an das Sitzungstimeout nach Leerlauf der neuen Sitzungsrichtlinie gebunden.

    Die Problemumgehung besteht darin, die ursprüngliche Sitzungsrichtlinie rückgängig zu machen: bei einem Konto mit dem ALTER ACCOUNT-Befehl und bei einem Benutzer mit dem ALTER USER-Befehl, wie unter diesem Thema gezeigt.

  • In der folgenden Tabelle sind einige Fehlermeldungen zusammengefasst, die bei Sitzungsrichtlinien auftreten können.

    Verhalten

    Fehlermeldung

    Problembehandlung

    Sitzungsrichtlinie kann nicht erstellt werden.

    Cannot perform CREATE SESSION POLICY. This session does not have a current database. Call ‚USE DATABASE‘, or use a qualified name.

    Geben Sie vor der Ausführung von CREATE SESSION POLICY eine Datenbank an, oder verwenden Sie in der Anweisung CREATE SESSION POLICY den vollqualifizierten Objektnamen.

    Sitzungsrichtlinie kann nicht erstellt werden.

    SQL access control error: Insufficient privileges to operate on schema ‚<Name_des_Schemas>‘

    Überprüfen Sie, ob die Rolle, die die Anweisung CREATE SESSION POLICY-Anweisung ausführt, Berechtigung CREATE SESSION POLICY ON SCHEMA.

    Sitzungsrichtlinie kann nicht erstellt werden.

    SQL compilation error: Database ‚<Name_der_Datenbank>‘ does not exist or not authorized.

    Überprüfen Sie, ob die Datenbank vorhanden ist und die Rolle, die die CREATE SESSION POLICY-Anweisung ausführt, die USAGE-Berechtigung für das Schema hat, in dem die Sitzungsrichtlinie vorhanden sein soll.

    DESCRIBE-Anweisung kann nicht ausgeführt werden.

    SQL compilation error: Schema ‚<Name_des_Schemas>‘ does not exist or not authorized.

    Überprüfen Sie, ob die Rolle, die die DESC SESSION POLICY-Anweisung ausführt, die OWNERSHIP-Berechtigung für die Sitzungsrichtlinie oder die APPLY-Berechtigung für die Sitzungsrichtlinie hat.

    Sitzungsrichtlinie kann nicht gelöscht werden.

    SQL compilation error: Session policy ‚<Name_der_Richtlinie>‘ does not exist or not authorized.

    Überprüfen Sie, ob die Rolle, die die DROP SESSION POLICY-Anweisung ausführt, die Berechtigung OWNERSHIP für die Sitzungsrichtlinie hat.

    Sitzungsrichtlinie kann nicht gelöscht werden.

    Session policy <Name_der_Richtlinie> cannot be dropped because it is attached to an account.

    Heben Sie die Sitzungsrichtlinie für das Konto mit einer ALTER ACCOUNT-Anweisung auf, und führen Sie die Drop-Anweisung erneut aus.

    Sitzungsrichtlinie kann für Konto nicht festgelegt werden.

    Session policy ‚<Name_der_Richtlinie> is already attached to account <Name_des_Kontos>.

    Ein Konto kann nur eine aktive Sitzungsrichtlinie haben. Bestimmen Sie, welche Sitzungsrichtlinie für das Konto festgelegt werden soll. . Falls erforderlich, heben Sie die aktuelle Sitzungsrichtlinie für das Konto mit einem ALTER ACCOUNT-Befehl auf, und legen Sie dann die andere Sitzungsrichtlinie für das Konto mit einem weiteren ALTER ACCOUNT-Befehl fest.

    Timeout-Wert kann nicht festgelegt werden.

    SQL compilation error: invalid value ‚<Ganzzahl>‘ for property ‚session_idle_timeout_mins‘

    Der Wert für das Sitzungstimeout in Minuten muss eine ganze Zahl zwischen 5 und 240 (einschließlich) sein. . Wählen Sie eine gültige Ganzzahl für das Sitzungstimeout, und führen Sie die Anweisung CREATE OR ALTER SESSION POLICY erneut aus.

    Bestehende Sitzungsrichtlinie kann nicht aktualisiert werden.

    SQL compilation error: Session policy ‚<Name_der_Richtlinie>‘ does not exist or not authorized.

    Überprüfen Sie den Namen der Sitzungsrichtlinie, die Syntax des ALTER SESSION POLICY-Befehls und die Berechtigungen zum Bearbeiten der Sitzungsrichtlinie, der Datenbank und des Schemas.