Quy tắc backup 3-2-1-1-0 và cách chống ransomware thực tế

Vì sao quy tắc 3-2-1 cũ đã không còn đủ

Quy tắc 3-2-1 ra đời từ thời mối đe doạ chính là hỏng ổ cứng, cháy nổ và lỗi con người. Ba bản dữ liệu, hai loại media, một bản off-site giải quyết rất tốt các sự cố vật lý. Nhưng ransomware hiện đại không phá hạ tầng, nó chờ đợi. Nhóm tấn công thường nằm vùng trung bình vài tuần trước khi kích hoạt mã hoá, dùng khoảng thời gian đó để lập bản đồ hệ thống, tìm máy chủ backup, xoá job và xoá repository. Khi bạn phát hiện ra thì cả ba bản sao đều đã nằm trong tầm với của kẻ tấn công.

Thực tế các vụ việc chúng tôi xử lý tại doanh nghiệp Việt Nam cho thấy điểm chết chung: máy chủ backup joined domain, tài khoản dịch vụ backup có quyền domain admin, repository là một share SMB nhìn thấy được từ mạng nội bộ. Chỉ cần một tài khoản quản trị bị chiếm là toàn bộ chuỗi bảo vệ sụp cùng lúc. Đó là lý do hai con số mới được thêm vào: một bản offline hoặc immutable, và không lỗi khi kiểm tra khôi phục.

Giải mã từng con số trong 3-2-1-1-0

Số 3 là ba bản dữ liệu, tính cả bản production đang chạy. Nhiều đội IT hiểu nhầm thành ba bản backup riêng, dẫn tới chi phí lưu trữ tăng gấp rưỡi không cần thiết. Số 2 là hai loại media khác nhau, ví dụ đĩa trên NAS và băng LTO, hoặc đĩa nội bộ và object storage đám mây. Mục tiêu là tránh lỗi cùng lô, cùng firmware, cùng cơ chế truy cập. Số 1 đầu tiên là một bản đặt ở vị trí địa lý khác, đủ xa để một sự cố cháy nổ hay ngập nước không cuốn theo cả hai nơi.

Số 1 thứ hai là bản offline, air-gap hoặc immutable. Đây là lớp phòng thủ quyết định trước ransomware, vì nó khiến dữ liệu không thể bị sửa hay xoá kể cả khi kẻ tấn công có quyền quản trị cao nhất. Số 0 cuối cùng là không lỗi khi kiểm tra khôi phục, tức mỗi bản backup phải được restore thử và xác nhận khởi động được, ứng dụng chạy được, dữ liệu đọc được. Một bản sao chưa từng khôi phục thử chỉ là một giả định, không phải một bản dự phòng.

• 3 bản dữ liệu: 1 production + 2 bản sao lưu độc lập
• 2 loại media: đĩa và băng, hoặc đĩa và object storage
• 1 bản off-site: khác toà nhà, tốt nhất khác tỉnh thành
• 1 bản immutable hoặc air-gap: không thể sửa, không thể xoá trong thời gian giữ
• 0 lỗi: mọi job phải qua kiểm tra khôi phục tự động hoặc thủ công định kỳ

Vì sao backup online bị mã hoá cùng production

Cơ chế lây lan rất đơn giản. Nếu repository backup là một thư mục chia sẻ SMB được mount trên máy chủ backup bằng tài khoản có quyền ghi, thì mã độc chạy dưới quyền tài khoản đó sẽ ghi đè file backup y hệt như ghi đè file người dùng. Với repository dạng NFS export mở cho toàn subnet, tình huống còn tệ hơn vì bất kỳ máy nào trong dải mạng cũng chạm được. Nhiều nhóm ransomware còn tích hợp sẵn module tìm và xoá file có phần mở rộng vbk, vib, bak, trước khi bắt đầu mã hoá dữ liệu chính.

Bước tiếp theo kẻ tấn công thường làm là đăng nhập vào console phần mềm backup bằng credential lưu trong trình duyệt hoặc trong file cấu hình, sau đó xoá job, xoá restore point và tắt lịch chạy. Có trường hợp họ giảm retention xuống một ngày rồi chờ hệ thống tự dọn dẹp các bản cũ, để lại rất ít dấu vết. Khi doanh nghiệp phát hiện, thứ còn lại chỉ là snapshot storage cũng đã bị xoá bằng chính quyền quản trị SAN.

Kết luận rút ra: mọi thứ mà tài khoản quản trị Windows domain chạm tới được đều phải coi là có thể mất trong một sự cố ransomware. Thiết kế backup phải bắt đầu từ giả định đó, chứ không phải từ giả định mạng nội bộ là vùng tin cậy. Thực tế khảo sát cho thấy phần lớn hệ sao lưu tại Việt Nam đều gắn NAS vào cùng domain với máy chủ sản xuất, dùng chung tài khoản dịch vụ và mở sẵn quyền ghi qua SMB. Cấu hình đó tiện cho vận hành nhưng biến kho sao lưu thành một thư mục nữa mà mã độc duyệt tới được. Việc cần làm ngay là liệt kê mọi đường mà tài khoản đặc quyền chạm tới repository, rồi cắt từng đường một.

Immutable repository và air-gap triển khai thế nào

Có hai hướng phổ biến và nên dùng song song. Hướng thứ nhất là object storage với S3 Object Lock ở chế độ Compliance, trong đó mỗi object được gắn thời hạn giữ và không ai xoá được trước hạn, kể cả tài khoản root của bucket. Hướng thứ hai là Veeam Hardened Repository, tức một máy chủ Linux cài trực tiếp, dùng filesystem XFS có reflink để tiết kiệm dung lượng nhờ block clone, và bật immutability flag ở mức file. Máy này không join domain, chỉ có một tài khoản single-use được tạo lúc cài đặt, SSH bị tắt sau khi cấu hình xong.

Air-gap đúng nghĩa là bản sao không có đường mạng tới hệ thống production trong phần lớn thời gian. Băng LTO rút ra khỏi thư viện và cất tủ chống cháy là dạng air-gap cổ điển nhưng vẫn hiệu quả, chi phí trên mỗi TB rất thấp nếu dữ liệu lưu trữ dài hạn. Với doanh nghiệp không muốn vận hành băng, một máy chủ repository chỉ bật nguồn theo lịch qua PDU điều khiển được cũng tạo ra cửa sổ tiếp xúc rất hẹp.

Về thời gian giữ, khuyến nghị thực dụng là immutable tối thiểu 14 ngày cho backup hàng ngày và 30 đến 90 ngày cho bản tuần hoặc tháng. Con số 14 ngày xuất phát từ thực tế thời gian nằm vùng của kẻ tấn công, đủ để bạn có một điểm khôi phục sạch trước khi payload được cài đặt. HQG thường cấu hình song song cả hardened repository tại chỗ và một tier object lock ở nhà cung cấp đám mây, để không phụ thuộc vào một lớp duy nhất.

• S3 Object Lock chế độ Compliance, không dùng Governance nếu muốn chống cả tài khoản quản trị
• Hardened Repository: Linux cài bare metal, XFS bật reflink, immutability flag, không join domain
• Tắt SSH và console truy cập từ xa sau khi cấu hình, chỉ mở khi bảo trì có kế hoạch
• Giữ immutable tối thiểu 14 ngày cho bản daily, 30 tới 90 ngày cho bản weekly và monthly
• Đồng bộ thời gian NTP đáng tin cậy, vì cơ chế immutability dựa hoàn toàn vào đồng hồ hệ thống

Tách credential và tách domain cho hạ tầng backup

Nguyên tắc là hạ tầng backup phải có ranh giới nhận dạng riêng. Máy chủ backup không join domain production, hoặc nếu buộc phải join thì đặt trong một forest quản trị tách biệt với quan hệ tin cậy một chiều. Tài khoản dịch vụ dùng cho job backup chỉ có quyền tối thiểu trên vCenter hoặc trên host, không phải domain admin. Console backup bật xác thực đa yếu tố, và quyền xoá restore point tách khỏi quyền tạo job, cần hai người phê duyệt cho các thao tác xoá hàng loạt.

Về mạng, nên đặt repository và máy chủ điều phối trong một VLAN quản trị riêng, chỉ cho phép các cổng cần thiết đi vào từ máy chủ proxy. Chặn hoàn toàn truy cập từ mạng người dùng cuối. Với môi trường có tường lửa Fortinet hoặc firewall của Cisco, việc này chỉ tốn vài policy nhưng loại bỏ được toàn bộ nhóm rủi ro lây lan ngang từ máy trạm nhân viên bị nhiễm.

Đừng quên lưu bản sao cấu hình phần mềm backup và khoá mã hoá ở nơi độc lập với chính hệ thống backup. Nhiều doanh nghiệp có dữ liệu nguyên vẹn nhưng không khôi phục được vì mất passphrase mã hoá lưu ngay trên máy chủ đã bị mã hoá. In ra giấy, cất két, và kiểm tra lại mỗi sáu tháng là biện pháp thô sơ nhưng cứu được nhiều tình huống.

Kiểm tra khôi phục: con số 0 khó nhất

Kiểm tra khôi phục là phần bị bỏ qua nhiều nhất vì tốn thời gian và không tạo ra kết quả nhìn thấy được khi mọi thứ bình thường. Với Veeam, SureBackup cho phép khởi động máy ảo từ chính file backup trong một sandbox mạng cách ly, chạy kiểm tra ping, kiểm tra cổng dịch vụ và script tuỳ chỉnh, rồi tự động tắt và ghi báo cáo. Cấu hình một virtual lab và lên lịch chạy hàng tuần cho nhóm máy chủ quan trọng là khoản đầu tư thời gian một lần nhưng trả lại giá trị mỗi tuần.

Ngoài kiểm tra tự động, mỗi quý nên có một buổi restore drill thủ công có tính giờ. Chọn ngẫu nhiên một hệ thống, khôi phục lên hạ tầng dự phòng, đo thời gian từ lúc bắt đầu tới lúc ứng dụng phục vụ được người dùng. Ghi lại con số thực tế và so với cam kết RTO. Gần như lần nào chạy lần đầu cũng phát hiện thiếu sót: thiếu tài liệu chuỗi khởi động dịch vụ, thiếu license, thiếu bản ghi DNS, hoặc thiếu người biết mật khẩu của một hệ thống cũ.

Một chỉ số nên theo dõi hàng tháng là tỷ lệ job thành công và tỷ lệ điểm khôi phục đã được verify. Nếu 98 phần trăm job báo xanh nhưng chỉ 20 phần trăm điểm khôi phục từng được kiểm tra, thì thực chất bạn chưa đạt số 0 trong quy tắc. Hai chỉ số này nên đưa vào báo cáo hạ tầng gửi ban lãnh đạo cùng với thời gian khôi phục đo được trong lần diễn tập gần nhất. Con số đo thật luôn thuyết phục hơn một cam kết trên giấy, và cũng là cơ sở tốt nhất để xin ngân sách bổ sung khi RTO thực tế đang cao hơn mức mà nghiệp vụ chấp nhận được.

• Lên lịch SureBackup hoặc kiểm tra tương đương hàng tuần cho nhóm hệ thống tier 1
• Restore drill thủ công có bấm giờ mỗi quý, luân phiên hệ thống
• Ghi biên bản mỗi lần drill: thời gian thực tế, vướng mắc, người thực hiện
• Theo dõi tỷ lệ restore point đã verify, đặt mục tiêu trên 90 phần trăm cho tier 1
• Kiểm tra khôi phục cả file đơn lẻ và cả toàn bộ máy, hai kịch bản khác nhau hoàn toàn

Đặt RTO và RPO theo mức độ quan trọng của hệ thống

RTO là thời gian tối đa chấp nhận được để khôi phục dịch vụ, RPO là lượng dữ liệu tối đa chấp nhận mất tính bằng thời gian. Hai con số này phải do lãnh đạo nghiệp vụ quyết, không phải do IT tự đặt. Cách làm hiệu quả là phân hệ thống thành ba nhóm. Nhóm 1 gồm ERP, cơ sở dữ liệu bán hàng, hệ thống thanh toán, nên đặt RTO 2 tới 4 giờ và RPO 15 tới 60 phút, nghĩa là cần replication hoặc backup log giao dịch liên tục chứ không chỉ backup đêm.

Nhóm 2 gồm file server, ứng dụng nội bộ, hệ thống báo cáo, RTO 8 tới 24 giờ và RPO 24 giờ là hợp lý, backup đêm một lần đáp ứng đủ. Nhóm 3 gồm máy trạm, môi trường test, dữ liệu lưu trữ, có thể chấp nhận RTO vài ngày và RPO một tuần. Việc phân nhóm giúp ngân sách đi đúng chỗ, thay vì mua giải pháp đắt tiền áp cho toàn bộ hệ thống rồi lại không đủ tiền làm off-site.

Lưu ý một cạm bẫy phổ biến: RTO trong kịch bản ransomware dài hơn nhiều so với RTO khi hỏng một máy chủ. Vì bạn phải điều tra phạm vi lây nhiễm, dựng lại hạ tầng sạch, đổi toàn bộ mật khẩu, rồi mới khôi phục dữ liệu. Nếu cam kết RTO 4 giờ, hãy tính riêng kịch bản này và cân nhắc chuẩn bị sẵn một cụm máy chủ dự phòng để không phải chờ mua thiết bị.

Checklist triển khai trong 30 ngày

Tuần đầu dành cho khảo sát và phân loại. Liệt kê toàn bộ hệ thống, xác định chủ sở hữu nghiệp vụ, thống nhất RTO và RPO cho từng nhóm, đo dung lượng dữ liệu thực tế và tốc độ tăng trưởng hàng tháng. Con số tăng trưởng quan trọng vì nó quyết định dung lượng repository cần mua cho 36 tháng tới, tránh tình trạng đầy đĩa sau một năm rồi phải cắt retention.

Tuần thứ hai dựng hạ tầng: cài hardened repository trên Linux, cấu hình XFS reflink và immutability, tạo bucket object lock ở nhà cung cấp đám mây, tách VLAN quản trị, dựng tài khoản dịch vụ quyền tối thiểu và bật MFA cho console. Tuần thứ ba chuyển job sang cấu trúc mới, chạy full backup lần đầu, kiểm tra băng thông và cửa sổ backup có nằm gọn trong khung giờ thấp điểm không.

Tuần cuối tập trung vào kiểm chứng và tài liệu. Chạy SureBackup cho toàn bộ tier 1, thực hiện một restore drill có bấm giờ, viết runbook khôi phục theo từng kịch bản, tập huấn cho ít nhất hai người trong đội để không phụ thuộc một cá nhân. Nếu đội IT của bạn thiếu người hoặc cần thiết bị repository, HQG có thể khảo sát tại chỗ và cho thuê máy chủ backup theo tháng để rút ngắn quá trình đầu tư ban đầu. Hotline 1900 636 106.

• Tuần 1: kiểm kê hệ thống, chốt RTO RPO, đo dung lượng và tốc độ tăng trưởng
• Tuần 2: dựng hardened repository, bucket object lock, tách VLAN và credential
• Tuần 3: chuyển job, chạy full backup, đo cửa sổ backup thực tế
• Tuần 4: SureBackup toàn bộ tier 1, một restore drill bấm giờ, viết runbook
• Sau 30 ngày: đưa các chỉ số job success và verify rate vào báo cáo vận hành hàng tháng