เมื่อระบบหลักในธุรกิจหยุดทำงาน ส่วนที่ยากที่สุดคือการรู้ว่าต้องกู้คืนสิ่งใดก่อน ใครมีสิทธิ์เข้าถึงเพื่อดำเนินการดังกล่าว ข้อมูลสำรองใดที่เชื่อถือได้ และธุรกิจจะทำงานต่อไปโดยไม่มีระบบนั้นได้นานเท่าใด
นั่นคือจุดที่ธุรกิจขนาดกลางและขนาดย่อม (SMB) จำนวนมากได้พบกับช่องว่างระหว่างการมีข้อมูลสำรองและการมีแผนกู้คืนที่ใช้งานได้จริง ข้อมูลสำรองอาจมีข้อมูลที่จำเป็น แต่ไม่ได้ทำหน้าที่กำหนดลำดับการกู้คืน มอบหมายความรับผิดชอบ ตรวจสอบว่าการกู้คืนใช้ได้ผลหรือไม่ หรือแก้ปัญหาข้อมูลยืนยันตัวตนของผู้ดูแลระบบที่สูญหายระหว่างที่ระบบขัดข้อง
แผนกู้คืนระบบไอทีจากภัยพิบัติจะช่วยจัดโครงสร้างให้แก่กระบวนการนี้ก่อนที่จะเกิดการหยุดชะงัก แผนนี้จะกำหนดว่าระบบใดสำคัญที่สุด ต้องได้รับการกู้คืนรวดเร็วเพียงใด ธุรกิจสามารถทนต่อการสูญเสียข้อมูลได้มากน้อยแค่ไหน ควรใช้กลยุทธ์การป้องกันข้อมูลสูญหายอย่างไร ใครเป็นผู้รับผิดชอบในแต่ละขั้นตอนการกู้คืน และมีการปกป้องข้อมูลยืนยันตัวตนที่สำคัญอย่างไร ความชัดเจนนี้สามารถป้องกันไม่ให้เหตุการณ์ด้านไอทีกลายเป็นการหยุดทำงานที่ยืดเยื้อ สูญเสียรายได้ หรือเกิดวิกฤตการดำเนินงานในวงกว้าง
แผนกู้คืนระบบไอทีจากภัยพิบัติคืออะไร?
ความต่อเนื่องทางธุรกิจกับการกู้คืนระบบไอทีจากภัยพิบัติ
สิ่งที่แผนกู้คืนระบบไอทีจากภัยพิบัติต้องครอบคลุม
สิ่งที่แผนกู้คืนระบบไอทีจากภัยพิบัติต้องกำหนด
การกู้คืนข้อมูลยืนยันตัวตน: สถานการณ์การกู้คืนจากภัยพิบัติที่มักถูกมองข้าม
วิธีทดสอบแผนกู้คืนระบบไอทีจากภัยพิบัติ
สร้างการกู้คืนโดยเน้นระบบ ข้อมูล และการเข้าถึง
แผนกู้คืนระบบไอทีจากภัยพิบัติคืออะไร?
แผนกู้คืนระบบไอทีจากภัยพิบัติคือกระบวนการที่มีการบันทึกไว้เป็นเอกสารสำหรับการกู้คืนระบบเทคโนโลยีหลังจากเกิดการหยุดชะงัก โดยมุ่งเน้นไปที่ส่วนของไอทีของธุรกิจ ได้แก่ ข้อมูล แอปพลิเคชั่น อุปกรณ์ โครงสร้างพื้นฐาน บริการคลาวด์ การเข้าถึงของผู้ดูแลระบบ ข้อมูลสำรอง และบุคลากรที่มีหน้าที่รับผิดชอบในการกู้คืน
แผนกู้คืนระบบไอทีที่ใช้งานได้จริงควรตอบคำถามต่าง ๆ เช่น:
- ระบบใดที่ต้องนำกลับมาใช้งานก่อนเป็นอันดับแรก?
- ธุรกิจสามารถทนต่อการหยุดทำงานได้นานเท่าใด?
- การสูญเสียข้อมูลในปริมาณเท่าใดที่ยอมรับได้?
- ข้อมูลสำรองที่จัดเก็บไว้ที่ไหน?
- ใครสามารถกู้คืนระบบได้บ้าง?
- ต้องใช้ข้อมูลยืนยันตัวตนของผู้ดูแลระบบใดบ้าง?
- ทีมงานจะยืนยันได้อย่างไรว่าระบบที่กู้คืนมานั้นปลอดภัยและสามารถใช้งานได้?
- ธุรกิจจะสื่อสารกับพนักงานและลูกค้าอย่างไรหากช่องทางหลักหยุดทำงาน?
แผนกู้คืนจากภัยพิบัติควรครอบคลุมมากกว่าการรับมือกับการโจมตีทางไซเบอร์ โดยต้องครอบคลุมถึงปัญหาที่พบได้ในทุก ๆ วัน เช่น ความล้มเหลวของฮาร์ดแวร์ ข้อมูลยืนยันตัวตนสูญหาย และการลบข้อมูลโดยอุบัติเหตุ นอกจากนี้ ยังต้องครอบคลุมถึงการหยุดชะงักของบริการภายนอก เช่น การขัดข้องของแพลตฟอร์มคลาวด์หรือเครื่องมือ SaaS การกำหนดค่าที่ไม่ถูกต้อง และพนักงานคนสำคัญที่ลาออกไปโดยไม่ได้ส่งต่อการเข้าถึงที่สำคัญ
การกู้คืนไม่ใช่สิ่งที่ควรมาออกแบบระหว่างที่ระบบหยุดทำงาน แต่ต้องได้รับการวางแผน กำหนดผู้รับผิดชอบ สื่อสาร และทดสอบก่อนที่ธุรกิจจะต้องพึ่งพาสิ่งนี้
ความต่อเนื่องทางธุรกิจกับการกู้คืนระบบไอทีจากภัยพิบัติ
ความต่อเนื่องทางธุรกิจและการกู้คืนระบบไอทีจากภัยพิบัติต่างมักถูกมองว่าเป็นสิ่งเดียวกัน แต่แท้จริงแล้วช่วยแก้ปัญหาที่แตกต่างกัน
ความต่อเนื่องทางธุรกิจ คือการช่วยให้บริษัทสามารถดำเนินงานต่อไปได้ในระหว่างที่เกิดการหยุดชะงัก ซึ่งจะครอบคลุมถึงการสื่อสารกับลูกค้า ขั้นตอนการทำงานชั่วคราว ความรับผิดชอบของพนักงาน การประสานงานกับผู้ผลิต และการตัดสินใจเกี่ยวกับบริการที่ต้องดำเนินต่อไปแม้ว่าระบบปกติจะไม่สามารถใช้งานได้
การกู้คืนระบบไอทีจากภัยพิบัติมุ่งเน้นไปที่เทคโนโลยีเบื้องหลังการทำงานนั้น โดยจะกำหนดวิธีที่จะกู้คืนระบบ ข้อมูล แอปพลิเคชั่น ข้อมูลสำรอง และการเข้าถึงของผู้ดูแลระบบ เพื่อให้ธุรกิจสามารถกลับมาดำเนินงานได้ตามปกติอย่างปลอดภัย
ตัวอย่างเช่น กรณีที่ระบบ CRM ขัดข้อง แผนความต่อเนื่องทางธุรกิจอาจอธิบายถึงวิธีที่ทีมขายหรือฝ่ายสนับสนุนจะให้บริการลูกค้าต่อไปในระหว่างที่ CRM หยุดทำงาน ส่วนแผนกู้คืนระบบไอทีจะอธิบายว่าใครจะเป็นผู้ติดต่อผู้ให้บริการ ข้อมูลใดที่ต้องกู้คืน มีข้อมูลสำรองหรือการส่งออกใดที่ใช้งานได้บ้าง ต้องใช้ข้อมูลยืนยันตัวตนใดบ้าง และทีมงานจะยืนยันได้อย่างไรว่าระบบปลอดภัยที่จะกลับมาใช้งานอีกครั้ง
สำหรับ SMB หลายแห่ง ช่องว่างนี้จะปรากฏให้เห็นเมื่อเกิดเหตุการณ์ขึ้นเท่านั้น โดยอาจทราบว่าใครจะเป็นผู้ติดต่อลูกค้า แต่ไม่ทราบว่าใครสามารถกู้คืนระบบเรียกเก็บเงินได้ ทราบว่ามีข้อมูลสำรองอยู่ แต่ไม่ทราบว่าเคยมีการทดสอบการกู้คืนหรือไม่ ทราบว่าปกติแล้วมีพนักงานคนหนึ่งเป็นผู้ดูแลด้านไอที แต่ไม่ทราบว่าจะเกิดอะไรขึ้นหากพนักงานคนนั้นไม่อยู่ หรือรหัสผ่านของผู้ดูแลระบบถูกจัดเก็บไว้ที่ใดหากไม่สามารถติดต่อพนักงานคนดังกล่าวได้
สิ่งที่แผนกู้คืนระบบไอทีจากภัยพิบัติต้องครอบคลุม
แผนกู้คืนระบบไอทีจากภัยพิบัติที่มีประสิทธิภาพไม่จำเป็นต้องยาวจนเกินไป แต่ต้องมีความเฉพาะเจาะจงมากพอที่จะนำไปปฏิบัติได้จริงในสถานการณ์ที่ตึงเครียด
เป้าหมายระยะเวลาการกู้คืน
เป้าหมายระยะเวลาการกู้คืน (Recovery time objective) หรือ RTO จะกำหนดว่าระบบต้องได้รับการกู้คืนรวดเร็วเพียงใด ระบบการชำระเงินอาจจำเป็นต้องกลับมาใช้งานได้ภายในไม่กี่ชั่วโมง ในขณะที่หน้าหลักของระบบรายงานภายในอาจทนต่อการหยุดทำงานได้นานกว่า
ควรกำหนด RTO ตามผลกระทบทางธุรกิจ ไม่ใช่ตามความชอบทางเทคนิค เนื่องจากต้นทุนของการหยุดทำงานเป็นทั้งปัญหาทางธุรกิจและทางเทคนิค โดยให้พิจารณาว่าระบบใดที่ส่งผลกระทบต่อรายได้ ข้อผูกพันกับลูกค้า ข้อผูกพันทางกฎหมาย ความปลอดภัย และประสิทธิภาพการทำงานของพนักงาน
เป้าหมายจุดกู้คืนข้อมูล
เป้าหมายจุดกู้คืนข้อมูล หรือ RPO จะกำหนดว่าการสูญเสียข้อมูลในปริมาณเท่าใดที่ยอมรับได้ ซึ่งจะช่วยกำหนดกลยุทธ์การป้องกันข้อมูลสูญหาย (DLP) ที่เหมาะสม หากระบบมี RPO เท่ากับหนึ่งชั่วโมง การสำรองข้อมูลหรือการทำซ้ำข้อมูลจำเป็นต้องรองรับการกู้คืนกลับไปยังจุดนั้นโดยประมาณ
หาก RPO เท่ากับหนึ่งวัน แสดงว่าธุรกิจยอมรับช่วงว่างที่กว้างขึ้น นอกจากนี้ RPO ยังช่วยกำหนดความถี่ในการสำรองข้อมูลด้วย เนื่องจากยิ่ง RPO สั้นลงเท่าใด ก็ยิ่งต้องสำรองข้อมูลบ่อยขึ้นเท่านั้น ดังนั้น ระบบที่สำคัญจึงจำเป็นต้องมีการสำรองข้อมูลบ่อยกว่าระบบที่มีลำดับความสำคัญต่ำ
ระดับความสำคัญของระบบ
ไม่ใช่ทุกระบบที่ควรได้รับการกู้คืนพร้อมกัน แผนกู้คืนจากภัยพิบัติของธุรกิจขนาดเล็กควรแบ่งระบบออกเป็นระดับความสำคัญต่าง ๆ
- ระดับ 1: ระบบที่จำเป็นสำหรับการดำเนินงานหลัก ความปลอดภัย การสื่อสาร หรือรายได้
- ระดับ 2: ระบบสำคัญที่สามารถทนต่อการหยุดทำงานช่วงสั้น ๆ ได้
- ระดับ 3: ระบบที่มีความสำคัญต่ำกว่าซึ่งสามารถกู้คืนได้หลังจากธุรกิจมีความมั่นคงแล้ว
โดยทั่วไปแล้วระบบในระดับ 1 อาจรวมถึงอีเมล ผู้ให้บริการข้อมูลระบุตัวตน โปรแกรมจัดการรหัสผ่าน ระบบการเงิน ฐานข้อมูลลูกค้า พื้นที่จัดเก็บข้อมูลบนคลาวด์ และแพลตฟอร์มการสื่อสาร
กลยุทธ์การสำรองข้อมูล
กลยุทธ์การสำรองข้อมูลควรกำหนดสิ่งต่อไปนี้:
- ข้อมูลใดบ้างที่ต้องได้รับการสำรองข้อมูลและบ่อยเพียงใด
- จัดเก็บข้อมูลสำรองไว้ที่ใด
- ใครบ้างที่สามารถเข้าถึงข้อมูลเหล่านั้นได้
- มีวิธีการทดสอบการกู้คืนอย่างไร
NCSC ยังได้เผยแพร่(หน้าต่างใหม่)หลักการสำรองข้อมูลที่ต้านทานแรนซัมแวร์สำหรับโซลูชันการสำรองข้อมูลบนคลาวด์และในสถานที่ทำงาน โดยระบุว่าข้อมูลที่สำรองไว้ไม่ได้ต้านทานแรนซัมแวร์โดยค่าเริ่มต้น และควรได้รับการประเมินความเสี่ยงต่อภัยคุกคามจากแรนซัมแวร์
กลยุทธ์การสำรองข้อมูลที่มีประสิทธิภาพมักประกอบด้วยการสำรองข้อมูลแบบออฟไลน์หรือแบบที่ไม่สามารถแก้ไขได้สำหรับข้อมูลที่สำคัญ การทดสอบอย่างสม่ำเสมอ ขั้นตอนการกู้คืนที่มีการบันทึกไว้เป็นเอกสาร และข้อมูลยืนยันตัวตนที่แยกต่างหากสำหรับการดูแลจัดการข้อมูลสำรอง
บทบาทและความรับผิดชอบ
แผนกู้คืนจากภัยพิบัติควรระบุชื่อผู้รับผิดชอบ ไม่ใช่แค่ระบุงานที่จะต้องทำ หากมีความรู้เกี่ยวกับการกู้คืนอยู่กับคนเพียงคนเดียว ธุรกิจจะมีความเสี่ยงด้านบุคลากรพอ ๆ กับความเสี่ยงด้านไอที ควรกำหนดว่าใครเป็นผู้:
- เป็นผู้นำในการกู้คืน
- กู้คืนระบบ
- ติดต่อผู้ให้บริการ
- อนุมัติการเข้าถึงในกรณีฉุกเฉิน
- สื่อสารภายในองค์กร
- บันทึกการตัดสินใจเป็นเอกสาร
สิ่งที่แผนกู้คืนระบบไอทีจากภัยพิบัติต้องกำหนด
| ส่วนประกอบ | สิ่งที่ให้คำตอบ |
| RTO | แต่ละระบบต้องได้รับการกู้คืนรวดเร็วเพียงใด? |
| RPO | ธุรกิจสามารถยอมรับการสูญเสียข้อมูลได้มากที่สุดเท่าใด? |
| ระดับความสำคัญ | ระบบใดที่ต้องนำกลับมาใช้งานก่อน และระบบใดที่สามารถรอได้? |
| กลยุทธ์การสำรองข้อมูล | ข้อมูลใดที่ได้รับการสำรองข้อมูล จัดเก็บไว้ที่ใด และเคยมีการทดสอบการกู้คืนแล้วหรือยัง? |
| บทบาทและความรับผิดชอบ | ใครเป็นผู้นำในการกู้คืน ใครเป็นผู้กู้คืนระบบ ใครเป็นผู้ติดต่อผู้ให้บริการ และใครเป็นผู้อนุมัติการเปลี่ยนแปลงในกรณีฉุกเฉิน? |
การกู้คืนข้อมูลยืนยันตัวตน: สถานการณ์การกู้คืนจากภัยพิบัติที่มักถูกมองข้าม
การกู้คืนจากภัยพิบัติมักเน้นไปที่ข้อมูล เซิร์ฟเวอร์ และข้อมูลสำรอง แต่ในทางปฏิบัติ การกู้คืนอาจล้มเหลวเนื่องจากทีมงานไม่สามารถเข้าถึงระบบที่จำเป็นในการกู้คืนการดำเนินงานได้
การกู้คืนข้อมูลยืนยันตัวตนจะพิจารณาคำถามต่อไปนี้:
- ใครสามารถเข้าถึงบัญชีผู้ดูแลระบบได้บ้าง
- ข้อมูลยืนยันตัวตนสำหรับการสำรองข้อมูลถูกจัดเก็บไว้ที่ใด
- บัญชีใดบ้างที่สามารถกู้คืนระบบที่สำคัญได้
- จะเกิดอะไรขึ้นหากรหัสผ่านสูญหาย ถูกโจมตี หรืออยู่กับผู้ที่ไม่สามารถติดต่อได้
- ข้อมูลยืนยันตัวตนในกรณีฉุกเฉินได้รับการปกป้องและตรวจสอบแล้วหรือยัง
- สามารถยกเลิกและมอบหมายสิทธิ์การเข้าถึงใหม่ได้อย่างรวดเร็วหรือไม่
หากข้อมูลยืนยันตัวตนสำหรับการสำรองข้อมูลถูกจัดเก็บไว้ในเบราว์เซอร์ของพนักงานเพียงคนเดียว รหัสกู้คืนถูกเก็บไว้ในบันทึกส่วนตัว หรือมีการแชร์รหัสผ่านของผู้ดูแลระบบผ่านทางแชท ธุรกิจอาจไม่สามารถกู้คืนระบบได้อย่างสมบูรณ์ในระหว่างที่เกิดเหตุการณ์ขัดข้อง
โปรแกรมจัดการรหัสผ่านสำหรับธุรกิจช่วยลดความเสี่ยงดังกล่าวโดยการรวบรวมข้อมูลยืนยันตัวตนที่สำคัญไว้ที่ศูนย์กลางในห้องนิรภัยที่เข้ารหัส มอบหมายการเข้าถึงตามบทบาท และช่วยให้ยกเลิกหรือมอบหมายสิทธิ์การเข้าถึงใหม่ได้ง่ายขึ้นเมื่อมีพนักงานลาออกหรือมีการเปลี่ยนแปลงหน้าที่ความรับผิดชอบ Proton Pass for Business ช่วยให้ทีมสามารถสร้างรหัสผ่านที่คาดเดายาก จัดเก็บข้อมูลยืนยันตัวตนอย่างปลอดภัย ใช้การแชร์อย่างปลอดภัย และป้องกันไม่ให้การเข้าถึงข้อมูลที่ละเอียดอ่อนรั่วไหลไปในแชทและตารางคำนวณ
ในฐานะที่เป็นโปรแกรมจัดการรหัสผ่านสำหรับทีมไอที Proton Pass รองรับการจัดการข้อมูลยืนยันตัวตนแบบรวมศูนย์ นโยบายรหัสผ่าน การแชร์อย่างปลอดภัย การรายงานและบันทึก การจัดสรร SCIM และการผสานรวม SSO ซึ่งทำให้การกู้คืนข้อมูลยืนยันตัวตนสามารถจัดการได้ง่ายขึ้น เนื่องจากการเข้าถึงระบบที่สำคัญจะไม่ขึ้นอยู่กับพนักงานเพียงคนเดียว โปรไฟล์เบราว์เซอร์เดียว หรือรหัสผ่านที่ไม่มีการบันทึกไว้เป็นเอกสารเพียงรหัสเดียว
เทมเพลตแผนกู้คืนจากภัยพิบัติ
แผนกู้คืนจากภัยพิบัติจะทำงานได้ดีที่สุดเมื่อมีความเฉพาะเจาะจงมากพอที่จะชี้แนะแนวทางปฏิบัติในระหว่างที่ระบบขัดข้อง แต่ต้องเรียบง่ายพอที่ทีมงานจะนำไปใช้ภายใต้ความกดดันได้ สำหรับ SMB เทมเพลตควรเน้นไปที่สิ่งจำเป็น ได้แก่ สิ่งที่ต้องกู้คืน ความรวดเร็ว จากข้อมูลสำรองใด โดยใคร และใช้ข้อมูลยืนยันตัวตนใด
1. ขอบเขต
กำหนดว่าระบบ บริการ ตำแหน่ง อุปกรณ์ และข้อมูลใดบ้างที่แผนนี้ครอบคลุม
สำเนาเทมเพลต: แผนกู้คืนระบบไอทีจากภัยพิบัตินี้ครอบคลุมถึงระบบ ข้อมูล บริการ ข้อมูลยืนยันตัวตน และผู้ให้บริการที่จำเป็นในการกู้คืนการดำเนินงานที่สำคัญของ [Company Name] หลังจากเกิดการหยุดชะงักทางเทคโนโลยี
2. รายการระบบที่สำคัญ
ระบุรายชื่อระบบที่ธุรกิจต้องพึ่งพาและจัดระดับความสำคัญ
สำเนาเทมเพลต: ระบบที่สำคัญจะถูกจัดกลุ่มเป็นระดับ 1, ระดับ 2 และระดับ 3 ตามผลกระทบทางธุรกิจ เป้าหมายระยะเวลาการกู้คืน เป้าหมายจุดกู้คืนข้อมูล และการพึ่งพาระบบอื่น ๆ
3. เป้าหมายการกู้คืน
กำหนด RTO และ RPO สำหรับแต่ละระบบตามระดับความสำคัญ
สำเนาเทมเพลต: แต่ละระบบต้องมีเป้าหมายระยะเวลาการกู้คืนและเป้าหมายจุดกู้คืนข้อมูลที่มีการบันทึกไว้เป็นเอกสาร ควรมีการทบทวนเป้าหมายเหล่านี้อย่างน้อยปีละครั้งและหลังจากการเปลี่ยนแปลงระบบครั้งสำคัญ
4. กระบวนการสำรองข้อมูลและกู้คืน
บันทึกข้อมูลตำแหน่งที่จัดเก็บข้อมูลสำรอง ความถี่ในการทำงาน ใครสามารถเข้าถึงได้บ้าง และขั้นตอนการทดสอบการกู้คืน
สำเนาเทมเพลต: ข้อมูลสำรองต้องได้รับการปกป้องจากการเข้าถึงที่ไม่ได้รับอนุญาต จัดเก็บแยกต่างหากจากระบบหลักอย่างเหมาะสม และทดสอบตามกำหนดเวลาปกติ ต้องมีการบันทึกขั้นตอนการกู้คืนเป็นเอกสารสำหรับระบบระดับ 1
5. การกู้คืนข้อมูลยืนยันตัวตนและการเข้าถึง
กำหนดตำแหน่งที่จัดเก็บข้อมูลยืนยันตัวตนที่สำคัญ และระบุผู้ที่สามารถเข้าถึงข้อมูลเหล่านั้นได้ในระหว่างการกู้คืน
สำเนาเทมเพลต: ข้อมูลยืนยันตัวตนของผู้ดูแลระบบ ข้อมูลยืนยันตัวตนสำหรับการสำรองข้อมูล รหัสกู้คืน และสิทธิ์การเข้าถึงของผู้ให้บริการที่จำเป็นสำหรับการกู้คืนจากภัยพิบัติ ต้องจัดเก็บไว้ในห้องนิรภัยที่เข้ารหัสซึ่งได้รับการอนุมัติแล้ว การเข้าถึงต้องจำกัดเฉพาะบทบาทที่ได้รับอนุญาต และต้องได้รับการทบทวนหลังจากการเปลี่ยนแปลงบทบาท การเลิกจ้าง และการฝึกซ้อมการกู้คืน
6. บทบาทและการยกระดับปัญหา
กำหนดผู้รับผิดชอบการกู้คืน ผู้รับผิดชอบสำรอง และเส้นทางการยกระดับปัญหา
สำเนาเทมเพลต: แต่ละบทบาทในการกู้คืนต้องมีผู้รับผิดชอบหลักและผู้รับผิดชอบสำรอง แผนดังกล่าวต้องระบุว่าใครเป็นผู้นำในการกู้คืน ใครเป็นผู้กู้คืนระบบ ใครเป็นผู้ติดต่อผู้ให้บริการ ใครเป็นผู้สื่อสารอัปเดตต่าง ๆ และใครเป็นผู้อนุมัติการเปลี่ยนแปลงในกรณีฉุกเฉิน
7. แผนการสื่อสาร
กำหนดวิธีที่ธุรกิจจะใช้สื่อสารทั้งภายในและภายนอกในระหว่างที่ระบบไอทีหยุดทำงาน
สำเนาเทมเพลต: ในระหว่างการกู้คืนระบบ ข้อมูลอัปเดตภายในองค์กรจะถูกแชร์ผ่าน [ช่องทางที่ได้รับการอนุมัติ] การสื่อสารภายนอกไปยังลูกค้า ผู้ให้บริการ บริษัทประกัน หรือหน่วยงานกำกับดูแลต้องได้รับการอนุมัติจาก [บทบาท/ทีม]
8. กำหนดเวลาการทดสอบและการทบทวน
กำหนดความถี่ในการทดสอบและอัปเดตแผนนี้
สำเนาเทมเพลต: แผนกู้คืนจากภัยพิบัตินี้จะได้รับการทดสอบอย่างน้อย [ปีละครั้ง/ปีละสองครั้ง] และได้รับการทบทวนหลังจากเกิดเหตุการณ์สำคัญ การเปลี่ยนแปลงระบบ การเปลี่ยนแปลงผู้ให้บริการ หรือเมื่อการฝึกซ้อมการกู้คืนล้มเหลว
วิธีทดสอบแผนกู้คืนระบบไอทีจากภัยพิบัติ
แผนกู้คืนจากภัยพิบัติจะมีประโยชน์ก็ต่อเมื่อได้รับการทดสอบภายใต้สภาวะที่คล้ายกับสถานการณ์หยุดชะงักจริงเท่านั้น ข้อมูลสำรองที่มีอยู่แต่ไม่เคยได้รับการกู้คืนก็เป็นเพียงการสมมติ บทบาทการกู้คืนที่มีคนเข้าใจเพียงคนเดียวก็ยังเป็นเรื่องของการพึ่งพา และข้อมูลยืนยันตัวตนของผู้ดูแลระบบที่ไม่มีใครหาเจอในระหว่างที่ระบบขัดข้องก็ยังคงเป็นอุปสรรคขัดขวางอยู่ดี
ในระยะแรก การทดสอบไม่จำเป็นต้องซับซ้อน สำหรับ SMB ส่วนใหญ่ เป้าหมายคือการพิสูจน์ว่าธุรกิจสามารถกู้คืนระบบที่ถูกต้อง โดยบุคลากรที่เหมาะสม และใช้ข้อมูลยืนยันตัวตนที่ถูกต้อง ภายในกรอบเวลาที่เป็นไปได้จริง
1. การฝึกซ้อมบนโต๊ะ
เลือกสถานการณ์ที่มีโอกาสเกิดขึ้น เช่น แรนซัมแวร์ที่ส่งผลกระทบต่อไฟล์ที่แชร์ การหยุดทำงานของพื้นที่จัดเก็บข้อมูลบนคลาวด์ การลบข้อมูลลูกค้าโดยไม่ได้ตั้งใจ หรือการสูญเสียการเข้าถึงบัญชีผู้ดูแลระบบอย่างกะทันหัน จากนั้นไล่เลียงสิ่งที่ทีมงานจะทำในชั่วโมงแรก ใครจะเป็นผู้นำ จะติดต่อผู้ให้บริการรายใด จะจัดลำดับความสำคัญของระบบใด และข้อมูลใดที่อาจขาดหายไป
2. ทดสอบการกู้คืน
เลือกไฟล์ที่สำคัญ ฐานข้อมูล กล่องจดหมาย หรือการส่งออกระบบ และยืนยันว่าสามารถกู้คืนสู่สถานะที่ใช้งานได้ ตรวจสอบว่าข้อมูลที่กู้คืนมานั้นเป็นข้อมูลล่าสุดเพียงพอหรือไม่ สิทธิ์การใช้งานต่าง ๆ ยังคงทำงานได้หรือไม่ และทีมงานทราบหรือไม่ว่าข้อมูลสำรองนั้นจัดเก็บอยู่ที่ใด
3. ทดสอบอย่างสม่ำเสมอ
ตามเกณฑ์มาตรฐานในทางปฏิบัติ SMB ควรทดสอบแผนอย่างน้อยปีละครั้งตามแนวทางของ NIST ใน Special Publication 800-34 ฉบับปรับปรุงครั้งที่ 1(หน้าต่างใหม่) และบ่อยขึ้นหลังจากเกิดการเปลี่ยนแปลงที่สำคัญในระบบหรือผู้ให้บริการ
4. ทดสอบการกู้คืนข้อมูลยืนยันตัวตน
ยืนยันว่าบุคคลที่ได้รับอนุญาตสามารถเข้าถึงบัญชีผู้ดูแลระบบสําหรับการสํารองข้อมูล บัญชีผู้ดูแลระบบคลาวด์ พอร์ทัลของผู้ให้บริการ รหัสกู้คืน และข้อมูลยืนยันตัวตนในกรณีฉุกเฉินได้ โดยไม่ต้องพึ่งพาเบราว์เซอร์ บันทึกส่วนตัว หรือความจำของพนักงานเพียงคนเดียว เป้าหมายไม่ใช่การเปิดเผยรหัสผ่านที่ละเอียดอ่อนโดยไม่จำเป็น แต่เป็นการยืนยันว่ารูปแบบการเข้าถึงยังคงใช้งานได้จริงเมื่อธุรกิจอยู่ภายใต้ความกดดัน
หลังจากการทดสอบทุกครั้ง ให้บันทึกสิ่งที่เป็นปัญหา สิ่งที่ใช้เวลานานเกินไป พร้อมทั้งมอบหมายผู้รับผิดชอบที่เฉพาะเจาะจงและกำหนดเวลาสำหรับแต่ละวิธีแก้ไข การทดสอบที่ดีไม่ใช่การทดสอบที่ทุกอย่างเป็นไปอย่างราบรื่นไม่มีที่ติ แต่เป็นการทดสอบที่เผยให้เห็นช่องว่างในขณะที่ธุรกิจยังมีเวลาแก้ไขปัญหาเหล่านั้น
สร้างการกู้คืนโดยเน้นระบบ ข้อมูล และการเข้าถึง
แผนกู้คืนระบบไอทีจากภัยพิบัติที่มีประโยชน์จะช่วยให้ธุรกิจมีลำดับการกู้คืนที่ชัดเจน กลุ่มผู้รับผิดชอบ มุมมองที่เป็นจริงเกี่ยวกับการหยุดทำงานที่ยอมรับได้ ตลอดจนแนวทางในการรักษาความต่อเนื่องทางธุรกิจและกู้คืนการเข้าถึงระบบต่าง ๆ ที่ช่วยขับเคลื่อนให้การทำงานดำเนินต่อไปได้
สำหรับ SMB สิ่งนี้อาจสร้างความแตกต่างระหว่างการหยุดชะงักในช่วงสั้น ๆ กับการหยุดทำงานที่ยืดเยื้อ หากอีเมล ซอฟต์แวร์การเงิน พื้นที่จัดเก็บข้อมูลบนคลาวด์ ระบบลูกค้า หรือบัญชีผู้ดูแลระบบไม่สามารถใช้งานได้ ทีมงานจำเป็นต้องทราบว่าสิ่งใดต้องกู้คืนก่อนเป็นอันดับแรก ใครสามารถดำเนินการได้บ้าง และต้องใช้ข้อมูลยืนยันตัวตนใดบ้างในการกู้คืนการเข้าถึงอย่างปลอดภัย
นี่คือเหตุผลที่การวางแผนการกู้คืนควรครอบคลุมระบบ ข้อมูล และการเข้าถึงไปพร้อมกัน ข้อมูลสำรองอาจสามารถกู้คืนไฟล์ได้ แต่ข้อมูลยืนยันตัวตนคือสิ่งที่จะช่วยให้ทีมงานสามารถกลับมาควบคุมระบบที่จำเป็นสำหรับการกู้คืนได้ การเข้าสู่ระบบของผู้ดูแลระบบ พอร์ทัลของผู้ให้บริการ บัญชีสำหรับการสำรองข้อมูล รหัสกู้คืน และข้อมูลยืนยันตัวตนเพื่อการดำเนินงานที่มีการแชร์ร่วมกัน ล้วนจำเป็นต้องได้รับการปกป้อง จัดระเบียบ และพร้อมใช้งานสำหรับบุคคลที่เหมาะสมเมื่อเกิดข้อผิดพลาดขึ้น
โปรแกรมจัดการรหัสผ่านสำหรับธุรกิจจะช่วยเพิ่มความแข็งแกร่งให้แก่ส่วนนี้ของแผน เมื่อจัดเก็บข้อมูลยืนยันตัวตนที่สำคัญไว้ในห้องนิรภัยเก็บรหัสผ่านที่เข้ารหัสและแชร์กับบุคคลที่ได้รับอนุญาตเท่านั้น ธุรกิจก็จะลดการพึ่งพาเบราว์เซอร์ บันทึกส่วนตัว หรือความจำของพนักงานเพียงคนเดียวในระหว่างเหตุการณ์กู้คืนระบบลงได้
