Backup yang belum pernah lu restore itu sering cuma rasa aman palsu.
Insiden cyber yang dilaporkan menimpa sistem land registry Romania jadi pengingat keras: risiko digital bukan cuma “data bocor”, tapi layanan publik bisa berhenti, transaksi bisa tertahan, dan orang biasa bisa kesulitan membuktikan kepemilikan aset. Artikel ini membahas kenapa backup offline, restore drill, credential hygiene, dan segmentasi sistem harus dianggap bagian inti dari reliability engineering. Bukan buat nakut-nakutin, tapi supaya builder dan developer punya checklist yang lebih waras sebelum bilang “tenang, ada backup”.
Apa yang terjadi di land registry Romania?
Risky Business melaporkan bahwa hacker menembus agen cadastre dan land registry Romania, ANCPI, lalu menghapus database land registry setelah upaya extortion gagal. Laporan itu menyebut aplikasi dan website resmi sempat offline sekitar satu minggu, notaris tidak bisa mencatat transaksi baru, dan warga tidak bisa mengambil bukti kepemilikan atau detail catatan tanah.
Detail teknisnya masih perlu dibaca hati-hati. Risky Business menyebut attacker memakai credential valid, memetakan sistem internal, lalu menghapus sistem dan backup. Di sisi lain, update resmi di situs ANCPI menyatakan, berdasarkan pemeriksaan sampai saat pengumuman itu, database teknis dan hukum institusi tidak terdampak. ANCPI juga menyebut proses migrasi aplikasi ke Government Cloud sedang berjalan bersama STS, lalu sistem akan diverifikasi sebelum layanan kembali normal.
Jadi angle paling aman bukan “semua data pasti hilang permanen”. Angle yang lebih berguna: ketika sistem penting offline, masyarakat tetap kena dampak nyata. Buat developer, pelajarannya bukan cuma security. Ini juga soal disaster recovery, continuity plan, dan desain sistem yang tahan saat credential valid disalahgunakan.
Kenapa ini relevan buat developer biasa?
Mungkin lu nggak mengelola database negara. Tapi pola risikonya tetap sama di project kecil: ada database production, ada akun admin, ada backup otomatis, ada server yang jarang disentuh, ada dokumentasi restore yang “nanti aja”. Bedanya cuma skala dampak.
Di side project, dampaknya mungkin user kehilangan data. Di toko online, transaksi bisa kacau. Di aplikasi internal kantor, tim operasional bisa berhenti kerja. Di sistem publik, dampaknya bisa nyambung ke dokumen, transaksi properti, layanan hukum, dan trust warga terhadap institusi.
Ini alasan gua selalu melihat backup sebagai fitur produk, bukan ritual DevOps. Backup bukan sekadar file dump yang tersimpan di storage lain. Backup baru berguna kalau bisa dipakai untuk mengembalikan layanan dalam waktu yang masuk akal.
Definisi singkat: backup offline, immutable backup, dan restore drill
Ada beberapa istilah yang sering terdengar mirip, tapi efeknya beda:
- Backup offline: salinan data yang tidak selalu tersambung ke sistem utama. Tujuannya supaya attacker yang masuk ke production tidak otomatis bisa menghapus semua salinan.
- Immutable backup: backup yang tidak bisa diubah atau dihapus dalam periode tertentu, bahkan oleh proses biasa. Ini membantu saat attacker punya credential yang cukup kuat.
- Restore drill: latihan mengembalikan sistem dari backup ke environment baru. Ini membuktikan backup lu bukan cuma ada, tapi bisa dipakai.
- RTO dan RPO: RTO menjawab “berapa lama layanan boleh down?”, sedangkan RPO menjawab “berapa banyak data yang boleh hilang?”. Tanpa dua angka ini, diskusi backup biasanya ngawang.
NIST SP 800-34 menekankan pentingnya contingency planning untuk sistem informasi: organisasi perlu menyiapkan, menguji, dan memperbarui rencana pemulihan. CISA juga mengingatkan bahwa serangan modern bisa bukan cuma mengenkripsi data, tapi juga mencuri, menekan korban, dan merusak operasi. Dengan kata lain, “backup ada” belum cukup kalau attacker bisa menghapusnya juga.
Masalah besarnya: credential valid bisa melewati banyak rasa aman
Kalau laporan Risky Business soal credential valid benar, ini pelajaran penting: attacker tidak selalu perlu exploit keren. Kadang mereka cukup punya username, password, token, atau akses internal yang sah secara teknis.
Di titik itu, firewall tidak otomatis menyelamatkan lu. Sistem melihat aktivitasnya seperti user valid. Makanya lapisan kontrol lain jadi penting: MFA, least privilege, segmentasi jaringan, audit log, alert untuk aktivitas aneh, dan pemisahan credential untuk operasi backup.
Kesalahan umum di project kecil adalah backup disimpan di akun cloud yang sama, diakses pakai credential yang sama, dan bisa dihapus dari server production yang sama. Kelihatannya praktis. Tapi kalau satu akses bocor, blast radius-nya terlalu besar.
Checklist praktis: kalau database production lu dihapus hari ini
Lu bisa pakai checklist ini buat project pribadi, startup kecil, atau sistem internal kantor:
- 1. Lu tahu backup terakhir ada di mana?
Jangan cuma tahu “ada cron backup”. Cek lokasi file, retention policy, ukuran file, dan log prosesnya. - 2. Backup bisa direstore ke environment baru?
Coba restore ke folder, database, atau server terpisah. Kalau cuma pernah backup tapi belum pernah restore, statusnya belum terbukti. - 3. Credential production bisa menghapus backup?
Kalau iya, itu red flag. Pisahkan akses tulis production dan akses penghapusan backup. - 4. Ada salinan offline atau immutable?
Minimal punya satu lapisan yang tidak mudah disentuh dari server utama. Untuk bisnis kecil, ini bisa mulai dari object storage dengan object lock, snapshot terpisah, atau export berkala yang aksesnya berbeda. - 5. Lu punya target RTO/RPO yang realistis?
Kalau layanan down, berapa jam masih bisa diterima? Kalau data hilang, maksimal berapa menit/jam yang bisa ditoleransi? - 6. Ada runbook saat incident?
Siapa yang mematikan akses? Siapa yang restore? Siapa yang komunikasi ke user? Jangan baru mikir saat panik. - 7. Log cukup buat investigasi?
Restore layanan penting, tapi tahu pintu masuk attacker juga penting supaya insiden tidak berulang.
Pelajaran buat builder: reliability dan security makin nyambung
Dulu banyak tim memisahkan security dan reliability terlalu jauh. Security dianggap urusan mencegah akses masuk. Reliability dianggap urusan uptime dan backup. Insiden seperti ini nunjukin dua hal itu nyambung.
Kalau attacker masuk memakai credential valid, reliability plan lu diuji. Kalau backup bisa dihapus dari akses yang sama, security boundary lu lemah. Kalau restore butuh tiga hari karena dokumentasinya ketinggalan, user tetap kena dampak walaupun backup sebenarnya ada.
Di rafli.dev, gua sering bahas AI, developer tools, dan automation. Tapi semakin banyak workflow otomatis, semakin penting juga pertanyaan boring seperti ini: data lu balik lagi nggak kalau sistem utama rusak?
Takeaway singkat
- Backup bukan bukti aman sampai lu pernah melakukan restore.
- Credential valid bisa jadi jalur serangan, jadi least privilege dan MFA tetap wajib.
- Backup harus punya boundary berbeda dari production.
- Offline atau immutable copy mengurangi risiko semua salinan ikut terhapus.
- RTO/RPO bikin diskusi recovery lebih konkret, bukan sekadar “nanti dibalikin”.
FAQ singkat
Apakah semua data land registry Romania benar-benar hilang?
Belum aman untuk menyimpulkan begitu. Risky Business melaporkan database dihapus dan layanan terganggu, sementara update ANCPI menyatakan database teknis dan hukum tidak terdampak berdasarkan pemeriksaan sampai saat pengumuman. Yang jelas, insiden ini cukup untuk membahas pentingnya recovery plan.
Apakah backup cloud sudah cukup?
Tergantung. Backup cloud bagus kalau aksesnya dipisah, retention jelas, dan restore pernah diuji. Kalau backup cloud bisa dihapus pakai credential production yang sama, risikonya masih besar.
Seberapa sering restore drill perlu dilakukan?
Untuk project kecil, minimal coba saat setup awal dan ulangi berkala setelah perubahan besar. Untuk sistem bisnis, restore drill perlu masuk rutinitas operasional dengan target RTO/RPO yang jelas.
