Pelajaran dari Serangan Ransomware PDN 2024
Serangan ransomware Brain Cipher ke PDNS 2 Surabaya pada Juni 2024 melumpuhkan layanan publik. Ini pelajaran praktisnya untuk backup dan keamanan bisnismu.
Jawaban singkat
Pada Juni 2024, ransomware Brain Cipher, varian baru LockBit 3.0, mengenkripsi Pusat Data Nasional Sementara 2 di Surabaya dan mengganggu layanan ratusan instansi. Pelajaran utamanya: backup harus terpisah dan teruji, sistem harus tersegmentasi, dan tanggung jawab backup harus jelas sejak awal.
Daftar isi
Pada 20 Juni 2024 dini hari, autogate imigrasi di bandara berhenti bekerja. Penyebabnya baru dipastikan beberapa hari kemudian: ransomware Brain Cipher mengenkripsi data di Pusat Data Nasional Sementara (PDNS) 2 di Surabaya. Pemerintah menyebut Brain Cipher sebagai pengembangan dari ransomware LockBit 3.0. Serangan itu mengganggu layanan banyak instansi pemerintah, dan pertanyaan yang paling sering muncul setelahnya sederhana: ada backup yang bisa dipakai atau tidak?
Pertanyaan yang sama berlaku untuk bisnis swasta, dan jawabannya sebaiknya sudah ada sebelum insiden.
Kronologi singkat dari sumber resmi
Keterbukaan informasi PT Telkom Indonesia kepada OJK tertanggal 26 Juni 2024 menyebut gangguan layanan PDNS dilaporkan mengganggu sistem autogate dan perlintasan bandara Ditjen Imigrasi pada 20 Juni 2024 pukul 04.15 WIB. Setelah analisis dan eskalasi ke penyedia platform cloud, dipastikan terjadi serangan ransomware Brain Cipher pada Pusat Data 2 (Surabaya), yang mengakibatkan kegagalan sistem dan data terenkripsi. Menurut dokumen itu, Crisis Center Gangguan PDNS sudah diaktifkan pada 20 Juni 2024 pukul 10.30, sekitar enam jam setelah gangguan autogate dilaporkan, untuk mengoordinasikan Kominfo, BSSN, Bareskrim, dan pengguna yang terdampak.
Dokumen yang sama mencatat serangan ini mengganggu sebagian layanan pada 239 tenant per 26 Juni 2024, termasuk beberapa layanan publik. Konfirmasi resmi soal gangguan disampaikan dalam konferensi pers Kominfo pada 24 Juni 2024. Per 26 Juni 2024, layanan yang disebut sudah dipulihkan antara lain keimigrasian, perizinan event, perizinan sertifikasi halal, dan layanan LKPP.
Langkah penahanan yang diumumkan pemerintah adalah mengisolasi PDNS 2 dengan memutus koneksinya ke pusat data lain agar ransomware tidak menyebar. Pemulihan jangka pendek dilakukan dengan menjalankan layanan di Disaster Recovery Center (DRC) sementara memakai data backup yang tersedia, sambil investigasi forensik berjalan.
Perhatikan urutannya: memastikan apa yang terjadi butuh beberapa hari, sedangkan memulihkan layanan satu per satu butuh jauh lebih lama. Pada insiden ransomware, layanan yang punya cadangan siap pakai bisa kembali lebih dulu, sementara yang tidak punya harus dibangun ulang.
Masalah inti: backup yang bergantung pada pilihan masing-masing
Ada satu detail di dokumen Telkom yang sering terlewat. Layanan PDNS terdiri dari IaaS, SaaS, Security as a Service, Backup as a Service, dan jaringan intra pemerintah, dengan seluruh layanan bersifat "request as a service" atau sesuai permintaan tenant. Artinya, backup adalah layanan yang harus diminta, bukan bawaan yang otomatis dimiliki setiap pengguna.
Pola ini mirip dengan yang terjadi di banyak bisnis. Pemilik usaha menyewa server atau hosting, lalu berasumsi "penyedia pasti punya backup". Padahal di banyak layanan, backup adalah fitur tambahan, punya masa simpan terbatas, atau disimpan di sistem yang sama dengan data utama. Saat ransomware mengenkripsi semuanya, backup yang tinggal satu atap ikut hilang.
Pelajarannya bukan soal siapa yang salah, tapi soal kejelasan tanggung jawab. Sebelum insiden, setiap pemilik data harus bisa menjawab tiga hal: di mana backup disimpan, siapa yang memastikannya berjalan, dan kapan terakhir backup itu berhasil dipulihkan.
Pelajaran konkret untuk bisnis
| Yang terlihat dari insiden | Risiko di bisnismu | Langkah yang bisa diambil |
|---|---|---|
| Backup adalah layanan sesuai permintaan | Mengira penyedia otomatis mem-backup | Tanyakan tertulis cakupan backup, lokasi, dan masa simpannya |
| Data di pusat data terenkripsi | Backup di server yang sama ikut terkunci | Simpan minimal satu salinan di lokasi dan akun terpisah |
| Penahanan dengan memutus koneksi antar pusat data | Ransomware menyebar lewat jaringan internal | Segmentasi jaringan, batasi akses antar server |
| Layanan publik terganggu lama | Bisnis berhenti selama pemulihan | Tentukan target waktu pulih dan uji secara rutin |
| Banyak instansi bergantung pada satu fasilitas | Satu titik kegagalan | Pisahkan sistem kritis, siapkan rencana cadangan |
Langkah pertama, dan yang paling murah, adalah menanyakan penyedia hosting atau servermu secara tertulis: apakah ada backup, seberapa sering, disimpan di mana, berapa lama, dan bagaimana cara memintanya dipulihkan. Kalau jawabannya kabur, anggap kamu belum punya backup. Simpan jawaban tertulis itu bersama dokumen kontrak, dan tanyakan ulang setiap kali paket atau penyedia berganti.
Langkah kedua adalah membuat salinan yang benar-benar terpisah. Prinsip yang banyak dipakai adalah aturan 3-2-1-1-0: tiga salinan, dua media, satu di luar lokasi, satu offline atau immutable, dan nol error saat verifikasi. Rinciannya ada di aturan backup 3-2-1-1-0. Untuk website, cara otomatisnya dibahas di backup website otomatis.
Langkah ketiga, dan yang paling sering dilewati, adalah menguji pemulihan. Backup yang tidak pernah dicoba dipulihkan hanyalah harapan. Cara menjalankan latihan pemulihan dan mengukur waktunya ada di uji restore backup.
Bagaimana ransomware bisa sampai mengenkripsi pusat data?
Detail teknis jalur masuk dalam insiden PDNS tidak dijelaskan lengkap di dokumen resmi yang kami rujuk, jadi kami tidak menebaknya. Namun pola umum ransomware modern sudah banyak didokumentasikan: penyerang masuk lewat kredensial yang bocor atau celah di sistem yang terbuka ke internet, bergerak ke server lain, mematikan perlindungan, menghapus atau mengenkripsi backup yang bisa dijangkau, lalu mengenkripsi data utama. Sebagian juga mencuri data dulu untuk pemerasan ganda.
Setiap tahap itu punya kontrol pencegahnya masing-masing, dari autentikasi multi faktor sampai pemisahan akun backup. Pemetaannya dibahas di cara kerja ransomware.
Jangan tunggu skala besar untuk belajar
Insiden PDNS menarik perhatian karena skalanya nasional, tapi mekanismenya sama dengan yang menimpa toko online, klinik, atau kantor akuntan. Bedanya, bisnis kecil jarang punya tim khusus untuk membangun ulang sistem dari nol. Kalau backup tidak ada, pilihan yang tersisa sangat sedikit.
Kalau minggu ini kamu hanya sempat mengerjakan satu hal, kirim tiga pertanyaan tadi ke penyedia server atau tim TI-mu: di mana backup disimpan, siapa yang memastikannya berjalan, dan kapan terakhir berhasil dipulihkan. Jawabannya akan menunjukkan dari mana kamu harus mulai.
