NAKIVO Backup & Replication - Backup Immutability
1. Lý thuyết
Khi tạo một công việc sao lưu và lựa chọn kho lưu trữ dạng
Amazon EC2, Amazon S3, Wasabi, Azure Blob Storage, Backblaze B2 CloudStorage,
Dell EMC DataDomain, NEC HYDRAstor
Thư mục cục bộ (Local Folder) nơi đã được cài đặt Transporter (cơ chế khoá là chattr +i), NAKIVO Backup & Replication cho phép bạn thiết lập tính năng bất biến cho các điểm khôi phục (recovery points) trong các kho lưu trữ này.
Khi tính năng bất biến được kích hoạt, các điểm khôi phục sẽ được lưu trữ theo mô hình (WORM - write-once-read-many).
Cơ chế này cung cấp một tầng bảo mật bổ sung bằng cách ngăn chặn ransomware cũng như việc vô tình xóa hoặc sửa đổi các điểm khôi phục.
1.1. Cơ chế Khóa đối tượng (Object Locking) trên Cloud
Nếu lưu trữ backup trên các nền tảng đám mây (như AWS S3, Azure Blob, S3-Compatible...), cơ chế này được gọi là S3 Object Lock hoặc Blob Immutability. Hoạt động dựa trên 2 chế độ khóa:- Chế độ Quản trị (Governance Mode): Các file backup bị khóa đối với người dùng thông thường, nhưng một số tài khoản có đặc quyền siêu cấp (chứa quyền IAM đặc biệt) vẫn có thể xóa được. (Chế độ này ít khi dùng cho mục đích chống Ransomware tuyệt đối).
- Chế độ Tuân thủ (Compliance Mode): Đây mới là "vũ khí tối thượng". Khi bật chế độ này, không một ai, kể cả tài khoản Root của tập đoàn hay chính nhà cung cấp dịch vụ đám mây (như Amazon, Microsoft) có thể xóa hoặc sửa đổi file cho đến khi hết thời gian khóa (Retention Period). Lệnh xóa gửi đến sẽ bị API của hệ thống đám mây từ chối ngay lập tức ở tầng hạ tầng.
2. Cơ chế Thuộc tính Hệ điều hành (Linux Hardened Repository)
Nếu lưu backup ở các ổ đĩa cục bộ (On-premise) thay vì Cloud, các phần mềm backup như NAKIVO hay Veeam thường yêu cầu bạn dựng một máy chủ Linux riêng biệt, gọi là Hardened Repository. Cơ chế bảo vệ ở đây bao gồm:- Sử dụng thuộc tính tệp tin "Append-Only" (Chỉ ghi thêm): Hệ điều hành Linux có một lệnh hệ thống sâu là chattr +i (Immutable) hoặc chattr +a (Append-only). Khi phần mềm sao lưu ghi xong file backup, nó sẽ kích hoạt lệnh này lên file. Khi đó, nhân (Kernel) của hệ điều hành Linux sẽ chặn đứng mọi hành vi RM (Xóa) hoặc Modify (Sửa) tác động lên file đó.
- Quyền hạn một chiều (Non-root credentials): Phần mềm backup kết nối với máy chủ Linux này bằng một tài khoản có quyền hạn rất thấp (chỉ đủ để ghi dữ liệu). Sau khi ghi xong, một tiến trình chạy ngầm (Service) nội bộ trên Linux (có quyền Root nội bộ) sẽ đứng ra "khóa" file lại. Hacker chiếm được phần mềm backup cũng không có quyền mở khóa trên Linux.
3. Cơ chế Mã hóa ký số và Đóng dấu thời gian (Timestamping)
Làm sao hệ thống biết khi nào thì hết hạn khóa để cho phép xóa?- Khi file backup được tạo ra, hệ thống sẽ gắn chặt một Metadata (Dữ liệu đặc tả) vào file đó, trong đó ghi rõ: Ngày khởi tạo và Thời gian khóa (ví dụ: Khóa 30 ngày).
- Metadata này được mã hóa và ký số để đảm bảo không ai có thể sửa đổi mốc thời gian này.
- Hệ thống lưu trữ sẽ đối chiếu thời gian của file với một đồng hồ hệ thống đáng tin cậy (NTP tin cậy) chứ không dựa vào đồng hồ hiển thị trên máy tính của bạn (để tránh việc hacker vặn ngược thời gian máy tính nhằm đánh lừa hệ thống).
Giải pháp can thiệp sâu (Chỉ áp dụng với một số hệ thống On-Premise)
Nếu đang sử dụng mô hình tự dựng Linux Hardened Repository (bản backup lưu trên máy chủ Linux do bạn quản lý) và tình huống cực kỳ khẩn cấp, có thể can thiệp bằng cách "phá vỡ" quy trình bảo mật từ gốc (tuy nhiên việc này làm mất đi ý nghĩa của Immutability):- Truy cập trực tiếp vào quyền Root của hệ điều hành Linux: Phần mềm backup (như NAKIVO/Veeam) không thể xóa file, nhưng nếu có quyền truy cập trực tiếp vào dòng lệnh (SSH) của máy chủ Linux với tư cách là root (hoặc tài khoản có quyền console tối cao), có thể gỡ bỏ thuộc tính bất biến của file bằng lệnh: sudo chattr -i /đường-dẫn-file-backup (hoặc -a tùy hệ thống). Sau khi gỡ thuộc tính này của hệ điều hành, bạn mới có thể dùng lệnh rm để xóa file thủ công nhằm giải phóng dung lượng.
- Lưu ý: Nếu bạn dùng Cloud (AWS S3 Compliance Mode) thì phương pháp can thiệp sâu để xoá như ở premiers thì nó lại gặp nhiều khó khăn hơn nhiều
2.1 Thực hành đối với S3 Object Lock
Kho lưu trữ S3 được cấu hình immutable
TH1: Xoá file nhưng mà xoá cả version ID
Khi BẬT "Show versions" và nhấn Xóa: Bạn đang chọn file gốc kèm theo versionId cụ thể của nó để yêu cầu S3 xoá nó vĩnh viễn. Lúc này, Object Lock (Compliance mode) sẽ chặn và báo lỗi Access Denied do chưa hết hạn immutable
TH2: Xoá không chưa version ID thì dữ liệu không bị xoá thực sự, chỉ bị đánh dâu là “delete marker” -> vẫn có thể khôi phục được
Khi KHÔNG bật "Show versions" và nhấn Xóa: Bạn không truyền lên versionId của file. AWS S3 hiểu là bạn chỉ muốn "ẩn" file này đi trong thư mục hiện tại. S3 sẽ tự động đặt một tấm biển mang tên Delete Marker lên trên cùng. File gốc của bạn vẫn được giữ an toàn và hoàn toàn khôi phục lại bình thường
"Deleting the specified objects adds delete markers to them" (Xóa các đối tượng đã chỉ định sẽ thêm các delete marker vào chúng)
khôi phục lại
