Amazon Redshift tidak akan lagi mendukung pembuatan Python UDFs baru mulai Patch 198. Python yang ada UDFs akan terus berfungsi hingga 30 Juni 2026. Untuk informasi lebih lanjut, lihat [posting blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Keamanan tingkat baris
Menggunakan keamanan tingkat baris (RLS) di Amazon Redshift, Anda dapat memiliki kontrol akses granular atas data sensitif Anda. Anda dapat memutuskan pengguna atau peran mana yang dapat mengakses catatan data tertentu dalam skema atau tabel, berdasarkan kebijakan keamanan yang ditentukan pada tingkat objek database. Selain keamanan tingkat kolom, di mana Anda dapat memberikan izin kepada pengguna ke subset kolom, gunakan kebijakan RLS untuk membatasi akses lebih lanjut ke baris tertentu dari kolom yang terlihat. Untuk informasi selengkapnya tentang keamanan tingkat kolom, lihat. [Catatan penggunaan untuk kontrol akses tingkat kolom](r_GRANT-usage-notes.md#r_GRANT-usage-notes-clp)
Saat menerapkan kebijakan RLS pada tabel, Anda dapat membatasi set hasil yang dikembalikan saat pengguna menjalankan kueri.
Saat membuat kebijakan RLS, Anda dapat menentukan ekspresi yang menentukan apakah Amazon Redshift mengembalikan baris yang ada dalam tabel dalam kueri. Dengan membuat kebijakan RLS untuk membatasi akses, Anda tidak perlu menambahkan atau mengeksternalisasi kondisi tambahan dalam kueri Anda.
Saat membuat kebijakan RLS, sebaiknya Anda membuat kebijakan sederhana dan menghindari pernyataan yang rumit dalam kebijakan. Saat mendefinisikan kebijakan RLS, jangan gunakan gabungan tabel berlebihan dalam definisi kebijakan yang didasarkan pada kebijakan.
Saat kebijakan mengacu pada tabel pencarian, Amazon Redshift memindai tabel tambahan, selain tabel tempat kebijakan tersebut ada. Akan ada perbedaan kinerja antara kueri yang sama untuk pengguna dengan kebijakan RLS yang dilampirkan, dan pengguna tanpa kebijakan apa pun yang dilampirkan.
# Menggunakan kebijakan RLS dalam pernyataan SQL
Saat menggunakan kebijakan RLS dalam pernyataan SQL, Amazon Redshift menerapkan aturan berikut:
+ Amazon Redshift menerapkan kebijakan RLS ke pernyataan SELECT, UPDATE, dan DELETE secara default.
+ Untuk SELECT dan UNLOAD, Amazon Redshift memfilter baris sesuai dengan kebijakan yang Anda tentukan.
+ Untuk PEMBARUAN, Amazon Redshift hanya memperbarui baris yang terlihat oleh Anda. Jika kebijakan membatasi subset baris dalam tabel, Anda tidak dapat memperbaruinya.
+ Untuk DELETE, Anda hanya dapat menghapus baris yang terlihat oleh Anda. Jika kebijakan membatasi subset baris dalam tabel, Anda tidak dapat menghapusnya. Untuk TRUNCATE, Anda masih bisa memotong tabel.
+ Untuk CREATE TABLE LIKE, tabel yang dibuat dengan opsi LIKE tidak akan mewarisi pengaturan izin dari tabel sumber. Demikian pula, tabel target tidak akan mewarisi kebijakan RLS dari tabel sumber.
# Menggabungkan beberapa kebijakan per pengguna
RLS di Amazon Redshift mendukung melampirkan beberapa kebijakan per pengguna dan objek. Jika ada beberapa kebijakan yang ditentukan untuk pengguna, Amazon Redshift menerapkan semua kebijakan dengan sintaks AND atau OR tergantung pada setelan JENIS KONJUNGSI RLS untuk tabel. Untuk informasi lebih lanjut tentang jenis konjungsi, lihat[ALTER TABLE](r_ALTER_TABLE.md).
Beberapa kebijakan pada tabel dapat dikaitkan dengan Anda. Baik beberapa kebijakan secara langsung melekat pada Anda, atau Anda termasuk dalam beberapa peran, dan peran tersebut memiliki kebijakan berbeda yang melekat padanya.
Jika beberapa kebijakan harus membatasi akses baris dalam relasi tertentu, Anda dapat menyetel JENIS KONJUNGSI RLS dari relasi ke AND. Pertimbangkan contoh berikut. Alice hanya dapat melihat acara Olahraga yang memiliki “catname” NBA sesuai kebijakan yang ditentukan.
```
-- Create an analyst role and grant it to a user named Alice.
CREATE ROLE analyst;
CREATE USER alice WITH PASSWORD 'Name_is_alice_1';
GRANT ROLE analyst TO alice;
-- Create an RLS policy that only lets the user see sports.
CREATE RLS POLICY policy_sports
WITH (catgroup VARCHAR(10))
USING (catgroup = 'Sports');
-- Create an RLS policy that only lets the user see NBA.
CREATE RLS POLICY policy_nba
WITH (catname VARCHAR(10))
USING (catname = 'NBA');
-- Attach both to the analyst role.
ATTACH RLS POLICY policy_sports ON category TO ROLE analyst;
ATTACH RLS POLICY policy_nba ON category TO ROLE analyst;
-- Activate RLS on the category table with AND CONJUNCTION TYPE.
ALTER TABLE category ROW LEVEL SECURITY ON CONJUNCTION TYPE AND;
-- Change session to Alice.
SET SESSION AUTHORIZATION alice;
-- Select all from the category table.
SELECT catgroup, catname
FROM category;
catgroup | catname
---------+---------
Sports | NBA
(1 row)
```
Ketika beberapa kebijakan harus mengizinkan pengguna untuk melihat lebih banyak baris dalam relasi tertentu, pengguna dapat menyetel JENIS KONJUNGSI RLS dari relasi ke OR. Pertimbangkan contoh berikut. Alice hanya dapat melihat “Konser” dan “Olahraga” sebagai kebijakan yang ditentukan.
```
-- Create an analyst role and grant it to a user named Alice.
CREATE ROLE analyst;
CREATE USER alice WITH PASSWORD 'Name_is_alice_1';
GRANT ROLE analyst TO alice;
-- Create an RLS policy that only lets the user see concerts.
CREATE RLS POLICY policy_concerts
WITH (catgroup VARCHAR(10))
USING (catgroup = 'Concerts');
-- Create an RLS policy that only lets the user see sports.
CREATE RLS POLICY policy_sports
WITH (catgroup VARCHAR(10))
USING (catgroup = 'Sports');
-- Attach both to the analyst role.
ATTACH RLS POLICY policy_concerts ON category TO ROLE analyst;
ATTACH RLS POLICY policy_sports ON category TO ROLE analyst;
-- Activate RLS on the category table with OR CONJUNCTION TYPE.
ALTER TABLE category ROW LEVEL SECURITY ON CONJUNCTION TYPE OR;
-- Change session to Alice.
SET SESSION AUTHORIZATION alice;
-- Select all from the category table.
SELECT catgroup, count(*)
FROM category
GROUP BY catgroup ORDER BY catgroup;
catgroup | count
---------+-------
Concerts | 3
Sports | 5
(2 rows)
```
# Kepemilikan dan manajemen kebijakan RLS
Sebagai superuser, administrator keamanan, atau pengguna yang memiliki peran sys:secadmin, Anda dapat membuat, memodifikasi, melampirkan, dan melepaskan kebijakan RLS. Kebijakan RLS dapat dilampirkan ke tabel, tampilan, tampilan pengikatan akhir (LBVs), dan tampilan terwujud (MVs). Pada tingkat objek, Anda dapat mengaktifkan atau menonaktifkan keamanan tingkat baris tanpa mengubah definisi skema untuk tabel.
Untuk memulai dengan keamanan tingkat baris, berikut adalah pernyataan SQL yang dapat Anda gunakan:
+ Gunakan pernyataan ALTER TABLE untuk mengaktifkan atau menonaktifkan RLS pada tabel, tampilan, atau tampilan pengikatan akhir. Untuk informasi selengkapnya, lihat [ALTER TABLE](r_ALTER_TABLE.md).
+ Gunakan pernyataan ALTER MATERIALIZED VIEW ke pernyataan untuk mengaktifkan atau menonaktifkan RLS pada tampilan terwujud (MV). Untuk informasi selengkapnya, lihat [MENGUBAH TAMPILAN TERWUJUD](r_ALTER_MATERIALIZED_VIEW.md).
+ Gunakan pernyataan CREATE RLS POLICY untuk membuat kebijakan keamanan untuk satu atau beberapa tabel, dan tentukan satu atau beberapa pengguna atau peran dalam kebijakan tersebut.
Untuk informasi selengkapnya, lihat [BUAT KEBIJAKAN RLS](r_CREATE_RLS_POLICY.md).
+ Gunakan pernyataan ALTER RLS POLICY untuk mengubah kebijakan, seperti mengubah definisi kebijakan. Anda dapat menggunakan kebijakan yang sama untuk beberapa tabel atau tampilan.
Untuk informasi selengkapnya, lihat [MENGUBAH KEBIJAKAN RLS](r_ALTER_RLS_POLICY.md).
+ Gunakan pernyataan ATTACH RLS POLICY untuk melampirkan kebijakan ke satu atau beberapa relasi, ke satu atau beberapa pengguna, atau peran.
Untuk informasi selengkapnya, lihat [LAMPIRKAN KEBIJAKAN RLS](r_ATTACH_RLS_POLICY.md).
+ Gunakan pernyataan KEBIJAKAN RLS DETACH untuk melepaskan kebijakan dari satu atau beberapa relasi, dari satu atau beberapa pengguna, atau dari peran.
Untuk informasi selengkapnya, lihat [KEBIJAKAN DETACH RLS](r_DETACH_RLS_POLICY.md).
+ Gunakan pernyataan DROP RLS POLICY untuk menghapus kebijakan.
Untuk informasi selengkapnya, lihat [KEBIJAKAN DROP RLS](r_DROP_RLS_POLICY.md).
+ Gunakan pernyataan GRANT dan REVOKE untuk secara eksplisit memberikan dan mencabut izin SELECT ke kebijakan RLS yang mereferensikan tabel pencarian. Untuk informasi selengkapnya, lihat [HIBAH](r_GRANT.md) dan [MENCABUT](r_REVOKE.md).
Untuk memantau kebijakan yang dibuat, sys:secadmin dapat melihat dan. [SVV\$1RLS\$1POLICY](r_SVV_RLS_POLICY.md) [SVV\$1RLS\$1ATTACHED\$1POLICY](r_SVV_RLS_ATTACHED_POLICY.md)
Untuk membuat daftar hubungan yang dilindungi RLS, sys:secadmin dapat melihat. [SVV\$1RLS\$1RELASI](r_SVV_RLS_RELATION.md)
Untuk melacak penerapan kebijakan RLS pada kueri yang mereferensikan hubungan yang dilindungi RLS, superuser, sys:operator, atau pengguna mana pun dengan izin sistem ACCESS SYSTEM TABLE dapat melihat. [SVV\$1RLS\$1APPLIED\$1POLICY](r_SVV_RLS_APPLIED_POLICY.md) Perhatikan bahwa sys:secadmin tidak diberikan izin ini secara default.
Untuk memungkinkan pengguna mengakses penuh ke relasi yang dilindungi RLS, Anda dapat memberikan izin IGNORE RLS. Superusers atau sys:secadmin secara otomatis diberikan IGNORE RLS. Untuk informasi selengkapnya, lihat [HIBAH](r_GRANT.md).
Untuk menjelaskan filter kebijakan RLS dari kueri dalam rencana EXPLOW untuk memecahkan masalah kueri terkait RLS, Anda dapat memberikan izin EXPLORE RLS kepada pengguna mana pun. Untuk informasi selengkapnya, lihat [HIBAH](r_GRANT.md) dan [EXPLAIN](r_EXPLAIN.md).
# Objek dan prinsip yang bergantung pada kebijakan
Untuk memberikan keamanan bagi aplikasi dan mencegah objek kebijakan menjadi basi atau tidak valid, Amazon Redshift tidak mengizinkan menjatuhkan atau mengubah objek yang direferensikan oleh kebijakan RLS.
Berikut daftar dependensi objek skema yang dilacak Amazon Redshift untuk kebijakan RLS.
+ Saat melacak ketergantungan objek skema untuk tabel target, Amazon Redshift mengikuti aturan berikut:
+ Amazon Redshift melepaskan kebijakan dari relasi, pengguna, peran, atau publik saat Anda menjatuhkan tabel target.
+ Saat Anda mengganti nama tabel target, tidak ada dampak pada kebijakan terlampir.
+ Anda hanya dapat menjatuhkan kolom tabel target yang direferensikan di dalam definisi kebijakan jika Anda menghapus atau melepaskan kebijakan terlebih dahulu. Ini juga berlaku ketika opsi CASCADE ditentukan. Anda dapat menjatuhkan kolom lain di tabel target.
+ Anda tidak dapat mengganti nama kolom yang dirujuk dari tabel target. Untuk mengganti nama kolom yang dirujuk, lepaskan kebijakan terlebih dahulu. Ini juga berlaku ketika opsi CASCADE ditentukan.
+ Anda tidak dapat mengubah jenis kolom yang dirujuk, bahkan ketika Anda menentukan opsi CASCADE.
+ Saat melacak ketergantungan objek skema untuk tabel pencarian, Amazon Redshift mengikuti aturan berikut:
+ Anda tidak dapat menjatuhkan tabel pencarian. Untuk menjatuhkan tabel pencarian, pertama-tama lepaskan kebijakan di mana tabel pencarian dirujuk.
+ Anda tidak dapat mengganti nama tabel pencarian. Untuk mengganti nama tabel pencarian, pertama-tama lepaskan kebijakan di mana tabel pencarian dirujuk. Ini juga berlaku ketika opsi CASCADE ditentukan.
+ Anda tidak dapat menjatuhkan kolom tabel pencarian yang digunakan dalam definisi kebijakan. Untuk menghapus kolom tabel pencarian yang digunakan dalam definisi kebijakan, pertama-tama lepaskan kebijakan tempat tabel pencarian dirujuk. Ini juga berlaku ketika opsi CASCADE ditentukan dalam pernyataan ALTER TABLE DROP COLUMN. Anda dapat menjatuhkan kolom lain di tabel pencarian.
+ Anda tidak dapat mengganti nama kolom yang dirujuk dari tabel pencarian. Untuk mengganti nama kolom yang dirujuk, pertama-tama lepaskan kebijakan di mana tabel pencarian dirujuk. Ini juga berlaku ketika opsi CASCADE ditentukan.
+ Anda tidak dapat mengubah jenis kolom yang dirujuk.
+ Saat pengguna atau peran dihapus, Amazon Redshift akan melepaskan semua kebijakan yang dilampirkan ke pengguna atau peran secara otomatis.
+ Saat Anda menggunakan opsi CASCADE dalam pernyataan DROP SCHEMA, Amazon Redshift juga menghapus relasi dalam skema. Ini juga menjatuhkan hubungan dalam skema lain yang bergantung pada hubungan dalam skema yang dijatuhkan. Untuk relasi yang merupakan tabel pencarian dalam kebijakan, Amazon Redshift gagal dalam DROP SCHEMA DDL. Untuk setiap hubungan yang dijatuhkan oleh pernyataan DROP SCHEMA, Amazon Redshift melepaskan semua kebijakan yang melekat pada hubungan tersebut.
+ Anda hanya dapat menghapus fungsi pencarian (fungsi yang dirujuk di dalam definisi kebijakan) saat Anda juga menghapus kebijakan. Ini juga berlaku ketika opsi CASCADE ditentukan.
+ Saat kebijakan dilampirkan ke tabel, Amazon Redshift memeriksa apakah tabel ini adalah tabel pencarian dalam kebijakan yang berbeda. Jika demikian, Amazon Redshift tidak akan mengizinkan melampirkan kebijakan ke tabel ini.
+ Saat membuat kebijakan RLS, Amazon Redshift memeriksa apakah tabel ini adalah tabel target untuk kebijakan RLS lainnya. Jika ini masalahnya, Amazon Redshift tidak akan mengizinkan pembuatan kebijakan di tabel ini.
## Contoh
Contoh berikut menggambarkan bagaimana ketergantungan skema dilacak.
```
-- The CREATE and ATTACH policy statements for `policy_events` references some
-- target and lookup tables.
-- Target tables are tickit_event_redshift and target_schema.target_event_table.
-- Lookup table is tickit_sales_redshift.
-- Policy `policy_events` has following dependencies:
-- table tickit_sales_redshift column eventid, qtysold
-- table tickit_event_redshift column eventid
-- table target_event_table column eventid
-- schema public and target_schema
CREATE RLS POLICY policy_events
WITH (eventid INTEGER)
USING (
eventid IN (SELECT eventid FROM tickit_sales_redshift WHERE qtysold <3)
);
ATTACH RLS POLICY policy_events ON tickit_event_redshift TO ROLE analyst;
ATTACH RLS POLICY policy_events ON target_schema.target_event_table TO ROLE consumer;
```
# Pertimbangan dan batasan menggunakan kebijakan RLS
## Pertimbangan-pertimbangan
Berikut ini adalah pertimbangan untuk bekerja dengan kebijakan RLS:
+ Amazon Redshift menerapkan kebijakan RLS ke pernyataan SELECT, UPDATE, atau DELETE.
+ Amazon Redshift tidak menerapkan kebijakan RLS ke pernyataan INSERT, COPY, ALTER TABLE APPEND.
+ Kebijakan RLS dapat dilampirkan ke tabel, tampilan, tampilan pengikatan akhir (LBVs), dan tampilan terwujud (MVs).
+ Keamanan tingkat baris bekerja dengan keamanan tingkat kolom untuk melindungi data Anda.
+ Ketika RLS diaktifkan untuk relasi sumber, Amazon Redshift mendukung pernyataan ALTER TABLE APPEND untuk pengguna super, pengguna yang telah secara eksplisit diberikan izin sistem IGNORE RLS, atau peran sys:secadmin. Dalam hal ini, Anda dapat menjalankan pernyataan ALTER TABLE APPEND untuk menambahkan baris ke tabel target dengan memindahkan data dari tabel sumber yang ada. Amazon Redshift memindahkan semua tupel dari relasi sumber ke dalam relasi target. Status RLS dari relasi target tidak mempengaruhi pernyataan ALTER TABLE APPEND.
+ Untuk memfasilitasi migrasi dari sistem gudang data lain, Anda dapat mengatur dan mengambil variabel konteks sesi yang disesuaikan untuk koneksi dengan menentukan nama dan nilai variabel.
Contoh berikut menetapkan variabel konteks sesi untuk kebijakan keamanan tingkat baris (RLS).
```
-- Set a customized context variable.
SELECT set_config(‘app.category’, ‘Concerts’, FALSE);
-- Create a RLS policy using current_setting() to get the value of a customized context variable.
CREATE RLS POLICY policy_categories
WITH (catgroup VARCHAR(10))
USING (catgroup = current_setting('app.category', FALSE));
-- Set correct roles and attach the policy on the target table to one or more roles.
ATTACH RLS POLICY policy_categories ON tickit_category_redshift TO ROLE analyst, ROLE dbadmin;
```
Untuk detail tentang cara mengatur dan mengambil variabel konteks sesi yang disesuaikan, buka[SET](r_SET.md),,[SET\$1CONFIG](r_SET_CONFIG.md), [MEMPERLIHATKAN](r_SHOW.md)[CURRENT\$1SETTING](r_CURRENT_SETTING.md), dan[ATUR ULANG](r_RESET.md). Untuk informasi lebih lanjut tentang memodifikasi konfigurasi server secara umum, buka. [Memodifikasi konfigurasi server](cm_chap_ConfigurationRef.md#t_Modifying_the_default_settings)
**penting**
Saat menggunakan variabel konteks sesi dalam kebijakan RLS, kebijakan keamanan bergantung pada pengguna atau peran yang memanggil kebijakan. Berhati-hatilah untuk menghindari kerentanan keamanan saat menggunakan variabel konteks sesi dalam kebijakan RLS.
+ Mengubah pengguna sesi menggunakan OTORISASI SESI SET antara DECLARE dan FETCH atau antara pernyataan FETCH berikutnya tidak akan menyegarkan paket yang sudah disiapkan berdasarkan kebijakan pengguna pada waktu DECLARE. Hindari mengubah pengguna sesi saat kursor digunakan dengan tabel yang dilindungi RLS.
+ Ketika objek dasar di dalam objek tampilan dilindungi RLS, kebijakan yang dilampirkan ke pengguna yang menjalankan kueri diterapkan pada objek dasar masing-masing. Ini berbeda dari pemeriksaan izin tingkat objek, di mana izin pemilik tampilan diperiksa terhadap objek dasar tampilan. Anda dapat melihat hubungan kueri yang dilindungi RLS dalam output rencana EXPLOW.
+ Ketika fungsi yang ditentukan pengguna (UDF) direferensikan dalam kebijakan RLS dari relasi yang dilampirkan ke pengguna, pengguna harus memiliki izin EXECUTE atas UDF untuk menanyakan relasi tersebut.
+ Keamanan tingkat baris mungkin membatasi pengoptimalan kueri. Sebaiknya evaluasi kinerja kueri dengan cermat sebelum menerapkan tampilan yang dilindungi RLS pada kumpulan data besar.
+ Kebijakan keamanan tingkat baris yang diterapkan pada tampilan yang mengikat akhir mungkin didorong ke tabel federasi. Kebijakan RLS ini mungkin terlihat di log mesin pemrosesan eksternal.
## Batasan
Berikut ini adalah batasan saat bekerja dengan kebijakan RLS:
+ Kebijakan RLS tidak dapat dilampirkan ke tabel eksternal dan beberapa jenis relasi lainnya. Untuk informasi selengkapnya, lihat [LAMPIRKAN KEBIJAKAN RLS](r_ATTACH_RLS_POLICY.md).
+ Amazon Redshift mendukung pernyataan SELECT untuk kebijakan RLS tertentu dengan pencarian yang memiliki gabungan kompleks, tetapi tidak mendukung pernyataan UPDATE atau DELETE. Dalam kasus dengan pernyataan UPDATE atau DELETE, Amazon Redshift mengembalikan kesalahan berikut:
```
ERROR: One of the RLS policies on target relation is not supported in UPDATE/DELETE.
```
+ Setiap kali fungsi yang ditentukan pengguna (UDF) direferensikan dalam kebijakan RLS dari relasi yang dilampirkan ke pengguna, pengguna harus memiliki izin EXECUTE atas UDF untuk menanyakan relasi.
+ Subquery berkorelasi tidak didukung. Amazon Redshift mengembalikan kesalahan berikut:
```
ERROR: RLS policy could not be rewritten.
```
+ Amazon Redshift tidak mendukung datasharing dengan RLS. Jika relasi tidak menonaktifkan RLS untuk datashares, kueri gagal di cluster konsumen dengan kesalahan berikut:
```
RLS-protected relation "rls_protected_table" cannot be accessed via datasharing query.
```
Anda dapat mematikan RLS untuk datashares menggunakan perintah ALTER TABLE dengan parameter ROW LEVEL SECURITY OFF FOR DATASHARES. Untuk informasi lebih lanjut tentang menggunakan ALTER TABLE untuk mengaktifkan atau menonaktifkan RLS, buka. [ALTER TABLE](r_ALTER_TABLE.md)
+ Dalam kueri lintas basis data, Amazon Redshift memblokir pembacaan ke relasi yang dilindungi RLS. Pengguna dengan izin IGNORE RLS dapat mengakses relasi yang dilindungi menggunakan kueri lintas basis data. Ketika pengguna tanpa izin IGNORE RLS mengakses relasi yang dilindungi RLS melalui kueri lintas basis data, kesalahan berikut akan muncul:
```
RLS-protected relation "rls_protected_table" cannot be accessed via cross-database query.
```
+ KEBIJAKAN ALTER RLS hanya mendukung modifikasi kebijakan RLS menggunakan klausa USING (using\$1predicate\$1exp). Anda tidak dapat mengubah kebijakan RLS dengan klausa WITH saat menjalankan KEBIJAKAN ALTER RLS.
+ Anda tidak dapat melakukan kueri relasi yang mengaktifkan keamanan tingkat baris jika nilai 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 jika Anda mencoba menanyakan relasi dengan keamanan tingkat baris dan melihat pesan “RLS 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 keamanan tingkat baris, perintah berikut akan diblokir untuk pengguna biasa:
```
ALTER SET enable_case_sensitive_super_attribute/enable_case_sensitive_identifier/downcase_delimited_identifier
```
Saat Anda membuat kebijakan RLS, 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](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html) *Pergeseran Merah Amazon*. Untuk informasi tentang perintah ALTER USER, lihat[ALTER USER](r_ALTER_USER.md).
+ Tampilan dan tampilan yang mengikat akhir dengan kebijakan keamanan tingkat baris tidak dapat diganti oleh pengguna biasa yang menggunakan perintah. [CREATE VIEW](r_CREATE_VIEW.md) Untuk mengganti tampilan atau LBVs dengan kebijakan RLS, pertama-tama lepaskan kebijakan RLS yang dilampirkan padanya, ganti tampilan atau LBVs, dan pasang kembali kebijakan. Pengguna super dan pengguna dengan `sys:secadmin permission` dapat menggunakan CREATE VIEW pada tampilan atau LBVs dengan kebijakan RLS tanpa melepaskan kebijakan.
+ Tampilan dengan kebijakan keamanan tingkat baris tidak dapat mereferensikan tabel sistem dan tampilan sistem.
+ Tampilan pengikatan akhir yang direferensikan oleh tampilan reguler tidak dapat dilindungi RLS.
+ Relasi yang dilindungi RLS dan data bersarang dari data lake tidak dapat diakses dalam kueri yang sama.
# Praktik terbaik untuk kinerja RLS
Berikut ini adalah praktik terbaik untuk memastikan kinerja yang lebih baik dari Amazon Redshift pada tabel yang dilindungi oleh RLS.
## Keamanan operator dan fungsi
Saat menanyakan tabel yang dilindungi RLS, penggunaan operator atau fungsi tertentu dapat menyebabkan penurunan kinerja. Amazon Redshift mengklasifikasikan operator dan fungsi sebagai aman atau tidak aman untuk menanyakan tabel yang dilindungi RLS. Fungsi atau operator diklasifikasikan sebagai RLS-safe ketika tidak memiliki efek samping yang dapat diamati tergantung pada input. Secara khusus, fungsi atau operator RLS-safe tidak dapat menjadi salah satu dari yang berikut:
+ Mengeluarkan nilai input, atau nilai apa pun yang bergantung pada nilai input, dengan atau tanpa pesan kesalahan.
+ Gagal atau mengembalikan kesalahan yang tergantung pada nilai input.
Operator RLS-tidak aman meliputi:
+ Operator aritmatika — \$1, -,/, \$1,%.
+ Operator teks — LIKE dan MIRIP DENGAN.
+ Operator pemeran.
+ UDFs.
Gunakan pernyataan SELECT berikut untuk memeriksa keamanan operator dan fungsi.
```
SELECT proname, proc_is_rls_safe(oid) FROM pg_proc;
```
Amazon Redshift memberlakukan pembatasan pada urutan evaluasi predikat pengguna yang berisi operator dan fungsi RLS-unsafe saat merencanakan kueri pada tabel yang dilindungi RLS. Kueri yang merujuk pada operator atau fungsi RLS-unsafe dapat menyebabkan penurunan kinerja saat menanyakan tabel yang dilindungi RLS. Kinerja dapat menurun secara signifikan ketika Amazon Redshift tidak dapat mendorong predikat RLS-unsafe ke pemindaian tabel dasar untuk memanfaatkan kunci pengurutan. Untuk kinerja yang lebih baik, hindari kueri menggunakan predikat RLS-unsafe yang memanfaatkan kunci pengurutan. Untuk memverifikasi bahwa Amazon Redshift dapat menekan operator dan fungsi, Anda dapat menggunakan pernyataan EXPLORE dalam kombinasi dengan izin sistem EXPLORE RLS.
## Hasil caching
Untuk mengurangi runtime kueri dan meningkatkan kinerja sistem, Amazon Redshift menyimpan hasil jenis kueri tertentu dalam memori pada node pemimpin.
Amazon Redshift menggunakan hasil cache untuk kueri baru yang memindai tabel yang dilindungi RLS ketika semua kondisi untuk tabel yang tidak dilindungi benar dan ketika semua hal berikut benar:
+ Tabel atau tampilan dalam kebijakan belum diubah.
+ Kebijakan tidak menggunakan fungsi yang harus dievaluasi setiap kali dijalankan, seperti GETDATE atau CURRENT\$1USER.
Untuk kinerja yang lebih baik, hindari penggunaan predikat kebijakan yang tidak memenuhi kondisi sebelumnya.
Untuk informasi selengkapnya tentang caching hasil di Amazon Redshift, lihat. [Hasil caching](c_challenges_achieving_high_performance_queries.md#result-caching)
## Kebijakan yang kompleks
Untuk kinerja yang lebih baik, hindari menggunakan kebijakan kompleks dengan subkueri yang menggabungkan beberapa tabel.
# Contoh keamanan tingkat baris end-to-end
Berikut ini adalah end-to-end contoh untuk menggambarkan bagaimana superuser menciptakan beberapa pengguna dan peran. Kemudian, pengguna dengan peran secadmin membuat, melampirkan, melepaskan, dan menjatuhkan kebijakan RLS. Contoh ini menggunakan database sampel tickit. Untuk informasi selengkapnya, lihat [Memuat data dari Amazon S3 ke Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-create-sample-db.html) di Panduan Memulai *Pergeseran Merah Amazon*.
```
-- Create users and roles referenced in the policy statements.
CREATE ROLE analyst;
CREATE ROLE consumer;
CREATE ROLE dbadmin;
CREATE ROLE auditor;
CREATE USER bob WITH PASSWORD 'Name_is_bob_1';
CREATE USER alice WITH PASSWORD 'Name_is_alice_1';
CREATE USER joe WITH PASSWORD 'Name_is_joe_1';
CREATE USER molly WITH PASSWORD 'Name_is_molly_1';
CREATE USER bruce WITH PASSWORD 'Name_is_bruce_1';
GRANT ROLE sys:secadmin TO bob;
GRANT ROLE analyst TO alice;
GRANT ROLE consumer TO joe;
GRANT ROLE dbadmin TO molly;
GRANT ROLE auditor TO bruce;
GRANT ALL ON TABLE tickit_category_redshift TO PUBLIC;
GRANT ALL ON TABLE tickit_sales_redshift TO PUBLIC;
GRANT ALL ON TABLE tickit_event_redshift TO PUBLIC;
-- Create table and schema referenced in the policy statements.
CREATE SCHEMA target_schema;
GRANT ALL ON SCHEMA target_schema TO PUBLIC;
CREATE TABLE target_schema.target_event_table (LIKE tickit_event_redshift);
GRANT ALL ON TABLE target_schema.target_event_table TO PUBLIC;
-- Change session to analyst alice.
SET SESSION AUTHORIZATION alice;
-- Check the tuples visible to analyst alice.
-- Should contain all 3 categories.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
CREATE RLS POLICY policy_concerts
WITH (catgroup VARCHAR(10))
USING (catgroup = 'Concerts');
SELECT poldb, polname, polalias, polatts, polqual, polenabled, polmodifiedby FROM svv_rls_policy WHERE poldb = CURRENT_DATABASE();
ATTACH RLS POLICY policy_concerts ON tickit_category_redshift TO ROLE analyst, ROLE dbadmin;
ALTER TABLE tickit_category_redshift ROW LEVEL SECURITY ON;
SELECT * FROM svv_rls_attached_policy;
-- Change session to analyst alice.
SET SESSION AUTHORIZATION alice;
-- Check that tuples with only `Concert` category will be visible to analyst alice.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to consumer joe.
SET SESSION AUTHORIZATION joe;
-- Although the policy is attached to a different role, no tuples will be
-- visible to consumer joe because the default deny all policy is applied.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to dbadmin molly.
SET SESSION AUTHORIZATION molly;
-- Check that tuples with only `Concert` category will be visible to dbadmin molly.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Check that EXPLAIN output contains RLS SecureScan to prevent disclosure of
-- sensitive information such as RLS filters.
EXPLAIN SELECT catgroup, count(*) FROM tickit_category_redshift GROUP BY catgroup ORDER BY catgroup;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
-- Grant IGNORE RLS permission so that RLS policies do not get applicable to role dbadmin.
GRANT IGNORE RLS TO ROLE dbadmin;
-- Grant EXPLAIN RLS permission so that anyone in role auditor can view complete EXPLAIN output.
GRANT EXPLAIN RLS TO ROLE auditor;
-- Change session to dbadmin molly.
SET SESSION AUTHORIZATION molly;
-- Check that all tuples are visible to dbadmin molly because `IGNORE RLS` is granted to role dbadmin.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to auditor bruce.
SET SESSION AUTHORIZATION bruce;
-- Check explain plan is visible to auditor bruce because `EXPLAIN RLS` is granted to role auditor.
EXPLAIN SELECT catgroup, count(*) FROM tickit_category_redshift GROUP BY catgroup ORDER BY catgroup;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
DETACH RLS POLICY policy_concerts ON tickit_category_redshift FROM ROLE analyst, ROLE dbadmin;
-- Change session to analyst alice.
SET SESSION AUTHORIZATION alice;
-- Check that no tuples are visible to analyst alice.
-- Although the policy is detached, no tuples will be visible to analyst alice
-- because of default deny all policy is applied if the table has RLS on.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
CREATE RLS POLICY policy_events
WITH (eventid INTEGER) AS ev
USING (
ev.eventid IN (SELECT eventid FROM tickit_sales_redshift WHERE qtysold <3)
);
ATTACH RLS POLICY policy_events ON tickit_event_redshift TO ROLE analyst;
ATTACH RLS POLICY policy_events ON target_schema.target_event_table TO ROLE consumer;
RESET SESSION AUTHORIZATION;
-- Can not cannot alter type of dependent column.
ALTER TABLE target_schema.target_event_table ALTER COLUMN eventid TYPE float;
ALTER TABLE tickit_event_redshift ALTER COLUMN eventid TYPE float;
ALTER TABLE tickit_sales_redshift ALTER COLUMN eventid TYPE float;
ALTER TABLE tickit_sales_redshift ALTER COLUMN qtysold TYPE float;
-- Can not cannot rename dependent column.
ALTER TABLE target_schema.target_event_table RENAME COLUMN eventid TO renamed_eventid;
ALTER TABLE tickit_event_redshift RENAME COLUMN eventid TO renamed_eventid;
ALTER TABLE tickit_sales_redshift RENAME COLUMN eventid TO renamed_eventid;
ALTER TABLE tickit_sales_redshift RENAME COLUMN qtysold TO renamed_qtysold;
-- Can not drop dependent column.
ALTER TABLE target_schema.target_event_table DROP COLUMN eventid CASCADE;
ALTER TABLE tickit_event_redshift DROP COLUMN eventid CASCADE;
ALTER TABLE tickit_sales_redshift DROP COLUMN eventid CASCADE;
ALTER TABLE tickit_sales_redshift DROP COLUMN qtysold CASCADE;
-- Can not drop lookup table.
DROP TABLE tickit_sales_redshift CASCADE;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
DROP RLS POLICY policy_concerts;
DROP RLS POLICY IF EXISTS policy_events;
ALTER TABLE tickit_category_redshift ROW LEVEL SECURITY OFF;
RESET SESSION AUTHORIZATION;
-- Drop users and roles.
DROP USER bob;
DROP USER alice;
DROP USER joe;
DROP USER molly;
DROP USER bruce;
DROP ROLE analyst;
DROP ROLE consumer;
DROP ROLE auditor FORCE;
DROP ROLE dbadmin FORCE;
```