Backup กัน Ransomware: Immutable หรือ Offline?

Backup ที่กัน ransomware ได้จริงคือ backup ที่ผู้โจมตีซึ่งยึดบัญชีผู้ดูแลระบบได้แล้วก็ยังลบ แก้ไข หรือเข้ารหัสไม่ได้ และองค์กรเคยกู้คืนจากชุดนั้นจนระบบกลับมาใช้งานได้แล้ว Immutable กับ offline ใช้คู่กัน ไม่ต้องเลือกอย่างใดอย่างหนึ่ง immutable ล็อกข้อมูลไม่ให้ถูกลบหรือแก้ตลอดช่วง retention ส่วน offline และ air gap ตัดเส้นทางที่ผู้โจมตีจะเข้าถึงสำเนานั้น ระบบสำคัญควรมีอย่างน้อยหนึ่งสำเนาที่อยู่นอกบัญชีและเครือข่ายที่ใช้ทำงานประจำ

Backup ช่วยให้กู้ระบบได้โดยไม่ต้องจ่ายค่าไถ่ แต่ไม่ได้กันการขโมยข้อมูลไปขู่เปิดเผย ซึ่ง #StopRansomware Guide ของ CISA เรียกการใช้ทั้งสองวิธีร่วมกันว่า double extortion และระบุว่าบางกรณีผู้โจมตีขู่ด้วยข้อมูลที่ขโมยไปอย่างเดียวโดยไม่ใช้ ransomware เลย การป้องกันส่วนนั้นอยู่ในบทความเรื่อง ransomware

บทความนี้ขยายหัวข้อ backup จาก Ransomware คืออะไร? ป้องกันและรับมืออย่างไร ซึ่งอธิบายภาพรวมของการป้องกัน แผนรับมือ และการแจ้งเหตุไว้แล้ว ที่นี่ลงรายละเอียดเฉพาะเรื่อง backup ได้แก่ เหตุที่ผู้โจมตีเล็ง backup, ความต่างระหว่าง offline, air gap และ immutable, สิ่งที่กลไก immutable แต่ละแบบกันได้และกันไม่ได้, การแยกสิทธิ์, การเก็บกุญแจเข้ารหัส, การเฝ้าระวัง และการทดสอบ restore เขียนสำหรับทีม IT ผู้ดูแลระบบ และผู้บริหารที่ต้องตัดสินใจเรื่องระยะเก็บและงบประมาณ ชื่อผลิตภัณฑ์ในบทความเป็นตัวอย่างที่อ้างจากเอกสารของผู้ผลิตเอง ไม่ใช่คำแนะนำให้เลือกยี่ห้อใด แหล่งอ้างอิงทั้งหมดตรวจ ณ วันที่ 8 พฤศจิกายน 2026 (พ.ศ. 2569)

ทำไมผู้โจมตีถึงลบหรือเข้ารหัส backup ก่อน?

เพราะถ้า backup ยังอยู่ องค์กรก็กู้คืนได้โดยไม่ต้องจ่ายค่าไถ่ #StopRansomware Guide ของ CISA (ฉบับ PDF ระบุวันเผยแพร่ October 2023) อธิบายว่าต้องเก็บ backup แบบ offline เพราะผู้โจมตีส่วนใหญ่พยายามค้นหาแล้วลบหรือเข้ารหัส backup ที่เข้าถึงได้ เพื่อให้กู้คืนไม่ได้นอกจากจ่ายค่าไถ่ คู่มือฉบับเดียวกันระบุว่าผู้โจมตีมักค้นหาและเก็บ credential ที่เก็บไว้ในระบบเป้าหมาย แล้วใช้ credential นั้นพยายามเข้าระบบ backup และยังใช้ exploit ที่เผยแพร่สาธารณะโจมตีระบบ backup ที่ไม่ได้ patch

ในฐานข้อมูล MITRE ATT&CK การทำลายกลไกกู้คืนคือเทคนิค T1490 Inhibit System Recovery การลบ shadow copy ด้วย vssadmin หรือ wbadmin บน Windows และวิธีตั้ง alert อธิบายไว้แล้วในบทความเรื่อง ransomware แต่ T1490 กว้างกว่านั้น MITRE บันทึกว่าผู้โจมตี:

• ลบหรือเข้ารหัส snapshot ของ VM บน ESXi เช่นด้วยคำสั่ง vim-cmd vmsvc/snapshot.removeall
• ลบ backup แบบ "online" ที่เชื่อมกับเครือข่าย ทั้งที่อยู่บน network storage และในโฟลเดอร์ที่ sync ขึ้นบริการคลาวด์
• บนคลาวด์ ปิด versioning และ backup policy แล้วลบ snapshot, backup ของฐานข้อมูล, machine image และ object version เก่าที่เตรียมไว้กู้คืน
• ปิดการแจ้งเตือนเรื่องการกู้คืนก่อน แล้วจึงทำให้ backup เสียหาย

ทั้งหมดนี้ไม่ต้องใช้ช่องโหว่พิเศษ ถ้าผู้โจมตีถือบัญชีที่มีสิทธิ์อยู่แล้ว เทคนิค T1078 Valid Accounts อธิบายว่า credential ที่ถูกขโมยใช้ข้ามการควบคุมการเข้าถึงทรัพยากรในเครือข่ายได้ เป้าหมาย 3.O ใน Cross-Sector Cybersecurity Performance Goals 2.0 ของ CISA ก็เขียนความเสี่ยงไว้ตรง ๆ ว่าผู้โจมตีลบข้อมูลและปิดบริการกู้คืนได้ จนกู้ระบบไม่ได้

ตัวระบบ backup เองก็เป็นเป้าหมาย Known Exploited Vulnerabilities Catalog ของ CISA (ฉบับ 2026.11.06) มีช่องโหว่ของซอฟต์แวร์ backup จากผู้ผลิตหลายรายที่ถูกใช้โจมตีจริง และหลายรายการระบุว่าเคยถูกใช้ในแคมเปญ ransomware backup server จึงต้องได้รับ patch และแยกโซนเครือข่ายเหมือนระบบสำคัญอื่น

Offline, air gap และ immutable backup ต่างกันอย่างไร?

สามคำนี้ตอบคนละคำถาม offline หมายถึงสำเนาที่ไม่ได้ต่ออยู่กับระบบที่ใช้งาน air gap หมายถึงไม่มีการเชื่อมต่อทั้งทางกายภาพและการเชื่อมต่ออัตโนมัติ ส่วน immutable backup คือ backup ที่ถูกล็อกจนแก้หรือลบไม่ได้ตลอดช่วง retention แม้ยังเชื่อมต่ออยู่

NIST SP 800-209 (Security Guidelines for Storage Infrastructure, 2020) ยังให้หลักที่ใช้ได้กับทุกแบบ คือสร้างสำเนาสำหรับกู้คืนบน storage ที่แยกไว้โดยเฉพาะ ใน private cloud หมายถึงระบบ storage ที่แยกทางกายภาพ ใน public cloud หมายถึงแยกบัญชี (IS-SS-R1) เก็บสำเนาไว้นอกสถานที่ที่เก็บข้อมูล production (IS-SS-R4) และพิจารณาใช้ immutable storage เช่น retention locking หรือ immutability policy (IS-SS-R10) ในมุมมองของเรา ระบบสำคัญควรมีทั้งสองชั้น คือสำเนาที่ล็อกแบบ immutable สำหรับกู้คืนเร็ว และสำเนาที่แยกบัญชีหรือ offline ไว้สำหรับกรณีที่ระบบจัดการ backup ถูกยึดทั้งระบบ

หลัก 3-2-1 ยังใช้ได้ไหม?

ยังเป็นจุดเริ่มที่ดี ความหมายของหลัก 3-2-1 อธิบายไว้แล้วในบทความเรื่องระบบเก่า เอกสาร Data Backup Options (2012) ที่จัดทำให้ US-CERT อ้างที่มาของหลักนี้ไปยังหนังสือ The DAM Book ของ Peter Krogh (2009) แต่ 3-2-1 ไม่ได้บอกว่าสำเนานอกสถานที่ต้องลบไม่ได้ด้วยบัญชีเดียวกับ production ผู้ผลิตบางรายจึงขยายหลักนี้เอง เช่น Veeam ใช้คำว่า 3-2-1-1-0 ซึ่งเพิ่มสำเนาที่ immutable, offline หรือ air-gapped หนึ่งชุด และ "0" หมายถึงไม่มีข้อผิดพลาดจากการตรวจกู้คืน แนวคิดนี้ตรงกับที่ CISA และ NIST แนะนำ และทำได้โดยไม่ต้องใช้ผลิตภัณฑ์ของผู้ผลิตรายใด

Immutable backup ทำได้กี่แบบ และแต่ละแบบไม่ได้กันอะไร?

กลไกที่มีเอกสารต้นทางอธิบายชัดแบ่งได้สี่กลุ่ม คือ object storage แบบ WORM, repository แบบ append-only, snapshot ของ filesystem และ backup server ที่มีการป้องกัน snapshot แต่ละแบบกันคนละระดับ จุดที่ต้องถามทุกครั้งคือ ใครยังปลดล็อกหรือลบได้

S3 Object Lock และ WORM กันอะไรได้และไม่ได้?

S3 Object Lock ใช้โมเดล write-once-read-many (WORM) ป้องกันไม่ให้ object ถูกลบหรือเขียนทับตามระยะเวลาที่กำหนด หรือไม่มีกำหนด ต้องเปิด S3 Versioning ก่อน เปิดได้ทั้งบน bucket ใหม่และ bucket เดิม แต่เปิดแล้วปิดไม่ได้ และ suspend versioning ไม่ได้ ตั้ง retention เริ่มต้นระดับ bucket เป็นจำนวนวันหรือปีได้ และมีการควบคุมสองแบบ คือ retention period และ legal hold

• Governance mode: ผู้ที่มีสิทธิ์ s3:BypassGovernanceRetention และส่ง header x-amz-bypass-governance-retention:true แก้หรือลบ retention ได้ และ AWS ระบุว่า S3 console ส่ง header นี้โดยค่าเริ่มต้น บัญชีที่ถูกยึดซึ่งมีสิทธิ์นี้จึงลบ backup ได้ AWS แนะนำให้ใช้ governance mode ทดสอบการตั้ง retention ก่อนเปลี่ยนเป็น compliance mode
• Compliance mode: ไม่มีผู้ใช้คนใดเขียนทับหรือลบ version ที่ล็อกได้ รวมถึง root user ของบัญชี AWS เปลี่ยนโหมดไม่ได้ ลด retention ไม่ได้ ขยายได้อย่างเดียว และ AWS ระบุว่าทางเดียวที่จะลบก่อนหมดอายุคือลบบัญชี AWS ถ้าตั้งยาวเกินไปก็ต้องเก็บและจ่ายค่าเก็บจนหมดอายุ
• Legal hold: ไม่มีวันหมดอายุ อยู่จนกว่าจะถูกถอด แต่ผู้ที่มีสิทธิ์ s3:PutObjectLegalHold ใส่และถอดได้อย่างอิสระ
• สิ่งที่ Object Lock ไม่ได้กัน: ล็อกปกป้อง version ไม่ได้กันการสร้าง version ใหม่หรือ delete marker คำสั่ง DELETE ธรรมดาจึงสำเร็จแต่เพียงใส่ delete marker ทับ object โดย version เดิมยังอยู่ ส่วนการลบถาวรแบบระบุ version จะได้ 403 Access Denied ระบบกู้คืนต้องรู้วิธีอ่าน version เดิม

AWS ยังยกตัวอย่างการใช้ variable retention (เปิด event hold ไว้ แล้ว S3 กำหนดวันหมดอายุเมื่อปลด hold บวกระยะที่ตั้งไว้) เพื่อสร้าง "recovery window" ที่ตั้งค่าได้สำหรับกรณี ransomware หรือการลบโดยไม่ตั้งใจ

Object storage ที่รองรับ S3 API และติดตั้งในองค์กรเองก็มีกลไกคล้ายกัน เอกสาร MinIO AIStor อธิบาย object locking แบบ WORM ที่มีทั้ง GOVERNANCE ซึ่ง bypass ได้ด้วยสิทธิ์ s3:BypassGovernanceRetention และ COMPLIANCE ซึ่งไม่มีผู้ใช้คนใดแก้ได้ รวมถึง root user ของ MinIO AIStor และถอดล็อกก่อนครบกำหนดไม่ได้ ต้องเปิด versioning เช่นกัน รุ่นตั้งแต่ RELEASE.2025-05-20T20-30-00Z เปิดล็อกบน bucket เดิมได้ ส่วนรุ่นก่อนหน้าต้องเปิดตอนสร้าง bucket ฝั่งคลาวด์ เช่น Huawei Cloud OBS WORM รองรับเฉพาะ compliance mode เปิดแล้ว versioning จะเปิดอัตโนมัติและปิดไม่ได้ ปิด WORM ไม่ได้ retention ระดับ object ขยายได้แต่ลดไม่ได้ delete marker ไม่ได้รับการป้องกันจาก WORM และเอกสารระบุว่าค่าเก็บข้อมูลจะเพิ่มขึ้น

เราเห็นว่า ถ้า bucket ที่ล็อกแบบ governance อยู่ในบัญชีเดียวกับ production และผู้ดูแลชุดเดียวกันมีสิทธิ์ bypass การล็อกนั้นกันได้เพียงความผิดพลาด ไม่ได้กันผู้โจมตี MITRE แนะนำให้คัดลอก backup ไปยังบัญชีหรือ region อื่น (M1053) และจำกัดบัญชีที่เข้าถึง backup ให้เหลือเท่าที่จำเป็น (M1018) ใน AWS พิจารณาใช้ Service Control Policy จำกัด API ที่ลบ backup, snapshot และ image

Repository แบบ append-only ของ restic และ Borg กันอะไรได้?

เครื่องมือ backup แบบโอเพนซอร์สหลายตัวมีโหมด append-only ที่ให้ client เขียน backup ใหม่ได้แต่ลบไม่ได้ rest-server ของ restic เมื่อรันด้วย --append-only จะสร้าง backup ใหม่ได้แต่ลบหรือแก้ backup เดิมไม่ได้ เพื่อกันไม่ให้ผู้โจมตีที่ยึด server ต้นทางได้ลบ backup ทิ้ง เอกสาร restic ระบุข้อจำกัดไว้ชัด คำสั่ง forget และ prune ต้องมีสิทธิ์อ่าน เขียน และลบเต็ม ถ้าผู้โจมตีมีสิทธิ์นี้ การป้องกันของ append-only ก็หมดไป จึงให้ทำงานที่ต้องใช้สิทธิ์เต็มจาก client แยกที่รักษาความปลอดภัยอย่างดี และให้ใช้ --keep-within กับ repository แบบ append-only เพราะผู้โจมตีอาจเพิ่ม snapshot ขยะเข้ามา

Borg (เอกสาร Borg 1.4) มีโหมด append-only ที่ทำให้ client ที่ถูกเจาะลบ backup บน server แบบถาวรไม่ได้ คำสั่ง prune หรือ delete จะแค่ทำเครื่องหมายว่าลบใน transaction ใหม่ ไม่คืนพื้นที่ และย้อนกลับไปยัง transaction ที่ดีได้ถ้ายังไม่ได้รัน borg compact ข้อจำกัดตามเอกสารคือ เครื่องมืออื่นนอกจาก Borg ไม่เคารพโหมดนี้ คำสั่ง rm บน server ยังลบ repository ได้ งาน prune อัตโนมัติที่รันในโหมดปกติทำให้ append-only ไม่มีความหมาย และควรรัน borg check --verify-data ก่อน compact ทุกครั้ง

สรุปคือ append-only กัน client ที่ถูกเจาะ แต่ไม่กันผู้ที่ได้สิทธิ์ root บนเครื่องที่เก็บ repository เครื่องนั้นจึงต้องใช้บัญชีและเส้นทางเข้าถึงที่แยกจาก production

Snapshot ของ ZFS นับเป็น immutable backup ได้ไหม?

ใน OpenZFS snapshot คือสำเนาแบบอ่านอย่างเดียวของ filesystem หรือ volume คำสั่ง zfs hold ใส่ reference ให้ snapshot ทำให้ zfs destroy คืนค่า EBUSY จนกว่าจะถอดด้วย zfs release ส่วน zfs allow มอบสิทธิ์รายคำสั่งให้ผู้ใช้ที่ไม่ใช่ root ได้ บัญชีที่ใช้ทำ backup จึงสร้าง snapshot ใส่ hold และส่งออกด้วย send ได้ (มอบสิทธิ์ snapshot, mount, hold และ send โดยเอกสารระบุว่าสิทธิ์ snapshot ต้องมี mount ด้วย) โดยไม่มีสิทธิ์ destroy หรือ release (เอกสารระบุว่าการ release อาจทำให้ snapshot ถูกลบ)

ข้อจำกัดคือ root บนเครื่อง storage หรือผู้ที่มีสิทธิ์ release ถอด hold แล้วลบได้ และ SP 800-209 (IS-SS-R5) ชี้ว่า snapshot ใช้ข้อมูล production เป็น baseline ขณะที่สำเนาสำหรับกู้คืนจากการโจมตีไม่ควรพึ่งข้อมูล production snapshot บนเครื่องเดียวกันจึงช่วยกู้คืนเร็ว แต่ต้องส่งออกไปเก็บอีกเครื่องที่ใช้บัญชีแยกด้วย

Proxmox Backup Server กันไม่ให้ snapshot ถูกลบได้แค่ไหน?

Proxmox Backup Server ให้ทำเครื่องหมาย snapshot เป็น protected ด้วย proxmox-backup-client snapshot protected update ซึ่งป้องกันการ prune และการลบด้วยมือจนกว่าจะถอด flag แต่ผู้ที่มีสิทธิ์ก็ถอด flag ได้ และเอกสารเรื่อง remote ระบุว่า flag นี้ไม่ถูก sync ไปกับ sync job เราไม่พบ datastore แบบ WORM ในตัวในเอกสารของ Proxmox Backup Server สิ่งที่มีคือ sync job ไปยังหรือจาก PBS อีกเครื่อง ทั้งแบบ pull และ push โดยเอกสารระบุว่า sync job แบบ pull จะดึงได้เฉพาะ backup group ที่บัญชีหรือ API token ฝั่ง remote อ่านได้ และสำหรับแบบ push แนะนำให้ใช้บัญชีที่มีสิทธิ์จำกัดฝั่ง remote นอกจากนี้มีตัวเลือก remove-vanished ที่ลบสำเนาในเครื่องเมื่อ snapshot ฝั่ง remote หายไป ถ้าต้องการสำเนาที่ยังอยู่แม้ต้นทางถูกลบ อย่าเปิด remove-vanished ใน sync job ของสำเนานั้น

ผลิตภัณฑ์เชิงพาณิชย์มีกลไกที่คล้ายกัน เช่น hardened repository ของ Veeam ที่ตั้ง immutable attribute ให้ไฟล์ backup บนเครื่อง Linux ตามช่วงเวลาที่กำหนด และมีข้อกำหนดของตัวเอง เช่น ต้องใช้ block storage ไม่ใช่ NFS หรือ SMB และผู้ผลิตแนะนำให้ใช้เครื่อง physical ที่มี local storage เพื่อลดช่องทางโจมตี ไม่ว่าเลือกแบบไหน ให้อ่านส่วนข้อจำกัดในเอกสารของผู้ผลิตก่อนตัดสินใจ

แยกสิทธิ์อย่างไรไม่ให้บัญชีเดียวลบ backup ได้ทุกชุด?

แยกทั้งระบบที่ใช้จัดการ backup และบัญชีที่ลบหรือแก้ retention ได้ ออกจากระบบและบัญชีที่ใช้ดูแล production ทุกวัน NIST SP 800-209 วางหลักไว้ดังนี้

• ระบบจัดการแยก (IS-SS-R2): สำเนาสำหรับกู้คืนควรจัดการจากระบบจัดการที่แยกจาก production และเข้าระบบนั้นด้วย credential ปกติไม่ได้ รวมทั้ง credential ของ production และของงาน backup ประจำ
• คนเข้าถึงน้อยและใช้ credential แยก (IS-SS-R3): สำหรับข้อมูลที่อ่อนไหว สำเนาสำหรับกู้คืนจากการโจมตีไม่ควรให้ทีม IT ทั่วไปเข้าถึง ควรจำกัดไว้ที่คนเดียว (เช่น CISO) หรือกลุ่มผู้บริหารหรือผู้ดูแลความปลอดภัยที่เล็กมาก ซึ่งใช้ credential แยกจากงานประจำ เพื่อให้ credential ของผู้ดูแลที่ถูกขโมยเข้าถึงสำเนาเหล่านั้นไม่ได้
• เครื่องที่ถูก backup ไม่ควรแก้การตั้งค่า backup ของตัวเอง (DP-SS-R4): การตั้งค่า backup, point-in-time copy และ replication ควรจัดการจากส่วนกลาง และแยกจากฝั่งที่ใช้ข้อมูล

NIST SP 800-53 Rev. 5 มีมาตรการ CP-9(7) ให้ใช้ dual authorization สำหรับการลบหรือทำลายข้อมูล backup ที่องค์กรกำหนด คือการลบจะเกิดขึ้นไม่ได้ถ้าไม่มีผู้มีคุณสมบัติสองคนร่วมกันทำ หรือที่เรียกว่า two-person control ส่วนแนวทางทั่วไปเรื่องบัญชีจาก CISA ใช้กับระบบ backup ได้ตรง ๆ คือแยกบัญชีผู้ดูแลออกจากบัญชีผู้ใช้ ใช้บัญชีผู้ดูแลที่กำหนดไว้เท่านั้นสำหรับงานผู้ดูแล ไม่เก็บรหัสผ่านไว้ในไฟล์บนเครื่อง ตั้งรหัสผ่านของบัญชีผู้ดูแลและบัญชีบริการให้ไม่ซ้ำกับบัญชีผู้ใช้ทั่วไป (CPG 2.0 เป้าหมาย 3.C) และให้สิทธิ์เท่าที่จำเป็นพร้อมทบทวนเป็นรอบ (3.H) เราแนะนำว่า console ของระบบ backup ควรบังคับ MFA และไม่ควรล็อกอินได้ด้วยบัญชีใน domain เดียวกับ production เพราะถ้า domain ถูกยึด ผู้โจมตีก็ได้ทั้งสองระบบ

ระบบ backup ควรดึงข้อมูล (pull) หรือรับข้อมูล (push)?

ขึ้นกับว่ายอมให้ฝั่งไหนถือ credential ในแบบ push เครื่อง production ถือ credential สำหรับเขียน backup ถ้าเครื่องถูกยึด ผู้โจมตีก็ได้ credential นั้นไปด้วย จึงต้องจำกัดให้เขียนได้อย่างเดียวด้วย append-only หรือ object lock ในแบบ pull ฝั่ง backup เป็นผู้เริ่มการเชื่อมต่อ เช่น pull mode ของ Borg ซึ่งเอกสารเตือนว่า server ที่ล็อกอินเป็น root ทำความเสียหายต่อ client ได้ไม่จำกัด จึงควรใช้เฉพาะกับ server ที่ไว้ใจเต็มที่ หรือ sync job แบบ pull ของ Proxmox Backup Server ซึ่งดึงได้เฉพาะสิ่งที่บัญชีฝั่ง remote อ่านได้ เราไม่พบแนวทางของ CISA หรือ NIST ที่แนะนำ pull มากกว่า push สิ่งที่ NIST กำหนดคือหลัก DP-SS-R4 ข้างต้น ไม่ว่าเลือกแบบไหน เครื่องที่ถือสิทธิ์ลบ backup ต้องเป็นเครื่องที่ป้องกันดีที่สุดในระบบ

เข้ารหัส backup แล้ว กุญแจควรเก็บที่ไหน?

เก็บไว้นอกระบบที่อาจล่มพร้อมกับ production และทดสอบว่าเปิดใช้ได้ตอนกู้คืน CP-9(8) ใน SP 800-53 ให้ใช้กลไกเข้ารหัสเพื่อป้องกันการเปิดเผยและการแก้ไขข้อมูล backup โดยไม่ได้รับอนุญาต และให้พิจารณาการจัดการกุญแจไปด้วย SP 800-209 (DP-SS-R1) ระบุว่าการเข้ารหัส backup ควรแข็งแรงไม่น้อยกว่าการเข้ารหัสข้อมูลต้นทาง และให้คิดเรื่องการเก็บรักษาและการหมุนเวียนกุญแจ

• เก็บกุญแจที่ใช้กู้คืนไว้ offline: คู่มือของ NIST NCCoE เรื่องการปกป้องข้อมูลจาก ransomware ให้ระบุชุด backup และข้อมูลที่ต้องเก็บ offline รวมถึงรหัสผ่าน digital certificate กุญแจเข้ารหัส และข้อมูลอื่นที่จำเป็นต่อการกลับมาทำงาน
• ระบบที่การกู้คืนต้องพึ่ง: SP 800-209 (RA-SS-R2) ระบุว่าองค์ประกอบอย่าง Active Directory, DNS และระบบจัดการกุญแจภายนอกต้องได้รับการป้องกันเพื่อให้กู้คืนได้ครบ ถ้ากุญแจอยู่ใน vault ที่ต้องล็อกอินผ่าน AD ซึ่งล่มไปพร้อมกัน backup ที่สมบูรณ์ก็เปิดไม่ได้
• แยกหน้าที่ตามความเหมาะสม: CISA ระบุว่าในบางสภาพแวดล้อมคลาวด์ บัญชีที่สร้างหรือจัดการกุญแจไม่ควรมีสิทธิ์ใช้กุญแจ และกลับกัน แต่วิธีนี้เพิ่มภาระการจัดการ จึงไม่เหมาะกับทุกสภาพแวดล้อม
• ตัวอย่างจากเอกสารผู้ผลิต: Proxmox Backup Server เข้ารหัสฝั่ง client ด้วย AES-256 แบบ GCM และแนะนำให้เก็บกุญแจแยกจากข้อมูลที่ backup เช่น ใน password manager, USB drive ที่เก็บในที่ปลอดภัย และสำเนา master key บนกระดาษด้วย paperkey

ต้องเฝ้าระวังอะไรในระบบ backup?

เฝ้าระวังทั้ง job ที่ล้มเหลวและการกระทำที่ลดความสามารถในการกู้คืน CISA แนะนำให้เปิด logging กับทุกทรัพยากรบนคลาวด์และตั้ง alert เมื่อมีการใช้งานผิดปกติ SP 800-209 (DP-SS-R3) ให้ติดตามการทำงานของ backup ตามนโยบายพร้อมกลไกแจ้งเตือน และเก็บ audit trail สิ่งที่ควรมี alert อย่างน้อย:

• backup job ที่ล้มเหลว ไม่ได้รัน หรือได้ข้อมูลน้อยผิดปกติ (NCCoE ให้ตรวจทั้งว่าไฟล์ backup ถูกสร้าง และกู้คืนได้และใช้งานได้จริง)
• การเรียก API บนคลาวด์ที่ปิดการตั้งเวลา snapshot, backup policy หรือ versioning แล้วตามด้วยการลบ snapshot หรือ volume ซึ่งเป็นรูปแบบที่ MITRE ใช้เป็นตัวอย่างการตรวจจับ T1490
• การลบ snapshot ของ VM ทั้งหมดบน ESXi ผ่าน shell หรือ vim-cmd
• การลด retention, ถอด legal hold, ถอด protected flag หรือใช้สิทธิ์ bypass governance
• การล็อกอิน console ของระบบ backup จากเครื่องหรือเวลาที่ไม่คาดคิด และการสร้างบัญชีผู้ดูแลใหม่ในระบบ backup
• การปิดการแจ้งเตือนของระบบ backup เพราะ MITRE บันทึกว่าผู้โจมตีอาจปิดการแจ้งเตือนก่อนทำให้ backup เสียหาย

SP 800-209 (AL-SS-R5) ให้ป้องกัน log ที่เก็บไว้จากการแก้ไข เช่น ใช้ WORM, object lock หรือให้การลบต้องอนุมัติด้วย MFA และเก็บ log ไว้นานพอ เพราะการบุกรุกมักถูกพบช้า ในทางปฏิบัติ log และ alert ของระบบ backup จึงควรส่งไปยังที่ที่ผู้ดูแล backup ลบเองไม่ได้ ถ้าใช้ SIEM อย่าง Wazuh อยู่แล้ว ให้รวม log ของ backup server และ audit log ของคลาวด์เข้าไปด้วย แล้วเขียน rule ตามรายการนี้ การวางแผนส่วนนี้อยู่ในบทความวางแผนติดตั้ง Wazuh

ทดสอบ restore อย่างไรให้รู้ว่ากู้ได้จริง?

กู้ทั้งระบบในเครือข่ายแยก จับเวลาทุกขั้น แล้วเทียบกับเป้าหมายที่องค์กรตั้งไว้ NIST SP 800-34 Rev. 1 นิยามเป้าหมายเหล่านี้ไว้ดังนี้

• RTO (Recovery Time Objective): เวลาสูงสุดที่ระบบหยุดได้ก่อนจะกระทบระบบอื่นและกระบวนการทางธุรกิจที่พึ่งพาอย่างรับไม่ได้
• RPO (Recovery Point Objective): จุดเวลาก่อนเกิดเหตุที่กู้ข้อมูลกลับมาได้จาก backup ล่าสุด หรือข้อมูลที่ธุรกิจยอมให้หายได้
• MTD (Maximum Tolerable Downtime): เวลารวมที่เจ้าของระบบยอมรับให้กระบวนการทางธุรกิจหยุดได้

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

ต้องทดสอบอะไรบ้าง?

• ความครบถ้วนของ repository: restic check โดยค่าเริ่มต้นตรวจเพียงโครงสร้าง ไม่ได้ตรวจว่าไฟล์ pack บนดิสก์ไม่ถูกแก้ ต้องเพิ่ม --read-data เพื่ออ่านข้อมูลจริง หรือ --read-data-subset เพื่อตรวจทีละส่วน ฝั่ง Borg ใช้ borg check --verify-data ส่วน Proxmox Backup Server ใช้ verify job และผู้ผลิตแนะนำให้ verify backup ทั้งหมดซ้ำอย่างน้อยเดือนละครั้ง
• กู้ทั้งระบบ ไม่ใช่แค่ไฟล์: SP 800-209 (RA-SS-R1) ระบุสิ่งที่ต้องอยู่ในสำเนาสำหรับกู้คืน เช่น volume, filesystem, ฐานข้อมูล, software image, certificate, กุญแจเข้ารหัส, ไฟล์ startup, catalog, ACL, การตั้งค่า virtualization และไฟล์ configuration
• ฐานข้อมูลต้อง consistent ในระดับแอปพลิเคชัน: SP 800-209 (DP-SS-R2) ให้คำนึงถึงความถูกต้องในระดับแอปพลิเคชันและกระบวนการธุรกิจ ถ้าสององค์ประกอบต้องกู้คืนถึงจุดเวลาเดียวกันจึงจะทำงานได้ ต้องวางกลไกให้ได้จุดเดียวกัน การทดสอบจึงต้องให้แอปพลิเคชันเปิดใช้ข้อมูลที่กู้มาได้จริง
• จับเวลาตั้งแต่ต้นจนจบเทียบกับ RTO: SP 800-209 (RA-SS-R4) ระบุว่าต้องประเมินความสามารถในการทำตาม RTO แบบองค์รวม รวมองค์ประกอบที่เกี่ยวข้องอย่างข้อมูล ไฟล์ configuration และกุญแจเข้ารหัส คู่มือ NCCoE ให้บันทึกเวลาดึงไฟล์จากนอกสถานที่ เวลากู้ไฟล์ลงระบบ เวลาสร้างระบบใหม่ และช่องโหว่ทั้งทางเทคนิคและขั้นตอนที่พบ
• กู้ลงสภาพแวดล้อมแยก: SP 800-209 (IS-SS-R7) ให้กู้สำเนาลงสภาพแวดล้อม staging ที่แยกหรือ air-gapped ไม่ใช่ลงเครื่องเป้าหมายโดยตรง และสำหรับระบบที่ต้องกู้เร็ว ให้ทดสอบแบบ end-to-end ด้วยการกู้ชุดข้อมูลทั้งหมดลง sandbox ที่จำลองสถานการณ์จริง (DP-SS-R3)
• ตรวจก่อนใช้: CPG 2.0 เป้าหมาย 3.O ให้ตรวจความครบถ้วนของ backup ก่อนเริ่มกู้คืน และตรวจหาร่องรอยการบุกรุก ไฟล์เสียหาย และปัญหาความถูกต้องอื่นก่อนใช้ สำหรับข้อมูลที่อ่อนไหว SP 800-209 (DP-SS-R3) แนะนำให้สแกนสำเนาเก่าอย่างน้อยบางส่วนด้วยเครื่องมือ anti-malware รุ่นปัจจุบันเป็นระยะ เพื่อหาสำเนาที่ปนเปื้อน

ซ้อมกู้คืนอย่างไร?

1. เลือกระบบที่จะซ้อม แล้วเขียน RTO และ RPO ที่องค์กรตั้งไว้สำหรับระบบนั้นให้ชัด
2. ทำรายการทุกอย่างที่ต้องใช้ ทั้งข้อมูล configuration ไฟล์ติดตั้ง license กุญแจเข้ารหัส credential และระบบที่ต้องพึ่งอย่าง AD และ DNS
3. เตรียมสภาพแวดล้อม staging ที่แยกเครือข่ายจาก production
4. ดึงสำเนาจากชุดที่ล็อกหรือแยกไว้ ไม่ใช่ชุดที่สะดวกที่สุด และจับเวลาตั้งแต่เริ่มดึง
5. ตรวจความครบถ้วนของ backup และสแกนหาร่องรอยการบุกรุกก่อนกู้
6. กู้ทั้งระบบโดยใช้กุญแจและ credential จากชุดที่เก็บ offline เท่านั้น
7. ให้เจ้าของระบบลองทำงานจริงบนระบบที่กู้มา และเทียบข้อมูลล่าสุดที่ได้กับ RPO
8. บันทึกเวลาแต่ละขั้นเทียบกับ RTO พร้อมสิ่งที่ขาดหรือเอกสารที่ผิด
9. แก้ runbook และแผน backup จากสิ่งที่พบ แล้วลบสภาพแวดล้อม staging

ต้องซ้อมบ่อยแค่ไหน?

เป็นการตัดสินใจขององค์กรตามความสำคัญของระบบ CP-9(1) ใน SP 800-53 ให้ทดสอบข้อมูล backup ตามความถี่ที่องค์กรกำหนด ส่วนแหล่งอื่นให้ขั้นต่ำไว้ดังนี้

• CPG 2.0 เป้าหมาย 3.O: ทดสอบ backup และการกู้คืนเป็นรอบ ไม่น้อยกว่าปีละครั้ง
• SP 800-209 (DP-SS-R3): ทดสอบ backup ของข้อมูลสำคัญอย่างน้อยเดือนละครั้ง
• SP 800-209 (IS-SS-R9): ตรวจว่าสำเนาสำหรับกู้คืนยังแยกอยู่จริงอย่างน้อยปีละครั้ง ระบบ storage ที่อ่อนไหวหรือมีมูลค่าสูงอาจต้องตรวจอย่างน้อยรายไตรมาสและหลังการเปลี่ยนแปลงใหญ่ทุกครั้ง

ใครเป็นผู้ทดสอบและต้องส่งหลักฐานอะไร ควรเขียนไว้ในสัญญา MA

Retention ยาวแค่ไหน และต้องแลกกับอะไร?

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

• ระยะที่ต้องย้อนกลับไปได้: เราแนะนำว่า retention ของสำเนาที่ล็อกไว้ควรยาวพอที่จะย้อนไปถึงจุดก่อนผู้โจมตีเข้ามา ถ้าองค์กรตรวจพบการบุกรุกช้ากว่าระยะ retention ทุกสำเนาที่เหลืออาจมีมัลแวร์หรือบัญชีที่ผู้โจมตีสร้างไว้ติดมาด้วย
• ล็อกแล้วแก้ไม่ได้: compliance mode ของ S3 และ WORM ของ OBS ลด retention ไม่ได้ ตั้งยาวเกินก็ต้องเก็บจนหมดอายุ ให้ทดสอบด้วย governance mode หรือ bucket ทดลองก่อน
• ค่าใช้จ่าย: Huawei Cloud ระบุว่าการเปิด WORM ทำให้ค่าเก็บข้อมูลเพิ่มขึ้น และ CISA เตือนว่าการตั้งค่า immutable storage ผิดอาจทำให้เกิดค่าใช้จ่ายสูง ประเมินจากปริมาณข้อมูลจริงและราคาของผู้ให้บริการที่ใช้
• ข้อกำหนดที่ต้องปฏิบัติ: CISA ระบุว่า immutable storage ไม่ผ่านเกณฑ์ compliance ของข้อกำหนดบางฉบับ ถ้ามีข้อมูลที่องค์กรมีหน้าที่ต้องลบภายในเวลาที่กำหนด ให้ฝ่ายกฎหมายหรือ DPO ดูว่าสำเนาที่ลบไม่ได้ขัดกับหน้าที่นั้นหรือไม่
• ลบของที่ไม่ใช้: SP 800-209 (DP-SS-R11) ให้ลบ snapshot และ clone ที่ล้าสมัยเพื่อลดช่องทางโจมตี และ CPG 2.0 เป้าหมาย 3.O ให้ทำรายการ backup ทั้งหมดที่ดูแลพร้อมระยะเก็บของแต่ละชุด

เลือกแบบไหนเหมาะกับระบบแบบไหน?

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

PDPA พูดถึง backup ไว้หรือไม่?

ไม่ได้พูดถึงคำว่า backup โดยตรง พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 37(1) ให้ผู้ควบคุมข้อมูลส่วนบุคคลจัดให้มีมาตรการรักษาความมั่นคงปลอดภัยที่เหมาะสม เพื่อป้องกันการสูญหาย เข้าถึง ใช้ เปลี่ยนแปลง แก้ไข หรือเปิดเผยข้อมูลส่วนบุคคลโดยปราศจากอำนาจหรือโดยมิชอบ และประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่อง มาตรการรักษาความมั่นคงปลอดภัยของผู้ควบคุมข้อมูลส่วนบุคคล พ.ศ. 2565 ข้อ 3 นิยามความมั่นคงปลอดภัยว่ารวมถึงสภาพพร้อมใช้งาน (availability) ข้อ 4(3) ให้มาตรการครอบคลุมการรักษาและฟื้นฟูความเสียหายที่เกิดจากภัยคุกคามหรือเหตุการละเมิด เท่าที่จำเป็น เหมาะสม และเป็นไปได้ตามระดับความเสี่ยง และข้อ 4(6)(ข) ระบุว่าการบริหารจัดการการเข้าถึงของผู้ใช้งานอาจรวมถึงการบริหารจัดการสิทธิการเข้าถึงตามสิทธิ (management of privileged access rights)

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

ถ้าผู้ให้บริการภายนอกดูแล backup ให้ CISA แนะนำให้ตรวจว่าผู้ให้บริการทำตามแนวปฏิบัติเดียวกัน และเขียนข้อกำหนดด้านความปลอดภัยไว้ในสัญญา

Checklist: ตรวจ backup ของคุณว่ากัน ransomware ได้จริงไหม

ตอบใช่หรือไม่ใช่ทีละข้อ ข้อที่ตอบว่าไม่ใช่หรือไม่แน่ใจคือจุดที่ต้องแก้ก่อน

• มีรายการ backup ทุกชุดที่ดูแลอยู่ พร้อมระยะเก็บ ที่เก็บ และเจ้าของของแต่ละชุดหรือไม่
• ระบบสำคัญมีอย่างน้อยหนึ่งสำเนาที่ล็อกแบบ immutable หรือแยกแบบ offline หรือไม่
• สำเนานั้นอยู่นอกสิทธิ์ของบัญชี domain admin หรือไม่ คือแม้บัญชีนั้นถูกยึดก็ลบหรือแก้ retention ไม่ได้
• Console ของระบบ backup ใช้บัญชีที่ไม่อยู่ใน domain เดียวกับ production และบังคับ MFA หรือไม่
• รหัสผ่านและ access key ทุกชุดที่ลบ backup ได้ เก็บไว้นอกเครื่อง production ทั้งหมดหรือไม่
• การลบ backup หรือลด retention ต้องใช้คนสองคนหรือมีขั้นตอนอนุมัติหรือไม่
• ถ้าใช้ Object Lock รู้หรือไม่ว่าใช้โหมดไหน และใครมีสิทธิ์ bypass หรือถอด legal hold
• ถ้าใช้ append-only งาน forget, prune หรือ compact รันจากเครื่องแยกที่เชื่อถือได้ใช่หรือไม่
• Backup server และซอฟต์แวร์ backup ได้รับ patch และอยู่ในโซนเครือข่ายที่จำกัดการเข้าถึงหรือไม่
• กุญแจเข้ารหัส backup และ credential ที่ใช้กู้คืน มีสำเนาเก็บ offline นอกระบบที่อาจล่มพร้อมกันหรือไม่
• มี alert เมื่อ backup job ล้มเหลว เมื่อมีการลบ backup หรือ snapshot จำนวนมาก และเมื่อ retention หรือ versioning ถูกแก้หรือไม่
• มีการตรวจความครบถ้วนที่อ่านข้อมูลจริง ไม่ใช่แค่ตรวจโครงสร้าง ตามรอบที่กำหนดหรือไม่
• เคยกู้ทั้งระบบลงสภาพแวดล้อมแยกและจับเวลาเทียบกับ RTO ภายในรอบที่องค์กรกำหนดหรือไม่
• ถ้าผู้ให้บริการภายนอกดูแล backup สัญญาระบุแนวปฏิบัติด้านความปลอดภัยและหลักฐานการทดสอบกู้คืนหรือไม่

UNIXDEV ช่วยตรวจระบบ backup และซ้อมกู้คืนได้อย่างไร?

งานวางแผน backup และทดสอบกู้คืนอยู่ในบริการ DevOps & SRE Managed Services ของเรา ร่วมกับรอบการ patch การจัดการสิทธิ์ และการแบ่งโซนเครือข่าย ส่วนระบบเก่าที่หมด support อยู่ในบริการดูแลระบบเดิม จุดเริ่มที่แนะนำคือตรวจระบบจริงตาม checklist ข้างต้น แล้วซ้อมกู้คืนหนึ่งระบบสำคัญลงสภาพแวดล้อมแยก เพื่อดูว่าสำเนาชุดไหนผู้โจมตีเข้าไม่ถึง และกู้ได้ทันเป้าที่องค์กรตั้งไว้หรือไม่ งานรับมือเหตุด้านความปลอดภัยและนิติวิทยาศาสตร์ดิจิทัลหลังเกิดเหตุควรใช้ผู้เชี่ยวชาญเฉพาะด้านนั้น

แหล่งอ้างอิงและอ่านต่อ

• CISA, MS-ISAC, NSA, FBI — #StopRansomware Guide (PDF, October 2023)
• CISA — Cross-Sector Cybersecurity Performance Goals 2.0
• US-CERT — Data Backup Options (2012)
• CISA — Known Exploited Vulnerabilities Catalog (data feed)
• NIST SP 800-209 — Security Guidelines for Storage Infrastructure (2020)
• NIST SP 800-53 Rev. 5 — Security and Privacy Controls (CP-9)
• NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems
• NIST NCCoE — Protecting Data from Ransomware and Other Data Loss Events
• NIST IR 8374 Rev. 1 — Ransomware Risk Management: A Cybersecurity Framework 2.0 Community Profile
• NIST CSRC Glossary — air gap
• MITRE ATT&CK — T1490 Inhibit System Recovery · T1078 · T1489
• AWS — Locking objects with Object Lock
• MinIO AIStor — Object locking and immutability
• Huawei Cloud — OBS WORM
• restic rest-server · restic — Removing backup snapshots · restic — Working with repositories
• Borg — Additional notes (append-only mode) · Borg — Backing up in pull mode
• OpenZFS — zfs-hold · zfs-allow
• Proxmox Backup Server — Backup client usage · Maintenance tasks · Managing remotes and sync
• Veeam — Hardened repository immutability · Veeam — 3-2-1 backup rule
• ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่อง มาตรการรักษาความมั่นคงปลอดภัยของผู้ควบคุมข้อมูลส่วนบุคคล พ.ศ. 2565
• บทความที่เกี่ยวข้อง: Ransomware คืออะไร? ป้องกันและรับมืออย่างไร
• บทความที่เกี่ยวข้อง: ระบบเก่าหมด support แต่ยังต้องใช้ต่อ
• บทความที่เกี่ยวข้อง: เช็กลิสต์สัญญา MA และ SLA
• บทความที่เกี่ยวข้อง: วางแผนติดตั้ง Wazuh
• บทความที่เกี่ยวข้อง: ตรวจจับ Ransomware ด้วย Wazuh: ตั้งค่าอะไรบ้าง
• บทความทั้งหมดในหมวด DevOps และดูแลระบบองค์กร

บทความโดย UNIXDEV Team · 8 พฤศจิกายน 2026 · อ้างอิงเอกสารของ CISA, NIST, MITRE, สคส. และเอกสารทางการของผู้ผลิตซอฟต์แวร์ ณ วันที่เขียน ซึ่งอาจเปลี่ยนภายหลัง ชื่อผลิตภัณฑ์เป็นตัวอย่างประกอบ ไม่ใช่คำแนะนำให้เลือกยี่ห้อใด สรุปข้อกฎหมายเพื่อประกอบการวางแผน ไม่ใช่คำแนะนำทางกฎหมาย และคำสั่งหรือการตั้งค่าต้องทดสอบกับระบบจริงก่อนใช้