Memahami perilaku masking dalam fungsi pemicu - Amazon Aurora

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Memahami perilaku masking dalam fungsi pemicu

Ketika pg_columnmask kebijakan diterapkan ke tabel, penting untuk memahami bagaimana masking berinteraksi dengan fungsi pemicu. Pemicu adalah fungsi database yang dijalankan secara otomatis sebagai respons terhadap peristiwa tertentu di atas meja, seperti operasi INSERT, UPDATE, atau DELETE.

Secara default, DDM menerapkan aturan masking yang berbeda tergantung pada jenis pemicu:

Pemicu tabel

Tabel transisi dibuka kedoknya - Fungsi pemicu pada tabel memiliki akses ke data yang dibuka kedok dalam tabel transisi mereka untuk versi baris lama dan baru

Pemilik tabel membuat pemicu dan memiliki data, sehingga mereka memiliki akses penuh untuk mengelola tabel mereka secara efektif

Lihat Pemicu (BUKAN Pemicu)

Tabel transisi disamarkan - Fungsi pemicu pada tampilan melihat data bertopeng sesuai dengan izin pengguna saat ini

Pemilik tampilan mungkin berbeda dari pemilik tabel dasar dan harus menghormati kebijakan masking pada tabel yang mendasarinya

Dua parameter konfigurasi tingkat server mengontrol perilaku pemicu dengan tabel bertopeng. Ini hanya dapat diatur olehrds_superuser:

  • Batasi Pemicu pada Tabel Bertopeng — Mencegah eksekusi pemicu saat pengguna bertopeng melakukan operasi DHTML pada tabel dengan kebijakan masking yang berlaku.

  • Batasi Pemicu pada Tampilan dengan Tabel Bertopeng: — Mencegah eksekusi pemicu pada tampilan saat definisi tampilan menyertakan tabel dengan kebijakan masking yang berlaku untuk pengguna saat ini.

contoh perbedaan antara aplikasi fungsi ke tabel dan tampilan

Contoh berikut menciptakan fungsi pemicu yang mencetak nilai baris lama dan baru, kemudian menunjukkan bagaimana fungsi yang sama berperilaku berbeda ketika dilampirkan ke tabel versus tampilan.

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

Sebaiknya tinjau perilaku pemicu sebelum menerapkan pemicu pada tabel bertopeng. Pemicu tabel memiliki akses ke data yang dibuka kedok dalam tabel transisi, sementara pemicu tampilan melihat data bertopeng.

contoh mengganti nama kebijakan masking

Contoh berikut menunjukkan cara mengganti nama kebijakan yang ada menggunakan prosedur. 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
contoh mengubah bobot kebijakan

Contoh berikut menunjukkan bagaimana mengubah bobot kebijakan untuk mengubah bobotnya.

-- 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
contoh membersihkan

Contoh berikut menunjukkan bagaimana untuk menghapus semua kebijakan, tabel dan pengguna.

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