Tính liên tục và phục hồi: Bộ phục hồi chưa ai kiểm tra

Mọi bảng điều khiển backup đều hiển thị dấu kiểm xanh. Các công việc hoàn thành, chính sách lưu giữ được thỏa mãn, bộ nhớ được sử dụng như mong đợi. Không có gì trong đó cho biết liệu bạn có thể đưa domain controller quay trở lại từ bare metal trong vòng bốn giờ trong một sự cố thực tế hay không. Khoảng cách giữa "backup thành công" và "restore thành công" là nơi hầu hết các kế hoạch tính liên tục bị thất bại im lặng.

Tại sao dấu kiểm nói dối

Phần mềm backup báo cáo thành công khi nó hoàn thành việc ghi byte vào một đích đến. Nó không biết liệu những byte đó có thể sử dụng được hay không. Một backup SQL Server có thể hoàn thành sạch sẽ nhưng vẫn không thể khôi phục được vì chuỗi transaction log bị gãy cách đây ba ngày và không ai để ý. Các VM snapshots có thể trông ổn trong bảng điều khiển trong khi VSS writer cơ bản im lặng thất bại bên trong guest OS, tạo ra một hình ảnh crash-consistent (không phải application-consistent).

Các toán tử ransomware biết điều này. Các nhóm chạy playbooks kiểu Conti trong các sự cố quá khứ cố tình nhắm vào cơ sở hạ tầng backup — xóa shadow copies bằng vssadmin delete shadows /all /quiet, vô hiệu hóa các kho lưu trữ Veeam, mã hóa các mục tiêu backup dựa trên NAS có thể truy cập được qua SMB. Nếu các backup của bạn nằm trên cùng một đoạn mạng với production với các thông tin xác thực miền có thể chạm vào chúng, chúng là một mục tiêu, không phải một lưới an toàn.

Xây dựng runbook phục hồi, không phải chính sách backup

Một kế hoạch tính liên tục cần các hướng dẫn phục hồi từng bước được viết cho người không phải là người thường xuyên làm điều đó. Viết ra:

• Thứ tự phục hồi chính xác (domain controllers và DNS trước, sau đó các ứng dụng cốt lõi, sau đó mọi thứ khác)
• Nơi lưu giữ thông tin xác thực cho bảng điều khiển backup nếu kho mật khẩu của bạn cũng bị lỗi
• Lệnh phục hồi cụ thể hoặc đường dẫn bảng điều khiển, không phải "sử dụng Veeam để phục hồi VM"
• Khoảng thời gian dự kiến cho mỗi hệ thống, dựa trên các bài kiểm tra được đo lường thực tế, không phải con số tiếp thị của nhà cung cấp

Đối với Veeam Backup & Replication, điều đó có nghĩa là ghi lại các bước thực tế: mở bảng điều khiển, điều hướng đến Backups > Disk, nhấp chuột phải vào điểm phục hồi, chọn Instant VM Recovery hoặc Full VM Restore tùy thuộc vào tình huống, và chọn máy chủ đích có đủ dung lượng trống. Nếu máy chủ chính của bạn cũng bị xâm phạm, bạn cần một máy chủ thứ hai, được cô lập và được cấp phép.

Kiểm tra phục hồi theo lịch trình, không phải tùy tiện

Chọn một rotation. Hàng tháng, phục hồi một hệ thống quan trọng vào một VLAN bị cô lập và xác thực nó khởi động, xác thực và phục vụ dữ liệu một cách chính xác. Hàng quý, chạy một bài kiểm tra toàn phạm vi: phục hồi domain controller, máy chủ tệp và cơ sở dữ liệu chính của bạn sang cơ sở hạ tầng bị cô lập, sau đó có người bên ngoài nhóm backup cố gắng đăng nhập và kéo một báo cáo.

Đối với cơ sở dữ liệu, đừng chỉ phục hồi tệp .bak — xác minh nó:

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

Sau đó thực sự phục hồi nó vào một test instance và chạy DBCC CHECKDB đối với nó. Một backup vượt qua VERIFYONLY vẫn có thể chứa corruption logic chỉ hiển thị khi bạn truy vấn nó.

Đối với các hệ thống Linux sử dụng thứ gì đó như Bacula hoặc restic, kiểm tra đường dẫn phục hồi thực tế:

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

Sau đó diff các tệp cấu hình đã phục hồi so với production để xác nhận không có gì bị thả một cách im lặng.

Bản sao bất biến và quy tắc 3-2-1-1

Quy tắc 3-2-1 cổ điển (ba bản sao, hai loại phương tiện, một ngoài địa điểm) cần cập nhật cho kỷ nguyên ransomware: 3-2-1-1, trong đó "1" thêm là một bản sao bất biến hoặc được cách ly không khí. Object lock trên bộ nhớ tương thích S3 (Wasabi, Backblaze B2, hoặc AWS S3 với Object Lock được bật) ngăn chặn xóa hoặc sửa đổi trong một cửa sổ lưu giữ được xác định, ngay cả bởi một tài khoản có thông tin xác thực quản trị. Cấu hình nó với:

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

Chế độ COMPLIANCE có nghĩa là không ai, kể cả tài khoản root, có thể rút ngắn lưu giữ hoặc xóa các đối tượng sớm hơn. Điều đó quan trọng khi kẻ tấn công có domain admin.

Đo RTO và RPO bằng các con số thực, không phải phỏng đoán

Recovery Time Objective và Recovery Point Objective nghe giống như các bài tập giấy tờ cho đến khi một giám đốc điều hành hỏi "chúng ta mất bao nhiêu dữ liệu và chúng ta bị ngừng bao lâu." Thời gian ba bài kiểm tra phục hồi cuối cùng của bạn. Nếu mục tiêu RPO của bạn là một giờ nhưng công việc backup của bạn chỉ chạy mỗi sáu giờ, bạn có một khoảng cách được ghi lại, và tốt hơn là tìm thấy khoảng cách đó trong một bài tập bàn thay vì trong một sự kiện mã hóa thực tế lúc 2 giờ sáng vào thứ Bảy.

Chạy bài kiểm tra, ghi lại thời gian đồng hồ thực tế, và so sánh với những gì bạn hứa trong tài liệu khôi phục thảm họa. Sự khác biệt giữa hai con số đó là trạng thái thực sự của kế hoạch tính liên tục của bạn.

Để biết thêm về cứng hóa các hệ thống bạn đang bảo vệ và xây dựng các quy trình phản hồi sự cố, hãy xem các phân đoạn Blue Team và Digital Forensics liên quan trên Korra Studio.