Comprendre le comportement de masquage dans les fonctions de déclenchement - Amazon Aurora

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Comprendre le comportement de masquage dans les fonctions de déclenchement

Lorsque pg_columnmask des politiques sont appliquées à des tables, il est important de comprendre comment le masquage interagit avec les fonctions de déclenchement. Les déclencheurs sont des fonctions de base de données qui s'exécutent automatiquement en réponse à certains événements sur une table, tels que les opérations INSERT, UPDATE ou DELETE.

Par défaut, DDM applique différentes règles de masquage en fonction du type de déclencheur :

déclencheurs de table

Les tables de transition sont démasquées : les fonctions de déclenchement des tables ont accès aux données non masquées de leurs tables de transition, tant pour les anciennes que pour les nouvelles versions de lignes

Les propriétaires de tables créent des déclencheurs et sont propriétaires des données, de sorte qu'ils disposent d'un accès complet pour gérer efficacement leurs tables

Afficher les déclencheurs (AU LIEU DES déclencheurs)

Les tables de transition sont masquées : les fonctions de déclenchement des vues voient les données masquées en fonction des autorisations de l'utilisateur actuel

Les propriétaires des vues peuvent être différents des propriétaires des tables de base et doivent respecter les politiques de masquage des tables sous-jacentes

Deux paramètres de configuration au niveau du serveur contrôlent le comportement des déclencheurs avec des tables masquées. Ils ne peuvent être définis que par rds_superuser :

  • Restreindre les déclencheurs sur les tables masquées : empêche l'exécution de déclencheurs lorsqu'un utilisateur masqué effectue des opérations DML sur des tables avec des politiques de masquage applicables.

  • Restreindre les déclencheurs sur les vues contenant des tables masquées : — Empêche l'exécution des déclencheurs sur les vues lorsque la définition de la vue inclut des tables avec des politiques de masquage applicables à l'utilisateur actuel.

Exemple des différences entre l'application de la fonction à la table et à la vue

L'exemple suivant crée une fonction de déclenchement qui imprime les anciennes et les nouvelles valeurs de ligne, puis montre comment la même fonction se comporte différemment lorsqu'elle est attachée à une table par rapport à une vue.

-- Create trigger function
CREATE OR REPLACE FUNCTION print_changes()
    RETURNS TRIGGER AS
    $$
        BEGIN
        RAISE NOTICE 'Old row: name=%, email=%, ssn=%, salary=%',
            OLD.name, OLD.email, OLD.ssn, OLD.salary;
        
        RAISE NOTICE 'New row: name=%, email=%, ssn=%, salary=%',
            NEW.name, NEW.email, NEW.ssn, NEW.salary;
        
        RETURN NEW;
        END;
    $$ LANGUAGE plpgsql;

-- Create trigger
CREATE TRIGGER print_changes_trigger
    BEFORE UPDATE ON hr.employees
    FOR EACH ROW
    EXECUTE FUNCTION print_changes();

-- Grant update to analyst role
GRANT UPDATE ON hr.employees TO analyst_role;

-- Unmasked data must be seen inside trigger even for masked user for the OLD and NEW
-- row passed to trigger function
BEGIN;
SET ROLE mike_analyst;
UPDATE hr.employees SET id = id + 10 RETURNING *;
NOTICE:  Old row: name=John Doe, email=john.doe@example.com, ssn=123-45-6789, salary=50000.00
NOTICE:  New row: name=John Doe, email=john.doe@example.com, ssn=123-45-6789, salary=50000.00
NOTICE:  Old row: name=Jane Smith, email=jane.smith@example.com, ssn=987-65-4321, salary=60000.00
NOTICE:  New row: name=Jane Smith, email=jane.smith@example.com, ssn=987-65-4321, salary=60000.00
 id |    name    |         email          |     ssn     |  salary  
----+------------+------------------------+-------------+----------
 11 | John Doe   | john.doe@example.com   | XXX-XX-6789 | 45000.00
 12 | Jane Smith | jane.smith@example.com | XXX-XX-4321 | 54000.00
(2 rows)

ROLLBACK;


-- Triggers on views (which are supposed to see masked data for new/old row)
CREATE VIEW hr.view_over_employees AS SELECT * FROM hr.employees;
GRANT UPDATE, SELECT ON hr.view_over_employees TO analyst_role;

-- Create trigger for this view
CREATE TRIGGER print_changes_trigger
    INSTEAD OF UPDATE ON hr.view_over_employees
    FOR EACH ROW
    EXECUTE FUNCTION print_changes();

-- Masked new and old rows should be passed to trigger if trigger is on view
BEGIN;
SET ROLE mike_analyst;
UPDATE hr.view_over_employees SET id = id + 10 RETURNING *;
NOTICE:  Old row: name=John Doe, email=john.doe@example.com, ssn=XXX-XX-6789, salary=45000.00
NOTICE:  New row: name=John Doe, email=john.doe@example.com, ssn=XXX-XX-6789, salary=45000.00
NOTICE:  Old row: name=Jane Smith, email=jane.smith@example.com, ssn=XXX-XX-4321, salary=54000.00
NOTICE:  New row: name=Jane Smith, email=jane.smith@example.com, ssn=XXX-XX-4321, salary=54000.00
 id |    name    |         email          |     ssn     |  salary  
----+------------+------------------------+-------------+----------
 11 | John Doe   | john.doe@example.com   | XXX-XX-6789 | 45000.00
 12 | Jane Smith | jane.smith@example.com | XXX-XX-4321 | 54000.00
(2 rows)
ROLLBACK;

Nous vous recommandons de revoir le comportement des déclencheurs avant de les implémenter sur des tables masquées. Les déclencheurs de table ont accès aux données non masquées des tables de transition, tandis que les déclencheurs de vue voient les données masquées.

Exemple de renommer la politique de masquage

L'exemple suivant montre comment renommer les politiques existantes à l'aide de la rename_masking_policy procédure.

-- Rename the strict policy
CALL pgcolumnmask.rename_masking_policy(
    'employee_mask_strict',
    'hr.employees',
    'intern_protection_policy'
);

-- Verify the rename
SELECT policyname, roles, weight
    FROM pgcolumnmask.pg_columnmask_policies
    WHERE tablename = 'employees'
    ORDER BY weight DESC;

        policyname        |     roles      | weight 
--------------------------+----------------+--------
 employee_mask_light      | {analyst_role} |    100
 employee_mask_moderate   | {support_role} |     50
 intern_protection_policy | {intern_role}  |     10
Exemple de la modification du poids des politiques

L'exemple suivant montre comment modifier les pondérations des politiques pour modifier leur pondération.

-- Change weight of moderate policy
CALL pgcolumnmask.alter_masking_policy(
    'employee_mask_moderate'::NAME,
    'hr.employees'::REGCLASS,
    NULL,    -- Keep existing masking expressions
    NULL,    -- Keep existing roles
    75       -- New weight
);

-- Verify the changes
SELECT policyname, roles, weight
    FROM pgcolumnmask.pg_columnmask_policies
    WHERE tablename = 'employees'
    ORDER BY weight DESC;
        policyname        |     roles      | weight 
--------------------------+----------------+--------
 employee_mask_light      | {analyst_role} |    100
 employee_mask_moderate   | {support_role} |     75
 intern_protection_policy | {intern_role}  |     10
Exemple de nettoyage

L'exemple suivant montre comment supprimer toutes les politiques, tables et utilisateurs.

-- Drop policies
CALL pgcolumnmask.drop_masking_policy(
    'intern_protection_policy',
    'hr.employees'
);

CALL pgcolumnmask.drop_masking_policy(
    'employee_mask_moderate',
    'hr.employees'
);

CALL pgcolumnmask.drop_masking_policy(
    'employee_mask_light',
    'hr.employees'
);

-- Drop table and functions
DROP VIEW IF EXISTS hr.view_over_employees;
DROP TABLE IF EXISTS hr.employees;
DROP SCHEMA IF EXISTS hr;
DROP FUNCTION IF EXISTS public.mask_ssn(text);
DROP FUNCTION IF EXISTS public.mask_salary(numeric, numeric);

-- Drop users
DROP USER sarah_intern, lisa_support, mike_analyst,
    ethan_support_intern, john_analyst_intern;
DROP ROLE intern_role, support_role, analyst_role;