9.5 Pemulihan bencana dan kesinambungan bisnis

Tinjauan dan motivasi

Cepat atau lambat, sesuatu yang tidak Anda rencanakan akan menjatuhkan sistem: pemadaman cloud seluruh wilayah, DROP TABLE yang salah ketik, banjir di pusat data, ledakan ransomware, atau pemasok yang lenyap semalam. Pertanyaannya bukan apakah gangguan tiba, tetapi seberapa cepat Anda pulih dan berapa banyak yang hilang dalam prosesnya. Bab ini membahas bersiap untuk hari buruk sebelum ia datang.

Dua disiplin menjawab kesiapan itu, dan keduanya tidak sama. Perencanaan kesinambungan bisnis (BCP) menjaga seluruh organisasi berfungsi melalui gangguan: orang, kantor, komunikasi, penggajian, dan proses bisnis kritis yang diandalkan pelanggan. Pemulihan bencana (DR) adalah pekerjaan teknis yang lebih sempit memulihkan sistem TI dan data setelah gagal. Kesinambungan adalah tujuan; pemulihan salah satu caranya. Anda dapat memulihkan setiap server dan tetap mengecewakan pelanggan jika tak ada yang tahu siapa yang boleh mendeklarasikan bencana atau bagaimana menjangkau mereka. Bab ini memperlakukan DR sebagai praktik rekayasa dan BCP sebagai bingkai bisnis yang dilayaninya.

Bagi tim besar, taruhannya berskala bersama Anda. Enterprise memikul kewajiban pemulihan regulasi, jejak multiwilayah, dan risiko konsentrasi pada segelintir pemasok. Pemerintah memikul kewajiban hukum mempertahankan fungsi esensial bagi warga, dikodifikasi sebagai kesinambungan operasi. Keduanya beroperasi di bawah pengawasan di mana rencana yang tak teruji adalah liabilitas yang akan Anda temukan pada saat terburuk. Pemulihan adalah tempat keandalan (bab 9.1) dan respons insiden (bab 9.3) bertemu pertanyaan lebih sulit bertahan dari kegagalan yang tak dapat Anda rancang hilang.

Prinsip utama

Kesinambungan lebih luas daripada pemulihan. Memulihkan server tidak sama dengan menjaga bisnis berjalan.
Dua angka mendorong segalanya. Recovery time objective (RTO) dan recovery point objective (RPO), ditetapkan dari dampak bisnis, menakar setiap keputusan.
Cadangan yang tak teruji bukan cadangan. Pemulihan yang tak pernah Anda lakukan adalah harapan, bukan kapabilitas.
Asumsikan cadangan adalah sasaran. Ransomware memburu cadangan Anda lebih dulu, jadi jaga salinan tak berubah dan offline.
Bangun ulang dari kode, bukan dari ingatan. Jika Anda tak dapat menciptakan ulang infrastruktur dari sumber, Anda tak dapat memulihkannya dengan andal.
Petakan apa yang Anda andalkan. Anda pulih secepat dependensi hulu paling lambat Anda.
Ukur pemulihan seperti sistem lain. RTO dan RPO aktual dari latihan nyata, bukan angka yang Anda tulis di slide.

Rekomendasi

Tetapkan RTO dan RPO dari analisis dampak bisnis

Setiap keputusan pemulihan turun dari dua angka, jadi benarkan itu lebih dulu. Recovery time objective (RTO) adalah berapa lama sistem dapat mati sebelum kerugiannya tidak dapat diterima. Recovery point objective (RPO) adalah berapa banyak data yang mampu Anda relakan hilang, diukur sebagai usia salinan baik terakhir yang dapat Anda pulihkan. Buku besar pembayaran mungkin menuntut RTO menit dan RPO nyaris nol; dasbor analitik internal mungkin menoleransi sehari masing-masing. Anda tak dapat menetapkan ini di rekayasa. Turunkan dari analisis dampak bisnis (BIA) yang memeringkat proses bisnis menurut biaya gangguannya dan menelusuri masing-masing kembali ke sistem dan data yang dibutuhkannya. Tujuan lebih ketat berbiaya lebih, jadi BIA yang menghentikan Anda menyepuh emas layanan remeh dan kurang melindungi yang kritis.

Lakukan cadangan dengan benar: aturan 3-2-1, imutabilitas, dan pengujian

Cadangan adalah lantai di bawah setiap strategi pemulihan, dan sebagian besar organisasi melakukannya lebih buruk daripada yang mereka kira. Ikuti disiplin cadangan yang dikenal sebagai aturan 3-2-1: simpan setidaknya tiga salinan data Anda, pada dua media atau sistem berbeda, dengan satu salinan di luar lokasi. Ancaman modern menambah dua persyaratan lagi. Jaga setidaknya satu salinan tak berubah (tulis-sekali, tak dapat dihapus selama jendela retensi) dan idealnya offline atau air-gapped, karena ransomware kini sengaja mengenkripsi atau menghapus cadangan yang terjangkau sebelum mengumumkan dirinya. Di atas segalanya, uji pemulihan sesuai jadwal. Cadangan yang tak teruji bukan cadangan, ia asumsi tak teruji, dan kegagalan yang Anda temukan dalam latihan (arsip rusak, kunci enkripsi hilang, cadangan volume yang salah) persis yang akan menamatkan Anda dalam peristiwa nyata.

Pilih strategi DR di sepanjang spektrum biaya-versus-kecepatan

Strategi DR menukar uang dengan kecepatan pemulihan, dan Anda harus memilih per sistem berdasarkan RTO dan RPO-nya alih-alih membeli satu tingkat untuk semuanya. Empat pola menjangkarkan spektrum. Cadangan dan pemulihan termurah dan terlambat: Anda membangun ulang dari cadangan ketika bencana menyerang, dengan RTO jam hingga hari. Pilot light menjaga inti minimal (basis data mereplikasi, konfigurasi inti di tempat) tetap hangat tetapi berskala kecil, siap memperluas. Warm standby menjalankan salinan lebih kecil yang selalu hidup dari seluruh tumpukan yang Anda skalakan ke atas saat failover, memangkas RTO menjadi menit. Multi-situs aktif-aktif menjalankan kapasitas penuh di dua lokasi atau lebih yang melayani lalu lintas langsung, memberi RTO nyaris nol dengan biaya dan kompleksitas tertinggi. Cocokkan tingkat dengan angka yang disetujui bisnis, dan jangan membayar harga aktif-aktif untuk sistem yang menoleransi pilot light.

Replikasi data dengan mempertimbangkan trade-off konsistensi

Kecepatan pemulihan bergantung pada seberapa mutakhir data standby Anda, dan di sini Anda mewarisi masalah sulit sistem terdistribusi (bab 3.3). Replikasi sinkron mengonfirmasi setiap penulisan di lokasi kedua sebelum mengakuinya, memberi RPO nyaris nol dengan biaya latensi tulis tambahan dan batas keras jarak. Replikasi asinkron mengakui secara lokal dan mengirim perubahan sesudahnya, sehingga cepat dan fleksibel secara geografis tetapi meninggalkan jendela lag replikasi yang akan Anda hilangkan saat failover. Tak ada pilihan gratis: konsistensi lebih kuat berbiaya latensi, konsistensi lebih lemah berbiaya data. Putuskan per penyimpanan data dari RPO-nya, dan ketahui lag replikasi tipikal Anda, karena lag itu RPO nyata Anda pada hari buruk, bukan angka di dokumen desain.

Bangun ulang dari kode dengan infrastructure as code

Anda tak dapat memulihkan lingkungan yang disediakan dengan tangan secara andal, karena tak ada yang ingat setiap klik. Definisikan lingkungan Anda sebagai infrastructure as code (bab 8.2) agar seluruh tumpukan dapat diciptakan ulang dari sumber terkontrol versi dalam keadaan yang diketahui baik. Ini mengubah pemulihan dari proyek arkeologi menjadi proses pipeline yang dapat diulang, menjaga wilayah standby Anda jujur (ia menyimpang lebih sedikit ketika keduanya dibangun dari kode yang sama), dan memberi cara bersih mendirikan infrastruktur pemulihan di akun atau wilayah segar setelah kompromi. Simpan kode, rujukan rahasia, dan runbook di tempat yang selamat dari hilangnya lingkungan primer Anda.

Petakan dependensi sebelum Anda membutuhkannya

Sistem gagal dalam jaring, bukan terisolasi, dan pemulihan macet pada dependensi yang Anda lupakan. Petakan apa yang dibutuhkan setiap sistem kritis untuk berfungsi: layanan hulu, DNS, identitas dan autentikasi, otoritas sertifikat, antrean pesan, dan API pihak ketiga serta penyedia SaaS. Catat urutan pemulihan, karena menaikkan aplikasi sebelum basis data atau penyedia identitasnya hanya menghasilkan pemadaman kedua. Beri perhatian khusus pada pemasok eksternal, karena pemulihan Anda dibatasi oleh pemulihan mereka dan Anda mungkin tak punya visibilitas ke dalamnya. Pemetaan ini terkait langsung dengan ketahanan dan degradasi anggun (bab 3.5): makin sedikit dependensi keras yang dimiliki sistem, makin cepat ia kembali.

Uji pemulihan sebagai praktik, bukan peristiwa

Rencana DR yang tak pernah Anda latih adalah fiksi. Bangun tangga pengujian. Latihan tabletop menelusuri tim melalui skenario di atas kertas untuk menemukan celah dalam peran, keputusan, dan komunikasi. Game day menyuntikkan kegagalan terkendali nyata ke lingkungan mirip-langsung. Latihan failover penuh benar-benar beralih ke situs pemulihan dan berjalan di atasnya. Jalankan ini pada irama, putar skenario (termasuk hilangnya orang atau pemasok kunci), dan ukur hasilnya: tangkap RTO dan RPO aktual yang Anda capai dan bandingkan dengan target. Selisih antara pemulihan terukur dan terjanji adalah metrik keandalan paling jujur yang Anda miliki, dan menutupnya seluruh maksud latihan.

Rencanakan pemulihan siber sebagai skenario tersendiri

Ransomware dan serangan siber destruktif mematahkan asumsi DR biasa, jadi perlakukan terpisah. Dalam bencana alam data Anda utuh di tempat lain; dalam peristiwa ransomware data dan sering cadangan Anda adalah senjatanya, dan lingkungan pemulihan Anda sendiri mungkin terkompromi. Rencanakan pemulihan clean-room: lingkungan terisolasi dan tepercaya tempat Anda memulihkan dari salinan tak berubah, memindai intrusi, dan membangun ulang identitas dan kredensial sebelum menghubungkan apa pun kembali. Ketahui cadangan mana titik terakhir yang diketahui bersih, dan harapkan menemukannya memakan waktu forensik yang tak pernah dianggarkan RTO biasa Anda. Di sinilah salinan tak berubah dan offline memperoleh biayanya, dan ia terhubung erat dengan manajemen insiden (bab 9.3) dan dengan kewajiban kepatuhan dan tata kelola untuk penanganan pelanggaran (bab 4.6).

Trade-off: kelebihan dan kekurangan

Strategi DR	Kelebihan	Kekurangan
Cadangan dan pemulihan	Termurah; sederhana; biaya berjalan rendah	RTO lambat (jam hingga hari); RPO lebih besar
Pilot light	Biaya rendah; data inti hangat dan siap	Penskalaan ke atas manual; pemulihan masih butuh waktu nyata
Warm standby	RTO cepat (menit); tumpukan penuh terbukti	Biaya berjalan lingkungan kedua yang hidup
Multi-situs aktif-aktif	RTO nyaris nol; tak ada kegagalan situs tunggal	Biaya dan kompleksitas tertinggi; konsistensi sulit
Replikasi sinkron	RPO nyaris nol	Latensi tulis; terbatas jarak; kopling lebih ketat
Replikasi asinkron	Cepat, fleksibel, bebas secara geografis	Jendela kehilangan data sama dengan lag replikasi

Ketegangan sentralnya adalah kecepatan pemulihan dan kesegaran data sama-sama berbiaya uang dan kompleksitas, dan tak ada yang gratis pada tingkat mana pun. Selesaikan per sistem alih-alih per organisasi: biarkan analisis dampak bisnis menetapkan RTO dan RPO untuk setiap sistem kritis, lalu beli persis strategi yang memenuhinya. Membelanjakan uang aktif-aktif untuk perkakas pelaporan membuat kelaparan buku besar yang membutuhkannya, dan sebaliknya adalah kelalaian. Disiplinnya adalah mencocokkan pengeluaran dengan angka yang dimiliki bisnis, dan meninjau ulang kecocokan itu seiring pentingnya sistem berubah.

Pertanyaan untuk didiskusikan dengan tim Anda

Berapa RTO dan RPO untuk setiap sistem kritis Anda, dan siapa di bisnis yang menyetujuinya? Jika rekayasa menciptakan angka ini sendirian, itu tebakan, dan tebakan didanai entah terlalu murah hati atau tidak sama sekali. Recovery time dan recovery point objective harus jatuh dari analisis dampak bisnis yang memeringkat proses menurut biaya gangguannya, sehingga buku besar mendapat menit dan wiki internal mendapat sehari. Bawa pentahapan Anda saat ini dan tanyakan apakah orang yang akuntabel atas setiap proses bisnis benar-benar akan menerima kehilangan data dan downtime yang telah Anda rancang. Dalam organisasi besar percakapan ini yang mencegah kesalahan mahal melindungi semuanya sama, yang tidak melindungi apa pun dengan baik. Jika tak ada orang di luar rekayasa yang dapat menamai angkanya, Anda belum punya tujuan, Anda punya harapan.
Kapan terakhir Anda melakukan pemulihan nyata, dan apakah Anda mengukur RTO dan RPO aktual yang Anda capai? Cadangan yang tak pernah Anda pulihkan adalah asumsi tak teruji, dan mode kegagalan yang membunuh Anda (arsip rusak, kunci enkripsi hilang, snapshot volume yang salah, dependensi yang tak mau naik) muncul hanya ketika Anda mencoba. Bawa tanggal dan hasil latihan failover penuh terakhir Anda, bukan tabletop terakhir, dan selisih antara pemulihan yang Anda capai dan yang Anda janjikan. Bagi tim besar, satu pemulihan berhasil satu sistem tidak membuktikan yang lain, jadi tanyakan pecahan sistem kritis yang telah dipulihkan ujung ke ujung dalam setahun terakhir. Selisih terukur adalah angka keandalan paling jujur Anda, dan jika Anda tak dapat menyatakannya, rencana Anda fiksi sampai terbukti sebaliknya.
Jika ransomware mengenkripsi produksi Anda dan mencapai cadangan malam ini, apa salinan terakhir Anda yang diketahui bersih dan di mana Anda akan membangun ulang? Pemulihan bencana biasa mengasumsikan data Anda aman di tempat lain, dan serangan siber destruktif mematahkan persis asumsi itu dengan menjadikan data dan cadangan Anda senjata. Tanyakan apakah setidaknya satu salinan cadangan tak berubah dan offline, bagaimana Anda akan mengidentifikasi titik pemulihan bersih terakhir, dan dari mana lingkungan clean-room tepercaya akan datang ketika produksi sendiri terkompromi. Skenario ini membutuhkan waktu forensik yang tak pernah dianggarkan RTO normal Anda, jadi bawa perkiraan jujur berapa lama menemukan titik bersih sebenarnya. Untuk tim enterprise dan pemerintah ini juga peristiwa kepatuhan (bab 4.6) dengan jam pemberitahuan pelanggaran berjalan paralel. Jika jawabannya “kami akan memulihkan cadangan terbaru,” Anda belum merencanakan ini sama sekali.
Sistem Anda yang mana membayar tingkat pemulihan yang tidak dibenarkan analisis dampak bisnisnya, dan mana yang kurang terlindungi dengan berbahaya? Kecepatan pemulihan dan kesegaran data sama-sama berbiaya uang di setiap tingkat, sehingga kebijakan seragam entah memboroskan anggaran aktif-aktif pada perkakas pelaporan atau membuat kelaparan buku besar yang benar-benar membutuhkannya. Tarikan yang bersaing nyata: satu tingkat standar jauh lebih sederhana dioperasikan banyak tim, sementara pentahapan per sistem mencocokkan pengeluaran dengan nilai tetapi menuntut kurasi berkelanjutan seiring pentingnya sistem bergeser. Bawa strategi DR saat ini untuk setiap sistem kritis, RTO dan RPO yang ditargetnya, biaya bulanan standby dan replikasinya, dan tanggal pentahapan terakhir ditinjau ulang terhadap analisis dampak segar. Dalam pengaturan enterprise atau pemerintah, tingkat yang tak cocok berlipat di berbagai wilayah dan audit akan meminta Anda membenarkan baik uang yang Anda belanjakan maupun paparan yang Anda terima, jadi tagihan aktif-aktif tak terjelaskan dan layanan kritis tak terlindungi sama sulitnya dibela.
Apakah Anda benar-benar tahu urutan pemulihan sistem kritis Anda, dan seberapa jauh pemulihan Anda bergantung pada pemasok yang tak dapat Anda uji? Sistem gagal dalam jaring, bukan terisolasi, dan pemulihan macet pada dependensi yang tak dipetakan siapa pun: naikkan aplikasi sebelum basis data, penyedia identitas, atau DNS-nya dan Anda hanya menghasilkan pemadaman kedua. Memetakan dependensi membosankan dan petanya menjadi basi, tetapi alternatifnya menemukan urutan pemulihan secara langsung selama failover, dan risiko konsentrasi pada segelintir penyedia SaaS tetap tak terlihat sampai mereka gagal bersama dan membatasi pemulihan Anda pada pemulihan mereka. Bawa peta dependensi saat ini, urutan pemulihan terdokumentasi, dan daftar pemasok eksternal dengan komitmen pemulihan yang dinyatakan dan apakah Anda pernah memvalidasi salah satunya. Untuk organisasi besar atau publik, kesinambungan pemasok dan risiko konsentrasi makin menjadi perhatian pengadaan dan regulasi, jadi kewajiban pemulihan itu termasuk dalam kontrak dalam bentuk yang dapat Anda audit alih-alih dalam pemasaran vendor.
Jika Anda memulihkan setiap server malam ini, apakah bisnis akan benar-benar terus berjalan, dan siapa yang berwenang mendeklarasikan bencana? Pemulihan bencana memulihkan TI, tetapi kesinambungan bisnis menjaga organisasi berfungsi: orang, komunikasi, penggajian, dan keputusan yang bergantung pada seseorang yang punya wewenang membuatnya. Anda dapat memulihkan setiap sistem dan tetap mengecewakan pelanggan jika tak ada yang tahu siapa yang dapat mendeklarasikan bencana atau bagaimana menjangkau staf ketika kanal normal juga mati. Rekayasa memiliki pemulihan, namun kesinambungan mencakup fasilitas, SDM, komunikasi, dan suksesi pimpinan, dan sambungan antardepartemen itu persis tempat rencana diam-diam membusuk. Bawa wewenang deklarasi dan rantai eskalasi, rencana komunikasi cadangan, pengganti bernama dan fasilitas alternatif, dan tanggal sisi bisnis (bukan hanya TI) terakhir melatih rencana. Pemerintah memikul kewajiban hukum kesinambungan operasi dengan pengganti bernama dan fungsi esensial, dan enterprise menghadapi kewajiban kesinambungan regulasi, sehingga keduanya dinilai dari apakah bisnis bertahan pada hari buruk, bukan sekadar server.

Lensa sektor

Startup. Dengan tim kecil dan sedikit runway, Anda tak mampu wilayah kedua yang panas, jadi bersikaplah sengaja tentang bagian murah yang tetap menyelamatkan Anda. Tetapkan satu tingkat pemulihan jujur, ikuti aturan 3-2-1 dengan snapshot otomatis dan setidaknya satu salinan tak berubah yang tak dapat dihapus admin Anda sendiri, dan simpan seluruh lingkungan sebagai infrastructure as code agar Anda dapat membangun ulang dari sumber. Lewati rencana rumit dan sebagai gantinya jalankan satu pemulihan nyata ke lingkungan awal setiap kuartal, karena satu latihan terukur mengajari Anda lebih banyak daripada binder yang tak dibaca siapa pun.

Bisnis kecil. Tanpa spesialis kesinambungan khusus dan anggaran ketat, perlakukan pemulihan sebagai sesuatu yang Anda beli alih-alih bangun. Bersandarlah pada cadangan terkelola, snapshot, dan replikasi lintas wilayah penyedia cloud Anda daripada mendirikan infrastruktur DR pesanan, dan pilih vendor yang cadangannya tak berubah dan yang proses pemulihannya dapat Anda jalankan sendiri. Bingkai seluruh latihan di sekitar dua pertanyaan yang dapat Anda jawab tanpa spesialis: berapa banyak data yang boleh kami hilangkan, dan berapa lama kami boleh mati, dan buktikan satu pemulihan berfungsi sebelum Anda memercayainya.

Enterprise. Pada skala besar masalahnya tata kelola portofolio lintas banyak tim: analisis dampak bisnis yang menetapkan RTO dan RPO untuk setiap layanan, strategi pemulihan bertingkat dari cadangan-dan-pemulihan hingga aktif-aktif, dan pandangan pusat atas dependensi hulu dan pemasok termasuk risiko konsentrasi. Anggarkan biaya standby, replikasi, dan salinan tak berubah secara eksplisit, jalankan failover penuh yang disaksikan regulator pada irama, dan ukur pemulihan aktual terhadap target sebagai metrik keandalan terlacak. Pelihara pemulihan siber sebagai program tersendiri dengan salinan vault tak berubah dan runbook clean-room, diuji terpisah dari latihan bencana alam.

Pemerintah. Aturan pengadaan, transparansi, dan akuntabilitas publik membentuk setiap pilihan, dan kesinambungan sering kewajiban hukum alih-alih preferensi. Bangun program kesinambungan operasi yang mengidentifikasi fungsi esensial, mengurutkan pemulihannya, dan menamai pengganti serta fasilitas alternatif agar keputusan tak pernah macet karena tak ada orang berwenang, dan selaraskan dengan panduan yang diakui seperti NIST SP 800-34 dalam mendukung kewajiban FISMA. Simpan salinan cadangan air-gapped, definisikan infrastructure as code untuk bangun ulang di wilayah alternatif, dan jalankan latihan penuh tahunan plus latihan tabletop ransomware yang hasil terukurnya Anda laporkan kepada badan pengawas sebagai bukti bahwa layanan esensial selamat.

Contoh

Startup. Perusahaan SaaS dua belas orang tak mampu wilayah kedua yang panas, jadi ia bersikap sengaja tentang bagian murah. Ia menetapkan satu tingkat jujur: RTO empat jam, RPO lima belas menit untuk basis data pelanggan. Ia mengikuti aturan 3-2-1 dengan snapshot otomatis, satu salinan direplikasi ke wilayah cloud kedua dan satu salinan tak berubah dengan jendela retensi terkunci yang tak dapat dihapus admin-nya sendiri. Seluruh lingkungannya infrastructure as code (bab 8.2), sehingga ia dapat mendirikan tumpukan segar dari sumber. Sekali per kuartal ia menjalankan pemulihan nyata ke lingkungan awal pada Jumat sore, mengukur waktunya, dan mengajukan catatan singkat. Latihan pertama memakan sembilan jam dan menemukan langkah migrasi yang hilang; perbaikannya yang membuat latihan berikutnya memakan tiga.

Enterprise. Sebuah bank multinasional beroperasi di bawah persyaratan pemulihan regulasi yang mewajibkan kesinambungan teruji untuk layanan kritis. Ia menjalankan warm standby di wilayah kedua untuk platform perbankan intinya, dengan replikasi sinkron di dalam pasangan metro untuk RPO nyaris nol dan replikasi asinkron ke wilayah jauh untuk bertahan dari bencana regional. Analisis dampak bisnis menetapkan RTO dan RPO untuk setiap layanan, dan tim pusat memetakan dependensi hulu termasuk dua penyedia SaaS yang ditandai sebagai risiko konsentrasi. Dua kali setahun ia melakukan failover penuh yang disaksikan regulator, mengukur aktual terhadap target, dan memberi makan celah ke siklus berikutnya. Program pemulihan siber terpisah memelihara salinan vault tak berubah dan runbook clean-room, diuji terpisah dari latihan bencana alam.

Pemerintah. Sebuah lembaga nasional yang menyalurkan tunjangan memelihara program kesinambungan operasi (COOP) yang dibangun untuk mempertahankan fungsi esensialnya selama gangguan apa pun. Mengikuti praktik kesinambungan operasi dan panduan perencanaan kontinjensi NIST SP 800-34 yang mendukung kewajiban FISMA-nya, ia mengidentifikasi fungsi esensial, mengurutkan pemulihannya, dan menamai pengganti serta fasilitas alternatif agar keputusan tak pernah macet karena tak ada orang berwenang. Sistem menghadap warga membawa RTO dan RPO terdokumentasi, cadangan mengikuti aturan 3-2-1 dengan salinan air-gapped, dan infrastruktur didefinisikan sebagai kode untuk bangun ulang di wilayah alternatif. Latihan penuh tahunan, plus latihan tabletop untuk skenario ransomware, menguji rencana terhadap pemulihan terukur, dan hasilnya dilaporkan kepada badan pengawas sebagai bukti bahwa layanan esensial selamat dari hari buruk.

Kasus bisnis: motivasi, ROI, dan TCO

Imbal hasil DR dan kesinambungan adalah bencana yang dihindari, yang benar-benar sulit dinilai sampai Anda membutuhkannya dan menyakitkan konkret ketika Anda membutuhkannya. Bingkai sebagai manajemen risiko: biaya yang diharapkan dari gangguan adalah kemungkinannya dikali dampaknya, dan dampak untuk organisasi besar berkisar dari pendapatan hilang per jam downtime hingga penalti regulasi, biaya pemberitahuan pelanggaran, dan kerusakan reputasi yang melampaui pemadaman. Satu peristiwa ransomware yang tak dapat dipulihkan telah menamatkan perusahaan dan, di sektor publik, menjatuhkan layanan warga esensial selama berminggu-minggu. Dibanding itu, biaya kapabilitas pemulihan teruji sederhana dan dapat diketahui.

Total biaya kepemilikan (TCO) nyata dan berkelanjutan: infrastruktur standby, bandwidth replikasi, penyimpanan cadangan (dilipatgandakan oleh salinan tak berubah dan offline), dan waktu rekayasa untuk membangun otomasi dan menjalankan latihan. Inilah mengapa Anda memberi tingkat menurut RTO dan RPO alih-alih membeli aktif-aktif di mana-mana, agar pengeluaran mengikuti nilai tiap sistem alih-alih kebijakan seragam. Untuk mengajukan kasus kepada pimpinan, terjemahkan rencana ke bahasa mereka: ini downtime dan kehilangan data yang dapat kami tahan hari ini, ini selisih ke target kami, ini biaya menutupnya, dan ini paparan jika tidak. Artefak paling persuasif adalah latihan terukur, karena pemulihan yang telah Anda demonstrasikan adalah angka yang dapat dipercaya pimpinan, dan rencana tak teruji adalah liabilitas yang menyamar sebagai aset.

Anti-pola dan jebakan

Cadangan tak teruji. Pemulihan yang tak pernah Anda lakukan adalah harapan; latihan adalah tempat Anda menemukan kerusakan, kunci yang hilang, dan volume yang salah.
Cadangan terjangkau dari produksi. Jika ransomware dapat mengenkripsi atau menghapus cadangan Anda, Anda punya satu salinan, bukan tiga. Jaga satu tak berubah dan offline.
Satu RTO dan RPO untuk segalanya. Tingkat seragam melindungi berlebih yang remeh dan kurang melindungi yang kritis; beri tingkat dari analisis dampak bisnis.
Mencampuradukkan DR dengan BCP. Memulihkan setiap server sementara tak ada yang tahu siapa yang mendeklarasikan bencana atau bagaimana menjangkau staf adalah sistem terpulihkan dan bisnis gagal.
Lingkungan pemulihan buatan tangan. Infrastruktur yang tak dapat Anda bangun ulang dari kode menyimpang, dan penyimpangan ditemukan di tengah failover.
Dependensi diabaikan. Memulihkan aplikasi sebelum basis data, penyedia identitas, atau DNS-nya hanya menghasilkan pemadaman kedua.
Pembusukan rencana. Binder yang ditulis sekali dan tak pernah dilatih mendeskripsikan sistem yang tak ada lagi.
Titik buta pemasok. Pemulihan Anda dibatasi oleh pemulihan pemasok kritis Anda, dan risiko konsentrasi tak terlihat sampai mereka gagal bersama.

Model kematangan

Tingkat 1, Memulai: Pemulihan ad hoc dan reaktif. Cadangan mungkin berjalan tetapi pemulihan tak teruji. Tak ada RTO atau RPO yang disepakati, tak ada analisis dampak bisnis, dan pemulihan diimprovisasi selama insiden. Kehilangan data serius atau peristiwa ransomware kemungkinan tak dapat dipulihkan.
Tingkat 2, Mengembangkan: Praktik dasar ada tetapi tidak konsisten lintas tim. Sebagian sistem kritis punya cadangan yang mengikuti aturan 3-2-1 dan RTO serta RPO terdokumentasi untuk layanan terpenting, dan rencana DR dasar ada dengan pemulihan diuji sesekali. Cakupan parsial, dependensi tak dipetakan, latihan ad hoc, dan disiplin satu tim tidak menyiratkan disiplin tim berikutnya.
Tingkat 3, Membakukan: Praktik pemulihan didokumentasikan dan ditegakkan di seluruh organisasi. Analisis dampak bisnis mendorong RTO dan RPO bertingkat lintas sistem, strategi pemulihan dicocokkan dengan tingkat itu, lingkungan adalah infrastructure as code, dependensi dan urutan pemulihan dipetakan, dan latihan terjadwal (tabletop, game day, dan failover) berjalan pada irama terdefinisi. Rencana pemulihan siber dengan salinan tak berubah dan offline didokumentasikan dan diterapkan konsisten alih-alih diserahkan kepada tim individual.
Tingkat 4, Mengelola: Pemulihan diukur dan dikendalikan terhadap garis dasar. Setiap latihan menangkap RTO dan RPO aktual yang dicapai dan melacak selisih ke target, dan metrik seperti tingkat keberhasilan pemulihan, pecahan sistem kritis yang dipulihkan ujung ke ujung dalam setahun terakhir, cakupan dan imutabilitas cadangan, dan lag replikasi terpantau sebagai RPO nyata dilaporkan di dasbor. Penyimpangan memicu tindakan, pentahapan diturunkan ulang dari data tentang bagaimana sistem benar-benar dipakai, dan keputusan go atau no-go bertumpu pada bukti alih-alih angka yang tertulis di slide.
Tingkat 5, Mengorkestrasi: Pemulihan terus diperbaiki, terintegrasi di seluruh organisasi, dan adaptif. Failover dan pemulihan clean-room siber dilatih sebagai rutin, risiko pemasok dan konsentrasi dikelola aktif, dan kesinambungan terintegrasi dengan keandalan (bab 9.1) dan respons insiden (bab 9.3) sehingga organisasi pulih secara dapat diprediksi dari kegagalan yang tak pernah dilihatnya dan menentukan ulang cakupan postur pemulihannya seiring lanskap sistem dan gambaran ancaman bergeser.

Gagasan untuk didiskusikan

Sistem kritis Anda yang mana belum pernah dipulihkan ujung ke ujung, dan apa yang dibutuhkan untuk membuktikan ia dapat?
Jika Anda kehilangan wilayah cloud primer selama sehari penuh, proses bisnis mana yang berhenti, dan dalam urutan apa Anda akan mengembalikan sistem?
Seberapa banyak pemulihan Anda bergantung pada pemasok yang pemulihannya tak dapat Anda lihat atau uji?
Di mana Anda membayar tingkat pemulihan yang tidak dibenarkan analisis dampak bisnis, dan di mana Anda kurang melindungi?
Jika cadangan Anda terjangkau dan terenkripsi malam ini, apa titik pemulihan terakhir Anda yang benar-benar diketahui bersih?
Apa selisih jujur antara RTO dan RPO terjanji Anda dan yang benar-benar dicapai latihan terakhir Anda?

Poin-poin utama

Kesinambungan adalah tujuan; pemulihan adalah sarana. Perencanaan kesinambungan bisnis menjaga organisasi berjalan; pemulihan bencana memulihkan sistem TI yang diandalkannya.
RTO dan RPO mendorong segalanya, dan keduanya berasal dari analisis dampak bisnis, bukan tebakan rekayasa. Beri tingkat pada sistem alih-alih melindungi semuanya sama.
Cadangan tak teruji bukan cadangan. Ikuti aturan 3-2-1, jaga setidaknya satu salinan tak berubah dan offline terhadap ransomware, dan uji pemulihan sesuai jadwal.
Cocokkan strategi DR dengan angkanya: cadangan-dan-pemulihan, pilot light, warm standby, atau aktif-aktif, dipilih menurut RTO dan RPO tiap sistem.
Replikasi menukar konsistensi dengan kesegaran (bab 3.3); RPO nyata Anda adalah lag replikasi Anda, bukan dokumen desain Anda.
Bangun ulang dari kode dengan infrastructure as code (bab 8.2), dan petakan dependensi Anda sebelum Anda membutuhkannya.
Uji dengan latihan tabletop, game day, dan latihan failover penuh, dan ukur RTO dan RPO aktual versus target.
Rencanakan pemulihan siber secara terpisah dengan pemulihan clean-room, dan hubungkan seluruh praktik dengan keandalan (bab 9.1), respons insiden (bab 9.3), dan kepatuhan (bab 4.6).

Referensi dan bacaan lanjutan

ISO 22301, Security and resilience: Business continuity management systems: Requirements (standar internasional untuk BCP).
National Institute of Standards and Technology, SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems (RTO, RPO, dan strategi pemulihan untuk sistem pemerintah).
National Institute of Standards and Technology, SP 800-61 Rev. 2: Computer Security Incident Handling Guide (penanganan insiden dan pemulihan siber).
U.S. Federal Emergency Management Agency, Continuity Guidance Circular dan panduan COOP federal (fungsi esensial dan kesinambungan operasi).
Federal Financial Institutions Examination Council (FFIEC), buklet Business Continuity Management (ekspektasi pemulihan regulasi untuk lembaga keuangan).
Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, eds., Site Reliability Engineering: How Google Runs Production Systems (keandalan dan pengujian bencana).
Kelly Shortridge dan Aaron Rinehart, Security Chaos Engineering (sengaja melatih kegagalan dan pemulihan).
Cybersecurity and Infrastructure Security Agency (CISA), #StopRansomware Guide (praktik pencegahan dan pemulihan ransomware).