Cybersecurity cho hệ bơm kết nối mạng cần lưu ý gì?

Điểm cần hiểu đúng là thân bơm cơ khí không tự nhiên trở thành “thiết bị mạng”. Bề mặt tấn công hình thành ở các thành phần số bao quanh bơm: cảm biến thông minh, PLC, relay, biến tần, HMI, máy tính kỹ thuật, router 4G, gateway, broker, máy chủ SCADA, cloud, API và phần mềm truy cập từ xa. Vì vậy, mua một bơm tốt chưa đủ để có một hệ thống kết nối an toàn; ngược lại, bảo mật tốt cũng không được làm mất liên động bảo vệ và khả năng vận hành cục bộ.

Bài viết này trình bày cách xây dựng cybersecurity cho hệ bơm theo góc nhìn vận hành thực tế: nhận diện tài sản, đánh giá hậu quả vật lý, phân vùng OT/IT, bảo vệ truy cập từ xa, làm cứng giao thức, kiểm soát lệnh, giám sát bất thường, sao lưu và ứng cứu. Mục tiêu không phải tạo một “pháo đài” quá phức tạp, mà là giảm những đường tấn công dễ khai thác nhất, giới hạn phạm vi ảnh hưởng và giúp trạm tiếp tục ở trạng thái an toàn khi mạng trung tâm gặp sự cố.

Trả lời ngắn: hệ bơm kết nối mạng cần ưu tiên điều gì?

Nếu chỉ chọn các việc quan trọng nhất, hãy bắt đầu theo thứ tự dưới đây:

1. Không để PLC, HMI, VFD, gateway hoặc router quản trị phơi trực tiếp ra Internet.
2. Lập danh mục tài sản và sơ đồ luồng dữ liệu: biết thiết bị nào tồn tại, giao tiếp với ai và ai chịu trách nhiệm.
3. Phân vùng OT với IT và cloud: chỉ cho phép đúng nguồn, đúng đích, đúng cổng và đúng chiều truyền cần thiết.
4. Truy cập từ xa qua gateway/VPN được quản lý: tài khoản riêng, MFA, quyền tối thiểu, giới hạn thời gian và lưu nhật ký.
5. Giữ bảo vệ tại chỗ: dừng khẩn, chống chạy khô, quá tải, quá áp và liên động van phải hoạt động độc lập với Internet.
6. Kiểm soát mọi lệnh ghi: xác thực, thời hạn hiệu lực, trạng thái cho phép, phiên bản cấu hình, xác nhận thực thi và audit.
7. Sao lưu cấu hình OT và thử khôi phục: PLC, HMI, VFD, gateway, firewall, chứng thư và tài liệu vận hành đều phải nằm trong phạm vi.
8. Chuẩn bị playbook sự cố: ai xác minh quá trình vật lý, ai cô lập mạng, khi nào chuyển local/manual và điều kiện đưa hệ thống trở lại.

NIST SP 800-82 Rev. 3 nhấn mạnh rằng bảo mật OT phải đồng thời đáp ứng yêu cầu hiệu năng, độ tin cậy và an toàn của quá trình. Đây là khác biệt nền tảng so với việc áp nguyên bộ chính sách IT vào tủ điều khiển bơm.

Cybersecurity của hệ bơm là bài toán cyber–physical

Trong hệ thống văn phòng, hậu quả thường được mô tả bằng mất bí mật, mất toàn vẹn hoặc gián đoạn dịch vụ số. Với trạm bơm, mỗi thay đổi số có thể kéo theo một trạng thái vật lý. Một setpoint áp suất bị sửa, một tín hiệu mức bị giả mạo hoặc một lệnh dừng bị chặn có thể tạo chuỗi hậu quả như sau:

Sự kiện mạng
→ dữ liệu hoặc lệnh bị thay đổi
→ logic điều khiển nhận trạng thái sai
→ bơm/van hoạt động sai chế độ
→ quá áp, tràn bể, cạn bể, chạy khô hoặc mất dịch vụ
→ hư hỏng thiết bị, tác động môi trường và an toàn

Vì thế, ba thuộc tính cần bảo vệ không có cùng mức ưu tiên trong mọi tình huống:

Không nên hiểu bảng trên là “OT chỉ cần availability”. Một trạm vẫn có thể sẵn sàng về mặt kết nối nhưng hiển thị số liệu giả hoặc nhận lệnh sai. Tính toàn vẹn của dữ liệu và lệnh thường quyết định trực tiếp chất lượng điều khiển.

Bề mặt tấn công nằm ở đâu?

Một hệ sử dụng máy bơm nước Pentax hoặc thương hiệu bất kỳ có thể hoàn toàn độc lập mạng, điều khiển bằng contactor và relay. Rủi ro mạng chỉ xuất hiện khi bổ sung các thành phần có giao tiếp số. Cần rà soát ít nhất bảy lớp:

1. Thiết bị hiện trường

Cảm biến áp suất, lưu lượng kế, công tơ, relay thông minh, bộ điều khiển van và cảm biến rung có thể dùng RS-485, Ethernet, Wi-Fi hoặc giao thức không dây. Chúng có thể chứa địa chỉ, mật khẩu, firmware, web server hoặc cổng cấu hình mà đội vận hành không nhận ra.

2. PLC, VFD và HMI

Đây là nơi thực hiện logic điều khiển, giữ setpoint và phát lệnh tới cơ cấu chấp hành. Tài khoản mặc định, chế độ lập trình luôn mở, dịch vụ thừa hoặc quyền ghi không giới hạn sẽ làm tăng hậu quả nếu một thiết bị khác trong vùng bị xâm nhập.

3. Máy tính kỹ thuật và thiết bị bảo trì

Laptop dùng để nạp chương trình thường kết nối cả mạng văn phòng, Internet, USB và mạng OT. Nếu không quản lý riêng, đây là cầu nối thuận tiện giữa nhiều miền tin cậy. File dự án PLC không rõ nguồn gốc, phần mềm lậu hoặc tài khoản admin dùng chung cũng làm mất khả năng truy vết.

4. Gateway, router và thiết bị biên

Gateway gom dữ liệu, chuyển giao thức, lưu đệm và kết nối cloud; router 4G cung cấp đường truyền; firewall kiểm soát luồng. Một cấu hình chuyển tiếp cổng, giao diện quản trị từ xa hoặc tài khoản nhà cung cấp không được thu hồi có thể bỏ qua toàn bộ lớp bảo vệ bên trong.

5. SCADA, historian và broker

Máy chủ trung tâm nắm dữ liệu của nhiều trạm và đôi khi có quyền ghi ngược xuống. Một broker cho phép client ẩn danh, một tài khoản dịch vụ quá quyền hoặc API thiếu giới hạn theo site có thể biến một sự cố thành ảnh hưởng diện rộng.

6. Cloud, ứng dụng web và di động

Tài khoản quản trị, token API, khóa tích hợp, cấu hình tenant, ứng dụng di động và cơ chế khôi phục mật khẩu đều cần được đưa vào mô hình đe dọa. “Đã dùng cloud” không đồng nghĩa trách nhiệm bảo mật đã chuyển hết cho nhà cung cấp.

7. Con người và quy trình

Tài khoản nhân viên nghỉ việc, nhà thầu vẫn còn quyền, ảnh chụp mật khẩu dán trong tủ, phê duyệt qua điện thoại không lưu vết hoặc thay đổi PLC không có hồ sơ đều là điểm yếu. Nhiều sự cố không cần kỹ thuật phức tạp; chỉ cần tìm được một đường truy cập đang mở và một thông tin xác thực yếu.

Những kịch bản rủi ro thường gặp ở trạm bơm

Danh sách dưới đây dùng để đặt câu hỏi trong buổi đánh giá, không phải khẳng định mọi trạm đều có cùng lỗ hổng.

Cảnh báo ngày 30/7/2026 của CISA đối với lĩnh vực nước và nước thải mô tả việc PLC phơi ra Internet bị đổi mật khẩu và địa chỉ IP, khiến người vận hành mất quyền truy cập. Đây là minh họa rõ rằng “chỉ là một PLC nhỏ ở trạm xa” vẫn có thể bị tìm thấy và khai thác nếu để lộ trực tiếp.

Đánh giá rủi ro từ hậu quả vật lý, không chỉ từ điểm CVE

Một lỗ hổng nghiêm trọng trên thiết bị chỉ đọc dữ liệu không nhất thiết có cùng mức ưu tiên với một lỗ hổng trung bình trên đường điều khiển bơm cấp nước trọng yếu. Điểm CVE phản ánh đặc tính kỹ thuật của lỗ hổng; nó không biết bơm đang phục vụ chữa cháy, cấp nước sản xuất hay tưới cảnh quan.

Mô hình tối giản để xếp hạng:

Rủi ro = Khả năng xảy ra × Mức độ hậu quả

Hậu quả nên chấm theo nhiều trục:

• An toàn con người và khả năng tạo áp suất/năng lượng nguy hiểm;
• Khả năng mất dịch vụ và thời gian chịu đựng của quy trình;
• Thiệt hại bơm, motor, van, đường ống và thiết bị công nghệ;
• Nguy cơ tràn, xả thải, thiếu nước hoặc ảnh hưởng môi trường;
• Phạm vi lan truyền sang trạm khác hoặc hệ thống doanh nghiệp;
• Khả năng phát hiện, cô lập và phục hồi bằng vận hành cục bộ.

Có thể dùng thang 1–5 để thảo luận, nhưng điểm số không thay thế phân tích kịch bản. Mọi tổ hợp dẫn tới hậu quả an toàn nghiêm trọng cần được xem xét riêng, kể cả khi xác suất ước tính thấp. NIST Cybersecurity Framework 2.0 tổ chức quản trị rủi ro theo sáu chức năng Govern, Identify, Protect, Detect, Respond và Recover; khung này hữu ích để tránh đầu tư toàn bộ vào phòng ngừa mà bỏ quên phát hiện và phục hồi.

Kiến trúc nền tảng: phân vùng và kiểm soát đường giao tiếp

Không nên nối PLC của trạm thẳng vào mạng văn phòng hoặc Internet chỉ vì hai đầu “ping được”. Một kiến trúc thực dụng có thể chia thành các vùng:

Khái niệm zone và conduit của bộ tiêu chuẩn ISA/IEC 62443 giúp nhóm các tài sản có yêu cầu bảo vệ tương đồng và kiểm soát các đường giao tiếp giữa chúng. “Có firewall” chưa đủ; cần tài liệu hóa firewall đang cho phép nguồn nào, đích nào, dịch vụ nào, chiều nào, do use case nào yêu cầu và ai phê duyệt.

Một nguyên tắc tốt là default deny: không mở cả dải mạng rồi trông chờ mật khẩu thiết bị. Nếu gateway chỉ cần gửi telemetry ra broker, hãy ưu tiên kết nối outbound do gateway khởi tạo, giới hạn đúng địa chỉ và cổng. Kênh điều khiển ghi ngược xuống nên là một đường riêng, có quyền, kiểm tra và nhật ký nghiêm ngặt hơn kênh đọc.

Không phơi PLC, HMI và thiết bị quản trị ra Internet

Đây là việc nên kiểm tra đầu tiên vì chi phí sửa thường thấp hơn nhiều biện pháp phức tạp. Hãy rà soát:

• Port forwarding trên router 4G, modem, firewall và cloud security group;
• Public IP gắn trực tiếp vào PLC, HMI, VFD, camera hoặc gateway;
• Web management, SSH, Telnet, VNC, RDP và cổng lập trình mở từ mọi nguồn;
• Dịch vụ cloud relay hoặc remote desktop “tạm thời” đã tồn tại nhiều năm;
• IPv6 hoặc đường dự phòng không nằm trong sơ đồ kiểm soát;
• Thiết bị do nhà thầu tự lắp SIM và giữ tài khoản quản trị.

Hướng dẫn giảm đe dọa OT của CISA đặt việc loại bỏ kết nối OT với Internet công cộng ở vị trí ưu tiên. Nếu nghiệp vụ thực sự cần truy cập từ xa, khuyến nghị liên cơ quan về bảo vệ PLC nêu rõ nên đặt proxy, gateway, firewall hoặc VPN phía trước PLC để kiểm soát đường vào.

Việc “đóng cổng” cần có kế hoạch vận hành. Trước khi thay đổi, xác định đường nào phục vụ telemetry, đường nào phục vụ bảo trì, ai đang dùng và phương án thay thế. Mục tiêu là loại bỏ truy cập không quản lý, không phải làm đội hiện trường mất khả năng hỗ trợ hợp pháp.

Truy cập từ xa an toàn: VPN chỉ là một lớp

VPN mã hóa đường truyền nhưng không tự trả lời được: người kết nối là ai, thiết bị đầu cuối có đáng tin không, được vào trạm nào, được làm gì và phiên đó có được phê duyệt không. Mô hình truy cập từ xa nên bao gồm:

1. Người dùng đăng nhập bằng danh tính cá nhân và MFA;
2. Thiết bị đầu cuối đáp ứng chính sách hoặc đi qua máy trạm trung gian được quản lý;
3. Yêu cầu quyền theo site, vai trò, mục đích và khoảng thời gian;
4. Kết nối tới jump host/gateway, không tới thẳng PLC;
5. Chỉ mở đúng công cụ và đích đã phê duyệt;
6. Ghi thời điểm, lệnh/thay đổi quan trọng và người xác nhận;
7. Đóng phiên, thu hồi quyền tạm và kiểm tra thay đổi sau công việc.

NIST SP 1800-45, bản chính thức tháng 6/2026 trình bày ba kiến trúc mẫu truy cập từ xa OT cho đơn vị nước có quy mô khác nhau, dùng công nghệ thương mại và nhấn mạnh truyền thông an toàn, xác thực và kiểm soát truy cập. Điều quan trọng là chọn kiến trúc vừa với năng lực vận hành; một hệ quá phức tạp nhưng không ai quản lý chứng thư, tài khoản và log sẽ không bền.

Quyền nhà cung cấp phải “tắt mặc định”

Tài khoản hỗ trợ của hãng tích hợp không nên hoạt động 24/7. Cách quản trị phù hợp là just-in-time: người phụ trách mở quyền cho một ticket, một site, một cửa sổ thời gian; nhà cung cấp đăng nhập bằng tài khoản cá nhân có MFA; phiên được giám sát; quyền tự hết hạn. Sau khi hoàn thành, cấu hình PLC/HMI/VFD phải được đối chiếu với baseline và đưa vào quản lý thay đổi.

Tài khoản khẩn cấp cần tồn tại nhưng phải được kiểm soát

Trạm có thể cần “break-glass account” khi dịch vụ danh tính hoặc đường WAN mất. Tài khoản này nên được bảo vệ bằng bí mật mạnh cất giữ an toàn, giám sát mọi lần sử dụng, đổi lại sau khi dùng và thử định kỳ. Không nên biến tài khoản khẩn cấp thành tài khoản dùng hằng ngày vì đăng nhập tiện hơn.

Quản lý danh tính, tài khoản và bí mật

Đối với hệ bơm nhiều trạm, tài khoản thường sinh ra ở nhiều nơi: cloud, VPN, HMI, PLC, router, gateway, laptop, phần mềm kỹ thuật và cơ sở dữ liệu. Nếu không có owner, tài khoản cũ sẽ tích tụ nhanh hơn thiết bị mới.

Quy trình joiner–mover–leaver phải áp dụng cho OT: cấp quyền khi vào vị trí, điều chỉnh khi đổi nhiệm vụ và thu hồi ngay khi rời công ty/dự án. Đừng chờ đợt audit cuối năm mới xóa quyền của nhà thầu đã kết thúc hợp đồng.

Modbus, OPC UA và MQTT: giao thức nào cũng cần cấu hình đúng

Không có giao thức nào tự động biến toàn hệ thành an toàn. Cần hiểu vai trò của từng giao thức, khả năng bảo mật của thiết bị cụ thể và lớp bù trừ khi thiết bị cũ không hỗ trợ mã hóa.

Modbus RTU/TCP

Modbus truyền thống phổ biến vì đơn giản và tương thích rộng, nhưng thường không cung cấp xác thực nguồn hoặc mã hóa ở tầng ứng dụng. Không nên đưa Modbus TCP nguyên bản xuyên Internet. Hãy giữ nó trong vùng tin cậy có allowlist, firewall công nghiệp và quyền ghi được giới hạn; nếu thiết bị hỗ trợ, Modbus Security kết hợp TLS với chứng thư X.509 để bảo vệ xác thực và toàn vẹn thông điệp.

OPC UA

OPC UA có cơ chế SecureChannel, chứng thư ứng dụng, ký và mã hóa. Tuy nhiên, hệ chỉ an toàn khi quản lý trust list, private key, certificate revocation, chính sách bảo mật và quyền người dùng đúng cách. Không chọn chế độ không ký/không mã hóa chỉ để “kết nối cho nhanh”; cũng không tự động chấp nhận mọi chứng thư chưa tin cậy. mô hình bảo mật OPC UA chính thức mô tả việc dùng khóa bất đối xứng để thiết lập kênh và khóa đối xứng cho các thông điệp tiếp theo.

MQTT

MQTT 5.0 của OASIS là giao thức publish/subscribe nhẹ, phù hợp telemetry và kết nối băng thông hạn chế. Nhưng QoS 0/1/2 nói về cách giao thông điệp, không phải quyền truy cập hay tính hợp lệ của lệnh. Broker cần TLS, xác thực client, ACL theo topic, giới hạn tenant/site, rate limit, log và chính sách retained message. Không mở anonymous publish/subscribe và không cho một client của trạm đọc/ghi wildcard toàn hệ.

Mã hóa không thay thế phân vùng

TLS bảo vệ dữ liệu trên đường truyền, nhưng endpoint đã bị chiếm quyền vẫn có thể gửi dữ liệu “đúng mã hóa” nhưng sai ý nghĩa. Do đó cần đồng thời bảo vệ endpoint, phân vùng mạng, quản lý danh tính, kiểm tra logic lệnh và giám sát hành vi.

Kiểm soát lệnh từ xa theo vòng đời đầy đủ

Đọc dữ liệu và điều khiển không nên dùng cùng mức tin cậy. Một lệnh khởi động bơm hoặc đổi áp suất phải có ngữ cảnh đủ để PLC quyết định chấp nhận hay từ chối. Logic tối giản:

Command_valid =
  Auth_OK
  AND Role_OK
  AND Site_OK
  AND TTL_OK
  AND State_OK
  AND Interlock_OK
  AND ConfigVersion_OK

Mỗi lệnh nên chứa hoặc liên kết tới:

• Command ID duy nhất để chống thực thi lặp;
• Danh tính người/ứng dụng phát lệnh và vai trò;
• Thiết bị đích, site và phiên bản cấu hình;
• Timestamp, thời hạn hiệu lực và điều kiện trước khi thực hiện;
• Giá trị cũ, giá trị mới, giới hạn cho phép và lý do thay đổi;
• Người phê duyệt nếu là lệnh rủi ro cao;
• Kết quả accepted/rejected/executed và nguyên nhân;
• Readback từ quá trình để xác nhận hiệu lực.

Kiểm tra độ mới của lệnh hoặc dữ liệu có thể biểu diễn:

Age = T_receive - T_source

Chấp nhận khi:
0 ≤ Age ≤ TTL
và trạng thái đồng bộ thời gian hợp lệ

Khi gateway mất mạng, telemetry có thể lưu đệm và gửi bù. Nhưng lệnh điều khiển không được mặc định xếp hàng rồi thực thi sau nhiều giờ. Lệnh hết TTL phải bị hủy; người vận hành gửi lại sau khi xem trạng thái mới.

PLC và liên động tại chỗ phải có quyền từ chối

Nền tảng trung tâm có thể đề nghị khởi động, dừng hoặc đổi setpoint; PLC tại trạm mới là nơi kiểm tra điều kiện vật lý cuối cùng. Một lệnh hợp lệ về danh tính vẫn phải bị từ chối nếu:

• Công tắc đang ở Local hoặc maintenance lock;
• Van chưa đúng vị trí hoặc feedback không tin cậy;
• Mức hút thấp, áp suất bất thường hoặc chống chạy khô đang tác động;
• Motor/VFD đang trip, quá nhiệt hoặc chưa hết thời gian nghỉ;
• Số lần khởi động vượt giới hạn;
• Thiết bị đang cô lập cơ khí/điện theo LOTO;
• Lệnh mâu thuẫn với trình tự cụm bơm hoặc giới hạn công nghệ.

Dừng khẩn, bảo vệ motor, chống chạy khô, quá áp và các liên động có hậu quả an toàn không nên phụ thuộc vào cloud, broker hoặc đường 4G. Khi mất WAN, trạm phải chuyển về chế độ đã thiết kế trước: tiếp tục auto cục bộ, giữ setpoint an toàn, hoặc dừng có kiểm soát tùy phân tích quá trình. “Fail-safe” không luôn đồng nghĩa “tắt tất cả”; với một số dịch vụ, dừng bơm đột ngột còn gây hậu quả lớn hơn.

Danh mục tài sản là nền móng của mọi kiểm soát

Không thể vá, sao lưu, giám sát hoặc thu hồi quyền cho một thiết bị không biết đang tồn tại. hướng dẫn inventory OT của CISA đề xuất bắt đầu bằng xác định phạm vi và xây taxonomy nhất quán. Với trạm bơm, mỗi bản ghi tài sản nên có:

• Mã tài sản, vị trí, khu vực và owner vận hành;
• Hãng, model, serial, firmware, hệ điều hành và phiên bản ứng dụng;
• Địa chỉ IP/MAC, VLAN/zone, giao thức, cổng và peer hợp lệ;
• Vai trò: điều khiển, bảo vệ, giám sát, gateway hay hỗ trợ;
• Mức quan trọng, hậu quả nếu mất và thời gian chịu đựng;
• Tài khoản/chứng thư liên quan và ngày hết hạn;
• Phương thức truy cập từ xa, nhà cung cấp và hợp đồng hỗ trợ;
• Vị trí backup, phiên bản known-good và lần thử restore gần nhất;
• Tình trạng hỗ trợ, ngày vá gần nhất và biện pháp bù trừ;
• Quan hệ phụ thuộc: nguồn điện, PLC, VFD, HMI, gateway, cloud.

Khám phá OT nên ưu tiên phương pháp thụ động hoặc hoạt động đã thử nghiệm. Quét chủ động dải cổng trên mạng điều khiển cũ có thể gây tải hoặc hành vi không mong muốn. Mọi công cụ discovery phải được kiểm chứng trong môi trường phù hợp và có cửa sổ vận hành.

Làm cứng PLC, VFD, HMI, gateway và máy kỹ thuật

PLC và VFD

• Đổi tài khoản mặc định; dùng khả năng xác thực mạnh nhất thiết bị hỗ trợ;
• Khóa chế độ lập trình hoặc yêu cầu chuyển khóa vật lý khi không bảo trì;
• Chỉ cho phép máy kỹ thuật/gateway đã định danh giao tiếp;
• Tắt web server, FTP, Telnet, discovery và dịch vụ không dùng;
• Giới hạn thanh ghi/đối tượng được ghi nếu kiến trúc hỗ trợ;
• Lưu checksum/version logic và cảnh báo khi download/chuyển mode;
• Bảo vệ cổng vật lý, tủ điện và quy trình thay thiết bị.

HMI và SCADA cục bộ

• Tách tài khoản operator, engineer và administrator;
• Không dùng HMI để đọc email, duyệt web hoặc cài phần mềm tùy ý;
• Hạn chế shell/desktop, autorun và cổng USB;
• Application allowlisting nếu nền tảng và quy trình hỗ trợ;
• Đồng bộ thời gian từ nguồn tin cậy và bảo vệ cấu hình audit;
• Hiển thị rõ Local/Remote, nguồn lệnh và quality của dữ liệu.

Gateway, router và firewall

• Đổi thông tin mặc định, tắt quản trị từ WAN và giới hạn management plane;
• Chỉ bật dịch vụ cần thiết, cập nhật firmware theo quy trình;
• Ưu tiên kết nối outbound; dùng allowlist đích và DNS phù hợp;
• Không lưu khóa bí mật dạng rõ trong file cấu hình chia sẻ;
• Bật log cấu hình, đăng nhập, reset, thay SIM và mất kết nối;
• Backup cấu hình sau mỗi thay đổi được phê duyệt.

Máy tính kỹ thuật

• Dùng máy chuyên dụng, không dùng chung cho công việc Internet hằng ngày;
• Kiểm soát phần mềm cài đặt, quyền local admin và thiết bị rời;
• Mã hóa ổ đĩa, EDR/anti-malware tương thích và backup file dự án;
• Không cắm đồng thời vào mạng không tin cậy và mạng PLC;
• Lưu nhật ký ai dùng máy, cho ticket nào và thay đổi gì.

Quản lý bản vá: không bỏ mặc, cũng không cập nhật mù

OT cần ổn định, nhưng “không bao giờ vá vì sợ dừng máy” tạo ra nợ rủi ro. Ngược lại, bật tự động cập nhật giống laptop văn phòng có thể làm HMI khởi động lại, driver mất tương thích hoặc phần mềm kỹ thuật ngừng hoạt động. Quy trình phù hợp gồm:

1. Theo dõi thông báo của nhà sản xuất và nguồn cảnh báo lỗ hổng;
2. Đối chiếu với inventory để biết thiết bị nào thực sự bị ảnh hưởng;
3. Đánh giá khả năng khai thác, đường tiếp cận và hậu quả quá trình;
4. Thử bản vá với phiên bản phần mềm, driver và project tương ứng;
5. Chuẩn bị backup, rollback và cửa sổ bảo trì;
6. Triển khai theo nhóm nhỏ, xác nhận chức năng và theo dõi sau thay đổi;
7. Nếu chưa thể vá, áp dụng biện pháp bù trừ có hạn sử dụng.

Biện pháp bù trừ có thể là cô lập sâu hơn, đóng cổng, allowlist peer, vô hiệu hóa dịch vụ, tăng giám sát hoặc loại bỏ truy cập từ xa. “Đã có kế hoạch vá” không phải biện pháp nếu không có deadline, owner và kiểm soát tạm thời.

Giám sát an ninh phải hiểu cả mạng lẫn quá trình

Chỉ thu log firewall sẽ bỏ sót việc setpoint hợp lệ về mặt giao thức nhưng bất thường về vận hành. Chỉ nhìn trend áp suất lại khó biết đó là lỗi cảm biến, thao tác đúng hay thay đổi trái phép. Trung tâm cần kết hợp hai nhóm tín hiệu.

Tín hiệu mạng và hệ thống

• Thiết bị, MAC hoặc giao thức mới xuất hiện trong zone;
• Kết nối từ nguồn/đích chưa từng được phép;
• Nhiều lần đăng nhập thất bại, dùng tài khoản khẩn cấp hoặc ngoài ca;
• Phiên remote mở ngoài ticket hoặc kéo dài bất thường;
• PLC download/upload, chuyển RUN/PROGRAM, reset hoặc đổi firmware;
• Firewall/router thay rule, NAT, DNS, route hoặc cấu hình VPN;
• Gateway dừng gửi log, lệch giờ hoặc chứng thư sắp hết hạn.

Tín hiệu quá trình

• Setpoint đổi ngoài cửa sổ vận hành hoặc vượt dải đã phê duyệt;
• Lệnh start/stop dày hơn baseline hoặc không khớp mức/áp suất;
• Feedback bơm chạy nhưng dòng/kW không xác nhận, hoặc ngược lại;
• Áp suất, lưu lượng, mức bể và trạng thái van mâu thuẫn;
• Cảm biến giữ nguyên quá lâu, timestamp lùi hoặc quality bị thay;
• Nhiều trạm thay đổi cùng lúc dù nhu cầu hệ thống không đổi;
• Cảnh báo bị disable, sửa priority hoặc acknowledgment hàng loạt.

Hệ giám sát OT nên ưu tiên thu thập thụ động, baseline theo từng trạm và có quy tắc giảm báo giả. Alarm cybersecurity cũng cần owner, mức độ, runbook và bằng chứng đóng sự kiện; nếu chỉ đẩy hàng nghìn log lên SIEM mà không ai hiểu tag bơm thì “visibility” chưa trở thành khả năng ứng phó.

Đồng bộ thời gian và chất lượng dữ liệu là kiểm soát bảo mật

Điều tra một chuỗi sự kiện cần ghép log VPN, firewall, HMI, PLC, broker và historian. Nếu mỗi thiết bị lệch vài phút, rất khó biết lệnh xảy ra trước hay sau khi áp suất đổi. Cần:

• Nguồn thời gian tin cậy theo kiến trúc zone;
• Giới hạn thiết bị được phép làm time server;
• Cảnh báo khi offset vượt ngưỡng hoặc thời gian nhảy lùi;
• Lưu timestamp nguồn, timestamp gateway và timestamp nhận;
• Không cho dữ liệu stale/uncertain điều khiển như dữ liệu good.

Độ mới của dữ liệu phải được định nghĩa theo use case. Telemetry năng lượng có thể chấp nhận trễ lâu hơn tín hiệu mức dùng để điều khiển. Không dùng một TTL cho mọi tag.

Sao lưu OT: không chỉ là copy file PLC

NIST SP 1339 về sao lưu OT nhấn mạnh việc tích hợp backup vào quản lý thay đổi, tạo bản sao đều đặn, thử nghiệm và xem xét trong diễn tập phục hồi. Phạm vi sao lưu của hệ bơm nên gồm:

• Chương trình PLC, safety/relay logic và đúng phiên bản phần mềm để mở;
• Project HMI/SCADA, tag database, alarm, historian schema và report;
• Tham số VFD, soft starter, công tơ, gateway, router và firewall;
• Chứng thư, trust list, khóa phục hồi và quy trình cấp lại bí mật;
• Sơ đồ mạng, inventory, mapping I/O, logic liên động và cause–effect;
• Golden image của máy kỹ thuật/máy chủ nếu bản quyền cho phép;
• Danh sách liên hệ, tài khoản khẩn cấp và hướng dẫn khởi động cục bộ.

Hai chỉ tiêu phục hồi phải gắn với quá trình:

RPO = Khoảng mất dữ liệu tối đa có thể chấp nhận
RTO = Thời gian tối đa để khôi phục chức năng cần thiết

RPO của historian có thể tính theo phút hoặc giờ, còn cấu hình PLC cần backup sau mọi thay đổi đã phê duyệt. RTO cho dashboard trung tâm có thể dài hơn RTO cho khả năng điều khiển cục bộ. Một bài thử restore đạt yêu cầu khi đội ngũ dựng lại đúng chức năng trên phần cứng hoặc môi trường kiểm thử phù hợp, không chỉ khi file nén mở được.

Ứng cứu sự cố: ưu tiên trạng thái vật lý an toàn

Playbook OT phải được xây cùng vận hành, điện–điều khiển, IT/security, bảo trì và quản lý dịch vụ. Không nên sao chép playbook laptop rồi ra lệnh “tắt thiết bị ngay” trong mọi trường hợp. Với bơm, ngắt PLC hoặc mạng sai thời điểm có thể làm mất quan sát, dừng cấp nước hoặc tạo chuyển tiếp thủy lực.

Trình tự tham khảo:

1. Xác minh quá trình: kiểm tra áp suất, mức, lưu lượng, trạng thái bơm/van bằng nguồn độc lập nếu có.
2. Ổn định vận hành: giữ hoặc chuyển trạm về local/manual/auto cục bộ theo playbook đã duyệt.
3. Giới hạn đường tấn công: cô lập đúng zone, phiên remote hoặc gateway bị nghi ngờ; tránh cắt tràn lan khi chưa đánh giá hậu quả.
4. Bảo toàn bằng chứng: log, thời gian, ảnh HMI, cấu hình, tài khoản, lưu lượng mạng và hành động của đội.
5. Loại bỏ nguyên nhân: đóng phơi nhiễm, thu hồi/đổi bí mật, làm sạch endpoint, sửa cấu hình và vá khi phù hợp.
6. Khôi phục known-good: dùng backup đã xác thực, kiểm tra checksum/version và chức năng liên động.
7. Đưa vào vận hành theo bước: xác nhận I/O, local control, protection, SCADA, remote access rồi mới mở lại đầy đủ.
8. Rút kinh nghiệm: cập nhật inventory, rule, playbook, đào tạo và trách nhiệm nhà cung cấp.

NIST SP 800-61 Rev. 3 liên kết ứng cứu sự cố với toàn bộ quản trị rủi ro: Govern, Identify và Protect giúp chuẩn bị/giảm tác động; Detect, Respond và Recover giúp phát hiện, xử lý và phục hồi. Với OT, mỗi bước phải kèm người có quyền quyết định trạng thái quá trình.

Bảo mật nền tảng quản lý nhiều trạm

Khi nhiều trạm đưa dữ liệu về một nền tảng, trung tâm giúp quản trị thống nhất nhưng cũng tạo phạm vi ảnh hưởng lớn hơn. Cần tránh một tài khoản hoặc một lỗi cấu hình có quyền vượt toàn đội trạm.

Tách tenant, site và môi trường

Mỗi user, service account và token phải được giới hạn theo tổ chức, vùng, site và chức năng. Môi trường development/test không được dùng khóa production hoặc kết nối ghi trực tiếp xuống trạm. Kiểm thử quyền phải có cả trường hợp dương và âm: user được xem Site A, đồng thời chứng minh không đọc/ghi được Site B.

Giảm điểm hỏng trung tâm

Nền tảng trung tâm ngừng hoạt động không được làm relay/PLC mất bảo vệ. Gateway cần store-and-forward cho telemetry; trạm giữ logic cục bộ; dashboard thể hiện rõ dữ liệu stale khi khôi phục. Cấu hình failover, backup và khôi phục broker/historian phải được thử như một phần nghiệm thu.

API và tích hợp doanh nghiệp

CMMS, ERP, BI hoặc ứng dụng di động thường chỉ cần đọc dữ liệu tổng hợp. Không cấp quyền ghi PLC chỉ vì tích hợp dùng chung API gateway. Tách API read và command; xác thực client; giới hạn tốc độ; kiểm tra schema; ký/audit lệnh; không đưa bí mật vào mã nguồn hoặc dashboard.

Ví dụ: thiết kế bảo mật cho cụm bơm công nghiệp

Giả sử một nhà máy có ba bơm ly tâm: hai máy chạy luân phiên và một máy dự phòng. Có cảm biến áp suất hút/đẩy, lưu lượng, mức bể, công tơ; PLC điều khiển VFD; gateway gửi dữ liệu về nền tảng trung tâm. Hệ có nhu cầu xem từ xa, xác nhận alarm và thay đổi một số setpoint đã giới hạn.

Phần thủy lực có thể dùng máy bơm nước công nghiệp Pentax, nhưng model phải được chọn từ yêu cầu Q–H, vật liệu, chất lỏng và điều kiện lắp đặt. Cybersecurity được thiết kế quanh hệ điều khiển, không dựa vào tên thương hiệu bơm.

Phân lớp chức năng

Nếu cụm dùng máy bơm nước Pentax CM EN733, model và đường đặc tính phải được lưu trong asset model để đặt giới hạn vận hành đúng cho từng máy. Ví dụ, Máy bơm nước Pentax CM32-160A công suất 4HP (3kW) và Máy bơm nước Pentax CM50-200A công suất 20HP (15kW) không được dùng chung dải dòng, công suất hoặc giới hạn Q–H. Đây vừa là yêu cầu kỹ thuật vận hành vừa giúp phát hiện lệnh/setpoint bất thường đúng ngữ cảnh.

Với một cụm nhỏ dùng máy bơm nước Pentax CMS, chẳng hạn Máy bơm nước Pentax CMS40C/7.5 công suất 10 HP, 7.5 kW, kiến trúc bảo mật có thể gọn hơn nhưng vẫn giữ cùng nguyên tắc: không phơi PLC, tài khoản riêng, local interlock, backup và kiểm soát lệnh. Quy mô nhỏ không phải lý do dùng mật khẩu mặc định.

Không đồng nhất cybersecurity với lựa chọn thương hiệu bơm

Doanh nghiệp có thể vận hành lẫn máy bơm nước Ebara, máy bơm Ebara 3M, máy bơm nước Ebara 3D và nhiều dòng Pentax trên cùng nền tảng. Chính sách mạng nên dựa trên vai trò của PLC, VFD, gateway và dữ liệu, không cấp quyền khác nhau chỉ vì nhãn bơm.

Điều cần giữ riêng theo model là baseline vận hành, giới hạn Q–H–kW, số lần khởi động, nhiệt độ, chế độ điều khiển và hậu quả khi mất máy. Ví dụ một Máy bơm nước Pentax CM65-200A công suất 30HP (22kW) làm nhiệm vụ chính có mức criticality khác một bơm phụ trợ nhỏ, dù cùng kết nối qua một loại gateway.

Mua mới và tích hợp: yêu cầu bảo mật ngay từ hồ sơ kỹ thuật

Nếu chỉ hỏi cybersecurity sau khi nghiệm thu, chủ đầu tư thường nhận một hệ khó đổi mật khẩu, không xuất log, firmware phụ thuộc nhà thầu và remote access không thể kiểm soát. Hồ sơ mua sắm nên yêu cầu nhà cung cấp trả lời:

• Thiết bị hỗ trợ tài khoản cá nhân, RBAC và MFA ở lớp nào?
• Có bắt buộc đổi thông tin mặc định trong commissioning không?
• Giao thức, cổng và dịch vụ nào là bắt buộc; cái nào tắt được?
• Chứng thư/khóa được cấp, lưu, xoay và thu hồi ra sao?
• Firmware có ký số/secure update không; vòng đời hỗ trợ bao lâu?
• Có SBOM hoặc thông tin thành phần phần mềm phù hợp không?
• Log nào xuất được, định dạng gì và đồng bộ thời gian thế nào?
• Backup/restore có tài liệu, license và công cụ cần thiết không?
• Remote support có thể tắt mặc định, bật theo phiên và ghi log không?
• Ai sở hữu project PLC/HMI, mật khẩu, cấu hình và tài liệu sau bàn giao?
• Quy trình công bố lỗ hổng và thông báo bản vá của nhà cung cấp là gì?
• Hệ thống vận hành an toàn thế nào khi mất cloud, WAN hoặc danh tính trung tâm?

IEC 62443-2-1:2024 quy định các yêu cầu chương trình bảo mật cho chủ sở hữu tài sản IACS đang vận hành. Tiêu chuẩn hữu ích để biến cybersecurity từ một danh sách thiết bị mua thêm thành chính sách, trách nhiệm và quy trình suốt vòng đời.

KPI cybersecurity nào có ích cho đội vận hành bơm?

KPI phải cho thấy mức giảm rủi ro hoặc khả năng phục hồi, không chỉ đếm số cảnh báo. Một bộ tối thiểu có thể gồm:

Ví dụ công thức coverage:

Asset_inventory_coverage (%) =
  Số tài sản đủ owner + zone + criticality + version
  -------------------------------------------------- × 100
  Tổng tài sản OT đã xác nhận

Đừng đặt mục tiêu “100% bản vá trong 24 giờ” cho mọi OT nếu không xét khả năng thử nghiệm và cửa sổ dừng. Mục tiêu tốt hơn là mọi rủi ro có owner, deadline, bằng chứng đánh giá và biện pháp bù trừ trong khi chờ xử lý.

Lộ trình triển khai theo bốn giai đoạn

Giai đoạn 0: chặn rủi ro dễ khai thác

• Tìm và gỡ PLC/HMI/router/gateway phơi Internet;
• Đổi tài khoản mặc định, vô hiệu tài khoản không rõ owner;
• Tắt remote access không dùng; bật MFA cho đường còn lại;
• Kiểm tra backup tối thiểu của PLC/HMI/VFD/firewall;
• Xác định người có quyền chuyển trạm về local/manual.

Giai đoạn 1: biết mình có gì và kết nối ra sao

• Lập inventory và sơ đồ zone/conduit;
• Ghi nguồn–đích–cổng–giao thức–chiều và owner từng luồng;
• Phân loại criticality theo hậu quả vật lý;
• Chuẩn hóa tài khoản, vai trò, nhà thầu và vòng đời chứng thư;
• Thiết lập quản lý thay đổi và baseline cấu hình.

Giai đoạn 2: phân vùng, giám sát và phục hồi

• Triển khai OT DMZ/jump host/gateway phù hợp;
• Áp default deny và allowlist theo use case;
• Thu log quan trọng, đồng bộ thời gian và cảnh báo logic/process;
• Thiết kế backup offline/immutable theo khả năng;
• Thử restore, failover và vận hành khi mất WAN.

Giai đoạn 3: vận hành chương trình liên tục

• Rà soát quyền, firewall rule, chứng thư và tài khoản định kỳ;
• Quản lý lỗ hổng/bản vá theo rủi ro và vòng đời hỗ trợ;
• Diễn tập kịch bản đa đội: IT compromise, mất cloud, PLC lockout;
• Đo KPI phục hồi và khép vòng bài học;
• Đưa yêu cầu security-by-design vào mọi gói mua sắm mới.

Thời gian của từng giai đoạn phụ thuộc số trạm, công nghệ và khả năng dừng. Không cần chờ nền tảng hoàn hảo mới đổi mật khẩu mặc định hoặc đóng port forwarding đang thừa; cũng không nên thay rule firewall hàng loạt mà chưa đối chiếu luồng nghiệp vụ.

Checklist nghiệm thu hệ bơm kết nối mạng

Những sai lầm phổ biến cần tránh

“Đã có VPN nên an toàn”

VPN chỉ bảo vệ đường truyền. Tài khoản bị lộ, máy đầu cuối nhiễm mã độc hoặc quyền quá rộng vẫn tạo phiên hợp lệ. Cần MFA, kiểm tra thiết bị, gateway, RBAC, JIT và giám sát.

“Trạm nhỏ, không ai quan tâm”

Thiết bị phơi Internet có thể bị tìm tự động; kẻ tấn công không cần biết trước tên nhà máy. Quy mô nhỏ còn thường đồng nghĩa ít người giám sát và mật khẩu lâu không đổi.

“Mạng riêng/APN riêng là đủ”

Private APN hoặc mạng thuê riêng giảm một số đường tiếp cận nhưng không thay thế xác thực, phân vùng, hardening và giám sát. Sai cấu hình, nhà thầu, endpoint bị chiếm hoặc kết nối nội bộ vẫn là rủi ro.

“Chỉ đọc dữ liệu nên không thể gây hại”

Tài khoản read-only vẫn có thể làm lộ sơ đồ, trạng thái, lịch vận hành và dữ liệu phục vụ chuẩn bị tấn công. Hơn nữa, cần xác minh thật sự không có API, thanh ghi hoặc route ghi ngược nào nằm ngoài tài liệu.

“Có backup là khôi phục được”

File có thể thiếu phiên bản phần mềm, license, password, certificate hoặc không tương thích phần cứng thay thế. Chỉ bài thử restore mới chứng minh khả năng phục hồi.

“Cybersecurity là việc riêng của IT”

IT/security hiểu danh tính, mạng, log và sự cố; vận hành hiểu trạng thái vật lý; điện–điều khiển hiểu logic, I/O và liên động; bảo trì hiểu tài sản và thay đổi; quản lý quyết định rủi ro. Thiếu một bên, biện pháp có thể đúng kỹ thuật mạng nhưng sai quá trình.

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

Có nên cho phép khởi động/dừng bơm từ điện thoại?

Chỉ nên cho phép nếu có use case rõ, MFA, thiết bị/ứng dụng được quản lý, quyền theo site, lệnh có TTL, phê duyệt phù hợp, PLC kiểm tra toàn bộ liên động và có audit/readback. Với nhiều hệ, điện thoại chỉ nên nhận cảnh báo và xem dữ liệu; lệnh rủi ro cao thực hiện qua trung tâm điều hành hoặc quy trình hai người.

Mất Internet thì trạm bơm nên dừng hay tiếp tục chạy?

Không có câu trả lời chung. Trạm cấp nước, tăng áp, tuần hoàn và thoát nước có hậu quả khác nhau. Phải phân tích quá trình để chọn auto cục bộ, giữ setpoint cuối đã phê duyệt, chuyển setpoint dự phòng hoặc dừng có kiểm soát. Liên động tại chỗ vẫn phải hoạt động.

Có cần mã hóa mọi kết nối Modbus trong nội bộ?

Nên dùng bảo vệ mạnh khi thiết bị và yêu cầu cho phép, nhưng thiết bị cũ có thể không hỗ trợ. Khi đó, cần phân vùng chặt, allowlist peer, giới hạn quyền ghi, không đưa Modbus nguyên bản qua mạng không tin cậy và giám sát hành vi. Mã hóa không thay thế các kiểm soát này.

Firewall IT có dùng cho mạng bơm được không?

Có thể nếu đáp ứng độ sẵn sàng, môi trường, hiệu năng, giao thức, quản trị và kiểm thử của OT. Quan trọng hơn nhãn “industrial” là kiến trúc dự phòng, rule tối thiểu, quản lý thay đổi, log, hỗ trợ vòng đời và khả năng vận hành an toàn khi thiết bị firewall lỗi.

Bơm điều khiển contactor, không PLC, có cần cybersecurity không?

Nếu hệ hoàn toàn không có kết nối số thì bề mặt tấn công mạng rất nhỏ, nhưng vẫn cần an ninh vật lý và kiểm soát tủ điện. Khi bổ sung công tơ mạng, relay thông minh, HMI, router hoặc gateway để giám sát, các thành phần đó phải được đưa vào phạm vi cybersecurity.

Nên chọn bơm nào cho hệ kết nối mạng?

Chọn bơm theo yêu cầu thủy lực, chất lỏng, vật liệu, hiệu suất, độ tin cậy và điều kiện lắp đặt. Khả năng kết nối chủ yếu nằm ở tủ điều khiển, cảm biến và nền tảng. Ví dụ bơm tăng áp như Máy bơm tăng áp trục đứng Pentax U5V-200/7T 2HP (1.5kW) vẫn cần được lựa chọn theo điểm làm việc; còn quyền remote, liên động và bảo mật là yêu cầu riêng của giải pháp điều khiển.

Kết luận

Cybersecurity cho hệ bơm kết nối mạng không bắt đầu bằng việc mua thêm một thiết bị bảo mật. Nó bắt đầu bằng việc biết tài sản nào đang kết nối, hậu quả vật lý nếu dữ liệu/lệnh bị sai, đường nào thực sự cần mở và ai có quyền thực hiện hành động. Từ nền tảng đó, doanh nghiệp phân vùng OT/IT, loại bỏ phơi nhiễm Internet, quản lý truy cập từ xa, làm cứng endpoint, kiểm soát lệnh và giám sát cả mạng lẫn quá trình.

Một kiến trúc tốt có hai phẩm chất đồng thời: trung tâm nhìn thấy đủ để quản lý và trạm vẫn tự chủ để an toàn. Khi cloud hoặc WAN mất, PLC và relay vẫn bảo vệ bơm; khi một tài khoản bị xâm phạm, quyền bị giới hạn theo site và chức năng; khi một thành phần hỏng, backup đã thử cho phép phục hồi; khi có sự cố, đội vận hành và security phối hợp theo playbook thay vì ứng biến.

Thứ tự đầu tư hợp lý thường rất rõ: đóng các cổng đang phơi, bỏ mật khẩu mặc định, lập inventory, bật MFA, phân vùng và thử khôi phục trước khi chạy theo các giải pháp phát hiện phức tạp. Cybersecurity bền vững không phải trạng thái “làm xong một lần”, mà là một chương trình vận hành gắn với mọi thay đổi của bơm, PLC, mạng, nền tảng và con người.