Gambaran Umum nd-to-end Contoh E Pertimbangan saat menggunakan masking data dinamis

Penutupan data dinamis

Gambaran Umum

Menggunakan masking data dinamis (DDM) di Amazon Redshift, Anda dapat melindungi data sensitif di gudang data Anda. Anda dapat memanipulasi cara Amazon Redshift menampilkan data sensitif kepada pengguna pada waktu kueri, tanpa mengubahnya dalam database. Anda mengontrol akses ke data melalui kebijakan masking yang menerapkan aturan obfuscation kustom ke pengguna atau peran tertentu. Dengan cara itu, Anda dapat menanggapi perubahan persyaratan privasi tanpa mengubah data yang mendasarinya atau mengedit kueri SQL.

Kebijakan masking data dinamis menyembunyikan, mengaburkan, atau mensamarkan data yang cocok dengan format tertentu. Saat dilampirkan ke tabel, ekspresi masking diterapkan ke satu atau lebih kolomnya. Anda dapat memodifikasi kebijakan masking lebih lanjut untuk hanya menerapkannya pada pengguna tertentu, atau ke peran yang ditentukan pengguna yang dapat Anda buat. Kontrol akses berbasis peran (RBAC) Selain itu, Anda dapat menerapkan DDM pada tingkat sel dengan menggunakan kolom bersyarat saat membuat kebijakan masking Anda. Untuk informasi lebih lanjut tentang penyembunyian bersyarat, lihat. Masking data dinamis bersyarat

Anda dapat menerapkan beberapa kebijakan masking dengan berbagai tingkat kekaburan ke kolom yang sama dalam tabel dan menetapkannya ke peran yang berbeda. Untuk menghindari konflik ketika Anda memiliki peran yang berbeda dengan kebijakan berbeda yang diterapkan pada satu kolom, Anda dapat menetapkan prioritas untuk setiap aplikasi. Dengan cara itu, Anda dapat mengontrol data apa yang dapat diakses oleh pengguna atau peran tertentu. Kebijakan DDM dapat menyunting sebagian atau seluruhnya data, atau hash dengan menggunakan fungsi yang ditentukan pengguna yang ditulis dalam SQL, Python, atau dengan. AWS Lambda Dengan menyembunyikan data menggunakan hash, Anda dapat menerapkan gabungan pada data ini tanpa akses ke informasi yang berpotensi sensitif.

nd-to-end Contoh E

Berikut ini adalah end-to-end contoh yang menunjukkan bagaimana Anda dapat membuat dan melampirkan kebijakan masking ke kolom. Kebijakan ini memungkinkan pengguna mengakses kolom dan melihat nilai yang berbeda, tergantung pada tingkat kebingungan dalam kebijakan yang dilampirkan pada peran mereka. Anda harus menjadi superuser atau memiliki sys:secadminperan untuk menjalankan contoh ini.

Membuat kebijakan masking

Pertama, buat tabel dan isi dengan nilai kartu kredit.


--create the table         
CREATE TABLE credit_cards (
  customer_id INT,
  credit_card TEXT
);

--populate the table with sample values
INSERT INTO credit_cards
VALUES
  (100, '4532993817514842'),
  (100, '4716002041425888'),
  (102, '5243112427642649'),
  (102, '6011720771834675'),
  (102, '6011378662059710'),
  (103, '373611968625635')
;

--run GRANT to grant permission to use the SELECT statement on the table
GRANT SELECT ON credit_cards TO PUBLIC;

--create two users
CREATE USER regular_user WITH PASSWORD '1234Test!';

CREATE USER analytics_user WITH PASSWORD '1234Test!';

--create the analytics_role role and grant it to analytics_user
--regular_user does not have a role
CREATE ROLE analytics_role;

GRANT ROLE analytics_role TO analytics_user;

Selanjutnya, buat kebijakan masking untuk diterapkan pada peran analitik.


--create a masking policy that fully masks the credit card number
CREATE MASKING POLICY mask_credit_card_full
WITH (credit_card VARCHAR(256))
USING ('000000XXXX0000'::TEXT);

--create a user-defined function that partially obfuscates credit card data
CREATE FUNCTION REDACT_CREDIT_CARD (credit_card TEXT)
RETURNS TEXT IMMUTABLE
AS $$
    import re
    regexp = re.compile("^([0-9]{6})[0-9]{5,6}([0-9]{4})")
 
    match = regexp.search(credit_card)
    if match != None:
        first = match.group(1)
        last = match.group(2)
    else:
        first = "000000"
        last = "0000"
    
    return "{}XXXXX{}".format(first, last)
$$ LANGUAGE plpythonu;

--create a masking policy that applies the REDACT_CREDIT_CARD function
CREATE MASKING POLICY mask_credit_card_partial
WITH (credit_card VARCHAR(256))
USING (REDACT_CREDIT_CARD(credit_card));

--confirm the masking policies using the associated system views
SELECT * FROM svv_masking_policy;

SELECT * FROM svv_attached_masking_policy;

Melampirkan kebijakan masking

Lampirkan kebijakan masking ke tabel kartu kredit.


--attach mask_credit_card_full to the credit card table as the default policy
--all users will see this masking policy unless a higher priority masking policy is attached to them or their role
ATTACH MASKING POLICY mask_credit_card_full
ON credit_cards(credit_card)
TO PUBLIC;

--attach mask_credit_card_partial to the analytics role
--users with the analytics role can see partial credit card information
ATTACH MASKING POLICY mask_credit_card_partial
ON credit_cards(credit_card)
TO ROLE analytics_role
PRIORITY 10;

--confirm the masking policies are applied to the table and role in the associated system view
SELECT * FROM svv_attached_masking_policy;

--confirm the full masking policy is in place for normal users by selecting from the credit card table as regular_user
SET SESSION AUTHORIZATION regular_user;

SELECT * FROM credit_cards;

--confirm the partial masking policy is in place for users with the analytics role by selecting from the credit card table as analytics_user
SET SESSION AUTHORIZATION analytics_user;

SELECT * FROM credit_cards;

Mengubah kebijakan masking

Bagian berikut menunjukkan cara mengubah kebijakan masking data dinamis.


--reset session authorization to the default
RESET SESSION AUTHORIZATION;

--alter the mask_credit_card_full policy
ALTER MASKING POLICY mask_credit_card_full
USING ('00000000000000'::TEXT);	
	
--confirm the full masking policy is in place after altering the policy, and that results are altered from '000000XXXX0000' to '00000000000000'
SELECT * FROM credit_cards;

Melepaskan dan menjatuhkan kebijakan masking

Bagian berikut menunjukkan cara melepaskan dan menghapus kebijakan masking dengan menghapus semua kebijakan masking data dinamis dari tabel.


--reset session authorization to the default
RESET SESSION AUTHORIZATION;

--detach both masking policies from the credit_cards table
DETACH MASKING POLICY mask_credit_card_full 
ON credit_cards(credit_card) 
FROM PUBLIC;

DETACH MASKING POLICY mask_credit_card_partial 
ON credit_cards(credit_card) 
FROM ROLE analytics_role;

--drop both masking policies
DROP MASKING POLICY mask_credit_card_full;

DROP MASKING POLICY mask_credit_card_partial;

Pertimbangan saat menggunakan masking data dinamis

Saat menggunakan masking data dinamis, pertimbangkan hal berikut:

Saat menanyakan objek yang dibuat dari tabel, seperti tampilan, pengguna akan melihat hasil berdasarkan kebijakan masking mereka sendiri, bukan kebijakan pengguna yang membuat objek. Misalnya, pengguna dengan peran analis yang menanyakan tampilan yang dibuat oleh secadmin akan melihat hasil dengan kebijakan masking yang dilampirkan pada peran analis.
Untuk mencegah perintah EXPLORE berpotensi mengekspos filter kebijakan masking sensitif, hanya pengguna dengan izin SYS_EXPLAIN_DDM yang dapat melihat kebijakan penyembunyian yang diterapkan dalam output EXPLOW. Pengguna tidak memiliki izin SYS_EXPLAIN_DDM secara default.

Berikut ini adalah sintaks untuk memberikan izin untuk peran.
```
GRANT EXPLAIN MASKING TO ROLE rolename
```
Untuk informasi selengkapnya tentang perintah EXPLORE, lihatEXPLAIN.
Pengguna dengan peran yang berbeda dapat melihat hasil yang berbeda berdasarkan kondisi filter atau kondisi gabungan yang digunakan. Misalnya, menjalankan perintah SELECT pada tabel menggunakan nilai kolom tertentu akan gagal jika pengguna yang menjalankan perintah tersebut menerapkan kebijakan masking yang mengaburkan kolom tersebut.
Kebijakan DDM harus diterapkan sebelum operasi predikat, atau proyeksi. Kebijakan masking dapat mencakup yang berikut:
- Operasi konstan berbiaya rendah seperti mengubah nilai menjadi nol
- Operasi biaya moderat seperti hashing HMAC
- Operasi berbiaya tinggi seperti panggilan ke fungsi yang ditentukan pengguna Lambda eksternal
Karena itu, kami menyarankan Anda menggunakan ekspresi masking sederhana jika memungkinkan.
Anda dapat menggunakan kebijakan DDM untuk peran dengan kebijakan keamanan tingkat baris, tetapi perhatikan bahwa kebijakan RLS diterapkan sebelum DDM. Ekspresi masking data dinamis tidak akan dapat membaca baris yang dilindungi oleh RLS. Untuk informasi lebih lanjut tentang RLS, lihatKeamanan tingkat baris.
Saat menggunakan MENYONTEK perintah untuk menyalin dari parket ke tabel target yang dilindungi, Anda harus secara eksplisit menentukan kolom dalam pernyataan COPY. Untuk informasi selengkapnya tentang pemetaan kolom dengan COPY, lihatOpsi pemetaan kolom.
Kebijakan DDM tidak dapat dilampirkan ke relasi berikut:
- Tabel dan katalog sistem
- Tabel eksternal
- Tabel Datasharing
- Tampilan terwujud
- Hubungan lintas-DB
- Tabel sementara
- Kueri yang berkorelasi

Kebijakan DDM dapat berisi tabel pencarian. Tabel pencarian dapat hadir dalam klausa USING. Jenis relasi berikut tidak dapat digunakan sebagai tabel pencarian:

Tabel dan katalog sistem
Tabel eksternal
Tabel Datasharing
Tampilan, tampilan terwujud, dan tampilan yang mengikat akhir
Hubungan lintas-DB
Tabel sementara
Kueri yang berkorelasi

Berikut ini adalah contoh melampirkan kebijakan masking ke tabel pencarian.


--Create a masking policy referencing a lookup table
CREATE MASKING POLICY lookup_mask_credit_card WITH (credit_card TEXT) USING (
  CASE
    WHEN
      credit_card IN (SELECT credit_card_lookup FROM credit_cards_lookup)      
    THEN '000000XXXX0000'
    ELSE REDACT_CREDIT_CARD(credit_card)
    END
  ); 
  
--Provides access to the lookup table via a policy attached to a role
GRANT SELECT ON TABLE credit_cards_lookup TO MASKING POLICY lookup_mask_credit_card;

Anda tidak dapat melampirkan kebijakan masking yang akan menghasilkan output yang tidak kompatibel dengan jenis dan ukuran kolom target. Misalnya, Anda tidak dapat melampirkan kebijakan masking yang menampilkan string panjang 12 karakter ke kolom VARCHAR (10). Amazon Redshift mendukung pengecualian berikut:
- Kebijakan masking dengan tipe input INTN dapat dilampirkan ke kebijakan dengan ukuran INTM selama M < N. Misalnya, kebijakan input BIGINT (INT8) dapat dilampirkan ke kolom smallint (INT4).
- Kebijakan masking dengan tipe input NUMERIC atau DECIMAL selalu dapat dilampirkan ke kolom FLOAT.
Kebijakan DDM tidak dapat digunakan dengan berbagi data. Jika produsen data data melampirkan kebijakan DDM ke tabel di datashare, tabel menjadi tidak dapat diakses oleh pengguna dari konsumen data yang mencoba menanyakan tabel. Tabel dengan kebijakan DDM terlampir tidak dapat ditambahkan ke datashare.
Anda tidak dapat menanyakan relasi yang telah melampirkan kebijakan DDM jika nilai Anda untuk salah satu opsi konfigurasi berikut tidak cocok dengan nilai default sesi:
- enable_case_sensitive_super_attribute
- enable_case_sensitive_identifier
- downcase_delimited_identifier
Pertimbangkan untuk mengatur ulang opsi konfigurasi sesi Anda jika Anda mencoba menanyakan relasi dengan kebijakan DDM yang dilampirkan dan melihat pesan “DDM protected relation does not support session level config on case sensitivity be different from the default value.”
Jika klaster yang disediakan atau namespace tanpa server memiliki kebijakan penyembunyian data dinamis, perintah berikut akan diblokir untuk pengguna biasa:
```
ALTER <current_user> SET enable_case_sensitive_super_attribute/enable_case_sensitive_identifier/downcase_delimited_identifier
```
Saat Anda membuat kebijakan DDM, sebaiknya Anda mengubah pengaturan opsi konfigurasi default untuk pengguna biasa agar sesuai dengan pengaturan opsi konfigurasi sesi pada saat kebijakan dibuat. Pengguna super dan pengguna dengan hak istimewa ALTER USER dapat melakukan ini dengan menggunakan pengaturan grup parameter atau perintah ALTER USER. Untuk informasi tentang grup parameter, lihat grup parameter Amazon Redshift di Panduan Manajemen Pergeseran Merah Amazon. Untuk informasi tentang perintah ALTER USER, lihatALTER USER.
Tampilan dan tampilan yang mengikat akhir dengan kebijakan DDM terlampir tidak dapat diganti oleh pengguna biasa yang menggunakan perintah. BUAT TAMPILAN Untuk mengganti tampilan atau LBV dengan kebijakan DDM, pertama-tama lepaskan kebijakan DDM yang melekat padanya, ganti tampilan atau LBV, dan pasang kembali kebijakan tersebut. Pengguna super dan pengguna dengan sys:secadmin izin dapat menggunakan CREATE VIEW pada tampilan atau LBV dengan kebijakan DDM tanpa melepaskan kebijakan.
Tampilan dengan kebijakan DDM terlampir tidak dapat mereferensikan tabel dan tampilan sistem. Tampilan yang mengikat akhir dapat mereferensikan tabel dan tampilan sistem.
Tampilan pengikatan akhir dengan kebijakan DDM terlampir tidak dapat mereferensikan data bersarang di data lake, seperti dokumen JSON.
Tampilan yang mengikat akhir tidak dapat memiliki kebijakan DDM yang dilampirkan jika tampilan pengikatan terlambat itu direferensikan oleh tampilan apa pun.
Kebijakan DDM yang dilampirkan pada tampilan yang mengikat akhir dilampirkan dengan nama kolom. Pada waktu kueri, Amazon Redshift memvalidasi bahwa semua kebijakan masking yang dilampirkan ke tampilan pengikatan akhir telah berhasil diterapkan, dan bahwa jenis kolom keluaran tampilan pengikatan akhir cocok dengan tipe dalam kebijakan masking terlampir. Jika validasi gagal, Amazon Redshift mengembalikan kesalahan untuk kueri.

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Keamanan metadata

Mengelola kebijakan masking data dinamis