Bundle 2022_08¶

SAML2-Sicherheitsintegrationen bearbeiten: Durchsetzen des Gültigkeitszeitraums von X.509-Zertifikaten¶

Bei der Definition einer SAML2.Sicherheitsintegration zur Aktivierung von Single Sign-On gibt der Sicherheitsadministrator mit dem Parameter SAML2_X509_CERT ein X.509-Zertifikat an.

Snowflake erzwingt nun die Einhaltung des Gültigkeitszeitraums dieser X.509-Zertifikate, sodass abgelaufene Zertifikate zu einer fehlgeschlagenen Authentifizierung führen. Bei Zertifikaten mit einem NotBefore-Datum, das noch nicht erreicht ist, schlägt die Authentifizierung ebenfalls fehl. Die Durchsetzung von Gültigkeitszeiträumen kann nicht deaktiviert werden.

Bisher:

Snowflake überprüfte nicht das Gültigkeitsdatum eines X.509-Zertifikats, um festzustellen, ob das Zertifikat abgelaufen ist bzw. ob das NotBefore-Datum bereits erreicht ist.

Jetzt:

Snowflake erzwingt die Einhaltung des Gültigkeitszeitraums eines X.509-Zertifikats. Wenn das aktuelle Datum nicht in den Gültigkeitszeitraum des Zertifikats fällt, schlägt die Authentifizierung fehl.

Datenbanken und Schemas: Löschen oder Ersetzen unzulässig, wenn dies in Kennwortrichtlinien oder Sitzungsrichtlinien zu verwaisten Referenzen führt¶

Das Verhalten der Operationen DROP SCHEMA, DROP DATABASE, CREATE OR REPLACE DATABASE und CREATE OR REPLACE SCHEMA in Bezug auf eine Kennwortrichtlinie oder eine Sitzungsrichtlinie hat sich wie folgt geändert:

Bisher:

Snowflake ließ DROP- und REPLACE-Operationen für Schema/Datenbank zu, wenn diese eine Richtlinie enthielten und diese Richtlinie für das Snowflake-Konto festgelegt wurde, das die Richtlinie enthielt, oder wenn die Richtlinie für einen Benutzer desselben Kontos festgelegt wurde.

Jetzt:

Snowflake lässt DROP- und REPLACE-Operationen für Schema/Datenbank zu, wenn diese eine Richtlinie enthalten und diese Richtlinie für das Snowflake-Konto festgelegt ist, das die Richtlinie enthält, oder wenn die Richtlinie für einen Benutzer desselben Kontos festgelegt ist.

Infolgedessen hat sich das Verhalten der vier oben genannten Befehle wir folgt geändert:

• DROP DATABASE

• DROP SCHEMA

• CREATE OR REPLACE DATABASE

• CREATE OR REPLACE SCHEMA

Je nach Operation gibt Snowflake eine der folgenden Fehlermeldungen zurück:

Für einen Benutzer festgelegte Richtlinie:

DROP DATABASE und CREATE OR REPLACE DATABASE:

Cannot drop database because policy 'MYDB.MYSCHEMA.POLICY1' is set on user 'JSMITH'. Unset the policy 'MYDB.MYSCHEMA.POLICY1' and then try the drop operation again.

DROP SCHEMA und CREATE OR REPLACE SCHEMA:

Cannot drop schema because policy 'MYDB.MYSCHEMA.POLICY1' is set on user 'JSMITH'. Unset the policy 'MYDB.MYSCHEMA.POLICY1' and then try the drop operation again.

Für das Konto festgelegte Richtlinie:

DROP DATABASE und CREATE OR REPLACE DATABASE:

Cannot drop database because policy 'MYDB.MYSCHEMA.POLICY1' is set on account 'MYACCOUNT'. Unset the policy 'MYDB.MYSCHEMA.POLICY1' and then try the drop operation again.

DROP SCHEMA und CREATE OR REPLACE SCHEMA:

Cannot drop schema because policy 'MYDB.MYSCHEMA.POLICY1' is set on account 'MYACC

Befehl SHOW FUNCTIONS: Neue Spalte in Ausgabe¶

Der Ausgabe des Befehls SHOW FUNCTIONS wurden die folgenden Spalten hinzugefügt:

Um die Auswirkungen dieser Neuerung zu minimieren, wurde die Spalte als letzte Spalte der Ausgabe hinzugefügt.

Befehl SHOW VIEWS: Neue Spalte in Ausgabe¶

Die Ausgabe von SHOW VIEWS enthält jetzt die neue Spalte CHANGE_TRACKING. Diese Spalte zeigt an, ob die Änderungsverfolgung für die Ansicht aktiviert ist.

Folgende Werte können in der Spalte für einzelne Ansichten angezeigt werden:

• ON: Die Änderungsverfolgung ist aktiviert. Sie können die Änderungsverfolgungsdaten mit Streams oder mit der CHANGES-Klausel für SELECT-Anweisungen abfragen.

• OFF: Die Änderungsverfolgung derzeit deaktiviert, kann aber aktiviert werden.

Um die Auswirkungen dieser Änderung zu begrenzen, wurde die Spalte als letzte Spalte der Ausgabe hinzugefügt.

Funktion GET_DDL: Unterstützung von Tags und Richtlinien hinzugefügt¶

Die Funktion GET_DDL unterstützt nun Tags und Richtlinien wie folgt:

• Wenn ein Tag auf einer Tabelle, einer Ansicht oder einer materialisierten Ansicht gesetzt ist, enthält die Ausgabe des Aufrufs der GET_DDL-Funktion die Tag-Zuweisungen aus der CREATE-Anweisung.

• Wenn ein oder mehrere Tags auf einem Schema oder einer Datenbank gesetzt sind, enthält die Ausgabe des Aufrufs der GET_DDL-Funktion die folgenden Anweisungen für das Zuweisen der Tags:

  • Eine ALTER DATABASE-Anweisung, wenn das Tag auf der Datenbank gesetzt ist.

  • Eine ALTER SCHEMA-Anweisung, wenn das Tag auf dem Schema gesetzt ist.

  • Eine ALTER DATABASE-Anweisung und eine ALTER SCHEMA-Anweisung, wenn das Tag sowohl auf der Datenbank als auch auf dem Schema gesetzt ist.

• Wenn ein Tag in einem Schema erstellt wurde und dieses Schema beim Aufrufen der GET_DDL-Funktion angegeben wird, enthält die Ausgabe eine CREATE OR REPLACE-Anweisung für das Generieren des Tags.

  Dasselbe gilt für ein Tag, das in einer Datenbank erstellt wurde: Wird die Datenbank beim Aufrufen der GET_DDL-Funktion angegeben, enthält die Ausgabe die CREATE OR REPLACE-Anweisung zum Generieren des Tags.

• Wenn eine Zeilenzugriffsrichtlinie für eine Tabelle oder Ansicht bzw. eine Maskierungsrichtlinie für eine Spalte festgelegt wurde, wird beim Aufrufen der GET_DDL-Funktion auf der Tabelle oder Ansicht das Schlüsselwort WITH hinzugefügt, um anzugeben, dass die Richtlinie in der CREATE-Anweisung für die Tabelle, Ansicht oder Spalte gesetzt ist.

  Beachten Sie, dass beim manuellen Erstellen einer Tabelle die Angabe des Schlüsselworts WITH optional ist, wenn Sie eine Zeilenzugriffsrichtlinie für die Tabelle oder Ansicht bzw. eine Maskierungsrichtlinie für eine Spalte festlegen.

Data Sharing Usage-Ansichten: Änderungen an Spalten in Ansichten¶

Alle Ansichten im DATA_SHARING_USAGE-Schema (der freigegebenen SNOWFLAKE-Datenbank) haben sich wie folgt geändert:

Bisher:

Die in der Spalte SNOWFLAKE_REGION der Ansichten angezeigten Daten wurden im Format <Cloud> <Region> in Kleinbuchstaben angezeigt (z. B. aws us_west_2). Dies war nicht konsistent mit den Werten, die in der SHOW REGIONS-Ausgabe für Snowflake-Regionen angezeigt wurden.

Betroffene Ansichten:

• LISTING_ACCESS_HISTORY

• LISTING_CONSUMPTION_DAILY

• LISTING_EVENTS_DAILY

• LISTING_TELEMETRY_DAILY

Jetzt:

In den oben aufgeführten Ansichten werden die Werte in der Spalte SNOWFLAKE_REGION jetzt im Format <Cloud>_<Region> durchgängig in Großbuchstaben angezeigt. Somit ist diese Ausgabe mit der Ausgabe von SHOW REGIONS konsistent.

Beispiel: Die Region us_west_2 in AWS wird jetzt als AWS_US_WEST_2 angezeigt.

Data Sharing-Nutzungsansichten: Neue Spalte in Ansichten¶

Diese Ankündigung wurde am 13. Februar 2023 hinzugefügt.

Die Spalte REGION_GROUP wurde zu folgenden Ansichten des DATA_SHARING_USAGE-Schemas hinzugefügt:

• LISTING_ACCESS_HISTORY

• LISTING_CONSUMPTION_DAILY

• LISTING_EVENTS_DAILY

• LISTING_TELEMETRY_DAILY

Um die Auswirkungen dieser Neuerung zu minimieren, wurde die Spalte REGION_GROUP als letzte Spalte der Ausgabe hinzugefügt.

Ansicht ACCESS_HISTORY (Account Usage): Neue Spalten in der Ansicht¶

Die folgenden Spalten wurden zur Ansicht ACCESS_HISTORY (im ACCOUNT_USAGE-Schema) hinzugefügt:

• object_modified_by_ddl

• policies_referenced

Um die Auswirkungen dieser Neuerung zu minimieren, wurden diese Spalten als letzte Spalten der Ausgabe hinzugefügt.

Beachten Sie, dass es sich bei diesen Spalten um Platzhalter handelt, die in einem der nächsten Releases befüllt werden.

Ansicht FUNCTIONS (Information Schema): Neue Spalte in der Ausgabe¶

Die folgende Spalte wurde der Information Schema-Ansicht FUNCTIONS (im INFORMATION_SCHEMA-Schema) hinzugefügt:

Um die Auswirkungen dieser Neuerung zu minimieren, wurde die Spalte als letzte Spalte der Ansicht hinzugefügt.

Ansicht TABLE_CONSTRAINTS (Account Usage): Neue Spalte in der Ansicht¶

Der Ansicht TABLE_CONSTRAINTS (im ACCOUNT_USAGE-Schema) wurde folgende neue Spalte hinzugefügt:

Ansicht USAGE_IN_CURRENCY_DAILY (Organization Usage): Neue Spalte in der Ansicht¶

Die Ansicht USAGE_IN_CURRENCY_DAILY (im ORGANIZATION_USAGE-Schema) enthält jetzt folgende neue Spalte:

Um die Auswirkungen dieser Änderung zu begrenzen, wurde die Spalte als letzte Spalte der Ansicht hinzugefügt.

Ansicht USERS (Account Usage): Neue Spalte in der Ansicht¶

Die Ansicht USERS (im ACCOUNT_USAGE-Schema) wurde aktualisiert und enthält nun eine neue Spalte USER_ID.

Verbraucher: SHOW-Befehle geben Fehler zurück, wenn Konto aus Freigabe entfernt wurde¶

Das Verhalten der SHOW <Objekte>-Befehle in einem Verbraucherkonto, dem der Zugriff auf eine Freigabe entzogen wurde, hat sich wie folgt geändert:

Bisher:

Wenn ein Verbraucherkonto zwei oder mehr Freigaben eingebunden hatte, die dieselben Anbieterobjekte enthielten, und der Anbieter entzog dann dem Konto eine der Freigaben, wurden Daten zurückgegeben, wenn auf der eingebundenen Datenbank oder auf dem eingebundenen Schema der verbleibenden Freigaben des Verbraucherkontos SHOW-Befehle ausgeführt wurden.

Beispiel: share1 und share2 enthalten dieselben Anbieterobjekte und werden in das Verbraucherkonto xy12345 eingebunden, und dann entfernte der Anbieter das Konto aus share2:

alter share share2 remove accounts = xy12345;

Copy

Wenn einer der folgenden Befehle im Verbraucherkonto ausgeführt wurde, wurden gültige Daten zurückgegeben:

SHOW <objects> IN DATABASE <revoked_mounted_db>;

SHOW <objects> IN SCHEMA <revoked_mounted_db>.<schema>;

Copy

Jetzt:

Bei demselben Szenario wird nun bei Ausführung der oben beschriebenen SHOW-Befehle eine Fehlermeldung ähnlich der folgenden zurückgegeben:

SQL compilation error: <Details zum spezifischen Fehler>.

Netzwerkrichtlinien: Verwaiste Referenzen bei Richtlinien mit Replikation und Failover/Failback¶

Das Verhalten von Replikation und Netzwerkrichtlinien sowie von Failover/Failback und Netzwerkrichtlinien hat sich wie folgt geändert:

Bisher:

Mit Netzwerkrichtlinien und deren Referenzen (d. h. Zuweisungen zu Primärkonto und Benutzern im Primärkonto):

• Geben Sie USERS und NETWORK POLICIES in der Replikations-/Failover-Gruppe an, wenn es Netzwerkrichtlinien auf Benutzerebene gibt.

• Geben Sie NETWORK POLICIES in der Replikations-/Failover-Gruppe an, wenn es nur Netzwerkrichtlinien auf Kontoebene gibt.

• Replikation und Failover/Failback traten auch dann auf, wenn das Ergebnis eine verwaiste Referenz im Zielkonto war.

Eine verwaiste Referenz bedeutet, dass ein Objekt im Sekundärkonto auf ein Objekt verweist, das nicht im selben Konto existiert. Beispiel:

• Ein Benutzer/Benutzername im Sekundärkonto verweist auf eine Netzwerkrichtlinie, die sich nicht im Sekundärkonto befindet. Dieses Szenario tritt auf, wenn eine Netzwerkrichtlinie einem Benutzer im Primärkonto zugewiesen wird und die Replikations-/Failover-Gruppe USERS, aber nicht NETWORK POLICIES angibt.

• Dem Primärkonto ist eine Netzwerkrichtlinie zugeordnet, und die Replikations-/Failover-Gruppe enthält nicht NETWORK POLICIES.

Jetzt:

Dieses Verhalten hat sich wie folgt geändert:

• Geben Sie ACCOUNT PARAMETERS, USERS und NETWORK POLICIES in der Replikations-/Failover-Gruppe an, wenn es Netzwerkrichtlinien auf Benutzerebene gibt.

• Geben Sie ACCOUNT PARAMETERS und NETWORK POLICIES in der Replikations-/Failover-Gruppe an, wenn es nur Netzwerkrichtlinien auf Kontoebene gibt.

• Replikation und Failover/Failback schlagen im Sekundärkonto fehl, wenn das Ergebnis eine verwaiste Referenz ist.

Wenn beispielsweise für das Primärkonto eine Netzwerkrichtlinie auf Kontoebene und eine Netzwerkrichtlinie auf Benutzerebene für einen Benutzer festgelegt ist, dann werden im Zielkonto sowohl für den Parameter auf Kontoebene als auch für den Benutzer verwaiste Referenzen erstellt:

Dangling references in the snapshot. Correct the errors before refreshing again. The following references are missing (referred entity <- [referring entities]):

ACCOUNT PARAMETERS <- [NETWORK POLICIES]. Add ACCOUNT PARAMETER into the replication group to fix it.

NETWORK_POLICY 'MYACCOUNT.P2' <- [USER 'MYACCOUNT.USERNAME']

Copy

Andernfalls wird in der Fehlermeldung entweder die Kontoparameteranweisung oder die Benutzeranweisung angegeben, je nachdem, wie die Replikationsgruppe konfiguriert ist und wie das Ergebnis im Zielkonto aussehen würde.

Replikationsgruppen: Beschränkung der Mitgliedschaft von Kontoobjekten auf eine einzigen Gruppe¶

Die Kontoreplikation ermöglicht die Replikation von Kontoobjekten in einer Replikations- oder Failover-Gruppe. Mögliche Kontoobjekte sind Kontoparameter, Rollen, Sicherheitsobjekte und Benutzer. Eine vollständige Liste der unterstützten Objekte finden Sie unter Replizierte Objekte.

Wenn ein Konto derzeit keiner Failover-Gruppe angehört, die Kontoobjekttypen enthält, können verschiedene Kontoobjekttypen in mehr als einer Replikationsgruppe enthalten sein. Dieses Verhalten hat sich wie folgt geändert:

Bisher:

Kontoobjekttypen können in mehr als einer Replikationsgruppe enthalten sein.

Jetzt:

Kontoobjekttypen sind auf eine Replikationsgruppe beschränkt.

Replikationsgruppen: Nur-Lese-Kontoparameter in Zielkonten¶

Wenn ein Kontoobjekttyp in eine Replikations- oder Failover-Gruppe aufgenommen wird, ist der Objekttyp im Zielkonto schreibgeschützt. Wenn zum Beispiel Rollen in ein Zielkonto repliziert werden, können im Zielkonto keine Rollen erstellt oder geändert werden.

Kontoparameter können in eine Replikations- oder Failover-Gruppe aufgenommen werden, um in ein Zielkonto repliziert zu werden. Einige Parameter (z. B. STATEMENT_TIMEOUT_IN_SECONDS) können auf mehreren Ebenen eingestellt werden (z. B. auf der Ebene des Kontos und pro Benutzer). Bei der Replikation von Kontoparametern wird nur die Einstellung auf Kontoebene für einen Parameter repliziert.

Das Verhalten bei der Replikation von Kontoparametern hat sich wie folgt geändert:

Bisher:

Wenn ACCOUNT PARAMETERS in der Liste OBJECT_TYPES einer Replikations- oder Failover-Gruppe enthalten war, konnten Parameter auf Sekundärkontoebene in Zielkonten geändert werden.

Jetzt:

Wenn ACCOUNT PARAMETERS in der Liste OBJECT_TYPES einer Replikations- oder Failover-Gruppe enthalten sind, sind Parameter auf Sekundärkontoebene in Zielkonten schreibgeschützt.

Befehl SHOW REPLICATIONGROUPS: Änderungen an der Ausgabe¶

Der Befehl SHOW REPLICATION GROUPS enthält in seiner Ausgabe eine Spalte next_scheduled_refresh, in der das Datum und die Uhrzeit der nächsten geplanten Aktualisierung für eine sekundäre Replikations- oder Failover-Gruppe mit einem Replikationsplan angezeigt wird. Diese Spalte enthält NULL für sekundäre Replikations- oder Failover-Gruppen mit einem Replikationsplan, die sich nicht in der aktuellen Region befinden.

Dieses Verhalten hat sich wie folgt geändert:

Bisher:

Die Spalte next_scheduled_refresh enthielt NULL für sekundäre Replikations- oder Failover-Gruppen mit einem Replikationsplan, die sich nicht in der aktuellen Region befinden.

Jetzt:

Die Spalte next_scheduled_refresh enthält das Datum und die Uhrzeit für die nächste geplante Aktualisierung aller sekundären Replikations- und Failover-Gruppen mit einem Replikationsplan.