Kiểm soát lưu lượng đông-tây dựa trên Microsegmentation và triển khai Zero Trust

1. Tổng quan

Microsegmentation (vi phân đoạn) là kỹ thuật thiết kế bảo mật chia người dùng·ứng dụng·workload·thiết bị·luồng dữ liệu thành các vùng logic rất nhỏ theo thuộc tính nghiệp vụ và nhu cầu giao tiếp, đồng thời kiểm soát chi tiết việc giao tiếp giữa các vùng bằng danh sách cho phép (allow list) và chính sách.

Bảo mật mạng truyền thống phát triển theo hướng đặt tường lửa tại ranh giới giữa Internet và mạng nội bộ, còn bên trong thì cho phép giao tiếp tương đối rộng.

Cấu trúc này dễ vận hành vào thời kỳ trung tâm dữ liệu và hệ thống nghiệp vụ ở vị trí cố định, và người dùng truy cập từ bên trong tòa nhà công ty.

Tuy nhiên, khi cloud, container, SaaS, làm việc tại nhà, liên kết với đối tác lan rộng, vị trí của người dùng và vị trí vật lý của máy chủ khó còn là tiêu chí bảo vệ.

Nếu kẻ tấn công chiếm được một tài khoản hoặc một máy chủ rồi có thể thực hiện di chuyển ngang (Lateral Movement) sang máy chủ khác bên trong, thiệt hại sẽ lớn hơn nhiều so với điểm xâm nhập ban đầu.

Microsegmentation xử lý vấn đề này từ góc độ lưu lượng đông-tây (East-West).

Lưu lượng đông-tây, khác với lưu lượng bắc-nam (North-South) giữa người dùng và Internet, là các luồng nội bộ giữa máy chủ với máy chủ, dịch vụ với dịch vụ, thiết bị đầu cuối với thiết bị đầu cuối.

Do đó, chỉ tăng cường tường lửa bên ngoài là không đủ; phải xác nhận mọi giao tiếp nội bộ có phải là luồng cần thiết cho nghiệp vụ hay không và chặn các kết nối không cần thiết.

NIST SP 800-207 mô tả Zero Trust là mô hình bảo mật loại bỏ sự tin cậy ngầm định dựa trên vị trí mạng và đánh giá liên tục quyền truy cập vào tài nguyên, đồng thời nêu microsegmentation logic là một trong các cách tiếp cận của kiến trúc Zero Trust (NIST SP 800-207).

Microsegmentation không phải bản thân Zero Trust, mà là phương tiện thực thi đặc quyền tối thiểu và giả định bị xâm nhập của Zero Trust tại ranh giới mạng·workload.

Nói cách khác, cần có cả hệ thống chính sách ra quyết định truy cập dựa trên danh tính và ngữ cảnh, lẫn điểm thực thi thực sự chặn hoặc cho phép gói tin·phiên·lời gọi dịch vụ.

A. Bối cảnh ra đời và sự cần thiết

Thứ nhất, ảo hóa và container khiến các workload của các nghiệp vụ và khách hàng khác nhau được bố trí đồng thời trên một máy chủ vật lý.

Nếu mọi workload có thể giao tiếp với nhau chỉ vì nằm trên cùng một host hoặc cùng một cluster, một lỗ hổng có thể lan rộng sang nhiều dịch vụ.

Thứ hai, kiến trúc microservice nhằm tăng tốc độ phát triển đã làm gia tăng đáng kể các lời gọi API giữa các dịch vụ.

Khi số dịch vụ tăng, kết nối mạng cũng phức tạp hơn, nên quy tắc đơn giản "tin cậy dịch vụ nội bộ" lại trở thành đường di chuyển của kẻ tấn công.

Thứ ba, trong môi trường hybrid·multi-cloud, khó quản lý nhất quán mọi luồng nghiệp vụ chỉ bằng VLAN hoặc tường lửa vật lý.

Phải gộp security group của cloud, tường lửa host, service mesh, chính sách mạng container vào một mô hình chính sách thì mới duy trì được cùng một kiểm soát dù vị trí tài sản thay đổi.

Thứ tư, trong các sự cố ransomware và chiếm đoạt tài khoản, việc chặn lan rộng sau xâm nhập ban đầu nhanh đến đâu quyết định quy mô thiệt hại.

Phân đoạn càng nhỏ và chính sách càng cụ thể thì các đường mà kẻ tấn công có thể dùng và phạm vi tài nguyên có thể truy cập càng bị thu hẹp.

2. Nguyên lý cốt lõi và cấu trúc khái niệm

Cốt lõi của microsegmentation không nằm ở việc chia nhỏ mạng một cách vô điều kiện.

Bản chất là nhận diện các luồng nghiệp vụ, biểu diễn chủ thể·đích·hành vi·điều kiện của từng luồng, rồi chỉ cho phép giao tiếp cần thiết.

Đơn vị chính sách không chỉ dừng ở địa chỉ IP và cổng mà có thể mở rộng sang người dùng, trạng thái thiết bị, tên ứng dụng, nhãn workload, tài khoản dịch vụ, cấp dữ liệu, môi trường và phiên bản triển khai.

Sơ đồ khái niệm sau thể hiện cấu trúc tổng thể từ phát hiện tài sản đến thực thi chính sách và quan sát liên tục.

flowchart LR
    A[Người dùng·Thiết bị·Workload] --> F[Phát hiện luồng·Nhận diện tài sản]
    F --> C[Ngữ cảnh nghiệp vụ·Phân cấp dữ liệu]
    C --> P[Mô hình chính sách<br/>Chủ thể-Hành vi-Đích-Điều kiện]
    I[IdP·CMDB·Thẻ cloud] --> P
    T[Tình báo mối đe dọa·Trạng thái thiết bị] --> P
    P --> D[Quyết định chính sách·Mô phỏng]
    D --> E[Điểm thực thi<br/>Tường lửa·Agent·CNI·Proxy]
    E --> W[Luồng đông-tây được phép]
    E --> X[Chặn·Cô lập·Xác thực bổ sung]
    E --> L[Log·Metric·Bản ghi luồng]
    L --> O[Phân tích·Cải tiến chính sách]
    O -. Phản hồi .-> P

A. Bề mặt bảo vệ và phân đoạn

Bề mặt bảo vệ (protect surface) là khái niệm ưu tiên nhận diện dữ liệu·ứng dụng·dịch vụ có mức tác động kinh doanh cao, thay vì coi mọi tài sản là đối tượng bảo vệ cùng lúc.

Ví dụ, cơ sở dữ liệu thanh toán, kho dữ liệu cá nhân khách hàng, dịch vụ xác thực, máy chủ điều khiển sản xuất không có cùng mức ưu tiên bảo mật với máy chủ phát triển thông thường.

Khi định nghĩa bề mặt bảo vệ, có thể căn ranh giới phân đoạn theo mức quan trọng nghiệp vụ và quan hệ giao tiếp thay vì vị trí vật lý của tài sản.

Phân đoạn có thể chia theo địa chỉ mạng như VLAN, hoặc theo security group của cloud, tường lửa host, namespace container, danh tính workload của service mesh.

Có thể biến một workload thành một phân đoạn, nhưng trong môi trường thực tế, xét đến độ phức tạp quản lý và hiệu năng, người ta thường gộp các nhóm tài sản dùng chung một chính sách.

Phân đoạn quá lớn thì không hạn chế đủ di chuyển ngang, còn quá nhỏ thì số chính sách bùng nổ khiến người vận hành lạm dụng ngoại lệ.

Vì vậy, kích thước phân đoạn không nên là "đơn vị nhỏ nhất" mà là "đơn vị có thể quản lý rủi ro độc lập và giải thích được luồng nghiệp vụ".

B. Chủ thể·Đích·Hành vi·Điều kiện

Chính sách có thể bắt đầu từ quy tắc kỹ thuật "cho phép TCP 443 từ mạng A sang mạng B".

Tuy nhiên, trong môi trường cloud và container, IP bị cấp phát lại và instance thường xuyên bị thay thế, nên nếu duy trì chính sách chỉ bằng IP thì mỗi lần thay đổi đều cần thao tác thủ công.

Thay vào đó, cần biểu diễn ý nghĩa của chủ thể và đích, ví dụ "dịch vụ đơn hàng gọi API phê duyệt thanh toán của dịch vụ thanh toán thuộc phiên bản triển khai đã được phê duyệt".

Chủ thể có thể là con người, tài khoản dịch vụ, ứng dụng, thiết bị, bộ lập lịch tác vụ.

Đích có thể là tài nguyên được bảo vệ như dịch vụ web, message queue, cơ sở dữ liệu, kho tệp, giao diện quản trị.

Hành vi không chỉ là kết nối mà có thể định nghĩa chi tiết như phương thức API, lệnh cơ sở dữ liệu, đọc·ghi tệp, lệnh quản trị.

Điều kiện gồm thời gian, môi trường (dev·staging·production), phiên bản triển khai, trạng thái bảo mật thiết bị, cấp dữ liệu, mức rủi ro của yêu cầu, đã được phê duyệt hay chưa.

Sử dụng các thuộc tính này, cùng một dịch vụ có thể được kiểm soát phân biệt: cho phép truy cập kiểm thử rộng ở môi trường phát triển, còn ở môi trường vận hành chỉ cho phép yêu cầu đọc của một tài khoản dịch vụ cụ thể.

C. Từ chối mặc định và đặc quyền tối thiểu

Giá trị mặc định thông thường của microsegmentation là từ chối các luồng không được cho phép một cách tường minh.

Tuy nhiên, nếu chặn toàn diện trước khi nắm được luồng nghiệp vụ thì sẽ xảy ra sự cố, nên ban đầu thu thập giao tiếp thực tế ở chế độ quan sát và tạo ra các ứng viên chính sách.

Ứng viên chính sách không được tự động trở thành quy tắc cho phép.

Người vận hành và người phụ trách dịch vụ phải xác nhận đó là luồng nghiệp vụ bình thường, kết nối gỡ lỗi tạm thời, hay giao tiếp không cần thiết của agent cũ.

Đặc quyền tối thiểu là quá trình thu hẹp không chỉ đối tượng kết nối mà cả chiều kết nối, cổng, API được gọi, loại dữ liệu, thời gian phiên.

Ví dụ, việc dịch vụ đơn hàng được phép gửi yêu cầu đến dịch vụ thanh toán không có nghĩa là nó được truy cập cả cổng quản trị và shell vận hành của dịch vụ thanh toán.

Chính sách từ chối mặc định ảnh hưởng đến tính sẵn sàng, nên phải thiết kế đồng thời thủ tục phê duyệt ngoại lệ và thủ tục gỡ bỏ khẩn cấp.

Việc gỡ bỏ khẩn cấp phải tự động hết hạn sau một thời gian và ghi lại lý do·người phê duyệt·phạm vi ảnh hưởng thì mới không trở thành đường vòng vĩnh viễn.

D. Kiểm chứng liên tục và giả định bị xâm nhập

Microsegmentation không phải là công nghệ tin cậy vĩnh viễn chủ thể đã vào được phân đoạn.

Khi chứng chỉ dịch vụ hết hạn, trạng thái bảo mật của thiết bị xấu đi, hoặc phát hiện hành vi bất thường, phải có khả năng đánh giá lại quyền của phiên hiện có.

Giả định bị xâm nhập của Zero Trust có nghĩa là thiết kế sao cho dù một tài sản đã bị xâm nhập, kẻ tấn công cũng không thể tự động di chuyển sang tài sản khác.

Vì vậy, chính sách phải bao gồm không chỉ tình huống bình thường mà cả cách thu hẹp trong tình huống chiếm đoạt tài khoản, thực thi tiến trình độc hại, yêu cầu hàng loạt bất thường, mã độc xâm nhập qua chuỗi cung ứng.

3. Kiến trúc triển khai và quy trình hoạt động

Cách triển khai thay đổi theo loại tài sản và tầng giao tiếp.

Với máy chủ trung tâm dữ liệu có thể áp dụng host agent hoặc tường lửa host, với cloud có thể dùng security group gốc và tường lửa mạng.

Với container có thể kết hợp chính sách mạng của plugin CNI với sidecar hoặc node proxy của service mesh.

Với tài sản khó cài agent như OT·IoT, cần các kiểm soát lấy mạng làm trung tâm như switch, tường lửa, cảm biến thụ động, NAC dựa trên danh tính.

Sequence sau là quy trình vận hành từ quan sát đến thực thi chính sách và ứng phó sự cố.

sequenceDiagram
    participant S as Tài sản·Workload
    participant V as Trực quan hóa luồng
    participant C as Phân loại·CMDB
    participant P as Policy engine
    participant E as Điểm thực thi
    participant R as Tài nguyên được bảo vệ
    participant O as SIEM·Phân tích
    S->>V: Gửi luồng giao tiếp·Metadata
    V->>C: Phân tích tương quan tài sản·Dịch vụ·Phụ thuộc
    C->>P: Cung cấp chủ thể·Đích·Ngữ cảnh nghiệp vụ
    P-->>E: Triển khai ứng viên chính sách chế độ quan sát
    E->>R: Ghi kết quả cho phép·Chặn và độ trễ
    E->>O: Gửi log vi phạm chính sách·Phiên·Luồng
    O-->>P: Tín hiệu rủi ro·Yêu cầu đánh giá lại
    P-->>E: Chính sách thu hẹp quyền·Cô lập·Chặn
    E-->>S: Duy trì·Kết thúc phiên hoặc cô lập

A. Phát hiện tài sản và đường cơ sở luồng

Bước đầu tiên không phải là viết ngay quy tắc tường lửa mà là làm cho danh mục tài sản và quan hệ giao tiếp trở nên đáng tin cậy.

Liên kết địa chỉ IP, hostname, tài khoản cloud, thẻ, nhãn container, tài khoản dịch vụ, tổ chức sở hữu vào một hệ thống định danh duy nhất trong phạm vi có thể.

Thu thập NetFlow·VPC Flow Logs·metadata gói tin·log ứng dụng giúp nắm được ai kết nối đến tài nguyên nào qua cổng nào với tần suất bao nhiêu.

Với lưu lượng được mã hóa, dù không giải mã nội dung vẫn có thể xác nhận luồng cơ bản bằng metadata như hai đầu cuối, thời gian, cổng, số byte, tần suất kết nối.

Các luồng chưa xác nhận được chủ sở hữu và mục đích nghiệp vụ không nên xóa ngay mà đánh dấu mức rủi ro và tác động rồi đưa vào diện điều tra.

Đường cơ sở cũng phải bao gồm khung giờ của batch job, chu kỳ lưu lượng sao lưu, đường thay thế khi chuyển đổi dự phòng (failover).

Nếu không, có thể nhầm bản sao lưu ban đêm bình thường là tấn công, hoặc bỏ sót luồng cần thiết khi sự cố khỏi chính sách.

B. Mô hình chính sách và vòng đời chính sách

Mô hình chính sách là biểu diễn trung gian chuyển quy tắc nghiệp vụ bằng ngôn ngữ tự nhiên thành quy tắc thực thi thực tế.

Các trường tối thiểu cần có trong chính sách là chủ thể, hành vi, đích, giao thức·cổng, điều kiện, quyết định, ngày hết hạn, chủ sở hữu, căn cứ.

Ghi lại căn cứ của chính sách giúp xác nhận "ai đã cho phép luồng này theo yêu cầu nghiệp vụ nào" khi kiểm toán hoặc phân tích sự cố.

Chính sách phải có vòng đời tạo·rà soát·mô phỏng·phê duyệt·triển khai·quan sát·sửa đổi·hủy bỏ.

Dù nhà phát triển yêu cầu mở cổng khẩn cấp, nếu xử lý như ngoại lệ vĩnh viễn không có hạn thì nợ bảo mật sẽ tích lũy.

Dùng chính sách dưới dạng mã (policy as code) có thể lưu lịch sử thay đổi và peer review, nhưng cần kiểm chứng sự khác biệt giữa khả năng biểu đạt của ngôn ngữ chính sách và bộ thực thi thực tế.

Mô phỏng chính sách phải xác nhận luồng đang được phép có bị chặn không, thứ tự quy tắc có đúng ý đồ không, quy tắc rộng hơn có ghi đè quy tắc hẹp hơn không.

C. Điểm quyết định chính sách và điểm thực thi chính sách

Điểm quyết định chính sách (PDP) phán định cho phép hay từ chối truy cập, còn điểm thực thi chính sách (PEP) cưỡng chế quyết định đó trên đường giao tiếp thực tế.

Trong cấu trúc logic của NIST SP 800-207, policy engine tạo quyết định còn policy administrator truyền chỉ thị tạo·sửa·kết thúc phiên đến điểm thực thi.

Điểm thực thi của microsegmentation có thể được hiện thực bằng tường lửa, router, host agent, security group của cloud, plugin mạng container, proxy của service mesh.

Dù policy engine trả về "cho phép" một cách bình thường, nếu tài nguyên bị phơi nhiễm trực tiếp qua một đường vòng khác thì kiểm soát thất bại.

Phải điều chỉnh đồng thời định tuyến, security group, tường lửa host để tài nguyên được bảo vệ không thể truy cập nếu không đi qua điểm thực thi đã được phê duyệt.

Hành vi khi điểm thực thi gặp sự cố cũng quan trọng.

Khi dịch vụ xác thực hoặc policy engine tạm thời không khả dụng, quyết định duy trì phiên hiện có, chỉ chặn phiên mới, hay ưu tiên chặn tài nguyên rủi ro cao tùy theo mức quan trọng nghiệp vụ.

D. Khả năng quan sát và tự động hóa ứng phó

Không thể coi mọi hành động chặn là thành công.

Chính sách quá rộng thì không ngăn được lan rộng khi bị xâm nhập, còn quá hẹp thì chặn lời gọi bình thường khiến người vận hành tạo chính sách vòng.

Gửi mọi sự kiện cho phép·chặn·ngoại lệ·lỗi truy vấn chính sách·lỗi điểm thực thi về log tập trung, liên kết với thông tin tài sản·người dùng·ticket·triển khai.

Chỉ số vận hành có thể dùng tỷ lệ tài sản chưa phân loại, thời gian ở chế độ quan sát, số ngoại lệ chính sách, tỷ lệ ngoại lệ đã hết hạn, số lần thử lại sau khi bị chặn, tỷ lệ thất bại khi thay đổi chính sách.

Chỉ số bảo mật có thể theo dõi các nỗ lực kết nối trái phép đến tài sản quan trọng, đường di chuyển ngang giữa các phân đoạn, thời gian đến khi cô lập, số tài nguyên mà tài sản bị xâm nhập đã truy cập.

Cô lập tự động có thể gây gián đoạn nghiệp vụ khi dương tính giả, nên áp dụng ứng phó theo bậc cảnh báo·xác thực bổ sung·chỉ đọc·cô lập tùy theo mức quan trọng và độ tin cậy.

4. Các loại hình áp dụng và so sánh

A. Trung tâm dữ liệu và cloud

Trong môi trường trung tâm dữ liệu, có thể chia vùng lớn bằng VLAN·VRF·tường lửa nội bộ và bổ sung kiểm soát giữa các máy chủ bằng tường lửa host hoặc agent.

Cách này dễ tương thích với thiết bị hiện có, nhưng khó vận hành nhất quán do thay đổi địa chỉ IP và cú pháp chính sách khác nhau theo thiết bị.

Trong môi trường cloud, có thể tận dụng tài khoản·VPC·subnet·security group·network ACL·thẻ workload làm thuộc tính chính sách.

Tính năng cloud-native có khả năng mở rộng tốt, nhưng mỗi cloud có mô hình và định dạng log khác nhau nên tính di động của chính sách multi-cloud có thể giảm.

Do đó, cần đặt một mô hình chính sách chung cùng tầng chuyển đổi·kiểm chứng riêng cho từng cloud, và xác nhận lại kết quả thực thi thực tế ở từng môi trường.

B. Container và service mesh

Chính sách mạng container dùng namespace, nhãn pod, tài khoản dịch vụ... để hạn chế giao tiếp L3·L4.

Proxy của service mesh có thể tận dụng thông tin L7 như danh tính dịch vụ, mTLS, đường dẫn yêu cầu, phương thức nên có lợi cho chính sách ở mức API.

Ngược lại, nếu mọi lưu lượng đều đi qua proxy thì độ trễ·mức sử dụng tài nguyên·độ phức tạp vận hành có thể tăng.

Ngoài ra, chỉ chính sách mesh không thể bảo vệ mọi luồng phi ứng dụng như cổng quản trị node, DNS bên ngoài, đường lưu trữ.

Vì vậy, kết hợp phân tầng giữa cô lập cơ bản L3·L4 và kiểm soát chi tiết L7, đồng thời kiểm soát riêng các đường quản trị nằm ngoài mesh.

C. Dựa trên agent và dựa trên mạng

Cách dựa trên agent dễ phản ánh thông tin tiến trình·người dùng·workload vào chính sách và có thể kiểm soát chi tiết bên trong host.

Tuy nhiên, khó áp dụng cho OT·IoT không cài được agent, thiết bị có hiệu năng hạn chế, thiết bị của đối tác bên ngoài.

Cách dựa trên mạng có thể bảo vệ nhiều loại thiết bị bằng router·switch·tường lửa hiện có, nhưng khó nắm được ý nghĩa ứng dụng đã mã hóa và chủ thể ở mức tiến trình.

Hai cách này không phải quan hệ thay thế mà nên dùng bổ trợ lẫn nhau tùy theo đối tượng bảo vệ và tầng giao tiếp.

Phân loại	Phân vùng mạng truyền thống	Microsegmentation	ZTNA
Mục tiêu chính	Tách ranh giới vùng lớn	Hạn chế luồng đông-tây và di chuyển ngang	Kiểm soát truy cập ứng dụng của người dùng·thiết bị
Đơn vị chính sách	VLAN·Subnet·IP	Workload·Danh tính·Thẻ·Dịch vụ	Người dùng·Thiết bị·Tài nguyên·Ngữ cảnh
Luồng chính	Lưu lượng giữa các vùng	Luồng nội bộ giữa máy chủ·dịch vụ·thiết bị	Giữa người dùng·chủ thể bên ngoài và tài nguyên
Điểm thực thi	Router·Tường lửa	Host·CNI·Tường lửa·Proxy	Broker·Gateway·Agent
Ưu điểm	Tương đối dễ hiểu và vận hành	Thu hẹp bán kính ảnh hưởng và phạm vi chính sách	Kết nối tài nguyên mà không phơi nhiễm toàn mạng
Hạn chế	Tin cậy quá mức bên trong vùng	Độ phức tạp vận hành chính sách·tài sản·ngoại lệ	Khó liên kết với legacy·giao thức phi web

Ba công nghệ này không thay thế lẫn nhau.

Thiết kế nhiều lớp là thực tế: tối thiểu hóa truy cập của người dùng bên ngoài bằng ZTNA, kiểm soát giao tiếp giữa các workload nội bộ bằng microsegmentation, và cô lập các miền lỗi lớn của trung tâm dữ liệu bằng phân vùng mạng truyền thống.

5. Tình huống áp dụng

A. Tình huống dịch vụ thương mại điện tử

Sau đây là ví dụ giả định một doanh nghiệp thương mại điện tử vận hành các tầng web·đơn hàng·thanh toán·dữ liệu.

Lưu lượng từ Internet vào tầng web đi qua WAF và API gateway, và tầng web bị giới hạn chỉ được gọi API đơn hàng.

Dịch vụ đơn hàng có thể gọi API phê duyệt thanh toán và API tra cứu tồn kho, nhưng không truy cập được cổng quản trị của cơ sở dữ liệu thanh toán.

Dịch vụ thanh toán chỉ dùng stored procedure hoặc tài khoản đọc·ghi cụ thể cần cho việc phê duyệt, còn shell của người vận hành và đường xuất dữ liệu hàng loạt được tách riêng bằng phê duyệt riêng.

Luồng dịch vụ kiểm thử ở môi trường phát triển gọi đến tầng thanh toán vận hành bị từ chối mặc định, còn truy cập tạm thời tạo ra khi ứng phó sự cố được ghi số ticket và thời gian hết hạn vào chính sách.

Nếu tài khoản dịch vụ thanh toán tra cứu hàng loạt nhiều bảng của cơ sở dữ liệu khách hàng khác thường lệ, có thể chuyển tín hiệu rủi ro của SIEM đến policy engine để chuyển phiên sang chỉ đọc hoặc cô lập.

Hiệu quả của cấu trúc này là dù kẻ tấn công chiếm được tầng web cũng không thể di chuyển ngay sang tầng đơn hàng·thanh toán·dữ liệu cá nhân.

Tuy nhiên, nếu chặn luồng đơn hàng bình thường sẽ dẫn đến tổn thất doanh thu, nên phải thực thi chính sách dần dần qua chế độ quan sát và kiểm thử tải.

B. Tình huống môi trường sản xuất·OT

Tại nhà máy sản xuất, không được đối xử mạng IT văn phòng, máy chủ quản lý sản xuất, mạng điều khiển, mạng thiết bị·cảm biến ở cùng một mức bảo mật.

Giao thức điều khiển của thiết bị sản xuất chỉ được giao tiếp với máy chủ cần thiết cho nghiệp vụ theo chiều hạn chế, còn đường truy cập trực tiếp từ thiết bị văn phòng vào mạng điều khiển bị chặn.

Khi đối tác thực hiện bảo trì từ xa, chỉ cho phép truy cập vào thiết bị cụ thể qua máy chủ trung chuyển, trong thời gian được phê duyệt và từ thiết bị được phê duyệt.

Với thiết bị khó cài agent như PLC hoặc cảm biến cũ, cấu hình kiểm soát bằng giám sát thụ động, tường lửa công nghiệp, ACL của switch, jump server.

Trong mạng điều khiển, thay đổi chính sách bảo mật có thể ảnh hưởng đến tính sẵn sàng và an toàn, nên trước khi triển khai chính sách chặn phải qua mô phỏng, phê duyệt thay đổi và quy trình an toàn tại hiện trường.

Như cách tiếp cận Zone·Conduit của ISA/IEC 62443, gộp các tài sản có chức năng và rủi ro tương tự thành vùng và kiểm soát đường giao tiếp giữa các vùng giúp điều hòa các yêu cầu tính sẵn sàng khác nhau của IT và OT.

6. Chuyên sâu: Chiến lược triển khai theo giai đoạn và mức trưởng thành

Năm 2025, CISA công bố phần đầu tiên của hướng dẫn lập kế hoạch và áp dụng microsegmentation theo góc nhìn Zero Trust, mô tả nó như năng lực chia mạng và áp dụng kiểm soát bảo mật theo nhu cầu giao tiếp của trụ cột mạng (CISA Microsegmentation in Zero Trust, Part One).

Khi áp dụng luồng hướng dẫn này vào thực tiễn, điều quan trọng là hiểu tài sản và luồng nghiệp vụ trước khi đưa sản phẩm vào.

Giai đoạn 1 là chuẩn bị: xác định bề mặt bảo vệ·tài sản quan trọng·tổ chức sở hữu·yêu cầu quy định·mức chịu đựng sự cố.

Giai đoạn 2 là phát hiện: quan sát luồng trong một khoảng thời gian và chuẩn hóa các phụ thuộc tài sản·dịch vụ·người dùng·dữ liệu.

Giai đoạn 3 là thiết kế: biểu diễn luồng nghiệp vụ bằng chủ thể·hành vi·đích·điều kiện và mô phỏng các ứng viên chính sách.

Giai đoạn 4 là thực thi có giới hạn: áp dụng từ chối mặc định bắt đầu từ môi trường phát triển·kiểm thử có tác động thấp và chủ sở hữu rõ ràng hoặc một phần tài sản quan trọng.

Giai đoạn 5 là mở rộng: kết nối các phương tiện thực thi khác nhau của cloud·container·trung tâm dữ liệu·OT bằng mô hình chính sách và hệ thống log chung.

Giai đoạn 6 là tối ưu hóa: nội hóa vào vận hành việc cô lập tự động theo tín hiệu rủi ro, hết hạn chính sách, giảm ngoại lệ, kiểm chứng đường tấn công.

Mức trưởng thành không được đo đơn thuần bằng số lượng phân đoạn.

Phải xem xét đồng thời tỷ lệ bảo vệ tài sản quan trọng, mức giảm luồng chưa phân loại, mức giảm ngoại lệ vĩnh viễn, tỷ lệ thất bại khi thay đổi chính sách, số tài nguyên có thể truy cập khi bị xâm nhập và thời gian cô lập.

Có thể dùng đề xuất chính sách dựa trên AI, nhưng nếu kết quả đề xuất trở thành chính sách cho phép ngay thì có nguy cơ tự động phê duyệt luồng sai hoặc giao tiếp của kẻ tấn công.

AI nên được dùng làm công cụ hỗ trợ phân cụm luồng và phát hiện chính sách trùng lặp, còn tài nguyên rủi ro cao và chính sách ngoại lệ phải được con người rà soát căn cứ rồi mới phê duyệt.

7. Những điểm cần cân nhắc và hàm ý

A. Cân bằng giữa liên tục nghiệp vụ và bảo mật

Microsegmentation tăng cường bảo mật nhưng việc chặn sai sẽ lập tức trở thành sự cố nghiệp vụ.

Không chặn toàn diện ngay từ đầu mà tuân thủ các bước quan sát·mô phỏng·thực thi một phần·mở rộng, đồng thời kiểm chứng trước đường failover và thủ tục gỡ bỏ khẩn cấp.

B. Nhận diện tài sản và chất lượng chính sách

Nếu danh mục tài sản không chính xác hoặc chưa xác định chủ sở hữu thì tiêu chí của chính sách cũng bị lung lay.

Cần tự động hóa việc liên kết định danh của CMDB, kiểm kê cloud, container orchestrator, IdP, và hủy chính sách cùng lúc khi tài sản kết thúc vòng đời.

C. Ngoại lệ chính sách và nợ bảo mật

Nếu các ngoại lệ tạo ra với lý do ứng phó sự cố khẩn cấp không hết hạn thì microsegmentation chỉ còn là cái tên.

Ngoại lệ phải ghi lý do·người phê duyệt·phạm vi ảnh hưởng·ngày hết hạn·kiểm soát thay thế, và áp dụng nguyên tắc tự động xóa nếu không được phê duyệt lại trước khi hết hạn.

D. Mã hóa và khả năng hiển thị

TLS và mTLS có lợi cho tính bí mật và xác minh danh tính, nhưng có thể khiến hệ thống quan sát khó hiểu đầy đủ luồng nghiệp vụ.

Thay vì mở rộng giải mã vô điều kiện, cần kết hợp metadata, log dịch vụ, truy vết phân tán (distributed tracing), chứng chỉ·danh tính dịch vụ, telemetry endpoint để bảo đảm khả năng hiển thị cần thiết.

E. Hiệu năng và khả năng mở rộng

Truy vấn chính sách và kiểm tra gói tin có thể làm tăng độ trễ trên đường yêu cầu, nên phải kiểm thử hiệu năng cache·cấu trúc phân phối chính sách·dung lượng điểm thực thi·hành vi khi sự cố.

Số proxy của service mesh, mức sử dụng CPU·bộ nhớ của agent, khối lượng log và chi phí lưu trữ cũng được quản lý như yêu cầu phi chức năng của toàn bộ thiết kế.

F. Tính thực tế với legacy·OT·IoT

Giả định rằng có thể áp dụng agent mới nhất hoặc xác thực mạnh cho mọi thiết bị là khác với thực tế.

Với thiết bị hỗ trợ hạn chế, áp dụng các kiểm soát bù trừ như cô lập dựa trên mạng, vá ảo (virtual patch), jump server, phát hiện thụ động, và báo cáo kế hoạch thay thế cùng rủi ro tồn dư cho ban lãnh đạo.

G. Đo lường hiệu quả và cải tiến liên tục

Số phân đoạn hay số quy tắc chặn nhiều không có nghĩa là mức trưởng thành bảo mật cao.

Phải xác nhận di chuyển ngang có thực sự bị chặn thông qua kiểm chứng đường tấn công giả định kịch bản xâm nhập và diễn tập purple team, đồng thời tự động hóa phân tích tác động chính sách khi thay đổi dịch vụ.

Tài liệu tham khảo

• NIST, “Zero Trust Architecture, SP 800-207”: https://csrc.nist.gov/pubs/sp/800/207/final
• NIST NCCoE, “Implementing a Zero Trust Architecture, SP 1800-35”: https://www.nist.gov/news-events/news/2025/06/nist-releases-cybersecurity-practice-guide-implementing-zero-trust
• CISA, “Microsegmentation in Zero Trust, Part One: Introduction and Planning”: https://www.cisa.gov/resources-tools/resources/microsegmentation-zero-trust-part-one-introduction-and-planning
• CISA, “Zero Trust Maturity Model Version 2.0”: https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model

---

Tóm tắt một câu: Microsegmentation là phương tiện triển khai Zero Trust chia tài sản và luồng nghiệp vụ thành các ranh giới logic nhỏ, thực thi chính sách đặc quyền tối thiểu·từ chối mặc định trên lưu lượng đông-tây, qua đó giảm di chuyển ngang và bán kính ảnh hưởng của thiệt hại sau khi bị xâm nhập.