Ketika sistem utama dalam bisnis mengalami gangguan, bagian tersulit adalah mengetahui apa yang harus dipulihkan terlebih dahulu, siapa yang memiliki akses untuk melakukannya, cadangan mana yang tepercaya, dan berapa lama bisnis dapat terus berjalan tanpa sistem tersebut.
Di situlah banyak usaha kecil dan menengah (UKM) menemukan celah antara memiliki cadangan dan memiliki paket pemulihan yang nyata. Cadangan mungkin berisi data yang dibutuhkan, tetapi cadangan tersebut tidak menentukan urutan pemulihan, menetapkan tanggung jawab, memvalidasi apakah tindakan pulihkan berhasil, atau menyelesaikan masalah kredensial admin yang hilang selama gangguan.
Paket pemulihan bencana TI memberikan struktur pada proses ini sebelum terjadi gangguan. Paket ini menentukan sistem mana yang paling penting, seberapa cepat sistem tersebut harus dipulihkan, seberapa banyak kehilangan data yang dapat ditoleransi oleh bisnis, strategi pencegahan kehilangan data apa yang harus diterapkan, siapa yang bertanggung jawab atas setiap langkah pemulihan, dan bagaimana kredensial penting dilindungi. Kejelasan ini dapat mencegah insiden TI berkembang menjadi waktu henti yang berkepanjangan, hilangnya pendapatan, atau krisis operasional yang lebih luas.
Apa itu paket pemulihan bencana TI?
Kelangsungan bisnis vs. pemulihan bencana TI
Hal yang harus dicakup dalam paket pemulihan bencana TI
Hal yang perlu ditentukan oleh paket pemulihan bencana TI
Pemulihan kredensial: skenario pemulihan bencana yang sering diabaikan
Templat paket pemulihan bencana
Cara menguji paket pemulihan bencana TI
Membangun pemulihan berbasis sistem, data, dan akses
Apa itu paket pemulihan bencana TI?
Paket pemulihan bencana TI adalah proses terdokumentasi untuk memulihkan sistem teknologi setelah terjadi gangguan. Paket ini berfokus pada lapisan TI bisnis: data, aplikasi, perangkat, infrastruktur, layanan cloud, akses admin, cadangan, dan orang-orang yang bertanggung jawab atas pemulihan.
Paket pemulihan TI yang praktis harus menjawab pertanyaan seperti:
- Sistem mana yang harus dipulihkan terlebih dahulu?
- Berapa banyak waktu henti yang dapat ditoleransi oleh bisnis?
- Berapa banyak kehilangan data yang dapat diterima?
- Di mana cadangan tersimpan?
- Siapa yang dapat memulihkan sistem?
- Kredensial admin mana yang diperlukan?
- Bagaimana tim akan mengonfirmasi bahwa sistem yang dipulihkan aman dan dapat digunakan?
- Bagaimana bisnis akan berkomunikasi dengan staf dan pelanggan jika kanal utama terganggu?
Paket pemulihan bencana harus lebih dari sekadar menangani serangan siber: paket ini perlu mencakup isu sehari-hari seperti kegagalan perangkat keras, hilangnya kredensial, dan penghapusan yang tidak disengaja. Paket ini juga perlu mencakup gangguan layanan eksternal seperti gangguan platform cloud atau alat SaaS, kesalahan konfigurasi, dan karyawan kunci yang keluar tanpa mentransfer akses penting.
Pemulihan bukanlah sesuatu yang dirancang saat terjadi pemadaman. Pemulihan perlu direncanakan, dimiliki, dikomunikasikan, dan diuji sebelum bisnis harus bergantung padanya.
Kelangsungan bisnis vs. pemulihan bencana TI
Kelangsungan bisnis dan pemulihan bencana TI sering kali dianggap sama, tetapi keduanya menyelesaikan masalah yang berbeda.
Kelangsungan bisnis adalah tentang menjaga perusahaan tetap beroperasi selama gangguan. Hal ini mencakup komunikasi klien, alur kerja sementara, tanggung jawab staf, koordinasi pemasok, dan keputusan tentang layanan mana yang harus dilanjutkan meskipun sistem normal tidak tersedia.
Pemulihan bencana TI berfokus pada teknologi di balik pekerjaan tersebut. Hal ini menentukan bagaimana sistem, data, aplikasi, cadangan, dan akses admin akan dipulihkan sehingga bisnis dapat kembali ke operasi normal dengan aman.
Sebagai contoh, pertimbangkan gangguan CRM. Paket kelangsungan bisnis dapat menjelaskan bagaimana tim penjualan atau dukungan terus melayani pelanggan saat CRM tidak berfungsi. Paket pemulihan TI menjelaskan siapa yang menghubungi vendor, data mana yang perlu dipulihkan, cadangan atau ekspor mana yang tersedia, kredensial mana yang diperlukan, dan bagaimana tim mengonfirmasi sistem aman untuk digunakan kembali.
Bagi banyak UKM, celah tersebut baru terlihat saat terjadi insiden. Orang-orang tahu siapa yang akan menghubungi klien, tetapi tidak tahu siapa yang dapat memulihkan sistem penagihan. Mereka tahu cadangan itu ada, tetapi tidak tahu apakah tindakan pulihkan pernah diuji. Mereka tahu satu karyawan biasanya menangani TI, tetapi tidak tahu apa yang terjadi jika orang tersebut tidak tersedia atau di mana kata sandi admin tersimpan jika orang tersebut tidak dapat dihubungi.
Hal yang harus dicakup dalam paket pemulihan bencana TI
Paket pemulihan bencana TI yang kuat tidak harus terlalu panjang, tetapi harus cukup spesifik untuk dijalankan dalam situasi yang penuh tekanan.
Target waktu pemulihan
Recovery time objective, atau RTO, menentukan seberapa cepat suatu sistem harus dipulihkan. Sistem pembayaran mungkin perlu kembali berfungsi dalam hitungan jam, sementara dasbor pelaporan internal dapat menoleransi waktu gangguan yang lebih lama.
Tetapkan RTO berdasarkan dampak bisnis, bukan preferensi teknis, karena biaya waktu henti merupakan masalah bisnis sekaligus masalah teknis. Tanyakan sistem mana yang memengaruhi pendapatan, komitmen pelanggan, kewajiban hukum, keamanan, dan produktivitas karyawan.
Target titik pemulihan
Recovery point objective, atau RPO, menentukan seberapa banyak kehilangan data yang dapat diterima, yang kemudian membantu menetapkan strategi pencegahan kehilangan data (DLP) yang tepat. Jika suatu sistem memiliki RPO satu jam, cadangan atau replikasi harus mendukung pemulihan hingga waktu tersebut.
Jika RPO adalah satu hari, bisnis menerima celah yang lebih besar. RPO juga membantu menentukan frekuensi cadangan, karena semakin pendek RPO, semakin sering cadangan perlu dilakukan. Oleh karena itu, sistem penting memerlukan cadangan yang lebih sering daripada sistem berprioritas rendah.
Tingkat prioritas sistem
Tidak semua sistem harus dipulihkan pada saat yang sama. Paket pemulihan bencana bisnis kecil harus membagi sistem ke dalam tingkat prioritas.
- Tingkat 1: Sistem yang diperlukan untuk operasi inti, keamanan, komunikasi, atau pendapatan.
- Tingkat 2: Sistem penting yang dapat menoleransi waktu henti singkat.
- Tingkat 3: Sistem berprioritas lebih rendah yang dapat dipulihkan setelah bisnis stabil.
Sistem tingkat 1 yang umum dapat mencakup email, penyedia identitas, pengelola kata sandi, sistem keuangan, basis data pelanggan, penyimpanan cloud, dan platform komunikasi.
Strategi cadangan
Strategi cadangan harus menentukan:
- Apa yang dicadangkan dan seberapa sering
- Di mana cadangan tersimpan
- Siapa yang dapat mengaksesnya
- Bagaimana pemulihan diuji
NCSC juga telah menerbitkan(jendela baru) prinsip cadangan yang tahan terhadap ransomware untuk solusi cadangan cloud dan on-premise, dengan catatan bahwa data yang dicadangkan tidak tahan terhadap ransomware secara bawaan dan harus dinilai terhadap ancaman ransomware.
Strategi cadangan yang kuat biasanya mencakup cadangan luring atau tidak dapat diubah untuk data penting, pengujian rutin, langkah pemulihan yang terdokumentasi, dan kredensial terpisah untuk administrasi cadangan.
Peran dan tanggung jawab
Paket pemulihan bencana harus menyebutkan penanggung jawab, bukan hanya tugas. Jika satu orang memegang semua pengetahuan pemulihan, bisnis memiliki risiko personel serta risiko TI. Tentukan siapa yang:
- Memimpin pemulihan
- Memulihkan sistem
- Menghubungi vendor
- Menyetujui akses darurat
- Berkomunikasi secara internal
- Mendokumentasikan keputusan
Hal yang perlu ditentukan oleh paket pemulihan bencana TI
| Komponen | Hal yang dijawab |
| RTO | Seberapa cepat setiap sistem harus dipulihkan? |
| RPO | Berapa banyak data yang sanggup dihilangkan oleh bisnis? |
| Tingkat prioritas | Sistem mana yang harus dipulihkan terlebih dahulu, dan mana yang dapat menunggu? |
| Strategi cadangan | Apa yang dicadangkan, di mana tersimpan, dan apakah pemulihan telah diuji? |
| Peran dan tanggung jawab | Siapa yang memimpin pemulihan, memulihkan sistem, menghubungi vendor, dan menyetujui perubahan darurat? |
Pemulihan kredensial: skenario pemulihan bencana yang sering diabaikan
Pemulihan bencana sering kali berfokus pada data, server, dan cadangan. Namun dalam praktiknya, pemulihan dapat gagal karena tim tidak dapat mengakses sistem yang diperlukan untuk memulihkan operasi.
Pemulihan kredensial mempertanyakan:
- Siapa yang memiliki akses ke akun admin?
- Di mana kredensial cadangan tersimpan?
- Akun mana yang dapat memulihkan sistem penting?
- Apa yang terjadi jika kata sandi hilang, dikompromikan, atau dipegang oleh seseorang yang tidak tersedia?
- Apakah kredensial darurat dilindungi dan ditinjau?
- Apakah akses dapat dicabut dan ditetapkan kembali dengan cepat?
Jika kredensial cadangan tersimpan di peramban milik salah satu karyawan, kode pemulihan disimpan dalam catatan pribadi, atau kata sandi admin yang dibagikan beredar melalui obrolan, bisnis mungkin tidak dapat pulih sepenuhnya selama terjadi insiden.
A pengelola kata sandi bisnis membantu mengurangi risiko tersebut dengan memusatkan kredensial penting dalam brankas terenkripsi, menetapkan akses berdasarkan peran, dan memudahkan untuk mencabut atau menetapkan kembali akses ketika seseorang keluar atau tanggung jawab berubah. Proton Pass for Business membantu tim membuat kata sandi yang kuat, menyimpan kredensial dengan aman, menggunakan metode berbagi yang aman, dan menjaga agar akses sensitif tidak berada di luar obrolan dan spreadsheet.
Sebagai pengelola kata sandi untuk tim TI, Proton Pass mendukung pengelolaan kredensial terpusat, kebijakan kata sandi, berbagi yang aman, pelaporan dan log, penyediaan SCIM, serta integrasi SSO. Hal ini membuat pemulihan kredensial lebih mudah dikelola karena akses ke sistem penting tidak bergantung pada satu orang, satu profil peramban, atau satu kata sandi yang tidak terdokumentasi.
Templat paket pemulihan bencana
Paket pemulihan bencana berfungsi paling baik jika cukup spesifik untuk memandu tindakan selama pemadaman, tetapi cukup sederhana untuk digunakan oleh tim di bawah tekanan. Untuk UKM, templat harus berfokus pada hal-hal penting: apa yang perlu dipulihkan, seberapa cepat, dari cadangan mana, oleh siapa, dan dengan kredensial mana.
1. Cakupan
Tentukan sistem, layanan, lokasi, perangkat, dan data mana yang dicakup oleh paket.
Salinan templat: Paket pemulihan bencana TI ini mencakup sistem, data, layanan, kredensial, dan vendor yang diperlukan untuk memulihkan operasi penting [Nama Perusahaan] setelah gangguan teknologi.
2. Inventarisasi sistem penting
Cantumkan sistem yang diandalkan oleh bisnis dan tetapkan tingkat prioritas.
Salinan templat: Sistem penting akan digrupkan ke dalam Tingkat 1, Tingkat 2, dan Tingkat 3 berdasarkan dampak bisnis, recovery time objective, recovery point objective, dan ketergantungan pada sistem lain.
3. Target pemulihan
Tentukan RTO dan RPO untuk setiap sistem prioritas.
Salinan templat: Setiap sistem harus memiliki target recovery time objective dan recovery point objective yang terdokumentasi. Target ini harus ditinjau setidaknya setiap tahun dan setelah perubahan sistem yang besar.
4. Proses cadangan dan pemulihan
Dokumentasikan di mana cadangan tersimpan, seberapa sering cadangan dijalankan, siapa yang dapat mengaksesnya, dan bagaimana pengujian pemulihan berfungsi.
Salinan templat: Cadangan harus dilindungi dari akses yang tidak sah, disimpan secara terpisah dari sistem utama jika diperlukan, dan diuji secara berkala. Prosedur pemulihan harus didokumentasikan untuk sistem Tingkat 1.
5. Pemulihan kredensial dan akses
Tentukan di mana kredensial penting tersimpan dan siapa yang dapat mengaksesnya selama pemulihan.
Salinan templat: Kredensial admin, kredensial cadangan, kode pemulihan, dan akses vendor yang diperlukan untuk pemulihan bencana harus tersimpan dalam brankas terenkripsi yang disetujui. Akses harus dibatasi pada peran yang berwenang dan ditinjau setelah terjadi perubahan peran, proses offboarding, serta latihan pemulihan.
6. Peran dan eskalasi
Tentukan penanggung jawab pemulihan, pengganti, dan jalur eskalasi.
Salinan templat: Setiap peran pemulihan harus memiliki penanggung jawab utama dan penanggung jawab cadangan. Paket harus mengidentifikasi siapa yang memimpin pemulihan, siapa yang memulihkan sistem, siapa yang menghubungi vendor, siapa yang mengomunikasikan pembaruan, dan siapa yang menyetujui perubahan darurat.
7. Paket komunikasi
Tentukan bagaimana bisnis berkomunikasi secara internal dan eksternal selama gangguan TI.
Salinan templat: Selama acara pemulihan, pembaruan internal akan dibagikan melalui [kanal yang disetujui]. Komunikasi eksternal kepada pelanggan, vendor, perusahaan asuransi, atau regulator harus disetujui by [peran/tim].
8. Frekuensi pengujian dan peninjauan
Tentukan seberapa sering paket diuji dan diperbarui.
Salinan templat: Paket pemulihan bencana ini akan diuji setidaknya [setiap tahun/dua kali setahun] dan ditinjau setelah terjadi insiden besar, perubahan sistem, perubahan vendor, atau latihan pemulihan yang gagal.
Cara menguji paket pemulihan bencana TI
Paket pemulihan bencana hanya akan berguna jika telah diuji dalam kondisi yang menyerupai gangguan nyata. Cadangan yang ada tetapi tidak pernah dipulihkan hanyalah sebuah asumsi. Peran pemulihan yang hanya dipahami oleh satu orang tetap menjadi ketergantungan. Kredensial admin yang tidak dapat ditemukan oleh siapa pun saat terjadi gangguan akan menjadi penghambat.
Pada awalnya, pengujian tidak harus rumit. Bagi sebagian besar UKM, tujuannya adalah membuktikan bahwa bisnis dapat memulihkan sistem yang tepat, dengan orang yang tepat, menggunakan kredensial yang tepat, dalam jangka waktu yang realistis.
1. Latihan tabletop
Pilih skenario yang mungkin terjadi, seperti ransomware yang memengaruhi file yang dibagikan, gangguan penyimpanan cloud, penghapusan data pelanggan yang tidak disengaja, atau hilangnya akses secara tiba-tiba ke akun admin. Lalui apa yang akan dilakukan tim dalam satu jam pertama, siapa yang akan memimpin, vendor mana yang akan dihubungi, sistem mana yang akan diprioritaskan, dan informasi apa yang akan hilang.
2. Uji pemulihan
Pilih file penting, basis data, kotak surat, atau ekspor sistem dan konfirmasikan bahwa file tersebut dapat dipulihkan ke kondisi yang dapat digunakan. Periksa apakah data yang dipulihkan cukup baru, apakah izin akses masih berfungsi, dan apakah tim mengetahui lokasi cadangan disimpan.
3. Lakukan pengujian secara berkala
Sebagai acuan praktis, UKM harus menguji paket ini setidaknya sekali setahun, sejalan dengan panduan NIST dalam Special Publication 800-34 Revisi 1(jendela baru), dan lebih sering setelah terjadi perubahan sistem atau vendor besar.
4. Uji pemulihan kredensial
Konfirmasikan bahwa orang yang berwenang dapat mengakses akun admin cadangan, akun admin cloud, portal vendor, kode pemulihan, dan kredensial darurat tanpa bergantung pada peramban, catatan pribadi, atau ingatan salah satu karyawan. Tujuannya bukan untuk mengekspos kata sandi sensitif secara tidak perlu. Tujuannya adalah untuk mengonfirmasi bahwa model akses tetap berfungsi saat bisnis berada di bawah tekanan.
Setelah setiap pengujian, dokumentasikan apa yang gagal, apa yang memakan waktu terlalu lama, serta tetapkan orang tertentu dan tenggat waktu untuk setiap perbaikan. Pengujian yang baik bukanlah pengujian yang semuanya berjalan sempurna. Melainkan pengujian yang mengungkapkan celah saat bisnis masih memiliki waktu untuk memperbaikinya.
Membangun pemulihan berbasis sistem, data, dan akses
Paket pemulihan bencana TI yang berguna memberikan urutan pemulihan kepada bisnis, serangkaian penanggung jawab, pandangan realistis tentang waktu henti yang dapat diterima, dan cara untuk mempertahankan kelangsungan bisnis serta memulihkan akses ke sistem yang menjaga pekerjaan tetap berjalan.
Bagi UKM, hal ini dapat menjadi pembeda antara gangguan singkat dan pemadaman yang berkepanjangan. Jika email, perangkat lunak keuangan, penyimpanan cloud, sistem pelanggan, atau akun admin tidak tersedia, tim perlu mengetahui apa yang dipulihkan terlebih dahulu, siapa yang dapat bertindak, dan kredensial mana yang diperlukan untuk memulihkan akses dengan aman.
Inilah mengapa perencanaan pemulihan harus mencakup sistem, data, dan akses secara bersamaan. Cadangan dapat memulihkan file, tetapi kredensial adalah hal yang memungkinkan tim mendapatkan kembali kendali atas sistem yang diperlukan untuk pulih. Masuk admin, portal vendor, akun cadangan, kode pemulihan, dan kredensial operasional yang dibagikan semuanya perlu dilindungi, diatur, dan tersedia bagi orang yang tepat ketika terjadi kesalahan.
Pengelola kata sandi bisnis membantu memperkuat bagian dari paket tersebut. Dengan kredensial penting tersimpan di brankas kata sandi terenkripsi dan hanya dibagikan kepada orang yang berwenang, bisnis menjadi kurang bergantung pada peramban, catatan pribadi, atau ingatan satu karyawan selama acara pemulihan.
