Sao lưu dữ liệu doanh nghiệp và khôi phục thảm họa: hướng dẫn cho SME

Sao lưu dữ liệu doanh nghiệp: câu trả lời ngắn

Sao lưu dữ liệu doanh nghiệp là giữ những bản sao độc lập của dữ liệu quan trọng, tách khỏi hệ thống đang chạy, để có thể khôi phục khi gặp lỗi người dùng, hỏng phần cứng, mã độc tống tiền (ransomware) hay hỏa hoạn. Khôi phục thảm họa (disaster recovery – DR) là kế hoạch và quy trình đưa hệ thống trở lại hoạt động từ các bản sao đó, trong thời gian và mức mất dữ liệu mà doanh nghiệp chấp nhận được.

Với doanh nghiệp vừa và nhỏ, một khung tối thiểu gồm bốn việc: áp dụng quy tắc 3-2-1, có ít nhất một bản sao ngoại tuyến hoặc bất biến, đặt mục tiêu RPO/RTO cho từng hệ thống, và thử khôi phục định kỳ. Bài viết đi qua từng việc, kèm bảng phân tầng và checklist runbook dùng được ngay. Nếu bạn đang chọn nơi đặt hệ thống, đọc thêm chọn kiến trúc cloud theo ràng buộc vận hành.

Quy tắc 3-2-1 và biến thể 3-2-1-1-0

Tài liệu Data Backup Options của US-CERT (nay thuộc CISA) nêu quy tắc 3-2-1: giữ 3 bản của mọi tệp quan trọng (1 bản chính và 2 bản sao lưu), lưu trên 2 loại phương tiện khác nhau để chống các loại rủi ro khác nhau, và giữ 1 bản ở ngoài cơ sở làm việc. Trang hướng dẫn sao lưu cho doanh nghiệp nhỏ và vừa của CISA tiếp tục gọi 3-2-1 là một nguyên tắc đáng tin cậy và khuyên kết hợp sao lưu tại chỗ với sao lưu từ xa.

Quy tắc 3-2-1 ra đời trước làn sóng ransomware. Vì vậy nhiều nhà cung cấp giải pháp sao lưu mở rộng thành 3-2-1-1-0: thêm 1 bản sao bất biến (immutable) hoặc cách ly (air-gapped), và 0 lỗi khi kiểm tra khôi phục. Đây là quy ước của ngành, không phải tiêu chuẩn do một cơ quan ban hành; điểm cốt lõi của nó trùng với khuyến nghị của CISA về bản sao ngoại tuyến và kiểm thử khôi phục.

RPO và RTO: hai con số quyết định thiết kế

Theo bảng thuật ngữ của NIST (SP 800-34 Rev. 1), RPO (Recovery Point Objective) là thời điểm mà dữ liệu phải được khôi phục về sau sự cố; nói đơn giản, đó là lượng dữ liệu tính theo thời gian mà doanh nghiệp chấp nhận mất. RTO (Recovery Time Objective) là tổng thời gian các thành phần của hệ thống được phép nằm trong giai đoạn khôi phục trước khi ảnh hưởng tiêu cực đến hoạt động; nói đơn giản, đó là thời gian ngừng tối đa chấp nhận được.

Ví dụ minh họa: nếu phần mềm bán hàng được sao lưu mỗi đêm lúc 23 giờ và sự cố xảy ra lúc 16 giờ hôm sau, bạn có thể mất khoảng 17 giờ dữ liệu. Nếu không chấp nhận được, RPO phải ngắn hơn, nghĩa là sao lưu dày hơn hoặc dùng sao chép liên tục. RPO và RTO càng ngắn thì chi phí và độ phức tạp càng cao, nên không phải hệ thống nào cũng cần mức cao nhất. CISA cũng khuyên doanh nghiệp kiểm thử khôi phục theo lịch để điều chỉnh RPO và RTO cho khớp với nhu cầu kinh doanh.

Ransomware: vì sao cần bản sao ngoại tuyến hoặc bất biến

Hướng dẫn #StopRansomware do CISA phối hợp cùng FBI, NSA và MS-ISAC phát hành khuyến nghị duy trì bản sao lưu ngoại tuyến, được mã hóa, cho dữ liệu trọng yếu, và thường xuyên kiểm tra tính sẵn sàng và toàn vẹn của bản sao trong kịch bản khôi phục thảm họa. Lý do được nêu rõ: nhiều biến thể ransomware tìm và xóa hoặc mã hóa các bản sao lưu truy cập được, khiến việc khôi phục bất khả thi nếu không trả tiền chuộc.

Cùng hướng dẫn đó gợi ý giữ "golden image" của hệ thống trọng yếu để dựng lại nhanh, lưu mẫu hạ tầng dưới dạng mã (IaC) ở nơi ngoại tuyến, bật quản lý phiên bản cho lưu trữ, và cân nhắc sao lưu cloud-to-cloud hoặc đa nhà cung cấp để tránh trường hợp mọi tài khoản trên cùng một nhà cung cấp bị ảnh hưởng. CISA cũng lưu ý lưu trữ bất biến cần dùng thận trọng vì có thể không đáp ứng một số yêu cầu tuân thủ và cấu hình sai có thể phát sinh chi phí lớn.

• Tách thông tin đăng nhập: tài khoản quản trị sao lưu không dùng chung với tài khoản quản trị hệ thống chính, có xác thực đa yếu tố.
• Bật khóa đối tượng (object lock) hoặc chính sách lưu giữ không xóa được trong khoảng thời gian xác định cho ít nhất một bản sao.
• Giữ một bản thực sự ngắt kết nối mạng nếu có thể, ví dụ ổ rời được luân chuyển theo lịch.
• Khi khôi phục sau tấn công, dựng lại trên vùng mạng sạch và kiểm tra bản sao trước khi nối lại, như CISA khuyến nghị, để không tái nhiễm.

SaaS có tự sao lưu cho bạn không? Mô hình trách nhiệm chia sẻ

Nhiều doanh nghiệp nghĩ dữ liệu trên Google Workspace hay Microsoft 365 đã "nằm trên cloud nên an toàn". Các tài liệu chính thức cho thấy cần phân biệt tính sẵn sàng của nền tảng với việc sao lưu dữ liệu của chính bạn.

Hướng dẫn bảo vệ dữ liệu Google Workspace (Google Cloud, 12/2020) mô tả mô hình trách nhiệm chia sẻ: khách hàng chịu trách nhiệm cho các thành phần mình cung cấp hoặc kiểm soát, như nội dung đưa vào dịch vụ và việc phân quyền truy cập cho người dùng. Ở mục sao lưu thông tin, tài liệu khuyên khách hàng có chính sách sao lưu, khôi phục và xác định RTO, RPO cho các hoạt động thiết yếu.

Phía Microsoft, trang Shared responsibility in the cloud trên Microsoft Learn nêu rằng với mọi loại triển khai cloud, khách hàng sở hữu dữ liệu và danh tính của mình và chịu trách nhiệm bảo vệ chúng. Tài liệu thực hành tốt nhất về Microsoft 365 Backup của Microsoft khuyên khách hàng xây dựng kế hoạch khôi phục vận hành và cân nhắc dùng dịch vụ Microsoft 365 Backup hoặc ứng dụng bên thứ ba được công nhận xây trên nền tảng lưu trữ sao lưu của Microsoft 365. Lưu ý: cùng tài liệu đó, Microsoft nói chung không khuyến nghị đưa khối lượng lớn dữ liệu ra ngoài Microsoft 365 và đề nghị cân nhắc kỹ yêu cầu bảo mật, tuân thủ, quyền riêng tư; dịch vụ Microsoft 365 Backup lưu bản sao trong phạm vi Microsoft 365 trên lưu trữ chỉ ghi thêm (append-only). Vì vậy, doanh nghiệp cần tự quyết định mức độ "độc lập" của bản sao dựa trên rủi ro của mình (ví dụ tài khoản quản trị bị chiếm) và yêu cầu tuân thủ.

Thử khôi phục: bản sao chưa thử là bản sao chưa chắc dùng được

Cả CISA và hướng dẫn #StopRansomware đều nhấn mạnh kiểm thử định kỳ. Một tác vụ sao lưu báo "thành công" chỉ cho biết dữ liệu đã được ghi đi; nó chưa chứng minh được dữ liệu đọc lại đúng, ứng dụng chạy được, và đội ngũ biết các bước làm.

Một buổi diễn tập khôi phục nên chọn ngẫu nhiên một bản sao (không chỉ bản mới nhất), khôi phục vào môi trường tách biệt, đo thời gian thực tế so với RTO, kiểm tra dữ liệu với người dùng nghiệp vụ, rồi ghi biên bản các điểm cần sửa. Tần suất diễn tập phụ thuộc vào tầng của hệ thống và mức thay đổi của hạ tầng; điều quan trọng là có lịch, có người chịu trách nhiệm và có biên bản.

Checklist runbook khôi phục thảm họa cho doanh nghiệp nhỏ

Runbook là tài liệu từng bước mà người trực có thể làm theo trong lúc căng thẳng. Bảng dưới đây là khung tối thiểu; hãy in ra một bản và lưu một bản ngoài hệ thống chính, vì khi sự cố xảy ra, wiki nội bộ có thể cũng không truy cập được.

Lộ trình 30 ngày bắt đầu từ con số không

Ví dụ minh họa cho một doanh nghiệp khoảng vài chục người dùng phần mềm kế toán, một ứng dụng bán hàng và một bộ công cụ văn phòng trên cloud:

• Tuần 1: kiểm kê dữ liệu và hệ thống, xếp tầng, thống nhất RPO/RTO với lãnh đạo.
• Tuần 2: bật sao lưu tự động cho từng hệ thống theo 3-2-1; thêm sao lưu độc lập cho dữ liệu SaaS.
• Tuần 3: thiết lập ít nhất một bản bất biến hoặc ngoại tuyến; tách tài khoản quản trị sao lưu, bật xác thực đa yếu tố.
• Tuần 4: viết runbook, diễn tập khôi phục một hệ thống tầng 1 và một hệ thống tầng 2, ghi biên bản và sửa lỗi phát hiện được.