Bản sao lưu chỉ có giá trị khi nó có thể khôi phục đúng dữ liệu vào một môi trường đáng tin cậy trong khoảng thời gian doanh nghiệp chấp nhận được.

Điều này nghe có vẻ hiển nhiên, nhưng nhiều tổ chức vẫn đo thành công bằng số công việc sao lưu đã hoàn tất. Trạng thái màu xanh chỉ chứng minh một công cụ đã ghi dữ liệu vào đâu đó. Nó không chứng minh bản sao có đủ mọi phần phụ thuộc, cơ sở dữ liệu nhất quán, khóa mã hóa còn dùng được, môi trường khôi phục có thể dựng lại hoặc đội ngũ có thể phục hồi dịch vụ trong sự cố thật.

Vì vậy, chiến lược sao lưu nghiêm túc là một hệ thống khôi phục, không phải một công việc lưu trữ. Hệ thống đó kết nối tác động kinh doanh, kiến trúc kỹ thuật, bảo mật, thời hạn lưu giữ, giám sát, kiểm thử, ứng phó sự cố và trách nhiệm rõ ràng.

Hướng dẫn này trình bày cách xây dựng hệ thống đó cho trang web doanh nghiệp, nền tảng thương mại điện tử, tác vụ đám mây, cơ sở dữ liệu, dữ liệu SaaS và hạ tầng hỗ trợ.

1. Bắt đầu từ kết quả khôi phục

Đừng bắt đầu bằng câu hỏi nên mua sản phẩm sao lưu nào. Hãy bắt đầu bằng bốn câu hỏi kinh doanh:

  1. Dịch vụ và dữ liệu nào thiết yếu?
  2. Doanh nghiệp có thể chấp nhận mất bao nhiêu dữ liệu mới phát sinh?
  3. Mỗi dịch vụ có thể ngừng hoạt động trong bao lâu?
  4. Kế hoạch khôi phục phải chịu được những loại lỗi và cuộc tấn công nào?

Câu trả lời sẽ quyết định tần suất, thời hạn lưu giữ, vị trí bản sao, phương pháp khôi phục, nhân sự và chi phí.

Trang giới thiệu doanh nghiệp và cửa hàng có lượng giao dịch lớn không nên dùng cùng một chính sách. Việc mất một ngày chỉnh sửa trên trang ít thay đổi có thể chấp nhận được. Mất một ngày đơn hàng, thanh toán, biến động kho, tin nhắn khách hàng hoặc lịch đặt chỗ thường không thể chấp nhận.

Hướng dẫn lập kế hoạch dự phòng của NIST xem mục tiêu khôi phục là kết quả của phân tích tác động kinh doanh. Thứ tự đó rất quan trọng. Khả năng chịu đựng của doanh nghiệp phải dẫn dắt lựa chọn công nghệ.

2. Hiểu các khái niệm quyết định chiến lược

Mục tiêu Điểm Khôi phục

Recovery Point Objective, viết tắt là RPO, là lượng dữ liệu tối đa có thể chấp nhận mất, được đo bằng thời gian.

RPO bằng 24 giờ nghĩa là doanh nghiệp chấp nhận việc khôi phục có thể đưa dữ liệu về thời điểm cách sự cố tối đa 24 giờ. RPO bằng 15 phút nghĩa là phải tạo điểm khôi phục đủ thường xuyên để trong tình huống đã xác định, lượng dữ liệu đã ghi nhận bị mất không vượt quá khoảng 15 phút.

RPO không tự động bằng tần suất sao lưu. Một công việc chạy mỗi 15 phút vẫn có thể không đạt mục tiêu nếu chạy quá lâu, thất bại mà không cảnh báo, sao chép dữ liệu thiếu nhất quán hoặc không thể khôi phục. Hãy đo tuổi của điểm khôi phục dùng được gần nhất.

Mục tiêu Thời gian Khôi phục

Recovery Time Objective, viết tắt là RTO, là thời gian gián đoạn tối đa có thể chấp nhận từ lúc dịch vụ ngừng đến lúc được phục hồi.

RTO không chỉ gồm thời gian truyền dữ liệu. Phát hiện, tuyên bố sự cố, phê duyệt, chuẩn bị môi trường, khôi phục thông tin xác thực, phục hồi dữ liệu, kiểm tra ứng dụng, đổi DNS, làm nóng bộ nhớ đệm và nghiệm thu của doanh nghiệp đều tiêu tốn thời gian.

Cam kết khôi phục cơ sở dữ liệu một terabyte trong hai giờ là vô nghĩa nếu chưa ai đo toàn bộ quy trình.

Thời gian ngừng hoạt động tối đa có thể chịu đựng

Đây là thời điểm mà sự gián đoạn bắt đầu gây thiệt hại không thể chấp nhận. RTO thường phải nằm bên trong giới hạn này để dành thời gian cho quyết định, phần phụ thuộc và yếu tố bất định.

Năng lực thời gian và điểm khôi phục

Mục tiêu cho biết doanh nghiệp cần gì. Năng lực cho biết hệ thống đã kiểm thử thực sự làm được gì. Hãy ghi lại cả hai.

Nếu doanh nghiệp cần RTO bốn giờ nhưng lần diễn tập gần nhất mất chín giờ, tổ chức đang có một khoảng cách khôi phục đã được đo. Tài liệu vẫn ghi bốn giờ không làm khoảng cách đó biến mất.

Thời hạn lưu giữ

Thời hạn lưu giữ cho biết điểm khôi phục tồn tại bao lâu. RPO trả lời điểm mới nhất phải gần đến mức nào. Thời hạn lưu giữ trả lời tổ chức có thể quay lại quá khứ xa đến đâu.

Sự khác biệt này rất quan trọng khi dữ liệu hỏng, truy cập trái phép hoặc lỗi ứng dụng không được phát hiện trong nhiều tuần.

3. Xác định các tình huống hỏng hóc

Mỗi loại lỗi cần một con đường khôi phục khác nhau. Hãy thiết kế và kiểm thử cho các tình huống như:

  • Vô tình xóa một tệp, bản ghi, hộp thư hoặc đối tượng
  • Triển khai hoặc chuyển đổi cơ sở dữ liệu thất bại
  • Dữ liệu hỏng lan vào các bản sao gần đây
  • Tài khoản quản trị bị xâm phạm
  • Mã độc tống tiền tấn công cả hệ thống chính và hệ thống sao lưu
  • Mất máy chủ, mảng lưu trữ, vùng sẵn sàng, khu vực hoặc văn phòng
  • Mất quyền truy cập tài khoản đám mây hoặc SaaS
  • Nhà cung cấp dịch vụ quản lý ngừng hoạt động
  • Người nội bộ thực hiện hành động phá hoại
  • Mất khóa mã hóa
  • Yêu cầu lưu giữ pháp lý hoặc truy xuất theo quy định
  • Phải dựng lại hoàn toàn trong môi trường sạch sau khi bị xâm phạm

Ảnh chụp nhanh cục bộ có thể phục hồi nhanh một tệp bị xóa nhầm. Cùng ảnh chụp đó có thể vô dụng nếu tài khoản đám mây bị khóa, khu vực ngừng hoạt động hoặc kẻ tấn công dùng chính danh tính quản trị để xóa mọi điểm khôi phục.

4. Kiểm kê những gì phải khôi phục

Hãy sao lưu dịch vụ kinh doanh, không chỉ sao lưu máy chủ. Với mỗi dịch vụ, cần lập bản đồ đầy đủ về tập hợp phải khôi phục.

Đối với một trang web điển hình, tập hợp đó có thể gồm:

  • Bản ghi cơ sở dữ liệu và nhật ký giao dịch
  • Nội dung tải lên và tài liệu được tạo
  • Mã ứng dụng không thể tái tạo từ nguồn khác
  • Giao diện, phần mở rộng, mô đun và phần tùy chỉnh
  • Cấu hình môi trường và ứng dụng
  • Hạ tầng dưới dạng mã và định nghĩa triển khai
  • Cấu hình máy chủ web, môi trường chạy, hàng đợi, bộ nhớ đệm và bộ lập lịch
  • Vùng DNS, thông tin chứng thư và cấu hình định tuyến
  • Bí mật hoặc cách đã kiểm thử để cấp lại bí mật
  • Khóa mã hóa và quy trình khôi phục khóa đã ghi thành tài liệu
  • Chỉ mục tìm kiếm nếu dựng lại sẽ vượt RTO
  • Kho đối tượng, vùng chia sẻ tệp và dữ liệu tích hợp bên ngoài
  • Nhật ký kiểm toán cần cho điều tra hoặc tuân thủ
  • Gói phần mềm, giấy phép và ảnh hệ thống chuẩn cần khi dựng lại
  • Tài liệu, danh sách liên hệ, sổ tay khôi phục và sơ đồ kiến trúc

Một số tài sản nên được tái tạo thay vì sao lưu. Bộ chứa ứng dụng dùng một lần có thể được dựng lại từ mã nguồn, ảnh đã ký và mã hạ tầng. Tuy nhiên, mã nguồn, kho sản phẩm biên dịch, cấu hình biên dịch, bí mật và phần phụ thuộc vẫn phải sẵn sàng.

Hãy ghi rõ nguồn nào là nguồn chính thức cho từng mục. Bản sao của chỉ mục tìm kiếm có thể không cần thiết nếu cơ sở dữ liệu là nguồn chính và chỉ mục có thể dựng lại trong RTO.

5. Phân loại dịch vụ theo tầng khôi phục

Một chính sách duy nhất cho mọi hệ thống thường quá đắt hoặc quá yếu. Hãy dùng các tầng khôi phục.

Tầng 1: quan trọng đối với doanh thu hoặc an toàn

Ví dụ gồm thanh toán, đơn hàng, đặt chỗ, cơ sở dữ liệu chính, danh tính khách hàng và API thiết yếu.

Các hệ thống này có thể cần điểm khôi phục sau mỗi vài phút, bảo vệ nhật ký giao dịch, khôi phục nhanh, bản sao bất biến, nơi lưu ở tài khoản hoặc khu vực khác và diễn tập thường xuyên.

Tầng 2: quan trọng với hoạt động kinh doanh

Ví dụ gồm trang thu thập khách hàng tiềm năng, cổng khách hàng, hệ thống nội dung, quy trình nội bộ hoặc kho tệp doanh nghiệp.

Các hệ thống này có thể dùng điểm khôi phục theo giờ hoặc hằng ngày, với khả năng phục hồi đã kiểm thử trong cùng ngày làm việc.

Tầng 3: có thể tái tạo hoặc ít thay đổi

Ví dụ gồm trang chiến dịch tĩnh, môi trường phát triển có thể dựng lại hoặc nội dung tham khảo đã lưu trữ.

Bản sao hằng ngày hoặc hằng tuần có thể đủ nếu cách tái tạo đã được ghi lại và kiểm thử.

Việc phân loại phải xét cả phần phụ thuộc. Một hệ thống thanh toán Tầng 1 phụ thuộc dịch vụ danh tính Tầng 3 thì thực tế chưa thể khôi phục ở Tầng 1.

6. Áp dụng đúng quy tắc 3 2 1

Quy tắc 3 2 1 cổ điển yêu cầu:

  • Giữ ba bản dữ liệu quan trọng, gồm cả bản đang vận hành
  • Dùng ít nhất hai loại phương tiện hoặc hai hệ thống lưu trữ độc lập
  • Đặt ít nhất một bản ở địa điểm khác

Quy tắc này xuất hiện trong hướng dẫn lựa chọn sao lưu dữ liệu của CISA. Đây vẫn là cách ghi nhớ hữu ích, nhưng chỉ là mẫu thiết kế tối thiểu, không phải bằng chứng rằng hệ thống có thể khôi phục.

Ba bản logic trong cùng một tài khoản đám mây có thể cùng chịu ảnh hưởng từ một danh tính bị xâm phạm. Hai tầng lưu trữ do cùng mặt phẳng điều khiển quản lý có thể cùng gặp một nguyên nhân lỗi. Bản sao ở nơi khác nhưng luôn cho phép hệ thống chính ghi vào vẫn có thể bị mã độc tống tiền xóa.

Mức độc lập quan trọng hơn số biểu tượng trên sơ đồ kiến trúc.

7. Hiểu các quy tắc mở rộng

Bạn có thể gặp quy tắc 3 2 1 1 0. Quy tắc này bổ sung một bản ngoại tuyến, cách ly vật lý hoặc bất biến và yêu cầu không còn lỗi sao lưu chưa được xác minh sau kiểm thử.

Một biến thể khác là 4 3 2, nhấn mạnh bốn bản, ba vị trí và hai vị trí nằm ngoài môi trường chính. Tổ chức lớn có thể dùng nhiều mẫu khác.

Đây là các cách ghi nhớ hữu ích, không phải tiêu chuẩn áp dụng cho mọi nơi. Đừng mua thêm dung lượng chỉ để tăng số bản mà chưa đánh giá quyền quản trị có độc lập không, bản sao có được bảo vệ khỏi xóa không, có đủ mới không, được giữ đủ lâu không và có thể phục hồi trong thời gian mục tiêu không.

Cách diễn giải hiện đại và thực tế gồm:

  1. Duy trì nhiều điểm khôi phục.
  2. Tách ít nhất một bản khỏi danh tính và quyền quản trị hệ thống chính.
  3. Bảo vệ ít nhất một bản trước việc sửa đổi và xóa sớm.
  4. Giữ một bản độc lập về địa lý cho thảm họa tại cơ sở hoặc khu vực.
  5. Liên tục giám sát tình trạng sao lưu.
  6. Chứng minh khả năng khôi phục bằng việc phục hồi và kiểm tra ứng dụng.

8. Chọn đúng phương pháp sao lưu

Không phương pháp đơn lẻ nào giải quyết mọi bài toán khôi phục.

Sao lưu toàn phần

Sao lưu toàn phần chép toàn bộ tập dữ liệu đã chọn. Khôi phục đơn giản nhưng thời gian sao lưu, dung lượng và tải mạng có thể lớn.

Nên tạo bản toàn phần định kỳ làm mốc khi nền tảng và kích thước dữ liệu cho phép.

Sao lưu gia tăng

Sao lưu gia tăng ghi lại thay đổi kể từ lần sao lưu trước. Cách này giảm thời gian và dung lượng sao chép nhưng có thể cần nhiều bước hơn khi khôi phục.

Cách triển khai khác nhau tùy nền tảng. Một số hệ thống tổng hợp dữ liệu gia tăng thành điểm khôi phục toàn phần mới.

Sao lưu sai khác

Sao lưu sai khác ghi lại thay đổi kể từ bản toàn phần gần nhất. Quá trình khôi phục thường cần bản toàn phần cuối cùng và bản sai khác đã chọn. Dung lượng tăng dần cho đến lần sao lưu toàn phần tiếp theo.

Ảnh chụp nhanh

Ảnh chụp nhanh ghi lại trạng thái ổ đĩa, máy ảo, cơ sở dữ liệu hoặc dịch vụ tại một thời điểm. Cơ chế này có thể nhanh và tiết kiệm dung lượng nhưng không tự động trở thành bản sao độc lập.

Hãy chép ảnh quan trọng sang kho, tài khoản, gói đăng ký, dự án hoặc khu vực được bảo vệ riêng. Xác nhận ảnh chỉ nhất quán ở mức máy gặp sự cố hay nhất quán ở mức ứng dụng.

Nhật ký giao dịch và khôi phục đến một thời điểm

Nhật ký giao dịch của cơ sở dữ liệu cho phép phục hồi đến thời điểm nằm giữa các bản toàn phần hoặc gia tăng. Cơ chế này thường cần thiết cho hệ thống có RPO thấp.

Hãy kiểm thử toàn bộ chuỗi nhật ký. Chỉ một đoạn bị thiếu hoặc hỏng cũng có thể ngăn việc khôi phục đến thời điểm mong muốn.

Bảo vệ dữ liệu liên tục

Bảo vệ dữ liệu liên tục ghi lại thay đổi với tần suất cao và có thể cung cấp nhiều điểm khôi phục. Cách này cải thiện RPO nhưng vẫn cần hoạch định dung lượng, kiểm soát tính nhất quán và bảo vệ trước việc dữ liệu hỏng lan rộng.

Nhân bản

Nhân bản hỗ trợ tính sẵn sàng và chuyển đổi nhanh bằng cách chép dữ liệu sang hệ thống khác. Nó không thay thế sao lưu vì thao tác xóa, dữ liệu hỏng hoặc thay đổi độc hại cũng có thể được nhân bản.

Hãy dùng nhân bản cho hoạt động liên tục và dùng bản sao có phiên bản, được bảo vệ cho khôi phục lịch sử.

Xuất dữ liệu

Xuất dữ liệu ở mức ứng dụng có thể tăng khả năng di chuyển. Ví dụ gồm kết xuất cơ sở dữ liệu, nội dung, bản ghi tài khoản hoặc dữ liệu SaaS.

Tệp xuất có thể thiếu siêu dữ liệu, quyền, quan hệ, lịch sử hoặc tệp lớn. Cần ghi rõ nó chứa gì và nhập lại như thế nào.

9. Đặt tần suất sao lưu từ RPO

Tần suất phải bám theo tốc độ thay đổi và thiệt hại kinh doanh, không theo nhãn chung như doanh nghiệp nhỏ.

Mô hình khởi đầu hợp lý có thể là:

  • Trang giới thiệu hầu như tĩnh: sao lưu cơ sở dữ liệu và tệp hằng ngày, cùng một bản trước mỗi thay đổi lớn
  • Trang xuất bản thường xuyên: sao lưu sau mỗi vài giờ, với điểm hằng ngày được bảo vệ
  • Trang thu thập khách hàng tiềm năng: bảo vệ đầy đủ hằng ngày, cùng tần suất cao hơn cho dữ liệu biểu mẫu nếu dữ liệu đó không được chuyển sang hệ thống chính thức khác
  • Cửa hàng trực tuyến: điểm khôi phục cơ sở dữ liệu thường xuyên, thường sau mỗi 5 đến 15 phút hoặc dùng nhật ký giao dịch liên tục, cùng bản sao tệp và cấu hình hằng ngày
  • Nền tảng đặt chỗ hoặc thành viên: tần suất dựa trên số giao dịch và chi phí tái tạo bản ghi
  • API hoặc nền tảng SaaS thiết yếu: bảo vệ liên tục hoặc gần liên tục khi doanh nghiệp không thể tái tạo giao dịch đã ghi nhận

Đây là ví dụ, không phải cam kết. Hãy đo tuổi thật của điểm khôi phục và thời gian chạy công việc. Hướng dẫn sao lưu của AWS cũng khuyến nghị căn tần suất theo RPO và tạo một bản tại thời điểm trước thay đổi quan trọng.

10. Thiết kế thời hạn lưu giữ cho cả vận hành và tấn công

Thời hạn lưu giữ phải hỗ trợ khôi phục vận hành nhanh và xử lý sự cố bị phát hiện muộn.

Một mẫu phổ biến gồm:

  • Các điểm thường xuyên trong 24 đến 72 giờ
  • Điểm hằng ngày trong 14 đến 35 ngày
  • Điểm hằng tuần trong 8 đến 12 tuần
  • Điểm hằng tháng trong 12 đến 24 tháng
  • Bản lưu hằng năm chỉ khi yêu cầu pháp lý, hợp đồng hoặc kinh doanh thật sự cần

Đừng sao chép lịch này một cách máy móc. Cơ sở dữ liệu thay đổi nhiều có thể cần điểm dày hơn. Dữ liệu cá nhân có thể cần thời hạn ngắn hơn. Hồ sơ tài chính hoặc dữ liệu chịu quản lý có thể cần được giữ lâu hơn.

Lưu giữ tạo ra nghĩa vụ bên cạnh sự an toàn. Bản sao có thể chứa dữ liệu cá nhân, bí mật, tài khoản đã xóa và phần mềm cũ có lỗ hổng. Hãy cùng nhóm pháp lý và quyền riêng tư có chuyên môn xác định căn cứ lưu giữ, quyền truy cập, mã hóa, tiêu hủy, lưu giữ phục vụ tố tụng và xử lý yêu cầu của chủ thể dữ liệu.

11. Dùng vòng quay ngày, tuần, tháng khi phù hợp

Mô hình thường được gọi là grandfather, father, son giữ các thế hệ hằng ngày, hằng tuần và hằng tháng. Mô hình cung cấp nhiều lựa chọn gần đây cùng một số điểm dài hạn mà không phải giữ mọi bản mãi mãi.

Hệ thống hiện đại thực hiện logic tương tự qua chính sách vòng đời. Tên gọi ít quan trọng hơn mục tiêu:

  • Đủ điểm gần đây cho sai sót vận hành
  • Đủ chiều sâu lịch sử cho xâm phạm hoặc dữ liệu hỏng bị phát hiện muộn
  • Chi phí có thể dự đoán
  • Bản dài hạn được bảo vệ khi cần
  • Hết hạn tự động và có thể kiểm toán

Không được rút ngắn thời hạn lưu giữ trong sự cố cho đến khi nhóm ứng phó xác nhận những điểm phải bảo toàn.

12. Tạo một bản bất biến hoặc ngoại tuyến

Kẻ vận hành mã độc tống tiền thường tấn công hệ thống sao lưu trước khi mã hóa hệ thống chính. CISA khuyến nghị giữ bản ngoại tuyến có mã hóa và thường xuyên kiểm thử tính sẵn sàng cùng toàn vẹn.

Các biện pháp hữu ích gồm:

  • Kho chỉ ghi một lần và đọc nhiều lần
  • Thời hạn lưu giữ đối tượng đã khóa
  • Kho sao lưu bất biến
  • Băng từ hoặc phương tiện tháo rời được cất an toàn
  • Kho nằm trong tài khoản khác với quản trị viên độc lập
  • Yêu cầu nhiều người phê duyệt thao tác phá hủy
  • Xóa mềm với khoảng thời gian khôi phục được bảo vệ
  • Trì hoãn xóa và cảnh báo khi chính sách thay đổi

Tính bất biến phải được khóa thì mới có ý nghĩa trước quản trị viên bị xâm phạm. Tính năng mà cùng quản trị viên có thể tắt ngay lập tức chỉ bảo vệ khỏi sai sót, không đủ chống kẻ tấn công quyết tâm.

Bản ngoại tuyến cũng cần kỷ luật vận hành. Phương tiện phải được mã hóa, kiểm kê, luân chuyển, vận chuyển an toàn, kiểm thử và tiêu hủy an toàn khi hết vòng đời.

Nguyên tắc sao lưu chống mã độc tống tiền của NCSC tại Vương quốc Anh nhấn mạnh hệ thống sao lưu cần được bảo vệ vì kẻ tấn công phá hoại thường nhắm đến nó từ sớm.

13. Tách danh tính và quyền quản trị sao lưu

Hệ thống sao lưu là một ranh giới bảo mật đặc quyền. Hãy bảo vệ nó tương xứng.

  • Dùng vai trò quản trị sao lưu riêng
  • Không dùng lại thông tin xác thực quản trị hệ thống chính
  • Yêu cầu MFA chống lừa đảo cho truy cập đặc quyền
  • Cấp quyền đúng lúc nếu nền tảng hỗ trợ
  • Tách tài khoản, gói đăng ký, dự án hoặc không gian thuê sao lưu khỏi hệ thống chính
  • Không cho tác vụ chính quyền xóa điểm khôi phục
  • Hạn chế quyền phục hồi vì bản sao chứa dữ liệu nhạy cảm
  • Yêu cầu phê duyệt bổ sung khi giảm thời hạn, xóa kho hoặc thay đổi tính bất biến
  • Gửi nhật ký và cảnh báo bảo mật đến nơi ngoài ranh giới tin cậy của hệ thống chính
  • Duy trì quyền truy cập khẩn cấp đã kiểm thử, được giám sát và cất giữ an toàn

Tài khoản dịch vụ chỉ nên có quyền cần thiết để tạo và đọc đúng bản sao. Nó không nên có quyền rộng để tắt nhật ký, đổi thời hạn hoặc phá hủy kho.

14. Mã hóa bản sao và bảo vệ khóa

Hãy mã hóa khi truyền và khi lưu. Sau đó thiết kế cho tình huống hệ thống quản lý khóa thông thường không hoạt động trong lúc khôi phục.

Cần ghi thành tài liệu:

  • Khóa nào bảo vệ tập bản sao nào
  • Ai có thể dùng, luân chuyển, vô hiệu hóa và khôi phục khóa
  • Khóa có dùng chung tài khoản hoặc khu vực với hệ thống chính không
  • Quyền dùng khóa khẩn cấp được phê duyệt và kiểm toán thế nào
  • Khóa được sao lưu hoặc ký gửi ra sao khi phù hợp
  • Cách kiểm thử khôi phục sau khi luân chuyển khóa
  • Điều gì xảy ra khi nhân viên, nhà cung cấp hoặc mô đun bảo mật phần cứng không sẵn sàng

Mã hóa mà không thể khôi phục khóa chính là xóa dữ liệu vĩnh viễn. Kiểm soát truy cập khóa yếu cũng có thể cho phép kẻ tấn công giải mã dữ liệu lịch sử nhạy cảm.

15. Tạo bản cơ sở dữ liệu nhất quán ở mức ứng dụng

Chép tệp cơ sở dữ liệu khi hệ thống đang chạy có thể tạo ra điểm khôi phục thiếu nhất quán nếu nền tảng không điều phối đúng các thao tác ghi.

Hãy dùng chức năng sao lưu gốc của cơ sở dữ liệu, dịch vụ khôi phục đến một thời điểm, cơ chế đóng băng hệ thống tệp, tích hợp ảnh chụp ổ đĩa hoặc phương pháp nhất quán ở mức ứng dụng đã được ghi nhận.

Với hệ thống giao dịch, cần kiểm thử:

  • Khôi phục bản toàn phần
  • Khôi phục bản gia tăng hoặc sai khác
  • Phát lại nhật ký đến một mốc thời gian đã chọn
  • Khôi phục sang máy chủ hoặc tài khoản mới
  • Phục hồi sau chuyển đổi lược đồ
  • Kiểm tra toàn vẹn và truy vấn ứng dụng sau phục hồi
  • Xử lý hàng đợi, chỉ mục tìm kiếm, bộ nhớ đệm và tác động bên ngoài

Cần cẩn trọng khi phát lại giao dịch liên quan thanh toán, thư điện tử, tồn kho và webhook. Hệ thống vừa khôi phục có thể gửi lại thông báo hoặc lặp hành động nếu chưa tạm dừng tích hợp và chưa hiểu rõ tính bất biến của giao dịch.

16. Chủ động sao lưu dữ liệu đám mây và SaaS

Độ bền của đám mây không đồng nghĩa với bản sao lưu của khách hàng. Nhà cung cấp có thể bảo vệ hạ tầng, trong khi khách hàng vẫn chịu trách nhiệm về thời hạn lưu giữ, xóa nhầm, quản trị viên độc hại, lỗi ứng dụng, đóng tài khoản và xuất dữ liệu theo quy định.

Với mỗi cơ sở dữ liệu được quản lý, kho đối tượng, kho mã, nền tảng thư điện tử, CRM và sản phẩm SaaS, hãy hỏi:

  1. Nhà cung cấp tự động bảo vệ phần nào?
  2. Quản trị viên của khách hàng có thể xóa gì?
  3. Lịch sử phiên bản gốc tồn tại bao lâu?
  4. Điểm khôi phục có thể chép sang tài khoản hoặc nhà cung cấp khác không?
  5. Dữ liệu có thể xuất đầy đủ ở định dạng dùng được không?
  6. Quyền, siêu dữ liệu, bình luận, lịch sử và tệp đính kèm có được bao gồm không?
  7. Khôi phục lượng dữ liệu lớn mất bao lâu?
  8. Điều gì xảy ra khi gói dịch vụ bị đình chỉ hoặc nhà cung cấp thất bại?

Đừng nhầm đồng bộ với sao lưu. Nếu người dùng hoặc kẻ tấn công xóa một tệp được đồng bộ, thao tác xóa đó có thể lan ra mọi nơi.

17. Bảo vệ các phần phụ thuộc của trang web và thương mại điện tử

Với WordPress, Magento, WooCommerce và các hệ thống nội dung hoặc thương mại khác, tập hợp khôi phục dùng được thường cần nhiều hơn một tệp kết xuất cơ sở dữ liệu.

Cần bao gồm:

  • Cơ sở dữ liệu và nhật ký giao dịch nếu có
  • Nội dung người dùng tải lên và hình ảnh sản phẩm
  • Mã ứng dụng, mô đun tùy chỉnh, giao diện và tệp khóa phần phụ thuộc
  • Cấu hình máy chủ web và môi trường chạy
  • Công việc theo lịch, bộ xử lý hàng đợi và cấu hình tìm kiếm
  • Cài đặt tích hợp thanh toán, vận chuyển, thuế, thư điện tử và danh tính
  • Bản ghi DNS và thông tin khôi phục chứng thư
  • Cấu hình môi trường và cách an toàn để cấp lại bí mật
  • Định nghĩa hạ tầng và hướng dẫn triển khai

Không cần sao lưu bộ nhớ đệm dùng một lần, trừ khi dựng lại sẽ phá RTO. Không đưa mã độc đã biết, tệp lưu trữ tạm hoặc bản sao nằm công khai vào tập phục hồi.

Trước bản cập nhật lớn, hãy tạo một điểm khôi phục đã biết. Sau cập nhật, giữ điểm cũ cho đến khi mọi kiểm tra chức năng đều đạt.

18. Giám sát tình trạng sao lưu, không chỉ trạng thái hoàn tất

Hệ thống giám sát cần phát hiện:

  • Công việc thất bại, bị bỏ lỡ, chậm hoặc kéo dài bất thường
  • Tuổi của điểm khôi phục dùng được gần nhất
  • Kích thước hoặc số mục thay đổi bất thường
  • Chuỗi nhật ký giao dịch bị đứt
  • Nguy cơ hết dung lượng hoặc vượt hạn mức
  • Sao chép sang khu vực khác thất bại
  • Lỗi mã hóa hoặc truy cập khóa
  • Chính sách bị tắt và thời hạn bị giảm
  • Nỗ lực xóa và thay đổi cấu hình kho
  • Tài sản mới chưa thuộc chính sách nào
  • Kiểm thử khôi phục quá hạn hoặc thất bại

Gửi cảnh báo cho người chịu trách nhiệm và theo dõi đến khi xử lý xong. Cảnh báo không ai đọc trong chính tài khoản bị xâm phạm không phải biện pháp kiểm soát hiệu quả.

19. Kiểm chứng tính toàn vẹn theo nhiều cấp

Việc kiểm chứng nên đi từ kiểm tra rẻ và thường xuyên đến diễn tập hoàn chỉnh.

Cấp 1: kiểm tra công việc và danh mục

Xác nhận công việc đã chạy, danh mục đọc được, tài sản dự kiến đã được bảo vệ và chính sách lưu giữ đang hoạt động.

Cấp 2: kiểm tra mật mã và cấu trúc

Xác minh giá trị băm, tính toàn vẹn đối tượng, khả năng đọc tệp lưu trữ, phép kiểm tra bản sao cơ sở dữ liệu và tính liên tục của nhật ký giao dịch.

Cấp 3: khôi phục mẫu

Tự động phục hồi một số tệp, đối tượng, bản ghi hoặc cơ sở dữ liệu nhỏ vào môi trường cô lập.

Cấp 4: khôi phục ứng dụng

Khôi phục toàn bộ ứng dụng cùng phần phụ thuộc, khởi động, chạy kiểm tra chức năng và đo tổng thời gian.

Cấp 5: diễn tập khôi phục

Mô phỏng một sự cố hoặc xâm phạm thực tế. Dùng đúng sổ tay, đường liên lạc, quy trình phê duyệt, thông tin xác thực sạch, môi trường thay thế và tiêu chí nghiệm thu kinh doanh.

AWS Well Architected Framework khuyến nghị phục hồi định kỳ để kiểm chứng cả tính toàn vẹn của bản sao lẫn quy trình khôi phục.

20. Kiểm thử khôi phục mà không tin hệ thống nguồn

Trong sự cố bảo mật, bản sao mới nhất có thể đã chứa mã độc, bản ghi hỏng, khóa bị lộ hoặc tài khoản trái phép.

Quy trình khôi phục sạch nên:

  1. Bảo toàn bằng chứng và phối hợp với người chỉ huy ứng phó sự cố.
  2. Xác định khoảng thời gian có khả năng bị xâm phạm.
  3. Chọn các điểm khôi phục ứng viên trước khoảng thời gian đó.
  4. Phục hồi vào môi trường cô lập và đáng tin cậy.
  5. Quét tệp và kiểm tra tính toàn vẹn phần mềm.
  6. Vá điểm xâm nhập trước khi nối lại dịch vụ.
  7. Luân chuyển thông tin xác thực, mã truy cập, chứng thư và khóa có thể đã lộ.
  8. Rà soát tài khoản, công việc theo lịch, tích hợp, cơ chế khởi động và lưu lượng đi ra.
  9. Kiểm tra dữ liệu và luồng kinh doanh quan trọng.
  10. Kết nối lại theo từng giai đoạn với mức giám sát cao hơn.

Phục hồi một ảnh đã bị xâm phạm có thể dựng lại kẻ tấn công nhanh hơn dựng lại dịch vụ.

21. Viết sổ tay khôi phục để người khác cũng thực hiện được

Sổ tay hữu ích cần có:

  • Phạm vi và người sở hữu dịch vụ
  • Mức ưu tiên kinh doanh, RPO, RTO và thời gian ngừng tối đa
  • Phần phụ thuộc và thứ tự khôi phục
  • Vị trí bản sao, ranh giới tài khoản và thời hạn lưu giữ
  • Vai trò cần thiết và đầu mối phê duyệt
  • Quy trình khôi phục thông tin xác thực cùng khóa khẩn cấp
  • Các bước phục hồi chính xác
  • Điều kiện về dung lượng và mạng
  • Các bước với DNS, chứng thư, hàng đợi, bộ nhớ đệm và tích hợp
  • Kiểm tra bảo mật trước khi kết nối lại
  • Kiểm tra chức năng và tiêu chí nghiệm thu kinh doanh
  • Các bước liên lạc và chuyển cấp
  • Con đường quay lui hoặc khôi phục thay thế
  • Bằng chứng cần thu trong diễn tập
  • Ngày, kết quả và người phụ trách lần kiểm thử tiếp theo

Hãy giữ một bản ngoại tuyến hoặc có thể truy cập độc lập của sổ tay cùng thông tin liên hệ quan trọng. Tài liệu chỉ nằm trong hệ thống đang ngừng hoạt động sẽ không giúp ích.

22. Đo năng lực thật

Các chỉ số hữu ích gồm:

  • Tỷ lệ tài sản trong phạm vi được bảo vệ bằng chính sách đã phê duyệt
  • Tỷ lệ tài sản đạt RPO thực tế
  • Tuổi của điểm khôi phục dùng được gần nhất
  • Tỷ lệ công việc thành công sau khi loại trừ lượt chạy lại
  • Tỷ lệ kiểm thử phục hồi thành công
  • Thời gian khôi phục thực tế theo dịch vụ
  • Điểm dữ liệu thực tế đạt được trong diễn tập
  • Số bài kiểm thử quá hạn
  • Số phần phụ thuộc quan trọng chưa được bảo vệ
  • Thời gian điều tra công việc thất bại
  • Mức bao phủ của lưu giữ bất biến
  • Số người có thể thực hiện từng quy trình khôi phục quan trọng
  • Khoảng cách giữa mục tiêu và năng lực đã kiểm thử

Tránh chỉ số đẹp nhưng rỗng. Tỷ lệ thành công 99,9 phần trăm có thể che giấu một cơ sở dữ liệu quan trọng chưa từng có bản dùng được.

23. Phân công trách nhiệm rõ ràng

Công việc sao lưu liên quan nhóm kinh doanh, ứng dụng, hạ tầng, bảo mật, pháp lý và tài chính.

Mô hình trách nhiệm đơn giản cần xác định:

  • Người sở hữu kinh doanh phê duyệt mức mất dữ liệu và thời gian ngừng chấp nhận được
  • Người sở hữu dịch vụ xác định phạm vi và xác nhận ứng dụng đã khôi phục
  • Người vận hành chạy và giám sát nền tảng sao lưu
  • Người phụ trách bảo mật bảo vệ danh tính, kho, nhật ký và quy trình phục hồi sự cố
  • Người phụ trách quyền riêng tư hoặc pháp lý xác định nghĩa vụ lưu giữ cùng xóa
  • Người chỉ huy sự cố phê duyệt phục hồi khi có xâm phạm
  • Người ghi nhận bằng chứng kiểm thử và theo dõi khoảng trống

Nhà cung cấp quản lý có thể vận hành sao lưu, nhưng khách hàng vẫn phải hiểu phạm vi, bằng chứng, mục tiêu khôi phục, phần loại trừ và quy trình chấm dứt dịch vụ.

24. Tránh những lỗi sao lưu phổ biến nhất

Giữ mọi bản trên máy chủ chính

Mất máy chủ, bị xâm phạm hoặc đình chỉ tài khoản sẽ làm mất cả hệ thống chính lẫn bản sao.

Xem RAID là sao lưu

RAID tăng tính sẵn sàng khi một số ổ đĩa hỏng. Nó không cung cấp phiên bản lịch sử và không bảo vệ khỏi xóa, dữ liệu hỏng, mã độc tống tiền hoặc mất cả cơ sở.

Xem đồng bộ là sao lưu

Đồng bộ có thể lan truyền thay đổi không mong muốn. Vẫn cần lịch sử phiên bản và thời hạn độc lập.

Xem nhân bản là sao lưu

Nhân bản có thể chép rất nhanh dữ liệu hỏng và thao tác phá hủy. Cần giữ các điểm lịch sử được bảo vệ.

Bảo vệ dữ liệu nhưng bỏ quên cấu hình

Chỉ cơ sở dữ liệu có thể không đủ để phục hồi ứng dụng, mạng, danh tính, chứng thư, tích hợp và môi trường triển khai.

Dùng cùng quản trị viên ở mọi nơi

Một danh tính bị đánh cắp có thể phá hủy hệ thống chính và mọi điểm khôi phục.

Giữ lịch sử quá ngắn

Nhóm phát hiện xâm phạm sau khi mọi điểm sạch đã hết hạn.

Giữ mọi thứ mãi mãi

Chi phí, mức lộ quyền riêng tư, nghĩa vụ cung cấp chứng cứ và dữ liệu lịch sử có lỗ hổng đều tăng mà không có mục đích rõ.

Không bao giờ kiểm thử khôi phục lớn

Băng thông, giới hạn API, độ trễ truy xuất kho lưu trữ, thời gian đưa dữ liệu trở lại và bước xác nhận khiến RTO thực tế dài hơn nhiều so với dự đoán.

Phục hồi đè trực tiếp lên hệ thống chính

Việc này có thể phá bằng chứng, loại bỏ đường quay lui và lan truyền xâm phạm ẩn. Khi tình huống cho phép, hãy phục hồi vào môi trường cô lập trước.

25. Ví dụ chính sách thực tế

Mẫu sau là điểm khởi đầu cho một trang web doanh nghiệp đang hoạt động, không phải yêu cầu chung cho mọi tổ chức:

  • Điểm khôi phục cơ sở dữ liệu chính mỗi 15 phút
  • Bản cơ sở dữ liệu nhất quán ở mức ứng dụng mỗi ngày
  • Bản sao tệp và kho đối tượng mỗi ngày
  • Điểm khôi phục trước mọi bản phát hành hoặc chuyển đổi quan trọng
  • Giữ các điểm thường xuyên trong bảy ngày
  • Giữ điểm hằng ngày trong 35 ngày
  • Giữ điểm hằng tháng trong 12 tháng khi yêu cầu quyền riêng tư và pháp lý cho phép
  • Một bản bất biến trong kho được quản trị riêng
  • Một bản độc lập về địa lý cho dịch vụ quan trọng
  • Mã hóa khi truyền và khi lưu
  • MFA chống lừa đảo và quyền quản trị sao lưu tách biệt
  • Rà soát cảnh báo hằng ngày
  • Khôi phục mẫu hằng tháng
  • Diễn tập khôi phục toàn bộ ứng dụng mỗi quý
  • Diễn tập tình huống hằng năm với người phụ trách kinh doanh, kỹ thuật, bảo mật và truyền thông
  • Kiểm thử sau thay đổi lớn về kiến trúc, nhà cung cấp, mã hóa hoặc công cụ khôi phục

Mỗi dòng phải có người phụ trách, nguồn bằng chứng, quy trình ngoại lệ và ngày rà soát.

26. Kế hoạch triển khai trong 90 ngày

Ngày 1 đến 30: khám phá và ưu tiên

  1. Kiểm kê hệ thống, dữ liệu, nhà cung cấp và phần phụ thuộc.
  2. Chỉ định người sở hữu dịch vụ và kinh doanh.
  3. Xác định tầng khôi phục, RPO, RTO và thời hạn lưu giữ.
  4. Tìm tài sản bị bỏ sót và điểm lỗi đơn lẻ.
  5. Xác nhận bản sao hiện có nằm ở đâu và ai có thể xóa.
  6. Khắc phục ngay công việc thất bại và tệp sao lưu bị công khai.

Ngày 31 đến 60: bảo vệ và tự động hóa

  1. Áp dụng chính sách tự động theo từng tầng.
  2. Tạo một bản ở địa điểm khác với quyền quản trị tách biệt.
  3. Khóa thời hạn bất biến cho điểm quan trọng sau khi kiểm thử thiết lập chính sách.
  4. Tách danh tính và yêu cầu MFA mạnh.
  5. Mã hóa bản sao và ghi lại cách khôi phục khóa.
  6. Tập trung hóa cảnh báo cùng nhật ký thay đổi cấu hình.
  7. Viết sổ tay khôi phục cho các dịch vụ quan trọng nhất.

Ngày 61 đến 90: phục hồi và chứng minh

  1. Phục hồi tệp, cơ sở dữ liệu và một ứng dụng hoàn chỉnh vào môi trường cô lập.
  2. Đo thời gian khôi phục và lượng dữ liệu mất thực tế.
  3. Kiểm thử xác nhận bảo mật trước khi kết nối lại.
  4. Ghi lại mọi phần phụ thuộc bị thiếu và điểm nghẽn thủ công.
  5. Sửa các khoảng trống lớn nhất.
  6. Lập lịch diễn tập định kỳ và rà soát của lãnh đạo.

27. Danh sách kiểm tra chiến lược sao lưu

Kinh doanh

  • Dịch vụ quan trọng có người sở hữu cụ thể.
  • RPO và RTO được phê duyệt từ phân tích tác động kinh doanh.
  • Tầng khôi phục và phần phụ thuộc đã được ghi lại.
  • Thời hạn lưu giữ đáp ứng yêu cầu pháp lý, quyền riêng tư, hợp đồng và vận hành.

Phạm vi bảo vệ

  • Cơ sở dữ liệu, tệp, đối tượng, cấu hình, mã nguồn và định nghĩa hạ tầng đều được bao phủ.
  • Dữ liệu SaaS và dữ liệu thuần đám mây được đánh giá rõ ràng.
  • Bí mật cùng khóa có thể được cấp lại hoặc phục hồi an toàn.
  • Tài sản mới được phát hiện và gán chính sách.

Bảo mật

  • Ít nhất một bản bất biến hoặc ngoại tuyến.
  • Ít nhất một bản được quản trị độc lập với hệ thống chính.
  • Truy cập đặc quyền dùng MFA mạnh và quyền tối thiểu.
  • Bản sao cùng khóa được mã hóa và có thể khôi phục.
  • Thay đổi phá hủy được ghi nhật ký, cảnh báo và bảo vệ bằng phê duyệt bổ sung.

Vận hành

  • Công việc, tuổi điểm khôi phục, dung lượng, trạng thái sao chép và thay đổi chính sách được giám sát.
  • Công việc thất bại có người phụ trách và thời hạn xử lý.
  • Sổ tay có thể truy cập khi hệ thống chính ngừng hoạt động.
  • Diễn tập đo kết quả hoàn chỉnh của ứng dụng.
  • Khoảng trống trở thành công việc có người phụ trách và hạn hoàn thành.

Chiến lược sao lưu chỉ hoàn chỉnh khi khả năng khôi phục đã được chứng minh

Mục tiêu không phải thu thập số lượng bản sao lớn nhất. Mục tiêu là duy trì những lựa chọn khôi phục đáng tin cậy trước các loại hỏng hóc mà doanh nghiệp thực sự phải đối mặt.

Hãy bắt đầu từ khả năng chịu đựng của doanh nghiệp. Tạo các điểm khôi phục độc lập và được bảo vệ. Bảo vệ mặt phẳng điều khiển sao lưu. Giữ đủ lịch sử để tìm được một điểm sạch. Giám sát mọi công việc quan trọng. Sau đó khôi phục dịch vụ nhiều lần cho đến khi năng lực đo được đáp ứng lời hứa.

Nếu doanh nghiệp cần một kế hoạch sao lưu thực tế cho trang web, cửa hàng trực tuyến, tác vụ đám mây hoặc cơ sở dữ liệu, hãy liên hệ ViWeb. ViWeb có thể giúp xác định mục tiêu khôi phục, triển khai chính sách được bảo vệ, giám sát tình trạng sao lưu và kiểm thử phục hồi trước khi sự cố biến bài kiểm tra thành tình huống khẩn cấp.

Câu hỏi thường gặp

Quy tắc sao lưu 3 2 1 là gì?

Giữ ba bản dữ liệu quan trọng, gồm cả bản đang dùng, lưu các bản đó trên ít nhất hai hệ thống lưu trữ hoặc loại phương tiện độc lập và đặt ít nhất một bản ở địa điểm khác. Chiến lược hiện đại thường bổ sung một bản ngoại tuyến hoặc bất biến cùng quy trình kiểm thử khôi phục.

Trang web doanh nghiệp nên được sao lưu bao lâu một lần?

Lịch sao lưu phải bám theo Mục tiêu Điểm Khôi phục. Trang giới thiệu ít thay đổi có thể sao lưu hằng ngày hoặc hằng tuần, còn cơ sở dữ liệu thương mại điện tử đang hoạt động có thể cần nhật ký giao dịch liên tục hoặc điểm khôi phục sau mỗi vài phút. Cũng nên tạo bản sao trước thay đổi quan trọng.

Ảnh chụp nhanh trên đám mây có đủ để làm bản sao lưu không?

Không nên dùng riêng ảnh chụp nhanh. Cơ chế này có thể khôi phục nhanh nhưng thường dùng chung tài khoản, mặt phẳng điều khiển, khu vực hoặc nguyên nhân lỗi với hệ thống chính. Cần có bản sao độc lập, thời hạn lưu giữ được bảo vệ, quyền quản trị tách biệt và quy trình khôi phục đã kiểm thử.

Nên kiểm thử khôi phục bao lâu một lần?

Hệ thống quan trọng nên được kiểm thử ít nhất mỗi quý và sau thay đổi kiến trúc lớn. Các bước kiểm tra tính toàn vẹn nhỏ hơn nên chạy thường xuyên hơn. Tần suất chính xác phụ thuộc tác động kinh doanh, tốc độ thay đổi, mục tiêu khôi phục và nghĩa vụ pháp lý.

Tính bất biến có thay thế bản sao ngoại tuyến không?

Không. Tính bất biến bảo vệ điểm khôi phục trước việc sửa đổi hoặc xóa sớm, còn bản ngoại tuyến hoặc cách ly logic giảm ảnh hưởng từ danh tính và hệ thống quản lý bị xâm phạm. Chiến lược mạnh dùng nhiều lớp độc lập thay vì xem một tính năng là biện pháp bảo vệ hoàn chỉnh.