Belajar Database Administrator - Data Governance & Compliance

#Pendahuluan

Sejauh ini kita mengelola database sebagai mesin. Mulai episode ini, kalian mengelolanya sebagai aset yang diatur hukum. Data pribadi pelanggan bukan sekadar byte di disk — ia diatur GDPR di Eropa, PCI-DSS untuk data kartu, dan UU PDP di Indonesia. Melanggar bukan hanya soal teknis: ada denda besar dan reputasi hancur.

Di sinilah DBA bertransformasi: dari "penjaga performa" menjadi jembatan antara data dan kepatuhan. Kalian akan diminta: berapa lama data disimpan? siapa yang boleh melihat nomor KTP? apa yang terjadi saat pelanggan minta datanya dihapus? Episode ini membekali kalian menjawabnya.

#Data Masking: Melindungi Data di Lingkungan Non-Produksi

Salah satu celah paling umum: developer butuh data realistis untuk menguji — lalu menyalin produksi mentah ke staging. Nomor KTP, alamat, dan data kartu pun bocor ke mesin yang kurang aman. Solusinya: data masking — mengaburkan data sensitif sambil mempertahankan bentuk dan distribusinya.

-- staging: pertahankan format, ubah isi
UPDATE users SET
    email       = 'user' || id || '@example.com',
    phone       = '0812' || lpad((id % 100000000)::text, 8, '0'),
    full_name   = 'User ' || id,
    ktp_number  = null
WHERE true;

Prinsip masking:

• Pertahankan bentuk (format, panjang, domain) supaya query & UI tetap bekerja — email tetap terlihat email, tanggal tetap tanggal.
• Hancurkan keterkaitan: nama asli tidak boleh bisa direkonstruksi dari versi masking (jangan substr(nama,1,2) — masih mudah ditebak).
• Lakukan di pipeline resmi, bukan manual ad hoc; dan jadwalkan refresh data staging berkala.

Tool ekosistem: pg_dump + query masking, atau alat khusus seperti Redgate Data Masker, Google DLP, dan fitur dynamic data masking di SQL Server. Prinsipnya sama di semua.

#Retention Policy: Kapan Data Dipensiunkan

Data bukan aset abadi — menyimpannya terlalu lama justru menambah risiko (makin banyak data bocor, makin besar kerusakan). Retention policy menjawab: data apa, disimpan berapa lama, lalu apa yang terjadi.

Contoh kebijakan yang wajar:

Implementasi teknisnya memakai alat yang sudah kita kuasai:

-- partisi per bulan; hapus data > 2 tahun cukup drop partisi
DROP TABLE logs_2024_08;   -- jauh lebih cepat dari DELETE

0 3 * * * psql -c "DELETE FROM session_data \
  WHERE created_at < now() - interval '24 hours'"

Kunci: retention policy harus terdokumentasi dan disetujui bisnis — kalian tidak boleh menghapus data sendiri tanpa dasar hukum yang jelas. Dokumen inilah yang akan diperiksa auditor.

#Audit Trails: Menjawab "Siapa yang Mengubah Apa"

Compliance menuntut bukti. Dari episode 9 kita sudah mengaktifkan log_connections + pgaudit — sekarang kita naikkan levelnya menjadi sistem yang bisa dipertanggungjawabkan:

log_connections = on
log_disconnections = on
log_statement = 'ddl'
log_line_prefix = '%m [%p] %u@%d '

CREATE EXTENSION IF NOT EXISTS pgaudit;
ALTER SYSTEM SET pgaudit.log = 'write, ddl';
SELECT pg_reload_conf();

Audit yang baik menyimpan siapa (user), apa (statement), kapan (timestamp), dari mana (IP), dan log-nya tidak bisa diubah oleh yang diaudit — simpan di host berbeda atau object storage immutable (pola episode 15). Tiga pertanyaan yang pasti ditanya auditor: bisa lihat log audit? data apa saja yang tercatat? bisa buktikan siapa akses data nasabah tanggal X? Pastikan kalian bisa menjawab ketiganya tanpa menyentuh database produksi.

#Regulasi: GDPR, PCI-DSS, UU PDP

Dari sisi database, regulasi yang paling sering ditemui meminta hal-hal yang kalian sudah bisa lakukan:

Pola teknis yang sama menanggung semuanya: enkripsi (episode 9/19), least privilege (episode 9), audit (episode 9/16), retention & deletion (episode 16), dan data flow documentation.

#Membangun Program Governance yang Realistis

Tidak perlu sempurna sejak hari pertama. Roadmap yang realistis:

1. Inventory data: daftar tabel yang berisi PII / data kartu — tag di catalog.
2. Klasifikasi: kritis (data kartu), pribadi (KTP/email), internal (log), publik.
3. Kontrol dasar: least privilege + masking + audit untuk data berklasifikasi tinggi (sudah bisa dari episode 9).
4. Retention & deletion: kebijakan tertulis + cron/partition yang mengeksekusinya.
5. Dokumentasi + review berkala: data flow diagram, kebijakan tertulis, review tahunan.

Mulai dari langkah 1-3 yang paling berisiko, lalu bangun ke 4-5. Governance adalah maraton, bukan sprint — dan DBA yang paham domain ini sangat langka serta mahal.

#Penutup

Inti yang harus dibawa pulang:

• Data masking melindungi data pribadi di lingkungan non-produksi — pertahankan bentuk, hancurkan keterkaitan.
• Retention policy menjawab simpan berapa lama & apa yang terjadi; eksekusi via partitioning + cron + arsip dingin.
• Audit trails (siapa, apa, kapan, dari mana) yang immutable adalah bukti yang diminta auditor.
• GDPR, PCI-DSS, dan UU PDP menuntut pola teknis yang sama: enkripsi, least privilege, audit, retention, dokumentasi.

Di episode 17 selanjutnya kita menertibkan perubahan skema: database version control & change management — migration-based schema dengan Flyway/Alembic, review flow yang rapi, dan pipeline CI/CD untuk database sehingga perubahan skema seterbuka kode aplikasi. Sampai jumpa di episode 17!