Belajar Database Administrator - Encryption & Key Management

#Pendahuluan

Enkripsi adalah lapisan keamanan terakhir — dan paling sering disalahpahami. Di episode 9 dan 18 kita sudah mengenal enkripsi in transit (TLS) dan menyentuh at rest; episode ini merangkainya menjadi strategi menyeluruh: apa yang dienkripsi, di lapisan mana, dan — yang paling sering dilupakan — siapa yang memegang kuncinya.

Pelajaran inti yang harus kalian hafal: encryption without key management is just obfuscation. Menyalakan enkripsi tanpa mengelola kunci (siapa pegang, bagaimana rotasi, apa yang terjadi saat kunci hilang) adalah keamanan palsu — dan bisa berubah menjadi bencana saat kunci hilang dan data tidak bisa dibuka sama sekali.

#Matriks Enkripsi: Melindungi Data di Semua Kondisi

Data berpindah posisi; tiap posisi butuh enkripsi berbeda:

Prinsip: data harus terenkripsi di tiap kondisi. TLS saja tidak cukup — file backup yang dicuri dari object storage harus tidak terbaca tanpa kunci. Enkripsi at rest juga melindungi dari penyalahgunaan fisik (disk bekas, server dicuri) dan persyaratan compliance (episode 16).

#Enkripsi At Rest: Lapisan Disk dan File

Cara tercepat dan paling luas cakupannya: enkripsi di level disk/volume — semua yang ditulis ke disk terenkripsi transparan. Pilihan:

• LUKS di Linux on-prem: seluruh partisi data terenkripsi.
• Cloud: EBS encryption (RDS: --storage-encrypted — sudah kita aktifkan di episode 12), Google Cloud Storage encryption, Azure SSE.
• Database file-level: file DB dienkripsi sendiri (TDE di MSSQL/Oracle, atau pgcrypto/encryption di layer file).

sudo cryptsetup luksFormat /dev/sdb1
sudo cryptsetup open /dev/sdb1 db_enc
sudo mkfs.ext4 /dev/mapper/db_enc
# mount /dev/mapper/db_enc di mount point data PostgreSQL

Di cloud, aktivasinya cukup flag: --storage-encrypted untuk RDS. Keuntungannya nol perubahan aplikasi; kerugiannya cakupan terbatas pada disk — data yang keluar (backup ke object storage, log ke tool lain) butuh enkripsi di lapisan berikutnya.

#Kunci: KMS dan Vault

Ini bagian yang membedakan profesional dari amatir. Kunci enkripsi adalah objek paling sensitif dalam sistem — jangan pernah disimpan dekat data yang dienkripsinya.

KMS (Key Management Service): layanan cloud yang menyimpan kunci master dan melakukan enkripsi/dekripsi atas nama aplikasi:

aws kms create-key --description "Kunci utama DB produksi"
aws rds create-db-instance \
    --db-instance-identifier appdb \
    --storage-encrypted \
    --kms-key-id arn:aws:kms:ap-southeast-1:1234:key/xxxx

Poin KMS yang wajib dipahami:

• Kunci master tidak pernah keluar dari KMS — data dienkripsi oleh KMS, kunci tidak pernah jatuh ke server DB.
• Rotasi otomatis tiap tahun (AWS) — data lama tetap terbaca lewat versi kunci (key versioning).
• Audit penggunaan: CloudTrail mencatat siapa memakai kunci — bahan audit episode 16.

HashiCorp Vault untuk on-prem/self-managed: menyimpan kunci dan mengeluarkan kredensial database secara dinamis (episode 14). Vault juga bisa membuat kunci enkripsi database yang dirotasi berkala:

vault secrets enable transit
vault write -f transit/keys/db-main
# aplikasi meminta enkripsi/dekripsi lewat API Vault

Skenario klasik yang harus bisa kalian jelaskan: kunci hilang = data hilang. Enkripsi tanpa kunci yang dikelola berarti data terkunci permanen. KMS/Vault justru ada untuk mencegah ini — kunci terpisah, direplikasi, dan bisa di-restore.

#TDE: Transparent Data Encryption

TDE adalah fitur yang dimiliki database komersial (MSSQL, Oracle) dan cloud (RDS Oracle/SQL Server): file database dienkripsi secara transparan di level storage engine — aplikasi dan query tidak berubah sama sekali, tapi file .mdf/datafile tidak terbaca tanpa kunci.

Cara kerjanya berlapis:

1. Database Encryption Key (DEK) mengenkripsi file database.
2. DEK dienkripsi oleh Certificate/ASymmetric Key (Master Key) yang disimpan di KMS.

Keuntungannya: transparan (tanpa perubahan aplikasi), melindungi backup & file. Kelemahannya: performa CPU (ringan di hardware modern), dan tidak melindungi dari query berbahaya — user yang punya akses SELECT tetap bisa membaca data. TDE melindungi file, bukan akses.

PostgreSQL komunitas tidak punya TDE native (opsi: pg_tde/enterprise, atau enkripsi disk/LUKS). Di praktik, enkripsi disk + field-level untuk kolom kritis adalah kombinasi paling umum di dunia Postgres.

#Field-Level: Menyasar Kolom Paling Sensitif

Untuk kolom yang benar-benar kritis (nomor kartu, KTP), enkripsi di lapisan aplikasi atau database:

CREATE EXTENSION IF NOT EXISTS pgcrypto;
INSERT INTO cards (number_enc)
VALUES (pgp_sym_encrypt('4111-1111-1111-1111', 'kunci-aplikasi'));
-- query memakai kunci yang dirotasi via aplikasi/Vault
SELECT pgp_sym_decrypt(number_enc, 'kunci-aplikasi') FROM cards;

Trade-off yang wajib dipertimbangkan:

• Index & pencarian jadi sulit: kolom terenkripsi tidak bisa di-index biasa / di-query dengan WHERE =. Pertimbangkan hash/keystore terpisah untuk lookup (atau pgcrypto untuk password hash — episode 9).
• Kunci di aplikasi = kunci ikut aplikasi: rotasi jadi sulit dan secret bocor ke lebih banyak tempat. Idealnya kunci dari KMS/Vault, bukan hardcoded.

#Rotasi Kunci: Rutinitas Wajib

Rotasi kunci menjaga kerusakan tetap terbatas: jika satu kunci bocor, dampaknya hanya pada periode pemakaian kunci itu. Frekuensi bergantung kepentingan:

• Kunci TLS: 90 hari - 1 tahun (otomatis dengan cert-manager).
• Kunci data at rest: 1 tahun (KMS otomatis), atau saat key compromise.
• Kredensial aplikasi: 30-90 hari (Vault dynamic secrets / database rotation).

Proses rotasi yang benar untuk DB at rest di cloud: buat kunci baru, RDS memakai versi kunci baru untuk re-encrypt tanpa downtime; file lama tetap terbaca sampai re-encrypt selesai. Di on-prem: rencanakan window, re-encrypt file backup, perbarui semua referensi. Uji rotasi di staging — rotasi yang gagal di production adalah insiden (episode 20).

#Skenario Pengujian: Apa yang Selamat Saat Breach?

Cara terbaik menguji strategi enkripsi: bayangkan skenario nyata.

Perhatikan baris ketiga: enkripsi at rest tidak melindungi dari query berbahaya — untuk itu ada least privilege (episode 9). Strategi enkripsi yang jujur menyatakan apa yang dilindungi dan apa yang tidak.

#Penutup

Inti yang harus dibawa pulang:

• Enkripsi berlapis: TLS (transit) + disk/TDE (at rest) + field-level (kolom kritis) — setiap posisi data terlindungi.
• Kunci dikelola KMS/Vault: terpisah dari data, rotasi otomatis, audit penggunaan.
• TDE transparan melindungi file/backup, bukan akses query — bedakan dengan jelas.
• Rotasi kunci diuji di staging; skenario breach dipetakan agar tahu persis apa yang selamat.

Di episode 20 selanjutnya kita menghadapi malam-malam terburuk DBA: incident & troubleshooting — men-debug deadlock, lock contention, dan connection exhaustion, mengikuti alur diagnosa yang sistematis, serta menjalankan post-mortem yang berujung perbaikan, bukan cari siapa yang salah. Sampai jumpa di episode 20!