กลยุทธ์ Backup 3-2-1-1-0 และ Immutable Backup

Backup (การสำรองข้อมูล คือการทำสำเนาข้อมูลไว้อีกที่ เพื่อกู้คืนเมื่อข้อมูลจริงเสียหาย) ต้องรอดจากแรนซัมแวร์ (ransomware คือโปรแกรมเรียกค่าไถ่ที่เข้ารหัสข้อมูลจนใช้ไม่ได้) ด้วย กฎ 3-2-1-1-0 เป็นหลักจำง่ายว่าควรเก็บสำเนากี่ชุด เก็บที่ไหน และตรวจอย่างไร ส่วน immutable backup (สำเนาที่ล็อกไว้ ห้ามแก้ไขหรือลบจนกว่าจะครบเวลาที่ตั้ง) ช่วยให้สำเนาอย่างน้อยหนึ่งชุดรอดแม้ผู้โจมตีเข้ามาในระบบแล้ว บทความนี้อธิบายทีละขั้นว่าจะวางระบบ backup ตามกฎ 3-2-1-1-0 และเพิ่ม immutable backup อย่างไร และแยกให้เห็นว่าส่วนไหนเป็นข้อแนะนำของ NIST และ CISA ส่วนไหนเป็นธรรมเนียมของวงการ

ทำไม backup ธรรมดาจึงไม่พอเมื่อเจอแรนซัมแวร์

CISA (หน่วยงานด้านความมั่นคงปลอดภัยไซเบอร์ของสหรัฐฯ) ระบุว่าแรนซัมแวร์หลายตัวพยายามหา backup ที่เข้าถึงได้เพื่อลบหรือเข้ารหัส ทำให้กู้คืนเองไม่ได้ เหลือทางเดียวคือจ่ายค่าไถ่ ส่วน NCSC (ศูนย์ความมั่นคงปลอดภัยไซเบอร์ของสหราชอาณาจักร) เขียนไว้ในบล็อกปี 2019 ว่าเคยพบเหตุที่แรนซัมแวร์เข้ารหัสไม่เพียงข้อมูลจริง แต่รวมถึงไดรฟ์ USB และไดรฟ์เครือข่ายที่เก็บ backup และพื้นที่เก็บข้อมูลบน cloud ที่ต่ออยู่ด้วย

NIST (สถาบันมาตรฐานและเทคโนโลยีของสหรัฐฯ) ออกเอกสาร SP 800-209 ว่าด้วยความมั่นคงปลอดภัยของระบบจัดเก็บข้อมูล ซึ่งอธิบายผลที่ตามมา ถ้าผู้โจมตีทำลายข้อมูลสำรองได้ด้วย การโจมตีระบบหลักจะร้ายแรงมาก เพราะองค์กรไม่เหลือทางกู้คืน เอกสารจึงแยกการกู้คืนออกเป็น 2 แบบ แบบแรกคือกู้คืนจากเหตุที่ไม่ได้เกิดจากผู้โจมตี เช่น ฮาร์ดแวร์เสีย หรือเผลอลบ แบบที่สองคือกู้คืนหลังถูกโจมตี ซึ่งต้องใช้สำเนาที่ถูกล็อกและแยกไว้ต่างหาก เพื่อไม่ให้ได้รับผลกระทบ แม้ระบบจริงถูกผู้โจมตีควบคุมไปแล้ว

กฎ 3-2-1 (อธิบายในหัวข้อถัดไป) เป็นข้อแรกใน วิธีป้องกันแรนซัมแวร์: 5 ขั้นตอนที่องค์กรทำได้ทันที บทความนี้ขยายข้อนั้นให้ลึกขึ้น

กฎ 3-2-1-1-0: ตัวเลขแต่ละตัวหมายถึงอะไร

กฎนี้มี 5 ตัวเลข ตามคำอธิบายของผู้ผลิตซอฟต์แวร์ backup และสื่อด้านไอทีที่ใช้กันทั่วไป:

• 3 สำเนา: เก็บข้อมูลอย่างน้อย 3 ชุด ตามนิยามของ Veeam (บริษัทซอฟต์แวร์ backup) ซึ่งนับรวมข้อมูลจริง คือข้อมูลจริง 1 ชุดและ backup อีกอย่างน้อย 2 ชุด
• 2 ประเภทสื่อเก็บข้อมูล: เก็บบนที่เก็บข้อมูลต่างชนิดกัน เช่น ดิสก์ในองค์กรกับ cloud หรือเทป เพื่อให้ปัญหาของสื่อชนิดเดียวไม่ทำให้เสียทุกชุด
• 1 ชุดนอกสถานที่ (off-site): อยู่ห่างจากที่ตั้งของระบบจริง เพื่อรอดเมื่อสถานที่นั้นเกิดเหตุ เช่น ไฟไหม้หรือน้ำท่วม
• 1 ชุดที่ผู้โจมตีแก้หรือลบไม่ได้ (เลข 1 ตัวหลัง): เป็นสำเนา offline (ถอดการเชื่อมต่อไว้) air-gapped (แยกขาดจากเครือข่าย) หรือ immutable (ล็อกห้ามแก้ไข) แต่ละแหล่งระบุแบบไม่เหมือนกัน
• 0 ข้อผิดพลาด: ตรวจและทดสอบกู้คืนสม่ำเสมอ จนมั่นใจว่ากู้ได้จริง ไม่ใช่แค่งาน backup รายงานว่าสำเร็จ

คำนิยามยังไม่ตรงกันทุกแหล่ง Veeam นับ 3 สำเนารวมข้อมูลจริง ส่วนบทความของ TechTarget (เว็บไซต์ข่าวไอที มกราคม 2026) นับ 3 สำเนาเป็น backup เพิ่มจากข้อมูลจริง รวมเป็น 4 ชุด Veeam อธิบายเลข 1 ตัวหลังว่าเป็นสำเนา immutable หรือ air-gapped ส่วน TechTarget อธิบายว่าเป็นสำเนา offline ดังนั้นถ้าจะเขียนกฎนี้เป็นข้อกำหนดภายในองค์กร ให้ระบุชัดว่านับ 3 สำเนารวมข้อมูลจริงหรือไม่ และเลข 1 ตัวหลังหมายถึงแบบใด

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

สถานะของกฎนี้ควรบอกให้ตรง กฎ 3-2-1 ไม่ใช่มาตรฐานที่มีผลบังคับ แต่ CISA เรียกว่า "trusted guideline" (แนวทางที่เชื่อถือได้) ในหน้า Back Up Government Data ส่วน 3-2-1-1-0 เป็นธรรมเนียมของวงการ (industry convention) ที่ผู้ผลิตซอฟต์แวร์และสื่อด้านไอทีเผยแพร่ ไม่ใช่มาตรฐาน เราไม่พบชื่อ 3-2-1-1-0 ในเอกสาร CISA และ NIST ที่ตรวจสำหรับบทความนี้ เอกสารเหล่านั้นแนะนำหลักการเดียวกันด้วยคำอื่น เช่น สำเนา offline สำเนาที่ล็อกได้ และการทดสอบกู้คืน จึงควรใช้กฎนี้เป็นเช็กลิสต์ ไม่ควรอ้างว่าเป็นเกณฑ์ที่ใช้ตรวจการปฏิบัติตามมาตรฐาน

Immutable backup ทำงานอย่างไร

NIST SP 800-209 นิยาม immutability ว่าเป็นความสามารถในการล็อกข้อมูลหลังสร้างแล้ว เพื่อไม่ให้ถูกแก้ไขหรือลบ ในทางปฏิบัติ ระบบ object storage (ที่เก็บข้อมูลเป็นก้อนวัตถุ มักใช้บน cloud) หลายระบบมีฟีเจอร์นี้ เช่น S3 Object Lock (ฟีเจอร์ล็อกของบริการเก็บไฟล์ Amazon S3) และ immutable storage ของ Azure Blob Storage (บริการเก็บข้อมูลของ Microsoft) ทั้งสองใช้แนวคิด WORM (write once, read many คือเขียนได้ครั้งเดียว อ่านได้หลายครั้ง) ผู้ดูแลตั้งระยะเวลาเก็บ (retention period) ไว้ ข้อมูลจะแก้ไขหรือลบไม่ได้จนครบเวลานั้น

นอกจากการล็อกด้วยระบบจัดเก็บ ยังมีวิธีอื่นที่ทำให้ผู้โจมตีเอื้อมไม่ถึงสำเนา:

• Offline: ไม่ต่อสำเนากับระบบจริงเมื่อไม่ได้ใช้ เช่น เทปหรือดิสก์ที่ถอดเก็บ NCSC แนะนำให้มีอย่างน้อยหนึ่งสำเนา offline ตลอดเวลา สำหรับ cloud ที่ถอดสายไม่ได้ ให้ตัดการเชื่อมต่อด้วยการตั้งค่า เช่น ไม่เก็บข้อมูลรับรองการเข้าใช้ (credential คือชื่อผู้ใช้และรหัสสำหรับเข้า cloud) ไว้ในเครื่องที่ใช้สำรองข้อมูล ในช่วงที่ไม่ได้ใช้งาน
• Air gap (การแยกขาดจากเครือข่าย): NIST แบ่งเป็น 2 แบบ แบบเข้มงวดคือแยกทางกายภาพและแยกเครือข่ายครบทั้งหมด แบบผ่อนปรนคือปิดพอร์ตข้อมูลไว้ แล้วเปิดช่วงสั้น ๆ เพื่อส่งข้อมูลที่เปลี่ยนไปเข้าสำเนา ตามรอบที่กำหนด ให้เลือกตามมูลค่าของข้อมูลและความสามารถของผู้โจมตี
• แยกบัญชีและระบบจัดการ: บน cloud สาธารณะ NIST แนะนำให้เก็บสำเนาไว้ในบัญชี cloud (account) แยกต่างหาก และจัดการด้วยระบบที่แยกจากระบบจริง โดยเข้าด้วยข้อมูลรับรองการเข้าใช้ปกติของระบบจริงหรือของ backup ทั่วไปไม่ได้
• จำกัดผู้เข้าถึง: สำหรับข้อมูลสำคัญ NIST แนะนำให้เปิดสิทธิ์กับคนเดียวหรือกลุ่มเล็กมาก เช่น CISO (ผู้บริหารด้านความมั่นคงปลอดภัยสารสนเทศ) ด้วยบัญชีแยกจากงานประจำ เพื่อให้ผู้ดูแลระบบไอทีที่ถูกขโมยบัญชีเข้าถึงสำเนากู้คืนไม่ได้

ถ้าใช้ S3 Object Lock มี 2 โหมดที่ต่างกันมาก โหมด compliance ทำให้ผู้ใช้ทุกคนรวมถึง root user (บัญชีเจ้าของบัญชี AWS) ลบหรือเขียนทับไม่ได้ และลดระยะเวลาเก็บลงไม่ได้ ส่วนโหมด governance ผู้ใช้ที่ได้รับสิทธิ์พิเศษยังข้ามการล็อกได้ สิทธิ์พิเศษนั้นจึงต้องปกป้องให้เข้มงวดพอกับตัวสำเนาเอง

ข้อจำกัดที่ต้องรู้ก่อนใช้ immutable backup:

• ล็อกของเสียก็ล็อกเหมือนกัน: immutable กันการแก้ไขหลังเขียนแล้ว แต่ไม่ได้บอกว่าข้อมูลตอนเขียนสะอาดหรือไม่ CISA เตือนให้หามัลแวร์ตัวนำ (dropper) ก่อนกู้จาก backup เพื่อไม่ให้ระบบติดซ้ำ
• ตั้งผิดแล้วแก้ยาก: CISA เตือนให้ใช้ด้วยความระวัง เพราะการตั้งค่าผิดอาจทำให้ค่าใช้จ่ายสูงมาก และ AWS ระบุว่าโหมด compliance ลดเวลาเก็บลงไม่ได้ AWS ระบุว่าใช้โหมด governance ทดสอบการตั้งค่าระยะเวลาเก็บได้
• อาจไม่ตรงกับกฎระเบียบบางข้อ: CISA ระบุว่า immutable storage ไม่ตรงตามเกณฑ์ของกฎระเบียบบางข้อ จึงควรตรวจกับฝ่ายกฎหมายหรือฝ่ายกำกับดูแลก่อนกำหนดระยะเวลาล็อก
• ล็อกทีละเวอร์ชันของไฟล์: S3 Object Lock ต้องเปิด versioning (การเก็บหลายเวอร์ชันของไฟล์) ก่อน ผู้ใช้ยังเขียนเวอร์ชันใหม่ หรือสั่งลบได้ แต่ระบบแค่ใส่เครื่องหมายว่าลบแล้ว (delete marker) ส่วนเวอร์ชันเดิมที่ล็อกไว้ยังอยู่ครบ
• ยังต้องปกป้องบัญชีผู้จัดการ backup: ถ้าบัญชีเดียวกันใช้ทั้งระบบจริงและ backup ผู้โจมตีที่ขโมยบัญชีนั้นอาจปิดงาน backup หรือเปลี่ยนการตั้งค่าได้ ดู PAM คืออะไร และทำไมต้องควบคุมสิทธิ์ผู้ดูแลระบบ

วางระบบทีละขั้น

ลำดับต่อไปนี้เรียบเรียงโดยเราจากแนวทางของ CISA และ NIST ไม่ใช่ขั้นตอนที่เอกสารใดกำหนดไว้ตามลำดับนี้:

• ระบุข้อมูลและระบบที่องค์กรขาดไม่ได้: CISA แนะนำให้เริ่มจากทำบัญชีรายการข้อมูลสำคัญ แล้วจัดลำดับสิ่งที่ต้องปกป้องก่อน
• ตั้งเป้าหมายการกู้คืน: กำหนด RPO (ข้อมูลที่ยอมให้หายได้ย้อนหลังกี่ชั่วโมง) และ RTO (เป้าหมายว่าต้องกู้ระบบให้กลับมาใช้ได้ภายในกี่ชั่วโมง) ของแต่ละระบบ วิธีตั้งและตัวอย่างคำนวณอยู่ใน แผนกู้คืนหลังโดนแรนซัมแวร์: RTO, RPO และการซ้อม
• ทำ 3-2-1 ให้ครบก่อน: มีข้อมูลจริงและ backup รวมอย่างน้อย 3 ชุด เก็บบนสื่ออย่างน้อย 2 ชนิด และมี 1 ชุดอยู่นอกสถานที่ ตั้งให้ทำงานอัตโนมัติและสม่ำเสมอ ตามที่ CISA แนะนำ
• เพิ่มสำเนาที่ผู้โจมตีลบไม่ได้: เลือก immutable, offline หรือ air gap อย่างน้อยหนึ่งแบบ ตามงบและความสำคัญของข้อมูล
• แยกสิทธิ์และเปิด MFA: บัญชีที่จัดการ backup ใช้ MFA (การยืนยันตัวตนหลายขั้นตอน) และแยกจากบัญชีใช้งานประจำวัน
• สำรองให้ครบทั้งระบบ ไม่ใช่แค่ไฟล์ข้อมูล: NIST แนะนำให้รวมใบรับรองดิจิทัล กุญแจเข้ารหัส และไฟล์ตั้งค่า รวมถึง Active Directory (ระบบจัดการบัญชีผู้ใช้ขององค์กร) และ DNS (ระบบที่เชื่อมชื่อโดเมนกับเครื่อง) เพราะต้องใช้กู้ระบบให้ครบ CISA แนะนำให้เก็บ golden image (ต้นแบบระบบที่ตั้งค่าไว้พร้อมติดตั้งใหม่) ของระบบสำคัญ
• เฝ้าระวังการแก้ไขหรือลบ backup: ตั้งการแจ้งเตือนเมื่อมีการลบ backup หรือปิดงาน CISA แนะนำให้ตรวจการใช้เครื่องมือของ Windows ที่ผู้โจมตีใช้ทำลายสำเนาย้อนหลังที่ Windows เก็บไว้เอง (shadow copy) เช่น vssadmin.exe และ wbadmin.exe

ทดสอบกู้คืนเพื่อให้ได้เลข 0

เลข 0 หมายถึง backup ที่กู้คืนได้จริง ไม่ใช่แค่ผ่านขั้นตอนสำรอง NIST SP 800-209 ระบุว่าหลายองค์กรมี backup แต่ไม่ได้ตรวจเป็นประจำว่ากู้ระบบได้จริงหรือไม่ จนเกิดเหตุจึงพบว่าใช้ไม่ได้ NIST แนะนำให้ทดสอบกู้คืนเป็นระยะ โดยกู้ไปยังพื้นที่แยกต่างหากแทนที่จะกู้ทับระบบจริง และสแกนสำเนาที่กู้ด้วยเครื่องมือตรวจมัลแวร์ นอกจากนี้ให้ตรวจว่าสำเนายังอยู่ในสภาพดี อย่างน้อยปีละครั้ง ระบบสำคัญควรตรวจถี่กว่านั้น CISA แนะนำให้ทดสอบทั้งกู้คืนเต็มระบบและกู้บางส่วน และให้ทดสอบว่ากู้ข้อมูลย้อนหลังอย่างน้อย 7 วันได้จริง

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

• ถือว่ากฎ 3-2-1 พอสำหรับแรนซัมแวร์: NCSC ชี้ว่ากฎนี้ไม่ได้กำหนดให้มีสำเนา offline สำเนาทั้ง 3 ชุดจึงอาจต่ออยู่กับเครือข่ายเดียวกันและถูกเข้ารหัสหมด
• เก็บสำเนา "นอกสถานที่" ไว้ใน cloud บัญชีเดียวกับระบบจริง: ถ้าผู้โจมตีเข้าควบคุมบัญชี cloud นั้นได้ ทุกสำเนาในบัญชีก็ถูกควบคุมไปด้วย NIST แนะนำให้แยกบัญชี และ CISA แนะนำให้พิจารณาใช้ cloud หลายราย เพื่อไม่ผูกกับผู้ให้บริการ cloud รายเดียว
• ให้ผู้ดูแลคนเดียวถือสิทธิ์ทั้งระบบจริงและ backup: บัญชีนั้นถูกขโมยครั้งเดียว ผู้โจมตีก็ได้ทั้งสองอย่าง
• ตั้งระยะล็อกนานโดยไม่ทดลองก่อน: ตั้งผิดแล้วลดลงไม่ได้ในโหมด compliance และเสียค่าเก็บข้อมูลไปตลอดช่วงล็อก
• ถือว่าเสร็จเมื่องาน backup ขึ้นสถานะสำเร็จ: ไม่เคยลองกู้จริง จึงไม่รู้ว่ากู้ได้หรือไม่
• ลืมสำรองสิ่งที่ใช้กู้ระบบ: เช่น กุญแจเข้ารหัส Active Directory DNS และไลเซนส์ซอฟต์แวร์ ซึ่ง NIST และ CISA ระบุว่าควรเก็บไว้ด้วย
• ฝากผู้ให้บริการดูแล backup โดยไม่กำหนดข้อตกลง: CISA แนะนำให้ระบุข้อกำหนดด้านความมั่นคงปลอดภัยไว้ในสัญญากับผู้ให้บริการดูแลระบบไอที (MSP) ที่ดูแล backup

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

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

หากต้องการทราบว่า backup และการกู้คืนขององค์กรอยู่ในระดับใด ลองใช้ แบบประเมินตนเอง

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

• CISA #StopRansomware Guide: คำแนะนำเรื่อง backup offline การทดสอบกู้คืน immutable storage และการจัดการ backup ที่ผู้ให้บริการดูแล
• CISA Back Up Government Data: กฎ 3-2-1 ในฐานะแนวทางที่เชื่อถือได้ และการทดสอบย้อนข้อมูล 7 วัน
• NIST SP 800-209: Security Guidelines for Storage Infrastructure: ข้อแนะนำเรื่องการแยกสำเนากู้คืน immutability air gap และการตรวจให้กู้ได้จริง
• NIST SP 1800-11: Data Integrity: Recovering from Ransomware and Other Destructive Events: แนวปฏิบัติและตัวอย่างระบบเพื่อกู้คืนข้อมูล
• NCSC: Offline backups in an online world: เหตุผลของกฎ offline และวิธีทำให้ cloud backup แยกจากระบบจริง
• AWS: Locking objects with Object Lock: โหมด compliance และ governance ของ S3 Object Lock
• Microsoft: Immutable storage for Azure Blob Storage: นโยบายล็อกตามเวลาและ legal hold
• Veeam: 3-2-1 Backup Rule: คำนิยามของผู้ผลิตซอฟต์แวร์ backup ที่ใช้คำว่า 3-2-1-1-0
• TechTarget: Use the 3-2-1-1-0 rule for better backups: คำอธิบายจากสื่อด้านไอที ซึ่งนับสำเนาต่างจาก Veeam