"ระบบนี้เรามีแบ็กอัปไหม" "เก็บไว้กี่เวอร์ชัน" "กู้คืนต้องใช้เวลาเท่าไร"
นี่คือคำถามที่ผมได้ยินจากผู้บริหารบ่อยที่สุด แต่มักได้ยินในวันที่ระบบหยุดไปแล้ว และถ้าการกู้คืนรอบแรกไม่สำเร็จ คำถามถัดไปจะตามมาทันที "แล้วข้อมูลของเราเก็บไว้ที่ไหนบ้าง"
ทุกคำถามถูกต้องหมด เพียงแต่ถามช้าไปหนึ่งวัน
สรุปสั้นสำหรับรายงานเจ้าของกิจการ
การมีแบ็กอัปยังไม่ได้แปลว่ากู้คืนได้ทันเวลา และการกู้ระบบได้ครบก็ยังไม่ได้แปลว่าธุรกิจเดินต่อได้ เราควรเริ่มจากทำรายการว่าระบบไหนสำคัญต่องานส่วนไหน กำหนดว่าแต่ละระบบหยุดได้นานที่สุดเท่าไร แล้วทดสอบกู้คืนจริงทุกไตรมาส พร้อมรายงานผลเป็นตัวเลข ถ้าต้องลงทุนเพิ่ม ก็ลงเฉพาะจุดที่ยังมีช่องว่าง
สิ่งที่เห็นจากเหตุการณ์จริง
มีสองเหตุการณ์ที่ผมได้เห็นใกล้ชิด และเล่าให้เห็นภาพได้ดี (ปรับรายละเอียดบางส่วนเพื่อรักษาความลับ)
ที่สถานพยาบาลแห่งหนึ่ง ระบบที่เจ้าหน้าที่ใช้เปิดดูข้อมูลของคนไข้ใช้งานไม่ได้อยู่หลายชั่วโมง งานที่ต้องใช้ระบบนี้ต้องเปลี่ยนไปทำแบบ manual ชั่วคราว กว่าระบบจะกลับมา ต้องไล่กู้ข้อมูลจากแบ็กอัปหลายแหล่ง และทดสอบว่าข้อมูลที่กู้มาครบและใช้ได้จริงก่อนเปิดใช้งาน การทดสอบกู้คืนที่ควรได้ทำในวันปกติ จึงต้องมาทำกันตอนที่ระบบหยุดอยู่
อีกแห่งเป็นธุรกิจขนาดกลาง ระบบที่ได้รับผลกระทบคือระบบบัญชีและระบบบุคคล จนเงินเดือนพนักงานเกือบออกไม่ทัน
สาเหตุของทั้งสองแห่งคล้ายกันมาก คือพื้นที่จัดเก็บข้อมูลเหลือน้อยจนระบบหยุด เพราะมี snapshot (สำเนาชั่วคราวของระบบ ณ เวลาหนึ่ง) ค้างอยู่โดยไม่มีใครรู้ ประกอบกับข้อมูลที่โตขึ้นทุกเดือน โดยไม่มีระบบเฝ้าดูและแจ้งเตือนล่วงหน้า
ไม่มีการโจมตี ไม่มีใครตั้งใจทำผิด เพียงแต่ไม่มีใครเห็นสัญญาณก่อนที่ระบบจะหยุด
เรื่องแบบนี้ไม่ได้เกิดแค่สองที่ สิ่งที่ผมเห็นซ้ำในหลายองค์กรคือ ทุกคนพูดได้ว่า "ต้องทำ DR (ระบบสำรองสำหรับกู้คืนเมื่อเกิดเหตุใหญ่)" และ "ต้องมี BCP (แผนให้ธุรกิจเดินต่อได้เมื่อเกิดเหตุ)" แต่ตอบไม่ได้ว่าระบบไหนบ้างที่ต้องทำ และแต่ละระบบผูกกับงานส่วนไหนของธุรกิจ
และต่อให้กู้ระบบได้ ก็ยังไม่ได้แปลว่าธุรกิจเดินต่อได้ ลองดูกรณีน้ำท่วม สมมติทีมไอทีกู้ระบบกลับมาได้ครบ 100% แต่พนักงานเข้าโรงงานไม่ได้ ระบบที่กู้คืนมาก็ยังใช้ทำงานไม่ได้อยู่ดี ถ้าไม่เริ่มจากคำถามทางธุรกิจ เงินลงทุนเรื่อง DR มักลงเกินจำเป็น กับระบบที่ธุรกิจไม่ได้ต้องการให้กลับมาเร็วขนาดนั้น
ช่องว่างแบบนี้ไม่ได้อยู่ที่เทคโนโลยี และไม่ได้เกิดจากใครทำงานไม่ดี แต่อยู่ที่นโยบาย การบริหารความเสี่ยง และการรู้ว่าองค์กรมีระบบอะไรบ้าง
ถ้าได้คุยกับเจ้าของกิจการตั้งแต่ก่อนเกิดเหตุ ผมจะชวนตัดสินใจเรื่องเหล่านี้ก่อนพูดถึงอุปกรณ์ใด ๆ
- ระบบไหนสำคัญต่อธุรกิจ และถ้าหยุดจะกระทบงานส่วนไหน
- ความเสี่ยงข้อไหนจะแก้ ข้อไหนยอมรับไว้ก่อน โดยให้เจ้าของกิจการเป็นคนตัดสินใจเอง
- เมื่อเกิดเหตุจริง ธุรกิจจะเดินต่ออย่างไร รวมถึงกรณีที่คนเข้าสถานที่ไม่ได้
ตัวเลข 2 ตัวที่เจ้าของกิจการควรเป็นคนกำหนด
ก่อนจะถามเรื่องเทคนิค มีสองคำถามที่เป็นการตัดสินใจทางธุรกิจ ไม่ใช่ทางไอที
- ระบบหลักหยุดได้นานที่สุดเท่าไร เช่น ระบบขาย ระบบบัญชี หรือระบบผลิต หยุดได้ 4 ชั่วโมง 1 วัน หรือ 3 วัน ในภาษาไอที ตัวเลขนี้ใช้ตั้ง RTO (เป้าเวลากู้ระบบให้เสร็จ) ซึ่งต้องไม่เกินตัวเลขนี้
- ข้อมูลย้อนหลังหายได้มากที่สุดเท่าไร เช่น ถ้าต้องกู้คืนจากแบ็กอัปเมื่อคืน ข้อมูลของวันนี้ทั้งวันจะหายไป ธุรกิจรับได้หรือไม่ ในภาษาไอทีเรียกว่า RPO
ตัวเลขสองตัวนี้คือการบอกว่าธุรกิจ รับความเสียหายได้แค่ไหน เป็นการตัดสินใจแบบเดียวกับที่เจ้าของกิจการทำอยู่แล้ว เช่น ควรเก็บสต็อกสำรองไว้กี่วัน หรือควรทำประกันวงเงินเท่าไร ถ้าไม่มีใครกำหนด ทีมไอทีก็ต้องเดาเอาเอง และมักเดาจากงบที่มี ไม่ใช่จากสิ่งที่ธุรกิจต้องการ
5 คำถามสำหรับถามทีมไอที
ผมไม่มีตัวเลขสถิติที่นับไว้เป็นทางการ แต่จากที่เห็นมา ผมเชื่อว่าองค์กรที่ไม่เคยทดสอบกู้คืนจริงมีเกินครึ่ง และในองค์กรที่กู้คืนได้ ก็มีเกินครึ่งที่ใช้เวลานานกว่าที่ธุรกิจรับได้ ห้าคำถามนี้ช่วยให้รู้ว่าองค์กรของคุณอยู่ตรงไหน
- ทดสอบกู้คืนจริงครั้งล่าสุดเมื่อไร และใช้เวลากี่ชั่วโมง ขอดูผลการทดสอบจริง ไม่ใช่หน้าจอที่บอกว่าแบ็กอัปสำเร็จ เพราะแบ็กอัปสำเร็จกับกู้คืนได้เป็นคนละเรื่องกัน
- มีสำเนาอย่างน้อยหนึ่งชุดที่ลบหรือแก้ไขไม่ได้หรือไม่ แม้แต่คนที่ได้รหัสผู้ดูแลระบบไป ก็ต้องลบไม่ได้จนกว่าจะครบระยะเวลาที่กำหนด เพราะเหตุการณ์อย่างแรนซัมแวร์มักตามไปลบแบ็กอัปก่อนเสมอ
- สำเนาเก็บไว้คนละที่กับระบบหลักหรือไม่ หากเกิดไฟไหม้ น้ำท่วม หรืออุปกรณ์หายในที่เดียว สำเนาอีกชุดต้องยังอยู่
- ถ้าแบ็กอัปล้มเหลว ใครได้รับแจ้ง และใครเป็นคนตรวจ การแจ้งเตือนที่ส่งไปหาคนที่ลาออกไปแล้ว หรือไม่มีใครเปิดอ่าน เท่ากับไม่มีการแจ้งเตือน และควรถามต่อด้วยว่า มีใครเฝ้าดูพื้นที่จัดเก็บที่ใกล้เต็มหรือไม่ เพราะทั้งสองเคสข้างบนเริ่มจากเรื่องนี้
- มีอะไรบ้างที่ยังไม่ได้แบ็กอัป เช่น อีเมลบน Microsoft 365 ไฟล์บนเครื่องของผู้บริหาร หรือระบบบนคลาวด์ของผู้ให้บริการภายนอก หลายองค์กรเข้าใจว่าบริการคลาวด์สำรองข้อมูลให้ทุกอย่างอัตโนมัติ ซึ่งมักไม่เป็นเช่นนั้น
ถ้าทีมไอทีพูดถึงหลัก 3-2-1-1-0 ความหมายคือ มีข้อมูล 3 ชุด เก็บบนสื่อ 2 แบบ อยู่นอกสถานที่ 1 ชุด ลบหรือแก้ไขไม่ได้ 1 ชุด และทดสอบกู้คืนแล้วไม่มีข้อผิดพลาด ไม่จำเป็นต้องทำครบในวันเดียว ค่อย ๆ ปิดช่องว่างตามความสำคัญของระบบก็ได้
เริ่มได้โดยยังไม่ต้องซื้ออะไรเพิ่ม
สิ่งที่ผมแนะนำให้ทำก่อนเรื่องอื่น คือทำตาราง 2 ชุด ใช้แค่ Excel ก็พอ
ชุดแรก รายการระบบ ว่าองค์กรมีระบบอะไรบ้าง แต่ละระบบใช้กับงานไหน ใครเป็นเจ้าของงานนั้น ถ้าหยุดจะกระทบอะไร และใส่ตัวเลข 2 ตัวข้างต้นของแต่ละระบบไว้ด้วย คือหยุดได้นานที่สุดเท่าไร และข้อมูลย้อนหลังหายได้มากที่สุดเท่าไร
ชุดที่สอง ทะเบียนความเสี่ยง (Risk Register) ว่ามีความเสี่ยงอะไรบ้าง ข้อไหนจะแก้ ข้อไหนเจ้าของกิจการตัดสินใจยอมรับไว้ก่อน ใครเป็นคนตัดสินใจ และจะทบทวนอีกครั้งเมื่อไร
สองตารางนี้ทำให้การคุยเรื่อง DR และงบประมาณมีฐานเดียวกัน จากนั้นค่อยกำหนดให้ทดสอบกู้คืนระบบสำคัญทุกไตรมาส และบันทึกผลไว้
- วันที่ทดสอบ
- ระบบที่ทดสอบ
- เวลาที่ใช้กู้คืนจนใช้งานได้
- ผลลัพธ์และสิ่งที่ต้องแก้
- ผู้ทดสอบและผู้รับทราบ
แนวทางนี้สอดคล้องกับ NIST Cybersecurity Framework 2.0 ที่วางการกำกับดูแล (Govern) ไว้เป็นแกนกลางในการกำหนดทิศทาง และให้รู้ว่าองค์กรมีระบบและความเสี่ยงอะไร (Identify) ควบคู่กับการป้องกันและการกู้คืน ส่วนตารางชุดแรกคือจุดเริ่มต้นของการวิเคราะห์ผลกระทบทางธุรกิจ (BIA) ซึ่งเป็นพื้นฐานของมาตรฐานความต่อเนื่องทางธุรกิจ ISO 22301
4 ตัวเลขที่ผู้บริหารควรเห็นทุกไตรมาส
ผลทดสอบควรสรุปให้ผู้บริหารเห็นในรายงานหน้าเดียว ไม่ต้องมีรายละเอียดเชิงเทคนิค
- เวลากู้คืนจริงเทียบกับเป้าหมาย เช่น ตั้งเป้าไว้ 8 ชั่วโมง ทดสอบจริงได้ 6 ชั่วโมง
- ระบบสำคัญที่ผ่านการทดสอบกู้คืนในไตรมาสนี้ กี่ระบบจากทั้งหมด
- ระบบสำคัญที่มีสำเนาแบบลบไม่ได้และเก็บไว้นอกสถานที่ กี่ระบบจากทั้งหมด
- ปัญหาแบ็กอัปที่ค้างนานเกิน 7 วัน ควรเป็นศูนย์ หากยังมี ต้องมีชื่อผู้รับผิดชอบและวันที่คาดว่าจะแก้เสร็จ
เมื่อทุกคนเห็นตัวเลขชุดเดียวกัน การคุยเรื่องงบก็ง่ายขึ้น เพราะรู้ว่าเงินที่ขอเพิ่มจะทำให้ตัวเลขไหนดีขึ้น
ใครควรเป็นคนถามคำถามเหล่านี้
ยิ่งเห็นเคสจริงมาก ผมยิ่งเชื่อว่านโยบายไอทีต้องเริ่มจากธุรกิจ ทีมไอทีเก่งแค่ไหนก็ตอบแทนไม่ได้ว่าธุรกิจยอมให้ระบบไหนหยุดได้นานเท่าไร คำถามนี้ต้องมาจากฝั่งผู้บริหาร
ในบริษัทใหญ่ หน้าที่นี้เป็นของ CISO (ผู้บริหารที่ดูแลความเสี่ยงด้านไอทีและข้อมูล) ส่วนในธุรกิจขนาดกลาง มักตกอยู่กับเจ้าของกิจการเอง หรือกับทีมไอทีที่ต้องทั้งทำงานและตรวจงานของตัวเองไปพร้อมกัน ที่ปรึกษาแบบ vCISO (ทำหน้าที่ CISO เป็นรายเดือนหรือรายโครงการ) ช่วยตั้งคำถามเหล่านี้ ตรวจผลทดสอบ และสรุปเป็นภาษาธุรกิจให้ผู้บริหาร โดยไม่ต้องจ้างผู้บริหารเต็มเวลา
การสำรองข้อมูลดูเหมือนเป็นเรื่องง่าย แต่ถ้าเป็นข้อมูลของธุรกิจ คุณวางใจได้จริงแค่ไหน
อ่านต่อ: ถ้าคนดูแลไอทีลาออกพรุ่งนี้ รหัสผ่านและระบบของบริษัทอยู่กับใคร เพราะรหัสผู้ดูแลระบบที่อยู่กับคนเดียว ก็เป็นความเสี่ยงต่อแบ็กอัปเช่นกัน