Comprensione del comportamento di mascheramento nelle funzioni di attivazione - Amazon Aurora

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Comprensione del comportamento di mascheramento nelle funzioni di attivazione

Quando pg_columnmask le policy vengono applicate alle tabelle, è importante capire come il mascheramento interagisce con le funzioni di attivazione. I trigger sono funzioni di database che vengono eseguite automaticamente in risposta a determinati eventi su una tabella, come le operazioni INSERT, UPDATE o DELETE.

Per impostazione predefinita, DDM applica regole di mascheramento diverse a seconda del tipo di trigger:

Trigger della tabella

Le tabelle di transizione sono smascherate: le funzioni di attivazione sulle tabelle hanno accesso ai dati non mascherati nelle relative tabelle di transizione sia per le vecchie che per le nuove versioni di riga

I proprietari delle tabelle creano i trigger e sono proprietari dei dati, in modo da avere pieno accesso per gestire le proprie tabelle in modo efficace

Visualizza i trigger (ANZICHÉ i trigger)

Le tabelle di transizione sono mascherate: le funzioni di attivazione nelle viste visualizzano i dati mascherati in base alle autorizzazioni dell'utente corrente

I proprietari delle viste possono differire dai proprietari delle tabelle di base e devono rispettare le politiche di mascheramento sulle tabelle sottostanti

Due parametri di configurazione a livello di server controllano il comportamento dei trigger con tabelle mascherate. Questi possono essere impostati solo da: rds_superuser

  • Limita i trigger sulle tabelle mascherate: impedisce l'esecuzione dei trigger quando un utente mascherato esegue operazioni DML su tabelle con politiche di mascheramento applicabili.

  • Limita i trigger sulle viste con tabelle mascherate: — Impedisce l'esecuzione dei trigger sulle viste quando la definizione della vista include tabelle con politiche di mascheramento applicabili all'utente corrente.

Esempio delle differenze tra la funzione, l'applicazione, la tabella e la visualizzazione

L'esempio seguente crea una funzione di attivazione che stampa valori di riga vecchi e nuovi, quindi dimostra come la stessa funzione si comporti in modo diverso quando è collegata a una tabella rispetto a una vista.

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

Consigliamo di esaminare il comportamento dei trigger prima di implementarli nelle tabelle mascherate. I trigger delle tabelle hanno accesso ai dati non mascherati nelle tabelle di transizione, mentre i trigger di visualizzazione visualizzano i dati mascherati.

Esempio della politica di mascheramento della ridenominazione

L'esempio seguente mostra come rinominare le politiche esistenti utilizzando la procedura. rename_masking_policy

-- 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
Esempio di alterare il peso delle politiche

L'esempio seguente mostra come modificare i pesi delle politiche per modificarne il peso.

-- 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
Esempio di pulizia

L'esempio seguente mostra come eliminare tutte le politiche, le tabelle e gli utenti.

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