กฎ Backup 3-2-1 คืออะไร? คู่มือวางแผนสำรองข้อมูลองค์กรให้รอดจากแรนซัมแวร์

กฎ Backup 3-2-1 คือหลักการสำรองข้อมูลที่ให้มีข้อมูลสำคัญ 3 ชุด เก็บบนสื่อ 2 ประเภท และมี 1 ชุดอยู่นอกสถานที่ เป้าหมายคือไม่ให้เหตุการณ์ใดเหตุการณ์หนึ่งทำลายข้อมูลทุกชุดได้พร้อมกัน หลักนี้ใช้ได้ตั้งแต่ผู้ใช้ตามบ้านจนถึงองค์กรขนาดใหญ่ และยังเป็นจุดเริ่มต้นที่ดีที่สุดของแผนสำรองข้อมูล แต่ในยุคที่แรนซัมแวร์ตั้งใจทำลายสำเนาสำรองก่อนเรียกค่าไถ่ องค์กรต้องเพิ่มเงื่อนไขอีกสองข้อ คือมีสำเนาที่ออฟไลน์หรือแก้ไขไม่ได้ และทดสอบกู้คืนจริง

กฎ 3-2-1 กำหนดอะไรบ้าง

เอกสาร Data Backup Options ที่ Carnegie Mellon University จัดทำให้ US-CERT ในปี 2012 สรุปกฎนี้ไว้สามข้อ

เอกสารเดียวกันแนะนำว่าองค์กรขนาดใหญ่ควรมีสำเนาหนึ่งชุดในสถานที่และอีกชุดนอกสถานที่ ซึ่งอาจเป็นบริการคลาวด์ เซิร์ฟเวอร์สำรองระยะไกล หรือระบบเทปขององค์กรเอง และหากข้อมูลเป็นความลับต้องเข้ารหัสและดูแลความปลอดภัยทางกายภาพของสื่อด้วย

ตัวอย่างการจัดวางตามกฎ 3-2-1 ขององค์กรขนาดกลาง คือข้อมูลใช้งานอยู่บนเซิร์ฟเวอร์หลัก สำเนาชุดแรกอยู่บนอุปกรณ์จัดเก็บสำรองในห้องเซิร์ฟเวอร์เดียวกันเพื่อกู้คืนได้เร็ว และสำเนาชุดที่สองอยู่บน Object Storage ของผู้ให้บริการคลาวด์หรือดาต้าเซ็นเตอร์อีกแห่ง

ทำไม 3-2-1 แบบเดิมไม่พอในยุคแรนซัมแวร์

กฎ 3-2-1 ถูกคิดขึ้นเพื่อรับมือความเสียหายทางกายภาพและความผิดพลาดของอุปกรณ์ แต่ผู้โจมตีในปัจจุบันตั้งใจกำจัดสำเนาสำรองก่อนลงมือ คู่มือ #StopRansomware ของ CISA, MS-ISAC, NSA และ FBI ระบุว่าแรนซัมแวร์หลายสายพันธุ์พยายามค้นหาแล้วลบหรือเข้ารหัสสำเนาสำรองที่เข้าถึงได้ หากสำเนาทั้งสามชุดเชื่อมต่ออยู่กับเครือข่ายเดียวกันและใช้บัญชีผู้ดูแลชุดเดียวกัน การมีสามชุดก็ไม่ช่วยอะไร

แนวทางของหน่วยงานความมั่นคงไซเบอร์จึงเพิ่มข้อกำหนดเข้ามา

• CISA แนะนำให้มีสำเนาสำรองแบบออฟไลน์ที่เข้ารหัส และทดสอบความพร้อมใช้กับความถูกต้องของสำเนาอย่างสม่ำเสมอในสถานการณ์กู้คืนจากภัยพิบัติ
• NCSC ของสหราชอาณาจักร แนะนำว่าไม่ควรให้สำเนาสำรองทุกชุดเชื่อมต่ออยู่พร้อมกัน เมื่อมีอย่างน้อยหนึ่งชุดออฟไลน์อยู่ตลอดเวลา เหตุการณ์เดียวจะไม่กระทบสำเนาทุกชุด
• CISA แนะนำเพิ่มให้เก็บ "golden image" ของระบบสำคัญ คือชุดระบบปฏิบัติการและซอฟต์แวร์ที่ตั้งค่าไว้ล่วงหน้า เพื่อสร้างระบบใหม่ได้เร็ว

จากข้อแนะนำเหล่านี้ วงการจึงนิยมต่อยอดกฎเดิมเป็น 3-2-1-1-0 โดยเลข 1 ที่เพิ่มมาหมายถึงสำเนาหนึ่งชุดที่ออฟไลน์หรือแก้ไขไม่ได้ และเลข 0 หมายถึงผลการทดสอบกู้คืนต้องไม่มีข้อผิดพลาด ตัวเลขชุดนี้เป็นแนวปฏิบัติของอุตสาหกรรม ไม่ใช่มาตรฐานทางการ แต่สะท้อนข้อแนะนำของหน่วยงานข้างต้นได้ตรง

Offsite, Offline และ Immutable ต่างกันอย่างไร

สามคำนี้มักถูกใช้แทนกัน แต่ป้องกันความเสี่ยงคนละแบบ

NCSC ย้ำว่าสำเนาออฟไลน์ต้อง "ตัดขาดทางดิจิทัล" ด้วย ไม่ใช่เพียงถอดสาย สำหรับการสำรองขึ้นคลาวด์ โปรแกรมสำรองข้อมูลไม่ควรถือข้อมูลรับรองที่ใช้งานได้ตลอดเวลาในขณะที่ไม่ได้สำรอง ส่วน CISA แนะนำให้พิจารณาการสำรองข้ามผู้ให้บริการคลาวด์ เผื่อกรณีบัญชีทั้งหมดภายใต้ผู้ให้บริการรายเดียวได้รับผลกระทบ

กำหนด RPO และ RTO ก่อนเลือกเครื่องมือ

คำถามแรกของแผนสำรองข้อมูลไม่ใช่ "ใช้ซอฟต์แวร์อะไร" แต่คือ "แต่ละระบบยอมเสียข้อมูลและหยุดทำงานได้เท่าใด" NIST SP 800-34 Rev. 1 นิยามสองค่านี้ไว้ว่า

• RPO (Recovery Point Objective) คือจุดเวลาที่ต้องกู้ข้อมูลกลับไปให้ได้หลังเกิดเหตุขัดข้อง
• RTO (Recovery Time Objective) คือระยะเวลารวมที่ส่วนประกอบของระบบอยู่ในช่วงกู้คืนได้ ก่อนจะส่งผลเสียต่อภารกิจหรือกระบวนการทางธุรกิจขององค์กร

RPO กำหนดความถี่ในการสำรอง ส่วน RTO กำหนดวิธีกู้คืนและตำแหน่งของสำเนา ตารางต่อไปนี้เป็นตัวอย่างการจัดกลุ่มเพื่อประกอบความเข้าใจ องค์กรต้องกำหนดค่าจริงจากการวิเคราะห์ผลกระทบทางธุรกิจของตนเอง

Full, Incremental และ Differential Backup

องค์กรส่วนใหญ่ผสมกัน เช่น ทำ Full สัปดาห์ละครั้งและ Incremental ทุกวัน ยิ่งสายโซ่ของ Incremental ยาว ความเสี่ยงที่ชุดใดชุดหนึ่งเสียแล้วกู้ไม่ได้ทั้งสายก็ยิ่งสูง จึงต้องตรวจความสมบูรณ์ของสำเนาเป็นประจำ

ขั้นตอนวางแผนสำรองข้อมูลสำหรับองค์กร

ขั้นตอนที่ 1: จัดทำทะเบียนข้อมูลและระบบ

ระบุว่ามีข้อมูลอะไร อยู่ที่ไหน และใครเป็นเจ้าของ รวมถึงข้อมูลบนบริการ SaaS เช่น อีเมลและไฟล์บนคลาวด์ ฐานข้อมูล เครื่องของผู้บริหาร และการตั้งค่าของอุปกรณ์เครือข่าย ข้อมูลที่ไม่อยู่ในทะเบียนคือข้อมูลที่จะไม่ถูกสำรอง

ขั้นตอนที่ 2: กำหนด RPO และ RTO ร่วมกับเจ้าของงาน

ให้ฝ่ายธุรกิจเป็นผู้ตอบว่าระบบหยุดได้นานเท่าใดและเสียข้อมูลได้เท่าใด ฝ่ายไอทีเป็นผู้แปลงคำตอบนั้นเป็นวิธีการและต้นทุน

ขั้นตอนที่ 3: ออกแบบตามกฎ 3-2-1 และเพิ่มสำเนาที่ออฟไลน์หรือแก้ไขไม่ได้

เลือกตำแหน่งของสำเนาแต่ละชุดให้ต่างทั้งสื่อและสถานที่ และกำหนดว่าชุดใดเป็นชุดที่ตัดขาดจากเครือข่ายหรือล็อกไม่ให้แก้ไข

ขั้นตอนที่ 4: แยกสิทธิ์ของระบบสำรองออกจากระบบใช้งาน

บัญชีที่ดูแลระบบสำรองไม่ควรเป็นบัญชีผู้ดูแลโดเมนเดียวกับระบบหลัก เปิดใช้การยืนยันตัวตนหลายปัจจัย และจำกัดผู้ที่ลบสำเนาสำรองหรือเปลี่ยนระยะเวลาเก็บรักษาได้

ขั้นตอนที่ 5: เข้ารหัสสำเนาและดูแลกุญแจ

เข้ารหัสทั้งระหว่างส่งและขณะจัดเก็บ และเก็บกุญแจถอดรหัสแยกจากสำเนา หากกุญแจหายหรือถูกเข้ารหัสไปพร้อมกับระบบหลัก สำเนาที่สมบูรณ์ก็กู้ไม่ได้

ขั้นตอนที่ 6: ทดสอบกู้คืนและบันทึกผล

ทดสอบทั้งการกู้ไฟล์เดี่ยวและการกู้ทั้งระบบ จับเวลาเทียบกับ RTO ที่กำหนด และปรับแผนเมื่อผลจริงไม่ถึงเป้า สำเนาสำรองที่ไม่เคยทดสอบกู้คืนยังนับเป็นสำเนาสำรองไม่ได้

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

• เข้าใจว่าการซิงก์คือการสำรอง ไฟล์ที่ถูกลบหรือถูกเข้ารหัสจะถูกซิงก์ไปด้วย
• สำเนาทุกชุดออนไลน์ตลอดเวลา และใช้บัญชีผู้ดูแลชุดเดียวกับระบบหลัก
• ไม่เคยทดสอบกู้คืน จึงมารู้ว่าสำเนาใช้ไม่ได้ในวันที่ต้องใช้
• สำรองเฉพาะข้อมูล ไม่สำรองการตั้งค่า ทำให้กู้ข้อมูลได้แต่สร้างระบบกลับมาไม่ทัน
• เก็บย้อนหลังสั้นเกินไป ผู้โจมตีมักแฝงตัวอยู่ในระบบระยะหนึ่งก่อนลงมือ หากเก็บสำเนาไว้เพียงไม่กี่วัน สำเนาทุกชุดอาจมีมัลแวร์อยู่แล้ว
• คิดว่าข้อมูลบนคลาวด์ปลอดภัยโดยอัตโนมัติ การกระจายข้อมูลหลายโซนในภูมิภาคเดียวไม่ใช่การสำรองข้ามภูมิภาค ดังที่เห็นจากกรณี AWS แจ้งว่ากู้ข้อมูลใน Region บาห์เรนไม่ได้

ผลต่อองค์กรไทย

พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 กำหนดให้ผู้ควบคุมข้อมูลส่วนบุคคลจัดให้มีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม เพื่อป้องกันการสูญหาย การเข้าถึง หรือการเปลี่ยนแปลงข้อมูลโดยมิชอบ การสำรองข้อมูลที่กู้คืนได้จริงจึงเป็นส่วนหนึ่งของการปฏิบัติตามกฎหมาย ไม่ใช่เพียงเรื่องทางเทคนิค และสำเนาสำรองที่มีข้อมูลส่วนบุคคลต้องได้รับการคุ้มครองระดับเดียวกับข้อมูลต้นฉบับ

สิ่งที่องค์กรควรทำในไตรมาสนี้

1. ตรวจว่าระบบสำคัญแต่ละระบบมีสำเนาครบตามกฎ 3-2-1 หรือไม่ และมีชุดใดที่ออฟไลน์หรือแก้ไขไม่ได้
2. ทดสอบกู้คืนระบบสำคัญอย่างน้อยหนึ่งระบบแบบเต็มรูปแบบ แล้วเทียบเวลาที่ใช้กับ RTO
3. ตรวจสิทธิ์ของบัญชีที่ลบสำเนาสำรองได้ และแยกออกจากบัญชีผู้ดูแลระบบหลัก
4. รวมข้อมูลบนบริการ SaaS และการตั้งค่าของระบบเข้าไว้ในแผนสำรอง
5. สำหรับงานบนคลาวด์ ให้มีสำเนาอยู่นอกภูมิภาคหรือนอกผู้ให้บริการหลัก ตามระดับความสำคัญของข้อมูล