Membuat Pengguna Database Read-Only

Menyambungkan database perusahaan ke alat analitik mana pun sebaiknya dimulai dari satu keputusan: alat itu tidak boleh bisa menulis. Bukan karena alatnya mencurigakan, melainkan karena batasan yang ditegakkan database Anda sendiri tidak bergantung pada janji siapa pun.

Tulisan ini berisi perintah yang bisa langsung dijalankan, kesalahan izin yang sering terjadi, dan cara memastikan pembatasannya benar-benar bekerja.

PostgreSQL

Buat pengguna, beri izin baca, lalu pastikan tabel yang dibuat di masa depan ikut terkena aturan yang sama.

-- 1. Pengguna baru dengan kata sandi acak yang panjang
CREATE USER analitik_ro WITH PASSWORD 'ganti-dengan-kata-sandi-acak-32-karakter';

-- 2. Izin menyambung ke database tertentu saja
GRANT CONNECT ON DATABASE toko TO analitik_ro;

-- 3. Izin melihat isi skema
GRANT USAGE ON SCHEMA public TO analitik_ro;

-- 4. Izin baca untuk tabel yang sudah ada
GRANT SELECT ON ALL TABLES IN SCHEMA public TO analitik_ro;

-- 5. Izin baca untuk tabel yang dibuat kemudian
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO analitik_ro;

Langkah kelima adalah yang paling sering dilewati. Tanpa itu, tabel yang dibuat bulan depan tidak akan terbaca, dan gejalanya muncul sebagai “kenapa data baru tidak ada” — pertanyaan yang butuh waktu lama untuk dilacak ke sumbernya.

Menyembunyikan tabel tertentu

Bila ada tabel yang tidak boleh terbaca sama sekali — data karyawan, rekam medis, catatan gaji — jangan memberi SELECT untuk seluruh skema. Berikan per tabel:

GRANT SELECT ON transaksi, transaksi_item, produk, cabang TO analitik_ro;

Cara paling andal menjaga sesuatu tidak terbaca adalah tidak memberikan izin membacanya. Menyembunyikannya di tampilan alat analitik bukan pembatasan; itu hanya dekorasi.

Membatasi beban kueri

Kueri analitik yang berat bisa mengganggu aplikasi transaksi. Dua pagar yang murah:

-- Batasi waktu jalan kueri untuk pengguna ini saja
ALTER ROLE analitik_ro SET statement_timeout = '30s';

-- Batasi jumlah koneksi bersamaan
ALTER ROLE analitik_ro CONNECTION LIMIT 5;

Bila beban analitiknya besar, arahkan pengguna ini ke replika baca alih-alih ke database utama.

MySQL / MariaDB

CREATE USER 'analitik_ro'@'%' IDENTIFIED BY 'ganti-dengan-kata-sandi-acak';

GRANT SELECT ON toko.* TO 'analitik_ro'@'%';

-- Atau per tabel bila ada yang harus disembunyikan
-- GRANT SELECT ON toko.transaksi TO 'analitik_ro'@'%';

FLUSH PRIVILEGES;

Perhatikan bagian '@'%'. Tanda persen berarti pengguna ini boleh menyambung dari alamat mana pun. Bila Anda tahu alamat IP alat yang akan menyambung, batasi:

CREATE USER 'analitik_ro'@'203.0.113.45' IDENTIFIED BY '...';

Pembatasan ini menghilangkan seluruh kelas percobaan masuk dari alamat lain, dan biayanya satu baris.

Memeriksa bahwa pembatasannya bekerja

Jangan percaya bahwa izinnya benar sampai Anda mencoba melanggarnya. Masuk sebagai pengguna baru, lalu jalankan:

-- Harus berhasil
SELECT count(*) FROM transaksi;

-- Semuanya harus GAGAL dengan permission denied
INSERT INTO transaksi (total) VALUES (1);
UPDATE transaksi SET total = 0 WHERE id = 1;
DELETE FROM transaksi WHERE id = 1;
CREATE TABLE coba_saja (id int);
DROP TABLE transaksi;

Bila salah satu perintah tulis berhasil, izinnya belum benar. Yang paling sering jadi penyebab: pengguna dibuat dengan hak SUPERUSER tanpa sengaja, atau izin diberikan ke role PUBLIC sehingga semua pengguna mewarisinya.

Periksa juga apa saja yang bisa dilihat pengguna ini:

-- PostgreSQL: daftar tabel yang bisa dibaca analitik_ro
SELECT table_name
FROM information_schema.table_privileges
WHERE grantee = 'analitik_ro' AND privilege_type = 'SELECT'
ORDER BY table_name;

Bacalah daftarnya sampai selesai. Sering kali ada satu atau dua tabel di situ yang membuat Anda berkata “ini tidak perlu terbaca” — dan itulah gunanya memeriksa.

Menyimpan kredensialnya

Kata sandi ini akan dimasukkan ke alat analitik dan kemungkinan juga tersimpan di catatan seseorang. Beberapa hal yang membuat perbedaan nyata:

• Buat kata sandi acak sepanjang minimal 24 karakter. Tidak ada manusia yang perlu mengetiknya lebih dari sekali.
• Jangan pakai kata sandi yang sama dengan pengguna aplikasi utama.
• Jangan kirim lewat chat grup. Bila terlanjur, ganti — memutar kata sandi lebih murah daripada memikirkannya berbulan-bulan.
• Catat di mana saja kredensial ini dipakai, supaya saat harus diganti Anda tahu apa yang akan berhenti bekerja.

Yang berubah setelah ini

Setelah pengguna read-only berjalan, pertanyaan “apakah alat ini aman disambungkan” berubah bentuk. Ia tidak lagi soal mempercayai alatnya, melainkan soal memeriksa daftar tabel yang Anda izinkan — pertanyaan yang jauh lebih mudah dijawab dan bisa ditinjau ulang kapan saja.