Enkripsi Backup, Kenapa Salinan Data Juga Perlu Dikunci

Backup perlu dienkripsi karena siapa pun yang mendapatkan salinan itu mendapatkan seluruh datamu, tanpa perlu membobol server.

Kenapa ini penting? Server produksi biasanya dijaga berlapis: firewall, kata sandi kuat, update rutin. Backup-nya justru sering tergeletak di tempat yang lebih longgar. File .sql di bucket cloud storage, arsip .tar.gz di NAS kantor, atau hard disk eksternal di laci meja. Isinya sama persis: data pelanggan, transaksi, kata sandi yang di-hash, dokumen internal. Bagi penyerang, backup yang tidak terkunci adalah jalan pintas.

Di mana saja backup bisa bocor?

Beberapa skenario yang sering terjadi:

• Bucket atau folder cloud salah atur sehingga bisa diakses publik tanpa login.
• Kredensial cloud storage bocor, misalnya tersimpan di kode yang terunggah ke repositori publik.
• Folder backup di dalam direktori web, misalnya public_html/backup.zip, yang bisa diunduh siapa saja yang menebak namanya.
• Perangkat fisik hilang atau dicuri, seperti hard disk eksternal atau laptop yang menyimpan salinan.
• Penyedia atau pihak ketiga yang ikut menyimpan salinan, dengan standar keamanan yang tidak sepenuhnya kamu kendalikan.

Dalam semua skenario di atas, enkripsi menjadi lapisan terakhir. Data yang bocor dalam bentuk terenkripsi jauh berbeda dampaknya dengan data yang bocor dalam bentuk terbaca.

Apa yang dimaksud enkripsi backup?

Enkripsi backup berarti data diacak dengan algoritma kriptografi sebelum atau saat disimpan, sehingga hanya pemegang kunci yang bisa membacanya. Ada dua titik penting:

• Enkripsi saat dikirim (in transit): data dilindungi selama perjalanan ke tempat penyimpanan, misalnya lewat SFTP atau HTTPS.
• Enkripsi saat disimpan (at rest): data tetap teracak saat diam di disk atau cloud.

Untuk enkripsi saat disimpan, yang paling aman adalah enkripsi di sisi klien, yaitu backup dienkripsi di servermu sebelum dikirim. Dengan cara ini penyedia penyimpanan hanya menerima data teracak dan tidak memegang kuncinya.

Perbandingan singkat pilihan yang umum:

Bagaimana cara memulainya di server Linux?

Cara paling praktis adalah memakai alat backup yang sudah mengenkripsi secara bawaan. Restic, misalnya, selalu mengenkripsi repositori dengan AES-256 dan mengautentikasi datanya dengan Poly1305. Saat membuat repositori, kamu diminta kata sandi:

restic -r sftp:user@backup.example.com:/srv/restic init
restic -r sftp:user@backup.example.com:/srv/restic backup /var/www /root/dump.sql

Borg (seri 1.x) juga mendukung enkripsi saat inisialisasi, misalnya borg init --encryption=repokey-blake2 /path/repo. Pada mode repokey, kunci disimpan di repositori dan dilindungi passphrase, jadi passphrase itulah yang harus kamu jaga.

Untuk satu file, misalnya hasil dump database, GPG dengan enkripsi simetris sudah cukup:

gpg --symmetric --cipher-algo AES256 dump.sql

Hasilnya dump.sql.gpg yang hanya bisa dibuka dengan passphrase. Hapus file dump.sql aslinya setelah enkripsi berhasil, karena salinan yang belum terenkripsi yang tertinggal di folder kerja justru membatalkan tujuan langkah ini. Bila passphrase perlu dipakai oleh skrip terjadwal, simpan di file yang hanya bisa dibaca root, di luar folder yang ikut di-backup. Otomasinya, termasuk jadwal dan rotasi, dibahas di backup database otomatis.

Kunci adalah titik lemah barunya

Enkripsi memindahkan masalah: dari "bagaimana menjaga data" menjadi "bagaimana menjaga kunci". Ada dua kegagalan yang harus dihindari.

Pertama, kunci disimpan di tempat yang sama dengan backup. Kata sandi restic tertulis di file teks di folder yang ikut di-backup, atau kunci ada di bucket yang sama. Kalau penyerang mendapatkan backup, ia mendapatkan kuncinya juga.

Kedua, kunci hilang. Ini lebih menyakitkan karena tidak ada jalan kembali. Backup terenkripsi tanpa kunci sama dengan tidak punya backup sama sekali. Jangan sampai kunci hanya ada di server yang justru sedang rusak dan perlu dipulihkan.

Apakah enkripsi menggantikan aturan backup lainnya?

Tidak. Enkripsi menjaga kerahasiaan, bukan ketersediaan. Penyerang ransomware yang berhasil menghapus backup-mu tetap membuatmu kehilangan data, terenkripsi atau tidak. Karena itu enkripsi harus berjalan bersama prinsip lain: salinan di lokasi terpisah, salinan yang tidak bisa diubah atau dihapus (immutable), dan akses tulis yang dibatasi. Prinsip ini dibahas di aturan backup tahan ransomware.

Satu hal lagi: setelah backup dienkripsi, uji pemulihannya dengan kunci yang tersimpan, bukan dengan kunci yang kebetulan masih ada di sesi terminalmu. Panduannya ada di uji restore backup berkala.

Dari sisi aturan, UU PDP mewajibkan pengendali data menjaga keamanan data pribadi yang diprosesnya. Backup yang berisi data pelanggan termasuk di dalamnya, sehingga enkripsi backup adalah langkah teknis yang masuk akal untuk memenuhi kewajiban itu.