ความต่อเนื่องและการกู้คืน: การ Restore ที่ไม่มีใครทดสอบ

ทุก dashboard backup แสดง checkmarks สีเขียว Jobs เสร็จสิ้น นโยบาย retention พอใจ storage ถูกใช้งานตามที่คาดไว้ ไม่มีอะไรเลยที่บอกคุณว่าคุณสามารถนำ domain controller กลับมาจากสภาวะ bare metal ได้ภายในสี่ชั่วโมงในระหว่างเหตุการณ์จริง ช่องว่างระหว่าง "backup succeeded" และ "restore succeeded" คือที่ที่แผนความต่อเนื่องส่วนใหญ่ล้มเหลวอย่างเงียบๆ

ทำไม checkmark จึงโกหก

Backup software รายงานความสำเร็จเมื่อมันจบการเขียน bytes ไปยังปลายทาง มันไม่รู้ว่า bytes เหล่านั้นสามารถใช้งานได้หรือไม่ SQL Server backup สามารถเสร็จสิ้นได้อย่างสะอาดแต่ยังคงไม่สามารถกู้คืนได้เพราะเชน transaction log ขาดสายสามวันก่อนหน้านี้และไม่มีใครสังเกต VM snapshots สามารถดูเหมือนว่าไม่มีปัญหาในคอนโซลในขณะที่ VSS writer ที่อยู่ด้านล่างล้มเหลวเงียบๆ ภายในระบบปฏิบัติการแขก ทำให้เกิดอิมเมจที่ crash-consistent ไม่ใช่ application-consistent

Operators ransomware รู้สิ่งนี้ Groups ที่ใช้ Conti-style playbooks ในเหตุการณ์ที่ผ่านมา โดยตั้งใจเป้าหมายอินฟราสตรัคเจอร์ backup — ลบ shadow copies ด้วย vssadmin delete shadows /all /quiet ปิดใช้งาน Veeam repositories เข้ารหัส backup targets ที่ใช้ NAS และเข้าถึงได้ผ่าน SMB หากไฟล์ backup ของคุณอยู่บนเซกเมนต์เครือข่ายเดียวกับ production ด้วยข้อมูลรับรองโดเมนที่สามารถเข้าถึงได้ พวกมันจึงเป็นเป้าหมายไม่ใช่ safety net

สร้าง restore runbook ไม่ใช่ backup policy

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

• ลำดับการกู้คืนที่แน่นอน (domain controllers และ DNS ก่อน จากนั้นแอปพลิเคชันหลัก แล้วจึงทั้งหมด)
• ที่ที่เก็บข้อมูลรับรองสำหรับ backup console หากคลัง password ของคุณลงด้วย
• คำสั่ง restore ที่เฉพาะเจาะจงหรือเส้นทาง console ไม่ใช่ "ใช้ Veeam เพื่อกู้คืน VM"
• ระยะเวลาที่คาดว่าจะใช้ต่อระบบ โดยยึดตามการทดสอบที่วัดจริง ไม่ใช่ตัวเลขการตลาดของผู้ขาย

สำหรับ Veeam Backup & Replication นั่นหมายถึงการจัดทำเอกสารเกี่ยวกับขั้นตอนจริง: เปิดคอนโซล ไปที่ Backups > Disk คลิกขวาที่จุด restore เลือก Instant VM Recovery หรือ Full VM Restore ขึ้นอยู่กับสถานการณ์ และเลือก target host ที่มีความจุฟรีเพียงพอ หากโฮสต์หลักของคุณถูกบุกรุกด้วย คุณต้องมีโฮสต์ที่สอง แยกออกจากกัน และมีใบอนุญาตแล้ว

ทดสอบ restore ตามตารางเวลา ไม่ใช่ตามใจ

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

สำหรับฐานข้อมูล อย่าเพียงแค่ restore ไฟล์ .bak — ตรวจสอบ:

RESTORE VERIFYONLY FROM DISK = 'D:\Backups\prod_2024.bak'

จากนั้นจริงๆ restore มันไปยังอินสแตนซ์ทดสอบและเรียกใช้ DBCC CHECKDB กับมัน Backup ที่ผ่าน VERIFYONLY ยังคงสามารถมี logical corruption ที่ปรากฏเฉพาะเมื่อคุณ query มัน

สำหรับระบบ Linux ที่ใช้บางอย่างเช่น Bacula หรือ restic ให้ทดสอบเส้นทาง restore จริง:

restic restore latest --target /tmp/restore-test --repo /mnt/backup-repo

จากนั้น diff ไฟล์คอนฟิกที่กู้คืนกับ production เพื่อยืนยันว่าไม่มีอะไรหล่นอย่างเงียบๆ

Immutable copies และกฎ 3-2-1-1

กฎคลาสสิก 3-2-1 (สามสำเนา สองประเภทสื่อ หนึ่งที่ห่างไกล) ต้องการการอัปเดตสำหรับยุค ransomware: 3-2-1-1 โดยที่ "1" พิเศษคือสำเนา immutable หรือ air-gapped Object lock บน S3-compatible storage (Wasabi, Backblaze B2, หรือ AWS S3 ที่มี Object Lock เปิดใช้งาน) ป้องกันการลบหรือการแก้ไขสำหรับ retention window ที่กำหนด แม้จากบัญชีที่มีข้อมูลรับรอง admin กำหนดค่าด้วย:

aws s3api put-object-lock-configuration \
  --bucket backup-vault \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

โหมด COMPLIANCE หมายความว่าไม่มีใครรวมทั้งบัญชี root สามารถย่อ retention หรือลบออบเจกต์ก่อนกำหนดได้ สิ่งนั้นมีความสำคัญเมื่อผู้โจมตีมี domain admin

วัด RTO และ RPO ด้วยตัวเลขจริง ไม่ใช่การคาดเดา

Recovery Time Objective และ Recovery Point Objective ฟังเหมือนแบบฝึกหัดเอกสารจนกว่าผู้บริหารจะถาม "เราสูญเสียข้อมูลเท่าไหร่และเราปิดดำเนินการนานแค่ไหน" ควบคุมเวลา restore ทดสอบสามครั้งล่าสุดของคุณ หากเป้าหมาย RPO ของคุณคือหนึ่งชั่วโมงแต่งาน backup ของคุณเพียง run ทุกหกชั่วโมง คุณมีช่องว่างที่เอกสารไว้ และจะดีกว่าถ้าค้นหาช่องว่างนั้นในแบบฝึกหัด tabletop มากกว่าระหว่างเหตุการณ์การเข้ารหัสจริงเวลา 2 น. ของวันเสาร์

รัน test เขียนลงเวลาจริง และเปรียบเทียบกับสิ่งที่คุณสัญญาไว้ในเอกสาร disaster recovery ความแตกต่างระหว่างตัวเลขทั้งสองนั้นคือสถานะจริงของแผนความต่อเนื่องของคุณ

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการเสริมความแข็งแกร่งของระบบที่คุณปกป้องและสร้างเวิร์กโฟลว์การตอบสนองต่อเหตุการณ์ ดูเซกเมนต์ Blue Team และ Digital Forensics ที่เกี่ยวข้องบน Korra Studio