Lâm Văn PhongReliability · EAM · AI Agent
Liên hệ

OT · Cybersecurity · Lâm Văn Phong

Đưa Cybersecurity vào Scope of Work của dự án EAM–OT

Khi EAM, historian và AI Portal kết nối với môi trường OT, sơ đồ API đẹp chưa đủ. Hồ sơ kỹ thuật cần ghi rõ trust boundary, luồng dữ liệu, quyền, trách nhiệm vận hành và cách xử lý khi một thành phần mất kết nối.

01

Vẽ data flow và trust boundary

Liệt kê hệ thống nguồn, đích, giao thức, hướng truyền, tần suất, độ trễ chấp nhận được và dữ liệu nhạy cảm. Phân biệt luồng đọc dữ liệu từ OT với luồng có khả năng ghi lệnh hoặc cấu hình. Mọi ngoại lệ cần có owner và lý do nghiệp vụ.

02

Thiết kế identity và quyền

Tài khoản dịch vụ không dùng chung với tài khoản cá nhân. Ghi rõ cách cấp, xoay vòng và thu hồi credential; quyền đọc, tạo draft và ghi phải tách biệt. Remote access cần thời hạn, phê duyệt và nhật ký phiên phù hợp chính sách của cơ sở.

03

Tính đến vận hành và availability

Xác định điều gì xảy ra khi historian, gateway hoặc EAM không sẵn sàng: retry, queue, dữ liệu trễ, cảnh báo và quy trình thủ công. Không để lỗi của lớp phân tích ảnh hưởng điều khiển quá trình. Lịch vá và thay đổi phải xét cửa sổ vận hành của nhà máy.

04

Bằng chứng nghiệm thu

Scope of Work cần chỉ rõ tài liệu kiến trúc, asset inventory, cấu hình quyền, log, test mất kết nối, backup/restore, xử lý sự cố và người ký nghiệm thu. Một câu “tuân thủ Cybersecurity” không đủ để kiểm thử hoặc giao trách nhiệm.

05

Giữ giới hạn tư vấn rõ ràng

Danh sách trên là câu hỏi đầu vào cho kiến trúc giải pháp, không thay thế OT security assessment của chuyên gia được ủy quyền. Bộ control cuối cùng phải được chọn theo rủi ro, hệ thống hiện hữu và yêu cầu của đơn vị vận hành.

06

Chốt kiến trúc tích hợp ở mức luồng dữ liệu

Với mỗi interface, Scope of Work nên có source, destination, protocol, port, hướng kết nối, tần suất, khối lượng, độ trễ, phân loại dữ liệu và owner. Vẽ trust boundary giữa OT, DMZ và IT theo kiến trúc của cơ sở; xác định rõ thành phần nào chủ động kết nối và có quyền gửi lệnh. Các luồng chỉ đọc từ historian vẫn cần kiểm tra tải truy vấn, cách cache và điều gì xảy ra khi network gián đoạn.

Không nên viết chung “tích hợp hai chiều” nếu use case chỉ cần đưa dữ liệu thiết bị ra EAM. Quyền ghi cần business justification riêng, phê duyệt kiến trúc và test giới hạn. Một data flow register được duyệt là nền để firewall team, OT owner, EAM team và vendor cùng triển khai và nghiệm thu. Mọi kết nối tạm trong pilot cũng cần ngày hết hạn và đường gỡ bỏ.

07

Đưa control vào deliverable và test case

Yêu cầu cần kiểm chứng được: tài khoản dịch vụ có quyền tối thiểu, cách lưu và xoay credential, log đăng nhập và thay đổi cấu hình, đồng bộ thời gian, backup, khôi phục, giám sát lỗi và quy trình thu hồi truy cập. Ghi rõ bên nào cung cấp chứng chỉ, firewall rule, host hardening và patch window. Nếu chỉ ghi “theo chính sách Cybersecurity”, bên thực hiện và bên nghiệm thu sẽ hiểu khác nhau.

Acceptance test nên có mất kết nối, dữ liệu đến muộn, queue đầy, credential hết hạn, quyền truy cập bị thu hồi, restore từ backup và thay đổi cấu hình không được phép. Với từng case, xác định trạng thái an toàn, log cần có, cảnh báo đến ai và thời gian xử lý theo yêu cầu của đơn vị vận hành. Kết quả test phải lưu evidence, người chứng kiến và action còn mở.

08

Phân định trách nhiệm vận hành

Sau handover, ai quản lý service account, theo dõi health của gateway, kiểm tra log, cấp remote access, áp dụng bản vá và phản ứng sự cố? RACI cần phân biệt IT, OT, EAM application owner, SOC và vendor. Hợp đồng hỗ trợ phải nêu giờ làm việc, escalation, khả năng truy cập từ xa và điều kiện có người giám sát tại site. Nếu các vai trò này bỏ trống, tích hợp có thể chạy được ngày đầu nhưng khó duy trì an toàn.

Kiến trúc cũng cần kịch bản degraded mode: EAM không truy cập được OT thì dữ liệu hiển thị phải có timestamp và trạng thái stale; AI Portal không được diễn giải dữ liệu cũ như dữ liệu hiện hành. Thay đổi về hệ thống, giao thức hoặc quyền truy cập phải đi qua change control và đánh giá lại data flow. Các control cụ thể cuối cùng cần được OT security owner của cơ sở xác nhận.

09

Ví dụ minh họa: historian cung cấp dữ liệu cho EAM

Một pilot cần đưa trạng thái thiết bị từ historian sang EAM để hỗ trợ bảo trì. Data flow register xác định tag, tần suất, hướng kết nối, gateway, protocol, owner và giới hạn độ trễ. Thiết kế chỉ cho gateway đọc dữ liệu cần thiết; EAM không có đường gửi lệnh về hệ điều khiển. UAT làm mất kết nối gateway: bản ghi được queue hoặc đánh dấu lỗi, dashboard hiển thị timestamp cuối cùng và trạng thái stale, đội vận hành nhận cảnh báo. Test tiếp credential hết hạn và backup restore, lưu log và người chứng kiến. Sau handover, OT owner quản lý kết nối, EAM owner xử lý dữ liệu ứng dụng, security team review quyền và log. Những vai trò này được ghi trong Scope of Work trước khi ký nghiệm thu.

Checklist khi áp dụng

  • Data flow và trust boundary được duyệt
  • Ma trận quyền và service identity
  • Remote access và logging
  • Failure mode, backup và recovery test
  • Deliverable, test và approver trong Scope of Work

Khung thực hành do Lâm Văn Phong biên soạn. Cần đối chiếu tiêu chuẩn, quy định và dữ liệu hiện hành của từng dự án trước khi áp dụng.