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 basis data Anda mengelola keamanan database dengan mengontrol pengguna mana yang memiliki akses ke objek database mana. Pengguna dapat diberi peran atau grup, dan izin yang Anda berikan kepada pengguna, peran, atau grup menentukan objek database mana yang dapat mereka akses. **Topics** + [Ikhtisar keamanan Amazon Redshift](c_security-overview.md) + [Izin pengguna basis data default](r_Privileges.md) + [superuser](r_superusers.md) + [Pengguna](r_Users.md) + [Grup](r_Groups.md) + [Skema](r_Schemas_and_tables.md) + [Kontrol akses berbasis peran (RBAC)](t_Roles.md) + [Keamanan tingkat baris](t_rls.md) + [Keamanan metadata](t_metadata_security.md) + [Penutupan data dinamis](t_ddm.md) + [Izin tercakup](t_scoped-permissions.md) Akses ke objek database bergantung pada izin yang Anda berikan kepada pengguna atau peran. Pedoman berikut merangkum cara kerja keamanan database: + Secara default, izin hanya diberikan kepada pemilik objek. + Pengguna database Amazon Redshift diberi nama pengguna yang dapat terhubung ke database. Pengguna diberikan izin dengan dua cara: secara eksplisit, dengan meminta izin tersebut ditetapkan langsung ke akun, atau secara implisit, dengan menjadi anggota grup yang diberikan izin. + Grup adalah kumpulan pengguna yang dapat secara kolektif diberi izin untuk pemeliharaan keamanan yang efisien. + Skema adalah kumpulan tabel database dan objek database lainnya. Skema mirip dengan direktori sistem file, kecuali skema tidak dapat bersarang. Pengguna dapat diberikan akses ke skema tunggal atau ke beberapa skema. Selain itu, Amazon Redshift menggunakan fitur-fitur berikut untuk memberi Anda kontrol yang lebih baik atas pengguna mana yang memiliki akses ke objek database mana: + Kontrol akses berbasis peran (RBAC) memungkinkan Anda menetapkan izin untuk peran yang kemudian dapat Anda terapkan ke pengguna, memungkinkan Anda mengontrol izin untuk kelompok besar pengguna. Tidak seperti grup, peran dapat mewarisi izin dari peran lain. Keamanan tingkat baris (RLS) memungkinkan Anda menentukan kebijakan yang membatasi akses ke baris pilihan Anda, lalu menerapkan kebijakan tersebut ke pengguna atau grup. Dynamic data masking (DDM) lebih melindungi data Anda dengan mengubahnya pada waktu proses kueri sehingga Anda dapat mengizinkan pengguna mengakses data tanpa mengekspos detail sensitif. Untuk contoh implementasi keamanan, lihat[Contoh untuk mengontrol akses pengguna dan grup](t_user_group_examples.md). Untuk informasi selengkapnya tentang melindungi data Anda, lihat [Keamanan di Amazon Redshift di Panduan](https://docs.aws.amazon.com/redshift/latest/mgmt/iam-redshift-user-mgmt.html) Manajemen *Pergeseran Merah Amazon*. # Ikhtisar keamanan Amazon Redshift Keamanan basis data Amazon Redshift berbeda dari jenis keamanan Amazon Redshift lainnya. Selain keamanan database, yang dijelaskan di bagian ini, Amazon Redshift menyediakan fitur-fitur ini untuk mengelola keamanan: + **Kredensyal masuk** — Akses ke Konsol AWS Manajemen Amazon Redshift Anda dikendalikan oleh izin akun Anda. AWS Untuk informasi selengkapnya, lihat [Kredensyal masuk](https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html). + **Manajemen akses** — Untuk mengontrol akses ke sumber daya Amazon Redshift tertentu, Anda menentukan akun AWS Identity and Access Management (IAM). Untuk informasi selengkapnya, lihat [Mengontrol akses ke resource Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/iam-redshift-user-mgmt.html). + **Grup keamanan klaster** — Untuk memberi pengguna lain akses masuk ke klaster Amazon Redshift, Anda menentukan grup keamanan klaster dan mengaitkannya dengan klaster. Untuk informasi selengkapnya, lihat [grup keamanan klaster Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-security-groups.html). + **VPC** — Untuk melindungi akses ke klaster Anda dengan menggunakan lingkungan jaringan virtual, Anda dapat meluncurkan klaster Anda di Amazon Virtual Private Cloud (VPC). Untuk informasi selengkapnya, lihat [Mengelola klaster di Virtual Private Cloud (VPC)](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-clusters-vpc.html). + **Enkripsi klaster** — Untuk mengenkripsi data di semua tabel yang dibuat pengguna, Anda dapat mengaktifkan enkripsi klaster saat meluncurkan klaster. Untuk informasi selengkapnya, lihat [klaster Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html). + **Koneksi SSL** — Untuk mengenkripsi koneksi antara klien SQL dan cluster Anda, Anda dapat menggunakan enkripsi lapisan soket aman (SSL). Untuk informasi selengkapnya, lihat [Connect ke cluster Anda menggunakan SSL](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-ssl-support.html). + **Memuat enkripsi data** — Untuk mengenkripsi file data pemuatan tabel saat Anda mengunggahnya ke Amazon S3, Anda dapat menggunakan enkripsi sisi server atau enkripsi sisi klien. Saat Anda memuat dari data terenkripsi sisi server, Amazon S3 menangani dekripsi secara transparan. Saat Anda memuat dari data terenkripsi sisi klien, perintah Amazon Redshift COPY mendekripsi data saat memuat tabel. Untuk informasi selengkapnya, lihat [Mengunggah data terenkripsi ke Amazon S3](t_uploading-encrypted-data.md). + **Data dalam perjalanan** — Untuk melindungi data Anda saat transit di dalam AWS Cloud, Amazon Redshift menggunakan SSL yang dipercepat perangkat keras untuk berkomunikasi dengan Amazon S3 atau Amazon DynamoDB untuk operasi COPY, UNLOAD, backup, dan restore. + **Kontrol akses tingkat kolom — Untuk memiliki kontrol akses** tingkat kolom untuk data di Amazon Redshift, gunakan pernyataan hibah dan cabut tingkat kolom tanpa harus menerapkan kontrol akses berbasis tampilan atau menggunakan sistem lain. + **Kontrol keamanan tingkat baris — Untuk memiliki kontrol** keamanan tingkat baris untuk data di Amazon Redshift, buat dan lampirkan kebijakan ke peran atau pengguna yang membatasi akses ke baris yang ditentukan dalam kebijakan. # Izin pengguna basis data default Ketika Anda membuat objek database, Anda adalah pemiliknya. Secara default, hanya superuser atau pemilik objek yang dapat menanyakan, memodifikasi, atau memberikan izin pada objek. Agar pengguna dapat menggunakan objek, Anda harus memberikan izin yang diperlukan kepada pengguna atau grup yang berisi pengguna. Superuser database memiliki izin yang sama dengan pemilik database. Amazon Redshift mendukung izin berikut: SELECT, INSERT, UPDATE, DELETE, REFERENCES, CREATE, TEMPORARY, dan USE. Izin yang berbeda dikaitkan dengan jenis objek yang berbeda. Untuk informasi tentang izin objek database yang didukung oleh Amazon Redshift, lihat [HIBAH](r_GRANT.md) perintahnya. Hanya pemilik yang memiliki izin untuk memodifikasi atau menghancurkan suatu objek. Secara default, semua pengguna memiliki izin CREATE dan USE pada skema PUBLIC database. Untuk melarang pengguna membuat objek dalam skema PUBLIC database, gunakan perintah REVOKE untuk menghapus izin tersebut. Untuk mencabut izin yang sebelumnya diberikan, gunakan perintah. [MENCABUT](r_REVOKE.md) Izin pemilik objek, seperti izin DROP, GRANT, dan REVOKE, bersifat implisit dan tidak dapat diberikan atau dicabut. Pemilik objek dapat mencabut izin biasa mereka sendiri, misalnya, untuk membuat tabel hanya-baca untuk diri mereka sendiri dan orang lain. Pengguna super mempertahankan semua izin terlepas dari perintah GRANT dan REVOKE. # Pengguna super Superuser database memiliki izin yang sama dengan pemilik database untuk semua database. Pengguna *admin*, yang merupakan pengguna yang Anda buat saat Anda meluncurkan cluster, adalah superuser. Anda harus menjadi superuser untuk membuat superuser. Tabel sistem Amazon Redshift dan tampilan sistem hanya dapat dilihat oleh pengguna super atau terlihat oleh semua pengguna. Hanya pengguna super yang dapat menanyakan tabel sistem dan tampilan sistem yang ditunjuk “terlihat oleh pengguna super.” Untuk informasi, lihat [Tampilan pemantauan SYS](serverless_views-monitoring.md). Superusers dapat melihat semua tabel katalog. Untuk informasi, lihat [Tabel katalog sistem](c_intro_catalog_views.md). Superuser database melewati semua pemeriksaan izin. Pengguna super mempertahankan semua izin terlepas dari perintah GRANT dan REVOKE. Hati-hati saat menggunakan peran superuser. Kami menyarankan Anda melakukan sebagian besar pekerjaan Anda sebagai peran yang bukan pengguna super. Anda dapat membuat peran administrator dengan izin yang lebih ketat. Untuk informasi selengkapnya tentang membuat peran, lihat [Kontrol akses berbasis peran (RBAC)](t_Roles.md) Untuk membuat superuser database baru, masuk ke database sebagai superuser dan mengeluarkan perintah CREATE USER atau perintah ALTER USER dengan izin CREATEUSER. ``` CREATE USER adminuser CREATEUSER PASSWORD '1234Admin'; ALTER USER adminuser CREATEUSER; ``` Untuk membuat, mengubah, atau menjatuhkan superuser, gunakan perintah yang sama untuk mengelola pengguna. Untuk informasi selengkapnya, lihat [Membuat, mengubah, dan menghapus pengguna](r_Users-creatingaltering-and-deleting-users.md). # Pengguna Anda dapat membuat dan mengelola pengguna database menggunakan perintah Amazon Redshift SQL CREATE USER dan ALTER USER. Atau Anda dapat mengonfigurasi klien SQL Anda dengan driver Amazon Redshift JDBC atau ODBC khusus. Ini mengelola proses pembuatan pengguna database dan kata sandi sementara sebagai bagian dari proses logon database. Driver mengautentikasi pengguna database berdasarkan otentikasi AWS Identity and Access Management (IAM). Jika Anda sudah mengelola identitas pengguna di luar AWS, Anda dapat menggunakan penyedia identitas (IDP) yang sesuai dengan SAMP 2.0 untuk mengelola akses ke sumber daya Amazon Redshift. Anda menggunakan peran IAM untuk mengonfigurasi IDP Anda AWS dan mengizinkan pengguna federasi Anda menghasilkan kredensyal database sementara dan masuk ke database Amazon Redshift. Untuk informasi selengkapnya, lihat [Menggunakan autentikasi IAM untuk menghasilkan kredensyal pengguna database](https://docs.aws.amazon.com/redshift/latest/mgmt/generating-user-credentials.html). Pengguna Amazon Redshift hanya dapat dibuat dan dijatuhkan oleh superuser database. Pengguna diautentikasi saat mereka masuk ke Amazon Redshift. Mereka dapat memiliki database dan objek database (misalnya, tabel). Mereka juga dapat memberikan izin pada objek tersebut kepada pengguna, grup, dan skema untuk mengontrol siapa yang memiliki akses ke objek mana. Pengguna dengan hak CREATE DATABASE dapat membuat database dan memberikan izin ke database tersebut. Superusers memiliki izin kepemilikan database untuk semua database. # Membuat, mengubah, dan menghapus pengguna Pengguna database bersifat global di seluruh cluster gudang data (dan bukan untuk setiap database individu). + Untuk membuat pengguna, gunakan [BUAT PENGGUNA](r_CREATE_USER.md) perintah. + Untuk membuat superuser, gunakan [BUAT PENGGUNA](r_CREATE_USER.md) perintah dengan opsi CREATEUSER. + Untuk menghapus pengguna yang ada, gunakan [JATUHKAN PENGGUNA](r_DROP_USER.md) perintah. + Untuk mengubah pengguna, misalnya mengubah kata sandi, gunakan [ALTER USER](r_ALTER_USER.md) perintah. + Untuk melihat daftar pengguna, kueri tabel katalog PG\$1USER. ``` select * from pg_user; usename | usesysid | usecreatedb | usesuper | usecatupd | passwd | valuntil | useconfig ------------+----------+-------------+----------+-----------+----------+----------+----------- rdsdb | 1 | t | t | t | ******** | | masteruser | 100 | t | t | f | ******** | | dwuser | 101 | f | f | f | ******** | | simpleuser | 102 | f | f | f | ******** | | poweruser | 103 | f | t | f | ******** | | dbuser | 104 | t | f | f | ******** | | (6 rows) ``` # Grup Grup adalah kumpulan pengguna yang semuanya diberikan izin apa pun yang terkait dengan grup. Anda dapat menggunakan grup untuk menetapkan izin. Misalnya, Anda dapat membuat grup yang berbeda untuk penjualan, administrasi, dan dukungan dan memberi pengguna di setiap grup akses yang sesuai ke data yang mereka butuhkan untuk pekerjaan mereka. Anda dapat memberikan atau mencabut izin di tingkat grup, dan perubahan tersebut akan berlaku untuk semua anggota grup, kecuali untuk pengguna super. Untuk melihat semua grup pengguna, kueri tabel katalog sistem PG\$1GROUP: ``` select * from pg_group; ``` Misalnya, untuk daftar semua pengguna database berdasarkan grup, jalankan SQL berikut. ``` SELECT u.usesysid ,g.groname ,u.usename FROM pg_user u LEFT JOIN pg_group g ON u.usesysid = ANY (g.grolist) ``` # Membuat, mengubah, dan menghapus grup Hanya pengguna super yang dapat membuat, mengubah, atau menjatuhkan grup. Anda dapat melakukan tindakan berikut: + Untuk membuat grup, gunakan [BUAT GRUP](r_CREATE_GROUP.md) perintah. + Untuk menambahkan pengguna ke atau menghapus pengguna dari grup yang ada, gunakan [MENGUBAH KELOMPOK](r_ALTER_GROUP.md) perintah. + Untuk menghapus grup, gunakan [GRUP DROP](r_DROP_GROUP.md) perintah. Perintah ini hanya menjatuhkan grup, bukan pengguna anggotanya. # Contoh untuk mengontrol akses pengguna dan grup Contoh ini membuat grup pengguna dan pengguna dan kemudian memberi mereka berbagai izin untuk database Amazon Redshift yang terhubung ke klien aplikasi web. Contoh ini mengasumsikan tiga kelompok pengguna: pengguna reguler aplikasi web, pengguna daya aplikasi web, dan pengembang web. Untuk informasi tentang cara menghapus pengguna dari grup, lihat[MENGUBAH KELOMPOK](r_ALTER_GROUP.md). 1. Buat grup tempat pengguna akan ditugaskan. Kumpulan perintah berikut menciptakan tiga kelompok pengguna yang berbeda: ``` create group webappusers; create group webpowerusers; create group webdevusers; ``` 1. Buat beberapa pengguna database dengan izin berbeda dan tambahkan ke grup. 1. Buat dua pengguna dan tambahkan ke grup WEBAPPUSERS: ``` create user webappuser1 password 'webAppuser1pass' in group webappusers; create user webappuser2 password 'webAppuser2pass' in group webappusers; ``` 1. Buat pengguna pengembang web dan tambahkan ke grup WEBDEVUSERS: ``` create user webdevuser1 password 'webDevuser2pass' in group webdevusers; ``` 1. Buat superuser. Pengguna ini akan memiliki hak administratif untuk membuat pengguna lain: ``` create user webappadmin password 'webAppadminpass1' createuser; ``` 1. Buat skema untuk dikaitkan dengan tabel database yang digunakan oleh aplikasi web, dan berikan berbagai grup pengguna akses ke skema ini: 1. Buat skema WEBAPP: ``` create schema webapp; ``` 1. Berikan izin PENGGUNAAN ke grup WEBAPPUSERS: ``` grant usage on schema webapp to group webappusers; ``` 1. Berikan izin PENGGUNAAN ke grup WEBPOWERUSERS: ``` grant usage on schema webapp to group webpowerusers; ``` 1. Berikan SEMUA izin ke grup WEBDEVUSERS: ``` grant all on schema webapp to group webdevusers; ``` Pengguna dasar dan grup sekarang sudah diatur. Anda sekarang dapat mengubah pengguna dan grup. 1. Misalnya, perintah berikut mengubah parameter search\$1path untuk. WEBAPPUSER1 ``` alter user webappuser1 set search_path to webapp, public; ``` SEARCH\$1PATH menentukan urutan pencarian skema untuk objek database, seperti tabel dan fungsi, ketika objek direferensikan dengan nama sederhana tanpa skema yang ditentukan. 1. Anda juga dapat menambahkan pengguna ke grup setelah membuat grup, seperti menambahkan WEBAPPUSER2 ke grup WEBPOWERUSERS: ``` alter group webpowerusers add user webappuser2; ``` # Skema Database berisi satu atau lebih skema bernama. Setiap skema dalam database berisi tabel dan jenis objek bernama lainnya. Secara default, database memiliki skema tunggal, yang bernama PUBLIC. Anda dapat menggunakan skema untuk mengelompokkan objek database dengan nama umum. Skema mirip dengan direktori sistem file, kecuali skema tidak dapat bersarang. Nama objek database identik dapat digunakan dalam skema yang berbeda dalam database yang sama tanpa konflik. Misalnya, baik MY\$1SCHEMA dan YOUR\$1SCHEMA dapat berisi tabel bernama MYTABLE. Pengguna dengan izin yang diperlukan dapat mengakses objek di beberapa skema dalam database. Secara default, objek dibuat dalam skema pertama di jalur pencarian database. Untuk informasi, lihat [Jalur pencarian](#c_Search_path) nanti di bagian ini. Skema dapat membantu masalah organisasi dan konkurensi dalam lingkungan multipengguna dengan cara berikut: + Untuk membiarkan banyak pengembang bekerja dalam database yang sama tanpa mengganggu satu sama lain. + Untuk mengatur objek database ke dalam kelompok logis untuk membuatnya lebih mudah dikelola. + Untuk memberikan aplikasi kemampuan untuk menempatkan objek mereka ke dalam skema terpisah sehingga nama mereka tidak akan bertabrakan dengan nama-nama objek yang digunakan oleh aplikasi lain. ## Jalur pencarian Jalur pencarian didefinisikan dalam parameter search\$1path dengan daftar nama skema yang dipisahkan koma. Jalur pencarian menentukan urutan skema yang dicari ketika objek, seperti tabel atau fungsi, direferensikan dengan nama sederhana yang tidak menyertakan kualifikasi skema. Jika objek dibuat tanpa menentukan skema target, objek ditambahkan ke skema pertama yang terdaftar di jalur pencarian. Ketika objek dengan nama identik ada dalam skema yang berbeda, nama objek yang tidak menentukan skema akan merujuk ke skema pertama di jalur pencarian yang berisi objek dengan nama itu. Untuk mengubah skema default untuk sesi saat ini, gunakan [SET](r_SET.md) perintah. Untuk informasi selengkapnya, lihat [search\$1path](r_search_path.md) deskripsi di Referensi Konfigurasi. # Membuat, mengubah, dan menghapus skema Setiap pengguna dapat membuat skema dan mengubah atau menjatuhkan skema yang mereka miliki. Anda dapat melakukan tindakan berikut: + Untuk membuat skema, gunakan [BUAT SKEMA](r_CREATE_SCHEMA.md) perintah. + Untuk mengubah pemilik skema, gunakan [ALTER SCHEMA](r_ALTER_SCHEMA.md) perintah. + Untuk menghapus skema dan objeknya, gunakan [DROP SCHEMA](r_DROP_SCHEMA.md) perintah. + Untuk membuat tabel dalam skema, buat tabel dengan format *schema\$1name.table\$1name*. Untuk melihat daftar semua skema, kueri tabel katalog sistem PG\$1NAMESPACE: ``` select * from pg_namespace; ``` Untuk melihat daftar tabel yang termasuk dalam skema, kueri tabel katalog sistem PG\$1TABLE\$1DEF. Misalnya, query berikut mengembalikan daftar tabel dalam skema PG\$1CATALOG. ``` select distinct(tablename) from pg_table_def where schemaname = 'pg_catalog'; ``` # Izin berbasis skema Izin berbasis skema ditentukan oleh pemilik skema: + Secara default, semua pengguna memiliki izin CREATE dan USE pada skema PUBLIC database. Untuk melarang pengguna membuat objek dalam skema PUBLIC database, gunakan [MENCABUT](r_REVOKE.md) perintah untuk menghapus izin tersebut. + Kecuali mereka diberikan izin PENGGUNAAN oleh pemilik objek, pengguna tidak dapat mengakses objek apa pun dalam skema yang tidak mereka miliki. + Jika pengguna telah diberikan izin CREATE untuk skema yang dibuat oleh pengguna lain, pengguna tersebut dapat membuat objek dalam skema tersebut. # Kontrol akses berbasis peran (RBAC) Dengan menggunakan kontrol akses berbasis peran (RBAC) untuk mengelola izin database di Amazon Redshift, Anda dapat menyederhanakan pengelolaan izin keamanan di Amazon Redshift. Anda dapat mengamankan akses ke data sensitif dengan mengontrol apa yang dapat dilakukan pengguna baik pada tingkat yang luas atau halus. Anda juga dapat mengontrol akses pengguna ke tugas yang biasanya dibatasi untuk pengguna super. Dengan menetapkan izin yang berbeda untuk peran yang berbeda dan menetapkannya ke pengguna yang berbeda, Anda dapat memiliki kontrol akses pengguna yang lebih terperinci. Pengguna dengan peran yang ditetapkan hanya dapat melakukan tugas yang ditentukan oleh peran yang ditetapkan yang mereka otorisasi. Misalnya, pengguna dengan peran yang ditetapkan yang memiliki izin CREATE TABLE dan DROP TABLE hanya diizinkan untuk melakukan tugas tersebut. Anda dapat mengontrol akses pengguna dengan memberikan berbagai tingkat izin keamanan kepada pengguna yang berbeda untuk mengakses data yang mereka butuhkan untuk pekerjaan mereka. RBAC menerapkan prinsip izin paling sedikit kepada pengguna berdasarkan persyaratan peran mereka, terlepas dari jenis objek yang terlibat. Pemberian dan pencabutan izin dilakukan pada tingkat peran, tanpa perlu memperbarui izin pada objek database individu. Dengan RBAC, Anda dapat membuat peran dengan izin untuk menjalankan perintah yang dulu memerlukan izin pengguna super. Pengguna dapat menjalankan perintah ini, selama mereka diberi wewenang dengan peran yang menyertakan izin ini. Demikian pula, Anda juga dapat membuat peran untuk membatasi akses ke perintah tertentu, dan menetapkan peran untuk pengguna super atau pengguna yang telah diberi wewenang dengan peran tersebut. Untuk mempelajari cara kerja Amazon Redshift RBAC, tonton video berikut. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/IhHQ7mZ-tp4/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/IhHQ7mZ-tp4) # Hirarki peran *Peran* adalah kumpulan izin yang dapat Anda tetapkan ke pengguna atau peran lain. Anda dapat menetapkan izin sistem atau database untuk peran. Pengguna mewarisi izin dari peran yang ditetapkan. Di RBAC, pengguna dapat memiliki peran bersarang. Anda dapat memberikan peran kepada pengguna dan peran. Saat memberikan peran kepada pengguna, Anda memberi otorisasi kepada pengguna dengan semua izin yang disertakan peran ini. Saat memberikan peran r1 kepada pengguna, Anda mengotorisasi pengguna dengan izin dari r1. Pengguna sekarang memiliki izin dari r1 dan juga izin yang ada yang sudah mereka miliki. Saat memberikan peran (r1) ke peran lain (r2), Anda mengotorisasi r2 dengan semua izin dari r1. Juga, ketika memberikan r2 ke peran lain (r3), izin r3 adalah kombinasi dari izin dari r1 dan r2. Hirarki peran memiliki izin mewarisi r2 dari r1. Amazon Redshift menyebarkan izin dengan setiap otorisasi peran. Pemberian r1 ke r2 dan kemudian r2 ke r3 mengotorisasi r3 dengan semua izin dari tiga peran. Dengan demikian, dengan memberikan r3 kepada pengguna, pengguna memiliki semua izin dari tiga peran. Amazon Redshift tidak mengizinkan pembuatan siklus otorisasi peran. Siklus otorisasi peran terjadi ketika peran bersarang ditetapkan kembali ke peran sebelumnya dalam hierarki peran, seperti r3 ditugaskan kembali ke r1. Untuk informasi selengkapnya tentang cara membuat peran dan mengelola penetapan peran, lihat[Mengelola peran di RBAC](r_roles-managing.md). # Penugasan peran Pengguna super dan pengguna biasa dengan izin CREATE ROLE dapat menggunakan pernyataan CREATE ROLE untuk membuat peran. Pengguna super dan administrator peran dapat menggunakan pernyataan GRANT ROLE untuk memberikan peran kepada orang lain. Mereka dapat menggunakan pernyataan REVOKE ROLE untuk mencabut peran dari orang lain, dan pernyataan DROP ROLE untuk menghapus peran. Administrator peran termasuk pemilik peran dan pengguna yang telah diberikan peran dengan izin OPSI ADMIN. Hanya pengguna super atau administrator peran yang dapat memberikan dan mencabut peran. Anda dapat memberikan atau mencabut satu atau beberapa peran ke atau dari satu atau beberapa peran atau pengguna. Gunakan opsi WITH ADMIN OPTION dalam pernyataan GRANT ROLE untuk menyediakan opsi administrasi untuk semua peran yang diberikan kepada semua penerima hibah. Amazon Redshift mendukung kombinasi penugasan peran yang berbeda, seperti memberikan banyak peran atau memiliki banyak penerima hibah. OPSI DENGAN ADMIN hanya berlaku untuk pengguna dan bukan untuk peran. Demikian pula, gunakan opsi WITH ADMIN OPTION dalam pernyataan REVOKE ROLE untuk menghapus peran dan otorisasi administratif dari penerima hibah. Saat digunakan dengan OPSI ADMIN, hanya otorisasi administratif yang dicabut dari peran. Contoh berikut mencabut otorisasi administratif `sample_role2` peran dari. `user2` ``` REVOKE ADMIN OPTION FOR sample_role2 FROM user2; ``` Untuk informasi selengkapnya tentang cara membuat peran dan mengelola penetapan peran, lihat[Mengelola peran di RBAC](r_roles-managing.md). # Peran yang ditentukan sistem Amazon Redshift Amazon Redshift menyediakan beberapa peran yang ditentukan sistem yang ditentukan dengan izin tertentu. Peran khusus sistem dimulai dengan awalan. `sys:` Hanya pengguna dengan akses yang sesuai yang dapat mengubah peran yang ditentukan sistem atau membuat peran yang ditentukan sistem khusus. Anda tidak dapat menggunakan `sys:` awalan untuk peran yang ditentukan sistem kustom. Tabel berikut merangkum peran dan izinnya. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/r_roles-default.html) ## Peran dan pengguna yang ditentukan sistem untuk berbagi data Amazon Redshift menciptakan peran dan pengguna untuk penggunaan internal yang sesuai dengan datashares dan konsumen datashare. Setiap nama peran internal dan nama pengguna memiliki awalan namespace yang dicadangkan. `ds:` Mereka memiliki format berikut: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/r_roles-default.html) Peran berbagi data dibuat untuk setiap datashare. Ini memegang semua izin yang saat ini diberikan ke datashare. Pengguna berbagi data dibuat untuk setiap konsumen dari datashare. Ini diberikan izin untuk peran berbagi data tunggal. Konsumen yang ditambahkan ke beberapa datashares akan memiliki pengguna berbagi data yang dibuat untuk setiap datashare. Pengguna dan peran ini diperlukan agar berbagi data berfungsi dengan baik. Mereka tidak dapat dimodifikasi atau dijatuhkan dan tidak dapat diakses atau digunakan untuk tugas apa pun yang dijalankan oleh pelanggan. Anda dapat dengan aman mengabaikannya. Untuk informasi selengkapnya tentang berbagi data, lihat [Berbagi data di seluruh klaster di Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/datashare-overview.html). **catatan** Anda tidak dapat menggunakan `ds:` awalan untuk membuat peran atau pengguna yang ditentukan pengguna. # Izin sistem untuk RBAC Berikut ini adalah daftar izin sistem yang dapat Anda berikan atau cabut dari peran. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/redshift/latest/dg/r_roles-system-privileges.html) # Izin objek database Terlepas dari izin sistem, Amazon Redshift menyertakan izin objek database yang menentukan opsi akses. Ini termasuk opsi seperti kemampuan untuk membaca data dalam tabel dan tampilan, menulis data, membuat tabel, dan menjatuhkan tabel. Untuk informasi selengkapnya, lihat [HIBAH](r_GRANT.md). Dengan menggunakan RBAC, Anda dapat menetapkan izin objek database untuk peran, mirip dengan bagaimana Anda bisa dengan izin sistem. Kemudian Anda dapat menetapkan peran kepada pengguna, mengotorisasi pengguna dengan izin sistem, dan mengotorisasi pengguna dengan izin database. # UBAH HAK ISTIMEWA DEFAULT untuk RBAC Gunakan pernyataan ALTER DEFAULT PRIVILEGES untuk menentukan set default izin akses yang akan diterapkan ke objek yang dibuat di masa depan oleh pengguna yang ditentukan. Secara default, pengguna hanya dapat mengubah izin akses default mereka sendiri. Dengan RBAC, Anda dapat mengatur izin akses default untuk peran. Untuk informasi lebih lanjut, lihat [MENGUBAH HAK ISTIMEWA DEFAULT](r_ALTER_DEFAULT_PRIVILEGES.md) perintah. RBAC memungkinkan Anda untuk menetapkan izin objek database untuk peran, mirip dengan izin sistem. Kemudian Anda dapat menetapkan peran kepada pengguna, mengotorisasi pengguna dengan izin sistem dan/atau database. # Pertimbangan untuk penggunaan peran di RBAC Saat bekerja dengan peran RBAC, pertimbangkan hal berikut: + Amazon Redshift tidak mengizinkan siklus otorisasi peran. Anda tidak dapat memberikan r1 ke r2 dan kemudian memberikan r2 ke r1. + RBAC berfungsi untuk objek Amazon Redshift asli dan tabel Amazon Redshift Spectrum. + Sebagai administrator Amazon Redshift, Anda dapat mengaktifkan RBAC dengan memutakhirkan klaster Anda ke patch pemeliharaan terbaru untuk memulai. + Hanya pengguna super dan pengguna dengan izin sistem CREATE ROLE yang dapat membuat peran. + Hanya pengguna super dan administrator peran yang dapat memodifikasi atau menghapus peran. + Nama peran tidak bisa sama dengan nama pengguna. + Nama peran tidak dapat berisi karakter yang tidak valid, seperti “:/\$1n.” + Nama peran tidak dapat berupa kata yang dicadangkan, seperti PUBLIC. + Nama peran tidak dapat dimulai dengan awalan cadangan untuk peran default. `sys:` + Anda tidak dapat menghapus peran yang memiliki parameter RESTRICT ketika diberikan ke peran lain. Pengaturan default adalah RESTRICT. Amazon Redshift memunculkan kesalahan saat Anda mencoba menjatuhkan peran yang mewarisi peran lain. + Pengguna yang tidak memiliki izin admin pada peran tidak dapat memberikan atau mencabut peran. + RBAC tidak sepenuhnya didukung untuk tabel dan tampilan sistem. Izin RBAC untuk tabel dan tampilan sistem tidak bertahan melalui peningkatan, penurunan, atau pengubahan ukuran. Sebaiknya gunakan [Peran yang ditentukan sistem Amazon RedshiftPeran dan pengguna yang ditentukan sistem untuk berbagi data](r_roles-default.md) untuk mengelola tabel sistem dan melihat izin. Untuk informasi lebih lanjut tentang tabel sistem, buka[Tabel sistem dan tampilan referensi](cm_chap_system-tables.md). # Mengelola peran di RBAC Untuk melakukan tindakan berikut, gunakan perintah berikut: + Untuk membuat peran, gunakan [CREATE ROLE](r_CREATE_ROLE.md) perintah. + Untuk mengganti nama peran atau mengubah pemilik peran, gunakan [MENGUBAH PERAN](r_ALTER_ROLE.md) perintah. + Untuk menghapus peran, gunakan [DROP ROLE](r_DROP_ROLE.md) perintah. + Untuk memberikan peran kepada pengguna, gunakan [HIBAH](r_GRANT.md) perintah. + Untuk mencabut peran dari pengguna, gunakan perintah. [MENCABUT](r_REVOKE.md) + Untuk memberikan izin sistem ke peran, gunakan [HIBAH](r_GRANT.md) perintah. + Untuk mencabut izin sistem dari peran, gunakan perintah. [MENCABUT](r_REVOKE.md) Untuk melihat daftar peran di klaster atau grup kerja Anda, lihat[SVV\$1ROLE](r_SVV_ROLES.md). # Tutorial: Membuat peran dan query dengan RBAC Dengan RBAC, Anda dapat membuat peran dengan izin untuk menjalankan perintah yang dulu memerlukan izin pengguna super. Pengguna dapat menjalankan perintah ini, selama mereka diberi wewenang dengan peran yang menyertakan izin ini. Dalam tutorial ini, Anda menggunakan kontrol akses berbasis peran (RBAC) untuk mengelola izin dalam database yang Anda buat. Anda kemudian terhubung ke database dan kueri database dari dua peran yang berbeda untuk menguji fungsionalitas RBAC. Dua peran yang Anda buat dan gunakan untuk query database adalah `sales_ro` dan`sales_rw`. Anda membuat data `sales_ro` peran dan kueri sebagai pengguna dengan `sales_ro` peran tersebut. `sales_ro`Pengguna hanya dapat menggunakan perintah SELECT tetapi tidak dapat menggunakan perintah UPDATE. Kemudian, Anda membuat `sales_rw` peran dan data kueri sebagai pengguna dengan `sales_rw` peran tersebut. `sales_rw`Pengguna dapat menggunakan perintah SELECT dan perintah UPDATE. Selain itu, Anda dapat membuat peran untuk membatasi akses ke perintah tertentu, dan menetapkan peran untuk pengguna super atau pengguna. **Tugas** + [Prasyarat](#tutorial-rbac-prereqs) + [Langkah 1: Buat pengguna administrator](#tutorial-rbac-step1) + [Langkah 2: Mengatur skema](#tutorial-rbac-step2) + [Langkah 3: Buat pengguna hanya-baca](#tutorial-rbac-step3) + [Langkah 4: Kueri data sebagai pengguna hanya-baca](#tutorial-rbac-step4) + [Langkah 5: Buat pengguna baca-tulis](#tutorial-rbac-step5) + [Langkah 6: Kueri data sebagai pengguna dengan peran hanya-baca yang diwariskan](#tutorial-rbac-step6) + [Langkah 7: Berikan pembaruan dan masukkan izin ke peran baca-tulis](#tutorial-rbac-step7) + [Langkah 8: Kueri data sebagai pengguna baca-tulis](#tutorial-rbac-step8) + [Langkah 9: Analisis dan vakum tabel dalam database sebagai pengguna administrator](#tutorial-rbac-step9) + [Langkah 10: Potong tabel sebagai pengguna baca-tulis](#tutorial-rbac-step10) + [Fungsi sistem untuk RBAC (opsional)](#tutorial-rbac-system-functions) + [Tampilan sistem untuk RBAC (opsional)](#tutorial-rbac-system-views) + [Gunakan keamanan tingkat baris dengan RBAC (opsional)](#tutorial-rbac-rls) ## Prasyarat + Buat klaster Amazon Redshift atau workgroup tanpa server yang dimuat dengan database sampel TICKIT. Untuk membuat grup kerja tanpa server, lihat [Memulai gudang data Redshift Tanpa](https://docs.aws.amazon.com/redshift/latest/gsg/new-user-serverless.html) Server. Untuk membuat klaster, lihat [Membuat contoh klaster Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-launch-sample-cluster.html). Untuk informasi selengkapnya tentang database sampel TICKIT, lihat[Database sampel](c_sampledb.md). + Memiliki akses ke pengguna dengan izin superuser atau administrator peran. Hanya pengguna super atau administrator peran yang dapat memberikan atau mencabut peran. Untuk informasi selengkapnya tentang izin yang diperlukan untuk RBAC, lihat. [Izin sistem untuk RBAC](r_roles-system-privileges.md) + Tinjau[Pertimbangan untuk penggunaan peran di RBAC](r_role-usage-notes.md). ## Langkah 1: Buat pengguna administrator Untuk mengatur tutorial ini, Anda membuat peran admin database dan melampirkannya ke pengguna administrator database di langkah ini. Anda harus membuat administrator database sebagai superuser atau administrator peran. Jalankan semua kueri di editor [kueri Amazon Redshift v2](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-using.html). 1. Untuk membuat peran administrator db\$1admin, gunakan contoh berikut. ``` CREATE ROLE db_admin; ``` 1. Untuk membuat pengguna database bernama dbadmin, gunakan contoh berikut. ``` CREATE USER dbadmin PASSWORD 'Test12345'; ``` 1. Untuk memberikan peran yang ditentukan sistem bernama sys:dba ke peran db\$1admin, gunakan contoh berikut. Ketika diberikan peran sys:dba, pengguna dbadmin dapat membuat skema dan tabel. Untuk informasi selengkapnya, lihat [Peran yang ditentukan sistem Amazon RedshiftPeran dan pengguna yang ditentukan sistem untuk berbagi data](r_roles-default.md). ## Langkah 2: Mengatur skema Pada langkah ini, Anda terhubung ke database Anda sebagai administrator database. Kemudian, Anda membuat dua skema dan menambahkan data ke dalamnya. 1. Connect ke database dev sebagai pengguna dbadmin menggunakan query editor v2. Untuk informasi selengkapnya tentang menghubungkan ke database, lihat [Bekerja dengan editor kueri v2](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-using.html). 1. Untuk membuat skema basis data penjualan dan pemasaran, gunakan contoh berikut. ``` CREATE SCHEMA sales; CREATE SCHEMA marketing; ``` 1. Untuk membuat dan menyisipkan nilai ke dalam tabel dalam skema penjualan, gunakan contoh berikut. ``` CREATE TABLE sales.cat( catid smallint, catgroup varchar(10), catname varchar(10), catdesc varchar(50) ); INSERT INTO sales.cat(SELECT * FROM category); CREATE TABLE sales.dates( dateid smallint, caldate date, day char(3), week smallint, month char(5), qtr char(5), year smallint, holiday boolean ); INSERT INTO sales.dates(SELECT * FROM date); CREATE TABLE sales.events( eventid integer, venueid smallint, catid smallint, dateid smallint, eventname varchar(200), starttime timestamp ); INSERT INTO sales.events(SELECT * FROM event); CREATE TABLE sales.sale( salesid integer, listid integer, sellerid integer, buyerid integer, eventid integer, dateid smallint, qtysold smallint, pricepaid decimal(8,2), commission decimal(8,2), saletime timestamp ); INSERT INTO sales.sale(SELECT * FROM sales); ``` 1. Untuk membuat dan menyisipkan nilai ke dalam tabel dalam skema pemasaran, gunakan contoh berikut. ``` CREATE TABLE marketing.cat( catid smallint, catgroup varchar(10), catname varchar(10), catdesc varchar(50) ); INSERT INTO marketing.cat(SELECT * FROM category); CREATE TABLE marketing.dates( dateid smallint, caldate date, day char(3), week smallint, month char(5), qtr char(5), year smallint, holiday boolean ); INSERT INTO marketing.dates(SELECT * FROM date); CREATE TABLE marketing.events( eventid integer, venueid smallint, catid smallint, dateid smallint, eventname varchar(200), starttime timestamp ); INSERT INTO marketing.events(SELECT * FROM event); CREATE TABLE marketing.sale( marketingid integer, listid integer, sellerid integer, buyerid integer, eventid integer, dateid smallint, qtysold smallint, pricepaid decimal(8,2), commission decimal(8,2), saletime timestamp ); INSERT INTO marketing.sale(SELECT * FROM marketing); ``` ## Langkah 3: Buat pengguna hanya-baca Pada langkah ini, Anda membuat peran hanya-baca dan pengguna analis penjualan untuk peran hanya-baca. Analis penjualan hanya membutuhkan akses read-only ke tabel dalam skema penjualan untuk menyelesaikan tugas yang ditugaskan untuk menemukan peristiwa yang menghasilkan komisi terbesar. 1. Connect ke database sebagai pengguna dbadmin. 1. Untuk membuat peran sales\$1ro, gunakan contoh berikut. ``` CREATE ROLE sales_ro; ``` 1. Untuk membuat pengguna salesanalyst, gunakan contoh berikut. ``` CREATE USER salesanalyst PASSWORD 'Test12345'; ``` 1. Untuk memberikan penggunaan peran sales\$1ro dan memilih akses ke objek skema penjualan, gunakan contoh berikut. ``` GRANT USAGE ON SCHEMA sales TO ROLE sales_ro; GRANT SELECT ON ALL TABLES IN SCHEMA sales TO ROLE sales_ro; ``` 1. Untuk memberi pengguna salesanalyst peran sales\$1ro, gunakan contoh berikut. ``` GRANT ROLE sales_ro TO salesanalyst; ``` ## Langkah 4: Kueri data sebagai pengguna hanya-baca Pada langkah ini, pengguna analis penjualan menanyakan data dari skema penjualan. Kemudian, pengguna analis penjualan mencoba memperbarui tabel dan membaca tabel dalam skema pemasaran. 1. Connect ke database sebagai pengguna salesanalyst. 1. Untuk menemukan 10 penjualan dengan komisi tertinggi, gunakan contoh berikut. ``` SET SEARCH_PATH TO sales; SELECT DISTINCT events.dateid, sale.commission, cat.catname FROM sale, events, dates, cat WHERE events.dateid=dates.dateid AND events.dateid=sale.dateid AND events.catid = cat.catid ORDER BY 2 DESC LIMIT 10; +--------+------------+----------+ | dateid | commission | catname | +--------+------------+----------+ | 1880 | 1893.6 | Pop | | 1880 | 1893.6 | Opera | | 1880 | 1893.6 | Plays | | 1880 | 1893.6 | Musicals | | 1861 | 1500 | Plays | | 2003 | 1500 | Pop | | 1861 | 1500 | Opera | | 2003 | 1500 | Plays | | 1861 | 1500 | Musicals | | 1861 | 1500 | Pop | +--------+------------+----------+ ``` 1. Untuk memilih 10 peristiwa dari tabel acara dalam skema penjualan, gunakan contoh berikut. ``` SELECT * FROM sales.events LIMIT 10; +---------+---------+-------+--------+--------------------+---------------------+ | eventid | venueid | catid | dateid | eventname | starttime | +---------+---------+-------+--------+--------------------+---------------------+ | 4836 | 73 | 9 | 1871 | Soulfest | 2008-02-14 19:30:00 | | 5739 | 41 | 9 | 1871 | Fab Faux | 2008-02-14 19:30:00 | | 627 | 229 | 6 | 1872 | High Society | 2008-02-15 14:00:00 | | 2563 | 246 | 7 | 1872 | Hamlet | 2008-02-15 20:00:00 | | 7703 | 78 | 9 | 1872 | Feist | 2008-02-15 14:00:00 | | 7903 | 90 | 9 | 1872 | Little Big Town | 2008-02-15 19:30:00 | | 7925 | 101 | 9 | 1872 | Spoon | 2008-02-15 19:00:00 | | 8113 | 17 | 9 | 1872 | Santana | 2008-02-15 15:00:00 | | 463 | 303 | 8 | 1873 | Tristan und Isolde | 2008-02-16 19:00:00 | | 613 | 236 | 6 | 1873 | Pal Joey | 2008-02-16 15:00:00 | +---------+---------+-------+--------+--------------------+---------------------+ ``` 1. Untuk mencoba memperbarui eventname untuk eventid 1, jalankan contoh berikut. Contoh ini akan menghasilkan kesalahan izin ditolak karena pengguna analis penjualan hanya memiliki izin SELECT pada tabel peristiwa dalam skema penjualan. Untuk memperbarui tabel peristiwa, Anda harus memberikan izin peran sales\$1ro ke UPDATE. Untuk informasi selengkapnya tentang pemberian izin untuk memperbarui tabel, lihat parameter UPDATE untuk. [HIBAH](r_GRANT.md) Untuk informasi selengkapnya tentang perintah UPDATE, lihat[UPDATE](r_UPDATE.md). ``` UPDATE sales.events SET eventname = 'Comment event' WHERE eventid = 1; ERROR: permission denied for relation events ``` 1. Untuk mencoba memilih semua dari tabel acara dalam skema pemasaran, gunakan contoh berikut. Contoh ini akan menghasilkan kesalahan izin ditolak karena pengguna analis penjualan hanya memiliki izin SELECT untuk tabel peristiwa dalam skema penjualan. Untuk memilih data dari tabel peristiwa dalam skema pemasaran, Anda harus memberikan izin SELECT peran sales\$1ro pada tabel peristiwa dalam skema pemasaran. ``` SELECT * FROM marketing.events; ERROR: permission denied for schema marketing ``` ## Langkah 5: Buat pengguna baca-tulis Pada langkah ini, insinyur penjualan yang bertanggung jawab untuk membangun pipeline ekstrak, transformasi, dan beban (ETL) untuk pemrosesan data dalam skema penjualan akan diberikan akses hanya-baca, tetapi nantinya akan diberikan akses baca dan tulis untuk melakukan tugas mereka. 1. Connect ke database sebagai pengguna dbadmin. 1. Untuk membuat peran sales\$1rw dalam skema penjualan, gunakan contoh berikut. ``` CREATE ROLE sales_rw; ``` 1. Untuk membuat pengguna salesengineer, gunakan contoh berikut. ``` CREATE USER salesengineer PASSWORD 'Test12345'; ``` 1. Untuk memberikan penggunaan peran sales\$1rw dan memilih akses ke objek skema penjualan dengan menetapkan peran sales\$1ro untuk itu, gunakan contoh berikut. Untuk informasi selengkapnya tentang cara peran mewarisi izin di Amazon Redshift, lihat. [Hirarki peran](t_role_hierarchy.md) ``` GRANT ROLE sales_ro TO ROLE sales_rw; ``` 1. Untuk menetapkan peran sales\$1rw ke pengguna salesengineer, gunakan contoh berikut. ``` GRANT ROLE sales_rw TO salesengineer; ``` ## Langkah 6: Kueri data sebagai pengguna dengan peran hanya-baca yang diwariskan Pada langkah ini, pengguna salesengineer mencoba memperbarui tabel peristiwa sebelum diberikan izin baca. 1. Connect ke database sebagai pengguna salesengineer. 1. Pengguna salesengineer dapat berhasil membaca data dari tabel peristiwa skema penjualan. Untuk memilih acara dengan eventid 1 dari tabel acara dalam skema penjualan, gunakan contoh berikut. ``` SELECT * FROM sales.events where eventid=1; +---------+---------+-------+--------+-----------------+---------------------+ | eventid | venueid | catid | dateid | eventname | starttime | +---------+---------+-------+--------+-----------------+---------------------+ | 1 | 305 | 8 | 1851 | Gotterdammerung | 2008-01-25 14:30:00 | +---------+---------+-------+--------+-----------------+---------------------+ ``` 1. Untuk mencoba memilih semua dari tabel acara dalam skema pemasaran, gunakan contoh berikut. Pengguna salesengineer tidak memiliki izin untuk tabel dalam skema pemasaran, jadi kueri ini akan menghasilkan kesalahan izin ditolak. Untuk memilih data dari tabel peristiwa dalam skema pemasaran, Anda harus memberikan izin SELECT peran sales\$1rw pada tabel peristiwa dalam skema pemasaran. ``` SELECT * FROM marketing.events; ERROR: permission denied for schema marketing ``` 1. Untuk mencoba memperbarui eventname untuk eventid 1, jalankan contoh berikut. Contoh ini akan menghasilkan kesalahan izin ditolak karena pengguna salesengineer hanya memiliki izin pilih pada tabel peristiwa dalam skema penjualan. Untuk memperbarui tabel peristiwa, Anda harus memberikan izin peran sales\$1rw ke UPDATE. ``` UPDATE sales.events SET eventname = 'Comment event' WHERE eventid = 1; ERROR: permission denied for relation events ``` ## Langkah 7: Berikan pembaruan dan masukkan izin ke peran baca-tulis Pada langkah ini, Anda memberikan pembaruan dan menyisipkan izin ke peran sales\$1rw. 1. Connect ke database sebagai pengguna dbadmin. 1. Untuk memberikan izin UPDATE, INSERT, dan DELETE ke peran sales\$1rw, gunakan contoh berikut. ``` GRANT UPDATE, INSERT, ON ALL TABLES IN SCHEMA sales TO role sales_rw; ``` ## Langkah 8: Kueri data sebagai pengguna baca-tulis Pada langkah ini, insinyur penjualan berhasil memperbarui tabel setelah peran mereka diberikan izin sisipan dan pembaruan. Selanjutnya, insinyur penjualan mencoba menganalisis dan menyedot tabel peristiwa tetapi gagal melakukannya. 1. Connect ke database sebagai pengguna salesengineer. 1. Untuk memperbarui eventname untuk eventid 1, jalankan contoh berikut. ``` UPDATE sales.events SET eventname = 'Comment event' WHERE eventid = 1; ``` 1. Untuk melihat perubahan yang dibuat dalam kueri sebelumnya, gunakan contoh berikut untuk memilih acara dengan eventid 1 dari tabel peristiwa dalam skema penjualan. ``` SELECT * FROM sales.events WHERE eventid=1; +---------+---------+-------+--------+---------------+---------------------+ | eventid | venueid | catid | dateid | eventname | starttime | +---------+---------+-------+--------+---------------+---------------------+ | 1 | 305 | 8 | 1851 | Comment event | 2008-01-25 14:30:00 | +---------+---------+-------+--------+---------------+---------------------+ ``` 1. Untuk menganalisis tabel peristiwa yang diperbarui dalam skema penjualan, gunakan contoh berikut. Contoh ini akan menghasilkan kesalahan izin ditolak karena pengguna salesengineer tidak memiliki izin yang diperlukan dan bukan pemilik tabel peristiwa dalam skema penjualan. Untuk menganalisis tabel peristiwa, Anda harus memberikan izin peran sales\$1rw untuk MENGANALISIS menggunakan perintah GRANT. Untuk informasi selengkapnya tentang perintah ANALYZE, lihat[MENGANALISA](r_ANALYZE.md). ``` ANALYZE sales.events; ERROR: skipping "events" --- only table or database owner can analyze ``` 1. Untuk mengosongkan tabel peristiwa yang diperbarui, gunakan contoh berikut. Contoh ini akan menghasilkan kesalahan izin ditolak karena pengguna salesengineer tidak memiliki izin yang diperlukan dan bukan pemilik tabel peristiwa dalam skema penjualan. Untuk mengosongkan tabel peristiwa, Anda harus memberikan izin peran sales\$1rw ke VACUUM menggunakan perintah GRANT. Untuk informasi lebih lanjut tentang perintah VACUUM, lihat[VAKUM](r_VACUUM_command.md). ``` VACUUM sales.events; ERROR: skipping "events" --- only table or database owner can vacuum it ``` ## Langkah 9: Analisis dan vakum tabel dalam database sebagai pengguna administrator Pada langkah ini, pengguna dbadmin menganalisis dan menyedot semua tabel. Pengguna memiliki izin administrator pada database ini, sehingga mereka dapat menjalankan perintah ini. 1. Connect ke database sebagai pengguna dbadmin. 1. Untuk menganalisis tabel peristiwa dalam skema penjualan, gunakan contoh berikut. ``` ANALYZE sales.events; ``` 1. Untuk menyedot tabel acara dalam skema penjualan, gunakan contoh berikut. ``` VACUUM sales.events; ``` 1. Untuk menganalisis tabel peristiwa dalam skema pemasaran, gunakan contoh berikut. ``` ANALYZE marketing.events; ``` 1. Untuk menyedot tabel acara dalam skema pemasaran, gunakan contoh berikut. ``` VACUUM marketing.events; ``` ## Langkah 10: Potong tabel sebagai pengguna baca-tulis Pada langkah ini, pengguna salesengineer mencoba memotong tabel peristiwa dalam skema penjualan, tetapi hanya berhasil jika diberikan izin pemotongan oleh pengguna dbadmin. 1. Connect ke database sebagai pengguna salesengineer. 1. Untuk mencoba menghapus semua baris dari tabel peristiwa dalam skema penjualan, gunakan contoh berikut. Contoh ini akan mengakibatkan kesalahan karena pengguna salesengineer tidak memiliki izin yang diperlukan dan bukan pemilik tabel peristiwa dalam skema penjualan. Untuk memotong tabel peristiwa, Anda harus memberikan izin peran sales\$1rw ke TRUNCATE menggunakan perintah GRANT. Untuk informasi selengkapnya tentang perintah TRUNCATE, lihat. [MEMOTONG](r_TRUNCATE.md) ``` TRUNCATE sales.events; ERROR: must be owner of relation events ``` 1. Connect ke database sebagai pengguna dbadmin. 1. Untuk memberikan hak istimewa tabel pemotongan ke peran sales\$1rw, gunakan contoh berikut. ``` GRANT TRUNCATE TABLE TO role sales_rw; ``` 1. Connect ke database sebagai pengguna salesengineer menggunakan query editor v2. 1. Untuk membaca 10 peristiwa pertama dari tabel acara dalam skema penjualan, gunakan contoh berikut. ``` SELECT * FROM sales.events ORDER BY eventid LIMIT 10; +---------+---------+-------+--------+-----------------------------+---------------------+ | eventid | venueid | catid | dateid | eventname | starttime | +---------+---------+-------+--------+-----------------------------+---------------------+ | 1 | 305 | 8 | 1851 | Comment event | 2008-01-25 14:30:00 | | 2 | 306 | 8 | 2114 | Boris Godunov | 2008-10-15 20:00:00 | | 3 | 302 | 8 | 1935 | Salome | 2008-04-19 14:30:00 | | 4 | 309 | 8 | 2090 | La Cenerentola (Cinderella) | 2008-09-21 14:30:00 | | 5 | 302 | 8 | 1982 | Il Trovatore | 2008-06-05 19:00:00 | | 6 | 308 | 8 | 2109 | L Elisir d Amore | 2008-10-10 19:30:00 | | 7 | 309 | 8 | 1891 | Doctor Atomic | 2008-03-06 14:00:00 | | 8 | 302 | 8 | 1832 | The Magic Flute | 2008-01-06 20:00:00 | | 9 | 308 | 8 | 2087 | The Fly | 2008-09-18 19:30:00 | | 10 | 305 | 8 | 2079 | Rigoletto | 2008-09-10 15:00:00 | +---------+---------+-------+--------+-----------------------------+---------------------+ ``` 1. Untuk memotong tabel acara dalam skema penjualan, gunakan contoh berikut. ``` TRUNCATE sales.events; ``` 1. Untuk membaca data dari tabel peristiwa yang diperbarui dalam skema penjualan, gunakan contoh berikut. ``` SELECT * FROM sales.events ORDER BY eventid LIMIT 10; +---------+---------+-------+--------+-----------------------------+---------------------+ | eventid | venueid | catid | dateid | eventname | starttime | +---------+---------+-------+--------+-----------------------------+---------------------+ ``` ### Buat peran read-only dan read-write untuk skema pemasaran (opsional) Pada langkah ini, Anda membuat peran read-only dan read-write untuk skema pemasaran. 1. Connect ke database sebagai pengguna dbadmin. 1. Untuk membuat peran read-only dan read-write untuk skema pemasaran, gunakan contoh berikut. ``` CREATE ROLE marketing_ro; CREATE ROLE marketing_rw; GRANT USAGE ON SCHEMA marketing TO ROLE marketing_ro, ROLE marketing_rw; GRANT SELECT ON ALL TABLES IN SCHEMA marketing TO ROLE marketing_ro; GRANT ROLE marketing_ro TO ROLE marketing_rw; GRANT INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA marketing TO ROLE marketing_rw; CREATE USER marketinganalyst PASSWORD 'Test12345'; CREATE USER marketingengineer PASSWORD 'Test12345'; GRANT ROLE marketing_ro TO marketinganalyst; GRANT ROLE marketing_rw TO marketingengineer; ``` ## Fungsi sistem untuk RBAC (opsional) Amazon Redshift memiliki dua fungsi untuk menyediakan informasi sistem tentang keanggotaan pengguna dan keanggotaan peran dalam grup atau peran tambahan: role\$1is\$1member\$1of dan user\$1is\$1member\$1of. Fungsi-fungsi ini tersedia untuk pengguna super dan pengguna biasa. Superusers dapat memeriksa semua keanggotaan peran. Pengguna reguler hanya dapat memeriksa keanggotaan untuk peran yang telah diberikan akses kepada mereka. Untuk menggunakan fungsi role\$1is\$1member\$1of 1. Connect ke database sebagai pengguna salesengineer. 1. Untuk memeriksa apakah peran sales\$1rw adalah anggota dari peran sales\$1ro, gunakan contoh berikut. ``` SELECT role_is_member_of('sales_rw', 'sales_ro'); +-------------------+ | role_is_member_of | +-------------------+ | true | +-------------------+ ``` 1. Untuk memeriksa apakah peran sales\$1ro adalah anggota dari peran sales\$1rw, gunakan contoh berikut. ``` SELECT role_is_member_of('sales_ro', 'sales_rw'); +-------------------+ | role_is_member_of | +-------------------+ | false | +-------------------+ ``` Untuk menggunakan fungsi user\$1is\$1member\$1of 1. Connect ke database sebagai pengguna salesengineer. 1. Contoh berikut mencoba untuk memeriksa keanggotaan pengguna untuk pengguna salesanalyst. Kueri ini menghasilkan kesalahan karena salesengineer tidak memiliki akses ke analis penjualan. Untuk menjalankan perintah ini dengan sukses, sambungkan ke database sebagai pengguna salesanalyst dan gunakan contoh. ``` SELECT user_is_member_of('salesanalyst', 'sales_ro'); ERROR ``` 1. Connect ke database sebagai superuser. 1. Untuk memeriksa keanggotaan pengguna salesanalyst saat terhubung sebagai superuser, gunakan contoh berikut. ``` SELECT user_is_member_of('salesanalyst', 'sales_ro'); +-------------------+ | user_is_member_of | +-------------------+ | true | +-------------------+ ``` 1. Connect ke database sebagai pengguna dbadmin. 1. Untuk memeriksa keanggotaan pengguna salesengineer, gunakan contoh berikut. ``` SELECT user_is_member_of('salesengineer', 'sales_ro'); +-------------------+ | user_is_member_of | +-------------------+ | true | +-------------------+ SELECT user_is_member_of('salesengineer', 'marketing_ro'); +-------------------+ | user_is_member_of | +-------------------+ | false | +-------------------+ SELECT user_is_member_of('marketinganalyst', 'sales_ro'); +-------------------+ | user_is_member_of | +-------------------+ | false | +-------------------+ ``` ## Tampilan sistem untuk RBAC (opsional) Untuk melihat peran, penetapan peran ke pengguna, hierarki peran, dan hak istimewa untuk objek database melalui peran, gunakan tampilan sistem untuk Amazon Redshift. Tampilan ini tersedia untuk pengguna super dan pengguna biasa. Pengguna super dapat memeriksa semua detail peran. Pengguna reguler hanya dapat memeriksa detail untuk peran yang telah diberikan akses kepada mereka. 1. Untuk melihat daftar pengguna yang secara eksplisit diberikan peran dalam klaster, gunakan contoh berikut. ``` SELECT * FROM svv_user_grants; ``` 1. Untuk melihat daftar peran yang secara eksplisit diberikan peran dalam klaster, gunakan contoh berikut. ``` SELECT * FROM svv_role_grants; ``` Untuk daftar lengkap tampilan sistem, lihat[Tampilan metadata SVV](svv_views.md). ## Gunakan keamanan tingkat baris dengan RBAC (opsional) Untuk memiliki kontrol akses terperinci atas data sensitif Anda, gunakan keamanan tingkat baris (RLS). Untuk informasi lebih lanjut tentang RLS, lihat[Keamanan tingkat baris](t_rls.md). Di bagian ini, Anda membuat kebijakan RLS yang memberikan izin `salesengineer` pengguna untuk hanya melihat baris dalam `cat` tabel yang memiliki `catdesc` nilai Major League Baseball. Anda kemudian menanyakan database sebagai `salesengineer` pengguna. 1. Connect ke database sebagai `salesengineer` pengguna. 1. Untuk melihat 5 entri pertama dalam `cat` tabel, gunakan contoh berikut. ``` SELECT * FROM sales.cat ORDER BY catid ASC LIMIT 5; +-------+----------+---------+---------------------------------+ | catid | catgroup | catname | catdesc | +-------+----------+---------+---------------------------------+ | 1 | Sports | MLB | Major League Baseball | | 2 | Sports | NHL | National Hockey League | | 3 | Sports | NFL | National Football League | | 4 | Sports | NBA | National Basketball Association | | 5 | Sports | MLS | Major League Soccer | +-------+----------+---------+---------------------------------+ ``` 1. Connect ke database sebagai `dbadmin` pengguna. 1. Untuk membuat kebijakan RLS untuk `catdesc` kolom dalam `cat` tabel, gunakan contoh berikut. ``` CREATE RLS POLICY policy_mlb_engineer WITH (catdesc VARCHAR(50)) USING (catdesc = 'Major League Baseball'); ``` 1. Untuk melampirkan kebijakan RLS ke `sales_rw` peran, gunakan contoh berikut. ``` ATTACH RLS POLICY policy_mlb_engineer ON sales.cat TO ROLE sales_rw; ``` 1. Untuk mengubah tabel untuk mengaktifkan RLS, gunakan contoh berikut. ``` ALTER TABLE sales.cat ROW LEVEL SECURITY ON; ``` 1. Connect ke database sebagai `salesengineer` pengguna. 1. Untuk mencoba melihat 5 entri pertama dalam `cat` tabel, gunakan contoh berikut. Perhatikan bahwa hanya entri yang hanya muncul ketika `catdesc` kolom tersebut`Major League Baseball`. ``` SELECT * FROM sales.cat ORDER BY catid ASC LIMIT 5; +-------+----------+---------+-----------------------+ | catid | catgroup | catname | catdesc | +-------+----------+---------+-----------------------+ | 1 | Sports | MLB | Major League Baseball | +-------+----------+---------+-----------------------+ ``` 1. Connect ke database sebagai `salesanalyst` pengguna. 1. Untuk mencoba melihat 5 entri pertama dalam `cat` tabel, gunakan contoh berikut. Perhatikan bahwa tidak ada entri yang muncul karena kebijakan penolakan default semua diterapkan. ``` SELECT * FROM sales.cat ORDER BY catid ASC LIMIT 5; +-------+----------+---------+-----------------------+ | catid | catgroup | catname | catdesc | +-------+----------+---------+-----------------------+ ``` 1. Connect ke database sebagai `dbadmin` pengguna. 1. Untuk memberikan izin IGNORE RLS ke `sales_ro` peran, gunakan contoh berikut. Ini memberi `salesanalyst` pengguna izin untuk mengabaikan kebijakan RLS karena mereka adalah anggota peran. `sales_ro` ``` GRANT IGNORE RLS TO ROLE sales_ro; ``` 1. Connect ke database sebagai `salesanalyst` pengguna. 1. Untuk melihat 5 entri pertama dalam `cat` tabel, gunakan contoh berikut. ``` SELECT * FROM sales.cat ORDER BY catid ASC LIMIT 5; +-------+----------+---------+---------------------------------+ | catid | catgroup | catname | catdesc | +-------+----------+---------+---------------------------------+ | 1 | Sports | MLB | Major League Baseball | | 2 | Sports | NHL | National Hockey League | | 3 | Sports | NFL | National Football League | | 4 | Sports | NBA | National Basketball Association | | 5 | Sports | MLS | Major League Soccer | +-------+----------+---------+---------------------------------+ ``` 1. Connect ke database sebagai `dbadmin` pengguna. 1. Untuk mencabut izin IGNORE RLS dari `sales_ro` peran, gunakan contoh berikut. ``` REVOKE IGNORE RLS FROM ROLE sales_ro; ``` 1. Connect ke database sebagai `salesanalyst` pengguna. 1. Untuk mencoba melihat 5 entri pertama dalam `cat` tabel, gunakan contoh berikut. Perhatikan bahwa tidak ada entri yang muncul karena kebijakan penolakan default semua diterapkan. ``` SELECT * FROM sales.cat ORDER BY catid ASC LIMIT 5; +-------+----------+---------+-----------------------+ | catid | catgroup | catname | catdesc | +-------+----------+---------+-----------------------+ ``` 1. Connect ke database sebagai `dbadmin` pengguna. 1. Untuk melepaskan kebijakan RLS dari `cat` tabel, gunakan contoh berikut. ``` DETACH RLS POLICY policy_mlb_engineer ON cat FROM ROLE sales_rw; ``` 1. Connect ke database sebagai `salesanalyst` pengguna. 1. Untuk mencoba melihat 5 entri pertama dalam `cat` tabel, gunakan contoh berikut. Perhatikan bahwa tidak ada entri yang muncul karena kebijakan penolakan default semua diterapkan. ``` SELECT * FROM sales.cat ORDER BY catid ASC LIMIT 5; +-------+----------+---------+---------------------------------+ | catid | catgroup | catname | catdesc | +-------+----------+---------+---------------------------------+ | 1 | Sports | MLB | Major League Baseball | | 2 | Sports | NHL | National Hockey League | | 3 | Sports | NFL | National Football League | | 4 | Sports | NBA | National Basketball Association | | 5 | Sports | MLS | Major League Soccer | +-------+----------+---------+---------------------------------+ ``` 1. Connect ke database sebagai `dbadmin` pengguna. 1. Untuk menghapus kebijakan RLS, gunakan contoh berikut. ``` DROP RLS POLICY policy_mlb_engineer; ``` 1. Untuk menghapus RLS, gunakan contoh berikut. ``` ALTER TABLE cat ROW LEVEL SECURITY OFF; ``` ## Topik terkait Untuk informasi selengkapnya tentang RBAC, lihat dokumentasi berikut: + [Hirarki peran](t_role_hierarchy.md) + [Penugasan peran](t_role_assignment.md) + [Izin objek database](r_roles-database-privileges.md) + [UBAH HAK ISTIMEWA DEFAULT untuk RBAC](r_roles-alter-default-privileges.md) # 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; ``` # Keamanan metadata Seperti keamanan tingkat baris Amazon Redshift, keamanan metadata memberi Anda kontrol yang lebih terperinci atas metadata Anda. Jika keamanan metadata diaktifkan untuk klaster yang disediakan atau grup kerja tanpa server, pengguna dapat melihat metadata untuk objek yang dapat diakses oleh mereka. Keamanan metadata memungkinkan Anda memisahkan visibilitas berdasarkan kebutuhan Anda. Misalnya, Anda dapat menggunakan gudang data tunggal untuk memusatkan semua penyimpanan data Anda. Namun, jika Anda menyimpan data untuk berbagai sektor, mengelola keamanan bisa menjadi merepotkan. Dengan keamanan metadata diaktifkan, Anda dapat mengonfigurasi visibilitas Anda. Pengguna dari satu sektor dapat memiliki lebih banyak visibilitas atas objek mereka, sementara Anda membatasi akses melihat ke pengguna sektor lain. Keamanan metadata mendukung semua jenis objek, seperti skema, tabel, tampilan, tampilan terwujud, prosedur tersimpan, fungsi yang ditentukan pengguna, dan model pembelajaran mesin. Pengguna dapat melihat metadata objek dalam keadaan berikut: + Jika akses objek diberikan kepada pengguna. + Jika akses objek diberikan ke grup atau peran yang menjadi bagian dari pengguna. + Objeknya publik. + Pengguna adalah pemilik objek database. Untuk mengaktifkan keamanan metadata, gunakan perintah [ALTER SYSTEM](https://docs.aws.amazon.com/redshift/latest/dg/r_ALTER_SYSTEM.html). Berikut ini adalah sintaks bagaimana menggunakan perintah ALTER SYSTEM dengan keamanan metadata. ``` ALTER SYSTEM SET metadata_security=[true|t|on|false|f|off]; ``` Saat Anda mengaktifkan keamanan metadata, semua pengguna yang memiliki izin yang diperlukan dapat melihat metadata objek yang relevan yang dapat mereka akses. Jika Anda hanya ingin pengguna tertentu yang dapat melihat keamanan metadata, berikan `ACCESS CATALOG` izin ke peran, lalu tetapkan peran tersebut kepada pengguna. Untuk informasi selengkapnya tentang penggunaan peran untuk mengontrol keamanan dengan lebih baik, lihat Kontrol [akses berbasis peran](https://docs.aws.amazon.com/redshift/latest/dg/t_Roles.html). Contoh berikut menunjukkan cara memberikan `ACCESS CATALOG` izin untuk peran, dan kemudian menetapkan peran untuk pengguna. Untuk informasi selengkapnya tentang pemberian izin, lihat perintah [GRANT](https://docs.aws.amazon.com/redshift/latest/dg/r_GRANT.html). ``` CREATE ROLE sample_metadata_viewer; GRANT ACCESS CATALOG TO ROLE sample_metadata_viewer; GRANT ROLE sample_metadata_viewer to salesadmin; ``` Jika Anda lebih suka menggunakan peran yang sudah ditentukan, peran [yang ditentukan sistem](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html)`operator`,, `secadmin``dba`, dan `superuser` semuanya memiliki izin yang diperlukan untuk melihat metadata objek. Secara default, pengguna super dapat melihat katalog lengkap. ``` GRANT ROLE operator to sample_user; ``` Jika Anda menggunakan peran untuk mengontrol keamanan metadata, Anda memiliki akses ke semua tampilan sistem dan fungsi yang disertakan dengan kontrol akses berbasis peran. Misalnya, Anda dapat menanyakan tampilan [SVV\$1ROLES untuk melihat semua peran](https://docs.aws.amazon.com/redshift/latest/dg/r_SVV_ROLES.html). Untuk melihat apakah pengguna adalah anggota peran atau grup, gunakan fungsi [USER\$1IS\$1MEMBER\$1OF](https://docs.aws.amazon.com/redshift/latest/dg/r_USER_IS_MEMBER_OF.html). Untuk daftar lengkap tampilan SVV, lihat Tampilan [metadata SVV](https://docs.aws.amazon.com/redshift/latest/dg/svv_views.html). Untuk daftar fungsi informasi sistem, lihat [Fungsi informasi sistem](https://docs.aws.amazon.com/redshift/latest/dg/r_System_information_functions.html). # Penutupan data dinamis **catatan** Amazon Redshift secara otomatis menutupi kolom tabel sistem tertentu saat mencatat informasi tentang kueri yang dibuat ke tampilan Katalog Data untuk mencegah pemaparan metadata sensitif. Untuk informasi selengkapnya, lihat [Logging aman](https://docs.aws.amazon.com/redshift/latest/mgmt/db-auditing-secure-logging.html) di *Panduan Manajemen Amazon Redshift*. 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)](t_Roles.md) Selain itu, Anda dapat menerapkan DDM pada tingkat sel dengan menggunakan kolom bersyarat saat membuat kebijakan masking Anda. Untuk informasi lebih lanjut tentang masking bersyarat, lihat. [Masking data dinamis bersyarat](t_ddm-conditional.md) 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. # Perintah SQL untuk mengelola kebijakan masking data dinamis Anda dapat melakukan tindakan berikut untuk membuat, melampirkan, melepaskan, dan menghapus kebijakan masking data dinamis: + Untuk membuat kebijakan DDM, gunakan [BUAT KEBIJAKAN MASKING](r_CREATE_MASKING_POLICY.md) perintah. Berikut ini adalah contoh pembuatan kebijakan masking menggunakan fungsi hash SHA-2. ``` CREATE MASKING POLICY hash_credit WITH (credit_card varchar(256)) USING (sha2(credit_card + 'testSalt', 256)); ``` + Untuk mengubah kebijakan DDM yang ada, gunakan perintah. [MENGUBAH KEBIJAKAN MASKING](r_ALTER_MASKING_POLICY.md) Berikut ini adalah contoh mengubah kebijakan masking yang ada. ``` ALTER MASKING POLICY hash_credit USING (sha2(credit_card + 'otherTestSalt', 256)); ``` + Untuk melampirkan kebijakan DDM pada tabel ke satu atau beberapa pengguna atau peran, gunakan [LAMPIRKAN KEBIJAKAN MASKING](r_ATTACH_MASKING_POLICY.md) perintah. Berikut ini adalah contoh melampirkan kebijakan masking ke pasangan. column/role ``` ATTACH MASKING POLICY hash_credit ON credit_cards (credit_card) TO ROLE science_role PRIORITY 30; ``` Klausa PRIORITAS menentukan kebijakan masking mana yang berlaku untuk sesi pengguna ketika beberapa kebijakan dilampirkan ke kolom yang sama. Misalnya, jika pengguna dalam contoh sebelumnya memiliki kebijakan masking lain yang dilampirkan ke kolom kartu kredit yang sama dengan prioritas 20, kebijakan science\$1role adalah kebijakan yang berlaku, karena memiliki prioritas lebih tinggi yaitu 30. + Untuk melepaskan kebijakan DDM pada tabel dari satu atau beberapa pengguna atau peran, gunakan perintah. [KEBIJAKAN PELEPASAN MASKING](r_DETACH_MASKING_POLICY.md) Berikut ini adalah contoh melepaskan kebijakan masking dari pasangan. column/role ``` DETACH MASKING POLICY hash_credit ON credit_cards(credit_card) FROM ROLE science_role; ``` + Untuk menghapus kebijakan DDM dari semua database, gunakan perintah. [KEBIJAKAN DROP MASKING](r_DROP_MASKING_POLICY.md) Berikut ini adalah contoh menjatuhkan kebijakan masking dari semua database. ``` DROP MASKING POLICY hash_credit; ``` # Hirarki kebijakan penyembunyian data dinamis Saat melampirkan beberapa kebijakan masking, pertimbangkan hal berikut: + Anda dapat melampirkan beberapa kebijakan masking ke satu kolom. + Jika beberapa kebijakan masking berlaku untuk kueri, kebijakan prioritas tertinggi yang dilampirkan pada setiap kolom masing-masing berlaku. Pertimbangkan contoh berikut. ``` ATTACH MASKING POLICY partial_hash ON credit_cards(address, credit_card) TO ROLE analytics_role PRIORITY 20; ATTACH MASKING POLICY full_hash ON credit_cards(credit_card, ssn) TO ROLE auditor_role PRIORITY 30; SELECT address, credit_card, ssn FROM credit_cards; ``` Saat menjalankan pernyataan SELECT, pengguna dengan peran analitik dan auditor akan melihat kolom alamat dengan kebijakan `partial_hash` masking yang diterapkan. Mereka melihat kolom kartu kredit dan SSN dengan kebijakan `full_hash` masking diterapkan karena `full_hash` kebijakan tersebut memiliki prioritas lebih tinggi pada kolom kartu kredit. + Jika Anda tidak menentukan prioritas saat melampirkan kebijakan masking, prioritas defaultnya adalah 0. + Anda tidak dapat melampirkan dua kebijakan ke kolom yang sama dengan prioritas yang sama. + Anda tidak dapat melampirkan dua kebijakan ke kombinasi pengguna dan kolom atau peran dan kolom yang sama. + Ketika beberapa kebijakan masking berlaku di sepanjang jalur SUPER yang sama saat dilampirkan ke pengguna atau peran yang sama, hanya lampiran prioritas tertinggi yang berlaku. Pertimbangkan contoh berikut. Contoh pertama menunjukkan dua kebijakan masking yang dilampirkan pada jalur yang sama, dengan kebijakan prioritas yang lebih tinggi mulai berlaku. ``` ATTACH MASKING POLICY hide_name ON employees(col_person.name) TO PUBLIC PRIORITY 20; ATTACH MASKING POLICY hide_last_name ON employees(col_person.name.last) TO PUBLIC PRIORITY 30; --Only the hide_last_name policy takes effect. SELECT employees.col_person.name FROM employees; ``` Contoh kedua menunjukkan dua kebijakan masking yang dilampirkan ke jalur berbeda di objek SUPER yang sama, tanpa konflik antar kebijakan. Kedua lampiran akan berlaku pada saat yang sama. ``` ATTACH MASKING POLICY hide_first_name ON employees(col_person.name.first) TO PUBLIC PRIORITY 20; ATTACH MASKING POLICY hide_last_name ON employees(col_person.name.last) TO PUBLIC PRIORITY 20; --Both col_person.name.first and col_person.name.last are masked. SELECT employees.col_person.name FROM employees; ``` Untuk mengonfirmasi kebijakan penyembunyian mana yang berlaku untuk kombinasi pengguna dan kolom atau peran dan kolom tertentu, pengguna dengan [https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html)peran tersebut dapat mencari pasangan kolom/pengguna column/role atau kolom/pengguna dalam tampilan sistem. [SVV\$1ATTACHED\$1MASKING\$1POLICY](r_SVV_ATTACHED_MASKING_POLICY.md) Untuk informasi selengkapnya, lihat [Tampilan sistem penyembunyian data dinamis](r_ddm-svv.md). # Menggunakan masking data dinamis dengan jalur tipe data SUPER Amazon Redshift mendukung melampirkan kebijakan masking data dinamis ke jalur kolom tipe SUPER. Untuk informasi selengkapnya tentang tipe data SUPER, lihat[Data semi-terstruktur di Amazon Redshift](super-overview.md). Saat melampirkan kebijakan masking ke jalur kolom tipe SUPER, pertimbangkan hal berikut. + Saat melampirkan kebijakan masking ke jalur pada kolom, kolom tersebut harus didefinisikan sebagai tipe data SUPER. Anda hanya dapat menerapkan kebijakan masking ke nilai *skalar* di jalur SUPER. Anda tidak dapat menerapkan kebijakan penyembunyian ke struktur atau array yang kompleks. + Anda dapat menerapkan kebijakan masking yang berbeda ke beberapa nilai skalar pada satu kolom SUPER, selama jalur SUPER tidak bertentangan. Misalnya, jalur SUPER `a.b` dan `a.b.c` konflik karena mereka berada di jalur yang sama, dengan `a.b` menjadi induk dari`a.b.c`. Jalur SUPER `a.b.c` dan `a.b.d` jangan konflik. + Amazon Redshift tidak dapat memeriksa apakah jalur yang dilampirkan kebijakan masking ada dalam data dan merupakan jenis yang diharapkan hingga kebijakan diterapkan pada waktu proses kueri pengguna. Misalnya, saat Anda melampirkan kebijakan masking yang menutupi nilai TEXT ke jalur SUPER yang berisi nilai INT, Amazon Redshift akan mencoba mentransmisikan tipe nilai di jalur. Dalam situasi seperti itu, perilaku Amazon Redshift saat runtime bergantung pada pengaturan konfigurasi Anda untuk menanyakan objek SUPER. Secara default, Amazon Redshift berada dalam mode longgar, dan akan menyelesaikan jalur yang hilang dan cast yang tidak valid seperti `NULL` untuk jalur SUPER yang diberikan. Untuk informasi selengkapnya tentang pengaturan konfigurasi Super-related, lihat[Konfigurasi SUPER](super-configurations.md). + SUPER adalah tipe tanpa skema, yang berarti Amazon Redshift tidak dapat mengkonfirmasi keberadaan nilai pada jalur SUPER tertentu. Jika Anda melampirkan kebijakan masking ke jalur SUPER yang tidak ada dan Amazon Redshift dalam mode longgar, Amazon Redshift akan menyelesaikan jalur ke nilai. `NULL` Kami menyarankan Anda mempertimbangkan format objek SUPER yang diharapkan dan kemungkinan objek tersebut memiliki atribut yang tidak terduga saat melampirkan kebijakan masking ke jalur kolom SUPER. Jika menurut Anda mungkin ada skema yang tidak terduga di kolom SUPER Anda, pertimbangkan untuk melampirkan kebijakan masking Anda langsung ke kolom SUPER. Anda dapat menggunakan fungsi informasi tipe SUPER untuk memeriksa atribut dan tipe, dan menggunakan `OBJECT_TRANSFORM` untuk menutupi nilai. Untuk informasi selengkapnya tentang fungsi informasi tipe SUPER, lihat[Fungsi informasi tipe SUPER](c_Type_Info_Functions.md). ## Contoh **Melampirkan kebijakan masking ke jalur SUPER** Contoh berikut melampirkan beberapa kebijakan masking ke beberapa jalur tipe SUPER dalam satu kolom. ``` CREATE TABLE employees ( col_person SUPER ); INSERT INTO employees VALUES ( json_parse(' { "name": { "first": "John", "last": "Doe" }, "age": 25, "ssn": "111-22-3333", "company": "Company Inc." } ') ), ( json_parse(' { "name": { "first": "Jane", "last": "Appleseed" }, "age": 34, "ssn": "444-55-7777", "company": "Organization Org." } ') ) ; GRANT ALL ON ALL TABLES IN SCHEMA "public" TO PUBLIC; -- Create the masking policies. -- This policy converts the given name to all uppercase letters. CREATE MASKING POLICY mask_first_name WITH(first_name TEXT) USING ( UPPER(first_name) ); -- This policy replaces the given name with the fixed string 'XXXX'. CREATE MASKING POLICY mask_last_name WITH(last_name TEXT) USING ( 'XXXX'::TEXT ); -- This policy rounds down the given age to the nearest 10. CREATE MASKING POLICY mask_age WITH(age INT) USING ( (FLOOR(age::FLOAT / 10) * 10)::INT ); -- This policy converts the first five digits of the given SSN to 'XXX-XX'. CREATE MASKING POLICY mask_ssn WITH(ssn TEXT) USING ( 'XXX-XX-'::TEXT || SUBSTRING(ssn::TEXT FROM 8 FOR 4) ); -- Attach the masking policies to the employees table. ATTACH MASKING POLICY mask_first_name ON employees(col_person.name.first) TO PUBLIC; ATTACH MASKING POLICY mask_last_name ON employees(col_person.name.last) TO PUBLIC; ATTACH MASKING POLICY mask_age ON employees(col_person.age) TO PUBLIC; ATTACH MASKING POLICY mask_ssn ON employees(col_person.ssn) TO PUBLIC; -- Verify that your masking policies are attached. SELECT policy_name, TABLE_NAME, priority, input_columns, output_columns FROM svv_attached_masking_policy; policy_name | table_name | priority | input_columns | output_columns -----------------+------------+----------+-----------------------------------+----------------------------------- mask_age | employees | 0 | ["col_person.\"age\""] | ["col_person.\"age\""] mask_first_name | employees | 0 | ["col_person.\"name\".\"first\""] | ["col_person.\"name\".\"first\""] mask_last_name | employees | 0 | ["col_person.\"name\".\"last\""] | ["col_person.\"name\".\"last\""] mask_ssn | employees | 0 | ["col_person.\"ssn\""] | ["col_person.\"ssn\""] (4 rows) -- Observe the masking policies taking effect. SELECT col_person FROM employees ORDER BY col_person.age; -- This result is formatted for ease of reading. col_person -------------------------------- { "name": { "first": "JOHN", "last": "XXXX" }, "age": 20, "ssn": "XXX-XX-3333", "company": "Company Inc." } { "name": { "first": "JANE", "last": "XXXX" }, "age": 30, "ssn": "XXX-XX-7777", "company": "Organization Org." } ``` Berikut ini adalah beberapa contoh lampiran kebijakan masking yang tidak valid ke jalur SUPER. ``` -- This attachment fails because there is already a policy -- with equal priority attached to employees.name.last, which is -- on the same SUPER path as employees.name. ATTACH MASKING POLICY mask_ssn ON employees(col_person.name) TO PUBLIC; ERROR: DDM policy "mask_last_name" is already attached on relation "employees" column "col_person."name"."last"" with same priority -- Create a masking policy that masks DATETIME objects. CREATE MASKING POLICY mask_date WITH(INPUT DATETIME) USING ( INPUT ); -- This attachment fails because SUPER type columns can't contain DATETIME objects. ATTACH MASKING POLICY mask_date ON employees(col_person.company) TO PUBLIC; ERROR: cannot attach masking policy for output of type "timestamp without time zone" to column "col_person."company"" of type "super ``` Berikut ini adalah contoh melampirkan kebijakan masking ke jalur SUPER yang tidak ada. Secara default, Amazon Redshift akan menyelesaikan jalur ke. `NULL` ``` ATTACH MASKING POLICY mask_first_name ON employees(col_person.not_exists) TO PUBLIC; SELECT col_person FROM employees LIMIT 1; -- This result is formatted for ease of reading. col_person ----------------------------------- { "name": { "first": "JOHN", "last": "XXXX" }, "age": 20, "ssn": "XXX-XX-3333", "company": "Company Inc.", "not_exists": null } ``` # Masking data dinamis bersyarat Anda dapat menutupi data di tingkat sel dengan membuat kebijakan masking dengan ekspresi kondisional dalam ekspresi masking. Misalnya, Anda dapat membuat kebijakan masking yang menerapkan masker berbeda ke nilai, bergantung pada nilai kolom lain di baris tersebut. Berikut ini adalah contoh penggunaan masking data bersyarat untuk membuat dan melampirkan kebijakan masking yang sebagian menyunting nomor kartu kredit yang terlibat dalam penipuan, sementara sepenuhnya menyembunyikan semua nomor kartu kredit lainnya. Anda harus menjadi superuser atau memiliki [https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html)peran untuk menjalankan contoh ini. ``` --Create an analyst role. CREATE ROLE analyst; --Create a credit card table. The table contains an is_fraud boolean column, --which is TRUE if the credit card number in that row was involved in a fraudulent transaction. CREATE TABLE credit_cards (id INT, is_fraud BOOLEAN, credit_card_number VARCHAR(16)); --Create a function that partially redacts credit card numbers. CREATE FUNCTION REDACT_CREDIT_CARD (credit_card VARCHAR(16)) RETURNS VARCHAR(16) 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 partially redacts credit card numbers if the is_fraud value for that row is TRUE, --and otherwise blanks out the credit card number completely. CREATE MASKING POLICY card_number_conditional_mask WITH (fraudulent BOOLEAN, pan varchar(16)) USING (CASE WHEN fraudulent THEN REDACT_CREDIT_CARD(pan) ELSE Null END); --Attach the masking policy to the credit_cards/analyst table/role pair. ATTACH MASKING POLICY card_number_conditional_mask ON credit_cards (credit_card_number) USING (is_fraud, credit_card_number) TO ROLE analyst PRIORITY 100; ``` # Tampilan sistem penyembunyian data dinamis Pengguna super, pengguna dengan `sys:operator` peran, dan pengguna dengan izin ACCESS SYSTEM TABLE dapat mengakses tampilan sistem terkait DDM berikut. + [SVV\$1MASKING\$1POLICY](r_SVV_MASKING_POLICY.md) Gunakan SVV\$1MASKING\$1POLICY untuk melihat semua kebijakan masking yang dibuat pada cluster atau workgroup. + [SVV\$1ATTACHED\$1MASKING\$1POLICY](r_SVV_ATTACHED_MASKING_POLICY.md) Gunakan SVV\$1ATTACHED\$1MASKING\$1POLICY untuk melihat semua relasi dan pengguna atau peran dengan kebijakan yang dilampirkan pada database yang saat ini terhubung. + [SYS\$1APPLIED\$1MASKING\$1POLICY\$1LOG](SYS_APPLIED_MASKING_POLICY_LOG.md) Gunakan SYS\$1APPLIED\$1MASKING\$1POLICY\$1LOG untuk melacak penerapan kebijakan masking pada kueri yang mereferensikan hubungan yang dilindungi DDM. Berikut adalah beberapa contoh informasi yang dapat Anda temukan menggunakan tampilan sistem. ``` --Select all policies associated with specific users, as opposed to roles SELECT policy_name, schema_name, table_name, grantee FROM svv_attached_masking_policy WHERE grantee_type = 'user'; --Select all policies attached to a specific user SELECT policy_name, schema_name, table_name, grantee FROM svv_attached_masking_policy WHERE grantee = 'target_grantee_name' --Select all policies attached to a given table SELECT policy_name, schema_name, table_name, grantee FROM svv_attached_masking_policy WHERE table_name = 'target_table_name' AND schema_name = 'target_schema_name'; --Select the highest priority policy attachment for a given role SELECT samp.policy_name, samp.priority, samp.grantee, smp.policy_expression FROM svv_masking_policy AS smp JOIN svv_attached_masking_policy AS samp ON samp.policy_name = smp.policy_name WHERE samp.grantee_type = 'role' AND samp.policy_name = mask_get_policy_for_role_on_column( 'target_schema_name', 'target_table_name', 'target_column_name', 'target_role_name') ORDER BY samp.priority desc LIMIT 1; --See which policy a specific user will see on a specific column in a given relation SELECT samp.policy_name, samp.priority, samp.grantee, smp.policy_expression FROM svv_masking_policy AS smp JOIN svv_attached_masking_policy AS samp ON samp.policy_name = smp.policy_name WHERE samp.grantee_type = 'role' AND samp.policy_name = mask_get_policy_for_user_on_column( 'target_schema_name', 'target_table_name', 'target_column_name', 'target_user_name') ORDER BY samp.priority desc; --Select all policies attached to a given relation. SELECT policy_name, schema_name, relation_name, database_name FROM sys_applied_masking_policy_log WHERE relation_name = 'relation_name' AND schema_name = 'schema_name'; ``` # 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\$1EXPLAIN\$1DDM yang dapat melihat kebijakan penyembunyian yang diterapkan dalam output EXPLOW. Pengguna tidak memiliki izin SYS\$1EXPLAIN\$1DDM secara default. Berikut ini adalah sintaks untuk memberikan izin untuk peran. ``` GRANT EXPLAIN MASKING TO ROLE rolename ``` Untuk informasi selengkapnya tentang perintah EXPLORE, lihat[EXPLAIN](r_EXPLAIN.md). + 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, lihat[Keamanan tingkat baris](t_rls.md). + Saat menggunakan [MENYONTEK](r_COPY.md) 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, lihat[Opsi pemetaan kolom](copy-parameters-column-mapping.md). + Kebijakan DDM tidak dapat dilampirkan pada relasi berikut: + Tabel dan katalog sistem + Tabel eksternal + Tabel Datasharing + 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. + Anda tidak dapat menggunakan kebijakan DDM 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. Mencoba menambahkan relasi ke datashare gagal pada cluster sisi produsen atau namespace dengan kesalahan berikut: ``` or a relation dependent on it is protected by a masking policy and cannot be added to a datashare ``` Jika Anda melampirkan kebijakan masking ke relasi di sisi produsen dan relasi tersebut sudah termasuk dalam datashare, upaya untuk menanyakan relasi di sisi konsumen gagal dengan kesalahan berikut: ``` cross-cluster query of the masked relation is not supported. ``` Anda dapat mematikan DDM untuk datashares menggunakan perintah ALTER TABLE dengan parameter MASKING OFF FOR DATASHARES. Untuk informasi selengkapnya, lihat [ALTER TABLE](r_ALTER_TABLE.md). + 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 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](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 DDM terlampir tidak dapat diganti oleh pengguna biasa yang menggunakan perintah. [CREATE VIEW](r_CREATE_VIEW.md) Untuk mengganti tampilan atau LBVs dengan kebijakan DDM, pertama-tama lepaskan kebijakan DDM yang melekat padanya, ganti tampilan atau LBVs, dan pasang kembali kebijakan tersebut. Pengguna super dan pengguna dengan `sys:secadmin` izin dapat menggunakan CREATE VIEW pada tampilan atau LBVs 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. + Anda dapat menggunakan variabel konteks sesi yang disesuaikan saat membuat kebijakan DDM. Contoh berikut menetapkan variabel konteks sesi untuk kebijakan DDM. ``` -- Set a customized context variable. SELECT set_config('app.city', 'XXXX', FALSE); -- Create a MASKING policy using current_setting() to get the value of a customized context variable. CREATE MASKING POLICY city_mask WITH (city VARCHAR(30)) USING (current_setting('app.city')::VARCHAR(30)); -- Attach the policy on the target table to one or more roles. ATTACH MASKING POLICY city_mask ON tickit_users_redshift(city) 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 DDM, kebijakan keamanan bergantung pada pengguna atau peran yang memanggil kebijakan. Berhati-hatilah untuk menghindari kerentanan keamanan saat menggunakan variabel konteks sesi dalam kebijakan DDM. # Contoh masking end-to-end data dinamis 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 [https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html)peran 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; ``` # Izin tercakup Izin tercakup memungkinkan Anda memberikan izin kepada pengguna atau peran pada semua objek dari tipe dalam database atau skema. Pengguna dan peran dengan izin cakupan memiliki izin yang ditentukan pada semua objek saat ini dan masa depan dalam database atau skema. Anda dapat melihat cakupan izin cakupan tingkat database di. [SVV\$1DATABASE\$1PRIVILEGES](r_SVV_DATABASE_PRIVILEGES.md) Anda dapat melihat cakupan izin cakupan tingkat skema di. [SVV\$1SCHEMA\$1PRIVILEGES](r_SVV_SCHEMA_PRIVILEGES.md) Untuk informasi selengkapnya tentang penerapan izin cakupan, lihat dan. [HIBAH](r_GRANT.md) [MENCABUT](r_REVOKE.md) # Pertimbangan untuk menggunakan izin cakupan Saat menggunakan izin cakupan, pertimbangkan hal berikut: + Anda dapat menggunakan izin cakupan untuk memberikan atau mencabut izin pada database atau cakupan skema ke atau dari pengguna atau peran tertentu. + Anda tidak dapat memberikan izin tercakup ke grup pengguna. + Pemberian atau pencabutan izin cakupan mengubah izin untuk semua objek saat ini dan masa depan dalam lingkup. + Izin cakupan dan izin tingkat objek beroperasi secara independen satu sama lain. Misalnya, pengguna akan mempertahankan izin pada tabel dalam kedua kasus berikut. + Pengguna diberikan SELECT pada tabel schema1.table1 dan SELECT izin cakupan pada schema1. Pengguna kemudian telah SELECT dicabut untuk semua tabel dalam skema schema1. Pengguna mempertahankan SELECT pada schema1.table1. + Pengguna diberikan SELECT pada tabel schema1.table1 dan SELECT izin cakupan pada schema1. Pengguna kemudian telah SELECT dicabut untuk schema1.table1. Pengguna mempertahankan SELECT pada schema1.table1. + Untuk memberikan atau mencabut izin cakupan, Anda harus memenuhi salah satu kriteria berikut: + Pengguna super. + Pengguna dengan opsi hibah untuk izin itu. Untuk informasi lebih lanjut tentang opsi hibah, buka parameter WITH GRANT OPTION di[HIBAH](r_GRANT.md). + Izin cakupan hanya dapat diberikan atau dicabut dari objek untuk database yang terhubung, atau dari database yang diimpor dari datashare. + Anda dapat menggunakan izin cakupan untuk mengatur izin default pada database yang dibuat dari datashare. Pengguna datashare sisi konsumen yang diberikan izin cakupan pada database bersama akan secara otomatis mendapatkan izin tersebut untuk setiap objek baru yang ditambahkan ke datashare di sisi produsen. + Produsen dapat memberikan izin cakupan pada objek dalam skema ke datashare. (pratinjau)