CYBER RESILIENCE ARCHITECTURE – BACKUP: NỀN TẢNG SỐNG CÒN CỦA RESILIENCE: Backup cho OT/SCADA

Trong lĩnh vực Cyber Resilience Architecture, chúng ta thường tập trung nhiều vào các lớp phòng thủ (security controls) hay các công cụ chống ransomware tiên tiến. Nhưng khi sự cố lớn xảy ra—điều không thể tránh khỏi—thì khả năng sống sót của doanh nghiệp lại được quyết định bởi một yếu tố tưởng chừng đơn giản, nhưng lại là nền tảng tối thượng: Hệ thống sao lưu và phục hồi (Backup & Recovery).

Trong kiến trúc Cyber Resilience, Backup không chỉ là việc copy dữ liệu; nó là một luồng nghiệp vụ phức tạp, một lớp bảo vệ cuối cùng, và là bằng chứng sống về khả năng duy trì vận hành (Business Continuity). Nếu Backup là nền tảng của mọi kiến trúc phục hồi, thì Backup cho môi trường Công nghệ Vận hành (Operational Technology – OT), đặc biệt là các hệ thống Điều khiển Giám sát và Thu thập Dữ liệu (SCADA) hay Hệ thống Điều khiển Công nghiệp (ICS), lại là một bài toán hoàn toàn khác biệt, đòi hỏi một tư duy thiết kế kiến trúc phục hồi hoàn toàn riêng biệt.

Sai lầm phổ biến nhất không nằm ở việc doanh nghiệp có backup hay không, mà nằm ở việc họ thiết kế, triển khai và quản trị backup theo mô hình của IT thông thường, gán ghép vào một môi trường OT có các yêu cầu về Tính sẵn sàng (Availability) và Yêu cầu về Thời gian Phục hồi (RTO) cực kỳ ngặt nghèo. Khi rủi ro tấn công mạng (như ransomware) lan sang môi trường OT, hậu quả không chỉ là mất dữ liệu mà là dừng toàn bộ hoạt động sản xuất, năng lượng, hoặc cung cấp dịch vụ công cộng.

Bài chia sẻ này sẽ không nói về 3-2-1 hay quy tắc cơ bản; chúng ta sẽ đào sâu vào bản chất kiến trúc và các điểm gãy tiềm ẩn khi xây dựng khả năng phục hồi (Resilience) cho các môi trường OT/SCADA.

---

MỤC LỤC

PHẦN I. THIẾT LẬP BỐI CẢNH: TẠI SAO BACKUP CHO OT LẠI LÀ MỘT “CUỘC CHIẾN RTO/RPO” KHÁC

• 1.1. Cyber Resilience vs. Cyber Security: Góc nhìn của OT
• 1.2. Định nghĩa lại RTO và RPO trong môi trường Điều khiển Công nghiệp
• 1.3. Bản chất của OT: Sự phân mảnh, Kế thừa và Tính sẵn sàng tối thượng

PHẦN II. BẢN CHẤT KIẾN TRÚC OT: NHỮNG THÁCH THỨC ĐỘC NHẤT ĐỐI VỚI BACKUP

• 2.1. Phân tích Dữ liệu OT: Không chỉ là Dữ liệu (Data-in-Motion)
• 2.2. Sự khác biệt giữa Sao lưu Dữ liệu Quy trình (Process Data) và Cấu hình Hệ thống (Control Logic)
• 2.3. Vấn đề Tương thích: Khi hệ thống cũ từ chối sự Phục hồi hiện đại
• 2.4. Điểm gãy Dữ liệu: Lớp Vận hành (HMI) và Lớp Kiểm soát (PLC/DCS)

PHẦN III. SAI LẦM TƯ DUY VÀ TRIỂN KHAI HỦY HOẠI KHẢ NĂNG PHỤC HỒI

• 3.1. Sai lầm về Mô hình Quản trị: Giao phó OT Backup hoàn toàn cho IT
• 3.2. Sai lầm Kỹ thuật: Sử dụng công cụ Backup không chuyên cho OT
• 3.3. Hiểu sai về Air-Gap và Tính bất biến (Immutability) trong OT
• 3.4. Thử nghiệm Phục hồi (DR Test): Kịch bản Thảm họa Vận hành

PHẦN IV. XÂY DỰNG KIẾN TRÚC BACKUP RESILIENCE BỀN VỮNG CHO OT

• 4.1. Nguyên tắc Zero Trust trong OT Resilience: Không tin tưởng ngay cả dữ liệu backup
• 4.2. Thiết kế Kiến trúc Lưu trữ Bất biến (Immutable Storage) cho Môi trường OT cô lập
• 4.3. Chiến lược Air-Gap Vật lý và Logic: Khi nào cần di chuyển đĩa, khi nào cần Air-Gap ảo
• 4.4. Đảm bảo RPO/RTO: Kết hợp Backup, Replication và Snapshot Cấu hình

PHẦN V. VAI TRÒ CỦA QUẢN TRỊ VÀ VẬN HÀNH: ĐIỂM GÃY PHI KỸ THUẬT

• 5.1. Phân định Quyền và Trách nhiệm: Giữa Kiến trúc sư, Vận hành viên và Quản trị Rủi ro
• 5.2. Chuẩn hóa Quy trình: Từ Ghi nhận Thay đổi Cấu hình đến Phục hồi Thảm họa
• 5.3. Xây dựng Kịch bản Phục hồi sau Tấn công (Playbook)

PHẦN VI. PHÂN TÍCH CHUYÊN SÂU: VÍ DỤ THỰC TIỄN VỀ LỖ HỔNG KIẾN TRÚC OT BACKUP

• 6.1. Case Study 1: Nhà máy Năng lượng và Thảm họa Cấu hình HMI/SCADA
• 6.2. Case Study 2: Sản xuất Vật liệu và Ảo tưởng về Air-Gap Vật lý

PHẦN VII. HÀNH ĐỘNG CỤ THỂ VÀ LỜI KẾT

---

PHẦN I. THIẾT LẬP BỐI CẢNH: TẠI SAO BACKUP CHO OT LẠI LÀ MỘT “CUỘC CHIẾN RTO/RPO” KHÁC

1.1. Cyber Resilience vs. Cyber Security: Góc nhìn của OT

Cyber Security (An ninh mạng) là tập trung vào việc ngăn chặn. Chúng ta cố gắng dựng các tường lửa, thiết lập IDPS, vá lỗ hổng để không bị tấn công. Nhưng khi làm việc trong môi trường OT/SCADA—nơi các thiết bị điều khiển quy trình có tuổi đời 15-20 năm, chạy trên hệ điều hành không thể vá, và phải duy trì hoạt động 24/7/365—thì phòng thủ chỉ là một phần nhỏ của phương trình.

Cyber Resilience (Khả năng Phục hồi trước Tấn công mạng) thừa nhận rằng thất bại là điều không thể tránh khỏi. Mục tiêu của Resilience không phải là 100% không bị xâm nhập, mà là đảm bảo rằng khi bị xâm nhập, khả năng chịu đựng và tốc độ quay lại vận hành phải đạt mức tối ưu được xác định trước.

Trong OT, một cuộc tấn công ransomware không nhằm mã hóa dữ liệu kế toán, mà nhằm làm gián đoạn hoặc phá hủy các thành phần điều khiển quy trình (PLC, DCS, RTU, HMI). Khi điều này xảy ra, hệ thống Backup & Recovery trở thành tuyến phòng thủ duy nhất. Nhưng việc phục hồi lại một dây chuyền sản xuất hay một trạm biến áp phức tạp hơn nhiều so với việc khởi động lại một máy chủ ảo.

1.2. Định nghĩa lại RTO và RPO trong môi trường Điều khiển Công nghiệp

Tham số quan trọng nhất trong Resilience là RTO (Recovery Time Objective – Mục tiêu Thời gian Phục hồi) và RPO (Recovery Point Objective – Mục tiêu Điểm Phục hồi).

Trong IT, RTO có thể là 4 giờ, 12 giờ, hoặc thậm chí 24 giờ cho các hệ thống phụ trợ. RPO thường là 4 giờ, 1 ngày, hoặc 1 tuần tùy theo mức độ quan trọng của dữ liệu.

Trong OT, các con số này thay đổi triệt để:

• RPO (OT): Thường được đo bằng phút hoặc giây. Dữ liệu thu thập từ cảm biến, dữ liệu thời gian thực (Time Series Data), hoặc dữ liệu nhật ký quy trình sản xuất (Batch Record) là vô giá. Mất 1 giờ dữ liệu quy trình có thể dẫn đến việc mất kiểm soát về chất lượng sản phẩm, hoặc tệ hơn, mất khả năng tuân thủ quy định pháp lý (Regulatory Compliance) cho toàn bộ lô hàng.
• RTO (OT): Phải là gần như tức thì đối với các hệ thống kiểm soát cấp 1 và cấp 2 (PLC/DCS). Một nhà máy điện không thể ngừng hoạt động 4 giờ để chờ IT phục hồi server; việc dừng đột ngột (Emergency Shutdown) và khởi động lại (Startup sequence) là một quy trình kỹ thuật phức tạp, tốn kém và nguy hiểm. Mục tiêu RTO trong OT phải bao gồm không chỉ việc khôi phục máy tính, mà còn phải khôi phục logic điều khiển và vận hành quy trình (Process Control Logic).

Điều này đòi hỏi kiến trúc backup cho OT phải chuyển từ mô hình “lưu trữ dài hạn” sang mô hình “khả năng chuyển đổi tức thời” (Instant Recovery/Failover).

1.3. Bản chất của OT: Sự phân mảnh, Kế thừa và Tính sẵn sàng tối thượng

Môi trường OT không đồng nhất. Chúng là một hỗn hợp của:

1. Thiết bị Cũ Kỹ (Legacy): Máy tính chạy Windows NT/XP/7 vì đó là hệ điều hành duy nhất tương thích với phần mềm điều khiển từ 15 năm trước.
2. Giao thức Độc Quyền (Proprietary Protocols): Modbus, OPC, DNP3, Profibus/Profinet, v.v., không phải là TCP/IP đơn thuần.
3. Mức độ Liên thông Thấp: Mặc dù đang có xu hướng IT/OT Convergence, nhưng nhiều hệ thống vẫn được cách ly vật lý hoặc logic rất nghiêm ngặt.
4. Ưu tiên Vận hành: Bất kỳ thao tác nào, kể cả backup, không được phép gây ra độ trễ (latency) hoặc làm gián đoạn luồng điều khiển.

Những yếu tố này làm cho việc áp dụng các giải pháp backup và bảo mật tiêu chuẩn của IT vào OT là một công thức dẫn đến thảm họa.

---

PHẦN II. BẢN CHẤT KIẾN TRÚC OT: NHỮNG THÁCH THỨC ĐỘC NHẤT ĐỐI VỚI BACKUP

Để thiết kế kiến trúc phục hồi cho OT, chúng ta phải hiểu rõ bốn loại “dữ liệu” trong môi trường này, vì mỗi loại yêu cầu một chiến lược bảo vệ và phục hồi khác nhau.

2.1. Phân tích Dữ liệu OT: Không chỉ là Dữ liệu (Data-in-Motion)

Trong một hệ thống OT điển hình (ví dụ: mô hình Purdue), có bốn lớp dữ liệu cần phải được backup:

Lớp	Loại Dữ liệu	Ví dụ	Yêu cầu RPO/RTO	Chiến lược Backup
L0/L1 (Điều khiển)	Firmware và Cấu hình Điều khiển	Logic PLC/DCS, chương trình điều khiển, bảng tham số	RPO: Near-zero. RTO: Tối thiểu (phải nạp lại nhanh)	Snapshot cấu hình, lưu trữ trên hệ thống chuyên dụng, kiểm soát phiên bản nghiêm ngặt.
L2 (Giám sát)	Giao diện Vận hành và Thiết lập	Hệ điều hành (Windows Server/Client), phần mềm HMI, database tag name, mã hóa cấp giấy phép	RPO: Vài giờ. RTO: Vài giờ (cần khôi phục giao diện điều khiển)	Image level backup, Virtualization-aware backup.
L3 (Sản xuất)	Dữ liệu Quy trình và Lịch sử	Database SCADA/Historian (Time Series Data), dữ liệu MES (Manufacturing Execution System)	RPO: Vài phút. RTO: Vài giờ (cần tiếp tục ghi nhận lịch sử)	Application-aware backup, Replication tốc độ cao.
L4 (Doanh nghiệp)	Dữ liệu Đã xử lý (đã xuất)	Báo cáo sản xuất, dữ liệu chất lượng đã chuyển sang ERP	RPO/RTO: Theo chuẩn IT	Backup tiêu chuẩn, Replication.

Nếu kiến trúc backup chỉ tập trung vào L4 (Data đã chuyển lên IT) hoặc L3 (Historian database), mà bỏ qua L0/L1/L2 (Cấu hình Điều khiển), thì khi xảy ra sự cố, doanh nghiệp có thể mất dữ liệu lịch sử, nhưng quan trọng hơn, sẽ mất khả năng khởi động lại quy trình sản xuất.

2.2. Sự khác biệt giữa Sao lưu Dữ liệu Quy trình (Process Data) và Cấu hình Hệ thống (Control Logic)

Dữ liệu quy trình (Process Data) là dòng chảy liên tục của các giá trị cảm biến. Nếu mất, chúng ta mất lịch sử. Việc khôi phục nó có thể chậm hơn một chút, miễn là hệ thống có thể tiếp tục ghi nhận dữ liệu mới.

Tuy nhiên, Cấu hình Hệ thống (Control Logic) là linh hồn của OT. Đây là các tệp nhị phân chứa logic điều khiển PLC/DCS, mã hóa cách máy móc tương tác, các thuật toán kiểm soát vòng lặp kín (closed-loop control).

• Thách thức về Ransomware: Kẻ tấn công hiện nay biết rõ rằng nếu chúng mã hóa hoặc phá hủy các tệp cấu hình này, việc phục hồi sẽ cực kỳ khó khăn. Bởi vì các tệp cấu hình này thường nằm trong các thiết bị cũ, không được quản lý bởi các giải pháp backup IT truyền thống, và thường không được cập nhật phiên bản.
• Điểm Gãy Kiến Trúc: Hầu hết các giải pháp backup truyền thống tập trung vào Volume/Image Backup. Chúng thất bại trong việc quản lý và kiểm soát phiên bản (Version Control) của hàng trăm tệp cấu hình nhỏ nhưng quan trọng này. Khi cần phục hồi, OT Engineer cần phiên bản cấu hình chính xác vào thời điểm trước sự cố, không phải phiên bản của một tháng trước, nếu không sẽ gây ra xung đột điều khiển.

2.3. Vấn đề Tương thích: Khi hệ thống cũ từ chối sự Phục hồi hiện đại

Nhiều hệ thống OT không hỗ trợ các tác nhân (agents) của phần mềm backup hiện đại, hoặc việc cài đặt agent sẽ làm mất chứng nhận bảo hành từ nhà cung cấp (OEM). Thậm chí nếu có thể backup, các máy tính công nghiệp (Industrial PCs) quá cũ có thể không hỗ trợ việc phục hồi nhanh chóng (Bare Metal Recovery) lên phần cứng mới hoặc phục hồi vào môi trường ảo hóa hiện đại.

Kiến trúc sư Resilience phải đối mặt với thực tế:

1. Backup không đủ: Phải có một kho lưu trữ các Image phục hồi cho các phần cứng legacy cụ thể, và quan trọng hơn là phải có các môi trường kiểm thử (Staging/Sandbox Environment) để đảm bảo Image cũ có thể chạy lại trên phần cứng thay thế.
2. Sự trôi dạt (Configuration Drift): Cấu hình HMI và PLC thường được điều chỉnh nhỏ bởi các kỹ sư vận hành theo thời gian. Nếu quy trình backup không đi kèm với quy trình Quản lý Thay đổi Cấu hình (Change Management), việc phục hồi sẽ đưa hệ thống về trạng thái cũ không còn phù hợp với quy trình vật lý hiện tại. Đây là lý do khiến nhiều đợt DR Test cho OT thất bại thảm hại.

2.4. Điểm gãy Dữ liệu: Lớp Vận hành (HMI) và Lớp Kiểm soát (PLC/DCS)

Hệ thống HMI (Human-Machine Interface) là lớp giao tiếp giữa người vận hành và quy trình. Các máy chủ HMI thường là mục tiêu dễ nhất để ransomware tấn công vì chúng chạy Windows tiêu chuẩn và có kết nối IT/OT. Nếu HMI bị mã hóa, người vận hành sẽ bị “mù”, không thể giám sát hay can thiệp.

Nhưng thảm họa lớn hơn là khi tấn công lan xuống PLC/DCS (Lớp Điều khiển). Trong kịch bản này, việc phục hồi không chỉ là khôi phục tệp, mà là nạp lại firmware và logic điều khiển vào thiết bị vật lý. Việc này đòi hỏi công cụ chuyên dụng, kỹ sư OT được đào tạo chuyên sâu và một quy trình phục hồi đã được kiểm tra nghiêm ngặt.

Sai lầm kiến trúc là khi chúng ta xây dựng giải pháp immutable backup chỉ tập trung vào việc bảo vệ các file trên L3/L4, trong khi kẻ tấn công có thể làm hỏng logic điều khiển trên L1/L2 mà không cần mã hóa bất kỳ tệp nào.

---

PHẦN III. SAI LẦM TƯ DUY VÀ TRIỂN KHAI HỦY HOẠI KHẢ NĂNG PHỤC HỒI

3.1. Sai lầm về Mô hình Quản trị: Giao phó OT Backup hoàn toàn cho IT

Đây là điểm gãy quản trị phổ biến nhất. Ban lãnh đạo thường giao trách nhiệm “backup” cho đội IT, vì họ là chuyên gia về lưu trữ và ảo hóa. Tuy nhiên, đội IT thường không hiểu:

• Tính nhạy cảm của OT: Một tác vụ backup không được tối ưu hóa có thể gây ra độ trễ mạng (network jitter) và ảnh hưởng trực tiếp đến tín hiệu điều khiển thời gian thực (real-time control loop), dẫn đến sự cố vận hành.
• Bản chất của phục hồi: Phục hồi OT không phải là “next-next-finish”. Nó đòi hỏi sự phối hợp với kỹ sư điện/cơ khí để đảm bảo rằng khi hệ thống điều khiển được khôi phục, quy trình vật lý cũng sẵn sàng và an toàn để tiếp nhận lệnh mới.

Hệ quả dài hạn: Khi xảy ra sự cố, IT phục hồi xong các máy chủ, nhưng OT Engineer không thể khởi động lại quy trình vì thiếu các tệp cấu hình chuyên biệt hoặc các cài đặt tương thích phần cứng. RTO thực tế bị kéo dài gấp 10 lần so với ước tính ban đầu.

3.2. Sai lầm Kỹ thuật: Sử dụng công cụ Backup không chuyên cho OT

Sử dụng phần mềm backup IT tiêu chuẩn trong môi trường OT thường dẫn đến các vấn đề sau:

• Đòi hỏi Agents: Nhiều phần mềm backup yêu cầu cài đặt Agent trên máy chủ/máy trạm. Nếu các thiết bị OT là legacy hoặc chạy các hệ điều hành chuyên biệt, việc này là bất khả thi hoặc bị cấm bởi nhà cung cấp.
• Tải hệ thống cao: Backup IT thường chạy tác vụ quét và nén dữ liệu rất nặng. Trong môi trường OT, CPU và IOPS (Input/Output Operations Per Second) của các máy chủ HMI hoặc Historian bị chiếm dụng có thể ảnh hưởng đến khả năng xử lý dữ liệu thời gian thực.
• Mất bối cảnh ứng dụng: Backup chỉ đơn giản là tạo ra một bản sao của ổ đĩa. Nó không đảm bảo rằng khi khôi phục, các ứng dụng chuyên biệt của SCADA/DCS (ví dụ: các dịch vụ chạy nền, cơ chế cấp phép) sẽ hoạt động đúng cách mà không cần cấu hình lại thủ công.

Kiến trúc Backup Resilience cho OT phải ưu tiên các giải pháp không cần Agent (Agentless) hoặc các giải pháp được chứng nhận bởi các nhà cung cấp OT lớn, hoặc phải thiết kế các cơ chế backup dựa trên ảnh chụp nhanh (Snapshot) chuyên biệt cho môi trường ảo hóa OT.

3.3. Hiểu sai về Air-Gap và Tính bất biến (Immutability) trong OT

Tính bất biến (Immutability) là trụ cột trong việc chống lại ransomware, đảm bảo rằng ngay cả khi kẻ tấn công chiếm được quyền quản trị cao nhất, chúng cũng không thể xóa hoặc mã hóa dữ liệu backup.

• Immutability trong IT: Thường đạt được qua các giải pháp lưu trữ phần mềm (Software-Defined Storage) hoặc lưu trữ đối tượng (Object Storage) với cơ chế Write-Once, Read-Many (WORM) hoặc thời gian giữ lại (Retention Lock).
• Immutability trong OT: Các hệ thống OT cũ không thể kết nối trực tiếp với các kho lưu trữ Immutability hiện đại vì lý do mạng hoặc giao thức. Việc áp dụng Immutability phải được thực hiện ở lớp trung gian: sử dụng một vùng đệm bảo mật (Secure Staging Area) tại ranh giới IT/OT, nơi dữ liệu backup được chuyển đổi, nén, và sau đó mới chuyển sang kho lưu trữ Immutability.

Air-Gap (Khoảng cách Không khí): Trong OT, Air-Gap thường bị hiểu lầm là “chỉ cần tách mạng vật lý.”

• Air-Gap Mạng: Tách biệt OT khỏi IT/Internet qua tường lửa hoặc thiết bị bảo mật chuyên dụng (Data Diode). Điều này tốt cho việc phòng thủ.
• Air-Gap Phục hồi: Đây mới là xương sống của Resilience. Dữ liệu backup OT phải được lưu trữ tại một nơi hoàn toàn không thể truy cập qua bất kỳ giao diện mạng nào từ môi trường sản xuất. Đối với OT, điều này thường dẫn đến các giải pháp Air-Gap vật lý (Physical Air-Gap) như việc di chuyển băng từ (Tape) hoặc đĩa cứng (Removable Disk Cartridges) ra khỏi mạng.

Sai lầm nghiêm trọng: Thiết kế Air-Gap nhưng lại sử dụng một máy chủ trung gian (Jump Server) có chung thông tin xác thực quản trị (Shared Credentials) với mạng OT để thực hiện thao tác chuyển dữ liệu. Nếu kẻ tấn công chiếm được tài khoản này, chúng sẽ vượt qua Air-Gap Logic.

3.4. Thử nghiệm Phục hồi (DR Test): Kịch bản Thảm họa Vận hành

Nếu DR Test cho IT là thử thách về thời gian khôi phục hệ thống thông tin, thì DR Test cho OT là thử thách về khả năng tái lập trạng thái vận hành an toàn và chính xác.

Sai lầm lớn nhất là:

1. Thiếu Kịch bản Phục hồi Đặc thù: Chỉ thử nghiệm khôi phục máy chủ HMI/Historian, mà không thử nghiệm việc nạp lại logic điều khiển PLC.
2. Không có Môi trường Thử nghiệm Tương đồng (Identical Staging): Việc phục hồi các Image OT legacy đòi hỏi một môi trường Sandbox/Staging có phần cứng, hệ điều hành và cấu hình mạng tương đương với môi trường sản xuất, để xác minh rằng khi khôi phục, phần mềm điều khiển sẽ nhận diện đúng các thiết bị ngoại vi và module I/O (Input/Output).

Nếu không thể chứng minh rằng sau khi phục hồi từ backup, quy trình OT có thể khởi động lại và duy trì hoạt động trong 8-12 giờ liên tục mà không gặp lỗi điều khiển, hệ thống backup đó không có giá trị phục hồi.

---

PHẦN IV. XÂY DỰNG KIẾN TRÚC BACKUP RESILIENCE BỀN VỮNG CHO OT

Việc thiết kế phải đi từ dưới lên (từ L0/L1) và đảm bảo rằng mỗi lớp có cơ chế phục hồi độc lập và được bảo vệ bất biến.

4.1. Nguyên tắc Zero Trust trong OT Resilience: Không tin tưởng ngay cả dữ liệu backup

Trong mô hình Zero Trust, chúng ta không tin tưởng bất kỳ ai, bất kỳ thiết bị nào, kể cả bên trong mạng. Khi áp dụng vào Backup Resilience:

1. Tách biệt Danh tính (Identity Separation): Tài khoản quản trị để thực hiện tác vụ backup (Backup Administrator) phải hoàn toàn khác biệt và độc lập với tài khoản quản trị mạng OT/IT thông thường. Kể cả khi kẻ tấn công chiếm được Domain Admin của IT hoặc tài khoản quản trị mạng OT, chúng không thể truy cập vào kho lưu trữ bất biến.
2. Xác minh Dữ liệu (Verification): Dữ liệu backup phải được kiểm tra tính toàn vẹn (Integrity Check) và quét mã độc (Malware Scan) trước khi được chuyển sang kho lưu trữ Immutability/Air-Gap, và trước khi được phục hồi.
3. Hạn chế Quyền Hủy diệt (Least Privilege): Hệ thống backup chỉ có quyền ghi (Write) vào kho Immutability trong một khung thời gian cực kỳ giới hạn (ví dụ: chỉ 15 phút sau khi tác vụ backup hoàn thành), và sau đó quyền truy cập phải bị khóa lại.

4.2. Thiết kế Kiến trúc Lưu trữ Bất biến (Immutable Storage) cho Môi trường OT cô lập

Vì môi trường OT thường bị cô lập, việc kết nối trực tiếp đến Cloud Storage hoặc các giải pháp Immutability trên IT là không khả thi và nguy hiểm.

Giải pháp Kiến trúc:

1. Vùng Bảo vệ Cục bộ (Local Protected Zone): Triển khai một thiết bị lưu trữ cục bộ (ví dụ: appliance backup chuyên dụng) trong mạng OT hoặc ranh giới OT/IT. Thiết bị này phải có khả năng lưu trữ bất biến riêng.
2. Sử dụng Mô hình Kéo (Pull Model) thay vì Đẩy (Push Model): Thay vì để máy chủ OT “đẩy” dữ liệu backup lên mạng IT (có thể bị chặn bởi Data Diode hoặc tường lửa nghiêm ngặt), hãy sử dụng một máy chủ trung gian bảo mật (Hardened Jumpbox) tại ranh giới để “kéo” dữ liệu ra khỏi OT, sau đó chuyển nó qua vùng đệm an toàn.
3. Kiểm soát Phiên bản Cấu hình PLC/HMI: Thay vì chỉ backup toàn bộ ổ đĩa HMI, cần có các công cụ chuyên biệt để tự động thu thập và lưu trữ chỉ các tệp cấu hình (ví dụ: file ladder logic, tag database) vào một kho lưu trữ Git hoặc kho lưu trữ phiên bản an toàn, được bảo vệ bởi WORM.

4.3. Chiến lược Air-Gap Vật lý và Logic: Khi nào cần di chuyển đĩa, khi nào cần Air-Gap ảo

Air-Gap là cần thiết để bảo vệ chống lại các cuộc tấn công nhắm vào hạ tầng backup (như mã độc nhắm vào phần mềm backup).

• Air-Gap Logic (Air-Gap Ảo): Sử dụng các cơ chế mạng như VLANs, ACLs, và tự động tắt kết nối mạng vật lý sau khi tác vụ backup hoàn thành. Đây là lựa chọn tốt cho RPO/RTO tương đối nhanh (vài giờ). Yêu cầu quản trị nghiêm ngặt về quyền truy cập để kích hoạt lại kết nối.
• Air-Gap Vật lý (Physical Air-Gap): Băng từ (Tape) hoặc đĩa cứng di động (Removable HDD Cartridges) được lưu trữ tại một địa điểm vật lý an toàn. Đây là lựa chọn tối ưu cho việc bảo vệ dài hạn trước các cuộc tấn công Zero-Day hoặc các thảm họa hủy hoại diện rộng.

Điểm Kiến Trúc Cần Lưu Ý: Đối với OT, Air-Gap vật lý thường là bắt buộc đối với các tệp cấu hình L0/L1 quan trọng nhất (như firmware và logic điều khiển). Nếu các tệp này bị hỏng, downtime sẽ kéo dài vô tận. Việc di chuyển thủ công các bản sao của cấu hình (đã mã hóa) ra khỏi mạng là biện pháp cuối cùng để đảm bảo khả năng phục hồi.

4.4. Đảm bảo RPO/RTO: Kết hợp Backup, Replication và Snapshot Cấu hình

Để đáp ứng RTO/RPO nghiêm ngặt của OT, kiến trúc phải là đa tầng:

Mục tiêu RTO/RPO	Công nghệ	Ứng dụng trong OT
Near-Zero RTO	Replication (tương tự DR)	Sao chép liên tục các máy chủ HMI/SCADA quan trọng nhất sang môi trường Standby/DR. Đảm bảo quy trình chuyển đổi tức thời (Failover).
Vài Phút RPO	Snapshot Cấu hình (Configuration Snapshot)	Thu thập các tệp cấu hình PLC/DCS/RTU theo chu kỳ nhỏ (1-5 phút) và lưu trữ cục bộ.
Vài Giờ RTO	Image/Volume Backup	Sao lưu toàn bộ máy chủ HMI/Historian để phục hồi nhanh chóng từ bản sao bất biến cục bộ.
Phòng vệ Tối thượng	Air-Gap Vật lý	Bản sao dự phòng của dữ liệu backup, được lưu trữ offline, chống lại sự phá hoại toàn bộ hạ tầng IT/OT.

Sự kết hợp này đảm bảo rằng dù là lỗi cục bộ (cần Replication nhanh) hay tấn công mạng quy mô lớn (cần phục hồi từ Air-Gap), doanh nghiệp vẫn có một lộ trình phục hồi đã được xác định.

---

PHẦN V. VAI TRÒ CỦA QUẢN TRỊ VÀ VẬN HÀNH: ĐIỂM GÃY PHI KỸ THUẬT

Một kiến trúc hoàn hảo có thể bị vô hiệu hóa bởi một quy trình vận hành lỏng lẻo.

5.1. Phân định Quyền và Trách nhiệm: Giữa Kiến trúc sư, Vận hành viên và Quản trị Rủi ro

Trong nhiều doanh nghiệp, trách nhiệm quản lý cấu hình PLC thuộc về Kỹ sư Vận hành (Operations Engineer), còn trách nhiệm quản lý backup thuộc về IT. Khi quy trình không rõ ràng, sẽ xảy ra xung đột:

• OT Engineer: Hiểu rõ cần backup gì (logic điều khiển) và khi nào (sau mỗi thay đổi cấu hình), nhưng không có công cụ.
• IT Admin: Có công cụ (phần mềm backup), nhưng không biết tệp nào là cấu hình quan trọng nhất và không có quyền truy cập vào các thiết bị L0/L1.

Giải pháp Quản trị: Phải thiết lập một ủy ban hỗn hợp IT/OT/Risk để thống nhất:

1. Chính sách RTO/RPO: Doanh nghiệp sẵn sàng chấp nhận downtime bao lâu (RTO) và mất bao nhiêu dữ liệu (RPO) cho từng phân đoạn OT.
2. Quy trình Ghi nhận Thay đổi: Bất kỳ thay đổi cấu hình nào trên PLC/DCS phải kích hoạt một tác vụ “Cấu hình Backup” ngay lập tức và được lưu trữ có gắn nhãn phiên bản.
3. Kế hoạch Đào tạo Chéo: Đào tạo OT Engineer về quy trình phục hồi từ Image và đào tạo IT Admin về các điểm nhạy cảm của hệ thống OT.

5.2. Chuẩn hóa Quy trình: Từ Ghi nhận Thay đổi Cấu hình đến Phục hồi Thảm họa

Quy trình Backup Resilience phải bao gồm ba bước vận hành liên tục:

1. Vận hành Hằng ngày (Daily Operations): Tác vụ backup định kỳ, kiểm tra tính toàn vẹn và chuyển dữ liệu sang kho Immutability.
2. Quản lý Thay đổi (Change Management): Khi có thay đổi hệ thống (ví dụ: vá lỗi HMI, thay đổi logic điều khiển), phải có một quy trình bổ sung:
   • Tạo ra một bản backup trước khi thay đổi.
   • Tạo ra một bản backup sau khi thay đổi thành công.
   • Ghi nhận chi tiết thay đổi và gắn nhãn (tag) cho bản backup đó.
3. Phục hồi Thảm họa (Disaster Recovery): Không chỉ là tài liệu kỹ thuật. Nó phải là một kịch bản hành động được diễn tập thường xuyên, mô tả rõ ràng: Ai làm gì, khi nào, sử dụng tài khoản nào, và làm thế nào để xác minh quy trình phục hồi (ví dụ: 10 bước khởi động lại dây chuyền sản xuất sau khi phục hồi hệ thống điều khiển).

5.3. Xây dựng Kịch bản Phục hồi sau Tấn công (Playbook)

Khi ransomware xảy ra, mọi thứ đều hỗn loạn. Playbook phải là một hướng dẫn rõ ràng, đặc biệt cho môi trường OT:

• Bước 1: Cô lập & Đánh giá Thiệt hại (Containment & Assessment): Xác định các máy chủ/thiết bị OT nào bị ảnh hưởng.
• Bước 2: Phục hồi từ Air-Gap/Immutability: Chọn điểm phục hồi (RPO) tốt nhất. Trong OT, điểm phục hồi không phải là bản backup mới nhất, mà là bản backup cuối cùng đã được xác minh có chứa cấu hình ổn định.
• Bước 3: Tái thiết Lớp Điều khiển (L0/L1): Ưu tiên nạp lại các tệp cấu hình PLC/DCS từ kho lưu trữ bất biến (thường là Air-Gap vật lý). Đây là phần chỉ có OT Engineer mới làm được, cần sự hỗ trợ của IT để truy cập dữ liệu.
• Bước 4: Tái thiết Lớp Vận hành (L2/L3): Khôi phục các máy chủ HMI/Historian từ Image bất biến.
• Bước 5: Thử nghiệm An toàn (Safety Verification): Kiểm tra các giới hạn an toàn, cảm biến, và các vòng điều khiển đã được khôi phục chính xác trước khi cho phép quy trình hoạt động trở lại.

---

PHẦN VI. PHÂN TÍCH CHUYÊN SÂU: VÍ DỤ THỰC TIỄN VỀ LỖ HỔNG KIẾN TRÚC OT BACKUP

6.1. Case Study 1: Nhà máy Năng lượng và Thảm họa Cấu hình HMI/SCADA

Bối cảnh Doanh nghiệp: Một nhà máy sản xuất năng lượng có hệ thống SCADA phức tạp (Hybrid OT/IT). Hệ thống SCADA chạy trên một cụm máy chủ ảo (VMware) được quản lý bởi IT, nhưng cấu hình vận hành (HMI Project Files) lại được phát triển và lưu trữ bởi đội OT.

Vấn đề Kiến trúc trước khi Xây dựng Cyber Resilience:Doanh nghiệp có giải pháp backup Image Level cho các VM của SCADA và sử dụng giải pháp immutable backup lưu trữ trên Cloud S3. RPO là 4 giờ.

• Điểm yếu: Đội IT chỉ backup toàn bộ Image VM. Đội OT thường xuyên chỉnh sửa các tệp cấu hình HMI (L2) và các bản đồ tag (tag mapping) (L3). Các tệp này là các tệp nhỏ nằm trong thư mục cài đặt của ứng dụng SCADA.

Sự cố và Sai lầm Ban đầu: Một biến thể ransomware nhắm mục tiêu vào các máy chủ ảo hóa đã thành công xâm nhập mạng IT, sau đó lan sang VMWare và mã hóa các VM của SCADA.

• Phục hồi: IT Admin khôi phục thành công VM SCADA từ bản backup immutable (RTO 6 giờ).
• Thảm họa RTO Kéo dài: Khi OT Engineer cố gắng khởi động lại hệ thống SCADA, giao diện HMI khởi động được nhưng không thể kết nối hoặc điều khiển các thiết bị đầu cuối (RTU/PLC). Nguyên nhân là trong vòng 48 giờ trước khi bị tấn công, OT Engineer đã thực hiện một loạt các thay đổi cấu hình quan trọng (cập nhật bảng tag tên, tinh chỉnh giao diện cảnh báo) nhưng chỉ lưu trữ các tệp cấu hình mới nhất này cục bộ trên ổ C của VM, và IT Admin chỉ backup Image VM cũ hơn 48 giờ.
• Hậu quả: Dữ liệu backup Image là toàn vẹn, nhưng dữ liệu cấu hình quan trọng nhất (Control Logic Context) đã bị mất. Đội OT phải mất thêm 3 ngày để làm việc thủ công (reverse engineering và so sánh với các bản in cũ) để tái lập cấu hình vận hành chính xác.

Cách tiếp cận Kiến trúc (Sau sự cố):

1. Phân tầng RPO/RTO: Xác định rằng tệp cấu hình HMI/Tag Mapping (L2) phải có RPO < 30 phút, tách biệt với RPO của Image VM (4 giờ).
2. Backup Data-Centric: Triển khai một công cụ backup chuyên biệt (hoặc script) để chỉ thu thập các thư mục chứa tệp cấu hình quan trọng của HMI/SCADA, nén, mã hóa và chuyển chúng ngay lập tức sang một kho lưu trữ bất biến riêng biệt (Micro-Vault) tại ranh giới IT/OT.
3. Kiểm soát Phiên bản: Bắt buộc OT Engineer sử dụng hệ thống Version Control khi thay đổi cấu hình, gắn nhãn rõ ràng (ví dụ: “v2.3_20231201_ChinhSuaVongLapNhiet”), và tự động backup phiên bản mới này sang Micro-Vault.

Kết quả Định lượng: Khả năng phục hồi toàn bộ hệ thống (HMI + Cấu hình chính xác) giảm từ > 3 ngày xuống còn dưới 8 giờ (đáp ứng RTO mới). Rủi ro mất Cấu hình Điều khiển quan trọng giảm gần như về 0.

6.2. Case Study 2: Sản xuất Vật liệu và Ảo tưởng về Air-Gap Vật lý

Bối cảnh Doanh nghiệp: Một công ty sản xuất vật liệu lớn, có hệ thống điều khiển DCS (Distributed Control System) cũ, hoạt động hoàn toàn cô lập (Air-Gapped) so với mạng IT và Internet, sử dụng Windows XP/7.

Vấn đề Kiến trúc trước khi Xây dựng Cyber Resilience:Doanh nghiệp tin rằng hệ thống OT đã an toàn vì chúng cô lập. Backup được thực hiện bằng cách sử dụng các đĩa cứng di động (Removable HDD) cắm trực tiếp vào máy chủ DCS/HMI, sau đó được vận hành viên thủ công di chuyển ra khỏi khu vực sản xuất (Air-Gap vật lý).

Sự cố và Sai lầm Ban đầu: Hệ thống không bị tấn công mạng, mà là hỏng ổ cứng đồng thời trên một cặp máy chủ HMI/DCS quan trọng. Khi cần phục hồi:

1. Chất lượng Backup Tồi: Đĩa cứng backup được lưu trữ trong môi trường vật lý không đạt chuẩn, và khi kiểm tra, dữ liệu trên đĩa đã bị lỗi từ vài tháng trước (data rot/corruption).
2. Sai lầm Quản trị Air-Gap: Quy trình di chuyển đĩa cứng thủ công được thực hiện bởi OT Engineer, nhưng không có quy trình xác minh tính toàn vẹn dữ liệu (Checksum/Integrity Check) sau khi backup. Họ chỉ kiểm tra dung lượng tệp.

Hệ quả dài hạn: Hệ thống phục hồi thất bại hoàn toàn. Doanh nghiệp mất 7 ngày để mua phần cứng thay thế và cài đặt lại hệ điều hành, sau đó phải cài đặt lại phần mềm DCS phức tạp và nạp lại logic điều khiển từ bản in trên giấy (vì bản điện tử cuối cùng đã bị hỏng). Tổng thiệt hại vận hành và sản xuất vượt xa chi phí đầu tư cho một giải pháp Resilience đúng đắn.

Cách tiếp cận Kiến trúc (Sau sự cố):

1. Phân biệt Air-Gap và Verification: Giữ nguyên Air-Gap vật lý, nhưng thay đổi công cụ. Triển khai một máy chủ backup chuyên dụng (appliance cứng, không chạy HĐH thông thường) trong khu vực OT, được cấu hình để thực hiện kiểm tra tính toàn vẹn dữ liệu (Integrity verification) ngay lập tức sau mỗi lần backup.
2. Tự động hóa Immutability cho Vật lý: Dữ liệu được mã hóa và lưu trữ trên băng từ hoặc đĩa chuyên dụng ngay sau khi xác minh thành công. Tăng tần suất sao lưu lên Air-Gap vật lý.
3. Xây dựng Năng lực Phục hồi Thực tế: Thiết lập một môi trường Staging/Sandbox OT (sử dụng các máy chủ cũ hoặc virtual machine tương thích) để thực hiện phục hồi DR Test hàng quý. Mục tiêu là chứng minh rằng đĩa cứng Air-Gap vật lý không chỉ chứa dữ liệu, mà còn phục hồi và chạy được trên phần cứng thay thế.

Kết quả Định lượng: Giảm rủi ro phục hồi thất bại do dữ liệu hỏng từ Air-Gap vật lý từ 50% xuống dưới 5%. Tăng khả năng kiểm soát chất lượng dữ liệu backup và rút ngắn thời gian phục hồi giả định từ 7 ngày xuống còn 24 giờ.

---

PHẦN VII. HÀNH ĐỘNG CỤ THỂ VÀ LỜI KẾT

Backup không phải là một tính năng; nó là một chiến lược sống còn, đặc biệt trong môi trường OT/SCADA nơi RTO được đo bằng phút và sự cố đồng nghĩa với dừng sản xuất. Cyber Resilience Architecture cho OT không phải là mua thêm license phần mềm, mà là xây dựng một cầu nối kiến trúc giữa sự nhạy cảm của OT và sự phức tạp của các giải pháp bảo vệ dữ liệu hiện đại.

Actionable Takeaways (Hành động Cụ thể):

1. Thiết lập RTO/RPO độc lập cho OT: Ngừng áp dụng RTO/RPO của IT cho OT. Phân loại hệ thống OT thành các cấp độ L0/L1/L2 và xác định RTO/RPO chi tiết cho từng lớp dữ liệu (dữ liệu quy trình, cấu hình điều khiển, HMI image).
2. Kiểm kê và Phân tích Cấu hình (Configuration Audit): Xác định chính xác vị trí của tất cả các tệp cấu hình L0/L1 (PLC logic, firmware, tag database) và đảm bảo chúng được quản lý phiên bản (Version Controlled) và được backup thường xuyên hơn bất kỳ dữ liệu nào khác.
3. Xây dựng Kho Lưu trữ Bất biến Micro-Vault: Thiết kế một kho lưu trữ bất biến nhỏ, chuyên dụng, được cách ly tại ranh giới IT/OT, chỉ dành riêng cho việc lưu trữ các tệp cấu hình OT quan trọng. Kho này phải sử dụng thông tin xác thực (Credentials) hoàn toàn độc lập với mạng sản xuất.
4. Kiểm soát Air-Gap Vật lý Bằng Quy trình: Nếu bắt buộc phải sử dụng Air-Gap vật lý (băng từ/đĩa di động), hãy đầu tư vào quy trình tự động kiểm tra tính toàn vẹn dữ liệu (Integrity Check) và thử nghiệm phục hồi (DR Validation) trước khi dữ liệu được coi là “an toàn”. Air-Gap không có xác minh chỉ là ảo tưởng về sự an toàn.
5. Diễn tập DR Test Hỗn hợp IT/OT: Thực hiện các bài kiểm tra phục hồi định kỳ, không chỉ khôi phục máy chủ mà còn phải bao gồm bước cuối cùng: Nạp lại cấu hình vào thiết bị điều khiển và khởi động lại quy trình sản xuất an toàn.

Trì hoãn việc xây dựng Cyber Resilience Architecture đúng đắn cho OT là chấp nhận rủi ro vận hành không thể chấp nhận được. Khi sự cố xảy ra, việc thiếu một kiến trúc backup phục hồi mạnh mẽ sẽ không chỉ là thiệt hại về tài chính, mà còn là sự đe dọa trực tiếp đến tính liên tục của hoạt động sản xuất, an toàn và danh tiếng của doanh nghiệp.

Nếu doanh nghiệp đang gặp khó khăn trong việc xác định RTO/RPO cho môi trường OT phức tạp, hoặc cần tư vấn về việc thiết kế các lớp Immutability và Air-Gap cho kiến trúc điều khiển cô lập, hãy cùng nhau trao đổi. Mục tiêu không phải là mua thêm công cụ, mà là thiết kế lại tư duy phục hồi.