Hak Istimewa PostgreSQL &Manajemen Pengguna - Yang Harus Anda Ketahui

Manajemen pengguna dalam PostgreSQL bisa jadi rumit. Biasanya pengguna baru dikelola, bersama-sama, dalam beberapa area utama di lingkungan. Seringkali, hak istimewa sempurna di satu sisi, namun dikonfigurasi dengan tidak benar di sisi lain. Posting blog ini akan memberikan 'Tips dan Trik' praktis untuk pengguna atau peran, seperti yang akan kita ketahui, pengaturan dalam PostgreSQL.

Area subjek yang akan kami fokuskan adalah:

• Pengambilan Peran PostgreSQL

Anda akan mempelajari tentang peran, atribut peran, praktik terbaik untuk memberi nama peran Anda, dan penyiapan peran umum.

• File pg_hba.conf

Di bagian ini kita akan melihat salah satu file kunci dan pengaturannya, untuk koneksi sisi klien dan komunikasi dengan server.

• Hak istimewa dan batasan tingkat Database, Tabel, dan Kolom.

Ingin mengonfigurasi peran untuk kinerja dan penggunaan yang optimal? Apakah tabel Anda berisi data sensitif, hanya dapat diakses oleh peran istimewa? Namun dengan kebutuhan untuk mengizinkan peran yang berbeda untuk melakukan pekerjaan yang terbatas? Pertanyaan-pertanyaan ini dan lebih banyak lagi akan diungkapkan di bagian ini.

Pengambilan Peran PostgreSQL - Apa itu 'Peran' dan bagaimana cara membuatnya?

Izin untuk akses database dalam PostgreSQL ditangani dengan konsep peran, yang mirip dengan pengguna. Peran juga dapat mewakili grup pengguna di ekosistem PostgreSQL.

PostgreSQL menetapkan kapasitas peran untuk menetapkan hak istimewa ke objek database yang mereka miliki, memungkinkan akses dan tindakan ke objek tersebut. Peran memiliki kemampuan untuk memberikan keanggotaan ke peran lain. Atribut menyediakan opsi penyesuaian, untuk otentikasi klien yang diizinkan.

Atribut untuk peran melalui perintah CREATE ROLE, tersedia di dokumentasi resmi PostgreSQL.

Di bawah ini, adalah atribut yang biasanya Anda tetapkan saat menyiapkan peran baru. Sebagian besar dari ini cukup jelas. Namun, deskripsi singkat diberikan untuk menjernihkan kebingungan beserta contoh penggunaan.

SUPERUSER - Sebuah database SUPERUSER layak mendapat peringatan. Intinya, peran dengan atribut ini dapat membuat SUPERUSER lain. Sebenarnya, atribut ini diperlukan untuk membuat peran SUPERUSER lain. Karena peran dengan atribut ini mengabaikan semua pemeriksaan izin, berikan hak istimewa ini dengan bijaksana.

CREATEDB - Memungkinkan peran untuk membuat database.

CREATEROLE - Dengan atribut ini, peran dapat mengeluarkan perintah CREATE ROLE. Karenanya, buat peran lain.

LOGIN - Memungkinkan kemampuan untuk masuk. Nama peran dengan atribut ini dapat digunakan dalam perintah koneksi klien. Detail lebih lanjut tentang atribut ini dengan contoh yang akan datang.

Atribut tertentu memiliki perintah bernama berlawanan kutub yang eksplisit dan biasanya merupakan default ketika dibiarkan tidak ditentukan.

mis.
PENGGUNA SUPER | PENGGUNA NOSUPER
CREATEROL |NOCREATEROLE
LOGIN |NOLOGIN

Mari kita lihat beberapa atribut ini beraksi untuk berbagai konfigurasi yang dapat Anda siapkan untuk memulai.

Membuat Dan Menghapus Peran

Membuat peran relatif mudah. Berikut ini contoh singkatnya:

postgres=# CREATE ROLE $money_man;
ERROR: syntax error at or near "$"
LINE 1: CREATE ROLE $money_man;

Apa yang salah di sana? Ternyata, nama peran tidak boleh diawali dengan apa pun selain huruf.

"Bagaimana dengan membungkus nama dengan tanda kutip ganda?" Mari kita lihat:

postgres=# CREATE ROLE "$money_man";
CREATE ROLE

Itu berhasil, meskipun mungkin bukan ide yang bagus. Bagaimana dengan karakter khusus di tengah nama?

postgres=# CREATE ROLE money$_man;
CREATE ROLE

Tidak ada masalah di sana. Bahkan tanpa tanda kutip ganda, tidak ada kesalahan yang dikembalikan.

Saya hanya tidak menyukai struktur nama $money_man untuk pengguna. Saya memberikan Anda $money_man dan memulai dari awal. Perintah DROP ROLE menangani penghapusan peran. Ini dia sedang digunakan.

postgres=# DROP ROLE $money_man;
ERROR: syntax error at or near "$"
LINE 1: DROP ROLE $money_man;

Dan kesalahan lain dengan peran $money_man. Sekali lagi, gunakan tanda kutip ganda.

postgres=# DROP ROLE "$money_man";
DROP ROLE

Hak istimewa LOGIN

Mari kita lihat dua pengguna yang berbeda, satu dengan hak LOGIN dan satu tanpa. Saya akan memberikan mereka kata sandi juga.

postgres=# CREATE ROLE nolog_user WITH PASSWORD 'pass1';
CREATE ROLE

postgres=# CREATE ROLE log_user WITH LOGIN PASSWORD 'pass2';
CREATE ROLE

Catatan:Kata sandi yang diberikan untuk peran fiksi di atas hanya untuk tujuan demonstrasi. Anda harus selalu berusaha untuk memberikan kata sandi yang unik dan keras saat menerapkan peran. Meskipun kata sandi lebih baik daripada tidak ada kata sandi, kata sandi yang diperkeras bahkan lebih baik daripada kata sandi yang tidak penting.

Mari kita tetapkan log_user atribut CREATEDB dan CREATEROLE dengan perintah ALTER ROLE.

postgres=# ALTER ROLE log_user CREATEROLE CREATEDB;
ALTER ROLE

Anda dapat memverifikasi atribut yang ditetapkan ini, dengan memeriksa katalog pg_role. Dua kolom yang diminati adalah rolcreaterole dan rolcreatedb. Keduanya bertipe data Boolean sehingga harus disetel ke t untuk true untuk atribut ini.

Konfirmasikan dengan kueri SELECT serupa.

postgres=# SELECT rolcreaterole, rolcreatedb FROM pg_roles WHERE rolname = 'log_user';
rolcreaterole | rolcreatedb 
---------------+-------------
t | t
(1 row)

Bagaimana Anda bisa menentukan peran yang ada di database?

Dua metode yang tersedia adalah perintah psql \du atau memilih dari katalog pg_roles.

Di sini keduanya digunakan.

postgres=> \du
List of roles
Role name | Attributes | Member of 
------------+------------------------------------------------------------+-----------
log_user | Create role, Create DB | {}
nolog_user | Cannot login | {}

postgres=> SELECT rolname FROM pg_roles;
rolname 
----------------------
nolog_user
log_user
(2 rows)

Masuk

Mari kita beri kedua peran, kesempatan untuk masuk ke server.

psql -U nolog_user -W postgres
Password for user nolog_user: 
psql: FATAL: no pg_hba.conf entry for host "[local]", user "nolog_user", database "postgres", SSL off
psql -U log_user -W postgres
Password for user log_user: 
psql: FATAL: no pg_hba.conf entry for host "[local]", user "log_user", database "postgres", SSL off

Untuk mengatasi masalah ini, kita harus menggali file pg_hba.conf itu. Solusinya dibahas saat kami melanjutkan posting ini, ke bagian khusus itu.

Pengambilan yang Dapat Ditindaklanjuti

• CREATE ROLE dan rekannya, DROP ROLE, adalah perintah utama Anda untuk menerapkan dan menghapus peran.
• ALTER ROLE menangani perubahan atribut peran.
• Peran valid dalam semua database karena definisi di tingkat cluster database.
• Perlu diingat, membuat nama peran yang dimulai dengan karakter khusus, Anda harus 'mengatasinya' dengan tanda kutip ganda.
• Peran dan hak istimewanya ditetapkan menggunakan atribut.
• Untuk menetapkan peran yang memerlukan atribut LOGIN secara default, CREATE USER adalah perintah opsional yang Anda inginkan. Digunakan sebagai pengganti CREATE ROLE role_name LOGIN, pada dasarnya sama.

File pg_hba.conf - Membangun Persamaan Antara Server dan Klien

Mencakup semua aspek dan pengaturan untuk file pg_hba.conf dalam satu posting blog akan sangat menakutkan. Sebagai gantinya, bagian ini akan menyajikan jebakan umum yang mungkin Anda temui dan solusi untuk memperbaikinya.

Koneksi yang berhasil membutuhkan upaya konjungtif dari kedua bagian secara keseluruhan. Peran yang terhubung ke server, tetap harus memenuhi batasan akses yang ditetapkan di tingkat basis data, setelah melewati pengaturan di file pg_hba.conf.

Contoh relevan dari hubungan ini disertakan saat bagian ini berjalan.

Untuk menemukan file pg_hba.conf Anda, buat kueri SELECT yang serupa, pada pg_settings VIEW. Anda harus masuk sebagai PENGGUNA SUPER untuk mengkueri VIEW ini.

postgres=# SELECT name, setting
FROM pg_settings WHERE name LIKE '%hba%';
name | setting 
----------+-------------------------------------
hba_file | /etc/postgresql/10/main/pg_hba.conf
(1 row)

File pg_hba.conf berisi catatan yang menentukan salah satu dari tujuh format yang tersedia untuk permintaan koneksi yang diberikan. Lihat spektrum lengkapnya di sini .

Untuk tujuan posting blog ini, kita akan melihat pengaturan yang dapat Anda gunakan untuk lingkungan lokal.

Mungkin server ini untuk pembelajaran dan pembelajaran Anda yang berkelanjutan (seperti milik saya).

Saya harus membuat catatan khusus bahwa pengaturan ini bukan pengaturan optimal untuk sistem yang diperkuat yang berisi banyak pengguna.

Kolom untuk jenis koneksi ini adalah:

local database user auth-method [auth-options]

Artinya:

lokal - koneksi dicoba dengan soket domain-Unix.

database - Menentukan database yang dinamai untuk kecocokan record ini.

user - Nama pengguna database cocok untuk catatan ini. Daftar beberapa pengguna atau semua yang dipisahkan koma juga diizinkan untuk bidang ini.

auth-method - Digunakan saat koneksi cocok dengan record unik ini. Pilihan yang mungkin untuk bidang ini adalah:

• kepercayaan
• tolak
• scram-sha-256
• md5
• sandi
• gss
• sspi
• identitas
• rekan
• ldap
• jari-jari
• sertifikat
• pam
• bsd

Baris yang diatur dalam file pg_hba.conf untuk peran nolog_user dan log_user terlihat seperti ini:

local all nolog_user password
local all log_user password

Catatan:Karena kata sandi dikirim dalam teks yang jelas, ini tidak boleh digunakan di lingkungan yang tidak tepercaya dengan jaringan yang tidak tepercaya.

Mari kita lihat tiga kolom menarik dari pg_hba_file_rules VIEW dengan query di bawah ini. Sekali lagi peran Anda memerlukan atribut SUPERUSER untuk mengkueri VIEW ini.

postgres=# SELECT database, user_name, auth_method
postgres-# FROM pg_hba_file_rules
postgres-# WHERE CAST(user_name AS TEXT) LIKE '%log_user%';
database | user_name | auth_method 
----------+--------------+-------------
{all} | {nolog_user} | password
{all} | {log_user} | password
(2 rows)

Kita dapat melihat informasi yang identik dari baris yang disediakan di atas yang ditemukan di file pg_hba.conf seperti yang kita dapat dari kueri yang menyertainya. Sepintas, sepertinya kedua peran dapat masuk.

Kami akan menguji dan mengonfirmasi.

psql -U nolog_user -W postgres
Password for user nolog_user: 
psql: FATAL: role "nolog_user" is not permitted to log in
psql -U log_user -W postgres
Password for user log_user: 
psql (10.1)
Type "help" for help.
postgres=>

Poin kuncinya di sini adalah, meskipun nolog_user dan log_user keduanya dapat login sesuai dengan file pg_hba.conf, hanya log_user yang diizinkan untuk benar-benar login.

Jika log_user melewati batasan akses tingkat basis data (Dengan memiliki atribut LOGIN), nolog_user tidak.

Mari edit baris log_user di file pg_hba.conf dan ubah nama database yang diizinkan untuk diakses oleh peran ini. Inilah perubahannya, yang menunjukkan bahwa log_user sekarang hanya dapat masuk ke database percobaan.

local trial log_user password

Pertama mari kita coba login ke database postgres, yang sebelumnya dapat diakses oleh log_user karena flag all.

$ psql -U log_user -W postgres
Password for user log_user: 
psql: FATAL: no pg_hba.conf entry for host "[local]", user "log_user", database "postgres", SSL off

Sekarang dengan database percobaan log_user memang memiliki hak istimewa untuk

$ psql -U log_user -W trial
Password for user log_user: 
psql (10.1)
Type "help" for help.
trial=>

Tidak ada kesalahan di sana dan prompt trial=> menunjukkan database yang terhubung saat ini.

Pengaturan ini juga berlaku dalam lingkungan server, setelah koneksi dibuat.

Mari kita coba koneksi ke database postgres itu lagi:

trial=> \c postgres;
Password for user log_user: 
FATAL: no pg_hba.conf entry for host "[local]", user "log_user", database "postgres", SSL off
Previous connection kept

Melalui contoh yang disajikan di sini, Anda harus mengetahui opsi penyesuaian untuk peran di cluster Anda.

Catatan:Sering kali, memuat ulang file pg_hba.conf diperlukan agar perubahan dapat diterapkan.

Gunakan utilitas pg_ctl untuk memuat ulang server Anda.

Sintaksnya adalah:

pg_ctl reload [-D datadir] [-s]

Untuk mengetahui di mana datadir Anda, Anda dapat meminta VIEW sistem pg_settings, jika login sebagai SUPERUSER dengan kueri SELECT yang serupa seperti di bawah ini.

postgres=# SELECT setting FROM pg_settings WHERE name = 'data_directory';
           setting           
-----------------------------
 /var/lib/postgresql/10/main
(1 row)

Kemudian, berikan shell Anda kepada pengguna postgres (atau PENGGUNA SUPER lainnya) dengan:

$ sudo -u postgres bash

Kecuali Anda telah menambahkan utilitas pg_ctl ke $PATH Anda, Anda harus memenuhi syarat sepenuhnya untuk menggunakannya, lalu meneruskan perintah untuk dieksekusi, bersama dengan lokasi datadir.

Ini contohnya:

$ /usr/lib/postgresql/10/bin/pg_ctl reload -D /var/lib/postgresql/10/main
server signaled

Mari kita periksa status server dengan:

$ /usr/lib/postgresql/10/bin/pg_ctl status -D /var/lib/postgresql/10/main
pg_ctl: server is running (PID: 1415)
/usr/lib/postgresql/10/bin/postgres "-D" "/var/lib/postgresql/10/main" "-c" "config_file=/etc/postgresql/10/main/postgresql.conf"

Pengambilan yang Dapat Ditindaklanjuti

• Peran harus melewati persyaratan dari file pg_hba.conf dan hak akses tingkat basis data.
• File pg_hba.conf diperiksa dari atas ke bawah, untuk setiap permintaan koneksi. Urutan dalam file itu penting.

Keistimewaan dan Batasan Database, Tabel, dan Kolom - Sesuaikan Peran untuk Tugas dan Tanggung Jawab

Agar role dapat menggunakan objek database (tabel, tampilan, kolom, fungsi, dll...), mereka harus diberikan hak akses kepada mereka.

Perintah GRANT mendefinisikan hak istimewa penting ini.

Kami akan membahas beberapa contoh untuk mendapatkan esensi penggunaannya.

Membuat database

Karena log_user diberikan atribut CREATEDB dan CREATEROLE, kita dapat menggunakan peran ini untuk membuat database pengujian bernama trial.

postgres=> CREATE DATABASE trial:
CREATE DATABASE

Selain membuat PERAN baru:

postgres=> CREATE ROLE db_user WITH LOGIN PASSWORD 'scooby';
CREATE ROLE

Terakhir, log_user akan terhubung ke database percobaan baru:

postgres=> \c trial;
Password for user log_user: 
You are now connected to database "trial" as user "log_user".
trial=>

Perhatikan prompt berubah menjadi nama 'trial' yang menunjukkan bahwa kita terhubung ke database itu.

Mari gunakan log_user untuk MENCIPTAKAN tabel tiruan.

trial=> CREATE TABLE another_workload(
trial(> id INTEGER,
trial(> first_name VARCHAR(20),
trial(> last_name VARCHAR(20),
trial(> sensitive_info TEXT);
CREATE TABLE

Peran log_user baru-baru ini membuat peran pembantu, db_user. Kami membutuhkan db_user untuk memiliki hak istimewa terbatas untuk tabel another_workload.

Tidak diragukan lagi, kolom sensitive_info tidak boleh diakses oleh peran ini. Perintah INSERT, UPDATE, dan DELETE juga tidak boleh diberikan saat ini, hingga db_user memenuhi harapan tertentu.

Namun, db_user diperlukan untuk mengeluarkan kueri SELECT. Bagaimana kita bisa membatasi kemampuan peran ini dalam tabel another_workload?

Pertama mari kita periksa sintaks persis yang ditemukan di dokumen perintah GRANT PostgreSQL, di tingkat tabel.

GRANT { { SELECT | INSERT | UPDATE | REFERENCES } ( column_name [, ...] )
[, ...] | ALL [ PRIVILEGES ] ( column_name [, ...] ) }
ON [ TABLE ] table_name [, ...]
TO role_specification [, ...] [ WITH GRANT OPTION ]

Selanjutnya, kami menerapkan persyaratan yang ditetapkan untuk peran db_user, menerapkan sintaks tertentu.

trial=> GRANT SELECT (id, first_name, last_name) ON TABLE another_workload TO db_user;
GRANT

Perhatikan tepat setelah kata kunci SELECT, kami mencantumkan kolom yang dapat diakses db_user. Sampai diubah, jika db_user mencoba kueri SELECT pada kolom sensitive_info, atau perintah lain dalam hal ini, kueri tersebut tidak akan dijalankan.

Dengan db_user masuk, kami akan mempraktikkannya, mencoba kueri SELECT untuk mengembalikan semua kolom dan catatan dari tabel.

trial=> SELECT * FROM another_workload;
ERROR: permission denied for relation another_workload

Kolom sensitive_info disertakan dalam kueri ini. Oleh karena itu, tidak ada catatan yang dikembalikan ke db_user.

Tetapi db_user dapat PILIH kolom yang diizinkan

trial=> SELECT id, first_name, last_name
trial-> FROM another_workload;
id | first_name | last_name 
-----+------------+-----------
10 | John | Morris
191 | Jannis | Harper
2 | Remmy | Rosebuilt
(3 rows)

Itu berfungsi dengan baik.

Kami juga akan menguji perintah INSERT, UPDATE, dan DELETE.

trial=> INSERT INTO another_workload(id,first_name,last_name,sensitive_info)
VALUES(17,'Jeremy','Stillman','key code:400Z');
ERROR: permission denied for relation another_workload

trial=> UPDATE another_workload
trial-> SET id = 101
trial-> WHERE id = 10;
ERROR: permission denied for relation another_workload

trial=> DELETE FROM another_workload
trial-> WHERE id = 2;;
ERROR: permission denied for relation another_workload

Dengan tidak menetapkan perintah INSERT, UPDATE, atau DELETE ke db_user, peran tersebut ditolak aksesnya untuk menggunakannya.

Dengan banyaknya opsi yang tersedia, mengonfigurasi peran Anda hampir tidak terbatas. Anda dapat membuatnya berfungsi penuh, dapat menjalankan perintah apa pun, atau dibatasi sesuai kebutuhan Anda.

Pengambilan yang Dapat Ditindaklanjuti

• Peran diberikan hak akses ke objek database melalui perintah GRANT.
• Objek database dan perintah terhadap objek tersebut, sangat dapat dikonfigurasi dalam lingkungan PostgreSQL.

Menutup

Melalui contoh posting blog ini, Anda harus memiliki pemahaman yang lebih baik tentang:

1. Membuat peran dengan atribut tertentu.
2. Menyetel koneksi yang dapat diterapkan antara klien dan server, memungkinkan peran akses masuk ke database.
3. Sangat menyesuaikan peran Anda untuk memenuhi persyaratan individual untuk akses tingkat database, tabel, dan kolom dengan menerapkan atribut yang diperlukan.