Satu pelayan yang gagal, serangan ransomware, kebakaran kecil di bilik server, atau gangguan pembekal awan boleh menghentikan urusan yang biasanya dianggap rutin. Apabila sistem pesanan, rekod pelanggan, komunikasi pasukan, atau peralatan operasi tidak dapat diakses, kos sebenar bukan sekadar kos membaiki teknologi. Pemulihan bencana menentukan sama ada organisasi anda dapat terus berkhidmat, membuat keputusan, dan mengekalkan kepercayaan pelanggan ketika tekanan berada pada tahap tertinggi.

Bagi pemimpin operasi dan teknologi, persoalannya bukan sama ada gangguan akan berlaku. Persoalan yang lebih berguna ialah: berapa lama organisasi boleh beroperasi tanpa sistem kritikal, dan apakah data yang boleh diterima untuk hilang? Jawapan kepada dua soalan ini perlu diterjemahkan kepada pelan teknikal, proses kerja, tanggungjawab yang jelas, dan ujian yang konsisten.

Apa yang dimaksudkan dengan pemulihan bencana?

Pemulihan bencana ialah strategi dan keupayaan untuk memulihkan sistem IT, data, aplikasi, rangkaian, serta proses operasi penting selepas insiden besar. Insiden ini boleh berpunca daripada ancaman siber, kegagalan perkakasan, kesilapan manusia, gangguan elektrik, bencana alam, atau kegagalan perkhidmatan pihak ketiga.

Ia bukan sekadar membuat salinan data. Sandaran data menjawab persoalan sama ada fail masih boleh dipulihkan. Pemulihan bencana pula menjawab persoalan yang lebih luas: sistem mana perlu didahulukan, di mana ia akan dijalankan, siapa yang mengaktifkan pelan, bagaimana pengguna kembali bekerja, dan berapa lama proses itu mengambil masa.

Pelan kesinambungan perniagaan juga berkait rapat, tetapi skopnya lebih besar. Ia meliputi cara perniagaan terus beroperasi semasa gangguan, termasuk komunikasi pelanggan, proses manual, pembekal alternatif, dan pengurusan tenaga kerja. Pemulihan bencana menjadi komponen teknologi yang membolehkan pelan kesinambungan itu berfungsi.

Dua ukuran yang perlu dipersetujui sebelum memilih teknologi

Banyak organisasi bermula dengan membeli kapasiti sandaran tambahan. Pendekatan itu boleh membantu, tetapi tanpa sasaran pemulihan yang dipersetujui, pelaburan mungkin tidak sepadan dengan risiko sebenar.

Recovery Time Objective atau RTO ialah tempoh maksimum sistem boleh tidak tersedia. Contohnya, aplikasi pengebilan mungkin perlu pulih dalam empat jam, manakala arkib dokumen mungkin boleh menunggu sehingga keesokan hari.

Recovery Point Objective atau RPO pula menentukan jumlah kehilangan data yang boleh diterima, diukur mengikut masa. RPO selama 15 minit bermaksud organisasi mesti mempunyai mekanisme yang mengehadkan kehilangan data kepada maksimum 15 minit sebelum insiden. RPO 24 jam mungkin memadai untuk sistem tertentu, tetapi tidak untuk transaksi pesanan atau rekod makmal yang berubah sepanjang hari.

RTO dan RPO tidak sepatutnya ditentukan oleh pasukan IT sahaja. Pemilik proses, kewangan, operasi, pematuhan, dan pengurusan perlu menyatakan kesan perniagaan jika sistem tergendala atau data hilang. Dari situ, organisasi boleh membezakan antara sistem yang benar-benar kritikal dengan sistem yang hanya kerap digunakan.

Kenal pasti kebergantungan yang sering terlepas pandang

Aplikasi jarang berfungsi secara bersendirian. Sistem pengurusan pelanggan mungkin bergantung pada pangkalan data, identiti pengguna, sambungan internet, e-mel, storan fail, integrasi pembayaran, dan peranti di lokasi. Memulihkan aplikasi tanpa memulihkan kebergantungan tersebut hanya menghasilkan sistem yang masih tidak boleh digunakan.

Mulakan dengan inventori yang praktikal. Senaraikan aplikasi, pelayan, pangkalan data, peranti rangkaian, akaun pentadbir, lesen perisian, integrasi pihak ketiga, dan lokasi data. Kemudian kaitkan setiap aset dengan proses perniagaan yang disokong serta pemilik yang bertanggungjawab membuat keputusan.

Bagi organisasi kejuruteraan atau makmal, skopnya mungkin merangkumi sistem pengumpulan data instrumen, komputer kawalan, fail konfigurasi, perisian analisis khusus, dan rekod kalibrasi. Peralatan boleh kembali beroperasi, tetapi operasi masih tertangguh jika konfigurasi atau data pengesahan tidak tersedia. Ini sebabnya pemulihan perlu direka berdasarkan aliran kerja sebenar, bukan semata-mata senarai aset IT.

Bina seni bina pemulihan yang sepadan dengan tahap risiko

Tiada satu model yang sesuai untuk semua organisasi. Pilihan terbaik bergantung pada RTO, RPO, jumlah data, kebolehan pasukan dalaman, keperluan pematuhan, dan bajet yang tersedia.

Untuk sistem yang kurang kritikal, sandaran yang disulitkan dan disimpan di lokasi berasingan atau awan mungkin mencukupi. Pendekatan ini lebih menjimatkan, tetapi proses membina semula persekitaran boleh mengambil masa. Bagi sistem yang memerlukan pemulihan lebih pantas, replikasi data dan infrastruktur ke persekitaran sekunder boleh mengurangkan masa henti dengan ketara.

Sistem paling kritikal mungkin memerlukan persekitaran sedia aktif atau hampir sedia aktif. Kosnya lebih tinggi kerana sumber perlu tersedia sebelum insiden berlaku, tetapi ia boleh menyokong pertukaran operasi dalam tempoh yang jauh lebih singkat. Keputusan ini perlu dibuat berdasarkan kos masa henti, bukan hanya harga infrastruktur.

Satu prinsip yang berguna ialah mengekalkan beberapa salinan data pada media atau lokasi yang berbeza, termasuk satu salinan yang diasingkan daripada rangkaian biasa. Salinan yang tidak boleh diubah atau dihapuskan dengan mudah memberi perlindungan tambahan terhadap ransomware. Namun, teknologi ini tetap perlu disertai kawalan akses, pengesahan berbilang faktor, pemantauan, dan pengurusan identiti yang baik. Penyerang sering mensasarkan sistem sandaran terlebih dahulu.

Pelan pemulihan bencana mesti boleh dilaksanakan ketika tekanan tinggi

Dokumen yang panjang tetapi sukar dicari tidak membantu semasa insiden. Pelan yang baik menggunakan arahan jelas, pemilik tugas yang dinamakan, nombor hubungan terkini, dan urutan pemulihan yang mudah diikuti.

Pelan tersebut perlu menerangkan siapa yang berkuasa mengisytiharkan bencana, siapa yang berhubung dengan pihak pengurusan dan pelanggan, serta siapa yang mengesahkan sistem selamat untuk digunakan semula. Ia juga perlu menyatakan prosedur eskalasi kepada pembekal awan, telco, vendor perisian, pasukan keselamatan, atau penyedia sokongan teknikal.

Jangan abaikan komunikasi. Pasukan dalaman memerlukan maklumat yang tepat tentang sistem yang terjejas, proses alternatif, dan masa kemas kini seterusnya. Pelanggan pula tidak semestinya memerlukan semua butiran teknikal, tetapi mereka perlu tahu kesan terhadap perkhidmatan dan tindakan yang sedang diambil. Komunikasi yang tenang dan konsisten membantu mengurangkan kekeliruan serta mengekalkan keyakinan.

Ujian ialah bukti, bukan formaliti

Sandaran yang berjaya dibuat tidak semestinya boleh dipulihkan dengan berjaya. Fail mungkin rosak, akses mungkin tiada, versi aplikasi mungkin tidak serasi, atau pasukan mungkin tidak mengetahui langkah yang perlu diikuti. Sebab itu ujian pemulihan perlu menjadi sebahagian daripada operasi, bukan aktiviti tahunan yang dilakukan untuk memenuhi audit.

Ujian meja sesuai untuk menyemak peranan, keputusan, dan komunikasi melalui simulasi senario. Ujian teknikal pula mengesahkan sama ada data, pelayan, aplikasi, dan konfigurasi boleh dipulihkan dalam masa sasaran. Dari semasa ke semasa, lakukan latihan yang lebih realistik dengan memulihkan beban kerja terpilih ke persekitaran alternatif dan membenarkan pengguna utama mengesahkan fungsi kritikal.

Setiap ujian perlu menghasilkan penemuan yang boleh ditindaklanjuti. Mungkin masa pemulihan melebihi RTO, dokumentasi tidak lengkap, atau satu integrasi penting tidak termasuk dalam skop. Kelemahan yang ditemui dalam latihan jauh lebih murah untuk diperbaiki berbanding kelemahan yang ditemui ketika serangan sebenar.

Bila perlu mendapatkan sokongan pakar?

Organisasi dengan pasukan IT dalaman yang kuat masih boleh mendapat manfaat daripada pandangan luar, khususnya apabila persekitaran melibatkan sistem lama, aplikasi tersuai, keperluan keselamatan tinggi, atau peralatan khusus. Reka bentuk pemulihan memerlukan gabungan kepakaran infrastruktur, keselamatan siber, aplikasi, rangkaian, dan proses operasi.

TT Synergy Resources boleh membantu organisasi menilai keutamaan pemulihan, mereka bentuk penyelesaian mengikut keperluan kerja, melaksanakan kawalan yang sesuai, melatih pengguna, dan menyokong operasi selepas pelaksanaan. Pendekatan berasaskan keperluan ini penting kerana pelan yang terlalu mahal akan sukar dikekalkan, manakala pelan yang terlalu minimum mungkin gagal ketika ia paling diperlukan.

Mulakan dengan satu perbincangan yang jujur tentang sistem yang paling menjejaskan pelanggan, hasil, keselamatan, atau pematuhan jika ia terhenti hari ini. Dari situ, pemulihan bencana boleh berubah daripada dokumen kecemasan kepada keupayaan operasi yang memberi keyakinan setiap hari.