Backup yang terisolasi tidak banyak membantu bila satu akun admin yang sama masih dapat mengubah produksi, menghapus recovery point, dan mematikan proteksi. Untuk ransomware readiness, pertanyaannya bukan hanya “apakah kami punya backup?”, tetapi siapa yang dapat mengubah atau menghapusnya-dan apakah akses itu dipisahkan dari lingkungan yang mungkin sedang diserang.
Satu akun dengan hak terlalu luas memang terlihat praktis. Namun ia membuat kegagalan saling berkaitan: ketika akun tersebut disalahgunakan, operasional dan jalur pemulihan dapat terdampak dalam waktu yang sama. Artikel ini adalah panduan awal untuk IT Manager, bukan resep teknis universal. Desain akhir harus mengikuti IAM, repository backup, lisensi, jaringan, RPO/RTO, serta kebijakan organisasi.
Minta Access Review untuk memetakan risiko akses produksi dan recovery secara terarah.
Satu akun admin dapat menjadi satu titik kegagalan bersama
Admin convenience tidak sama dengan recovery resilience. Bila akun yang sama mengelola hypervisor atau cloud, console backup, repository storage, identity, serta akses remote, kompromi satu identitas dapat memberi penyerang jalur untuk mengubah banyak kontrol. MFA tetap penting, tetapi MFA bukan pengganti pemisahan peran, review akses, dan approval untuk tindakan destruktif.
CISA menempatkan kesiapan respons sebagai bagian penting dari penanganan ransomware. Dalam praktiknya, kesiapan itu harus terlihat sebelum insiden: owner jelas, akses dibatasi, bukti log tersedia, dan prosedur pemulihan dapat dijalankan ketika kredensial operasional utama tidak lagi dipercaya.
Risiko yang perlu dicari pada lingkungan perusahaan
- Akun bersama atau akun privileged tanpa owner yang dapat dipertanggungjawabkan.
- Akun yang sama dipakai untuk produksi, backup console, repository, storage, dan identity.
- MFA tidak konsisten pada VPN, akses remote, atau akun service.
- Hak menghapus backup, mengubah retensi, atau menonaktifkan proteksi tanpa approval dan audit trail.
- Akses lama yang belum dicabut setelah perubahan peran, perpindahan tim, atau berakhirnya kontrak.
Checklist pemisahan akses dalam 30 hari pertama
- Inventaris akun privileged dan pemiliknya.
- Petakan akses ke produksi, backup console, repository, cloud/storage, dan identity.
- Pisahkan akun atau role berdasarkan pekerjaan, bukan berdasarkan siapa yang paling senior.
- Wajibkan MFA pada jalur administratif yang relevan.
- Tetapkan break-glass account dengan owner, prosedur, durasi, dan audit trail.
- Review akses berkala serta cabut akses saat peran berubah.
- Jalankan tabletop atau restore test dengan asumsi akun admin utama tidak dapat dipercaya.
Keputusan akses yang perlu ditetapkan
| Kondisi | Keputusan | Bukti yang diperlukan |
|---|---|---|
| Satu admin memegang produksi dan backup | Pisahkan role dan review hak hapus/retensi | Inventory role, owner, approval path |
| Backup immutable tetapi admin utama masih mengelola seluruh jalur | Uji apakah recovery tetap dapat dijalankan saat akun utama dikompromikan | Restore test dan audit akses |
| Akses emergency diperlukan | Gunakan break-glass terbatas dan terpantau | Owner, expiry, log, review pasca-pakai |
| Scope belum dipahami | Jeda perubahan berisiko dan lakukan access review | Peta sistem, dependensi, dan owner |
Backup aman tetap harus bisa direcovery
Microsoft merekomendasikan pengujian pemulihan secara berkala untuk memverifikasi konfigurasi, ketersediaan data, dan kebutuhan RPO/RTO. Veeam juga menjelaskan peran backup immutable, air-gapped, dan terisolasi dalam kesiapan clean recovery. Kontrol tersebut saling melengkapi: immutable backup membantu membatasi perubahan selama periode retensi, sedangkan pemisahan akses mengurangi peluang satu identitas mengendalikan seluruh jalur risiko.
Namun jangan menganggap satu fitur sebagai jaminan ransomware. Perilaku repository, immutability, retensi, dan recovery bergantung pada platform serta konfigurasi yang dipakai. Bukti yang lebih kuat adalah restore test yang membuktikan orang yang tepat dapat memulihkan layanan dengan akses yang tepat.
Peran MFA dan monitoring
MFA dapat menambah lapisan perlindungan untuk akses admin, VPN, server, dan aplikasi. Contoh seperti Rublon dapat dipertimbangkan sesuai environment. Tetapi MFA tidak menjawab pertanyaan siapa yang seharusnya memiliki role tersebut, apakah aksesnya terlalu luas, atau apakah tindakan sensitif membutuhkan persetujuan. Monitoring dan review log tetap diperlukan untuk melihat perubahan akun, perubahan retensi, dan penggunaan break-glass account.
Peran solusi myBATICloud dalam access review
Untuk perusahaan Indonesia yang belum memiliki tim keamanan besar, myBATICloud / PT Bangun Abadi Teknologi Indonesia dapat memulai dari access review: memetakan pemisahan akses produksi dan backup, kebutuhan MFA, bukti restore, serta owner operasional. BaaS berbasis Veeam atau Acronis dapat dipadukan dengan SecaaS, monitoring/SOC sesuai scope, dan Managed Service untuk operasional serta review berbasis SLA. DRaaS, IaaS, atau StaaS dievaluasi bila desain recovery memang membutuhkan failover, compute, atau storage terpisah.
Mulai dari review, bukan membeli tool secara membabi buta
Urutan yang sehat adalah memahami jalur akses, menguji recovery, lalu memilih kontrol yang menutup gap nyata. Dengan begitu, investasi backup dan security tidak hanya menghasilkan dashboard “success”, tetapi kesiapan pemulihan yang bisa dijelaskan kepada manajemen.
Butuh mengecek kesiapan backup dan recovery? Mulai dari assessment singkat untuk memetakan owner akses, role administratif, MFA, approval, dan bukti restore. Minta Access Review.
Pertanyaan yang sering muncul
Apakah semua admin harus dipisahkan menjadi banyak akun?
Tidak selalu. Tujuannya bukan menambah kerumitan tanpa alasan, melainkan memisahkan hak sensitif agar kompromi satu akun tidak memberi kontrol penuh atas produksi dan recovery.
Apakah immutable backup sudah cukup?
Immutable backup adalah lapisan penting, tetapi perlu dipadukan dengan pemisahan akses, review perubahan, logging, dan recovery test agar desain dapat diuji pada kondisi nyata.
Kapan access review perlu diprioritaskan?
Prioritaskan bila satu akun menguasai produksi dan backup, ada akun bersama tanpa owner, akses lama tidak ditinjau, atau restore belum pernah diuji ketika akun operasional utama tidak dipercaya.