Veeam Immutable Backup — กัน Ransomware Lateral Movement
Ransomware สมัยใหม่เล็งลบ Backup ก่อนเรียกค่าไถ่ บทความนี้แชร์วิธีใช้ Hardened Linux Repository, S3 Object Lock และ 3-2-1-1-0 Rule เพื่อปิดช่องโหว่นั้น
1. ทำไม Backup ปกติถึงไม่พอ — กรณีศึกษา Ransomware ลบ Backup#
เหตุการณ์จริงในปี 2025: บริษัทผู้ผลิตขนาดกลางในภาคใต้โดน Ransomware กลุ่ม BlackBasta เข้าระบบผ่าน VPN Credential ที่หลุดออกไป ผู้โจมตีใช้เวลาประมาณ 11 วันทำ Lateral Movement เงียบ ๆ ก่อนกดเข้ารหัส
สิ่งที่เจ็บปวดกว่านั้นคือ Backup Server ถูก Map Drive เชื่อมอยู่กับ Domain และผู้โจมตีลบ Backup File ทิ้งทุก Recovery Point ก่อนที่จะปล่อย Ransomware ตัวจริง IT Admin เปิด Veeam ขึ้นมาเพื่อ Restore แต่เห็นแค่ Job ว่างเปล่า
Ransomware สมัยใหม่ไม่ได้แค่เข้ารหัสข้อมูล แต่มีขั้นตอน ลบ Backup โดยเฉพาะ เป็น Playbook มาตรฐาน ถ้า Backup Server อยู่บน Domain เดียวกัน หรือ Share Drive เข้าถึงได้ — Backup นั้นนับว่าไม่มี
จุดอ่อนที่พบซ้ำในกรณีแบบนี้คือ Backup Repository ใช้ Windows Server ที่ Join Domain, Credential เดียวกับ Admin ปกติ, ไม่มี Immutability ใด ๆ
2. หลักการ Immutability — Write-Once-Read-Many#
Immutable Backup หมายถึง Backup File ที่ถูกล็อกไว้แบบ Write-Once-Read-Many (WORM) ภายในช่วงเวลาที่กำหนด ไม่มีใครแก้ไขหรือลบได้ แม้แต่ Root หรือ Admin ของระบบนั้น ๆ
กลไกหลักมี 2 แบบ:
File-system level immutability — Linux Extended Attribute chattr +i บน XFS Filesystem ทำให้ File นั้น Immutable จนกว่าจะหมด Retention Period และต้องถอดผ่าน Local Console เท่านั้น
Object Storage level immutability — S3 Object Lock ล็อก Object ใน Bucket ผ่าน API ผู้โจมตีที่ได้ Access Key ไปก็ยังลบ Object ไม่ได้ถ้า Lock ยังไม่หมด
Veeam 12.x รองรับทั้งสองแบบนี้แบบ Native ผ่าน Hardened Repository และ Object Storage Repository ตามลำดับ
3. ตัวเลือกที่ 1: Veeam Hardened Linux Repository#
หลักการทำงาน#
Hardened Linux Repository ใช้ Linux Server (ไม่ Join Domain) รัน Veeam Data Mover เป็น Unprivileged User แยกต่างหาก Backup File จะถูก Set Immutable Flag ผ่าน chattr +i บน XFS โดยอัตโนมัติเมื่อ Backup Job เสร็จ
ระหว่าง Immutability Period ไม่มี Process ใด — รวมถึง Root — สามารถลบ File ได้ หมดอายุแล้วค่อย Remove ตาม Retention
ขั้นตอน Deploy#
1. เตรียม Linux Server
# Ubuntu 22.04 LTS หรือ RHEL 9 แนะนำ
# Disk: XFS เท่านั้น (ext4 ไม่รองรับ chattr immutable lock)
mkfs.xfs /dev/sdb
mkdir /backup-repo
mount /dev/sdb /backup-repo
echo "/dev/sdb /backup-repo xfs defaults 0 0" >> /etc/fstab
2. ไม่ Join Domain — สำคัญมาก
Server นี้ต้องไม่ผูก Active Directory ใด ๆ ใช้ Local Account เท่านั้น ปิด SMB/CIFS Share ทั้งหมด
3. เพิ่มใน Veeam Console
Backup Infrastructure > Add Repository > Linux (Hardened) > กรอก IP, SSH Credential > เลือก Path /backup-repo > ติ๊ก Make recent backups immutable for: 7 days (แนะนำ 7–14 วัน)
4. สร้าง Backup Job ชี้ไปที่ Hardened Repo
Veeam จะส่ง Backup ผ่าน SSH แล้ว Set chattr +i ให้อัตโนมัติ
ตั้ง SSH Port เป็น Non-standard (เช่น 2222) และจำกัด Firewall ให้รับ Connection จาก Veeam Backup Server IP เดียวเท่านั้น
4. ตัวเลือกที่ 2: Object Storage + S3 Object Lock#
ทำไมต้อง Object Lock#
Object Storage เช่น Wasabi, Backblaze B2, AWS S3 รองรับ S3 Object Lock ซึ่งล็อก Object ใน Mode Compliance หรือ Governance ถ้าใช้ Compliance Mode แม้แต่ Root Account ก็ลบ Object ก่อนกำหนดไม่ได้
ขั้นตอน Config#
1. สร้าง Bucket บน Wasabi (ตัวอย่าง)
- เปิด Object Lock เมื่อสร้าง Bucket (ไม่สามารถเปิดภายหลัง)
- เลือก Default Retention: Compliance Mode, 14 days
- สร้าง Access Key ที่มีสิทธิ์เฉพาะ Bucket นั้น ไม่ใช่ Root Key
2. เพิ่มใน Veeam Console
Backup Infrastructure > Add Repository > Object Storage > S3 Compatible > กรอก Endpoint, Access Key, Secret Key > เลือก Bucket > ติ๊ก Make recent backups immutable for: 14 days
3. ใช้เป็น Scale-out Repository Extent
แนะนำให้เพิ่ม Object Storage เป็น Capacity Tier ของ Scale-out Backup Repository (SOBR) โดยให้ Local Hardened Repo เป็น Performance Tier ข้อมูลจะไหลไป Object Storage อัตโนมัติหลัง Operational Restore Window
Wasabi ไม่คิด Egress Fee เหมาะกับการดึงข้อมูลกลับมา Restore ซึ่งต่างจาก AWS S3 ที่มี Egress Cost หากใช้ AWS ให้ใช้ S3 Glacier Instant Retrieval แทน Standard สำหรับ Long-term Copy
Insider Protection (Veeam 12.x)#
Veeam 12 เพิ่ม Feature Insider Protection บน Scale-out Repository — เมื่อลบ Backup Point ออกจาก Veeam Console ข้อมูลจริงจะยังไม่ถูกลบทันที แต่ถูกย้ายไป Recycle Bin ของ Repository เป็นเวลา 7 วัน (ค่า Default) เป็น Safety Net กรณี Admin ถูก Compromise แล้วสั่งลบ Job
5. ตัวเลือกที่ 3: Tape (LTO) — เก่าแต่ยังใช้ได้ดี#
LTO Tape ยังคงเป็น Air-gap ที่ดีที่สุด เมื่อ Eject Tape ออกจาก Drive แล้วผู้โจมตีทำอะไรไม่ได้เลย
Veeam รองรับ Tape natively ผ่าน Veeam Backup & Replication > Tape Infrastructure Wizard ใช้ร่วมกับ Media Pool และ GFS (Grandfather-Father-Son) Retention ได้
BOM Tape สำหรับ SMB:
- LTO-9 Tape Drive (Internal หรือ External): ~80,000–120,000 บาท
- LTO-9 Tape Cartridge 18TB Native (10 ม้วน): ~25,000 บาท
- เหมาะกับองค์กรที่ข้อมูลรวม 10–50 TB
แม้จะมี Immutable Repository แล้ว ยังแนะนำ Tape 1 ม้วนต่อสัปดาห์ เก็บนอก Site เพื่อป้องกันภัยพิบัติทางกายภาพ
6. 3-2-1-1-0 Rule#
กฎ 3-2-1 เดิมไม่เพียงพออีกต่อไป Veeam ปรับเป็น 3-2-1-1-0:
| ตัวเลข | ความหมาย |
|---|---|
| 3 | Copy ของข้อมูล 3 ชุด (Production + 2 Backup) |
| 2 | เก็บบน Media 2 ประเภทที่แตกต่างกัน (เช่น Disk + Object Storage) |
| 1 | 1 Copy อยู่นอก Site หรือ Offsite |
| 1 | 1 Copy ต้อง Immutable (Hardened Repo หรือ S3 Object Lock หรือ Tape) |
| 0 | 0 Errors จาก Automated Restore Verification ทุก Backup Job |
ตัวเลข 0 สำคัญมาก Veeam มี Feature SureBackup ที่รัน VM จาก Backup ใน Isolated Lab Network เพื่อตรวจสอบว่า OS Boot ได้ Application ตอบสนองได้ รายงานผลอัตโนมัติ ถ้าไม่ทำ Verification ก็ไม่รู้ว่า Backup นั้น Restore ได้จริงหรือเปล่า
7. สถาปัตยกรรมตัวอย่าง — SMB งบ 300,000–700,000 บาท#
Scenario: บริษัท 50–150 คน, Data 10–30 TB, Veeam 12.x#
BOM หลัก:
| รายการ | Spec | ราคาประมาณ |
|---|---|---|
| Veeam Backup & Replication Universal License | 10 Instance | ~120,000 บาท |
| Hardened Linux Repository Server | Rackmount 1U, 32GB RAM, 4x 8TB SATA RAID6 (usable ~16TB XFS) | ~85,000 บาท |
| Wasabi Object Storage | 10 TB/เดือน | ~1,900 บาท/เดือน (~23,000 บาท/ปี) |
| LTO-9 External Tape Drive | IBM/HPE | ~95,000 บาท |
| LTO-9 Tape x 10 ม้วน | 18TB Native each | ~25,000 บาท |
| Network Switch (1G/10G) สำหรับ Backup VLAN | Unmanaged หรือ Managed | ~15,000–30,000 บาท |
| รวม CapEx ปีแรก | ~350,000–370,000 บาท |
Architecture Flow:
Production VM (vSphere/Hyper-V/Proxmox)
│
▼ Backup Job (ทุกคืน)
Hardened Linux Repository [Immutable 14 days]
│
▼ Scale-out SOBR Offload (>14 days)
Wasabi S3 Object Lock [Immutable 30 days]
│
▼ Weekly Tape Job (ทุกศุกร์)
LTO-9 Tape [Eject + เก็บนอก Site]
Backup Network ต้องแยก VLAN — Production และ Backup ไม่ควรอยู่ Subnet เดียวกัน จำกัด ACL ให้ Backup Server เข้าถึงได้แค่ Hypervisor Host เท่านั้น ไม่อนุญาต Lateral Access
Veeam Backup Server ควร:
- ไม่ Join Domain หรือถ้า Join ใช้ Tiered Admin Account แยก
- เปิด 2FA สำหรับ Veeam Console
- ปิด RDP/Remote Desktop จาก Network ทั่วไป
8. สรุป + Action Priority#
ถ้าทำได้แค่ 3 อย่างภายในเดือนนี้ให้เริ่มที่:
- ตั้ง Hardened Linux Repository — ใช้ Linux ที่ไม่ Join Domain, XFS, Immutable 14 วัน เป็นขั้นต่ำที่ป้องกัน Lateral Movement ได้จริง
- เพิ่ม S3 Object Lock Copy — Wasabi หรือ Backblaze B2 ราคาถูก ทำ Offsite Immutable Copy โดยไม่ต้องซื้อ Hardware เพิ่ม
- เปิด SureBackup Verification — รู้ก่อนเกิดเหตุว่า Backup Restore ได้จริง ไม่ใช่รอวันที่ต้องใช้จริงแล้วค่อยรู้ว่ามีปัญหา
Backup ที่ไม่ผ่าน Verification ไม่ใช่ Backup — มันแค่ไฟล์ที่ยังไม่รู้ว่าใช้ได้หรือเปล่า
Ransomware Lateral Movement ใช้เวลาหลายวันถึงหลายสัปดาห์ก่อนโจมตี ถ้า Immutability Period ของ Backup ยาวกว่า Dwell Time ของผู้โจมตี คุณยังมี Recovery Point ที่สะอาดอยู่เสมอ
C9NETWORK ให้บริการ Veeam Deployment และ DR Planning ครบวงจร ตั้งแต่ออกแบบ Architecture, ติดตั้ง Hardened Linux Repository, Config S3 Object Lock, ไปจนถึง DR Test สม่ำเสมอ ทีมงานพร้อม Site Survey และออก BOM ที่เหมาะกับงบและขนาดองค์กรของคุณ ติดต่อได้เลย