Objets sécurisés : rédaction d’informations dans les messages d’erreur (En attente)¶
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.
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 :
CREATE SECURE VIEW myview
AS SELECT a FROM mytable;
Supprimez la table utilisée dans la requête sur la vue :
DROP TABLE mytable;
Exécutez une requête sur la vue :
SELECT * FROM myview;
Message d’erreur affiché à tous les utilisateurs avant la modification¶
002037 (42601): SQL compilation error:
Failure during expansion of view 'MYVIEW': SQL compilation error:
Object 'DB.SC.MYTABLE' does not exist or not authorized.
Message d’erreur expurgé affiché à certains utilisateurs après la modification¶
002037 (42601): SQL compilation error:
Failure during expansion of view 'MYVIEW': Error in secure object
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 :
CREATE SECURE FUNCTION myfunction1(x FLOAT, y FLOAT)
RETURNS FLOAT
LANGUAGE SQL
AS
'SELECT x / y';
Exécutez une requête qui appelle la fonction sécurisée :
SELECT myfunction1(1, 0);
Message d’erreur affiché à tous les utilisateurs avant la modification¶
100051 (22012): Division by zero
Message d’erreur expurgé affiché à certains utilisateurs après la modification¶
100051 (22012): Error in secure object
Exemple 2b : un objet dont dépend la fonction est supprimé¶
Créez la fonction sécurisée :
CREATE SECURE FUNCTION myfunction2()
RETURNS TABLE (a NUMBER)
LANGUAGE SQL
AS
'SELECT * FROM mytable';
Supprimez la table utilisée dans la fonction :
DROP TABLE mytable;
Exécutez une requête qui appelle la fonction sécurisée :
SELECT * FROM TABLE(myfunction2());
Message d’erreur affiché à tous les utilisateurs avant la modification¶
002003 (42S02): SQL compilation error:
Object 'DB.SC.MYTABLE' does not exist or not authorized
Message d’erreur expurgé affiché à certains utilisateurs après la modification¶
002003 (42S02): Error in secure object
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 :
CREATE MASKING POLICY allowed_role_names_mp as (val NUMBER) RETURNS NUMBER ->
CASE
WHEN EXISTS
(SELECT role FROM allowed_roles WHERE role = CURRENT_ROLE()) THEN val
ELSE '********'
END;
Créez une vue et définissez la politique de masquage sur une colonne de la vue :
CREATE TABLE test_masking_policy(x NUMBER) AS
SELECT * FROM VALUES (1), (2), (3);
CREATE VIEW myview_mp
AS SELECT * FROM test_masking_policy;
ALTER VIEW myview_mp
MODIFY COLUMN x SET MASKING POLICY allowed_role_names_mp;
Supprimez la table utilisée dans la politique de masquage :
DROP TABLE allowed_roles;
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 :
SELECT * FROM myview_mp;
Message d’erreur affiché à tous les utilisateurs avant la modification¶
002003 (42S02): SQL compilation error:
Object 'DB.SC.ALLOWED_ROLES' does not exist or not authorized.
Message d’erreur expurgé affiché à certains utilisateurs après la modification¶
002003 (42S02): Error in secure object
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 :
CREATE OR REPLACE ROW ACCESS POLICY myrap AS (role NUMBER) RETURNS BOOLEAN ->
EXISTS (
SELECT 1 FROM allowed_roles
WHERE role::STRING = CURRENT_ROLE());
Créez une vue et ajoutez la politique d’accès aux lignes sur la vue :
CREATE TABLE test_row_access_policy(x NUMBER) AS
SELECT * FROM VALUES (1), (2), (3);
CREATE VIEW myview_rap
AS SELECT * FROM test_row_access_policy;
ALTER VIEW myview_rap
ADD ROW ACCESS POLICY myrap ON (x);
Supprimez la table utilisée dans la politique d’accès aux lignes :
DROP TABLE allowed_roles;
Interrogez la vue en tant qu’utilisateur ne disposant pas des privilèges OWNERSHIP sur la politique d’accès aux lignes :
SELECT * FROM myview_rap;
Message d’erreur affiché à tous les utilisateurs avant la modification¶
002003 (42S02): SQL compilation error:
Object 'DB.SC.ALLOWED_ROLES' does not exist or not authorized.
Message d’erreur expurgé affiché à certains utilisateurs après la modification¶
002003 (42S02): Error in secure object
Réf : 1858