Ransomware: Kenapa Backup Saja Tidak Cukup (dan Cerita Restore yang Gagal)

Tim ops bangga: "Kita punya backup tiap malam ke tape, aman dari ransomware." Tiga bulan kemudian server file terenkripsi. Mereka pasang tape, jalankan restore — dan gagal di menit ke 40 karena backup terakhir yang sukses adalah 8 bulan lalu, sisanya silent-error karena disk penuh. Backup ada, tapi tidak bisa dipakai. Itu cerita nyata, dan bukan yang paling buruk yang saya temui. Artikel ini tidak akan jual solusi backup. Kita bedah kenapa backup saja tidak cukup, apa yang terjadi saat restore beneran, dan mengapa sebagian besar rencana recovery gagal di jam pertama.

Backup bukan antivirus

Mentalitas "punya backup jadi aman" adalah jebakan. Ransomware modern tidak cuma enkripsi — ia exfiltrasi dulu, lalu enkripsi. Jadi even kalau kamu restore 100% bersih, data sudah di tangan attacker (double extortion). Backup menyelamatkan ketersediaan data, bukan kerahasiaan. Kalau data sensitif (PII, medical, finansial) bocor, restore tidak menghapus kewajiban laporkan breach ke regulator.

Alasan praktis: backup menjawab "apakah saya bisa jalan lagi?", bukan "apakah saya sudah aman?". Dua pertanyaan beda, butuh strategi beda. Backup tanpa segmentasi jaringan, tanpa deteksi anomali, tanpa prinsip least-privilege = kamu cuma beli waktu sebelum serangan berikutnya.

Backup yang terhubung ke jaringan sama = backup yang ikut terenkripsi

Ini kesalahan nomor satu. Backup harian di //nas/backup yang di-mount read-write ke semua server produksi. Ransomware yang dapat kredensial domain admin (atau token SMB) langsung tulis ke share itu — enkripsi file backup juga. Kamu punya "backup" yang sudah rusak bersama produksi.

# SALAH: backup share di-mount RW ke semua host
mount -t cifs //nas/backup /mnt/backup -o username=svcbackup,password=...

Fix: backup target harus immutable atau append-only. Di Veeam: enable "GFS + capacity tier with object immutability" (WORM). Di Linux + rsync: tulis ke host terpisah lalu cabut mount, atau pakai rsync --read-only dari sisi backup server yang menarik (pull model), bukan produksi yang mendorong (push). Better: object storage dengan versioning + Object Lock (S3-compatible, waspada perbedaan Governance vs Compliance mode — Compliance tidak bisa di-override bahkan oleh root).

Alasan: attacker yang sudah di dalam akan mencari semua writable share. Kalau backup bisa ditulis dari host yang terinfeksi, ia bukan backup, cuma salinan yang lebih tua.

3-2-1 itu minimum, bukan selesai

Aturan 3-2-1 (3 copy, 2 media, 1 offsite) sudah standar, tapi orang stop di situ. Yang sering hilang:

  • Offline/offsite tidak sama dengan immutable. Offsite di cloud bisa dihapus kalau attacker dapat kredensial. Immutable object lock beda dengan "ada di bucket lain".
  • Copy ke-3 sering di-skip karena "mahal". Padahal itu yang selamatkan saat dua copy pertama (produksi + NAS lokal) ikut mati.
  • Tape tidak otomatis aman kalau tetap di library yang terhubung ke jaringan. Tape yang tidak di-eject dan disimpan fisik terpisah = masih bisa dienyahkan lewat library.

Saya sarankan 3-2-1-1: tambahan 1 copy offline/immutable (tape ejected, atau WORM object lock). Dan uji, jangan asumsi.

Cerita restore yang gagal: silent corruption

Kasus yang saya sebut di awal. Backup job lapor "success" tiap malam karena exit code 0 — tapi sejak 8 bulan lalu, disk tujuan penuh, rsync gagal halfway, dan log error dibuang ke /dev/null di cron job. Tidak ada yang cek. Saat butuh, backup-2026-07-01.tar.gz ukurannya 4 KB (cuma file manifest kosong).

# SALAH: cron yang buang error dan anggap sukses
0 2 * * * rsync -a /data/ /backup/ >/dev/null 2>&1

Mengapa gagal: tidak ada verification. Backup yang tidak pernah di-restore di lab adalah harapan, bukan backup.

Fix: - Jangan buang stderr. Log ke file, monitor ukuran output, alert kalau rsync return non-zero atau size anomali. - Verify: jalankan test -s backup.tar.gz && tar -tzf backup.tar.gz >/dev/null — bongkar test tiap backup. - Lakukan restore drill berkala (kuartalan). Pulihkan ke server terisolasi, cek checksum file kritis, catat waktu pemulihan (RTO).

Alasan: satu-satunya bukti backup berfungsi adalah restore yang berhasil. Sisanya adalah kepercayaan buta.

Cerita restore yang gagal: dependensi yang lupa

Tim restore database dari backup mingguan. Berhasil. Tapi aplikasi gagal jalan — ternyata schema baru butuh kolom yang tidak ada di backup minggu lalu, dan migration script tidak di-backup (cuma dev.db yang di-gitignore). Mereka restore data tapi tidak restore "bentuk" data.

Fix: backup harus mencakup kode + schema + konfigurasi, bukan cuma row. Untuk Postgres: pg_dump + simpan DDL; untuk aplikasi: tag rilis di git + env terpisah di vault. Dokumentasikan urutan restore: (1) schema, (2) data, (3) config, (4) verify.

Alasan: data tanpa schema = lump of bytes. Recovery plan yang tidak list urutan dan dependensi = rencana yang gagal saat panik.

RTO dan RPO bukan angka di dokumen

Banyak yang tulis "RTO 4 jam, RPO 1 jam" di paper, tapi tidak pernah diuji. Saat insiden, ternyata restore 2 TB dari cloud butuh 11 jam (bandwidth terbatas), dan RPO 1 jam tidak tercapai karena backup terakhir 6 jam lalu (job malam saja).

RPO (Recovery Point Objective) = berapa data maksimal hilang
RTO (Recovery Time Objective)  = berapa lama sampai jalan lagi

Fix: ukur betulan. Restore 100 GB ke staging, catat detik. Kalikan ke ukuran produksi, dapat estimasi realistis. Kalau RTO tidak masuk SLA bisnis, naikkan frekuensi backup (RPO) atau pakai replica panas (RTO). Jangan tulis angka yang tidak pernah diuji — itu bahaya saat audit.

Segmentasi jaringan menghentikan penyebaran

Ransomware menyebar lewat SMB/WMI/lateral movement. Kalau semua server di satu flat VLAN dengan share terbuka, satu host terinfeksi = semua ikut. Backup server di segmen sendiri dengan firewall yang hanya izinkan koneksi masuk dari backup software, bukan dari host produksi.

# Contoh: backup VLAN hanya boleh diakses dari management jump host
# Produksi TIDAK boleh inisiasi koneksi ke backup

Alasan: waktu serangan, kecepatan penyebaran menentukan berapa banyak yang sempat di-enkripsi sebelum terdeteksi. Segmen yang ketat = ledakan terisolasi.

Deteksi lebih murah dari restore

Rate enkripsi file mendadak (ribuan file berubah dalam detik) adalah signature jelas. Tool seperti Canary files (file palsu yang kalau diubah = alarm), atau monitor fswatch/inotify di share kritis, bisa deteksi di menit pertama — jauh sebelum enkripsi selesai.

Fix: pasang canary file di share penting, alert kalau berubah/hilang. Monitor event log Windows untuk event ID 4656/4663 (file access anomali) atau Linux auditd watch di direktori kritis.

Alasan: tiap menit yang dihemat sebelum enkripsi selesai = data yang tidak perlu di-restore. Deteksi adalah lapisan yang mencegah, backup adalah lapisan yang menyelamatkan.

Patching dan credential hygiene

Sebagian besar ransomware masuk lewat (1) RDP tanpa MFA, (2) VPN bug unpatched, (3) phishing kredensial. Backup tidak memperbaiki pintu masuk. Kalau kamu restore tanpa nutup jalur masuk, attacker balik dalam seminggu.

Fix: MFA wajib di semua remote access, patch dalam SLA (terutama edge/VPN), dan ganti semua kredensial + rotation secret setelah insiden — karena attacker sudah panen saat di dalam.

Alasan: restore tanpa memperbaiki akses = memulihkan mesin yang masih punya kunci cadangan di tangan musuh.

Kesalahan yang sering lolos

  1. Backup share di-mount RW ke produksi → ikut terenkripsi.
  2. 3-2-1 tanpa immutable/offline → cloud copy bisa dihapus.
  3. Cron buang error → silent corruption tidak ketahuan.
  4. Tidak ada restore drill → baru tahu rusak saat darurat.
  5. Backup cuma data, lupa schema/config → aplikasi tidak jalan.
  6. RTO/RPO cuma di kertas, tidak diuji.
  7. Flat network → penyebaran cepat.
  8. Tidak ada deteksi anomali → enkripsi selesai baru sadar.
  9. Restore tanpa ganti kredensial → attacker balik.

Takeaways

  • Backup menjawab ketersediaan, bukan kerahasiaan (double extortion tetap bocor).
  • Backup yang terhubung ke jaringan sama = bukan backup.
  • Immutable / offline copy wajib (WORM, ejected tape, object lock).
  • Verify + restore drill berkala; backup yang tidak pernah di-test = harapan.
  • Backup harus mencakup schema + config, bukan cuma row.
  • Ukur RTO/RPO betulan, jangan tulis angka kosong.
  • Segmen jaringan supaya ledakan terisolasi.
  • Pasang deteksi (canary file, auditd) — lebih murah dari restore.
  • Tutup jalur masuk (MFA, patch, rotate secret) sebelum restore.