Belajar pgBackRest - Encryption & Security

#Pendahuluan

Backup adalah salinan data paling sensitif yang dimiliki sebuah organisasi — dan ironisnya, sering menjadi target paling lemah. Sebuah repository backup berisi seluruh data produksi tanpa proteksi tambahan; kalau media backup dicuri, hilang, atau salah kirim, itu setara kebocoran total. Di episode 11 kita menutup celah ini dengan enkripsi at-rest: repository terenkripsi end-to-end dengan AES-256-CBC.

Bayangkan backup sebagai kotak berisi dokumen rahasia. Enkripsi bukan mengunci pintu gudang (access control), melainkan membuat isi kotak itu sendiri tidak terbaca tanpa kunci — bahkan jika kotaknya dicuri. Dua lapisan berbeda, dan backup butuh keduanya.

#Enkripsi di pgBackRest

#Bagaimana pgBackRest Mengenkripsi

pgBackRest mengenkripsi seluruh isi repository: file backup dan WAL, masing-masing dienkripsi sebelum ditulis. Enkripsinya memakai algoritma AES-256-CBC dengan kunci yang diturunkan dari passphrase yang kalian berikan. Tanpa passphrase yang benar, file di repository tidak bisa dibaca — termasuk oleh pgBackRest sendiri.

#Mengaktifkan Sebelum Stanza Dibuat

Keputusan paling penting: enkripsi harus diaktifkan saat stanza pertama kali dibuat, sebelum backup apa pun. Anda tidak bisa "menambahkan" enkripsi ke stanza yang sudah berisi backup lama — enkripsi adalah atribut seluruh repository/stanza, bukan per-file.

[global]
repo1-path = /var/lib/pgbackrest
repo1-cipher-type = aes-256-cbc
repo1-cipher-pass = pGcU4mTgK9xRvL2zHq7wE1sA5dF8jN0b

Setelah config diubah, buat stanza baru (atau ulangi stanza-create untuk stanza yang belum punya backup):

sudo -u postgres pgbackrest --stanza=main stanza-create
pgbackrest info

Di pgbackrest info, bagian cipher: aes-256-cbc menegaskan enkripsi aktif.

#Memverifikasi Enkripsi Benar-benar Aktif

Cek bahwa file di repository benar-benar terenkripsi, bukan sekadar label:

sudo -u postgres pgbackrest info
sudo ls -la /var/lib/pgbackrest/backup/main/latest/

File backup di sana berisi data terenkripsi — kalian tidak akan menemukan plaintext PostgreSQL di dalamnya. Untuk pengujian yang lebih meyakinkan, coba buka dengan strings dan periksa tidak ada data yang terbaca.

#Mengelola Passphrase

#Jangan Simpan di Config Terbuka

Passphrase yang tertulis di config file adalah pelanggaran prinsip enkripsi: tujuannya melindungi data saat config dicuri, tapi passphrase-nya sendiri ikut tertulis di config. Solusinya berlapis:

1. Config dengan permission 600:

sudo chown root:postgres /etc/pgbackrest.conf
sudo chmod 600 /etc/pgbackrest.conf

2. Passphrase di secret manager: jangan hardcode langsung. pgBackRest membaca nilai opsi dari config, tetapi pola yang lebih aman di environment modern adalah menyuntikkan passphrase via environment variable:

[global]
repo1-cipher-pass = ${PGBACKREST_CIPHER_PASS}

Lalu nilai PGBACKREST_CIPHER_PASS diisi dari secret manager (Vault, OpenBao, AWS Secrets Manager, dsb.) saat proses dijalankan. Ini membatasi paparan passphrase hanya di runtime, bukan di file statis.

#Rotasi Passphrase

Karena passphrase tidak bisa diubah di stanza yang ada, strategi rotasi adalah: buat full backup baru di stanza dengan passphrase baru (stanza baru atau repository baru), pertahankan yang lama sampai kadaluarsa retention, lalu hapus. Rotasi bukan operasi in-place — ia adalah transisi antar stanza.

#Proteksi Config dan Lingkungan

#Permission File Config

Selain enkripsi passphrase, file config harus tidak terbaca user biasa:

ls -l /etc/pgbackrest.conf
getfacl /etc/pgbackrest.conf

-rw------- (600) dengan owner root adalah standar. User postgres (yang menjalankan perintah) bisa membaca karena jadi group owner atau via sudo -u.

#Jangan Menyimpan Key di Log

Perhatikan bahwa passphrase bisa bocor lewat log jika perintah dijalankan dengan opsi --repo1-cipher-pass di command line. Selalu letakkan passphrase di config (dengan permission aman) atau environment variable — bukan di argumen perintah yang tercatat di shell history atau log.

#Enkripsi vs Akses

Enkripsi at-rest tidak menggantikan kontrol akses — ia melengkapinya. Tetap batasi siapa yang bisa membaca repository (permission), kunci SSH (episode 13), dan jangan expose repository ke jaringan publik. Enkripsi adalah jaring pengaman terakhir jika semua kontrol lain gagal.

#Penutup

Inti yang harus dibawa pulang:

• Aktifkan repo1-cipher-type = aes-256-cbc + repo1-cipher-pass sebelum stanza dibuat.
• Enkripsi melindungi seluruh isi repository: backup dan WAL at-rest.
• Passphrase tidak bisa diubah di stanza existing — rotasi berarti migrasi stanza baru.
• Kelola passphrase di secret manager; injeksi via environment variable.
• Kunci config 600; jangan pernah meletakkan passphrase di argumen perintah.

Di episode 12 selanjutnya kita akan memindahkan repository keluar dari host database: remote & object storage — repository di host lain via SSH (repo1-host) dan S3-compatible storage (repo1-s3-endpoint, bucket) untuk off-site backup yang murah dan tahan bencana lokasi. Inilah langkah menuju arsitektur backup yang benar-benar production!