Backup là thứ bạn đã khôi phục được, không phải thứ bạn đang lưu
Phần lớn tổ chức bị ransomware đánh sập đều có backup. Vấn đề nằm ở hai chỗ ít ai đo: kho backup là mục tiêu bị nhắm tới trong 96% các cuộc tấn công, và khi kẻ tấn công nằm im nhiều tháng trước khi mã hoá thì bản sao gần nhất — thứ mà mọi thiết kế backup đều tối ưu — chính là bản đã nhiễm.
10 giờ sáng 24/3/2024, hệ thống của VNDIRECT bị tấn công mã hoá dữ liệu. Giao dịch của một trong những công ty chứng khoán lớn nhất thị trường tê liệt gần một tuần và chỉ hoạt động trở lại vào sáng 1/4. Chín ngày sau đó, đến lượt PVOIL: hệ thống công nghệ thông tin ngừng hoạt động, kể cả phần phát hành hoá đơn điện tử cho bán hàng.
Điều đáng chú ý không phải là hai tổ chức này không có backup. Một công ty chứng khoán top đầu và một tổng công ty xăng dầu nhà nước đều có hệ thống sao lưu, có quy trình, có hồ sơ. Điều đáng chú ý là có backup mà vẫn mất tám ngày.
Khoảng cách giữa "có bản sao dữ liệu" và "hoạt động trở lại" là phần mà gần như không tổ chức nào đo trước khi cần đến nó. Bài này nói về khoảng cách đó: vì sao nó tồn tại, vì sao nó rộng hơn mọi người tưởng, và đo nó bằng cách nào.
Chỉ số đúng, nhưng đang đo sai chiều
Hai chỉ số chuẩn của thiết kế dự phòng là RTO (bao lâu thì chạy lại được) và RPO (mất tối đa bao nhiêu dữ liệu). Cả hai đều đúng, và cả hai đều sinh ra từ một mô hình sự cố cụ thể: hỏng ổ cứng, xoá nhầm bảng, cháy phòng máy, ngập tầng hầm. Trong mô hình đó, bản sao gần nhất luôn là bản tốt nhất. Toàn bộ nỗ lực kỹ thuật vì thế dồn vào việc kéo RPO xuống — sao lưu dày hơn, replication gần thời gian thực, snapshot mỗi mười lăm phút.
Ransomware hiện đại phá vỡ đúng giả định đó. Theo Báo cáo an ninh mạng Việt Nam 2025 của Hiệp hội An ninh mạng quốc gia, chiến thuật phổ biến hiện nay là chiến thuật kép: sau khi xâm nhập, kẻ tấn công không vội mã hoá mà nằm im lâu dài để rút dữ liệu quan trọng đem bán hoặc trao đổi; chỉ khi không còn gì để lấy nữa họ mới mã hoá để tống tiền.
Hệ quả với backup rất trực tiếp. Nếu kẻ tấn công đã ở trong hệ thống chín mươi ngày trước khi bấm nút, thì mọi bản sao trong chín mươi ngày đó đều được tạo ra từ một hệ thống đã bị kiểm soát. Bản gần nhất — bản mà toàn bộ thiết kế đang tối ưu — là bản nhiễm sâu nhất.
Câu hỏi thật vì thế không phải "bản sao gần nhất cách đây bao lâu" mà "lùi lại được bao xa mà vẫn dùng được". Đó là một trục hoàn toàn khác, và nó cần một thiết kế khác: chu kỳ lưu giữ đủ dài, các bản cũ vẫn khôi phục được, và một cách để biết bản nào là bản sạch cuối cùng.
Trục thứ hai này gần như không bao giờ xuất hiện trong hợp đồng dịch vụ. SLA thường cam kết tần suất sao lưu và thời gian khôi phục, chứ hiếm khi cam kết "khôi phục được về mốc chín mươi ngày trước". Nếu bạn chỉ đọc một dòng trong hợp đồng backup của mình, hãy đọc dòng nói về thời hạn lưu giữ.
Kho backup không phải nơi trú ẩn — nó là mục tiêu đầu tiên
Giả định ngầm thứ hai là kho backup nằm ngoài cuộc chiến. Nó không.
Khảo sát 1.200 tổ chức từng bị ransomware trong báo cáo Veeam Ransomware Trends được tổng hợp lại ở đây cho thấy kho backup bị nhắm tới trong 96% các cuộc tấn công và bị xâm phạm thành công trong 76%. Trung bình chỉ 57% dữ liệu bị ảnh hưởng được khôi phục — nghĩa là 43% không lấy lại được.
Đây không phải chi tiết kỹ thuật phụ. Phân tích của Sophos về tác động của việc backup bị xâm phạm cho thấy chi phí khôi phục trung vị của nhóm có backup bị phá là 3 triệu USD, gấp tám lần nhóm giữ được backup nguyên vẹn (375 nghìn USD). Khoản tiền chuộc trung vị cũng gần gấp đôi: 2 triệu so với 1,062 triệu USD. Lý do dễ hiểu — mất backup là mất toàn bộ vị thế đàm phán.
Ghép thêm một số liệu nữa thì bức tranh rõ hẳn. Báo cáo State of Ransomware 2026 của Sophos, khảo sát 2.158 lãnh đạo CNTT và an ninh có tổ chức bị tấn công trong mười hai tháng qua, ghi nhận 79% các vụ có yếu tố danh tính bị chiếm, và tỷ lệ tấn công mã hoá được dữ liệu tăng từ 50% lên 56%.
Danh tính là mắt xích, và đó chính là chỗ phần lớn kiến trúc backup hở ra: kho backup thường nằm cùng miền danh tính với production. Cùng Active Directory, cùng tenant đám mây, cùng nhóm quản trị, cùng SSO. Tiện cho vận hành, và cũng có nghĩa là một tài khoản quản trị bị chiếm sẽ hạ cả hai cùng lúc.
Diễn đạt cách khác: một kho backup mà production có quyền xoá thì không phải backup — nó chỉ là thêm một bản production.
Ba thuộc tính phân biệt bản backup với bản sao
- Bất biến trong một khoảng thời gian không rút ngắn được. Object lock, WORM, hoặc chính sách giữ có khoá pháp lý — điểm mấu chốt là *kể cả tài khoản quản trị cao nhất cũng không xoá được trước hạn*. Nếu một quyền nào đó rút ngắn được thời hạn ấy, thì đó là quyền mà kẻ tấn công sẽ đi tìm.
- Tách miền danh tính. Thông tin xác thực riêng, MFA riêng, không join vào domain của production, không dùng chung SSO. Hạ tầng backup nên được coi là một vùng an ninh riêng biệt, giống cách zones and conduits tách vùng điều khiển công nghiệp khỏi mạng văn phòng.
- Ít nhất một bản không tiếp cận được trực tuyến. Băng từ, ổ tháo rời, hoặc một tài khoản ở nhà cung cấp khác mà production không có đường tới. Đây là bản trả lời cho câu hỏi "nếu toàn bộ miền quản trị của chúng tôi bị chiếm thì sao".
Quy tắc 3-2-1 quen thuộc — ba bản sao, hai loại phương tiện, một bản ngoài site — vẫn đúng nhưng không còn đủ, vì nó chỉ nói về *thiên tai và hỏng hóc*. Phiên bản đang được dùng phổ biến hơn hiện nay là 3-2-1-1-0: thêm một bản bất biến hoặc offline, và 0 lỗi trong lần kiểm tra khôi phục gần nhất. Con số 0 cuối cùng là phần khó nhất, và là phần bị bỏ qua nhiều nhất.
Nút thắt thật khi khôi phục là thứ tự, không phải dung lượng
Số liệu 2026 có một điểm thoạt nhìn thì mâu thuẫn. Tỷ lệ tổ chức khôi phục được dữ liệu bằng backup tăng lên 66%, hơn năm trước 12 điểm phần trăm — một cải thiện thật. Nhưng chi phí khôi phục trung bình vẫn tăng 11%, lên 1,7 triệu USD mỗi sự cố.
Nếu tốc độ đọc dữ liệu từ backup là nút thắt thì hai con số này phải đi ngược chiều nhau. Chúng không đi ngược, vì nút thắt nằm ở chỗ khác: thứ tự khôi phục.
Danh sách backup ở hầu hết tổ chức được lập theo một tiêu chí rất hợp lý — hệ thống nào chứa dữ liệu quan trọng. Nhưng khi phải dựng lại từ một môi trường trống, thứ phải lên trước lại là những thứ không chứa dữ liệu nghiệp vụ nào cả:
- DNS nội bộ và dịch vụ cấp phát địa chỉ, vì không có chúng thì không thành phần nào tìm thấy thành phần nào.
- Thư mục danh tính (AD, LDAP, IdP), vì không có nó thì không ai đăng nhập được vào bất cứ đâu.
- Kho bí mật và CA nội bộ, vì không có chúng thì các dịch vụ không xác thực được với nhau.
- Image registry, kho gói nội bộ và máy chủ cấp phép, vì không có chúng thì không deploy lại được.
- Và chính hệ thống backup — phần mềm điều phối, catalog, khoá mã hoá của kho lưu trữ.
Bỏ sót nhóm này tạo ra những vòng lặp chết rất đặc trưng, và tổ chức nào cũng gặp ít nhất một cái trong lần diễn tập đầu tiên: mật khẩu để khôi phục nằm trong trình quản lý mật khẩu, trình quản lý mật khẩu xác thực qua SSO, SSO chạy trên máy chủ chưa khôi phục. Hoặc: quy trình khôi phục nằm trên wiki nội bộ, wiki nội bộ cũng vừa bị mã hoá.
Đây cũng là lý do một cuộc diễn tập kiểu "khôi phục thử một database" gần như không nói lên điều gì. Nó kiểm tra đúng phần đã hoạt động tốt sẵn — đọc dữ liệu ra từ bản sao — và bỏ qua toàn bộ phần thật sự tốn thời gian trong sự cố thật.
Bài kiểm tra một buổi chiều
Không cần dự án, không cần mua thêm gì. Bốn bước, mỗi bước cho ra một con số hoặc một danh sách.
- Khôi phục một hệ thống thật vào môi trường trống và bấm đồng hồ. Chọn một hệ thống có người dùng thật. Dựng lại nó ở nơi không có sẵn gì. Đo từ lúc bắt đầu đến lúc một người dùng thật đăng nhập và hoàn thành một nghiệp vụ đầu-cuối. Đó là RTO thật.
- Xác định ai xoá được backup. Liệt kê mọi tài khoản có thể xoá bản sao, sửa chính sách lưu giữ, hoặc rút ngắn thời hạn bất biến. Nếu danh sách đó giao với danh sách quản trị viên production, bạn vừa tìm ra rủi ro lớn nhất của mình.
- Vẽ đồ thị phụ thuộc khởi động lại. Cái gì phải sống trước khi hệ thống nghiệp vụ đầu tiên chạy được. Đối chiếu với danh sách đang được sao lưu. Khoảng chênh giữa hai danh sách là phần dễ sửa nhất và thường bị bỏ quên lâu nhất.
- Khôi phục từ bản chín mươi ngày trước. Không phải bản gần nhất. Ba thứ hay hỏng âm thầm ở đây: định dạng backup cũ mà phần mềm hiện tại không đọc được, khoá mã hoá đã xoay vòng, và lược đồ dữ liệu cũ mà ứng dụng hiện tại không chạy được. Cả ba đều chỉ lộ ra khi thử.
Ba con số nên ghi lại sau mỗi lần chạy: mất bao lâu, cần bao nhiêu người, và bao nhiêu bước phải ứng biến ngoài quy trình. Con số thứ ba là chỉ báo tốt nhất cho việc quy trình có bám sát thực tế hay không.
Bối cảnh Việt Nam
Số liệu 2025 của Hiệp hội An ninh mạng quốc gia có một cặp con số đáng chú ý: tổng số cuộc tấn công vào hệ thống thông tin tại Việt Nam giảm 19,38%, còn khoảng 552.000 vụ; nhưng tỷ lệ tổ chức, doanh nghiệp ghi nhận thiệt hại lại tăng từ 46,15% lên 52,30%. Ít vụ hơn, nhưng mỗi vụ đắt hơn — đúng với hướng dịch chuyển từ tấn công diện rộng sang tấn công có chọn lọc, nằm vùng lâu và rút dữ liệu trước khi mã hoá.
Mặt tích cực là khoảng 51,45% đơn vị đã tổ chức diễn tập an ninh mạng. Điều đáng hỏi tiếp theo là các buổi diễn tập ấy diễn tập cái gì: phát hiện xâm nhập, hay khôi phục từ số không. Hai bài tập này rèn hai năng lực khác nhau, và chỉ bài thứ hai trả lời được câu hỏi "tám ngày hay tám tiếng".
Về pháp lý, Nghị định 85/2016/NĐ-CP về bảo đảm an toàn hệ thống thông tin theo cấp độ đã đặt yêu cầu về phương án dự phòng và khôi phục tương ứng với từng cấp độ. Như với mọi khung tuân thủ, hồ sơ mô tả hệ thống ở thời điểm lập hồ sơ; khả năng chống chịu thì được quyết định ở thời điểm sự cố xảy ra.
Có một mâu thuẫn thực tế đáng nói riêng, vì nó rơi vào đúng khe giữa hai bộ phận. Chiến lược chống ransomware đẩy về phía giữ lâu và không xoá được; trong khi Luật Bảo vệ dữ liệu cá nhân đẩy về phía xoá được khi hết mục đích hoặc khi chủ thể yêu cầu. Bản backup chứa dữ liệu cá nhân vẫn là dữ liệu cá nhân, nhưng một bản backup bất biến thì theo định nghĩa là không xoá chọn lọc được.
Cách xử lý thông dụng không phải là chọn một bên, mà là tách hai chế độ: định nghĩa rõ thời hạn lưu giữ của backup, ghi nhận rằng yêu cầu xoá sẽ được thực thi trên hệ thống đang chạy ngay và trên các bản sao khi chúng hết hạn theo chu kỳ, và không khôi phục dữ liệu đã xoá trở lại production khi phục hồi từ bản cũ. Điểm cuối cùng cần một danh sách các bản ghi đã xoá được lưu ngoài phạm vi backup — chi tiết nhỏ, nhưng thiếu nó thì mỗi lần khôi phục là một lần vô tình hồi sinh dữ liệu lẽ ra không còn tồn tại.
Kết luận
VNDIRECT có backup. PVOIL có backup. Phần lớn tổ chức bị ransomware đánh sập trong hai năm qua đều có backup. Backup chưa bao giờ là câu trả lời cho câu hỏi này — nó chỉ là điều kiện cần.
Ba thứ quyết định kết quả nằm ở chỗ khác, và cả ba đều đo được trước khi cần đến: kho backup có nằm ngoài tầm với của danh tính đã bị chiếm hay không, chu kỳ lưu giữ có đủ dài để lùi qua khỏi thời gian kẻ tấn công nằm vùng hay không, và thứ tự khởi động lại đã từng được chạy thử từ số không hay chưa.
Ngày phát hiện sự cố là ngày tệ nhất để lần đầu biết câu trả lời. Một buổi chiều diễn tập cho bạn ba con số thật, và ba con số thật đáng giá hơn một tập hồ sơ dự phòng viết rất đúng.
Nếu bạn muốn biết RTO thật của một hệ thống cụ thể — không phải con số trong tài liệu — liên hệ với chúng tôi để chạy thử một lần khôi phục, hoặc xem năng lực Server & Database của KonexForge.
Bài viết liên quan
Cáp biển lại đứt: tự kiểm tra đường truyền trong 10 phút, và biết khi nào mới cần mua thêm
Ngày 25/8, ba trong sáu tuyến cáp biển của Việt Nam cùng hỏng. Bài này không bàn lý thuyết dự phòng — nó chỉ ra bốn lệnh bạn gõ được ngay để biết đường truyền của mình đi đâu và có đang tắc không, cách kiểm tra máy chủ của bạn đặt ở đâu bằng một con số, và bảng giá thật của từng phương án dự phòng để biết cái nào đáng mua.
Migrate database không downtime: dual-write, backfill và cutover an toàn cho hệ thống đang chạy
Đổi engine database, tách schema, hay chuyển nhà cung cấp cloud cho một hệ thống đang phục vụ khách hàng thật không thể giải quyết bằng một cửa sổ bảo trì nửa đêm nữa. Bốn giai đoạn của một migration an toàn — dual-write, backfill, verify, cutover — và những cái bẫy phổ biến nhất ở từng bước.
Kubernetes cho ML và data workload: thiết kế cluster từ node pool đến GPU scheduling
Kubernetes là tiêu chuẩn cho container orchestration — nhưng cấu hình mặc định không đủ cho ML workload. GPU node cần taint và toleration riêng; training job có thể chiếm hết cluster nếu không có resource quota; model serving cần PodDisruptionBudget để không bị interrupt giữa inference. Bốn vấn đề thường gặp và cách thiết kế cluster đúng ngay từ đầu.