Disaster Recovery Plan Teknologi Informasi

WTC 2001

Jakarta 2007

Japan Tsunami 2014

Ilustrasi Ketika banjir besar di Jakarta Pebruari 2007, sentral telepon Telkom di Semanggi sempat tenggelam dan tidak dapat digunakan selama beberapa hari. Bagaimana jika seandainya perusahaan memiliki server yang di-hosting di Telkom Semanggi? atau jaringan data antar kantor hanya mengandalkan jaringan dari Telkom yang kebetulan melewati sentral Semanggi? Berapa besar kerugian perusahaan karena tidak dapat menjalankan bisnisnya? atau Berapa besar kerugian karena perusahaan tidak dapat melakukan konsolidasi dengan cabang?

Untuk mengurangi kerugian yang diakibatkan oleh bencana perlu disusun sebuah rencana pemulihan dari bencana atau lebih dikenal dengan Disaster Recovery Plan(DRP). Dalam scope kecil, bagian TI dapat menyiapkan rencana DRP untuk layanan TI saja. Misalnya, kesiapan server backup, ketersediaan telepon cadangan jika jalur komunikasi utama mati. Dalam skala yang lebih besar perusahaan dapat menyiapkan DRP secara menyeluruh. Mulai dari ketersediaan personel, ruang kerja pengganti, hingga prosedur manual yang akan dikerjakan jika sistem otomatis tidak dapat berjalan.

Latar Belakang Adanya ancaman dari lingkungan alam seperti bencana alam, ataupun lingkungan sosial politik seperti kerusuhan, atau musibah lainnya seperti kebakaran, kerusakan layanan listrik dan lain-lain telah menempatkan informasi yang selama ini dititipkan pada infrastruktur teknologi informasi dalam posisi yang rawan. Paradigma baru seperti paperless office atau office automation yang menempatkan informasi dalam bentuk digital sebagai pengganti informasi fisik berupa kertas atau dokumen juga turut menambah tingginya resiko kehilangan informasi akibat kasus bencana.

Ada baiknya perusahaan atau organisasi mulai memikirkan antisipasi yang sungguh-sungguh untuk menyelamatkan informasi yang sangat berguna bagi kelangsungan bisnis, terutama setelah bencana terjadi. Business continuity atau keberlangsungan bisnis setelah satu bencana juga turut dijadikan salah satu parameter penilaian kematangan manajemen dalam mengelola sumber daya yang dimiliki di satu organisasi. Salahsatu elemen penting pada business continuity yaitu disaster recovery plan(DRP), atau penyusunan rencana pemulihan setelah terjadinya bencana.

Wujud DRP secara sederhana hanya berupa dokumen yang berisi response plan (rencana tanggap) terhadap bencana. Tetapi, proses penyusunan dokumen tersebut tidaklah mudah dan memerlukan pengetahuan yang mendalam mengenai berbagai resiko yang dihadapi perusahaan / organisasi. Ruang lingkup DRP dapat dibuat melebar meliputi infrastruktur, personel dan prosedur

Sasaran Memahami konsep Business Continuity Planning (perencanaan kontinuitas layanan TI). Memahami strategi pemulihan layanan TI dalam Disaster Recovery Plan (rencana penanggulangan bencana). Mampu menyusun dokumen DRP

Pendahuluan Disaster recovery plan (DRP) adalah rencana yang disiapkan organisasi untuk membantu organisasi pulih setelah terjadi musibah atau bencana. Penyebab musibah bervariasi, mulai dari fenomena alam hingga akibat perbuatan manusia, baik yang disengaja maupun tidak disengaja. Pada bidang teknologi informasi, penyebab dapat lebih spesifik misalnya kegagalan infrastruktur , kekeliruan operator, hingga serangan virus. Tingginya kebergantungan organisasi pada infrastruktur teknologi informasi menyebabkan perlunya dipertimbangkan DRP di bidang infrastruktur jaringan komputer.

Disaster Disaster (bencana) didefiniskan sebagai kejadian yang waktu terjadinya tidak dapat diprediksi dan bersifat sangat merusak. Pengertian ini mengidentifikasikan sebuah kejadian yang memiliki empat faktor utama, yaitu : tiba-tiba tidak diharapkan bersifat sangat merusak kurang perencanaan

Dalam dunia IT beberapa penyebab bencana dapat kita rumuskan sebagai berikut : Kebakaran Banjir Gempa bumi dan tanah longsor Perubahan suhu dan kelembaban yang ekstrim Virus Komputer Kecelakaan pesawat, kendaraan dll

Hal-hal yang perlu dibuat dalam perencanaan penanggulangan bencana ini adalah : Prosedur penyimpanan dan alternative lain Pihak pengelola apabila terjadi bencana Langkah-langkah yang sistematis dalam beckup data Ukuran tercapainya kesusksesan dalam penanggulangan bencana Prosedur pemulihan

Sebuah dokumen DRP idealnya memuat elemen-elemen berikut : Prosedur deklarasi keadaan dalam bencana Nama dan alamat yang dapat dihubungi dalam keadaan darurat Tim tanggap darurat Prosedur penilaian tingkat kerusakan Prosedur recovery dan restart sistem Transisi ke kondisi normal Tim recovery

Saat ini sudah diterbitkan pedoman standar khusus sebagai pedoman penyusunan dan evaluasi DRP, khusus untuk operasional dan manajemen teknologi informasi, yaitu ISO/IEC 24762:2008 yang menyediakan pedoman penyusunan DRP untuk teknologi informasi dan komunikasi. Pedoman ini merupakan bagian dari dari manajemen business continuity, dan diterapkan baik bagi penyedia layanan teknologi informasi dan komunikasi internal (information communication technology-ICT) maupun eksternal (outsourced), dan meliputi fasilitas fisik dan layanan

Spesifikasi ISO/IEC 24762:2008 meliputi : Kebutuhan untuk menerapkan, mengoperasikan, memonitor dan memelihara fasilitas dan layanan disaster recovery untuk ICT. Kemampuan yang harus dimiliki oleh layanan disaster recovery ICT eksternal dan pedoman praktis yang harus dijalankan untuk menyediakan lingkungan operasional minimal yang aman dan memfasilitasi usaha organisasi untuk melakukan recovery. Pedoman memilih situs recovery dan pedoman untuk peningkatan layanan disaster recovery ICT

Business Continuity Plan (BCP) Kontinuitas layanan TI perusahaan harus dijaga dari gangguan: Bencana alam Ulah manusia (disengaja atau tidak) Kerusakan. Dibutuhkan perencanaan untuk mencegah, menangani, dan menanggulangi gangguan Policy dan prosedur penanganan bencana. Strategi pemulihan layanan. Strategi minimasi dampak bencana.

Fase Penanganan Bencana insiden Evaluasi Kerusakan Pemulihan Layanan Vital Perbaikan Restorasi Layanan Notifikasi Tidak semua insiden berstatus bencana Ditentukan oleh hasil evaluasi. Pemulihan layanan menggunakan fasilitas alternatif/cadangan atau secara manual. Perbaikan dapat berupa pemindahan lokasi layanan.

Tahap Penyusunan DRP Penyusunan DRP untuk teknologi informasi di suatu organisasi, secara umum mengacu pada langkah-langkah pengelolaan proyek pada umumnya, yaitu : inisialisasi, eksekusi dan evaluasi. Pada tahap inisialisasi, diperlukan dukungan manajemen dan kontrak proyek yang jelas antara manajemen yang berwenang dengan pihak yang akan menyusun DRP. Kontrak proyek ini diperlukan untuk menjaga konsistensi komitmen semua pihak yang terlibat. Pada tahap eksekusi, dilakukan sekumpulan aktivitas yang keluaran akhirnya diharapkan dapat menghasilkan dokumen DRP yang sesuai dengan kondisi dan kebutuhan organisasi

Aktivitas Penyusunan DRP Melakukan business impact analysis, yang meliputi penentuan maximum tolerable downtime (MTD), penentuan recovery objective yang meliputi recovery time objective (RTO), dan recovery point objective (RPO), membuat analisis resiko, menyajikan semua hasil analisis dalam satu laporan terintegrasi. Mendefinisikan prosedur recovery, yaitu membuat DRP untuk setiap proses dengan cara memetakan proses dengan infrastruktur, membuat DRP dalam bentuk tertulis, dan menguji DRP tersebut. Evaluasi dan monitoring meliputi proses pengujian dan kaji ulang secara periodik misalnya setiap bulan setiap 4 bulan atau tahunan. Tahap lainnya yaitu memberikan pelatihan yang memadai bagi semua tim DRP yang terlibat, khususnya tim recovery.

Tahapan BC Planning Tahapan perencanaan: Penyusunan policy rencana darurat. Analisa dampak bisnis (dari gangguan). Identifikasi mekanisme pencegahan. Pengembangan strategi pemulihan layanan. Penyusunan prosedur penanganan situasi darurat. Uji coba, pelatihan, dan latihan prosedur darurat. Re-evaluasi rencana penanganan situasi darurat.

Proses Pengembangan BCP Penyusunan Policy Identifikasi peraturan perundangan yang mempersyaratkan perencanaan situasi darurat. Penyusunan kebijakan penanganan situasi darurat. Mendapatkan persetujuan. Mensosialisasikan policy.

Proses Pengembangan BCP Analisa Dampak terhadap bisnis Identifikasi sumber daya TI vital. Identifikasi dampak gangguan dan batas lamanya gangguan. Menyusun prioritas pemulihan sumber daya TI. Identifikasi mekanisme pencegahan Implementasi mekanisme pencegahan. Pemeliharaan mekanisme pencegahan.

Proses Pengembangan BCP Pengembangan strategi pemulihan layanan Identifikasi metoda pemulihan. Integrasi metoda dalam rancangan arsitektur TI. Pengembangan rencana penanganan situasi darurat Dokumentasi strategi pemulihan layanan.

Proses Pengembangan BCP Uji-coba, pelatihan, dan latihan prosedur darurat Pengembangan target uji-coba dan kriteria keberhasilan. Perbaikan berdasarkan pengalaman/ permasalahan. Pelatihan personil. Reevaluasi rencana penanggulangan situasi darurat Review dan update.

BCP Policy Terutama berisi: Peran dan tanggung-jawab dalam organisasi penanggulangan bencana Kepala: koordinator penanggulangan bencana. Ruang lingkup: bagian dalam organisasi dan kategori komponen infrastruktur. Kebutuhan sumber daya. Kebutuhan pelatihan personil. Jadwal uji-coba dan latihan. Jadwal reevaluasi rencana penanggulang-an bencana.

Klasifikasi Insiden Policy juga mengatur insiden apa yang masuk kategori bencana (mengaktifkan BCP). Menerapkan klasifikasi insiden: Negligible (biasa): tidak menyebabkan kerusakan (listrik mati, aplikasi crash, dsb.) Minor (kecil): kerusakan yang tidak berdampak kerugian. Major (besar): kerusakan yang berdampak kerugian pada bisnis. Crisis (krisis): kerusakan yang berdampak kerugian besar, mengancam kelangsungan bisnis, dan dapat mengganggu sistem lain (pihak ketiga).

Klasifikasi Insiden Kategori insiden biasanya dikaitkan dengan lamanya gangguan (mulai dari kejadian sampai resolusi): Kategori Level Lama gangguan Tindakan Krisis 7 24 jam Aktifkan BCP   6 12 jam Mayor 5 6 jam Antisipasi BCP 4 4 jam Perbaiki/restorasi 3 2 jam Perbaiki Minor 2 1 jam 1 0.5 jam Biasa Catat (log) & monitor

Analisa Dampak Bencana Langkah I: Identifikasi sumber daya TI vital: Melibatkan berbagai pihak (user, pengelola proses bisnis, pengelola aplikasi, dsb.), tahapan: Ranking proses bisnis berdasarkan nilai strategisnya. Identifikasi komponen infrastruktur yang mendukung proses- proses bisnis strategis (server, akses ke WAN, dsb.)

Analisa Dampak Bencana Langkah II: Klasifikasi layanan TI berdasarkan toleransi terhadap lamanya gangguan Critical: Layanan tidak dapat dijalankan tanpa fasilitas yang identik, apalagi manual. Biaya interupsi sangat mahal. Vital: Layanan dapat diganti dengan proses manual tapi tidak bisa lama (max. 5 hari). Sensitive: Layanan dapat diganti dengan proses manual dengan biaya yang tidak terlalu tinggi (tambahan staf, dsb.) Non-sensitive: Layanan dapat dihentikan dengan kerugian kecil.

Analisa Dampak Bencana Gangguan pada layanan tidak vital dapat berdampak pada layanan vital. Toleransi terhadap lamanya gangguan layanan TI dipetakan ke toleransi komponen infrastruktur pendukungnya Langkah III: Menyusun prioritas (urutan) dalam pemulihan/perbaikan komponen infrastruktur berdasarkan toleransi komponen-komponen infrastruktur vital.

Mekanisme Pencegahan Mekanisme untuk mencegah atau meminimasi gangguan, misal penggunaan: UPS (uninterrupted power supply). Generator set. AC dengan kapasitas berlebih. Fire hydrant atau suppressor. Detektor asap/api. Sensor kelembapan/air. Penyimpanan media tahan api dan kedap air. Tombol emergency shut down. Tempat penyimpanan media off-site. Backup rutin dan sering.

Biaya Pencegahan Tingkat pencegahan yang ideal: minimasi (biaya pencegahan & penanggulangan) + (kerugian akibat gangguan). Biaya Biaya kerugian akibat gangguan minimum Biaya pemulihan /pencegahan Waktu

Contoh Biaya vs. Waktu RPO (recovery point objective): target titik waktu dimana transaksi-transaksi terbaru dapat diselamatkan. RTO (recovery time objective): target waktu pemulihan layanan dari gangguan. mirroring disk backup tape 1 jam 2 jam 24 jam gangguan RTO RPO waktu

Strategi Pemulihan Layanan Penjadwalan backup data dan file penting: Misal metoda child-parent-grand parent (harian: 7 versi, mingguan: 4 versi, bulanan: 12 versi, tahunan: 1 versi). Penyimpanan backup di lokasi terpisah, kriteria Terpisah secara geografis (bebas bencana) Memiliki fasilitas keamanan (access control) Memiliki fasilitas penyimpanan bebas gangguan Biaya dan waktu untuk mengakses dapat diterima.

Strategi Pemulihan Layanan Pemulihan layanan di lokasi alternatif/ cadangan Mirror (dual) site: Fasilitas identik dengan replikasi data real-time. Siap mengambil alih setiap saat. Biasanya dimiliki dan dioperasikan oleh perusahaan. Hot site: Fasilitas cadangan yang dilengkapi dengan hardware, infrastruktur, dan staf. Proses migrasi sistem dimulai begitu BCP diaktifkan.

Strategi Pemulihan Layanan Warm site: Beberapa sarana sudah tersedia (biasanya merupakan lokasi layanan lain). Perlu penyiapan untuk mengambil alih layanan. Cold site: Hanya fasilitas bangunan dengan infrastruktur dasar (listrik, AC, dsb.) Perlu instalasi peralatan untuk mengambil alih layanan. Mobile site: Fasilitas portable yang dapat di-setup dimana saja. Biasanya dimiliki pihak ketiga.

Situs Alternatif Karakteristik: Site Cost Hardware Communi-cations Setup time Location Cold site Low None Long Fixed Warm site Medium Partial Partial/Full Hot site Medium/ High Full Short Mobile site High Dependent Not Fixed Mirror site

Strategi Pemulihan Layanan Strategi pengadaan perlengkapan pengganti Kontrak perjanjian (SLA) dengan vendor. Termasuk layanan prioritas dalam keadaan darurat. Beli dan simpan cadangan di gudang. Investasi besar dan ada resiko teknologi kadaluwarsa. Kontrak perjanjian dengan pihak ketiga untuk meminjam fasilitas. Fasilitas perusahaan lain dengan teknologi serupa atau compatible.

Tabulasi Biaya Biaya (juta Rp) Strategi Lokasi Cadangan   Biaya (juta Rp) Strategi Vendor Hardware Software Travel/ Shipping Labor/ Contractor Testing Supply Lokasi Cadangan Cold site Warm site Hot site Mobile site Mirror site Penyimpan-an Offsite Komersial Internal Peralatan Cadangan SLA Cadangan Pinjam

Peran dan Tanggung-jawab Daftar kontak resmi:

Dokumen BCP

Contoh

Topologi Jaringan

Responden Pada penelitian ini juga dilakukan semacam survey awal untuk melihat perilaku pengguna jaringan komputer di Universitas Widyatama, untuk menilai tingkat kebergantungan pengguna dan pelaksanaan proses bisnis terhadap infrastruktur jaringan komputer. Survey disebarkan kepada sekitar 60 responden, meliputi 30 mahasiswa, 15 dosen dan 15 pegawai. Jumlah sample responden yang kecil dipilih karena penelitian ini baru bersifat studi awal yang akan digunakan untuk pengembangan penelitian yang lebih spesifik lagi

Kesimpulan Perlu dilakukan inisiatif penyusunan DRP untuk infrastruktur jaringan komputer mengingat banyaknya aktivitas yang bergantung pada layanan jaringan komputer dan rendahnya tingkat kesadaran pengguna terhadap pentingnya proses pengamanan data milik sendiri ataupun data-data terkait pekerjaan masing-masing. Kelayakan diperlukannya DRP didukung oleh fakta bahwa secara teknis, saat ini implementasi jaringan komputer universitas juga belum mengadopsi kebutuhan ke arah tersebut. Hal ini dapat dilihat dari fakta bahwa semua server penting disimpan pada satu ruangan dan tidak ada mekanisme backup dan recovery pada setiap server tersebut.