Sao lưu chống chịu được ransomware ── quy tắc 3-2-1, nơi lưu trữ không thể ghi đè và kiểm tra xem có khôi phục được không

Go Komura

doi:10.5281/zenodo.23969212

Sao lưu chống chịu được ransomware ── quy tắc 3-2-1, nơi lưu trữ không thể ghi đè và kiểm tra xem có khôi phục được không

1 Nov 2026 13:10 · Go Komura · Bảo mật, Ransomware, Sao lưu, Windows, Doanh nghiệp vừa và nhỏ, VSS

Lịch sử sửa đổi (bản đầu tiên, đăng ngày 1 Nov 2026)

1 Nov 2026: Đăng lần đầu

Trích dẫn bài viết này(DOI: 10.5281/zenodo.23969212)

Bài viết này được lưu trữ trên Zenodo. Bên dưới là DOI luôn dẫn tới phiên bản mới nhất, và DOI gắn với phiên bản bạn đang đọc.

Go Komura (2026). Sao lưu chống chịu được ransomware ── quy tắc 3-2-1, nơi lưu trữ không thể ghi đè và kiểm tra xem có khôi phục được không. KomuraSoft LLC. https://doi.org/10.5281/zenodo.23969212 https://comcomponent.com/vi/blog/ransomware-resilient-backup/

DOI (phiên bản mới nhất): 10.5281/zenodo.23969212
DOI (phiên bản này): 10.5281/zenodo.23969213

Trong các vụ tấn công bằng ransomware, có nhiều trường hợp tổ chức đã sao lưu nhưng vẫn không khôi phục được. Nguyên nhân phổ biến nhất là bản sao lưu cũng bị mã hóa cùng với mọi thứ khác. Bài viết này giải thích cách xây dựng bản sao lưu chịu được tấn công, dành cho PC Windows và máy chủ tệp của doanh nghiệp vừa và nhỏ.

Có ba điểm chính: giữ một bản sao mà PC bị nhiễm không thể ghi đè, không dùng “Phiên bản trước” thay cho sao lưu, và kiểm tra xem có thực sự khôi phục được không. Quy tắc 3-2-1 quyết định số bản sao và nơi giữ chúng, nhưng tự nó vẫn còn thiếu sót nếu xét như một biện pháp phòng chống ransomware.

Các lệnh trong bài chỉ dùng cho Windows, và kết quả đã được kiểm tra trong cửa sổ Command Prompt chạy với quyền quản trị trên Windows Server 2022. Màn hình cài đặt và giá của sản phẩm có thể thay đổi, nên khi triển khai hãy xem tài liệu mới nhất của từng nhà cung cấp.

Nhiều tổ chức có sao lưu nhưng không khôi phục được

Cơ quan Cảnh sát Quốc gia Nhật Bản hỏi các tổ chức bị ransomware tấn công về tình trạng sao lưu của họ. Trong báo cáo nửa đầu năm 2025, 51 trong số 53 tổ chức trả lời đã có sao lưu. Tuy nhiên, trong 48 tổ chức được hỏi liệu có khôi phục được từ bản sao lưu về mức ngay trước khi bị tấn công hay không, chỉ có 7 tổ chức làm được và 41 tổ chức không làm được¹.

Trong 35 tổ chức nêu lý do không khôi phục được, 23 tổ chức cho biết “bản sao lưu cũng bị mã hóa”, 8 tổ chức là “thiếu sót trong vận hành” và 4 tổ chức là “khác”¹. Cùng báo cáo đó cho biết các nhóm ransomware xóa nhật ký và bản sao lưu của nạn nhân để xóa dấu vết và ngăn việc khôi phục. Sau đó báo cáo yêu cầu các tổ chức lưu giữ bản sao lưu trong môi trường ngoại tuyến².

flowchart TB
        accTitle: Vì sao có sao lưu mà vẫn không khôi phục được
        accDescr: Sơ đồ cho thấy dù có sao lưu, bản sao lưu vẫn bị mã hóa cùng mọi thứ khác nếu PC bị nhiễm chạm tới được, và nếu chưa kiểm tra quy trình khôi phục thì thiếu sót trong vận hành sẽ khiến không khôi phục được.
        A["Đã sao lưu"] --> B{"PC bị nhiễm có chạm tới không?"}
        B -->|"Chạm tới được"| C["Cũng bị mã hóa hoặc xóa"]
        B -->|"Không chạm tới được"| D{"Đã kiểm tra quy trình khôi phục chưa?"}
        D -->|"Chưa kiểm tra"| E["Không khôi phục được do thiếu sót trong vận hành"]
        D -->|"Đã kiểm tra"| F["Khôi phục được"]

Hình 1: Bản sao lưu dùng được khi PC bị nhiễm không chạm tới được và quy trình khôi phục đã được kiểm tra.

Cũng có trường hợp khôi phục thành công. Phiên bản thứ 4 của “Hướng dẫn biện pháp an toàn thông tin cho doanh nghiệp vừa và nhỏ” của IPA có nêu trường hợp một công ty xây dựng bị mã hóa máy chủ tệp và các hệ thống khác sau khi bị xâm nhập qua thiết bị VPN. Một phần nhờ công ty này diễn tập khôi phục hai lần mỗi năm, họ đã đưa hệ thống cốt lõi hoạt động trở lại từ bản sao lưu năm ngày sau khi phát hiện bị tấn công. Dù vậy, việc khôi phục từng hệ thống nội bộ mất 41 ngày, khôi phục truy cập từ xa mất bốn tháng, và công ty đã mất hơn 20 phần trăm tệp nội bộ³. Khôi phục được từ bản sao lưu không có nghĩa là thiệt hại biến mất.

Trong sơ đồ, đường liền nét biểu thị quan hệ luôn đúng và đường nét đứt biểu thị quan hệ có điều kiện (điều kiện nằm trong phần giải thích từng quan hệ trên trang chi tiết). Danh sách đầy đủ các quan hệ (tổng 13, kèm bằng chứng và mức chắc chắn) cùng định nghĩa các khái niệm chính được tập hợp tại trang chi tiết bản đồ tri thức (bằng tiếng Nhật). Dữ liệu: JSON-LD / Turtle

Kẻ tấn công xóa những bản sao lưu mà chúng chạm tới được

Hướng dẫn #StopRansomware do CISA và các cơ quan khác của Mỹ phát hành cho biết nhiều biến thể ransomware cố tìm các bản sao lưu có thể truy cập để xóa hoặc mã hóa chúng, khiến nạn nhân không thể khôi phục nếu không trả tiền chuộc. Vì vậy hướng dẫn cho rằng việc lưu giữ bản sao lưu ở trạng thái ngoại tuyến là quan trọng⁴.

Microsoft cũng viết rằng kẻ tấn công tập trung vào việc vô hiệu hóa phần mềm sao lưu và các tính năng của hệ điều hành như bản sao bóng của ổ đĩa⁵. Những bản sao lưu mà PC bị nhiễm có thể chạm tới bao gồm:

Ổ đĩa ngoài luôn cắm vào PC
Thư mục chia sẻ trên NAS hoặc máy chủ tệp được gán ký tự ổ đĩa
Thư mục đồng bộ đám mây mà tài khoản dùng hằng ngày có thể ghi vào
Bản sao bóng (Phiên bản trước) trên cùng ổ đĩa

Ngay cả các lệnh có sẵn trong hệ điều hành cũng xóa được bản sao bóng và danh mục sao lưu. MITRE ATT&CK xếp kỹ thuật này vào “Inhibit System Recovery” (T1490). Tài liệu đó nêu ví dụ xóa toàn bộ bản sao bóng bằng vssadmin.exe delete shadows /all /quiet và xóa danh mục sao lưu của Windows bằng wbadmin.exe delete catalog -quiet⁶. Hướng dẫn của CISA cũng yêu cầu theo dõi việc sử dụng đáng ngờ vssadmin.exe, wbadmin.exe, wmic.exe (shadowcopy) và các công cụ tương tự⁴.

flowchart TB
        accTitle: Những bản sao lưu PC bị nhiễm chạm tới được và không chạm tới được
        accDescr: Sơ đồ cho thấy PC bị nhiễm có thể ghi vào ổ đĩa ngoài luôn cắm, thư mục chia sẻ đã gán, thư mục đồng bộ và bản sao bóng, nhưng không thể ghi vào phương tiện đã tháo ra hoặc nơi lưu trữ không thể ghi đè.
        P["PC bị nhiễm"] --> R["Những nơi có thể ghi vào"]
        P -.-x N["Phương tiện đã tháo ra, nơi lưu trữ không thể ghi đè"]
        R --> A["Ổ đĩa ngoài luôn cắm"]
        R --> B["Thư mục chia sẻ đã gán"]
        R --> C["Thư mục đồng bộ đám mây"]
        R --> D["Bản sao bóng"]

Hình 2: Bản sao lưu đặt ở nơi PC bị nhiễm có thể ghi vào sẽ trở thành mục tiêu tấn công.

Cũng cần đề phòng những cuộc tấn công kéo dài. Microsoft viết rằng ransomware đôi khi mã hóa dần dần trong khi vẫn để khóa lại trên hệ thống. Trong thời gian đó người dùng vẫn dùng dữ liệu như bình thường, nên các bản sao lưu chứa dữ liệu đã bị mã hóa cứ tăng dần mà không ai nhận ra. Khi mọi thứ đã bị mã hóa và khóa bị xóa, ngay cả các bản sao lưu gần đây cũng không đọc được⁵. Nếu chỉ giữ thế hệ mới nhất, trong trường hợp này sẽ không còn nơi nào để quay về.

“Phiên bản trước” không thay thế được sao lưu

“Phiên bản trước” của Windows và bản sao bóng của thư mục chia sẻ sử dụng Volume Shadow Copy Service (VSS). Trình cung cấp hệ thống VSS đi kèm Windows dùng phương thức sao chép khi ghi (copy-on-write): trước khi một khối bị ghi đè, nội dung của khối đó được lưu sang vùng chênh lệch, nhờ vậy tái hiện được ổ đĩa tại một thời điểm⁷.

Trong tài liệu về VSS, Microsoft giải thích sự khác biệt giữa bản sao bóng và bản sao lưu như sau. Khi dữ liệu được sao chép từ bản sao bóng sang phương tiện tháo rời như băng từ, nội dung trên phương tiện đó trở thành bản sao lưu. Sau khi sao chép, có thể xóa chính bản sao bóng⁷. Tài liệu cũng cho biết khi vùng chênh lệch không đủ chỗ, các bản sao bóng cũ nhất sẽ bị xóa trước⁷.

flowchart TB
        accTitle: Khác biệt giữa bản sao bóng và bản sao lưu
        accDescr: Sơ đồ cho thấy bản sao bóng là phần chênh lệch so với ổ đĩa gốc và bị xóa khi thiếu chỗ hoặc bởi kẻ tấn công, còn bản sao lưu đã sao chép sang phương tiện riêng vẫn còn ngay cả khi mất ổ đĩa gốc.
        V["Ổ đĩa gốc"] --> S["Bản sao bóng (phần chênh lệch)"]
        S --> L["Thiếu chỗ thì xóa từ bản cũ nhất"]
        S --> K["Kẻ tấn công xóa bằng vssadmin"]
        S -->|"Sao chép sang phương tiện riêng"| B["Bản sao lưu"]
        B --> R["Vẫn còn dù mất ổ đĩa gốc"]

Hình 3: Bản sao bóng phụ thuộc vào dữ liệu của ổ đĩa gốc; thứ bạn sao chép sang phương tiện riêng mới là bản sao lưu.

Bản sao bóng rất tiện để người dùng tự khôi phục những tệp lỡ ghi đè. Tuy nhiên, như đã nói ở phần trước, kẻ tấn công đôi khi xóa chúng. Cơ chế và cách vận hành được giải thích chi tiết trong “Volume Shadow Copy (VSS): cơ chế và thực hành”.

Để liệt kê các bản sao bóng còn lại, hãy chạy vssadmin list shadows trong Command Prompt chạy với quyền quản trị. Lệnh con này dùng được trên cả máy khách và máy chủ⁸.

vssadmin list shadows

Lịch sử phiên bản và thùng rác trong OneDrive và SharePoint cũng là cách để người dùng lấy lại tệp. Microsoft khuyến nghị hướng dẫn người dùng cách khôi phục toàn bộ OneDrive về một thời điểm trước đó. Microsoft cũng nêu rằng chỉ nên cho người dùng khôi phục khi bạn chắc chắn kẻ tấn công đã bị loại khỏi môi trường, và cần chuẩn bị cho trường hợp người dùng khôi phục cả phần mềm độc hại⁵.

Quy tắc 3-2-1 quyết định số bản sao và nơi giữ

Quy tắc 3-2-1 là một nguyên tắc kinh nghiệm về cách giữ các bản sao lưu. Tài liệu “Data Backup Options”, được soạn cho US-CERT năm 2012, giải thích như sau⁹.

3: Giữ ba bản của các tệp quan trọng, gồm bản gốc và hai bản sao lưu.
2: Lưu trên hai loại phương tiện khác nhau để phòng các loại sự cố khác nhau.
1: Giữ một bản bên ngoài nhà hoặc cơ sở kinh doanh.

Tài liệu này dẫn nguồn là “The DAM Book”, cuốn sách về quản lý ảnh kỹ thuật số của nhiếp ảnh gia Peter Krogh⁹. Microsoft cũng nêu quy tắc này trong tài liệu về sao lưu để phòng chống ransomware, và mô tả số “1” là “bản sao ngoài cơ sở hoặc bản sao lạnh”⁵.

Điều quy tắc 3-2-1 yêu cầu là giữ một bản ngoài cơ sở. Quy tắc không yêu cầu bản ngoài cơ sở đó phải ngoại tuyến hay bất biến. Vì vậy, nếu bản ngoài cơ sở nằm trên đám mây mà PC bị nhiễm luôn ghi vào được, nó có thể bị mã hóa cùng các bản sao tại chỗ. Hướng dẫn của CISA và tài liệu của Microsoft đều nêu lưu trữ ngoại tuyến là một biện pháp phòng chống ransomware. Microsoft còn nêu thêm nơi lưu trữ không thể ghi đè⁴⁵.

flowchart TB
        accTitle: Quy tắc 3-2-1 và việc phòng chống ransomware
        accDescr: Sơ đồ cho thấy thêm một bản sao ngoại tuyến hoặc bất biến vào quy tắc 3-2-1 gồm ba bản sao, hai loại phương tiện và một bản ngoài cơ sở, rồi kiểm tra xem có khôi phục được không.
        A["Ba bản sao"] --> B["Hai loại phương tiện"]
        B --> C["Một bản ngoài cơ sở"]
        C --> D["Một bản ngoại tuyến hoặc bất biến"]
        D --> E["Kiểm tra có khôi phục được không"]

Hình 4: Thêm vào quy tắc 3-2-1 một bản sao mà PC bị nhiễm không thể ghi đè, và bước kiểm tra xem có khôi phục được không.

Nhà cung cấp phần mềm sao lưu Veeam quảng bá điều này dưới tên “quy tắc 3-2-1-1-0”. Trong tài liệu của Veeam, số “1” thêm vào nghĩa là giữ một bản sao ngoại tuyến, cách ly vật lý (air-gapped) hoặc bất biến, còn số “0” nghĩa là không có lỗi trong các lần xác minh khôi phục định kỳ¹⁰. Đây là cách gọi trong tài liệu của nhà cung cấp, không phải tiêu chuẩn chính thức. Dù vậy, hai mục thêm vào này trùng với những gì CISA và IPA yêu cầu.

Giữ một bản sao mà PC bị nhiễm không thể ghi đè

Có hai cách chính để tạo một bản sao không thể ghi đè: tháo phương tiện khỏi PC rồi cất giữ, hoặc dùng nơi lưu trữ trên đám mây mà trong một khoảng thời gian định trước dữ liệu không thể bị ghi đè hay xóa. Dù chọn cách nào, hãy tách quyền quản lý bản sao lưu khỏi công việc hằng ngày.

Tháo phương tiện khỏi PC và cất giữ riêng

Hướng dẫn của IPA nêu ví dụ biện pháp trong phần tự đánh giá là chỉ kết nối thiết bị và phương tiện dùng để sao lưu với máy tính khi đang sao lưu. Hướng dẫn cũng nêu việc quyết định cách sao lưu, cất giữ ở nơi an toàn và định kỳ kiểm tra xem có khôi phục được không¹¹.

Ở giai đoạn làm bài bản hơn, hướng dẫn nêu “cách ly vật lý”. Đây là cách đặt bản sao lưu ở nơi tách biệt về mặt vật lý với hệ thống gốc, cất giữ ổ lưu trữ ngoài hoặc băng sao lưu ở nơi càng xa càng tốt. Ví dụ về nơi cất giữ gồm két an toàn ở ngân hàng, hoặc đối tác kinh doanh hay công ty liên kết đáng tin cậy¹².

Bản sao lưu được cất giữ tách khỏi hệ thống vận hành như vậy được gọi là sao lưu ngoại tuyến. PC bị nhiễm không thể ghi vào phương tiện đã tháo ra. Đổi lại, việc cắm lại và mang phương tiện đi do con người thực hiện, nên có lúc quên sao lưu hoặc quên mang phương tiện ra ngoài. Hãy quyết định ai sẽ cắm phương tiện, tháo ra và mang đến nơi cất giữ, và vào lúc nào.

Dùng nơi lưu trữ đám mây không thể ghi đè

Các dịch vụ lưu trữ đám mây có tính năng ngăn dữ liệu bị ghi đè hoặc xóa trong một khoảng thời gian định trước. Chúng lưu dữ liệu ở trạng thái gọi là WORM (Write Once, Read Many).

Với lưu trữ bất biến của Azure Blob Storage, khi bạn đặt chính sách lưu giữ theo thời gian, trong khoảng thời gian đó dữ liệu có thể được tạo và đọc nhưng không thể sửa đổi hay xóa¹³. Chính sách ban đầu được tạo ở trạng thái chưa khóa, và bạn khóa nó sau khi thử nghiệm. Chính sách đã khóa không thể xóa, và thời gian lưu giữ có thể kéo dài nhưng không thể rút ngắn¹³. Microsoft giải thích rằng ngay cả người dùng có quyền quản trị tài khoản cũng không thể sửa đổi hay xóa dữ liệu¹³.

Amazon S3 Object Lock có hai chế độ. Ở chế độ tuân thủ (compliance mode), không ai, kể cả người dùng gốc của tài khoản AWS, có thể ghi đè hay xóa một phiên bản đối tượng trong thời gian lưu giữ. Ở chế độ quản trị (governance mode), chỉ người dùng có quyền đặc biệt mới có thể thay đổi hoặc gỡ cài đặt lưu giữ¹⁴. Object Lock chỉ dùng được trên các bucket đã bật S3 Versioning¹⁴.

flowchart TB
        accTitle: Hai ví dụ về nơi lưu trữ không thể ghi đè
        accDescr: Sơ đồ cho thấy với lưu trữ bất biến của Azure Blob Storage, chính sách đã khóa không thể xóa và không thể rút ngắn thời gian lưu giữ, còn với S3 Object Lock, ở chế độ tuân thủ ngay cả người dùng gốc cũng không xóa được, trong khi ở chế độ quản trị quyền đặc biệt cho phép thay đổi.
        W["Nơi lưu trữ không thể ghi đè"] --> AZ["Lưu trữ bất biến của Azure Blob Storage"]
        W --> S3["S3 Object Lock"]
        AZ --> AZ1["Sau khi khóa không rút ngắn được thời gian lưu giữ"]
        S3 --> C["Chế độ tuân thủ"]
        S3 --> G["Chế độ quản trị"]
        C --> C1["Ngay cả người dùng gốc cũng không xóa được"]
        G --> G1["Quyền đặc biệt cho phép thay đổi"]

Hình 5: Cả hai nơi lưu trữ đều từ chối việc ghi đè và xóa trong một khoảng thời gian định trước; mức độ nghiêm ngặt tùy theo cài đặt.

Trên Azure, ngay cả khi phát hiện lỗi cấu hình sau khi đã khóa chính sách, bạn cũng không thể rút ngắn thời gian lưu giữ¹³. Hướng dẫn của CISA giới thiệu rằng một số nhà cung cấp đám mây có nơi lưu trữ không thể ghi đè, đồng thời cảnh báo rằng cấu hình sai có thể dẫn đến chi phí lớn. Hướng dẫn cũng đề cập rằng loại lưu trữ này có thể không đáp ứng yêu cầu của một số quy định⁴. Nếu đặt thời gian lưu giữ dài rồi khóa lại, trong thời gian đó bạn không thể xóa dữ liệu và phí lưu trữ vẫn tiếp tục phát sinh. Hãy bắt đầu ở trạng thái chưa khóa hoặc với thời gian ngắn, xác nhận khôi phục được, rồi mới áp dụng cài đặt chính thức.

Tách quyền quản lý bản sao lưu

Ngay cả khi dùng nơi lưu trữ không thể ghi đè, nếu cài đặt và chính sách sao lưu có thể được thay đổi bằng tài khoản quản trị dùng hằng ngày, kẻ tấn công có thể thay đổi chúng. Microsoft khuyến nghị yêu cầu thêm một bước, chẳng hạn xác thực đa yếu tố hoặc mã PIN bảo mật, trước khi bản sao lưu trực tuyến có thể bị sửa đổi hoặc xóa. Microsoft cũng nêu việc giới hạn thao tác sao lưu và khôi phục cho người dùng có vai trò được chỉ định, và giảm số thư mục chia sẻ tệp mà nhiều người dùng có thể ghi và xóa⁵.

Ngay cả khi cùng một người quản lý cả PC lẫn bản sao lưu, đừng dùng tài khoản quản lý nơi lưu bản sao lưu để đăng nhập PC hằng ngày, và hãy bảo vệ tài khoản đó bằng xác thực đa yếu tố.

Giữ nhiều thế hệ

Hướng dẫn của IPA nêu “quản lý thế hệ”, tức là giữ bản sao lưu của nhiều thời điểm. Cách này cho phép quay về một thời điểm cụ thể khi dữ liệu bị hỏng hoặc bị mất¹². Như đã nói ở phần trước, nếu phải mất thời gian mới nhận ra việc mã hóa, các bản sao lưu gần nhất sẽ chứa dữ liệu đã bị mã hóa. Hãy quyết định số thế hệ cần giữ dựa trên khoảng thời gian có thể cần để nhận ra việc mã hóa và chi phí lưu trữ.

flowchart TB
        accTitle: Ba biện pháp để giữ một bản sao không thể ghi đè
        accDescr: Sơ đồ cho thấy việc cất giữ phương tiện đã tháo ra hoặc dùng nơi lưu trữ không thể ghi đè, tách quyền quản lý bản sao lưu khỏi tài khoản dùng hằng ngày, và giữ nhiều thế hệ.
        A["Bản sao không thể ghi đè"] --> B["Cất giữ phương tiện đã tháo ra"]
        A --> C["Nơi lưu trữ không thể ghi đè"]
        B --> D["Tách quyền quản lý"]
        C --> D
        D --> E["Giữ nhiều thế hệ"]

Hình 6: Sau khi quyết định nơi giữ, hãy tách quyền quản lý và giữ nhiều thế hệ để có thể quay về ngay cả khi phát hiện muộn.

Kiểm tra xem có khôi phục được không

Trong báo cáo của Cơ quan Cảnh sát Quốc gia, lý do phổ biến thứ hai khiến không khôi phục được là “thiếu sót trong vận hành”¹. Bạn không thể biết một bản sao lưu có thực sự khôi phục được hay không cho đến khi thử. Công việc thực sự khôi phục từ bản sao lưu để kiểm tra điều này được gọi là kiểm thử khôi phục.

Hướng dẫn của IPA chia việc vận hành sao lưu thành ba phần: tạo, cất giữ và khôi phục. Với phần khôi phục, hướng dẫn yêu cầu lập kế hoạch khôi phục và xác nhận rằng có thể khôi phục đúng cách³. Với các hệ thống quan trọng cho hoạt động kinh doanh, hướng dẫn yêu cầu sắp xếp cách tạo bản sao lưu và quy trình phù hợp với thời gian khôi phục mục tiêu (RTO) và điểm khôi phục mục tiêu (RPO), đồng thời kiểm chứng hiệu quả bằng diễn tập. RTO là thời gian cần để khôi phục về mức mục tiêu, còn RPO là thời điểm bạn khôi phục về, tức là thời điểm của bản sao lưu gần nhất¹⁵. Hướng dẫn của CISA cũng yêu cầu, với tình huống khôi phục sau thảm họa, định kỳ kiểm tra xem bản sao lưu có dùng được và còn nguyên vẹn hay không⁴.

flowchart TB
        accTitle: Cách tiến hành kiểm thử khôi phục
        accDescr: Sơ đồ cho thấy trình tự quyết định thứ tự khôi phục, khôi phục sang một môi trường riêng, so sánh thời gian đã mất và thời điểm khôi phục với RTO và RPO, rồi sửa sổ tay quy trình.
        A["Quyết định thứ tự khôi phục"] --> B["Khôi phục sang môi trường riêng"]
        B --> C["So sánh thời gian đã mất với RTO"]
        B --> D["So sánh thời điểm khôi phục với RPO"]
        C --> E["Sửa sổ tay quy trình"]
        D --> E
        E -.->|"Lần kiểm tra tiếp theo"| A

Hình 7: Thử khôi phục, kiểm tra xem thời gian và thời điểm có đạt mục tiêu không, rồi đưa kết quả trở lại sổ tay quy trình.

Kiểm tra những gì

Dựa trên tài liệu của IPA và Microsoft, những điều cần kiểm tra có thể sắp xếp như sau.

Điều cần kiểm tra	Điểm cần xem	Căn cứ
Có khôi phục được từng tệp không	Các tệp người dùng làm việc có mở được không	IPA¹¹
Có khôi phục được toàn bộ hệ thống không	Khôi phục sang PC hoặc máy chủ tách biệt với môi trường vận hành và xem ứng dụng nghiệp vụ có chạy không	IPA³, Microsoft⁵
Thời gian đã mất	Có nằm trong RTO đã đặt không	IPA¹⁵
Thời điểm khôi phục	Có cũ hơn RPO đã đặt không	IPA¹⁵
Thứ tự khôi phục	Đã quyết định thứ cần khôi phục trước chưa, chẳng hạn xác thực và nghiệp vụ cốt lõi	Microsoft⁵
Nơi để sổ tay quy trình	Có đọc được ngay cả khi mọi hệ thống nội bộ đều ngừng không	Microsoft⁵

Microsoft khuyến nghị trước tiên xác định các hệ thống không thể thiếu cho hoạt động kinh doanh và sao lưu chúng định kỳ. Danh sách bản sao lưu theo thứ tự ưu tiên tạo ra theo cách đó cũng chính là danh sách thứ tự khôi phục. Ở vị trí ưu tiên cao, Microsoft nêu đầu tiên các hệ thống xác thực như Active Directory, vốn cần để truy cập mọi hệ thống khác⁵. Microsoft cũng khuyến nghị định kỳ diễn tập đưa hoạt động kinh doanh trở lại từ trạng thái mọi hệ thống đều ngừng. Khi diễn tập, hãy giả định rằng cả email và chat cũng không dùng được⁵.

Microsoft viết rằng kẻ tấn công cố ý nhắm vào sổ tay quy trình khôi phục và sơ đồ mạng. Microsoft khuyến nghị bảo vệ chúng hoặc giữ bản in bên mình⁵. Nếu sổ tay quy trình chỉ nằm trên máy chủ tệp, khi máy chủ tệp đó bị mã hóa bạn sẽ không đọc được.

Lưu ý khi khôi phục sau khi bị tấn công

Sau một vụ tấn công thực tế, hãy loại bỏ chính ransomware khỏi môi trường trước rồi mới khôi phục⁵. Microsoft nêu việc chọn bản sao lưu ở thời điểm được biết là chưa bị nhiễm, và quét bản sao lưu để tìm phần mềm độc hại trước khi khôi phục⁵. Báo cáo của Cơ quan Cảnh sát Quốc gia cho biết các nhóm ransomware đôi khi cài phần mềm điều khiển từ xa làm cửa hậu để có thể quay lại ngay cả khi lối xâm nhập đã bị đóng². Trước khi khôi phục, cần điều tra đường xâm nhập và những gì kẻ tấn công để lại.

flowchart TB
        accTitle: Thứ tự khôi phục từ bản sao lưu sau khi bị tấn công
        accDescr: Sơ đồ cho thấy việc loại bỏ chính ransomware và đường xâm nhập, chọn bản sao lưu ở thời điểm chưa bị nhiễm, quét để tìm phần mềm độc hại, rồi khôi phục các hệ thống ưu tiên cao trước.
        A["Loại bỏ chính ransomware"] --> B["Điều tra đường xâm nhập và thứ còn sót lại"]
        B --> C["Chọn thời điểm chưa bị nhiễm"]
        C --> D["Quét bản sao lưu"]
        D --> E["Khôi phục thứ ưu tiên cao trước"]

Hình 8: Sau khi bị tấn công, hãy loại bỏ những gì kẻ tấn công để lại và xác nhận thời điểm chưa bị nhiễm rồi mới khôi phục.

Kiểm tra với tần suất nào

Cả hướng dẫn của IPA và hướng dẫn của CISA đều yêu cầu kiểm tra khả năng khôi phục “định kỳ”, nhưng không đưa ra con số cụ thể¹¹⁴. Công ty trong trường hợp của IPA được nêu ở trên đã diễn tập khôi phục hai lần mỗi năm³. Hãy quyết định doanh nghiệp có thể ngừng hoạt động trong bao lâu và điểm khôi phục được phép cũ đến mức nào, rồi kiểm tra với tần suất đủ để xác nhận bạn đang đáp ứng các mục tiêu đó.

Những gì cần quyết định trước tiên

Nội dung đến đây có thể tóm tắt thành những gì doanh nghiệp vừa và nhỏ cần quyết định trước tiên.

Hạng mục	Điều cần quyết định
Phạm vi	Dữ liệu và hệ thống mà nếu không khôi phục được thì hoạt động kinh doanh sẽ ngừng
Bản sao	Số bản sao, phương tiện và nơi giữ theo quy tắc 3-2-1
Bản sao không thể ghi đè	Dùng phương tiện đã tháo ra hay nơi lưu trữ không thể ghi đè
Quyền	Tài khoản quản lý bản sao lưu và xác thực đa yếu tố
Thế hệ	Giữ bao nhiêu thế hệ và trong bao lâu
Mục tiêu	RTO và RPO cho từng nghiệp vụ
Kiểm tra	Thử khôi phục cái gì, ai làm và với tần suất nào
Sổ tay quy trình	Để tài liệu ghi thứ tự và quy trình khôi phục ở đâu

flowchart TB
        accTitle: Thứ tự quyết định bản sao lưu chống chịu được ransomware
        accDescr: Sơ đồ cho thấy thứ tự quyết định phạm vi, quyết định nơi giữ bản sao và bản sao không thể ghi đè, quyết định quyền và thế hệ, quyết định RTO và RPO, rồi kiểm tra xem có khôi phục được không.
        A["Quyết định phạm vi"] --> B["Quyết định nơi giữ bản sao"]
        B --> C["Quyết định bản sao không thể ghi đè"]
        C --> D["Quyết định quyền và thế hệ"]
        D --> E["Quyết định RTO và RPO"]
        E --> F["Kiểm tra có khôi phục được không"]

Hình 9: Quyết định mọi thứ thành một chuỗi liên tục, từ phạm vi cho đến bước cuối là kiểm tra xem có khôi phục được không.

Trong phiên bản thứ 4 của hướng dẫn IPA, “Hãy sao lưu!” đã được thêm vào “5 điều về an toàn thông tin” mà các tổ chức bắt đầu thực hiện, nâng thành 6 điều¹⁶. Cách tiến hành theo toàn bộ hướng dẫn được tóm tắt trong “Where Should SMEs Start on Security?”. Nếu bạn có kế hoạch thay máy chủ, hãy tham khảo thêm “Preparing for Windows Server 2016 End of Support”.

Bài viết liên quan

Tài liệu tham khảo

Cơ quan Cảnh sát Quốc gia Nhật Bản, Cục Cảnh sát Mạng, Tình hình các mối đe dọa trên không gian mạng trong nửa đầu năm 2025 (tháng 9 năm 2025, bằng tiếng Nhật). Phần số liệu, trang 61, “Thống kê thiệt hại do ransomware (4)”. Tình trạng sao lưu (trong 53 câu trả lời hợp lệ, 51 có sao lưu), kết quả khôi phục (trong 48 câu trả lời hợp lệ, 7 khôi phục được và 41 không khôi phục được) và lý do không khôi phục được (trong 35 câu trả lời hợp lệ: bản sao lưu cũng bị mã hóa 23, thiếu sót trong vận hành 8, khác 4). ↩ ↩² ↩³
Cơ quan Cảnh sát Quốc gia Nhật Bản, Cục Cảnh sát Mạng, Tình hình các mối đe dọa trên không gian mạng trong nửa đầu năm 2025 (bằng tiếng Nhật). Trang 9. Việc các nhóm ransomware xóa nhật ký và bản sao lưu của nạn nhân, cài cửa hậu để quay lại, và việc bản sao lưu cần được lưu giữ trong môi trường ngoại tuyến. ↩ ↩²
IPA, Hướng dẫn biện pháp an toàn thông tin cho doanh nghiệp vừa và nhỏ, phiên bản 4.0 (bằng tiếng Nhật). Trường hợp 3 ở trang 11 (diễn tập khôi phục hai lần mỗi năm, hệ thống cốt lõi hoạt động trở lại năm ngày sau khi phát hiện, mất hơn 20 phần trăm tệp) và mục “Vận hành sao lưu đúng cách” ở trang 21 (tạo, cất giữ và khôi phục). ↩ ↩² ↩³ ↩⁴
CISA và các cơ quan khác, #StopRansomware Guide. Duy trì bản sao lưu ngoại tuyến đã mã hóa và định kỳ kiểm tra tính sẵn sàng và toàn vẹn của chúng. Việc nhiều biến thể ransomware cố xóa hoặc mã hóa các bản sao lưu có thể truy cập. Theo dõi việc sử dụng đáng ngờ vssadmin.exe, wbadmin.exe và các công cụ tương tự. Cảnh báo về chi phí và tác động pháp lý của việc cấu hình sai nơi lưu trữ không thể ghi đè. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Microsoft Learn, Azure backup and restore plan to protect against ransomware. Việc kẻ tấn công nhắm vào bản sao lưu và bản sao bóng của ổ đĩa, thủ đoạn mã hóa dần dần, quy tắc 3-2-1, lưu trữ ngoại tuyến và bất biến, xác thực đa yếu tố và mã PIN bảo mật, thứ tự khôi phục, bảo vệ sổ tay quy trình và các bước kiểm tra trước khi khôi phục. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴
MITRE ATT&CK, Inhibit System Recovery (T1490). Ví dụ xóa bản sao bóng bằng vssadmin.exe và xóa danh mục sao lưu bằng wbadmin.exe. ↩
Microsoft Learn, Volume Shadow Copy Service (VSS). Phương thức sao chép khi ghi, khác biệt giữa bản sao bóng và bản sao lưu, và việc xóa khi vùng chênh lệch không đủ chỗ. ↩ ↩² ↩³
Microsoft Learn, vssadmin. Các lệnh con như vssadmin list shadows, và khả năng sử dụng trên máy khách và máy chủ. ↩
Paul Ruggiero, Matthew A. Heckathorn, Data Backup Options (năm 2012, do Carnegie Mellon University soạn cho US-CERT). Nội dung quy tắc 3-2-1 và “The DAM Book” của Peter Krogh là nguồn gốc của quy tắc. ↩ ↩²

Veeam, [3-2-1 Rule

Veeam Backup for Microsoft 365 Best Practices](https://bp.veeam.com/vb365/guide/design/3-2-1). Tài liệu của nhà cung cấp. Số “1” thêm vào (một bản sao ngoại tuyến, cách ly vật lý hoặc bất biến) và số “0” (không có lỗi khi xác minh khôi phục) của quy tắc 3-2-1-1-0.

↩

IPA, Hướng dẫn biện pháp an toàn thông tin cho doanh nghiệp vừa và nhỏ, phiên bản 4.0 (bằng tiếng Nhật). Trang 24. Ví dụ biện pháp sao lưu (thực hiện định kỳ, chỉ kết nối thiết bị và phương tiện khi đang sao lưu, cất giữ ở nơi an toàn, định kỳ kiểm tra khả năng khôi phục). ↩ ↩² ↩³
IPA, Hướng dẫn biện pháp an toàn thông tin cho doanh nghiệp vừa và nhỏ, phiên bản 4.0 (bằng tiếng Nhật). Trang 33, “Thực hiện sao lưu phù hợp”. Quản lý thế hệ và cách ly vật lý. ↩ ↩²
Microsoft Learn, Immutable storage for blob data overview. Trạng thái WORM, chính sách lưu giữ theo thời gian, việc chính sách đã khóa không thể xóa và không thể rút ngắn thời gian lưu giữ, và việc ngay cả người dùng có quyền quản trị cũng không thể sửa đổi hay xóa dữ liệu. ↩ ↩² ↩³ ↩⁴
AWS, Locking objects with Object Lock. Chế độ tuân thủ và chế độ quản trị, và việc cần bật quản lý phiên bản. ↩ ↩²
IPA, Hướng dẫn biện pháp an toàn thông tin cho doanh nghiệp vừa và nhỏ, phiên bản 4.0 (bằng tiếng Nhật). Trang 38. Tạo bản sao lưu và chuẩn bị quy trình phù hợp với thời gian khôi phục mục tiêu (RTO) và điểm khôi phục mục tiêu (RPO), và kiểm chứng hiệu quả bằng diễn tập. ↩ ↩² ↩³
IPA, Công bố phiên bản 4.0 của “Hướng dẫn biện pháp an toàn thông tin cho doanh nghiệp vừa và nhỏ” (bằng tiếng Nhật). Việc thêm “Hãy sao lưu!” để trở thành 6 điều về an toàn thông tin. ↩

Các bài viết gần đây có cùng thẻ để tìm hiểu sâu hơn những chủ đề lân cận.

Volume Shadow Copy (VSS): cơ chế và thực hành — vì sao phần mềm sao lưu copy được tệp đang dùng

Tệp đang dùng thường không copy được vì vi phạm chia sẻ — vậy phần mềm sao lưu làm thế nào? Bài viết giải thích vai trò requester, writer...

Đọc bài viết

Hướng dẫn thực tế BitLocker ── bắt đầu mã hóa ổ đĩa từ quản lý khóa khôi phục

Từ Windows 11 24H2 trở đi, cài đặt sạch mặc định bật Mã hóa thiết bị, nên tai nạn "phát hiện ra đã bị mã hóa" đang xảy ra thực tế. Lấy bả...

Đọc bài viết

Bên trong ảo hóa Windows (Phần 2) — Bộ nhớ ngay cả kernel cũng không thấy: VBS, HVCI và Credential Guard

Khi cài sạch trên phần cứng tương thích, VBS được bật mặc định và dùng hypervisor cùng SLAT để tạo cô lập mạnh hơn kernel. Bài viết này g...

Đọc bài viết

Named pipe trong thực tiễn — IPC chuẩn của Windows, từ thiết kế đến bảo mật

Hướng dẫn thực tiễn về named pipe, cơ chế giao tiếp giữa các tiến trình chuẩn của Windows. Bài viết sắp xếp, từ nguồn gốc, việc chọn giữa...

Đọc bài viết

Từ Group Policy sang Intune — hướng dẫn di chuyển quản lý thiết bị cho doanh nghiệp vừa và nhỏ

Khi máy chủ AD đến hạn thay, nên giữ Group Policy hay chuyển sang Entra ID plus Intune? Bài viết này sắp xếp, cho doanh nghiệp vừa và nhỏ...

Đọc bài viết

Chủ đề liên quan

Đây là các trang chủ đề gần với chủ đề này. Từ bài viết, bạn có thể đi tiếp đến các dịch vụ liên quan và những bài viết khác.

Chủ đề kỹ thuật Windows

Cổng vào tổng hợp các chủ đề kỹ thuật về phát triển Windows, điều tra lỗi và khai thác tài sản hiện có.

Xem chủ đề

Dịch vụ liên quan đến chủ đề này

Bài viết này dẫn đến các trang dịch vụ sau. Hãy xem từ lối vào gần nhất với bạn.

Tư vấn kỹ thuật và đánh giá thiết kế

Chúng tôi có thể cùng bạn kiểm tra, dựa trên cấu hình thực tế, xem bản sao lưu của các PC và máy chủ tệp trong công ty có nằm ở nơi mà một PC bị nhiễm có thể chạm tới hay không, và quy trình khôi phục có thực sự dùng được hay không.

Xem dịch vụ Liên hệ

Chỉnh sửa và bảo trì phần mềm Windows hiện có

Hãy liên hệ với chúng tôi nếu bạn muốn sắp xếp thứ tự khôi phục và sổ tay quy trình, đồng thời thực hiện kiểm thử khôi phục trong môi trường có các máy chủ Windows và ứng dụng nghiệp vụ cũ.

Xem dịch vụ Liên hệ

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

Các câu hỏi thường gặp khi tư vấn về chủ đề của bài viết.

Nếu tôi có sao lưu, khi bị nhiễm ransomware tôi có khôi phục được mọi thứ không?: Thường thì chỉ sao lưu thôi là chưa đủ để khôi phục. Trong số liệu thiệt hại do Cơ quan Cảnh sát Quốc gia Nhật Bản tổng hợp cho nửa đầu năm 2025, 41 trong số 48 tổ chức có sao lưu và đã trả lời không thể khôi phục về mức ngay trước khi bị tấn công. Lý do phổ biến nhất là bản sao lưu cũng bị mã hóa. Bạn cần một bản sao mà PC bị nhiễm không thể ghi đè, và cần kiểm tra rằng có thể khôi phục từ bản sao đó.
Nếu Windows đã có Phiên bản trước, tôi có còn cần sao lưu không?: Có. Phiên bản trước là bản sao bóng của ổ đĩa (volume shadow copy), tức là phần chênh lệch được giữ trên chính ổ đĩa gốc. Microsoft coi dữ liệu được sao chép từ bản sao bóng sang phương tiện như băng từ mới là bản sao lưu. Ransomware đôi khi xóa bản sao bóng bằng các công cụ như vssadmin, vì vậy hãy kết hợp chúng với bản sao lưu trên phương tiện riêng.
Tuân theo quy tắc 3-2-1 có đủ để phòng chống ransomware không?: Đôi khi là không đủ. Quy tắc 3-2-1 yêu cầu ba bản sao, hai loại phương tiện và một bản đặt ngoài cơ sở, nhưng không yêu cầu bản ngoài cơ sở đó phải ngoại tuyến hoặc bất biến. Một bản sao trên đám mây mà PC bị nhiễm luôn ghi vào được có thể bị mã hóa theo cùng cách. Hãy thêm một bản sao trên phương tiện ngoại tuyến hoặc ở nơi lưu trữ không thể ghi đè.
Nên kiểm tra khả năng khôi phục từ bản sao lưu với tần suất như thế nào?: Cả hướng dẫn của IPA và hướng dẫn của CISA đều chỉ nói "định kỳ" và không đưa ra con số cụ thể. Hướng dẫn của IPA có nêu trường hợp một công ty diễn tập khôi phục hai lần mỗi năm đã đưa hệ thống cốt lõi hoạt động trở lại năm ngày sau khi phát hiện bị tấn công. Hãy quyết định doanh nghiệp có thể ngừng hoạt động trong bao lâu và điểm khôi phục được phép cũ đến mức nào, rồi kiểm tra với tần suất đủ để xác nhận bạn đáp ứng được các mục tiêu đó.

Hồ sơ tác giả

Trang giới thiệu tác giả bài viết.

Go Komura

Đại diện của KomuraSoft LLC

Chuyên về phát triển phần mềm Windows, tư vấn kỹ thuật và điều tra lỗi, với thế mạnh ở các dự án còn tài sản hiện có và việc điều tra những sự cố khó nhìn ra nguyên nhân.

Xem hồ sơ Liên hệ

Liên kết công khai

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

Quay lại blog