Studi Kasus: Serangan Ransomware Ganda & Pemulihan Data pada PT Financorp Indonesia
1. Profil Organisasi & Lingkungan TI
PT Financorp Indonesia adalah perusahaan penyedia layanan teknologi finansial (FinTech) yang mengelola platform pembayaran mikro untuk jutaan UMKM.
Aset Data Kritis: Basis data transaksi harian (Core Transaction Database) seluas 15 Terabyte (TB), data identifikasi nasabah (KYC), dan log audit transaksi.
Infrastruktur: Server database utama berjalan di Private Data Center Jakarta.
Kebijakan Backup: Perusahaan mengklaim telah menerapkan prosedur backup harian yang otomatis.
2. Kronologi Bencana (Skenario Insiden)
Pada hari Jumat pukul 23.00 WIB, kelompok penjahat siber (ransomware gang) berhasil menembus jaringan internal perusahaan melalui teknik Phishing Credential stuffing.
Eksploitasi & Pembajakan Hak Akses: Peretas mendapatkan kredensial akun Domain Administrator dan langsung memetakan seluruh jaringan internal.
Penghancuran Backup Lokal: Peretas menemukan server penyimpanan cadangan (NAS Local) yang terhubung dalam satu domain jaringan. Mereka menghapus seluruh salinan backup lokal dan mengenkripsi database utama di Jakarta menggunakan Ransomware BlackCat.
Pesan Tebusan: Pada Sabtu pukul 02.00 WIB, seluruh server utama lumpuh total. Peretas meninggalkan pesan tebusan sebesar USD 2 Juta (sekitar Rp31 Miliar) dan mengancam akan menghapus seluruh data jika tebusan tidak dibayar dalam 24 jam.
3. Pertanyaan Studi Kasus
Analisis mengapa sistem pencadangan tradisional PT Financorp Indonesia (sebelumnya) gagal melindungi perusahaan dari serangan ransomware ini!
Jelaskan bagaimana tim TI PT Financorp dapat memulihkan seluruh data transaksi secara utuh tanpa membayar tebusan sepeser pun dengan menerapkan prinsip Strategi Backup 3-2-1-1!
Petakan arsitektur penyimpanan data PT Financorp berdasarkan komponen 3-2-1-1 dalam bentuk tabel atau matriks skema!
Apa pelajaran kunci (key takeaways) bagi manajemen risiko TI dari insiden pemulihan ini?
4. Jawaban & Solusi Penanganan Kasus
Jawaban Nomor 1: Analisis Kegagalan Pencadangan Tradisional
Sistem pencadangan lama perusahaan gagal karena mengalami masalah Single Point of Failure dan kurangnya isolasi data:
Tidak Ada Isolasi Jaringan (Connected Backup): Server backup lokal terhubung secara terus-menerus (online) dalam domain jaringan utama. Ketika kredensial Domain Admin dibajak, peretas memiliki akses penuh untuk menghapus atau mengenkripsi file backup tersebut.
Tidak Ada Fitur Immutability: File backup disimpan dalam format standar yang dapat dimodifikasi atau dihapus oleh siapa pun yang memiliki hak akses administrator.
Bergantung pada Satu Lokasi: Seluruh aset data dan backup berada di fasilitas fisik yang sama di Jakarta.
Jawaban Nomor 2: Proses Pemulihan Data Menggunakan Strategi 3-2-1-1
Meskipun database utama dan backup lokal di Jakarta dienkripsi total, PT Financorp Indonesia berhasil pulih sepenuhnya karena dalam 6 bulan terakhir telah mengimplementasikan Strategi Backup 3-2-1-1:
Memanfaatkan Salinan Offsite (Angka "1" Pertama):
Tim TI mengabaikan server Jakarta yang terkontaminasi dan mengalihkan fokus pemulihan ke salinan cadangan yang tersimpan di Cloud Storage Provider lokasi Region Singapura (Offsite).
Memanfaatkan Fitur Immutable / WORM (Angka "1" Kedua - Kunci Utama):
Peretas mencoba menghapus file backup di Cloud Storage menggunakan akun admin yang mereka curi. Namun, aksi tersebut ditolak otomatis oleh sistem karena file backup dilindungi dengan fitur Object Lock (WORM - Write Once, Read Many) selama periode retensi 30 hari.
File backup tetap bersih, aman, dan tidak tersentuh oleh ransomware.
Mekanisme Restoration ke Server Baru (Clean Environment):
Tim TI menyiapkan infrastruktur server baru (clean slate) di Disaster Recovery Center (DRC) Surabaya.
File backup bersih dari Cloud diunduh dan dipulihkan (restored) ke server DRC Surabaya.
Dalam kurun waktu 6 jam, seluruh sistem transaksi dan basis data pelanggan kembali beroperasi normal tanpa ada data yang hilang.
Jawaban Nomor 3: Matriks Skema Penerapan 3-2-1-1 di PT Financorp
| Elemen 3-2-1-1 | Komponen Infrastruktur | Fungsi dalam Penanganan Insiden | Status Saat Serangan |
| 3 Salinan Data | 1. Database Utama (Jakarta) 2. Backup NAS Lokal (Jakarta) 3. Cloud Object Storage (Singapura) | Menjamin ketersediaan data dari beberapa titik jika salah satu rusak. | • Salinan 1: Terenkripsi • Salinan 2: Terhapus • Salinan 3: Selamat |
| 2 Media Berbeda | 1. NVMe Enterprise SSD (Server Utama) 2. Magnetic Tape / Cloud Object Storage | Mencegah kerusakan massal akibat kegagalan satu jenis media penyimpanan. | Media Cloud terisolasi secara fisik dan logis dari SSD lokal. |
| 1 Lokasi Offsite | Data Center Singapura (Cloud) | Melindungi data dari bencana fisik atau kelumpuhan total Data Center Jakarta. | Selamat karena berada di luar jaringan lokal Jakarta. |
| 1 Salinan Immutable | S3 Object Lock (Teknologi WORM) | Menolak segala perintah penghapusan/pengubahan file dari peretas/admin. | TETAP UTUH (Sistem menolak perintah hapus dari peretas). |
Jawaban Nomor 4: Pelajaran Kunci (Key Takeaways)
Immutability is Non-Negotiable: Fitur Immutable Backup (WORM) adalah benteng pertahanan terakhir yang paling ampuh melawan serangan ransomware modern.
Kredensial Admin Bukan Jaminan: Hak akses administrator dapat dicuri (compromised). Kontrol keamanan berbasis perangkat keras/sistem (Immutability & Air-Gap) jauh lebih tepercaya daripada sekadar proteksi kata sandi.
Menghemat Biaya & Reputasi: Dengan menerapkan strategi 3-2-1-1, perusahaan berhasil menghemat uang tebusan sebesar Rp31 Miliar dan menjaga integritas kepercayaan nasabah.
