Verstehen des Maskierungsverhaltens in Triggerfunktionen - Amazon Aurora

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verstehen des Maskierungsverhaltens in Triggerfunktionen

Wenn pg_columnmask Richtlinien auf Tabellen angewendet werden, ist es wichtig zu verstehen, wie Maskierung mit Triggerfunktionen interagiert. Trigger sind Datenbankfunktionen, die automatisch als Reaktion auf bestimmte Ereignisse in einer Tabelle ausgeführt werden, z. B. INSERT-, UPDATE- oder DELETE-Operationen.

Standardmäßig wendet DDM je nach Triggertyp unterschiedliche Maskierungsregeln an:

Tabellentrigger

Übergangstabellen sind unmaskiert — Triggerfunktionen für Tabellen haben Zugriff auf unmaskierte Daten in ihren Übergangstabellen sowohl für alte als auch für neue Zeilenversionen

Tabellenbesitzer erstellen Trigger und sind Eigentümer der Daten, sodass sie vollen Zugriff haben, um ihre Tabellen effektiv zu verwalten

Trigger anzeigen (STATT Trigger)

Übergangstabellen sind maskiert — Triggerfunktionen in Ansichten sehen maskierte Daten entsprechend den Berechtigungen des aktuellen Benutzers

Eigentümer von Ansichten können sich von Besitzern von Basistabellen unterscheiden und sollten die Maskierungsrichtlinien für die zugrunde liegenden Tabellen beachten

Zwei Konfigurationsparameter auf Serverebene steuern das Triggerverhalten bei maskierten Tabellen. Diese können nur gesetzt werden durch: rds_superuser

  • Trigger für maskierte Tabellen einschränken — Verhindert die Ausführung von Triggern, wenn ein maskierter Benutzer DML-Operationen an Tabellen mit entsprechenden Maskierungsrichtlinien ausführt.

  • Trigger für Ansichten mit maskierten Tabellen einschränken: — Verhindert die Ausführung von Triggern für Ansichten, wenn die Ansichtsdefinition Tabellen mit Maskierungsrichtlinien enthält, die für den aktuellen Benutzer gelten.

Beispiel der Unterschiede zwischen der Funktionsanwendung auf Tabelle und Ansicht

Im folgenden Beispiel wird eine Triggerfunktion erstellt, die alte und neue Zeilenwerte ausgibt. Anschließend wird veranschaulicht, wie sich dieselbe Funktion, wenn sie an eine Tabelle angehängt wird, anders verhält als bei einer Ansicht.

-- 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;

Wir empfehlen, das Verhalten des Triggers zu überprüfen, bevor Sie Trigger in maskierten Tabellen implementieren. Tabellen-Trigger haben Zugriff auf unmaskierte Daten in Übergangstabellen, während View-Trigger maskierte Daten sehen.

Beispiel der Maskierungsrichtlinie beim Umbenennen

Das folgende Beispiel zeigt, wie vorhandene Richtlinien mithilfe des rename_masking_policy Verfahrens umbenannt werden.

-- 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
Beispiel der Änderung des politischen Gewichts

Das folgende Beispiel zeigt, wie das Gewicht von Policen geändert werden kann, um ihr Gewicht zu ändern.

-- 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
Beispiel des Aufräumens

Das folgende Beispiel zeigt, wie alle Richtlinien, Tabellen und Benutzer gelöscht werden.

-- 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;