แผนกู้คืนหลังโดนแรนซัมแวร์: RTO, RPO และการซ้อม

แผนกู้คืนหลังโดนแรนซัมแวร์ (ransomware คือมัลแวร์ที่เข้ารหัสข้อมูลแล้วเรียกค่าไถ่) คือเอกสารที่เขียนไว้ก่อนเกิดเหตุ ว่าเมื่อระบบถูกเข้ารหัสจนใช้ไม่ได้ ใครทำอะไร ระบบไหนต้องกลับมาก่อน และต้องเสร็จเมื่อไร ตัวเลขสำคัญของแผนมีสองค่า คือ RTO (เป้าหมายว่าจะกู้ระบบให้กลับมาใช้ได้ภายในกี่ชั่วโมง) และ RPO (ข้อมูลที่ยอมให้หายได้ ย้อนหลังกี่ชั่วโมง) บทความนี้อธิบายสองค่านี้ด้วยตัวอย่างคำนวณ ต่อด้วยสิ่งที่แผนควรมีและวิธีซ้อม ส่วนมาตรการป้องกันพื้นฐานอยู่ใน วิธีป้องกันแรนซัมแวร์: 5 ขั้นตอนที่องค์กรทำได้ทันที

RTO และ RPO ในภาษาง่าย

ลองนึกถึงระบบบัญชีที่ถูกเข้ารหัสเมื่อบ่ายวันอังคาร ต้องตอบสองข้อ ข้อแรก ระบบต้องกลับมาใช้ได้ช้าที่สุดเมื่อไรจึงยังรับได้ ข้อสอง ข้อมูลที่หายไประหว่างรอบ backup (การสำรองข้อมูล) ล่าสุดกับตอนถูกโจมตี รับได้มากที่สุดกี่ชั่วโมง สองข้อนี้คือ RTO และ RPO

นิยามตามเอกสารของ NIST (สถาบันมาตรฐานและเทคโนโลยีของสหรัฐฯ) เรียบเรียงเป็นภาษาไทยได้ดังนี้:

• RTO (Recovery Time Objective, เป้าหมายเวลากู้คืน): เวลานานที่สุดที่ระบบหนึ่งไม่พร้อมใช้งานได้ ก่อนผลกระทบต่องานหลักจะรับไม่ได้ ใช้เป็นเป้าว่า "ต้องกู้เสร็จภายในกี่ชั่วโมง"
• RPO (Recovery Point Objective, เป้าหมายจุดเวลาที่กู้ข้อมูลกลับได้): NIST SP 800-209 อธิบายว่าคือปริมาณข้อมูลที่ยอมให้หายได้หลังเหตุ วัดเป็นเวลา เช่น RPO 4 ชั่วโมง คือยอมเสียข้อมูลของ 4 ชั่วโมงสุดท้าย ส่วน NIST SP 800-34 มองมุมกลับกัน คือจุดเวลาล่าสุดก่อนเหตุที่กู้ข้อมูลกลับมาได้
• MTD (Maximum Tolerable Downtime, เวลาหยุดสูงสุดที่ยอมรับได้): เพดานเวลาที่เจ้าของระบบยอมให้กระบวนการทางธุรกิจหนึ่งหยุดชะงัก RTO ต้องสั้นกว่า MTD เพราะหลังกู้ระบบเสร็จ ยังต้องใช้เวลาประมวลผลข้อมูลที่ค้างอยู่ NIST SP 800-34 ยกเหตุผลนี้ไว้

RPO เป็นตัวกำหนดว่าต้อง backup บ่อยแค่ไหน ส่วน RTO ช่วยเลือกเทคโนโลยีและวิธีกู้ให้ทันเวลา NIST SP 800-34 แนะนำให้ผู้ทำแผนกำหนดเวลาที่ยอมรับได้ ร่วมกับเจ้าของกระบวนการทางธุรกิจและผู้บริหาร ไม่ใช่ให้ฝ่ายไอทีตั้งเอง ส่วน NIST SP 800-209 เตือนให้ชั่งน้ำหนักระหว่างความเร็วที่ต้องการกับค่าใช้จ่ายของการทำให้ทุกส่วนเร็วตามนั้น

ตัวอย่างคำนวณ: ระบบบัญชีขององค์กรสมมติ

ตัวอย่างนี้ใช้ตัวเลขสมมติ เพื่อให้เห็นวิธีคิด ไม่ใช่ค่าที่ควรลอกไปใช้ องค์กรสมมติมีระบบบัญชีที่มีข้อมูลรวม 6 TB (เทราไบต์) ในตัวอย่างนี้ถือว่า 1 TB เท่ากับ 1,000,000 MB (เมกะไบต์) ข้อมูลจึงมี 6,000,000 MB ฝ่ายธุรกิจตั้งเป้า RPO 4 ชั่วโมง และ RTO 24 ชั่วโมง ส่วนเพดานเวลาหยุดที่ธุรกิจรับได้ (MTD) คือ 48 ชั่วโมง RTO 24 ชั่วโมงจึงสั้นกว่า MTD ตามหลักข้างต้น ตอนนี้ระบบสำรองข้อมูลทุกคืนเวลา 01:00 น.

เริ่มจาก RPO สมมติแรนซัมแวร์เข้ารหัสระบบตอน 15:00 น. วันอังคาร และ backup ล่าสุดคือ 01:00 น. ของวันเดียวกัน ข้อมูลที่หายคือ 14 ชั่วโมง (15:00 ลบ 01:00) ซึ่งเกินเป้า 4 ชั่วโมงอยู่ 10 ชั่วโมง ถ้าถูกโจมตีก่อนรอบ backup ถัดไปไม่นาน ข้อมูลจะหายเกือบ 24 ชั่วโมงเต็ม เพราะรอบ backup ห่างกัน 24 ชั่วโมง การได้ RPO 4 ชั่วโมงจึงต้อง backup อย่างน้อยทุก 4 ชั่วโมง คือ 24 หาร 4 เท่ากับ 6 รอบต่อวัน เป็น 6 เท่าของตอนนี้ (ตอนนี้ 1 รอบต่อวัน)

แต่ 14 ชั่วโมงนี้ยังเป็นกรณีที่เบาที่สุด เพราะสมมติว่า backup ล่าสุดสะอาด CISA (หน่วยงานด้านความมั่นคงปลอดภัยไซเบอร์ของสหรัฐฯ) ระบุว่าการเจอแรนซัมแวร์อาจแปลว่ามีผู้บุกรุกเข้ามาก่อนหน้านี้แล้วและยังไม่ถูกแก้ไข ดังนั้น backup ล่าสุดอาจติดมาด้วย สมมติว่าตรวจพบว่าผู้โจมตีเข้ามาหลัง 01:00 น. ของเช้าวันอาทิตย์ backup เวลา 01:00 น. วันอาทิตย์จึงยังสะอาด และเป็นจุดกู้ที่สะอาดล่าสุด ข้อมูลที่หายจะเป็น 62 ชั่วโมง (วันอาทิตย์ 01:00 ถึงวันอังคาร 15:00 คือ 24 + 24 + 14) เกินเป้า 4 ชั่วโมงอยู่ถึง 58 ชั่วโมง ข้อมูลที่หายจริงจึงขึ้นกับว่าสำเนาไหนสะอาด ไม่ได้ขึ้นกับรอบ backup อย่างเดียว

ต่อไปคือ RTO การกู้คืนไม่ใช่แค่คัดลอกข้อมูลกลับ ตัวอย่างนี้แบ่งเป็น 5 งาน ทำต่อกันตามลำดับ (เวลาเป็นตัวเลขสมมติ):

• ยืนยันขอบเขตและแยกระบบที่ติดออกจากเครือข่าย: 3 ชั่วโมง
• สร้างระบบจัดการบัญชีผู้ใช้ (Active Directory) และเซิร์ฟเวอร์หลักใหม่จากต้นแบบที่สะอาด: 8 ชั่วโมง
• สแกนสำเนาและเลือกจุดกู้ที่สะอาด: 4 ชั่วโมง
• กู้ข้อมูล 6 TB ด้วยความเร็วจริงเฉลี่ย 200 MB ต่อวินาที: 6,000,000 MB หาร 200 ได้ 30,000 วินาที หรือ 8 ชั่วโมง 20 นาที (30,000 หาร 3,600 ได้ 8.33 ชั่วโมง)
• ทดสอบระบบและให้ผู้ใช้ตรวจ: 4 ชั่วโมง

รวมเป็น 27 ชั่วโมง 20 นาที (3 + 8 + 4 + 8 ชั่วโมง 20 นาที + 4) เกินเป้า RTO 24 ชั่วโมงอยู่ 3 ชั่วโมง 20 นาที แต่ยังไม่เกิน MTD 48 ชั่วโมง ถ้าต้องการให้ทัน ต้องลดเวลาของบางงาน เช่น ให้กู้ข้อมูลเสร็จใน 5 ชั่วโมง (24 − 3 − 8 − 4 − 4 = 5) ซึ่งต้องกู้ได้ 6,000,000 MB หาร 18,000 วินาที ได้ประมาณ 333 MB ต่อวินาที เร็วกว่าเดิมราว 1.7 เท่า (333 หาร 200 ได้ราว 1.67) ในงานจริงบางงานทำคู่ขนานกันได้ จึงต้องวัดเวลาจากการซ้อมจริง ตัวเลข RTO ที่เขียนไว้บนกระดาษยังเป็นแค่เป้าหมาย

ตัวอย่างนี้ชี้ว่า RTO ขึ้นกับงานทุกอย่างระหว่างทาง ไม่ใช่แค่ความเร็วในการคัดลอกข้อมูล และ RPO ขึ้นกับจุดกู้ที่สะอาด ไม่ใช่แค่ความถี่ของ backup ตัวอย่างนี้ยังไม่รวมเวลาหาและกำจัดต้นเหตุ ซึ่งในเหตุจริงอาจใช้เวลานานกว่านี้มาก (ดูหัวข้อถัดไป) และนี่คือข้อสรุปจากการคำนวณตัวอย่างสมมติของเรา ไม่ใช่ค่าที่เอกสารของ NIST หรือ CISA กำหนด

แผนกู้คืนควรมีอะไรบ้าง

NIST SP 800-184 (คู่มือการกู้คืนหลังเหตุการณ์ไซเบอร์) เรียกแผนที่ใช้ได้จริงว่า playbook (คู่มือปฏิบัติที่เขียนขั้นตอนไว้ล่วงหน้า) และให้เขียนไว้ก่อนเกิดเหตุ รายการต่อไปนี้เรียบเรียงจากทั้ง NIST และ CISA:

• รายการระบบ รายชื่อคนที่เกี่ยวข้อง และความพึ่งพากันระหว่างระบบ (dependency): ระบบไหนต้องกู้ก่อนระบบไหน NIST SP 800-184 ยกตัวอย่างว่ามักต้องกู้ระบบบัญชีผู้ใช้ที่ใช้ยืนยันตัวตนก่อนไฟล์และอีเมล และ NIST SP 800-209 ระบุว่าต้องปกป้อง Active Directory และ DNS (ระบบที่เชื่อมชื่อโดเมนกับเครื่อง) ไว้เพื่อให้กู้ระบบได้ครบ
• ลำดับความสำคัญของระบบ: CISA แนะนำให้จัดตามความสำคัญต่อชีวิตและความปลอดภัย รายได้ และบริการหลักขององค์กร รวมถึงระบบอื่นที่ระบบสำคัญเหล่านั้นต้องพึ่ง
• RTO และ RPO ของแต่ละระบบ: ตั้งตามวิธีในตัวอย่างข้างต้น
• เงื่อนไขเริ่มใช้แผน และผู้มีอำนาจสั่ง: NIST แนะนำให้ระบุว่าเมื่อใดจึงเริ่มใช้แผน ใครสั่งได้ และจะแจ้งทีมกู้คืนอย่างไร
• ที่เก็บ backup และวิธีเข้าถึง: รวมสำเนานอกสถานที่และสำเนา offline (ถอดการเชื่อมต่อไว้) ดู กลยุทธ์ Backup 3-2-1-1-0 และ Immutable Backup
• แผนสื่อสาร: ทั้งภายในและภายนอก ตั้งแต่ผู้บริหาร ฝ่ายกฎหมาย ฝ่ายประชาสัมพันธ์ ผู้ให้บริการ ไปจนถึงหน่วยงานที่ต้องแจ้ง
• วิธีทำงานชั่วคราว (workaround): NIST แนะนำให้เตรียมขั้นตอนที่อนุมัติไว้แล้ว สำหรับกรณีกู้ระบบไม่ทันตาม RTO
• เกณฑ์ประกาศว่ากู้คืนเสร็จ: NIST SP 800-61 Rev. 3 แนะนำให้ประกาศจบการกู้คืนตามเกณฑ์ที่กำหนดไว้ และทำเอกสารเหตุการณ์ให้ครบ

ถ้าเหตุกระทบข้อมูลส่วนบุคคล ต้องดูหน้าที่แจ้งเหตุตาม PDPA (พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล) แหล่งข้อมูลรองที่เราค้นสรุปว่าต้องแจ้งสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลโดยไม่ชักช้า และภายใน 72 ชั่วโมงนับจากที่ทราบเหตุ เท่าที่ทำได้ ยกเว้นเหตุที่ไม่น่าจะกระทบสิทธิของบุคคล เราไม่ได้ตรวจตัวบทกฎหมายฉบับทางการ จึงควรให้ฝ่ายกฎหมายยืนยันข้อกำหนดล่าสุดแล้วใส่ไว้ในแผนสื่อสาร

แผนกู้คืนเชื่อมกับแผนรับมือเหตุการณ์อย่างไร

NIST SP 800-61 Rev. 3 (เมษายน 2025) มองการกู้คืนเป็นส่วนหนึ่งของการรับมือเหตุการณ์ (incident response) ส่วนฟังก์ชัน Recover ซึ่งเป็นหนึ่งในฟังก์ชันหลักของ CSF (กรอบการจัดการความเสี่ยงไซเบอร์ของ NIST) เวอร์ชัน 2.0 หมายถึงการทำให้ทรัพย์สินและการดำเนินงานที่ได้รับผลกระทบกลับมาใช้ได้ เอกสารนี้ระบุว่าสมัยก่อนการรับมือและกู้คืนมักเสร็จใน 1-2 วัน แต่ปัจจุบันเหตุเกิดบ่อยและเสียหายมากกว่า การกู้คืนมักใช้เวลาเป็นสัปดาห์หรือเป็นเดือน ข้อสังเกตของเรา RTO ของระบบหนึ่งไม่ได้แปลว่าทั้งองค์กรจะกลับมาปกติในเวลานั้น จึงควรมีวิธีทำงานชั่วคราวรองรับ

ขั้นตอนกู้คืนหลักตามแนวทางของ CISA และ NIST SP 800-61 Rev. 3 มีดังนี้:

• แยกระบบที่ติดออกและจัดลำดับระบบที่จะกู้: CISA แนะนำให้แยกระบบที่ได้รับผลกระทบทันที ใช้ช่องทางสื่อสารนอกเครือข่าย เช่น โทรศัพท์ เพื่อไม่ให้ผู้โจมตีรู้ตัว และจัดลำดับการกู้ตามรายการระบบสำคัญที่เตรียมไว้
• กำจัดต้นเหตุก่อนกู้: CISA แนะนำให้หามัลแวร์ตัวนำ (dropper) และการเข้าถึงที่ผู้โจมตีทิ้งไว้ ก่อนกู้จาก backup เพื่อไม่ให้ติดซ้ำ
• ตรวจสำเนาก่อนใช้: NIST SP 800-61 Rev. 3 แนะนำให้ตรวจร่องรอยการบุกรุก ไฟล์เสียหาย และปัญหาความสมบูรณ์ของข้อมูลในสำเนา ก่อนนำไปกู้
• กู้บนเครือข่ายที่สะอาดตามลำดับความสำคัญ: CISA แนะนำให้สร้างระบบใหม่จากต้นแบบระบบที่ตั้งค่าไว้ (image หรือ golden image) ถ้ามี และถ้าสร้างเครือข่ายย่อยเสมือน (VLAN) ใหม่เพื่อกู้ ให้เพิ่มเฉพาะระบบที่สะอาด
• รีเซ็ตรหัสผ่านและปิดช่องโหว่: หลังทำความสะอาดและสร้างระบบใหม่เสร็จ CISA แนะนำให้รีเซ็ตรหัสผ่านของระบบและบัญชีที่ได้รับผลกระทบ แพตช์ช่องโหว่ และเปลี่ยนกุญแจเข้ารหัสที่องค์กรจัดการเองตามความจำเป็น ควรตรวจบัญชีที่ผู้โจมตีอาจสร้างไว้ด้วย ดู ITDR: ตรวจจับและตอบสนองการโจมตีที่เล็งตัวตน
• ตรวจระบบที่กู้แล้ว ประกาศจบ และเก็บบทเรียน: NIST แนะนำให้ตรวจความสมบูรณ์ของระบบที่กู้ ยืนยันกับเจ้าของระบบ แล้วประกาศจบตามเกณฑ์ CISA แนะนำให้บันทึกบทเรียนเพื่อปรับแผน

การซ้อม: ทำให้ตัวเลข RTO และ RPO เป็นจริง

NIST SP 800-184 แนะนำให้ใช้ทั้ง exercise (การซ้อมสถานการณ์) และ test (การทดสอบทางเทคนิคจริง) ผลที่ได้คือรู้ว่าสิ่งที่แผนสมมติไว้ถูกหรือผิด โดยเฉพาะว่าเป้าหมายการกู้คืนทำได้จริงหรือไม่ ช่วยเผยช่องว่างของขั้นตอน และฝึกคนที่เพิ่งได้รับหน้าที่ใหม่ NIST ไม่ได้กำหนดความถี่ตายตัว ให้องค์กรกำหนดเองให้เหมาะสมและบันทึกผลทุกครั้ง

รูปแบบการซ้อมที่ใช้ได้:

• Tabletop (ซ้อมบนโต๊ะ: ผู้เกี่ยวข้องนั่งคุยตามสถานการณ์สมมติ): NIST แนะนำให้แต่ละทีมมีอย่างน้อยหนึ่งคนรับบทผู้โจมตี คอยสร้างอุปสรรคที่สมจริง และใช้เหตุการณ์จริงที่เป็นข่าวเป็นโจทย์ได้ ถ้าต้องการเครื่องมือช่วยจำลอง ดู Network & Cyber Security Simulator: ประเภทและการใช้งาน
• ทดสอบกู้คืนจริง: เลือกระบบหนึ่ง กู้จาก backup ไปยังพื้นที่แยก จับเวลาเทียบกับ RTO NIST SP 800-209 แนะนำให้ทดสอบกู้คืนเป็นระยะ เพื่อให้แน่ใจว่าเสร็จทันเวลาที่ต้องการ
• ซ้อมโดยไม่มีระบบปกติ: ให้ทีมสื่อสารผ่านช่องทางสำรอง และทำงานตามแผนฉบับพิมพ์ CISA แนะนำให้มีแผนทั้งฉบับพิมพ์และฉบับ offline
• ทบทวนหลังซ้อม: NIST แนะนำให้ทบทวนผลอย่างรอบด้านว่าอะไรได้ผลและอะไรไม่ได้ผล แล้วปรับแผน

NIST SP 800-184 ยกตัวอย่างตัวชี้วัดที่ใช้ติดตามได้ เช่น สัดส่วนการกู้คืนจาก backup ที่สำเร็จและทันเวลา จำนวนครั้งที่การกู้คืนบรรลุเป้าหมาย และจำนวนช่องว่างที่พบจากการซ้อม ตัวชี้วัดเหล่านี้ทำให้เห็นว่า RTO และ RPO ที่ตั้งไว้ทำได้จริงหรือไม่ NIST ยังเตือนว่าการเก็บตัวชี้วัดต้องไม่ขัดขวางงานกู้คืนจริง

ข้อผิดพลาดที่พบบ่อย

• ให้ฝ่ายไอทีตั้ง RTO และ RPO เองโดยไม่ถามเจ้าของงาน: NIST แนะนำให้กำหนดร่วมกับเจ้าของกระบวนการทางธุรกิจและผู้บริหาร
• นับเวลากู้เฉพาะตอนคัดลอกข้อมูล: ลืมเวลายืนยันขอบเขต สร้างระบบใหม่ สแกนสำเนา และตรวจสอบก่อนเปิดใช้ ซึ่งในตัวอย่างข้างต้นรวมกัน 19 จาก 27 ชั่วโมง 20 นาที คือมากกว่าสองในสามของเวลาทั้งหมด
• เข้าใจว่า RPO เท่ากับรอบ backup เสมอ: ถ้าสำเนาล่าสุดไม่สะอาด ต้องย้อนไปจุดที่เก่ากว่า ข้อมูลที่หายจึงมากกว่าที่คำนวณจากรอบ backup
• เก็บแผนไว้ในเซิร์ฟเวอร์ที่อาจถูกเข้ารหัสไปด้วย: CISA แนะนำให้มีแผนทั้งฉบับพิมพ์และฉบับ offline
• ซ้อมเฉพาะทีมไอที: NIST แนะนำให้ซ้อมทั้งด้านเทคนิคและด้านที่ไม่ใช่เทคนิค เช่น บุคลากรและประเด็นทางกฎหมาย
• รีบกู้โดยยังไม่กำจัดต้นเหตุ: ระบบที่กู้ขึ้นมาอาจถูกโจมตีซ้ำ เพราะมัลแวร์ตัวนำหรือบัญชีที่ผู้โจมตีทิ้งไว้ยังอยู่
• ไม่ปรับแผนเมื่อระบบเปลี่ยน: แผนผังความพึ่งพากันและตัวเลข RTO และ RPO ที่ล้าสมัยจะพาให้กู้ผิดลำดับหรือกู้ไม่ทัน

ขั้นแรกที่ทำได้ทันที

• เลือกระบบสำคัญ 3 ระบบ: ถามเจ้าของงานว่าต้องกู้ให้เสร็จภายในกี่ชั่วโมง (RTO) และยอมเสียข้อมูลย้อนหลังได้กี่ชั่วโมง (RPO)
• เทียบรอบ backup ปัจจุบันกับ RPO: ใช้วิธีเดียวกับตัวอย่างข้างต้น หาว่าต้อง backup ถี่ขึ้นกี่เท่า
• ลองกู้หนึ่งระบบและจับเวลาแต่ละขั้น: เอาตัวเลขจริงมาแทนตัวเลขสมมติ
• เขียนแผนผังความพึ่งพากันหน้าเดียว: ระบุว่าระบบบัญชีผู้ใช้และ DNS ต้องมาก่อนระบบอื่นหรือไม่
• พิมพ์รายชื่อผู้ติดต่อและขั้นตอนกู้คืนเก็บไว้นอกระบบ: ให้เปิดอ่านได้แม้เครือข่ายใช้ไม่ได้
• นัด tabletop หนึ่งครั้งในไตรมาสนี้: ให้มีฝ่ายกฎหมาย สื่อสารองค์กร และผู้บริหารเข้าร่วมด้วย

หากต้องการประเมินความพร้อมโดยรวมขององค์กร ลองใช้ แบบประเมินตนเอง

แผนกู้คืนเป็นส่วนหนึ่งของแผนรับมือเหตุการณ์ทั้งหมด ดู แผนรับมือเหตุการณ์ตาม NIST SP 800-61 Rev. 3

เมื่อมีแผนกู้คืนแล้ว ใช้ Tabletop Ransomware: แม่แบบสถานการณ์พร้อมใช้ ซ้อมแผนกับทีม

แหล่งอ้างอิงและข้อมูลเพิ่มเติม

• NIST SP 800-184: Guide for Cybersecurity Event Recovery: playbook การซ้อม ตัวชี้วัด และตัวอย่างการกู้คืนจากแรนซัมแวร์
• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations: ฟังก์ชัน Recover ข้อแนะนำการตรวจสำเนาก่อนกู้ และเกณฑ์ประกาศจบ
• CISA #StopRansomware Guide: รายการตรวจสำหรับตอบสนองและกู้คืนจากแรนซัมแวร์
• NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems: นิยามของ MTD, RTO และ RPO
• NIST SP 800-209: Security Guidelines for Storage Infrastructure: ข้อแนะนำเรื่อง RTO, RPO และการทดสอบกู้คืน
• CISA Back Up Government Data: การทดสอบกู้คืนและการย้อนข้อมูลอย่างน้อย 7 วัน
• NIST SP 800-84: Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities: คู่มือโปรแกรมทดสอบและซ้อมที่ NIST SP 800-184 อ้างถึง