Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Keamanan dengan Amazon Aurora PostgreSQL
Untuk gambaran umum tentang keamanan Aurora, lihat. [Keamanan di ](UsingWithRDS.md) Anda dapat mengelola keamanan untuk Amazon Aurora PostgreSQL pada beberapa level yang berbeda:
+ Untuk mengontrol siapa yang dapat melakukan tindakan pengelolaan Amazon RDS pada cluster DB PostgreSQL Aurora dan instans DB PostgreSQL, gunakan (IAM). AWS Identity and Access Management IAM menangani autentikasi identitas pengguna sebelum pengguna dapat mengakses layanan. IAM juga menangani otorisasi, yaitu, apakah pengguna diizinkan untuk melakukan apa yang mereka coba lakukan. Autentikasi basis data IAM adalah metode autentikasi tambahan yang dapat dipilih saat Anda membuat klaster DB Aurora PostgreSQL. Untuk informasi selengkapnya, lihat [Manajemen identitas dan akses untuk Amazon Aurora](UsingWithRDS.IAM.md).
Jika Anda menggunakan IAM dengan cluster Aurora PostgreSQL DB Anda, masuk Konsol Manajemen AWS ke dengan kredenal IAM Anda terlebih dahulu, sebelum membuka konsol Amazon RDS di. [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)
+ Pastikan untuk membuat klaster DB Aurora di cloud privat virtual (VPC) berdasarkan layanan Amazon VPC. Untuk mengendalikan perangkat dan instans Amazon EC2 mana yang dapat membuka koneksi ke titik akhir dan port instans DB untuk klaster Aurora DB di VPC, gunakan grup keamanan VPC. Anda dapat membuat titik akhir dan koneksi port ini menggunakan Lapisan Soket Aman (SSL). Selain itu, aturan firewall di perusahaan Anda dapat mengendalikan perangkat yang berjalan di perusahaan Anda untuk dapat membuka koneksi ke instans DB. Untuk informasi lebih lanjut tentang VPCs, lihat[Amazon VPC dan Aurora](USER_VPC.md).
Penghunian VPC yang didukung tergantung pada kelas instans DB yang digunakan oleh klaster DB Aurora PostgreSQL Anda. Dengan penghunian VPC `default`, klaster DB berjalan di perangkat keras bersama. Dengan penghunian VPC `dedicated`, klaster DB berjalan di instans perangkat keras khusus. Kelas instans DB performa yang dapat melonjak hanya mendukung penghunian VPC default. Kelas instans DB performa yang dapat melonjak mencakup kelas instans DB db.t3 dan db.t4g. Semua kelas instans DB Aurora PostgreSQL lainnya mendukung penghunian VPC default dan khusus.
Untuk informasi selengkapnya tentang kelas instans, lihat [Kelas instans Amazon Aurora DB](Concepts.DBInstanceClass.md). Untuk informasi selengkapnya tentang penghunian VPC `default` dan `dedicated`, lihat [Instans khusus](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-instance.html) dalam *Panduan Pengguna Amazon Elastic Compute Cloud*.
+ Guna memberikan izin ke basis data PostgreSQL yang berjalan di klaster DB Amazon Aurora, Anda dapat menggunakan pendekatan umum yang sama seperti instans PostgreSQL yang berdiri sendiri. Perintah seperti `CREATE ROLE`, `ALTER ROLE`, `GRANT`, dan `REVOKE` bekerja sama seperti dalam basis data on-premise, seperti mengubah langsung basis data, skema, dan tabel.
PostgreSQL mengelola hak istimewa dengan menggunakan *peran*. Peran `rds_superuser` adalah peran yang paling istimewa di klaster DB Aurora PostgreSQL. Peran ini dibuat secara otomatis, dan diberikan kepada pengguna yang membuat klaster DB (akun pengguna master, `postgres` secara default). Untuk mempelajari selengkapnya, lihat [Memahami peran dan izin PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Roles.md).
Semua versi Aurora PostgreSQL yang tersedia, termasuk versi 10, 11, 12, 13, 14, dan rilis yang lebih tinggi mendukung Salted Challenge Response Authentication Mechanism (SCRAM) untuk kata sandi sebagai alternatif untuk message digest (). MD5 Kami menyarankan Anda menggunakan SCRAM karena lebih aman daripada MD5. Untuk informasi selengkapnya, termasuk cara memigrasikan kata sandi pengguna database dari SCRAM MD5 ke SCRAM, lihat. [Menggunakan SCRAM untuk enkripsi kata sandi PostgreSQL](PostgreSQL_Password_Encryption_configuration.md)
# Memahami peran dan izin PostgreSQL
Bila Anda membuat Aurora PostgreSQL DB cluster DB menggunakan, akun administrator dibuat pada saat yang sama. Konsol Manajemen AWS Secara default, akun tersebut akan dinamakan `postgres`, seperti yang ditunjukkan pada gambar berikut:
![\[Identitas login default untuk Kredensial di halaman Buat basis data adalah postgres.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/default-login-identity-apg-rpg.png)
Anda dapat memilih nama lain daripada menerima nama default (`postgres`). Jika ya, nama yang Anda pilih harus dimulai dengan huruf dan terdiri atas 1 hingga 16 karakter alfanumerik. Untuk menyederhanakan, kami merujuk ke akun pengguna utama ini dengan nilai default-nya (`postgres`) di seluruh panduan ini.
Jika Anda menggunakan `create-db-cluster` AWS CLI bukan Konsol Manajemen AWS, Anda membuat nama pengguna dengan meneruskannya dengan `master-username` parameter. Untuk informasi selengkapnya, lihat [Langkah 2: Membuat klaster DB Aurora PostgreSQL](CHAP_GettingStartedAurora.AuroraPostgreSQL.FullConfig.md#CHAP_GettingStarted.AuroraPostgreSQL.CreateDBCluster).
Baik Anda menggunakan Konsol Manajemen AWS, API AWS CLI, atau Amazon RDS, dan apakah Anda menggunakan `postgres` nama default atau memilih nama yang berbeda, akun pengguna database pertama ini adalah anggota `rds_superuser` grup dan memiliki `rds_superuser` hak istimewa.
**Topics**
+ [Memahami peran rds\$1superuser](Appendix.PostgreSQL.CommonDBATasks.Roles.rds_superuser.md)
+ [Mengontrol akses pengguna ke basis data PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Access.md)
+ [Menyerahkan dan mengendalikan manajemen kata sandi pengguna](Appendix.PostgreSQL.CommonDBATasks.RestrictPasswordMgmt.md)
+ [Menggunakan SCRAM untuk enkripsi kata sandi PostgreSQL](PostgreSQL_Password_Encryption_configuration.md)
# Memahami peran rds\$1superuser
Dalam PostgreSQL, *peran* dapat menentukan pengguna, grup, atau sekumpulan izin tertentu yang diberikan kepada grup atau pengguna untuk berbagai objek dalam basis data. Perintah PostgreSQL untuk `CREATE USER` dan `CREATE GROUP` telah digantikan oleh `CREATE ROLE` yang lebih umum dengan properti khusus untuk membedakan pengguna basis data. Pengguna basis data dapat dianggap sebagai peran dengan hak akses LOGIN.
**catatan**
Perintah `CREATE USER` dan `CREATE GROUP` masih dapat digunakan. Untuk informasi selengkapnya, lihat [Database Roles](https://www.postgresql.org/docs/current/user-manag.html) dalam dokumentasi PostgreSQL.
Pengguna `postgres` adalah pengguna basis data dengan hak akses tertinggi di klaster DB Aurora PostgreSQL . Pengguna tersebut memiliki karakteristik yang ditentukan oleh pernyataan `CREATE ROLE` berikut.
```
CREATE ROLE postgres WITH LOGIN NOSUPERUSER INHERIT CREATEDB CREATEROLE NOREPLICATION VALID UNTIL 'infinity'
```
Properti`NOSUPERUSER`, `NOREPLICATION`, `INHERIT`, dan `VALID UNTIL 'infinity'` merupakan opsi default untuk CREATE ROLE, kecuali ditentukan lain.
Secara default, `postgres` memiliki hak akses yang diberikan kepada peran `rds_superuser`, serta izin untuk membuat peran dan basis data. Peran `rds_superuser` mengizinkan pengguna `postgres` untuk melakukan tindakan berikut:
+ Menambahkan ekstensi yang tersedia untuk digunakan dengan Aurora PostgreSQL. Untuk informasi selengkapnya, lihat [Menangani ekstensi dan pembungkus data asing](Appendix.PostgreSQL.CommonDBATasks.md).
+ Buat peran dan berikan hak akses kepada pengguna. Untuk informasi selengkapnya, lihat [CREATE ROLE](https://www.postgresql.org/docs/current/sql-createrole.html) dan [GRANT](https://www.postgresql.org/docs/14/sql-grant.html) dalam dokumentasi PostgreSQL.
+ Membuat basis data. Untuk informasi selengkapnya, lihat [CREATE DATABASE](https://www.postgresql.org/docs/14/sql-createdatabase.html) dalam dokumentasi PostgreSQL.
+ Berikan hak akses `rds_superuser` untuk peran pengguna yang tidak memiliki hak akses ini, dan cabut hak akses sesuai kebutuhan. Sebaiknya berikan peran ini hanya untuk pengguna yang menjalankan tugas superuser. Dengan kata lain, Anda dapat memberikan peran ini kepada administrator database (DBAs) atau administrator sistem.
+ Berikan (dan cabut) peran `rds_replication` kepada pengguna basis data yang tidak memiliki peran `rds_superuser`.
+ Berikan (dan cabut) peran `rds_password` kepada pengguna basis data yang tidak memiliki peran `rds_superuser`.
+ Dapatkan informasi status tentang semua koneksi basis data dengan menggunakan tampilan `pg_stat_activity`. Bila diperlukan, `rds_superuser` dapat menghentikan semua koneksi menggunakan `pg_terminate_backend` atau `pg_cancel_backend`.
Dalam pernyataan `CREATE ROLE postgres...`, Anda dapat melihat bahwa peran pengguna `postgres` secara khusus melarang izin `superuser` PostgreSQL. Aurora PostgreSQL adalah layanan terkelola, jadi Anda tidak dapat mengakses OS host, dan terhubung menggunakan akun `superuser` PostgreSQL. Banyak tugas yang memerlukan akses `superuser` pada PostgreSQL mandiri dikelola secara otomatis oleh Aurora.
Untuk informasi selengkapnya tentang pemberian hak akses, lihat [GRANT](http://www.postgresql.org/docs/current/sql-grant.html) dalam dokumentasi PostgreSQL.
Peran `rds_superuser` adalah satu dari beberapa peran yang *telah ditentukan* dalam klaster DB Aurora PostgreSQL.
**catatan**
Dalam PostgreSQL 13 dan rilis sebelumnya, peran yang *telah ditentukan* dikenal sebagai peran *default*.
Dalam daftar berikut, Anda akan menemukan beberapa peran standar lainnya yang dibuat secara otomatis untuk klaster DB Aurora PostgreSQL yang baru. Peran yang telah ditentukan dan hak aksesnya tidak dapat diubah. Anda tidak dapat menghapus, mengganti nama, atau memodifikasi hak akses untuk peran yang telah ditentukan ini. Mencoba untuk melakukannya akan mengakibatkan kesalahan.
+ **rds\$1password** — Peran yang dapat mengubah kata sandi dan mengatur batasan kata sandi untuk pengguna basis data. `rds_superuser`Peran diberikan dengan peran ini secara default, dan dapat memberikan peran tersebut kepada pengguna database. Untuk informasi selengkapnya, lihat [Mengontrol akses pengguna ke basis data PostgreSQLMengontrol akses pengguna ke PostgreSQL](Appendix.PostgreSQL.CommonDBATasks.Access.md).
+ Untuk RDS untuk PostgreSQL versi yang lebih tua dari 14`rds_password`, peran dapat mengubah kata sandi dan mengatur batasan kata sandi untuk pengguna database dan pengguna dengan peran. `rds_superuser` Dari RDS untuk PostgreSQL versi 14 dan yang lebih baru`rds_password`, peran dapat mengubah kata sandi dan mengatur batasan kata sandi hanya untuk pengguna database. Hanya pengguna dengan `rds_superuser` peran yang dapat melakukan tindakan ini pada pengguna lain yang memiliki `rds_superuser` peran.
+ **rdsadmin** — Peran yang dibuat untuk menangani banyak tugas manajemen yang dilakukan oleh administrator dengan hak akses `superuser` pada basis data PostgreSQL mandiri. Peran ini digunakan secara internal oleh Aurora PostgreSQL untuk banyak tugas manajemen.
# Melihat peran dan hak istimewa mereka
Anda dapat melihat peran yang telah ditentukan dan hak istimewanya di RDS untuk instans PostgreSQL DB menggunakan perintah yang berbeda tergantung pada versi PostgreSQL Anda. Untuk melihat semua peran yang telah ditentukan, Anda dapat terhubung ke RDS untuk instans PostgreSQL DB dan menjalankan perintah berikut menggunakan. `psql`
**Untuk `psql` 15 dan versi sebelumnya**
Connect ke RDS Anda untuk PostgreSQL DB instance dan gunakan perintah di psql: `\du`
```
postgres=> \du
List of roles
Role name | Attributes | Member of
-----------------+------------------------------------------------------------+------------------------------------------------------
postgres | Create role, Create DB +| {rds_superuser}
| Password valid until infinity |
rds_ad | Cannot login | {}
rds_iam | Cannot login | {}
rds_password | Cannot login | {}
rds_replication | Cannot login | {}
rds_superuser | Cannot login | {pg_monitor,pg_signal_backend,rds_password,rds_replication}
rdsadmin | Superuser, Create role, Create DB, Replication, Bypass RLS+| {}
| Password valid until infinity |
```
**Untuk `psql` 16 dan versi yang lebih baru**
```
postgres=> \drg+
List of role grants
Role name | Member of | Options | Grantor
---------------+-----------------------------+---------------------+----------
postgres | rds_superuser | INHERIT, SET | rdsadmin
rds_superuser | pg_checkpoint | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_monitor | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_signal_backend | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | pg_use_reserved_connections | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_password | ADMIN, INHERIT, SET | rdsadmin
rds_superuser | rds_replication | ADMIN, INHERIT, SET | rdsadmin
```
Untuk memeriksa keanggotaan peran tanpa ketergantungan versi, Anda dapat menggunakan kueri SQL berikut:
```
SELECT m.rolname AS "Role name", r.rolname AS "Member of"
FROM pg_catalog.pg_roles m
JOIN pg_catalog.pg_auth_members pam ON (pam.member = m.oid)
LEFT JOIN pg_catalog.pg_roles r ON (pam.roleid = r.oid)
LEFT JOIN pg_catalog.pg_roles g ON (pam.grantor = g.oid)
WHERE m.rolname !~ '^pg_'
ORDER BY 1, 2;
```
Dalam output, Anda dapat melihat bahwa `rds_superuser` itu bukan peran pengguna basis data (tidak dapat masuk), tetapi memiliki hak akses dari banyak peran lainnya. Anda juga dapat melihat bahwa pengguna basis data `postgres` adalah anggota peran `rds_superuser`. Seperti disebutkan sebelumnya, `postgres` adalah nilai default di halaman **Buat basis data** konsol Amazon RDS. Jika Anda memilih nama lain, nama itu akan ditampilkan dalam daftar peran.
**catatan**
Aurora PostgreSQL versi 15.2 dan 14.7 memperkenalkan perilaku restriktif peran `rds_superuser`. Pengguna Aurora PostgreSQL harus diberi hak akses `CONNECT` pada basis data terkait agar dapat menghubungkan, meskipun pengguna tersebut diberi peran `rds_superuser`. Sebelum Aurora PostgreSQL versi 14.7 dan 15.2, pengguna dapat terhubung dengan basis data dan tabel sistem mana pun jika diberi peran `rds_superuser`. Perilaku restriktif ini sejalan dengan komitmen Amazon Aurora AWS dan Amazon Aurora untuk peningkatan keamanan yang berkelanjutan.
Perbarui logika masing-masing dalam aplikasi Anda jika peningkatan di atas berdampak.
# Mengontrol akses pengguna ke basis data PostgreSQL
Basis data baru di PostgreSQL selalu dibuat dengan serangkaian hak akses default dalam skema `public` basis data yang memungkinkan semua pengguna dan peran basis data untuk membuat objek. Hak akses ini memungkinkan pengguna basis data untuk terhubung ke basis data, misalnya, dan membuat tabel sementara saat terhubung.
Agar dapat mengontrol dengan lebih baik akses pengguna ke instans basis data yang Anda buat di simpul primer klaster DB Aurora PostgreSQL , sebaiknya Anda mencabut hak akses `public` default. Setelah melakukannya, Anda kemudian memberikan hak akses khusus untuk pengguna basis data secara lebih rinci, seperti yang diperlihatkan dalam prosedur berikut ini.
**Untuk menyiapkan peran dan hak akses untuk instans basis data baru**
Misalnya, Anda sedang menyiapkan basis data pada klaster DB Aurora PostgreSQL yang baru dibuat untuk digunakan oleh beberapa peneliti, yang semuanya membutuhkan akses baca-tulis ke basis data.
1. Gunakan `psql` (atau pgAdmin) untuk menghubungkan ke instans DB primer di klaster DB Aurora PostgreSQL:
```
psql --host=your-cluster-instance-1.666666666666.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
Saat diminta, masukkan kata sandi Anda. Klien `psql` menghubungkan dan menampilkan basis data koneksi administratif default, `postgres=>`, sebagai perintah.
1. Untuk mencegah pengguna basis data membuat objek dalam skema `public`, lakukan tindakan berikut:
```
postgres=> REVOKE CREATE ON SCHEMA public FROM PUBLIC;
REVOKE
```
1. Selanjutnya, buat instans basis data baru:
```
postgres=> CREATE DATABASE lab_db;
CREATE DATABASE
```
1. Cabut semua hak akses dari skema `PUBLIC` pada basis data baru ini.
```
postgres=> REVOKE ALL ON DATABASE lab_db FROM public;
REVOKE
```
1. Buat peran untuk pengguna basis data.
```
postgres=> CREATE ROLE lab_tech;
CREATE ROLE
```
1. Berikan pengguna basis data yang memiliki peran ini kemampuan untuk terhubung ke basis data.
```
postgres=> GRANT CONNECT ON DATABASE lab_db TO lab_tech;
GRANT
```
1. Berikan semua hak akses pada basis data ini kepada semua pengguna dengan peran `lab_tech`.
```
postgres=> GRANT ALL PRIVILEGES ON DATABASE lab_db TO lab_tech;
GRANT
```
1. Buat pengguna basis data, sebagai berikut:
```
postgres=> CREATE ROLE lab_user1 LOGIN PASSWORD 'change_me';
CREATE ROLE
postgres=> CREATE ROLE lab_user2 LOGIN PASSWORD 'change_me';
CREATE ROLE
```
1. Beri hak akses terkait peran lab\$1tech kepada dua pengguna ini:
```
postgres=> GRANT lab_tech TO lab_user1;
GRANT ROLE
postgres=> GRANT lab_tech TO lab_user2;
GRANT ROLE
```
Pada titik ini, `lab_user1` dan `lab_user2` dapat terhubung ke basis data `lab_db`. Contoh ini tidak mengikuti praktik terbaik untuk penggunaan perusahaan, yang mungkin termasuk membuat beberapa instans basis data, skema yang berbeda, dan pemberian izin terbatas. Untuk informasi yang lebih lengkap dan skenario tambahan lainnya, lihat [Mengelola Pengguna dan Peran PostgreSQL](https://aws.amazon.com/blogs//database/managing-postgresql-users-and-roles/).
Untuk informasi selengkapnya tentang hak akses di PostgreSQL, lihat perintah [GRANT](https://www.postgresql.org/docs/current/static/sql-grant.html) dalam dokumentasi PostgreSQL.
# Menyerahkan dan mengendalikan manajemen kata sandi pengguna
Sebagai DBA, Anda mungkin perlu menyerahkan manajemen kata sandi pengguna. Atau, Anda juga dapat mencegah pengguna basis data mengubah kata sandi mereka atau mengonfigurasi ulang batasan kata sandi, seperti masa pakai kata sandi. Untuk memastikan bahwa hanya pengguna basis data yang Anda pilih yang dapat mengubah pengaturan kata sandi, Anda dapat mengaktifkan fitur manajemen kata sandi terbatas. Bila mengaktifkan fitur ini, hanya pengguna basis data yang telah diberikan peran `rds_password` yang dapat mengelola kata sandi.
**catatan**
Untuk menggunakan manajemen kata sandi terbatas, klaster DB Aurora PostgreSQL harus menjalankan Amazon Aurora PostgreSQL 10.6 atau versi lebih tinggi.
Secara default, fitur ini dalam keadaan `off`, seperti yang ditunjukkan berikut:
```
postgres=> SHOW rds.restrict_password_commands;
rds.restrict_password_commands
--------------------------------
off
(1 row)
```
Untuk mengaktifkan fitur ini, Anda harus menggunakan grup parameter kustom dan mengubah pengaturan `rds.restrict_password_commands` ke 1. Pastikan untuk melakukan booting ulang instans DB primer Aurora PostgreSQL agar pengaturan dapat berlaku.
Dalam keadaan fitur ini aktif, hak akses `rds_password` diperlukan untuk perintah SQL berikut:
```
CREATE ROLE myrole WITH PASSWORD 'mypassword';
CREATE ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword' VALID UNTIL '2023-01-01';
ALTER ROLE myrole WITH PASSWORD 'mypassword';
ALTER ROLE myrole VALID UNTIL '2023-01-01';
ALTER ROLE myrole RENAME TO myrole2;
```
Mengganti nama role (`ALTER ROLE myrole RENAME TO newname`) juga dibatasi jika password menggunakan algoritma MD5 hashing.
Jika fitur ini dalam keadaan aktif, mencoba salah satu perintah SQL ini tanpa izin peran `rds_password` akan menghasilkan kesalahan berikut:
```
ERROR: must be a member of rds_password to alter passwords
```
Sebaiknya Anda memberikan `rds_password` hanya untuk beberapa peran yang Anda gunakan semata untuk manajemen kata sandi. Jika memberikan hak akses `rds_password` kepada pengguna basis data yang tidak memiliki hak akses `rds_superuser`, Anda juga harus memberi mereka atribut `CREATEROLE`.
Pastikan Anda memverifikasi persyaratan kata sandi seperti kedaluwarsa dan kompleksitas yang diperlukan di sisi klien. Jika Anda menggunakan utilitas sisi klien Anda sendiri untuk perubahan terkait kata sandi, utilitas tersebut harus menjadi anggota `rds_password` dan memiliki hak akses `CREATE ROLE`.
# Menggunakan SCRAM untuk enkripsi kata sandi PostgreSQL
The *Salted Challenge Response Authentication Mechanism (SCRAM)* adalah alternatif dari algoritma message digest (MD5) default PostgreSQL untuk mengenkripsi kata sandi. Mekanisme otentikasi SCRAM dianggap lebih aman daripada. MD5 Untuk mempelajari selengkapnya tentang dua pendekatan berbeda untuk mengamankan kata sandi ini, lihat [Password Authentication](https://www.postgresql.org/docs/14/auth-password.html) dalam dokumentasi PostgreSQL.
Kami menyarankan Anda menggunakan SCRAM daripada MD5 sebagai skema enkripsi kata sandi untuk cluster Aurora PostgreSQL DB Anda. SCRAM didukung di Aurora PostgreSQL versi 10 dan semua versi mayor dan minor yang lebih tinggi. Ini adalah mekanisme respons tantangan kriptografi yang menggunakan algoritma scram-sha-256 untuk autentikasi dan enkripsi kata sandi.
Anda mungkin perlu memperbarui pustaka untuk aplikasi klien Anda agar dapat mendukung SCRAM. Misalnya, versi JDBC sebelum 42.2.0 tidak mendukung SCRAM. Untuk informasi selengkapnya, lihat [PostgreSQL JDBC Driver](https://jdbc.postgresql.org/changelogs/2018-01-17-42.2.0-release/) dalam dokumentasi Driver JDBC PostgreSQL. Untuk daftar driver PostgreSQL dan dukungan SCRAM lainnya, lihat [List of drivers](https://wiki.postgresql.org/wiki/List_of_drivers) dalam dokumentasi PostgreSQL.
Aurora PostgreSQL versi 14 dan yang lebih tinggi mendukung scram-sha-256 untuk enkripsi kata sandi untuk klaster DB baru secara default. Untuk versi ini, grup parameter cluster DB default (`default.aurora-postgresql14`) memiliki `password_encryption` nilai yang disetel ke scram-sha-256. SCRAM tidak didukung untukAurora Serverless v1.
## Menyiapkan Aurora PostgreSQL DB cluster untuk instance PostgreSQL DB untuk memerlukan SCRAM
Untuk Aurora PostgreSQL 14.3 dan versi yang lebih tinggi, Anda dapat meminta klaster DB Aurora PostgreSQL untuk hanya menerima kata sandi yang menggunakan algoritma scram-sha-256.
**penting**
Untuk Proksi RDS yang ada dengan basis data PostgreSQL, jika Anda mengubah autentikasi basis data untuk hanya menggunakan `SCRAM`, proksi akan menjadi tidak tersedia selama maksimal 60 detik. Untuk menghindari masalah ini, lakukan salah satu tindakan berikut:
Pastikan basis data mengizinkan autentikasi `SCRAM` dan `MD5`.
Untuk hanya menggunakan autentikasi `SCRAM`, buat proksi baru, migrasikan lalu lintas aplikasi Anda ke proksi baru, lalu hapus proksi yang sebelumnya terkait dengan basis data.
Sebelum melakukan perubahan pada sistem, pastikan Anda telah memahami proses lengkapnya, sebagai berikut:
+ Dapatkan informasi semua peran dan enkripsi kata sandi untuk semua pengguna basis data.
+ Periksa kembali pengaturan parameter klaster DB Aurora PostgreSQL untuk parameter yang mengontrol enkripsi kata sandi.
+ Jika klaster DB Aurora PostgreSQL menggunakan grup parameter default, maka Anda harus membuat grup parameter klaster DB , lalu menerapkannya ke klaster DB Aurora PostgreSQL agar Anda dapat memodifikasi parameter saat diperlukan. Jika klaster DB Aurora PostgreSQL menggunakan grup parameter kustom, Anda dapat memodifikasi parameter yang diperlukan nanti selama prosesnya sesuai kebutuhan.
+ Ubah parameter `password_encryption` ke `scram-sha-256`.
+ Beri tahu semua pengguna basis data bahwa mereka perlu memperbarui kata sandi. Lakukan hal yang sama untuk akun `postgres` Anda. Kata sandi baru telah dienkripsi dan disimpan menggunakan algoritma scram-sha-256.
+ Verifikasikan bahwa semua kata sandi telah dienkripsi menggunakan jenis enkripsi tersebut.
+ Jika semua kata sandi menggunakan scram-sha-256, Anda dapat mengubah parameter `rds.accepted_password_auth_method` dari `md5+scram` ke `scram-sha-256`.
**Awas**
Setelah Anda mengubah `rds.accepted_password_auth_method` ke scram-sha-256 saja, setiap pengguna (peran) dengan kata sandi terenkripsi `md5` tidak dapat terhubung.
###
Sebelum membuat perubahan apa pun pada klaster DB Aurora PostgreSQL periksa semua akun pengguna basis data yang ada. Periksa juga jenis enkripsi yang digunakan untuk kata sandi. Anda dapat melakukan semua tugas ini menggunakan ekstensi `rds_tools`. Untuk melihat versi PostgreSQL yang `rds_tools` didukung, [lihat Versi ekstensi untuk Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html) for PostgreSQL.
**Untuk mendapatkan daftar pengguna (peran) basis data dan metode enkripsi kata sandi**
1. Gunakan `psql` untuk terhubung ke instans primer klaster DB Aurora PostgreSQL , sebagaimana yang ditunjukkan di bawah ini.
```
psql --host=cluster-name-instance-1.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Instal ekstensi `rds_tools`.
```
postgres=> CREATE EXTENSION rds_tools;
CREATE EXTENSION
```
1. Dapatkan daftar peran dan enkripsi.
```
postgres=> SELECT * FROM
rds_tools.role_password_encryption_type();
```
Anda akan melihat output yang mirip dengan berikut ini.
```
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | md5
user_465 | md5
postgres | md5
(8 rows)
```
### Membuat grup parameter klaster DB
**catatan**
Jika klaster DB Aurora PostgreSQL sudah menggunakan grup parameter kustom, Anda tidak perlu membuat grup parameter yang baru.
Untuk ringkasan grup parameter Aurora, lihat [Membuat grup parameter cluster DB di Amazon Aurora](USER_WorkingWithParamGroups.CreatingCluster.md).
Jenis enkripsi kata sandi yang digunakan untuk kata sandi yang diatur dalam satu parameter, `password_encryption`. Enkripsi yang diizinkan oleh klaster DB Aurora PostgreSQL diatur dalam parameter lain, `rds.accepted_password_auth_method`. Mengubah salah satu dari nilai default ini mengharuskan Anda membuat grup parameter klaster DB , lalu menerapkannya ke klaster.
Anda juga dapat menggunakan Konsol Manajemen AWS atau RDS API untuk membuat grup parameter cluster DB kustom grup parameter . Untuk informasi lebih lanjut, lihat [Membuat grup parameter cluster DB di Amazon Aurora](USER_WorkingWithParamGroups.CreatingCluster.md).
Anda kini dapat mengaitkan grup parameter kustom dengan instans DB.
**Untuk membuat grup parameter cluster DB kustom grup**
1. Gunakan perintah CLI `[create-db-cluster-parameter-group](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster-parameter-group.html)` untuk membuat grup parameter kustom untuk klaster. Contoh berikut menggunakan `aurora-postgresql13` sebagai sumber untuk grup parameter kustom ini.
Untuk Linux, macOS, atau Unix:
```
aws rds create-db-cluster-parameter-group --db-cluster-parameter-group-name 'docs-lab-scram-passwords' \
--db-parameter-group-family aurora-postgresql13 --description 'Custom DB cluster parameter group for SCRAM'
```
Untuk Windows:
```
aws rds create-db-cluster-parameter-group --db-cluster-parameter-group-name "docs-lab-scram-passwords" ^
--db-parameter-group-family aurora-postgresql13 --description "Custom DB cluster parameter group for SCRAM"
```
Anda kini dapat mengaitkan grup parameter kustom dengan klaster.
1. Gunakan perintah CLI `[modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)` untuk menerapkan grup parameter kustom ini ke klaster DB Aurora PostgreSQL Anda.
Untuk Linux, macOS, atau Unix:
```
aws rds modify-db-cluster --db-cluster-identifier 'your-instance-name' \
--db-cluster-parameter-group-name "docs-lab-scram-passwords
```
Untuk Windows:
```
aws rds modify-db-cluster --db-cluster-identifier "your-instance-name" ^
--db-cluster-parameter-group-name "docs-lab-scram-passwords
```
Untuk menyinkronkan ulang klaster DB Aurora PostgreSQL Anda dengan grup parameter klaster DB kustom, boot ulang instans primer dan semua instans lain klaster.
### Mengonfigurasi enkripsi kata sandi agar menggunakan SCRAM
Mekanisme enkripsi kata sandi yang digunakan oleh klaster DB Aurora PostgreSQL diatur dalam grup parameter klaster DB dalam parameter `password_encryption`. Nilai yang diizinkan tidak ditentukan, `md5`, atau `scram-sha-256`. Nilai default bergantung pada versi Aurora PostgreSQL , sebagai berikut:
+ Aurora PostgreSQL 14 – Default adalah `scram-sha-256`
+ Aurora PostgreSQL 13 – Default adalah `md5`
Dengan grup parameter klaster DB yang terhubung ke klaster DB Aurora PostgreSQL, Anda dapat memodifikasi nilai untuk parameter enkripsi kata sandi.
![\[Berikutnya, konsol RDS akan menunjukkan nilai default parameter password_encryption untuk Aurora PostgreSQL.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/apg-pwd-encryption-md5-scram-1.png)
**Untuk mengubah pengaturan enkripsi kata sandi menjadi scram-sha-256**
+ Ubah nilai enkripsi kata sandi menjadi scram-sha-256, sebagaimana ditunjukkan berikut ini. Perubahan dapat langsung diterapkan karena parameternya dinamis, jadi mulai ulang tidak diperlukan agar perubahan diterapkan.
Untuk Linux, macOS, atau Unix:
```
aws rds modify-db-cluster-parameter-group --db-cluster-parameter-group-name \
'docs-lab-scram-passwords' --parameters 'ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate'
```
Untuk Windows:
```
aws rds modify-db-parameter-group --db-parameter-group-name ^
"docs-lab-scram-passwords" --parameters "ParameterName=password_encryption,ParameterValue=scram-sha-256,ApplyMethod=immediate"
```
### Memigrasikan kata sandi untuk peran pengguna ke SCRAM
Anda dapat memigrasikan kata sandi untuk peran pengguna ke SCRAM sebagaimana dijelaskan berikut.
**Untuk memigrasikan kata sandi pengguna (peran) basis data dari MD5 ke SCRAM**
1. Masuk sebagai pengguna administrator (nama pengguna default, `postgres`) sebagaimana ditunjukkan berikut.
```
psql --host=cluster-name-instance-1.111122223333.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password
```
1. Periksa pengaturan parameter `password_encryption` pada instans DB RDS for PostgreSQL menggunakan perintah berikut.
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
md5
(1 row)
```
1. Ubah nilai parameter ini menjadi scram-sha-256. Untuk informasi selengkapnya, lihat [Mengonfigurasi enkripsi kata sandi agar menggunakan SCRAM](#PostgreSQL_Password_Encryption_configuration.configure-password-encryption).
1. Periksa kembali nilainya untuk memastikan bahwa sekarang diatur ke`scram-sha-256`, sebagai berikut.
```
postgres=> SHOW password_encryption;
password_encryption
---------------------
scram-sha-256
(1 row)
```
1. Beri tahu semua pengguna basis data untuk mengubah kata sandi mereka. Pastikan juga untuk mengubah kata sandi Anda sendiri untuk akun `postgres` (pengguna basis data dengan hak akses `rds_superuser`).
```
labdb=> ALTER ROLE postgres WITH LOGIN PASSWORD 'change_me';
ALTER ROLE
```
1. Ulangi proses tersebut untuk semua basis data di klaster DB Aurora PostgreSQL Anda.
### Mengubah parameter untuk mengharuskan SCRAM
Ini adalah langkah terakhir dalam proses. Setelah Anda membuat perubahan dalam prosedur berikut, setiap akun pengguna (peran) yang masih menggunakan enkripsi `md5` untuk kata sandi tidak dapat masuk ke klaster DB PostgreSQL Aurora.
`rds.accepted_password_auth_method` menentukan metode enkripsi yang klaster DB Aurora PostgreSQL DB menerima untuk kata sandi pengguna selama proses masuk. Nilai default-nya adalah `md5+scram`, yang berarti bahwa salah satu metode diterima. Pada gambar berikut, Anda dapat menemukan pengaturan default untuk parameter ini.
![\[Konsol RDS menunjukkan nilai default dan yang diizinkan untuk parameter rds.accepted_password_auth_method.\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/images/pwd-encryption-md5-scram-2.png)
Nilai yang diizinkan untuk parameter ini adalah `md5+scram` atau `scram` saja. Mengubah nilai parameter ini ke `scram` akan menjadikannya sebagai persyaratan.
**Untuk mengubah nilai parameter agar mengharuskan autentikasi SCRAM untuk kata sandi**
1. Verifikasikan bahwa semua kata sandi pengguna basis data untuk semua basis data di klaster DB Aurora PostgreSQL menggunakan `scram-sha-256` untuk enkripsi kata sandi. Untuk melakukannya, buat kueri `rds_tools` untuk peran (pengguna) dan jenis enkripsi, sebagai berikut.
```
postgres=> SELECT * FROM rds_tools.role_password_encryption_type();
rolname | encryption_type
----------------------+-----------------
pg_monitor |
pg_read_all_settings |
pg_read_all_stats |
pg_stat_scan_tables |
pg_signal_backend |
lab_tester | scram-sha-256
user_465 | scram-sha-256
postgres | scram-sha-256
( rows)
```
1. Ulangi kueri di semua instans DB dalam klaster DB Aurora PostgreSQL Anda.
Jika semua kata sandi menggunakan scram-sha-256, Anda dapat melanjutkan.
1. Ubah nilai autentikasi kata sandi yang diterima menjadi scram-sha-256, sebagai berikut.
Untuk Linux, macOS, atau Unix:
```
aws rds modify-db-cluster-parameter-group --db-cluster-parameter-group-name 'docs-lab-scram-passwords' \
--parameters 'ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate'
```
Untuk Windows:
```
aws rds modify-db-cluster-parameter-group --db-cluster-parameter-group-name "docs-lab-scram-passwords" ^
--parameters "ParameterName=rds.accepted_password_auth_method,ParameterValue=scram,ApplyMethod=immediate"
```
## Mengamankan data Aurora PostgreSQL dengan SSL/TLS
Amazon RDS mendukung enkripsi Lapisan Soket Aman (SSL) dan Keamanan Lapisan Pengangkutan (TLS) untuk klaster DB Aurora PostgreSQL. MenggunakanSSL/TLS, you can encrypt a connection between your applications and your Aurora PostgreSQL DB clusters. You can also force all connections to your Aurora PostgreSQL DB cluster to use SSL/TLS. Amazon Aurora PostgreSQL mendukung Keamanan Lapisan Pengangkutan (TLS) versi 1.1 dan 1.2. Kami merekomendasikan menggunakan TLS 1.2 untuk koneksi terenkripsi. Kami telah menambahkan dukungan untuk TLSv1 .3 dari versi Aurora PostgreSQL berikut:
+ Versi 15.3 dan semua yang lebih tinggi
+ Versi 14.8 dan versi 14 yang lebih tinggi
+ 13.11 dan versi 13 yang lebih tinggi
+ 12.15 dan versi 12 yang lebih tinggi
+ Versi 11.20 dan versi 11 yang lebih tinggi
Untuk informasi umum tentang SSL/TLS dukungan dan database PostgreSQL, lihat dukungan [SSL](https://www.postgresql.org/docs/current/libpq-ssl.html) di dokumentasi PostgreSQL. Untuk informasi tentang menggunakan SSL/TLS koneksi melalui JDBC, lihat [Mengonfigurasi klien dalam](https://jdbc.postgresql.org/documentation/head/ssl-client.html) dokumentasi PostgreSQL.
**Topics**
+ [Membutuhkan SSL/TLS koneksi ke cluster Aurora PostgreSQL DB](#AuroraPostgreSQL.Security.SSL.Requiring)
+ [Menentukan status SSL/TLS koneksi](#AuroraPostgreSQL.Security.SSL.Status)
+ [Mengonfigurasi cipher suite untuk koneksi ke klaster DB Aurora PostgreSQL](#AuroraPostgreSQL.Security.SSL.ConfiguringCipherSuites)
Dukungan SSL/TLS tersedia di semua Wilayah untuk AWS Aurora PostgreSQL. Amazon RDS membuat SSL/TLS sertifikat untuk klaster DB PostgreSQL Aurora Anda saat cluster DB dibuat. Jika Anda mengaktifkan verifikasi SSL/TLS sertifikat, maka SSL/TLS sertifikat tersebut menyertakan titik akhir klaster DB sebagai Nama Umum (CN) agar SSL/TLS sertifikat terlindungi dari serangan spoofing.
**Untuk menghubungkan ke klaster DB Aurora PostgreSQL melalui SSL/TLS**
1. Unduh sertifikatnya.
Untuk informasi tentang mengunduh sertifikat, lihat [Menggunakan SSL/TLS untuk mengenkripsi koneksi ke ](UsingWithRDS.SSL.md).
1. Impor sertifikat ke dalam sistem operasi Anda.
1. Hubungkan ke klaster DB Aurora PostgreSQL melalui SSL/TLS.
Saat Anda menghubungkan menggunakan SSL/TLS, klien Anda dapat memilih untuk memverifikasi rantai sertifikat atau tidak. Jika parameter koneksi Anda menentukan `sslmode=verify-ca` atau `sslmode=verify-full`, maka klien Anda mengharuskan sertifikat RDS CA berada di penyimpanan kepercayaan atau direferensikan di URL koneksi. Persyaratan ini untuk memverifikasi rantai sertifikat yang menandatangani sertifikat basis data Anda.
Ketika klien, seperti psql atau JDBC, dikonfigurasi dengan SSL/TLS dukungan, klien pertama mencoba untuk terhubung ke database dengan secara default. SSL/TLS Jika klien tidak dapat terhubung denganSSL/TLS, it reverts to connecting without SSL/TLS. Secara default, opsi `sslmode` untuk klien berbasis JDBC dan libpq diatur ke `prefer`.
Gunakan parameter `sslrootcert` untuk mereferensikan sertifikat, misalnya `sslrootcert=rds-ssl-ca-cert.pem`.
Berikut ini adalah contoh penggunaan psql untuk terhubung ke klaster DB Aurora PostgreSQL.
```
$ psql -h testpg.cdhmuqifdpib.us-east-1.rds.amazonaws.com -p 5432 \
"dbname=testpg user=testuser sslrootcert=rds-ca-2015-root.pem sslmode=verify-full"
```
### Membutuhkan SSL/TLS koneksi ke cluster Aurora PostgreSQL DB
Untuk memerlukan SSL/TLS koneksi ke cluster Aurora PostgreSQL DB Anda, gunakan parameter. `rds.force_ssl`
+ Untuk memerlukan SSL/TLS koneksi, atur nilai `rds.force_ssl` parameter ke 1 (on).
+ Untuk mematikan SSL/TLS koneksi yang diperlukan, atur nilai `rds.force_ssl` parameter ke 0 (off).
Nilai default parameter ini tergantung pada versi Aurora PostgreSQL:
+ Untuk Aurora PostgreSQL versi 17 dan yang lebih baru: Nilai default adalah 1 (on).
+ Untuk Aurora PostgreSQL versi 16 dan yang lebih lama: Nilai default adalah 0 (off).
**catatan**
Saat Anda melakukan upgrade versi mayor dari Aurora PostgreSQL versi 16 atau versi sebelumnya ke versi 17 atau yang lebih baru, nilai default parameter berubah dari 0 (off) menjadi 1 (on). Perubahan ini dapat menyebabkan kegagalan konektivitas untuk aplikasi yang tidak dikonfigurasi untuk SSL. Anda dapat kembali ke perilaku default sebelumnya dengan menyetel parameter ini ke 0 (off).
Untuk informasi selengkapnya tentang penanganan parameter, lihat[](USER_WorkingWithParamGroups.md).
Memperbarui `rds.force_ssl` parameter juga menetapkan parameter `ssl` PostgreSQL ke 1 (on) dan memodifikasi file cluster `pg_hba.conf` DB Anda untuk mendukung konfigurasi baru. SSL/TLS
Ketika `rds.force_ssl` parameter diatur ke 1 untuk cluster DB, Anda melihat output yang mirip dengan yang berikut saat Anda terhubung, menunjukkan bahwa sekarang SSL/TLS diperlukan:
```
$ psql postgres -h SOMEHOST.amazonaws.com -p 8192 -U someuser
psql (9.3.12, server 9.4.4)
WARNING: psql major version 9.3, server major version 9.4.
Some psql features might not work.
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.
postgres=>
```
### Menentukan status SSL/TLS koneksi
Status terenkripsi dari koneksi Anda ditunjukkan pada banner logon saat Anda terhubung ke klaster DB.
```
Password for user master:
psql (9.3.12)
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.
postgres=>
```
Anda juga dapat memuat `sslinfo` ekstensi dan kemudian memanggil `ssl_is_used()` fungsi untuk menentukan apakah SSL/TLS sedang digunakan. Fungsi akan kembali `t` jika koneksi menggunakan SSL/TLS, jika tidak akan menghasilkan `f`.
```
postgres=> create extension sslinfo;
CREATE EXTENSION
postgres=> select ssl_is_used();
ssl_is_used
---------
t
(1 row)
```
Anda dapat menggunakan perintah `select ssl_cipher()` untuk menentukan cipher SSL/TLS:
```
postgres=> select ssl_cipher();
ssl_cipher
--------------------
DHE-RSA-AES256-SHA
(1 row)
```
Jika Anda mengaktifkan `set rds.force_ssl` dan memulai ulang klaster DB, koneksi non-SSL ditolak dengan pesan berikut ini:
```
$ export PGSSLMODE=disable
$ psql postgres -h SOMEHOST.amazonaws.com -p 8192 -U someuser
psql: FATAL: no pg_hba.conf entry for host "host.ip", user "someuser", database "postgres", SSL off
$
```
Untuk informasi tentang opsi `sslmode`, lihat [Database connection control functions](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNECT-SSLMODE) dalam dokumentasi PostgreSQL.
### Mengonfigurasi cipher suite untuk koneksi ke klaster DB Aurora PostgreSQL
Dengan menggunakan cipher suite yang dapat dikonfigurasi, Anda dapat memiliki kontrol lebih besar atas keamanan koneksi basis data. Anda dapat menentukan daftar cipher suite yang ingin Anda izinkan untuk mengamankan SSL/TLS koneksi klien ke database Anda. Dengan cipher suite yang dapat dikonfigurasi, Anda dapat mengontrol enkripsi koneksi yang diterima server basis data Anda. Melakukan hal ini membantu mencegah penggunaan cipher yang tidak aman atau usang.
Suite cipher yang dapat dikonfigurasi didukung di Aurora PostgreSQL versi 11.8 dan lebih tinggi.
Untuk menentukan daftar cipher yang diizinkan untuk mengenkripsi koneksi, modifikasi parameter klaster `ssl_ciphers`. Setel `ssl_ciphers` parameter ke string nilai cipher yang dipisahkan koma dalam grup parameter cluster menggunakan Konsol Manajemen AWS, AWS CLI, atau RDS API. Untuk mengatur parameter klaster, lihat [Memodifikasi parameter dalam grup parameter cluster DB di Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md).
Tabel berikut menunjukkan cipher yang didukung untuk versi mesin Aurora PostgreSQL yang valid.
| Versi mesin Aurora PostgreSQL | Cipher yang didukung | TLS 1.1 | TLS 1.2 | TLS 1.3 |
| --- | --- | --- | --- | --- |
| 9.6, 10.20 dan lebih rendah, 11.15 dan lebih rendah, 12.10 dan lebih rendah, 13.6 dan lebih rendah | DHE-RSA- -SHA AES128 DHE-RSA- - AES128 SHA256 DHE-RSA- -GCM- AES128 SHA256 DHE-RSA- -SHA AES256 DHE-RSA- - AES256 SHA256 DHE-RSA- -GCM- AES256 SHA384 ECDHE-ECDSA- -SHA AES256 ECDHE-ECDSA- -GCM- AES256 SHA384 ECDHE-RSA- - AES256 SHA384 ECDHE-RSA- -SHA AES128 ECDHE-RSA- - AES128 SHA256 ECDHE-RSA- -GCM- AES128 SHA256 ECDHE-RSA- -SHA AES256 ECDHE-RSA- -GCM- AES256 SHA384 | Ya Tidak Tidak Tidak Tidak Tidak Ya Tidak Tidak Ya Tidak Tidak Ya Tidak | Tidak Ya Ya Ya Ya Ya Ya Ya Ya Ya Ya Ya Ya Ya | Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak |
| 10.21, 11.16, 12.11, 13.7, 14.3, dan 14.4 | ECDHE-RSA- -SHATLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA AES128 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 TLS\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA TLS\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1DENGAN\$1 \$1 \$1 CHACHA20 POLY1305 SHA256 | Ya Tidak Ya Tidak Ya Tidak Ya Tidak Tidak Ya Tidak Ya Tidak | Ya Ya Ya Ya Ya Ya Ya Ya Ya Ya Ya Ya Ya | Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak |
| 10.22, 11.17, 12.12, 13.8, 14.5, dan 15.2 | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 TLS\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA TLS\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256 TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1DENGAN\$1 \$1 \$1 CHACHA20 POLY1305 SHA256 | Ya Tidak Tidak Ya Tidak Ya Tidak Tidak Ya Tidak Tidak Ya Tidak Ya Ya Tidak | Ya Ya Ya Ya Ya Ya Ya Ya Ya Ya Ya Ya Ya Ya Ya Ya | Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak |
| 11.20, 12.15, 13.11, 14.8, 15.3, 16.1 dan lebih tinggi | TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 TLS\$1RSA\$1WITH\$1AES\$1256\$1GCM\$1 SHA384 TLS\$1RSA\$1WITH\$1AES\$1256\$1CBC\$1SHA TLS\$1RSA\$1WITH\$1AES\$1128\$1GCM\$1 SHA256 TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1 SHA256 TLS\$1RSA\$1WITH\$1AES\$1128\$1CBC\$1SHA TLS\$1ECDHE\$1RSA\$1DENGAN\$1 \$1 \$1 CHACHA20 POLY1305 SHA256 TLS\$1AES\$1128\$1GCM\$1 SHA256 TLS\$1AES\$1256\$1GCM\$1 SHA384 | Ya Tidak Tidak Ya Tidak Ya Tidak Tidak Ya Tidak Tidak Ya Tidak Ya Ya Tidak Tidak Tidak | Ya Ya Ya Ya Ya Ya Ya Ya Ya Ya Ya Ya Ya Ya Ya Ya Tidak Tidak | Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Tidak Ya Ya |
Anda juga dapat menggunakan perintah [describe-engine-default-cluster-parameter](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-engine-default-cluster-parameters.html) CLI untuk menentukan rangkaian sandi mana yang saat ini didukung untuk keluarga grup parameter tertentu. Contoh berikut menunjukkan cara mendapatkan nilai yang diizinkan untuk parameter klaster `ssl_cipher` untuk Aurora PostgreSQL 11.
```
aws rds describe-engine-default-cluster-parameters --db-parameter-group-family aurora-postgresql11
...some output truncated...
{
"ParameterName": "ssl_ciphers",
"Description": "Sets the list of allowed TLS ciphers to be used on secure connections.",
"Source": "engine-default",
"ApplyType": "dynamic",
"DataType": "list",
"AllowedValues": "DHE-RSA-AES128-SHA,DHE-RSA-AES128-SHA256,DHE-RSA-AES128-GCM-SHA256,DHE-RSA-AES256-SHA,DHE-RSA-AES256-SHA256,DHE-RSA-AES256-GCM-SHA384,
ECDHE-RSA-AES128-SHA,ECDHE-RSA-AES128-SHA256,ECDHE-RSA-AES128-GCM-SHA256,ECDHE-RSA-AES256-SHA,ECDHE-RSA-AES256-SHA384,ECDHE-RSA-AES256-GCM-SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,
TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
"IsModifiable": true,
"MinimumEngineVersion": "11.8",
"SupportedEngineModes": [
"provisioned"
]
},
...some output truncated...
```
Parameter default `ssl_ciphers` ke semua suite cipher yang diizinkan. Untuk informasi selengkapnya tentang cipher, lihat variabel [ssl\$1ciphers](https://www.postgresql.org/docs/current/runtime-config-connection.html#GUC-SSL-CIPHERS) dalam dokumentasi PostgreSQL.
# Menggunakan masking dinamis dengan Aurora PostgreSQL
Dynamic data masking adalah fitur keamanan yang melindungi data sensitif dalam database Aurora PostgreSQL dengan mengontrol bagaimana data muncul kepada pengguna pada waktu query. Aurora mengimplementasikannya melalui ekstensi. `pg_columnmask` `pg_columnmask`menyediakan perlindungan data tingkat kolom yang melengkapi keamanan tingkat baris asli PostgreSQL dan mekanisme kontrol akses granular.
Dengan`pg_columnmask`, Anda membuat kebijakan masking yang menentukan visibilitas data berdasarkan peran pengguna. Saat pengguna menanyakan tabel dengan kebijakan masking, Aurora PostgreSQL menerapkan fungsi masking yang sesuai pada waktu kueri berdasarkan peran pengguna dan bobot kebijakan. Data yang mendasarinya tetap tidak berubah dalam penyimpanan.
`pg_columnmask`mendukung kemampuan berikut:
+ Fungsi **masking bawaan dan kustom - Gunakan fungsi** pra-bangun untuk pola umum seperti email dan masking teks, atau buat fungsi kustom Anda sendiri untuk melindungi data sensitif (PII) melalui kebijakan masking berbasis SQL.
+ **Beberapa strategi masking** — Sembunyikan informasi sepenuhnya, ganti nilai paral dengan wildcard, atau tentukan pendekatan masking khusus.
+ **Prioritas kebijakan** - Tentukan beberapa kebijakan untuk satu kolom. Gunakan bobot untuk menentukan kebijakan masking mana yang harus digunakan saat beberapa kebijakan berlaku pada kolom. Aurora PostgreSQL menerapkan kebijakan berdasarkan bobot dan keanggotaan peran pengguna.
`pg_columnmask`tersedia di Aurora PostgreSQL versi 16.10 dan lebih tinggi, dan versi 17.6 dan lebih tinggi. Tersedia tersedia tanpa biaya tambahan.
# Memulai dengan masking dinamis
Untuk menutupi data secara dinamis, Anda menginstal `pg_columnmask` ekstensi di database Anda dan membuat kebijakan masking untuk tabel Anda. Proses penyiapan melibatkan verifikasi prasyarat, instalasi ekstensi, konfigurasi peran, pembuatan kebijakan, dan pengujian validasi.
## Instalasi dan konfigurasi ekstensi
Connect ke cluster Aurora PostgreSQL Anda menggunakan RDS Console Query Editor atau klien PostgreSQL seperti psql dengan kredensial rds\$1superuser (pengguna utama).
Jalankan perintah pembuatan ekstensi untuk mengaktifkan `pg_columnmask` fungsionalitas:
```
CREATE EXTENSION pg_columnmask;
```
Perintah ini menginstal `pg_columnmask` ekstensi, membuat tabel katalog yang diperlukan, dan mendaftarkan fungsi masking bawaan. Instalasi ekstensi khusus basis data, artinya Anda harus menginstalnya secara terpisah di setiap database di mana fungsionalitas diperlukan.
**catatan**
Koneksi yang dibuat sebelum menginstal ekstensi ini masih akan menampilkan data yang dibuka kedoknya. Tutup dan sambungkan kembali untuk memperbaikinya.
Verifikasi instalasi ekstensi dengan memeriksa fungsi masking yang tersedia:
```
SELECT proname FROM pg_proc
WHERE pronamespace = 'pgcolumnmask'::regnamespace AND proname LIKE 'mask_%';
proname
--------Output --------
mask_email
mask_text
mask_timestamp
(3 rows)
```
# Prosedur untuk mengelola kebijakan penyembunyian data
Anda dapat mengelola kebijakan masking menggunakan prosedur yang disediakan oleh `pg_columnmask` ekstensi. Untuk membuat, memodifikasi, atau menghapus kebijakan masking, Anda harus memiliki salah satu hak istimewa berikut:
+ Pemilik tabel tempat Anda membuat `pg_columnmask` kebijakan.
+ Anggota dari`rds_superuser`.
+ Anggota peran manajer `pg_columnmask` kebijakan yang ditetapkan oleh `pgcolumnmask.policy_admin_rolname` parameter.
Perintah berikut membuat tabel yang digunakan di bagian berikutnya:
```
CREATE TABLE public.customers (
id SERIAL PRIMARY KEY,
name TEXT,
phone TEXT,
address TEXT,
email TEXT
);
```
## CREATE\$1MASKING\$1POLICY
Prosedur berikut membuat kebijakan masking baru untuk tabel pengguna:
**Sintaksis**
```
create_masking_policy(
policy_name,
table_name,
masking_expressions,
roles,
weight)
```
**Argumen**
| Parameter | JenisData | Deskripsi |
| --- | --- | --- |
| policy\$1name | NAME | Nama kebijakan masking. Harus unik per tabel. |
| table\$1name | REGCLASS | qualified/unqualified Nama atau oid tabel untuk menerapkan kebijakan masking. |
| masking\$1expressions | JSONB | Objek JSON yang berisi nama kolom dan pasangan fungsi masking. Setiap kunci adalah nama kolom dan nilainya adalah ekspresi masking yang akan diterapkan pada kolom itu. |
| roles | NAMA [] | Peran yang diterapkan kebijakan masking ini. Defaultnya adalah PUBLIK. |
| weight | INT | Bobot kebijakan masking. Jika beberapa kebijakan berlaku untuk kueri pengguna tertentu, kebijakan dengan bobot tertinggi (bilangan bulat lebih tinggi) akan diterapkan ke setiap kolom bertopeng. Default-nya adalah 0. Tidak ada dua kebijakan masking di atas meja yang dapat memiliki kekuatan yang sama. |
**Jenis pengembalian**
Tidak ada
**Example membuat kebijakan masking yang menutupi kolom email untuk `test_user` peran tersebut:**
```
CALL pgcolumnmask.create_masking_policy(
'customer_mask',
'public.customers',
JSON_OBJECT('{
"email", "pgcolumnmask.mask_email(email)"
}')::JSONB,
ARRAY['test_user'],
100
);
```
## ALTER\$1MASKING\$1POLICY
Prosedur ini memodifikasi kebijakan masking yang ada. `ALTER_MASKING_POLICY`dapat memodifikasi ekspresi masking kebijakan, serangkaian peran yang diterapkan kebijakan dan bobot kebijakan masking. Ketika salah satu parameter tersebut dihilangkan, bagian yang sesuai dari kebijakan tidak berubah.
**Sintaksis**
```
alter_masking_policy(
policy_name,
table_name,
masking_expressions,
roles,
weight)
```
**Argumen**
| Parameter | JenisData | Deskripsi |
| --- | --- | --- |
| policy\$1name | NAME | Nama kebijakan masking yang ada. |
| table\$1name | REGCLASS | qualified/unqualified Nama oid dari tabel yang berisi kebijakan masking. |
| masking\$1expressions | JSONB | Objek JSON baru yang berisi nama kolom dan pasangan fungsi masking atau NULL sebaliknya. |
| roles | NAMA [] | Daftar peran baru yang diterapkan kebijakan penyembunyian ini atau NULL sebaliknya. |
| weight | INT | Bobot baru untuk kebijakan masking atau NULL sebaliknya. |
**Jenis pengembalian**
Tidak ada
**Example menambahkan peran analis ke kebijakan masking yang ada tanpa mengubah atribut kebijakan lainnya.**
```
CALL pgcolumnmask.alter_masking_policy(
'customer_mask',
'public.customers',
NULL,
ARRAY['test_user', 'analyst'],
NULL
);
-- Alter the weight of the policy without altering other details
CALL pgcolumnmask.alter_masking_policy(
'customer_mask',
'customers',
NULL,
NULL,
4
);
```
## DROP\$1MASKING\$1POLICY
Prosedur ini menghapus kebijakan masking yang ada.
**Sintaksis**
```
drop_masking_policy(
policy_name,
table_name)
```
**Argumen**
| Parameter | JenisData | Deskripsi |
| --- | --- | --- |
| policy\$1name | NAME | Nama kebijakan masking yang ada. |
| table\$1name | REGCLASS | qualified/unqualified Nama oid dari tabel yang berisi kebijakan masking. |
**Jenis pengembalian**
Tidak ada
**Example menjatuhkan kebijakan masking customer\$1mask**
```
-- Drop a masking policy
CALL pgcolumnmask.drop_masking_policy(
'customer_mask',
'public.customers',
);
```
# Melarikan diri dari pengidentifikasi dalam prosedur DDL kebijakan masking
Saat membuat kebijakan penyembunyian data dengan pengidentifikasi yang dikutip, pelolosan yang tepat diperlukan untuk memastikan referensi objek dan aplikasi kebijakan yang benar. Untuk menggunakan pengenal yang dikutip dalam prosedur manajemen kebijakan `pg_columnmask` masking:
+ **Nama kebijakan** — Harus dilampirkan dalam tanda kutip ganda.
+ **Nama tabel** - Baik nama skema dan nama tabel harus dilampirkan dalam tanda kutip ganda satu per satu bila diperlukan.
+ **Ekspresi masking** — Nama kolom dan fungsi dalam ekspresi masking harus diapit tanda kutip ganda dan tanda kutip itu sendiri harus diloloskan menggunakan garis miring terbalik.
+ **Peran** - Array nama peran dikutip secara otomatis. Nama peran harus sama persis dengan nama seperti yang terlihat di `pg_roles` termasuk sensitivitas kasus.
**Example dari melarikan diri dan mengutip sintaks**
Contoh ini menunjukkan sintaks escaping dan kutipan yang tepat saat membuat kebijakan masking untuk tabel, kolom, fungsi, dan peran yang menggunakan nama kasus campuran atau memerlukan pengidentifikasi yang dikutip di Aurora PostgreSQL.
```
-- Create a table and columns with mixed case name
CREATE TABLE public."Employees" (
"Name" TEXT,
"Email" TEXT,
ssn VARCHAR(20)
);
-- Create a role with mixed case name
CREATE ROLE "Masked_user";
-- Create a function with mixed case name
CREATE OR REPLACE FUNCTION public."MaskEmail"(text)
RETURNS character varying
LANGUAGE plpgsql
IMMUTABLE PARALLEL SAFE
AS $$ BEGIN
RETURN 'XXXXXXXX'::text;
END $$;
-- Now use these objects with mixed case names in
-- masking policy management procedures
CALL pgcolumnmask.create_masking_policy(
'"Policy1"', -- policy name should be surrounded with double quotes for quoting
'public."Employees"', -- table and schema name should be individually
-- surrounded with double quotes for quoting
JSON_OBJECT('{
"\"Email\"", "\"MaskEmail\"(\"Email\")"
}')::JSONB, -- masking expression should have double quotes around function names
-- and columns names etc when needed. Also the double quotes itself
-- should be escaped using \ (backslash) since this is a JSON string
ARRAY['Masked_user'], -- Rolename do not need quoting
-- (this behaviour may change in future release)
100
);
SELECT * FROM pgcolumnmask.pg_columnmask_policies
WHERE tablename = 'Employees';
-[ RECORD 1 ]-----+-------------------------------------
schemaname | public
tablename | Employees
policyname | Policy1
roles | {Masked_user}
masked_columns | {Email}
masking_functions | {"(\"MaskEmail\"(\"Email\"))::text"}
weight | 100
```
## Pandangan administratif
Anda dapat meninjau semua `pg_columnmask` kebijakan menggunakan tampilan `pgcolumnmask.pg_columnmask_policies` administratif yang dapat diakses publik. Informasi berikut tersedia menggunakan tampilan ini. Tampilan hanya menampilkan kebijakan masking yang dimiliki oleh pengguna saat ini.
| Nama kolom | Jenis data | Deskripsi |
| --- | --- | --- |
| nama skema | NAME | Skema hubungan dengan mana kebijakan dilampirkan |
| tablename | NAME | Nama hubungan yang dilampirkan kebijakan |
| nama kebijakan | NAME | Nama kebijakan masking, semua kebijakan masking memiliki nama unik |
| peran | TEKS [] | Peran kebijakan yang berlaku. |
| bertopeng\$1kolom | TEKS [] | Kolom bertopeng |
| masking\$1functions | TEKS [] | Fungsi masking |
| berat | INT | Bobot kebijakan terlampir |
# Fungsi penyembunyian data yang telah ditentukan sebelumnya
`pg_columnmask`ekstensi menyediakan fungsi utilitas bawaan yang ditulis dalam bahasa C (untuk eksekusi lebih cepat) yang dapat digunakan sebagai ekspresi masking untuk `pg_columnmask` kebijakan.
**mask\$1text**
Fungsi untuk menutupi data teks dengan opsi visibilitas yang dapat dikonfigurasi.
**Argumen**
| Parameter | JenisData | Deskripsi |
| --- | --- | --- |
| input | TEXT | String teks asli yang akan disamarkan |
| mask\$1char | ARANG (1) | Karakter yang digunakan untuk masking (default: 'X') |
| visible\$1prefix | INT | Jumlah karakter di awal teks masukan yang akan tetap terbuka kedoknya (default: 0) |
| visible\$1suffix | INT | Jumlah karakter di akhir teks masukan yang akan tetap terbuka kedoknya (default: 0) |
| use\$1hash\$1mask | BOOLEAN | Jika TRUE, gunakan masking berbasis hash alih-alih mask\$1char (default: FALSE) |
**Example menggunakan opsi masking yang berbeda**
Tutupi seluruh string input dengan karakter 'X' default
```
postgres=> SELECT pgcolumnmask.mask_text('Hello World');
mask_text
-------------
XXXXXXXXXXX
```
Gunakan `mask_char` argumen untuk menutupi masukan teks menggunakan karakter yang berbeda
```
postgres=> SELECT pgcolumnmask.mask_text('Hello World', '*');
mask_text
-------------
***********
```
Gunakan `visible_prefix` dan `visible_suffix` parameter untuk mengontrol berapa banyak karakter yang tetap dibuka kedoknya di awal dan akhir teks
```
postgres=> SELECT pgcolumnmask.mask_text('Hello World', '*', 5, 1);
mask_text
-------------
Hello*****d
```
Kapan `use_hash_mask` benar, string input ditutupi menggunakan `mask_char` argumen karakter acak diabaikan tetapi `visible_prefix` dan `visible_suffix` masih dihormati
```
postgres=> SELECT pgcolumnmask.mask_text('Hello World', '*', 2, 2, true);
mask_text
-------------
Hex36dOHild
```
**mask\$1timestamp**
| Parameter | JenisData | Deskripsi |
| --- | --- | --- |
| ts\$1to\$1mask | TIMESTAMP | Stempel waktu asli yang akan ditutup |
| mask\$1part | TEXT | Menentukan bagian mana dari stempel waktu untuk menutupi (default: 'all') Nilai yang valid: 'year', 'month', 'day', 'hour', 'minute', 'second', 'all' |
| mask\$1value | TIMESTAMP | Nilai stempel waktu yang digunakan untuk masking (default: '1900-01-01 00:00:00 ') |
**Example menggunakan `mask_timestamps`**
Contoh-contoh ini menunjukkan masking stempel waktu lengkap ke nilai default, penyembunyian sebagian komponen stempel waktu tertentu (hanya tahun), dan penyembunyian dengan nilai penggantian khusus.
Sepenuhnya menutupi nilai input ke stempel waktu default
```
postgres=> SELECT pgcolumnmask.mask_timestamp('2023-06-15 14:30:00');
mask_timestamp
---------------------
1900-01-01 00:00:00
```
Untuk menutupi hanya satu bagian stempel waktu dari contoh hanya tahun
```
postgres=> SELECT pgcolumnmask.mask_timestamp('2023-06-15 14:30:00', 'year');
mask_timestamp
---------------------
1900-06-15 14:30:00
```
Untuk mengubah nilai masked untuk stempel waktu gunakan argumen `mask_value`
```
postgres=> SELECT pgcolumnmask.mask_timestamp('2023-06-15 14:30:00', 'all', '2012-12-12 12:12:12');
mask_timestamp
---------------------
2012-12-12 12:12:12
```
**mask\$1timestamp**
Fungsi untuk menutupi alamat email sambil mempertahankan struktur email.
| Parameter | JenisData | Deskripsi |
| --- | --- | --- |
| input | TEXT | Alamat email asli yang akan disamarkan |
| mask\$1char | ARANG (1) | Karakter yang digunakan untuk masking (default: 'X') |
| mask\$1local | BOOLEAN | Jika TRUE, menutupi bagian lokal email (sebelum @) (default: TRUE) |
| mask\$1domain | BOOLEAN | Jika TRUE, menutupi bagian domain email (setelah @) (default: TRUE) |
**Example menggunakan `mask_email`**
Contoh-contoh ini menunjukkan masking email lengkap, karakter topeng kustom, dan penyembunyian selektif dari bagian lokal atau bagian domain dari alamat email.
Masking lengkap
```
postgres=> SELECT pgcolumnmask.mask_email('user@example.com');
mask_email
------------------
XXXX@XXXXXXX.com
```
Gunakan `mask_char` untuk mengubah karakter yang digunakan untuk masking
```
postgres=> SELECT pgcolumnmask.mask_email('user@example.com', '*');
mask_email
------------------
****@*******.com
```
Gunakan `mask_local` dan `mask_domain` untuk mengontrol masking pada lokal dan domain
```
postgres=> SELECT pgcolumnmask.mask_email('user@example.com', '*', true, false);
mask_email
------------------
****@example.com
postgres=> SELECT pgcolumnmask.mask_email('user@example.com', '*', false, true);
mask_email
------------------
user@*******.com
```
# Menerapkan pg\$1columnmask dalam alur kerja end-to-end
Bagian ini menunjukkan implementasi lengkap `pg_columnmask` menggunakan tabel karyawan sampel dengan data sensitif. Anda akan belajar cara membuat fungsi masking khusus, menentukan beberapa kebijakan masking dengan tingkat bobot yang berbeda untuk berbagai peran (magang, dukungan, analis), dan mengamati bagaimana pengguna dengan keanggotaan peran tunggal atau ganda melihat berbagai tingkat data bertopeng. Contohnya juga mencakup perilaku penyembunyian dalam pernyataan DHTML dengan klausa RETURNING, pemicu pada tabel versus tampilan, dan operasi manajemen kebijakan termasuk mengganti nama, mengubah bobot, dan pembersihan.
1. Buat tabel sampel dengan beberapa data sensitif:
```
CREATE SCHEMA hr;
CREATE TABLE hr.employees (
id INT PRIMARY KEY,
name TEXT NOT NULL,
email TEXT,
ssn TEXT,
salary NUMERIC(10,2)
);
INSERT INTO hr.employees VALUES
(1, 'John Doe', 'john.doe@example.com', '123-45-6789', 50000.00),
(2, 'Jane Smith', 'jane.smith@example.com', '987-65-4321', 60000.00);
```
1. Buat fungsi masking kustom:
```
CREATE OR REPLACE FUNCTION public.mask_ssn(ssn TEXT)
RETURNS TEXT AS $$
BEGIN
RETURN 'XXX-XX-' || RIGHT(ssn, 4);
END;
$$ LANGUAGE plpgsql;
CREATE OR REPLACE FUNCTION public.mask_salary(salary NUMERIC, multiplier NUMERIC DEFAULT 0.0)
RETURNS NUMERIC AS $$
BEGIN
RETURN salary * multiplier;
END;
$$ LANGUAGE plpgsql;
```
1. Buat beberapa kebijakan dengan tingkat masking yang berbeda berdasarkan peran pengguna:
```
-- Create different roles
CREATE ROLE analyst_role;
CREATE ROLE support_role;
CREATE ROLE intern_role;
GRANT USAGE ON SCHEMA hr TO analyst_role, support_role, intern_role;
GRANT SELECT ON hr.employees TO analyst_role, support_role, intern_role;
----------------------------------------------------------------------
-- Low-Weight Policy (Intern)
CALL pgcolumnmask.create_masking_policy(
'employee_mask_strict',
'hr.employees',
JSON_BUILD_OBJECT('name', 'pgcolumnmask.mask_text(name, ''*'')',
'email', 'pgcolumnmask.mask_email(email)',
'ssn', 'pgcolumnmask.mask_text(ssn, ''*'')',
'salary', 'public.mask_salary(salary)')::JSONB,
ARRAY['intern_role'],
10 -- Lowest weight
);
----------------------------------------------------------------------
-- Medium-Weight Policy (Support)
CALL pgcolumnmask.create_masking_policy(
'employee_mask_moderate',
'hr.employees',
JSON_BUILD_OBJECT('email', 'pgcolumnmask.mask_email(email, ''#'')',
'ssn', 'public.mask_ssn(ssn)',
'salary', 'public.mask_salary(salary)')::JSONB,
ARRAY['support_role'],
50 -- Medium weight
);
----------------------------------------------------------------------
-- High-Weight Policy (Analyst)
CALL pgcolumnmask.create_masking_policy(
'employee_mask_light',
'hr.employees',
JSON_BUILD_OBJECT('ssn', 'public.mask_ssn(ssn)',
'salary', 'public.mask_salary(salary, 0.9)')::JSONB,
ARRAY['analyst_role'],
100 -- Highest weight
);
```
1. Contoh berikut menunjukkan bagaimana pengguna yang berbeda melihat data berdasarkan keanggotaan peran dan bobot kebijakan mereka.
```
-- Create users
CREATE USER sarah_intern;
GRANT intern_role TO sarah_intern;
CREATE USER lisa_support;
GRANT support_role TO lisa_support;
CREATE USER mike_analyst;
GRANT analyst_role TO mike_analyst;
CREATE USER ethan_support_intern;
GRANT support_role, intern_role TO ethan_support_intern;
CREATE USER john_analyst_intern;
GRANT analyst_role, intern_role TO john_analyst_intern;
```
Sebagai magang (masking ketat):
```
SET ROLE sarah_intern;
SELECT * FROM hr.employees;
id | name | email | ssn | salary
----+------------+------------------------+-------------+--------
1 | ******** | XXXXXXXX@XXXXXXX.com | *********** | 0.00
2 | ********** | XXXXXXXXXX@XXXXXXX.com | *********** | 0.00
```
Sebagai pengguna pendukung (masking moderat):
```
SET ROLE lisa_support;
SELECT * FROM hr.employees;
id | name | email | ssn | salary
----+------------+------------------------+-------------+--------
1 | John Doe | ########@#######.com | XXX-XX-6789 | 0.00
2 | Jane Smith | ##########@#######.com | XXX-XX-4321 | 0.00
```
Sebagai seorang analis (masking paling ringan):
```
SET ROLE mike_analyst;
SELECT * FROM hr.employees;
id | name | email | ssn | salary
----+------------+------------------------+-------------+----------
1 | John Doe | john.doe@example.com | XXX-XX-6789 | 45000.00
2 | Jane Smith | jane.smith@example.com | XXX-XX-4321 | 54000.00
```
Sebagai pengguna ethan\$1support\$1intern yang merupakan pengguna magang dan mendukung:
```
SET ROLE ethan_support_intern;
-- masking policies appliable to this user: employee_mask_strict and employee_mask_moderate
-- id : unmasked because no masking policy appliable on ethan_support_intern
-- masks these columns
-- name : masked because of employee_mask_strict policy
-- email, ssn, salary : both employee_mask_strict and employee_mask_moderate mask these columns
-- but employee_mask_moderate will be use because of higher weight
SELECT * FROM hr.employees;
id | name | email | ssn | salary
----+------------+------------------------+-------------+--------
1 | ******** | ########@#######.com | XXX-XX-6789 | 0.00
2 | ********** | ##########@#######.com | XXX-XX-4321 | 0.00
```
Sebagai john\$1analyst\$1intern yang merupakan magang dan analis:
```
SET ROLE john_analyst_intern;
-- masking policies appliable to this user: employee_mask_strict and employee_mask_light
-- id : unmasked because no masking policy appliable on john_analyst_intern
-- masks these columns
-- name, email : masked because of employee_mask_strict
-- ssn, salary : both employee_mask_strict and employee_mask_light mask these columns
-- but employee_mask_light will be use because of higher weight
SELECT * FROM hr.employees;
id | name | email | ssn | salary
----+------------+------------------------+-------------+----------
1 | ******** | XXXXXXXX@XXXXXXX.com | XXX-XX-6789 | 45000.00
2 | ********** | XXXXXXXXXX@XXXXXXX.com | XXX-XX-4321 | 54000.00
```
# Memahami perilaku masking dalam operasi DHTML
`pg_columnmask`berlaku secara konsisten di semua operasi DHTML, termasuk pernyataan INSERT, UPDATE, DELETE, dan MERGE. Saat Anda menjalankan operasi ini, Aurora PostgreSQL menutupi data sesuai dengan prinsip inti — data apa pun yang dibaca dari penyimpanan ditutupi sesuai dengan kebijakan yang berlaku pengguna saat ini.
Masking mempengaruhi beberapa komponen query berikut seperti:
+ Klausul WHERE
+ Ketentuan BERGABUNG
+ Subkueri
+ Klausul PENGEMBALIAN
Semua komponen ini beroperasi pada nilai bertopeng, bukan data asli. Sementara data ditulis ke penyimpanan tanpa kedok, pengguna hanya melihat tampilan bertopeng mereka saat membacanya kembali.
Aurora PostgreSQL memberlakukan semua kendala database (BUKAN NULL, UNIQUE, CHECK, FOREIGN KEY) pada nilai tersimpan aktual, bukan nilai bertopeng. Ini kadang-kadang dapat menciptakan inkonsistensi yang nyata jika fungsi masking tidak dirancang dengan hati-hati.
Masking berfungsi bersama izin tingkat kolom:
+ Pengguna tanpa hak SELECT tidak dapat membaca kolom
+ Pengguna dengan hak istimewa SELECT melihat nilai bertopeng sesuai dengan kebijakan yang berlaku
# Memahami perilaku masking dalam fungsi pemicu
Ketika `pg_columnmask` kebijakan diterapkan ke tabel, penting untuk memahami bagaimana masking berinteraksi dengan fungsi pemicu. Pemicu adalah fungsi database yang dijalankan secara otomatis sebagai respons terhadap peristiwa tertentu di atas meja, seperti operasi INSERT, UPDATE, atau DELETE.
Secara default, DDM menerapkan aturan masking yang berbeda tergantung pada jenis pemicu:
Pemicu tabel
**Tabel transisi dibuka kedoknya** - Fungsi pemicu pada tabel memiliki akses ke data yang dibuka kedok dalam tabel transisi mereka untuk versi baris lama dan baru
Pemilik tabel membuat pemicu dan memiliki data, sehingga mereka memiliki akses penuh untuk mengelola tabel mereka secara efektif
Lihat Pemicu (BUKAN Pemicu)
**Tabel transisi disamarkan** - Fungsi pemicu pada tampilan melihat data bertopeng sesuai dengan izin pengguna saat ini
Pemilik tampilan mungkin berbeda dari pemilik tabel dasar dan harus menghormati kebijakan masking pada tabel yang mendasarinya
Dua parameter konfigurasi tingkat server mengontrol perilaku pemicu dengan tabel bertopeng. Ini hanya dapat diatur oleh`rds_superuser`:
+ **Batasi Pemicu pada Tabel Bertopeng** — Mencegah eksekusi pemicu saat pengguna bertopeng melakukan operasi DHTML pada tabel dengan kebijakan masking yang berlaku.
+ **Batasi Pemicu pada Tampilan dengan Tabel Bertopeng:** — Mencegah eksekusi pemicu pada tampilan saat definisi tampilan menyertakan tabel dengan kebijakan masking yang berlaku untuk pengguna saat ini.
**Example perbedaan antara aplikasi fungsi ke tabel dan tampilan**
Contoh berikut menciptakan fungsi pemicu yang mencetak nilai baris lama dan baru, kemudian menunjukkan bagaimana fungsi yang sama berperilaku berbeda ketika dilampirkan ke tabel versus tampilan.
```
-- Create trigger function
CREATE OR REPLACE FUNCTION print_changes()
RETURNS TRIGGER AS
$$
BEGIN
RAISE NOTICE 'Old row: name=%, email=%, ssn=%, salary=%',
OLD.name, OLD.email, OLD.ssn, OLD.salary;
RAISE NOTICE 'New row: name=%, email=%, ssn=%, salary=%',
NEW.name, NEW.email, NEW.ssn, NEW.salary;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
-- Create trigger
CREATE TRIGGER print_changes_trigger
BEFORE UPDATE ON hr.employees
FOR EACH ROW
EXECUTE FUNCTION print_changes();
-- Grant update to analyst role
GRANT UPDATE ON hr.employees TO analyst_role;
-- Unmasked data must be seen inside trigger even for masked user for the OLD and NEW
-- row passed to trigger function
BEGIN;
SET ROLE mike_analyst;
UPDATE hr.employees SET id = id + 10 RETURNING *;
NOTICE: Old row: name=John Doe, email=john.doe@example.com, ssn=123-45-6789, salary=50000.00
NOTICE: New row: name=John Doe, email=john.doe@example.com, ssn=123-45-6789, salary=50000.00
NOTICE: Old row: name=Jane Smith, email=jane.smith@example.com, ssn=987-65-4321, salary=60000.00
NOTICE: New row: name=Jane Smith, email=jane.smith@example.com, ssn=987-65-4321, salary=60000.00
id | name | email | ssn | salary
----+------------+------------------------+-------------+----------
11 | John Doe | john.doe@example.com | XXX-XX-6789 | 45000.00
12 | Jane Smith | jane.smith@example.com | XXX-XX-4321 | 54000.00
(2 rows)
ROLLBACK;
-- Triggers on views (which are supposed to see masked data for new/old row)
CREATE VIEW hr.view_over_employees AS SELECT * FROM hr.employees;
GRANT UPDATE, SELECT ON hr.view_over_employees TO analyst_role;
-- Create trigger for this view
CREATE TRIGGER print_changes_trigger
INSTEAD OF UPDATE ON hr.view_over_employees
FOR EACH ROW
EXECUTE FUNCTION print_changes();
-- Masked new and old rows should be passed to trigger if trigger is on view
BEGIN;
SET ROLE mike_analyst;
UPDATE hr.view_over_employees SET id = id + 10 RETURNING *;
NOTICE: Old row: name=John Doe, email=john.doe@example.com, ssn=XXX-XX-6789, salary=45000.00
NOTICE: New row: name=John Doe, email=john.doe@example.com, ssn=XXX-XX-6789, salary=45000.00
NOTICE: Old row: name=Jane Smith, email=jane.smith@example.com, ssn=XXX-XX-4321, salary=54000.00
NOTICE: New row: name=Jane Smith, email=jane.smith@example.com, ssn=XXX-XX-4321, salary=54000.00
id | name | email | ssn | salary
----+------------+------------------------+-------------+----------
11 | John Doe | john.doe@example.com | XXX-XX-6789 | 45000.00
12 | Jane Smith | jane.smith@example.com | XXX-XX-4321 | 54000.00
(2 rows)
ROLLBACK;
```
Sebaiknya tinjau perilaku pemicu sebelum menerapkan pemicu pada tabel bertopeng. Pemicu tabel memiliki akses ke data yang dibuka kedok dalam tabel transisi, sementara pemicu tampilan melihat data bertopeng.
**Example mengganti nama kebijakan masking**
Contoh berikut menunjukkan cara mengganti nama kebijakan yang ada menggunakan prosedur. `rename_masking_policy`
```
-- Rename the strict policy
CALL pgcolumnmask.rename_masking_policy(
'employee_mask_strict',
'hr.employees',
'intern_protection_policy'
);
-- Verify the rename
SELECT policyname, roles, weight
FROM pgcolumnmask.pg_columnmask_policies
WHERE tablename = 'employees'
ORDER BY weight DESC;
policyname | roles | weight
--------------------------+----------------+--------
employee_mask_light | {analyst_role} | 100
employee_mask_moderate | {support_role} | 50
intern_protection_policy | {intern_role} | 10
```
**Example mengubah bobot kebijakan**
Contoh berikut menunjukkan bagaimana mengubah bobot kebijakan untuk mengubah bobotnya.
```
-- Change weight of moderate policy
CALL pgcolumnmask.alter_masking_policy(
'employee_mask_moderate'::NAME,
'hr.employees'::REGCLASS,
NULL, -- Keep existing masking expressions
NULL, -- Keep existing roles
75 -- New weight
);
-- Verify the changes
SELECT policyname, roles, weight
FROM pgcolumnmask.pg_columnmask_policies
WHERE tablename = 'employees'
ORDER BY weight DESC;
policyname | roles | weight
--------------------------+----------------+--------
employee_mask_light | {analyst_role} | 100
employee_mask_moderate | {support_role} | 75
intern_protection_policy | {intern_role} | 10
```
**Example membersihkan**
Contoh berikut menunjukkan bagaimana untuk menghapus semua kebijakan, tabel dan pengguna.
```
-- Drop policies
CALL pgcolumnmask.drop_masking_policy(
'intern_protection_policy',
'hr.employees'
);
CALL pgcolumnmask.drop_masking_policy(
'employee_mask_moderate',
'hr.employees'
);
CALL pgcolumnmask.drop_masking_policy(
'employee_mask_light',
'hr.employees'
);
-- Drop table and functions
DROP VIEW IF EXISTS hr.view_over_employees;
DROP TABLE IF EXISTS hr.employees;
DROP SCHEMA IF EXISTS hr;
DROP FUNCTION IF EXISTS public.mask_ssn(text);
DROP FUNCTION IF EXISTS public.mask_salary(numeric, numeric);
-- Drop users
DROP USER sarah_intern, lisa_support, mike_analyst,
ethan_support_intern, john_analyst_intern;
DROP ROLE intern_role, support_role, analyst_role;
```
# Mengkonfigurasi peran manajemen kebijakan masking
Ekstensi masking kolom PostgreSQL`pg_columnmask`, memungkinkan Anda untuk mendelegasikan pengelolaan kebijakan masking ke peran tertentu, bukan mewajibkan atau hak istimewa pemilik tabel. `rds_superuser` Ini memberikan kontrol yang lebih terperinci atas siapa yang dapat membuat, mengubah, dan menjatuhkan kebijakan masking.
Untuk mengonfigurasi peran yang akan memiliki hak istimewa pengelolaan kebijakan masking, ikuti langkah-langkah berikut:
1. Membuat peran admin kebijakan — Sebagai`rds_superuser`, buat peran baru yang bertanggung jawab untuk mengelola kebijakan masking:
```
CREATE ROLE mask_admin NOLOGIN;
```
1. Konfigurasikan parameter PostgreSQL - Di grup parameter cluster DB kustom Anda, atur `pgcolumnmask.policy_admin_rolname` parameter konfigurasi engine ke nama peran yang Anda buat:
```
pgcolumnmask.policy_admin_rolname = mask_admin
```
Parameter konfigurasi mesin ini dapat diatur dalam grup parameter cluster DB dan tidak memerlukan reboot instance. Untuk detail tentang memperbarui parameter, lihat[Memodifikasi parameter dalam grup parameter cluster DB di Amazon Aurora](USER_WorkingWithParamGroups.ModifyingCluster.md).
1. Berikan peran kepada pengguna Sebagai`rds_superuser`, berikan `mask_admin` peran tersebut kepada pengguna yang seharusnya dapat mengelola kebijakan masking:
```
CREATE USER alice LOGIN;
CREATE USER bob LOGIN;
GRANT mask_admin TO alice, bob;
```
Selain itu, pastikan bahwa pengguna memiliki hak istimewa PENGGUNAAN pada skema tempat mereka akan mengelola kebijakan masking:
```
GRANT USAGE ON SCHEMA hr TO alice, bob;
```
Sekarang, ketika pengguna `alice` dan `bob` terhubung ke database, mereka dapat menggunakan fungsi `pg_columnmask` ekstensi standar untuk membuat, mengubah, dan menghapus kebijakan masking pada semua tabel di semua skema di mana mereka memiliki `USAGE` hak istimewa pada skema.
# Praktik terbaik untuk implementasi pg\$1columnmask yang aman
Bagian berikut menyediakan praktik terbaik keamanan untuk diterapkan `pg_columnmask` di lingkungan Aurora PostgreSQL Anda. Ikuti rekomendasi ini untuk:
+ Membangun arsitektur kontrol akses berbasis peran yang aman
+ Kembangkan fungsi masking yang mencegah kerentanan keamanan
+ Memahami dan mengontrol perilaku pemicu dengan data bertopeng
## Arsitektur keamanan berbasis peran
Tentukan hierarki peran untuk mengimplementasikan kontrol akses dalam database Anda. Aurora PostgreSQL `pg_columnmask` menambah kontrol ini dengan menyediakan lapisan tambahan untuk penyembunyian data berbutir halus dalam peran tersebut.
Buat peran khusus yang selaras dengan fungsi organisasi daripada memberikan izin kepada pengguna individu. Pendekatan ini memberikan auditabilitas yang lebih baik dan menyederhanakan manajemen izin saat struktur organisasi Anda berkembang.
**Example Menciptakan Heirarki Peran Organisasi**
Contoh berikut membuat hierarki peran organisasi dengan peran khusus untuk fungsi yang berbeda, kemudian menetapkan pengguna individu ke peran yang sesuai. Dalam contoh ini, peran organisasi (analyst\$1role, support\$1role) dibuat terlebih dahulu, kemudian pengguna individu diberikan keanggotaan dalam peran ini. Struktur ini memungkinkan Anda mengelola izin di tingkat peran, bukan untuk setiap pengguna individu.
```
-- Create organizational role hierarchy
CREATE ROLE data_admin_role;
CREATE ROLE security_admin_role;
CREATE ROLE analyst_role;
CREATE ROLE support_role;
CREATE ROLE developer_role;
-- Specify security_admin_role as masking policy manager in the DB cluster parameter
-- group pgcolumnmask.policy_admin_rolname = 'security_admin_role'
-- Create specific users and assign to appropriate roles
CREATE USER security_manager;
CREATE USER data_analyst1, data_analyst2;
CREATE USER support_agent1, support_agent2;
GRANT security_admin_role TO security_manager;
GRANT analyst_role TO data_analyst1, data_analyst2;
GRANT support_role TO support_agent1, support_agent2;
```
Menerapkan prinsip hak istimewa terkecil dengan hanya memberikan izin minimum yang diperlukan untuk setiap peran. Hindari pemberian izin luas yang dapat dieksploitasi jika kredensyal dikompromikan.
```
-- Grant specific table permissions rather than schema-wide access
GRANT SELECT ON sensitive_data.customers TO analyst_role;
GRANT SELECT ON sensitive_data.transactions TO analyst_role;
-- Do not grant: GRANT ALL ON SCHEMA sensitive_data TO analyst_role;
```
Administrator kebijakan memerlukan `USAGE` hak istimewa pada skema tempat mereka mengelola kebijakan penyembunyian. Berikan hak istimewa ini secara selektif, mengikuti prinsip hak istimewa paling sedikit. Lakukan tinjauan reguler atas izin akses skema untuk memastikan hanya personel yang berwenang yang mempertahankan kemampuan manajemen kebijakan.
Konfigurasi parameter peran admin kebijakan dibatasi hanya untuk administrator database. Parameter ini tidak dapat diubah pada tingkat basis data atau sesi, mencegah pengguna yang tidak memiliki hak istimewa untuk mengganti penetapan admin kebijakan. Pembatasan ini memastikan bahwa kontrol kebijakan masking tetap terpusat dan aman.
Tetapkan peran admin kebijakan untuk individu tertentu, bukan grup. Pendekatan yang ditargetkan ini memastikan akses selektif ke manajemen kebijakan masking, karena administrator kebijakan memiliki kemampuan untuk menutupi semua tabel dalam database.
## Pengembangan fungsi masking yang aman
Kembangkan fungsi masking menggunakan semantik pengikatan awal untuk memastikan pelacakan ketergantungan yang tepat dan mencegah kerentanan pengikatan yang terlambat seperti modifikasi jalur pencarian selama runtime. Disarankan untuk menggunakan `BEGIN ATOMIC` sintaks untuk fungsi SQL untuk mengaktifkan validasi waktu kompilasi (yaitu pengikatan awal) dan manajemen ketergantungan.
```
-- Example - Secure masking function with early binding
CREATE OR REPLACE FUNCTION secure_mask_ssn(input_ssn TEXT)
RETURNS TEXT
LANGUAGE SQL
IMMUTABLE PARALLEL SAFE STRICT
BEGIN ATOMIC
SELECT CASE
WHEN input_ssn IS NULL THEN NULL
WHEN length(input_ssn) < 4 THEN repeat('X', length(input_ssn))
ELSE repeat('X', length(input_ssn) - 4) || right(input_ssn, 4)
END;
END;
```
Atau, buat fungsi yang kebal terhadap perubahan jalur pencarian dengan skema eksplisit yang memenuhi syarat semua referensi objek, memastikan perilaku yang konsisten di seluruh sesi pengguna yang berbeda.
```
-- Function immune to search path changes
CREATE OR REPLACE FUNCTION data_masking.secure_phone_mask(phone_number TEXT)
RETURNS TEXT
LANGUAGE SQL
IMMUTABLE PARALLEL SAFE STRICT
AS $$
SELECT CASE
WHEN phone_number IS NULL THEN NULL
WHEN public.length(public.regexp_replace(phone_number, '[^0-9]', '', 'g')) < 10 THEN 'XXX-XXX-XXXX'
ELSE public.regexp_replace(
phone_number,
'([0-9]{3})[0-9]{3}([0-9]{4})',
public.concat('\1-XXX-\2')
)
END;
$$;
```
Terapkan validasi input dalam fungsi masking untuk menangani kasus tepi dan mencegah perilaku yang tidak terduga. Selalu sertakan penanganan NULL dan validasi format input untuk memastikan perilaku masking yang konsisten.
```
-- Robust masking function with comprehensive input validation
CREATE OR REPLACE FUNCTION secure_mask_phone(phone_number TEXT)
RETURNS TEXT
LANGUAGE SQL
IMMUTABLE PARALLEL SAFE STRICT
BEGIN ATOMIC
SELECT CASE
WHEN phone_number IS NULL THEN NULL
WHEN length(trim(phone_number)) = 0 THEN phone_number
WHEN length(regexp_replace(phone_number, '[^0-9]', '', 'g')) < 10 THEN 'XXX-XXX-XXXX'
ELSE regexp_replace(phone_number, '([0-9]{3})[0-9]{3}([0-9]{4})', '\1-XXX-\2')
END;
END;
```
## DMLMemicu perilaku dengan pg\$1columnmask
Untuk pemicu tabel, tabel transisi akan sepenuhnya dibuka kedoknya. Untuk pemicu tampilan (IOT), tabel transisi akan disamarkan sesuai dengan izin tampilan pengguna saat ini.
Pemicu tabel dengan pg\$1columnmask
Pemicu dilewatkan tabel transisi yang berisi versi lama dan baru dari baris yang dimodifikasi oleh query DMLnya. Tergantung pada kapan pemicu diaktifkan, Aurora PostgreSQL mengisi baris lama dan baru. Misalnya, `BEFORE INSERT` pemicu hanya memiliki versi baru dari baris dan versi lama kosong karena tidak ada versi lama untuk dirujuk.
`pg_columnmask`tidak menutupi tabel transisi di dalam pemicu pada tabel. Pemicu dapat menggunakan kolom bertopeng di dalam tubuh mereka dan melihat data yang dibuka kedoknya. Pembuat pemicu harus memastikan bagaimana pemicu dieksekusi untuk pengguna. Contoh berikut berfungsi dengan benar dalam kasus ini.
```
-- Example for table trigger uses masked column in its definition
-- Create a table and insert some rows
CREATE TABLE public.credit_card_table (
name TEXT,
credit_card_no VARCHAR(16),
is_fraud BOOL
);
INSERT INTO public.credit_card_table (name, credit_card_no, is_fraud)
VALUES
('John Doe', '4532015112830366', false),
('Jane Smith', '5410000000000000', true),
('Brad Smith', '1234567891234567', true);
-- Create a role which will see masked data and grant it privileges
CREATE ROLE intern_user;
GRANT SELECT, DELETE ON public.credit_card_table TO intern_user;
-- Trigger which will silenty skip delete of non fraudelent credit cards
CREATE OR REPLACE FUNCTION prevent_non_fraud_delete()
RETURNS TRIGGER AS
$$
BEGIN
IF OLD.is_fraud = false THEN
RETURN NULL;
END IF;
RETURN OLD;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER prevent_non_fraud_delete
BEFORE DELETE ON credit_card_table
FOR EACH ROW
EXECUTE FUNCTION prevent_non_fraud_delete();
CREATE OR REPLACE FUNCTION public.return_false()
RETURNS BOOLEAN
LANGUAGE SQL
IMMUTABLE PARALLEL SAFE STRICT
BEGIN ATOMIC
SELECT false;
END;
-- A masking policy that masks both credit card number and is_fraud column.
-- If we apply masking inside trigger then prevent_non_fraud_delete trigger will
-- allow deleting more rows to masked user (even non fraud ones).
CALL pgcolumnmask.create_masking_policy(
'mask_credit_card_no_&_is_fraud'::NAME,
'public.credit_card_table'::REGCLASS,
JSON_BUILD_OBJECT('credit_card_no', 'pgcolumnmask.mask_text(credit_card_no)',
'is_fraud', 'public.return_false()')::JSONB,
ARRAY['intern_user']::NAME[],
10::INT
);
-- Test trigger behaviour using intern_user
BEGIN;
SET ROLE intern_user;
-- credit card number & is_fraud is completely masked from intern_user
SELECT * FROM public.credit_card_table;
name | credit_card_no | is_fraud
------------+------------------+----------
John Doe | XXXXXXXXXXXXXXXX | f
Jane Smith | XXXXXXXXXXXXXXXX | f
Brad Smith | XXXXXXXXXXXXXXXX | f
(3 rows)
-- The delete trigger lets the intern user delete rows for Jane and Brad even though
-- intern_user sees their is_fraud = false, but the table trigger works with original
-- unmasked value
DELETE FROM public.credit_card_table RETURNING *;
name | credit_card_no | is_fraud
------------+------------------+----------
Jane Smith | XXXXXXXXXXXXXXXX | f
Brad Smith | XXXXXXXXXXXXXXXX | f
(2 rows)
COMMIT;
```
Pembuat pemicu membocorkan data yang dibuka kedok ke pengguna jika mereka tidak berhati-hati dengan pernyataan yang mereka gunakan di badan pemicu mereka. Misalnya menggunakan `RAISE NOTICE ‘%’, masked_column;` cetakan kolom untuk pengguna saat ini.
```
-- Example showing table trigger leaking column value to current user
CREATE OR REPLACE FUNCTION leaky_trigger_func()
RETURNS TRIGGER AS
$$
BEGIN
RAISE NOTICE 'Old credit card number was: %', OLD.credit_card_no;
RAISE NOTICE 'New credit card number is %', NEW.credit_card_no;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER leaky_trigger
AFTER UPDATE ON public.credit_card_table
FOR EACH ROW
EXECUTE FUNCTION leaky_trigger_func();
-- Grant update on column is_fraud to auditor role
-- auditor will NOT HAVE PERMISSION TO READ DATA
CREATE ROLE auditor;
GRANT UPDATE (is_fraud) ON public.credit_card_table TO auditor;
-- Also add auditor role to existing masking policy on credit card table
CALL pgcolumnmask.alter_masking_policy(
'mask_credit_card_no_&_is_fraud'::NAME,
'public.credit_card_table'::REGCLASS,
NULL::JSONB,
ARRAY['intern_user', 'auditor']::NAME[],
NULL::INT
);
-- Log in as auditor
-- [auditor]
-- Update will fail if trying to read data from the table
UPDATE public.credit_card_table
SET is_fraud = true
WHERE credit_card_no = '4532015112830366';
ERROR: permission denied for table cc_table
-- [auditor]
-- But leaky update trigger will still print the entire row even though
-- current user does not have permission to select from public.credit_card_table
UPDATE public.credit_card_table SET is_fraud = true;
NOTICE: Old credit_card_no was: 4532015112830366
NOTICE: New credit_card_no is 4532015112830366
```
Pemicu tampilan dengan pg\$1columnmask (Alih-alih pemicu)
Pemicu hanya dapat dibuat pada tampilan di PostgreSQL. Mereka digunakan untuk menjalankan pernyataan DHTML pada tampilan yang tidak dapat diperbarui. Tabel transit selalu tertutup di dalam bukan pemicu (IOT), karena tampilan dan tabel dasar yang digunakan di dalam kueri tampilan dapat memiliki pemilik yang berbeda. Dalam hal ini, tabel dasar mungkin memiliki beberapa kebijakan masking yang berlaku pada pemilik tampilan dan pemilik tampilan harus selalu melihat data bertopeng dari tabel dasar di dalam pemicunya. Ini berbeda dari pemicu pada tabel karena dalam hal ini pembuat pemicu dan data di dalam tabel dimiliki oleh pengguna yang sama yang tidak terjadi di sini.
```
-- Create a view over credit card table
CREATE OR REPLACE VIEW public.credit_card_view
AS
SELECT * FROM public.credit_card_table;
-- Truncate credit card table and insert fresh data
TRUNCATE TABLE public.credit_card_table;
INSERT INTO public.credit_card_table (name, credit_card_no, is_fraud)
VALUES
('John Doe', '4532015112830366', false),
('Jane Smith', '5410000000000000', true),
('Brad Smith', '1234567891234567', true);
CREATE OR REPLACE FUNCTION public.print_changes()
RETURNS TRIGGER AS
$$
BEGIN
RAISE NOTICE 'Old row: name=%, credit card number=%, is fraud=%',
OLD.name, OLD.credit_card_no, OLD.is_fraud;
RAISE NOTICE 'New row: name=%, credit card number=%, is fraud=%',
NEW.name, NEW.credit_card_no, NEW.is_fraud;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER print_changes_trigger
INSTEAD OF UPDATE ON public.credit_card_view
FOR EACH ROW
EXECUTE FUNCTION public.print_changes();
GRANT SELECT, UPDATE ON public.credit_card_view TO auditor;
-- [auditor]
-- Login as auditor role
BEGIN;
-- Any data coming out from the table will be masked in instead of triggers
-- according to masking policies applicable to current user
UPDATE public.credit_card_view
SET name = CONCAT(name, '_new_name')
RETURNING *;
NOTICE: Old row: name=John Doe, credit card number=XXXXXXXXXXXXXXXX, is fraud=f
NOTICE: New row: name=John Doe_new_name, credit card number=XXXXXXXXXXXXXXXX, is fraud=f
NOTICE: Old row: name=Jane Smith, credit card number=XXXXXXXXXXXXXXXX, is fraud=f
NOTICE: New row: name=Jane Smith_new_name, credit card number=XXXXXXXXXXXXXXXX, is fraud=f
NOTICE: Old row: name=Brad Smith, credit card number=XXXXXXXXXXXXXXXX, is fraud=f
NOTICE: New row: name=Brad Smith_new_name, credit card number=XXXXXXXXXXXXXXXX, is fraud=f
name | credit_card_no | is_fraud
---------------------+------------------+----------
John Doe_new_name | XXXXXXXXXXXXXXXX | f
Jane Smith_new_name | XXXXXXXXXXXXXXXX | f
Brad Smith_new_name | XXXXXXXXXXXXXXXX | f
-- Any new data going into the table using INSERT or UPDATE command will be unmasked
UPDATE public.credit_card_view
SET credit_card_no = '9876987698769876'
RETURNING *;
NOTICE: Old row: name=John Doe, credit card number=XXXXXXXXXXXXXXXX, is fraud=f
NOTICE: New row: name=John Doe, credit card number=9876987698769876, is fraud=f
NOTICE: Old row: name=Jane Smith, credit card number=XXXXXXXXXXXXXXXX, is fraud=f
NOTICE: New row: name=Jane Smith, credit card number=9876987698769876, is fraud=f
NOTICE: Old row: name=Brad Smith, credit card number=XXXXXXXXXXXXXXXX, is fraud=f
NOTICE: New row: name=Brad Smith, credit card number=9876987698769876, is fraud=f
name | credit_card_no | is_fraud
------------+------------------+----------
John Doe | 9876987698769876 | f
Jane Smith | 9876987698769876 | f
Brad Smith | 9876987698769876 | f
COMMIT;
```
Database/Tingkat pengguna GuCs untuk mengontrol perilaku pemicu
Dua parameter konfigurasi mengontrol perilaku eksekusi pemicu bagi pengguna dengan kebijakan masking yang berlaku. Gunakan parameter ini untuk mencegah pemicu mengeksekusi pada tabel atau tampilan bertopeng saat pembatasan keamanan tambahan diperlukan. Kedua parameter dinonaktifkan secara default, memungkinkan pemicu untuk dijalankan secara normal.
**GUC Pertama: Memicu pembatasan penembakan pada tabel bertopeng**
Spesifikasi:
+ Nama: `pgcolumnmask.restrict_dml_triggers_for_masked_users`
+ Tipe: `boolean`
+ Default: `false` (pemicu diizinkan untuk dieksekusi)
Mencegah eksekusi pemicu pada tabel bertopeng untuk pengguna bertopeng saat disetel ke TRUE. `pg_columnmask`berjalan melalui kesalahan.
**GUC Kedua: Memicu pembatasan penembakan pada tampilan dengan tabel bertopeng**
Spesifikasi:
+ Nama: `pgcolumnmask.restrict_iot_triggers_for_masked_users`
+ Tipe: `boolean`
+ Default: `false` (pemicu diizinkan untuk dieksekusi)
Mencegah eksekusi pemicu pada tampilan yang menyertakan tabel bertopeng dalam definisinya untuk pengguna bertopeng saat disetel ke TRUE.
Parameter ini beroperasi secara independen dan dapat dikonfigurasi seperti parameter konfigurasi basis data standar.
# Skenario pergerakan data Aurora PostgreSQL pg\$1columnmask
`pg_columnmask`perilaku bervariasi di seluruh operasi pergerakan data yang berbeda tergantung pada apakah operasi terjadi pada lapisan penyimpanan, logis, atau aplikasi. Operasi tingkat penyimpanan (seperti kloning) berperilaku berbeda dari operasi logis (seperti`pg_dump`) dan operasi tingkat aplikasi (seperti kueri FDW). Bagian ini menjelaskan perilaku penyembunyian untuk skenario umum termasuk replikasi, pencadangan, ekspor, dan migrasi, dan menjelaskan implikasi keamanan untuk masing-masing skenario.
**Topics**
+ [Database Global Aurora dan Baca Replika](#AuroraPostgreSQL.Security.DynamicMasking.DataMovement.RR)
+ [Kloning basis data dan pemulihan snapshot](#AuroraPostgreSQL.Security.DynamicMasking.DataMovement.Clones)
+ [Replikasi logis](#AuroraPostgreSQL.Security.DynamicMasking.DataMovement.LogRep)
+ [Deployment Biru/Hijau](#AuroraPostgreSQL.Security.DynamicMasking.DataMovement.BlueGreen)
+ [Aliran nol-ETL dan CDC](#AuroraPostgreSQL.Security.DynamicMasking.DataMovement.ZETL)
+ [AWS Database Migration Service](#AuroraPostgreSQL.Security.DynamicMasking.DataMovement.DMS)
+ [Ekspor data](#AuroraPostgreSQL.Security.DynamicMasking.DataMovement.DataExport)
+ [Tampilan dan tampilan terwujud](#AuroraPostgreSQL.Security.DynamicMasking.DataMovement.Views)
+ [Pembuangan dan pemulihan data](#AuroraPostgreSQL.Security.DynamicMasking.DataMovement.DDR)
+ [Pembungkus data asing](#AuroraPostgreSQL.Security.DynamicMasking.DataMovement.FDQ)
## Database Global Aurora dan Baca Replika
`pg_columnmask`Kebijakan Aurora disimpan dalam tabel sistem database dalam volume cluster. Semua replika mengakses kebijakan yang sama dan mengembalikan hasil yang disamarkan secara konsisten. Untuk penerapan Aurora Global Database, `pg_columnmask` kebijakan mereplikasi ke sekunder Wilayah AWS bersama dengan tabel sistem database lainnya, memastikan perlindungan data yang konsisten di seluruh wilayah. Selama skenario failover, semua `pg_columnmask` kebijakan tetap utuh dan fungsional.
## Kloning basis data dan pemulihan snapshot
Operasi Aurora Fast Clone dan snapshot restore mempertahankan semua `pg_columnmask` kebijakan, peran, dan konfigurasi sebagai bagian dari tabel sistem database. Database yang dikloning atau dipulihkan mewarisi semua kebijakan yang ada dari kluster sumber. Setelah kloning atau restorasi, setiap cluster database mempertahankan `pg_columnmask` kebijakan independen.
## Replikasi logis
Selama sinkronisasi awal, replikasi logis menggunakan operasi SQL COPY standar, dan `pg_columnmask` kebijakan diberlakukan berdasarkan izin pengguna replikasi. Selama CDC (perubahan pengambilan data) yang sedang berlangsung, kebijakan masking tidak diterapkan dan data yang dibuka kedoknya direplikasi melalui catatan WAL. Pengguna dengan `pg_create_subscription` hak istimewa berpotensi mengeksfiltrasi data yang dibuka kedok dengan menyiapkan replikasi ke sistem yang mereka kendalikan.
## Deployment Biru/Hijau
Selama restorasi snapshot, `pg_columnmask` kebijakan secara otomatis disertakan. Lingkungan hijau dimulai dengan salinan identik dari semua kebijakan dari lingkungan biru. Selama replikasi dari biru ke hijau, data tidak disamarkan. Perubahan kebijakan masking berikutnya (perintah DDL) pada cluster biru tidak bereplikasi ke cluster hijau dan membatalkan penerapan RDS. blue/green
## Aliran nol-ETL dan CDC
Replikasi data tidak terpengaruh oleh `pg_columnmask` kebijakan. Zero-ETL mendukung replikasi DDL tetapi tidak mereplikasi atau kebijakan RLS. `pg_columnmask` Tidak ada kebijakan masking yang diterapkan pada data yang direplikasi di Zero-ETL.
## AWS Database Migration Service
Sinkronisasi data awal disamarkan atau dibuka kedok berdasarkan pengguna yang dipilih untuk tugas DMS. Data CDC selalu dibuka kedoknya. Meskipun kebijakan RLS internal `pg_columnmask` terkait dapat dimigrasikan, kebijakan tersebut tidak akan berfungsi pada target non-pg\$1columnmask-enabled.
## Ekspor data
`pg_columnmask`memperlakukan ekspor seperti operasi kueri lainnya—masking diterapkan berdasarkan izin pengguna yang mengeksekusi. Ini berlaku untuk perintah SQL seperti COPY, SELECT INTO, CREATE TABLE AS, dan fungsi ekspor S3 Aurora PostgreSQL.
**catatan**
Saat pengguna bertopeng mengekspor data, file yang dihasilkan berisi nilai bertopeng yang dapat melanggar batasan basis data saat dipulihkan.
## Tampilan dan tampilan terwujud
Ingatlah pertimbangan berikut saat menggunakan tampilan:
+ **Tampilan reguler** — Selalu gunakan `INVOKER` semantik. Kebijakan masking pengguna saat ini berlaku saat menanyakan tampilan, terlepas dari siapa yang membuat tampilan.
+ **Tampilan terwujud** — Saat disegarkan, kebijakan penyembunyian pemilik tampilan terwujud berlaku, bukan kebijakan pengguna yang melakukan penyegaran. Jika pemilik memiliki kebijakan penyembunyian, tampilan terwujud selalu berisi data bertopeng.
## Pembuangan dan pemulihan data
`pg_dump`beroperasi sebagai pengguna database reguler dan menerapkan kebijakan masking berdasarkan izin pengguna yang menghubungkan. Jika pengguna bertopeng melakukan dump, file cadangan berisi data bertopeng. `pg_columnmask`kebijakan termasuk dalam dump sebagai bagian dari skema database. Restorasi yang berhasil mengharuskan semua peran yang direferensikan ada di database target dan bahwa target memiliki `pg_columnmask` ekstensi yang diinstal.
**catatan**
Dimulai dengan PostgreSQL 18`pg_dump`, mendukung `—no-policies` opsi yang mengecualikan kebijakan Row Level Security (RLS) dan masking dari dump database. `pg_columnmask` Untuk informasi selengkapnya, lihat [pg\$1dump](https://www.postgresql.org/docs/current/app-pgdump.html).
## Pembungkus data asing
Saat menggunakan pembungkus data asing, kebijakan masking pada tabel jarak jauh diterapkan berdasarkan izin pengguna yang dipetakan di server sumber, bukan izin pengguna kueri lokal, dan meskipun Anda dapat mengakses data jarak jauh bertopeng melalui FDW, Anda tidak dapat membuat kebijakan DDM atau RLS secara langsung pada tabel asing di database lokal Anda.