Bundle 2022_08¶

Modifier les intégrations de sécurité SAML2 : appliquer les dates de validité des certificats X.509¶

Lors de la définition d’une intégration de sécurité SAML2 pour activer l’authentification unique, l’administrateur de la sécurité spécifie un certificat X.509 à l’aide du paramètre SAML2_X509_CERT.

Snowflake applique désormais les dates de validité de ces certificats X.509 de sorte que les certificats expirés entraînent un échec de l’authentification. Les certificats dont la date NotBefore n’a pas encore été atteinte échouent également à l’authentification. L’application des dates de validité ne peut pas être désactivée.

Précédemment:

Snowflake ne contrôlait pas la date de validité d’un certificat X.509 pour vérifier s’il était expiré ou si la date NotBefore n’était pas encore arrivée.

Actuellement:

Snowflake fait respecter les dates de validité d’un certificat X.509. Si la date du jour n’est pas comprise dans les dates de validité du certificat, l’authentification échoue.

Base de données et schémas : l’élimination ou le remplacement ne sont pas autorisés s’il en résulte des références pendantes pour les politiques de mots de passe et les politiques de sessions¶

Le comportement des opérations DROP SCHEMA, DROP DATABASE, CREATE OR REPLACE DATABASE et CREATE OR REPLACE SCHEMA par rapport à une politique de mot de passe et une politique de session a été modifié comme suit :

Précédemment:

Snowflake a autorisé les opérations DROP et REPLACE sur le schéma/la base de données qui contenait la politique lorsque celle-ci était définie sur le compte Snowflake contenant la politique ou lorsque la politique était définie sur un utilisateur du même compte.

Actuellement:

Snowflake autorise les opérations DROP et REPLACE sur le schéma/la base de données qui contient la politique lorsque celle-ci est définie sur le compte Snowflake qui la contient ou lorsque la politique est définie sur un utilisateur du même compte.

En conséquence, le comportement des quatre commandes énumérées a changé :

• DROP DATABASE

• DROP SCHEMA

• CREATE OR REPLACE DATABASE

• CREATE OR REPLACE SCHEMA

Selon l’opération, Snowflake renvoie l’un des messages d’erreur suivants :

Politique définie sur un utilisateur:

DROP DATABASE et CREATE OR REPLACE DATABASE :

Impossible de supprimer la base de données, car la politique 'MYDB.MYSCHEMA.POLICY1' est définie sur l'utilisateur 'JSMITH'. Annulez la politique 'MYDB.MYSCHEMA.POLICY1' et réessayez l'opération de suppression.

DROP SCHEMA et CREATE OR REPLACE SCHEMA :

Impossible de supprimer le schéma, car la politique 'MYDB.MYSCHEMA.POLICY1' est définie pour l'utilisateur 'JSMITH'. Annulez la politique 'MYDB.MYSCHEMA.POLICY1' et réessayez l'opération de suppression.

Politique définie sur le compte:

DROP DATABASE et CREATE OR REPLACE DATABASE :

Impossible de supprimer la base de données, car la politique 'MYDB.MYSCHEMA.POLICY1' est définie sur le compte 'MYACCOUNT'. Annulez la politique 'MYDB.MYSCHEMA.POLICY1' et réessayez l'opération de suppression.

DROP SCHEMA et CREATE OR REPLACE SCHEMA :

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

Commande SHOW FUNCTIONS : nouvelle colonne dans la sortie¶

La colonne suivante a été ajoutée à la sortie de la commande SHOW FUNCTIONS :

Pour aider à limiter l’impact de cet ajout, la colonne a été ajoutée en tant que dernière colonne dans la sortie.

Commande SHOW VIEWS : nouvelle colonne dans la sortie¶

La sortie SHOW VIEWS comprend maintenant une nouvelle colonne CHANGE_TRACKING. Cette colonne indique si le suivi des modifications est activé sur la vue.

La colonne affiche l’une des valeurs suivantes pour les vues individuelles :

• ON : le suivi des modifications est activé. Vous pouvez interroger ces données de suivi des modifications en utilisant les flux ou la clause CHANGES pour les instructions SELECT.

• OFF : le suivi des modifications est actuellement désactivé, mais pourrait être activé.

Pour aider à limiter l’impact de ce changement, la colonne a été ajoutée en tant que dernière colonne dans la sortie.

Fonction GET_DDL : ajout d’une prise en charge pour les balises et les politiques¶

La fonction GET_DDL prend désormais en charge les balises et les politiques comme suit :

• Lorsqu’une balise est définie sur une table, une vue ou une vue matérialisée, le résultat de l’appel de la fonction GET_DDL inclut les affectations de balise dans l’instruction CREATE.

• Lorsqu’une ou plusieurs balises sont définies sur un schéma ou une base de données, le résultat de l’appel de la fonction GET_DDL comprend les instructions suivantes pour affecter les balises :

  • Une instruction ALTER DATABASE lorsque la balise est définie sur la base de données.

  • Une instruction ALTER SCHEMA lorsque la balise est définie sur le schéma.

  • Une instruction ALTER DATABASE et une instruction ALTER SCHEMA lorsque la balise est définie à la fois sur la base de données et sur le schéma.

• Lorsqu’une balise est créée dans un schéma et que ce même schéma est spécifié lors de l’appel de la fonction GET_DDL, la sortie inclut une instruction CREATE OR REPLACE pour générer la balise.

  Il en va de même pour une balise créée dans une base de données : le fait de spécifier la base de données lors de l’appel de la fonction GET_DDL inclut l’instruction CREATE OR REPLACE pour générer la balise.

• Si une politique d’accès aux lignes est définie sur une table ou une vue ou si une politique de masquage est définie sur une colonne, l’appel de la fonction GET_DDL sur la table ou la vue ajoute le mot clé WITH pour indiquer que la politique est définie sur la table, la vue ou la colonne dans l’instruction CREATE.

  Notez que si vous deviez créer manuellement une table, la spécification du mot-clé WITH est facultative lorsque vous définissez une politique d’accès aux lignes sur la table ou la vue ou une politique de masquage sur une colonne.

Vues d’utilisation de Data Sharing : modifications des colonnes dans les vues¶

Toutes les vues du schéma DATA_SHARING_USAGE (dans la base de données partagée SNOWFLAKE) ont été modifiées comme suit :

Précédemment:

Les données affichées dans la colonne SNOWFLAKE_REGION des vues étaient affichées sous la forme <cloud> <région> en minuscules (par exemple, aws us_west_2). Cela ne correspond pas aux valeurs affichées pour la région Snowflake dans la sortie SHOW REGIONS.

Vues impactées :

• LISTING_ACCESS_HISTORY

• LISTING_CONSUMPTION_DAILY

• LISTING_EVENTS_DAILY

• LISTING_TELEMETRY_DAILY

Actuellement:

Dans les vues énumérées ci-dessus, les valeurs de la colonne SNOWFLAKE_REGION sont désormais affichées sous la forme <cloud>_<région> en majuscules. Ceci est cohérent avec la sortie SHOW REGIONS.

Par exemple, la région us_west_2 dans AWS est maintenant affichée comme AWS_US_WEST_2.

Vues d’utilisation de Data Sharing : nouvelle colonne dans les vues¶

Cette annonce a été ajoutée le 13 février 2023.

La colonne REGION_GROUP a été ajoutée aux vues suivantes dans le schéma DATA_SHARING_USAGE :

• LISTING_ACCESS_HISTORY

• LISTING_CONSUMPTION_DAILY

• LISTING_EVENTS_DAILY

• LISTING_TELEMETRY_DAILY

Pour aider à limiter l’impact de cet ajout, la colonne REGION_GROUP a été ajoutée en tant que dernière colonne dans la sortie.

Vue ACCESS_HISTORY (Account Usage) : nouvelles colonnes dans la vue¶

Les colonnes suivantes ont été ajoutées à la vue ACCESS_HISTORY (dans le schéma ACCOUNT_USAGE) :

• object_modified_by_ddl

• policies_referenced

Pour aider à limiter l’impact de ce changement, ces colonnes ont été ajoutées en tant que dernières colonnes dans la sortie.

Notez que ces colonnes sont des espaces réservés et qu’elles seront remplies dans une prochaine version.

Vue FUNCTIONS (Information Schema) : nouvelle colonne dans la sortie¶

La colonne suivante a été ajoutée à la vue Information Schema FUNCTIONS (dans le schéma INFORMATION_SCHEMA) :

Pour aider à limiter l’impact de cet ajout, la colonne a été ajoutée en tant que dernière colonne dans la vue.

Vue TABLE_CONSTRAINTS (Account Usage) : nouvelle colonne dans la vue¶

La nouvelle colonne suivante a été ajoutée à la vue TABLE_CONSTRAINTS (dans le schéma ACCOUNT_USAGE) :

Vue USAGE_IN_CURRENCY_DAILY (Utilisation de l’organisation) : nouvelle colonne dans la vue¶

La vue USAGE_IN_CURRENCY_DAILY (dans le schéma ORGANIZATION_USAGE) comprend maintenant une nouvelle colonne BALANCE_SOURCE.

Pour aider à limiter l’impact de ce changement, la colonne a été ajoutée en tant que dernière colonne dans la vue.

Vue USERS (Account Usage) : nouvelle colonne dans la vue¶

La vue USERS (dans le schéma ACCOUNT_USAGE) a été mise à jour pour inclure une nouvelle colonne USER_ID.

Consommateurs : les commandes SHOW renvoient une erreur si le compte a été révoqué du partage¶

Le comportement des commandes SHOW <objets> dans un compte consommateur pour lequel un partage a été révoqué a été modifié comme suit :

Précédemment:

Si un compte consommateur a monté deux ou plusieurs partages contenant les mêmes objets du fournisseur et que, par la suite, le fournisseur révoquait le compte d’un seul des partages, des données étaient renvoyées lorsque les commandes SHOW étaient exécutées dans le compte consommateur de la base de données ou du schéma monté dans le ou les partages restants.

Par exemple, share1 et share2 contenant les mêmes objets du fournisseur étaient montés dans le compte du consommateur xy12345, puis le fournisseur supprimait le compte de share2 :

alter share share2 remove accounts = xy12345;

Copy

Lorsque l’une des commandes suivantes était exécutée dans le compte du consommateur, des données valides étaient renvoyées :

SHOW <objects> IN DATABASE <revoked_mounted_db>;

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

Copy

Actuellement:

Si le même scénario se produit, une erreur similaire à la suivante est renvoyée lors de l’exécution des commandes SHOW décrites ci-dessus :

SQL compilation error: <détails de l'erreur spécifique>.

Politiques réseau : références ambigües pour les politiques avec réplication et basculement/restauration¶

Le comportement des politiques de réplication et réseau ainsi que des politiques de basculement/restauration et réseau a été modifié comme suit :

Précédemment:

Avec les politiques réseau et leurs références (c’est-à-dire les affectations au compte principal et aux utilisateurs du compte principal) :

• Spécifiez les USERS et les NETWORK POLICIES dans le groupe de réplication/basculement lorsqu’il existe des politiques réseau au niveau de l’utilisateur.

• Spécifiez NETWORK POLICIES dans le groupe de réplication/basculement lorsqu’il n’existe que des politiques réseau au niveau du compte.

• La réplication et le basculement/la restauration s’effectuaient même si le résultat était une référence pendante dans le compte cible.

Une référence ambigüe signifie qu’un objet du compte secondaire fait référence à un objet qui n’existe pas dans le même compte. Par exemple :

• Un utilisateur/nom d’utilisateur du compte secondaire fait référence à une politique réseau qui n’est pas dans le compte secondaire. Ce scénario se produit lorsqu’une politique réseau est attribuée à un utilisateur du compte principal et que le groupe de réplication/basculement spécifie USERS, mais pas NETWORK POLICIES.

• Une politique réseau est attachée au compte principal et le groupe de réplication/de basculement n’inclut pas de NETWORK POLICIES.

Actuellement:

Le comportement actuel a changé comme suit :

• Spécifiez les ACCOUNT PARAMETERS, les USERS et les NETWORK POLICIES dans le groupe de réplication/basculement lorsqu’il existe des politiques réseau au niveau de l’utilisateur.

• Spécifiez ACCOUNT PARAMETERS et NETWORK POLICIES dans le groupe de réplication/basculement lorsqu’il n’existe que des politiques réseau au niveau du compte.

• La réplication et le basculement/la restauration échouent dans le compte secondaire si le résultat est une référence pendante.

Par exemple, si le compte principal possède un ensemble de politiques réseau au niveau du compte et un ensemble de politiques réseau au niveau de l’utilisateur sur un utilisateur, des références pendantes seront créées dans le compte cible pour le paramètre de niveau compte et l’utilisateur :

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

Sinon, le message d’erreur spécifie soit l’instruction du paramètre du compte, soit l’instruction de l’utilisateur, selon la façon dont le groupe de réplication est configuré et ce que serait le résultat dans le compte cible.

Groupes de réplication : limiter les objets du compte à l’appartenance à un seul groupe¶

La réplication de compte permet de répliquer les objets de compte dans un groupe de réplication ou de basculement. Les objets de compte peuvent inclure des paramètres de compte, des rôles, des objets de sécurité et des utilisateurs. Pour une liste complète des objets pris en charge, reportez-vous à Objets répliqués.

Actuellement, si un compte n’a pas de groupe de basculement qui inclut des types d’objets de compte, différents types d’objets de compte peuvent être inclus dans plusieurs groupes de réplication. Le comportement a changé comme suit :

Précédemment:

Les types d’objets de compte peuvent être inclus dans plusieurs groupes de réplication.

Actuellement:

Les types d’objets de compte sont limités à un seul groupe de réplication.

Groupes de réplication : paramètres de compte en lecture seule dans les comptes cibles¶

Lorsqu’un type d’objet de compte est inclus dans un groupe de réplication ou de basculement, le type d’objet est en lecture seule dans le compte cible. Par exemple, si les rôles sont répliqués sur un compte cible, les rôles ne peuvent pas être créés ou modifiés dans le compte cible.

Les paramètres du compte peuvent être inclus dans un groupe de réplication ou de basculement pour être répliqués vers un compte cible. Certains paramètres (par exemple, STATEMENT_TIMEOUT_IN_SECONDS) peuvent être définis à plusieurs niveaux (par exemple, au niveau du compte et par utilisateur). La réplication des paramètres de compte ne réplique que le paramètre au niveau du compte pour un paramètre.

Le comportement pour la réplication des paramètres de compte a été modifié comme suit :

Précédemment:

Si ACCOUNT PARAMETERS étaient inclus dans la liste OBJECT_TYPES pour un groupe de réplication ou de basculement, les paramètres au niveau du compte secondaire dans les comptes cibles pourraient être modifiés.

Actuellement:

Si ACCOUNT PARAMETERS sont inclus dans la liste OBJECT_TYPES pour un groupe de réplication ou de basculement, les paramètres au niveau du compte secondaire dans les comptes cibles sont en lecture seule.

Commande SHOW REPLICATIONGROUPS : modifications de la sortie¶

La commande SHOW REPLICATION GROUPS inclut une colonne next_scheduled_refresh dans sa sortie qui affiche la date et l’heure de la prochaine actualisation planifiée pour une réplication secondaire ou un groupe de basculement avec une planification de réplication. Cette colonne est NULL pour les groupes de réplication ou de basculement secondaires avec un planning de réplication s’il ne se trouve pas dans la région actuelle.

Le comportement a changé comme suit :

Précédemment:

La colonne next_scheduled_refresh était NULL pour les groupes de réplication secondaire ou de basculement avec un planning de réplication qui n’était pas dans la région actuelle.

Actuellement:

La colonne next_scheduled_refresh comprend la date et l’heure de la prochaine actualisation planifiée pour tous les groupes de réplication et de basculement secondaires avec une planification de la réplication.