Objets sécurisés : Réaction aux informations contenues dans les messages d’erreur¶
Les messages d’erreur relatifs aux objets sécurisés se comportent comme suit :
- Avant la modification:
Les messages d’erreur relatifs aux objets sécurisés affichent le message complet.
- Après la modification:
Les messages d’erreur relatifs aux objets sécurisés peuvent être expurgés.
La modification s’applique aux messages d’erreur relatifs aux types d’objets suivants :
Fonctions sécurisées (y compris les fonctions de table sécurisées)
Pour plus d’informations sur les objets sécurisés, voir Utiliser des objets sécurisés pour contrôler l’accès aux données.
Lorsqu’une erreur est détectée lors de l’expansion ou de l’évaluation d’un objet sécurisé, le message d’erreur est susceptible d’être expurgé. Lorsqu’un message d’erreur est expurgé, le code d’erreur reste inchangé.
Deux types de modifications des messages d’erreur sont possibles : l’expurgation lors de l’exécution et l’expurgation dans les métadonnées après l’exécution. Ces types de modifications sont décrits dans les sections suivantes.
Expurgation lors de l’exécution¶
Un message d’erreur entier ou une partie d’un message d’erreur peut être expurgé lorsque l’erreur est renvoyée au cours d’une opération. En général, ce type d’expurgation de message d’erreur se produit lorsqu’un utilisateur tente d’utiliser un objet sécurisé sans avoir le privilège OWNERSHIP sur l’objet sécurisé.
Expurgation dans les métadonnées après exécution¶
Les utilisateurs peuvent consulter les métadonnées relatives aux erreurs après leur apparition, y compris les messages d’erreur. Par exemple, les utilisateurs peuvent consulter ces métadonnées sur la page Query History de Snowsight, ou en lançant des requêtes sur les vues et en appelant des fonctions dans Schéma d’information de Snowflake. Lorsqu’un message d’erreur est expurgé lors de l’exécution, le message d’erreur est toujours expurgé dans les métadonnées après l’exécution pour tous les utilisateurs.
Lorsqu’un message d’erreur n’est pas expurgé lors de l’exécution, le message apparaît inchangé dans les métadonnées pour certains utilisateurs et est expurgé pour d’autres. Le message d’erreur reste inchangé dans les métadonnées dans l’un ou l’autre des cas suivants :
L’utilisateur qui affiche les métadonnées a le privilège AUDIT.
Pour l’utilisateur qui voit les métadonnées, le paramètre utilisateur ENABLE_UNREDACTED_SECURE_OBJECT_ERROR est défini sur
TRUE. Un utilisateur disposant du privilège AUDIT peut définir ce paramètre pour un utilisateur.L’utilisateur qui affiche les métadonnées a exécuté l’instruction qui a provoqué l’erreur.
Dans tous les autres cas, le message d’erreur est expurgé dans les métadonnées. Les messages d’erreur expurgés comprennent le texte suivant : Error in secure object.
Exemples d’expurgation de message d’erreur¶
Les exemples suivants montre des messages d’erreur expurgés. L’expurgation peut avoir lieu lors de l’exécution ou dans les métadonnées après l’exécution.
Exemple 1 : lancement d’une requête sur une vue sécurisée¶
Dans l’exemple suivant, un utilisateur disposant du privilège SELECT sur une vue sécurisée exécute une requête sur la vue qui renvoie une erreur.
Créez la vue sécurisée :
Supprimez la table utilisée dans la requête sur la vue :
Exécutez une requête sur la vue :
Message d’erreur affiché à tous les utilisateurs avant la modification¶
Message d’erreur expurgé affiché à certains utilisateurs après la modification¶
Exemple 2 : exécution d’une requête qui appelle une fonction sécurisée¶
Dans les exemples suivants, un utilisateur disposant du privilège USAGE sur une fonction sécurisée exécute une requête qui appelle la fonction sécurisée, mais celle-ci renvoie une erreur.
Exemple 2a : les arguments de la fonction entraînent une erreur¶
Créez la fonction sécurisée :
Exécutez une requête qui appelle la fonction sécurisée :
Message d’erreur affiché à tous les utilisateurs avant la modification¶
Message d’erreur expurgé affiché à certains utilisateurs après la modification¶
Exemple 2b : un objet dont dépend la fonction est supprimé¶
Créez la fonction sécurisée :
Supprimez la table utilisée dans la fonction :
Exécutez une requête qui appelle la fonction sécurisée :
Message d’erreur affiché à tous les utilisateurs avant la modification¶
Message d’erreur expurgé affiché à certains utilisateurs après la modification¶
Exemple 3 : une politique de masquage renvoie une erreur¶
Dans l’exemple suivant, un utilisateur exécute une requête sur une vue avec une politique de masquage qui rencontre une erreur.
Créez une politique de masquage :
Créez une vue et définissez la politique de masquage sur une colonne de la vue :
Supprimez la table utilisée dans la politique de masquage :
Exécutez une requête sur la vue en tant qu’utilisateur ne disposant pas de privilèges de possession sur la politique de masquage :
Message d’erreur affiché à tous les utilisateurs avant la modification¶
Message d’erreur expurgé affiché à certains utilisateurs après la modification¶
Exemple 4 : une politique d’accès aux lignes renvoie une erreur¶
Dans l’exemple suivant, un utilisateur exécute une requête sur une vue avec une politique d’accès aux lignes et rencontre une erreur.
Créez une politique d’accès aux lignes :
Créez une vue et ajoutez la politique d’accès aux lignes sur la vue :
Supprimez la table utilisée dans la politique d’accès aux lignes :
Interrogez la vue en tant qu’utilisateur ne disposant pas des privilèges OWNERSHIP sur la politique d’accès aux lignes :
Message d’erreur affiché à tous les utilisateurs avant la modification¶
Message d’erreur expurgé affiché à certains utilisateurs après la modification¶
Réf : 1858