Immutable Backup คือข้อมูลสำรองที่เมื่อเขียนแล้ว จะแก้ไขหรือลบไม่ได้จนกว่าจะครบระยะเวลาที่กำหนด แม้ผู้ที่มีสิทธิ์ผู้ดูแลระบบก็ตาม แนวคิดนี้เป็นส่วนสำคัญของหลัก 3-2-1-1-0 ซึ่งต่อยอดจากหลัก 3-2-1 แบบเดิม เพราะ Ransomware รุ่นใหม่มักพยายามเข้าถึงและลบข้อมูลสำรองก่อนเข้ารหัสระบบหลัก ถ้าข้อมูลสำรองถูกลบไปด้วย การกู้คืนจะทำไม่ได้
หน่วยงานด้านความมั่นคงปลอดภัยไซเบอร์หลายแห่งแนะนำให้เก็บข้อมูลสำรองแบบ Offline หรือ Immutable ไว้เป็นแนวป้องกันสุดท้าย ดูตัวอย่างแนวทางได้ใน #StopRansomware Guide ของ CISA
หลัก 3-2-1 เดิมคืออะไร
- 3 ชุด: ข้อมูลจริง 1 ชุด และข้อมูลสำรองอีก 2 ชุด
- 2 สื่อ: เก็บบนอุปกรณ์หรือสื่อบันทึกอย่างน้อย 2 ประเภท
- 1 นอกสถานที่: มีอย่างน้อย 1 ชุดเก็บไว้ต่างสถานที่
หลักนี้ป้องกันดิสก์เสีย เครื่องพัง และภัยพิบัติที่ Site หลักได้ดี แต่ถ้าผู้โจมตีได้บัญชีผู้ดูแลระบบ Backup ไป ข้อมูลทั้ง 3 ชุดอาจถูกลบผ่านบัญชีเดียวกันได้
หลัก 3-2-1-1-0 เพิ่มอะไร
| ตัวเลข | ความหมาย | ป้องกันอะไร |
|---|---|---|
| 3 | ข้อมูล 3 ชุด | ข้อมูลเสียหายชุดเดียว |
| 2 | สื่อ 2 ประเภท | ความเสียหายเฉพาะประเภทอุปกรณ์ |
| 1 | 1 ชุดนอกสถานที่ | ภัยพิบัติที่ Site หลัก |
| 1 | 1 ชุดเป็น Offline หรือ Immutable Backup | ผู้โจมตีที่ได้สิทธิ์ผู้ดูแลระบบ |
| 0 | ตรวจแล้วกู้คืนได้โดยไม่มีข้อผิดพลาด | ข้อมูลสำรองที่เสียโดยไม่มีใครรู้ |
เลข 0 สำคัญไม่แพ้เลข 1 ตัวที่สอง เพราะองค์กรจำนวนมากเพิ่งพบว่าข้อมูลสำรองเสียในวันที่ต้องใช้จริง
วิธีทำ Immutable Backup ที่ใช้กันจริง
Object Storage แบบ Object Lock
Object Storage ที่รองรับ S3 API มักมีฟีเจอร์ Object Lock ซึ่งกำหนดระยะเวลาที่ห้ามลบหรือเขียนทับได้ มี 2 โหมดหลัก
- Governance Mode: ผู้ที่มีสิทธิ์พิเศษยังปลดล็อกได้ เหมาะกับการทดสอบ
- Compliance Mode: ไม่มีใครลบได้จนกว่าจะครบกำหนด รวมถึงบัญชีสูงสุดของผู้ให้บริการ
ซอฟต์แวร์ Backup หลายรายรองรับการเขียนข้อมูลสำรองลง Object Storage พร้อม Object Lock โดยตรง [ตรวจสอบ: รายชื่อซอฟต์แวร์ Backup ที่ใช้อยู่รองรับ Object Lock หรือไม่]
Hardened Repository บน Linux
เก็บข้อมูลสำรองบนเซิร์ฟเวอร์ Linux ที่ตั้งค่าให้ไฟล์เป็น Immutable ด้วย Attribute ของ File System และจำกัดการเข้าถึง เช่น ปิด SSH ระหว่างการทำงานปกติ และใช้บัญชีที่ไม่มีสิทธิ์ Root สำหรับรับข้อมูล
Snapshot ที่แยกสิทธิ์
Storage ระดับองค์กรหลายรุ่นมี Snapshot แบบล็อกได้ ต้องใช้ร่วมกับการแยกบัญชีผู้ดูแล Storage ออกจาก Domain หลัก ไม่อย่างนั้นผู้โจมตีที่ได้สิทธิ์ Domain Admin อาจเข้าไปลบ Snapshot ได้
Offline Media
เทปหรือดิสก์ที่ถอดออกจากเครือข่ายหลังเขียนเสร็จยังเป็นวิธีที่ได้ผล แต่มี RTO ยาวกว่าเพราะต้องนำสื่อกลับมาต่อก่อนกู้
Immutable Backup อย่างเดียวยังไม่พอ
ความสามารถห้ามลบของ Immutable Backup จะไม่มีประโยชน์ ถ้าผู้โจมตีเข้าไปเปลี่ยนค่าระยะเวลาการเก็บหรือปิดงาน Backup ได้ตั้งแต่แรก ควรทำเรื่องเหล่านี้คู่กัน
- แยกบัญชีผู้ดูแลระบบ Backup: อย่าผูกกับ Active Directory หลัก และบังคับใช้ MFA
- แยก Network: ให้ Backup Repository รับข้อมูลได้เฉพาะจาก Backup Server ที่กำหนด
- Monitor การเปลี่ยนแปลงผิดปกติ: เช่น งาน Backup ถูกปิด, Retention ถูกลดลง หรือมีการลบข้อมูลสำรองจำนวนมาก
- ตั้ง Retention ให้นานพอ: ผู้โจมตีบางกลุ่มแฝงตัวในระบบหลายสัปดาห์ก่อนลงมือ ถ้าเก็บข้อมูลสำรองแค่ 7 วัน ทุกชุดอาจมีมัลแวร์ติดอยู่แล้ว