ZTNA (Zero Trust Network Access, truy cập mạng Zero Trust)

1. Tổng quan

ZTNA (Zero Trust Network Access) là kiến trúc kiểm soát truy cập không tin cậy vị trí mạng của người dùng hay việc đã kết nối vào mạng nội bộ, mà mỗi lần đều xác minh người dùng, thiết bị, ứng dụng và ngữ cảnh yêu cầu rồi chỉ kết nối tới những ứng dụng cần thiết với đặc quyền tối thiểu.

Truy cập từ xa truyền thống là cách dùng VPN đưa người dùng vào một phân đoạn nhất định của mạng doanh nghiệp, rồi để họ tự tìm máy chủ cần thiết bên trong.

Mô hình này dễ vận hành vào thời kỳ trung tâm dữ liệu và mạng trụ sở chính là trung tâm của hệ thống thông tin.

Tuy nhiên, khi SaaS, đa đám mây (multi-cloud), làm việc tại nhà và truy cập của đối tác lan rộng, đối tượng cần bảo vệ không còn chỉ tồn tại bên trong mạng.

Một hạn chế quan trọng nữa là nếu kẻ tấn công vào VPN bằng tài khoản đánh cắp, chỉ vì đó là kết nối đã xác thực mà họ có thể dò quét tài nguyên nội bộ hoặc thử di chuyển ngang (lateral movement).

NIST SP 800-207 đưa ra nguyên tắc Zero Trust: không trao niềm tin ngầm định cho người dùng hay tài sản chỉ dựa trên vị trí mạng, mà phải xác thực và phân quyền chủ thể cùng thiết bị trước khi truy cập tài nguyên (NIST SP 800-207).

ZTNA là phương tiện tiêu biểu cụ thể hóa nguyên tắc này vào đường truy cập từ xa và truy cập ứng dụng.

Tuy nhiên, không nên hiểu ZTNA chỉ là tên mới của sản phẩm VPN.

VPN có xu hướng tạo kết nối mạng trước rồi kiểm soát truy cập trên đó, còn ZTNA định nghĩa trước ứng dụng cần bảo vệ và tạo kết nối theo từng yêu cầu.

Do đó, mục tiêu của ZTNA không phải là loại bỏ hoàn toàn mạng, mà là hạ vai trò của mạng từ căn cứ tin cậy xuống phương tiện truyền dẫn, và chuyển các quyết định bảo mật sang trọng tâm ứng dụng, dữ liệu và danh tính.

2. Nguyên tắc và cấu trúc khái niệm của ZTNA

Cốt lõi của ZTNA không phải là xác thực đơn lẻ chỉ kiểm tra “là ai”, mà là đánh giá tổng hợp “chủ thể nào, ở trạng thái nào, muốn thực hiện hành vi nào trên tài nguyên nào”.

Dù người dùng đã xác thực thành công, nếu kết hợp với thiết bị không được quản lý, vị trí bất thường, hành vi nguy hiểm hay yêu cầu ngoài giờ làm việc thì có thể hạn chế truy cập hoặc yêu cầu xác thực bổ sung.

Ngược lại, nếu cùng người dùng đó yêu cầu ứng dụng đã được phê duyệt từ thiết bị đã được phê duyệt trong ngữ cảnh công việc bình thường thì có thể cho phép truy cập trong phạm vi cần thiết.

Sơ đồ khái niệm sau thể hiện toàn bộ luồng yêu cầu truy cập đi qua điểm quyết định và điểm thực thi chính sách.

graph LR
    U[Chủ thể người dùng·dịch vụ] --> R[Yêu cầu truy cập]
    D[Nhận dạng thiết bị·trạng thái bảo mật] --> PIP[Nguồn cung cấp thông tin chính sách]
    I[IdP·MFA·nhóm] --> PIP
    C[Vị trí·thời gian·hành vi·tín hiệu mối đe dọa] --> PIP
    R --> PDP[Điểm quyết định chính sách PDP]
    PIP --> PDP
    PDP -->|Cho phép·cho phép có điều kiện·từ chối| PEP[Điểm thực thi chính sách PEP]
    PEP -->|Kết nối theo đơn vị ứng dụng| APP[Ứng dụng được bảo vệ]
    PEP --> LOG[Nhật ký kiểm toán·telemetry]
    LOG --> ANA[Phân tích·đánh giá rủi ro]
    ANA -.Hiệu chỉnh chính sách.-> PDP

A. Xác minh danh tính và chủ thể

Trong ZTNA, chủ thể không chỉ có nghĩa là người dùng là con người.

Mọi tác nhân yêu cầu truy cập tài nguyên như con người, tài khoản dịch vụ, tác vụ batch, thiết bị IoT đều được coi là chủ thể.

Danh tính người dùng được xác nhận qua IdP doanh nghiệp, thư mục, SSO, MFA, còn danh tính dịch vụ được xác nhận qua chứng chỉ workload hoặc token tài khoản dịch vụ.

Xác thực và phân quyền phải được tách biệt.

Xác thực là thủ tục xác nhận “là ai”, còn phân quyền là thủ tục quyết định bằng chính sách “được làm gì”.

Ví dụ, người dùng phòng nhân sự đã được xác thực không có nghĩa là có quyền quản trị trên mọi cơ sở dữ liệu nhân sự.

Phải kết hợp chức vụ, dự án, cấp độ dữ liệu, trạng thái phê duyệt để cấp riêng quyền đọc, sửa, xuất dữ liệu.

MFA giảm rủi ro chiếm đoạt tài khoản nhưng tự nó không hoàn thiện ZTNA.

Ngay cả phiên đã vượt qua MFA, nếu thiết bị bị nhiễm mã độc hoặc hành vi người dùng khác thường thì vẫn cần xác minh bổ sung.

Vì vậy, ZTNA coi kết quả xác thực của IdP là một trong nhiều đầu vào của policy engine.

B. Đánh giá trạng thái thiết bị và ngữ cảnh

Xác minh thiết bị là quá trình vượt ra ngoài mức kiểm tra loại hệ điều hành/trình duyệt, để đánh giá thiết bị đó có do tổ chức quản lý và có đáp ứng tiêu chuẩn bảo mật hay không.

Ví dụ, có thể dùng làm tín hiệu việc mã hóa ổ đĩa, mức bản vá bảo mật, EDR có đang chạy, chính sách khóa màn hình, có bị jailbreak/root, có sở hữu chứng chỉ hay không.

Trạng thái thiết bị không phải thuộc tính vĩnh viễn mà là giá trị quan sát thay đổi theo thời gian.

Chiếc laptop hôm qua được đánh giá bình thường, nếu hôm nay EDR bị dừng hoặc phát hiện tiến trình nguy hiểm thì không được giữ nguyên quyền hạn như cũ.

Vì lý do này, chính sách được thiết kế theo cách đánh giá lại theo chu kỳ hoặc khi phát sinh tín hiệu rủi ro, thay vì quy tắc tĩnh “đã cho phép một lần thì duy trì vô điều kiện đến hết phiên”.

Ngoài người dùng và thiết bị, ngữ cảnh có thể bao gồm vị trí, thời gian truy cập, loại mạng, ứng dụng được yêu cầu, phân loại dữ liệu đích, hành vi trước đó và thông tin tình báo mối đe dọa (threat intelligence).

Tuy nhiên, thu thập nhiều tín hiệu không tự động làm chất lượng phán định tốt lên.

Thông tin vị trí độ chính xác thấp hay phân tích hành vi quá mức có thể làm tăng cảnh báo sai và xâm phạm quyền riêng tư, nên phải áp dụng đồng thời mục đích nghiệp vụ và nguyên tắc thu thập tối thiểu.

C. Đặc quyền tối thiểu và kết nối theo đơn vị ứng dụng

ZTNA không kết nối người dùng tới “toàn bộ mạng nội bộ”, mà giới hạn kết nối trong tên, địa chỉ, cổng và phạm vi hành vi của ứng dụng đã được phê duyệt.

Người dùng chọn hệ thống quản lý đơn hàng trên cổng thông tin, hoặc truy cập ứng dụng web được phép qua proxy dựa trên trình duyệt.

Từ góc độ mạng, ứng dụng không được công khai trực tiếp cho người dùng, mà connector hoặc broker trung chuyển kết nối hai phía.

Cấu trúc này không để lộ địa chỉ IP nội bộ và danh sách dịch vụ không cần thiết cho người dùng, qua đó thu hẹp phạm vi trinh sát của kẻ tấn công.

Đặc quyền tối thiểu không dừng lại ở việc thu gọn danh sách ứng dụng.

Ngay trong cùng một ứng dụng, có thể tách tra cứu, đăng ký, phê duyệt, tải xuống, và gắn xác thực lại hoặc phê duyệt của quản trị viên cho các hành vi rủi ro cao.

Ví dụ, màn hình thông tin khách hàng cho phép tra cứu nhưng chặn tải xuống hàng loạt, hoặc chỉ người phụ trách phê duyệt mới được gọi API phê duyệt thanh toán.

Nếu đặt đặc quyền tối thiểu quá hẹp sẽ gây gián đoạn công việc và truy cập vòng tránh, nên phải phân tích luồng công việc thực tế để chi tiết hóa quyền.

3. Thành phần và quy trình hoạt động

Hiện thực ZTNA không phải một thiết bị đơn lẻ mà là cấu trúc logic kết hợp danh tính, chính sách, trung chuyển kết nối, bảo vệ tài nguyên và hệ thống quan sát.

Luồng chi tiết sau cho thấy từ lúc người dùng truy cập ứng dụng đến khi kết thúc phiên và kiểm toán.

sequenceDiagram
    participant U as Người dùng/thiết bị
    participant B as Broker hoặc cổng truy cập
    participant I as IdP·MFA
    participant E as Policy engine
    participant C as Connector/PEP
    participant A as Ứng dụng nội bộ
    participant O as Hệ thống log·phân tích
    U->>B: Yêu cầu truy cập ứng dụng
    B->>I: Yêu cầu xác thực người dùng·MFA
    I-->>B: Kết quả xác thực·nhóm·tín hiệu rủi ro
    B->>E: Truy vấn người dùng·thiết bị·ngữ cảnh
    E-->>B: Cho phép·cho phép có điều kiện·từ chối
    B->>C: Tạo kết nối tới tài nguyên đã phê duyệt
    C->>A: Kết nối ứng dụng nội bộ
    A-->>U: Phản hồi trong phạm vi cho phép
    C->>O: Ghi phiên·chính sách·lỗi·hành vi
    E->>O: Ghi căn cứ quyết định chính sách
    O-->>E: Tín hiệu rủi ro·yêu cầu đánh giá lại phiên
    E-->>C: Duy trì·thu hẹp·chấm dứt quyền

A. Đ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, Policy Decision Point) là vai trò logic tính toán việc có cho phép truy cập hay không.

Điểm thực thi chính sách (PEP, Policy Enforcement Point) là vai trò cưỡng chế quyết định của PDP trên đường truyền thông thực tế.

Trong mô hình trừu tượng của NIST, policy engine (PE) và policy administrator (PA) cấu thành chức năng quyết định chính sách, còn PEP kiểm soát kết nối giữa chủ thể yêu cầu và tài nguyên (NIST Zero Trust Architecture).

Tùy sản phẩm, PDP, PE, PA có thể trông như một dịch vụ đám mây duy nhất, hoặc được bố trí phân tán vào broker, gateway, agent.

Điều quan trọng không phải là tên gọi mà là cấu trúc tách biệt quyết định và thực thi để chính sách không bị vượt qua.

Nếu PDP trả về cho phép nhưng lưu lượng thực tế có thể đi đường khác tới thẳng máy chủ nội bộ thì kiểm soát của ZTNA bị vô hiệu hóa.

PEP có thể được hiện thực bằng agent trên thiết bị người dùng, reverse proxy, gateway ứng dụng, proxy của service mesh, chính sách tường lửa…

Điểm thực thi phải gần tài nguyên được bảo vệ, và phải xác định rõ tính sẵn sàng cao cũng như chính sách từ chối mặc định (default deny) hoặc cho phép có giới hạn (fail safe) khi sự cố.

B. Liên kết IdP, MFA và quản lý thiết bị

IdP cung cấp xác thực người dùng và thông tin nhóm/vai trò, nhưng không được trở thành nguồn sự thật duy nhất của chính sách ZTNA.

Hệ thống quản lý thiết bị cung cấp định danh thiết bị và trạng thái tuân thủ, EDR cung cấp trạng thái phát hiện mối đe dọa, còn SIEM và threat intelligence cung cấp tín hiệu rủi ro.

Policy engine thu thập các thông tin này để đánh giá mức độ rủi ro của yêu cầu.

Ví dụ, điều kiện “là người dùng tài chính, đã qua MFA, truy cập trong giờ làm việc từ laptop được mã hóa do công ty quản lý” có thể cho phép quyền đọc.

Ngược lại, nếu “cùng người dùng đó nhưng EDR bị dừng và thử tải xuống hàng loạt từ vị trí bất thường ở nước ngoài” thì có thể chặn phiên hoặc chuyển sang phê duyệt của quản trị viên.

Chênh lệch thời gian và định danh không khớp giữa các hệ thống liên kết thường xảy ra trong vận hành thực tế.

Nếu ID người dùng, mã nhân viên, email, ID thiết bị khác nhau giữa các hệ thống, chính sách có thể áp dụng sai chủ thể, nên cần chuẩn hóa định danh và giám sát lỗi đồng bộ.

C. Broker, connector và bảo vệ ứng dụng

Broker ZTNA đảm nhận xác thực, chính sách và trung chuyển phiên giữa người dùng và ứng dụng được bảo vệ.

Connector được đặt trong mạng nội bộ, không mở cổng inbound ra bên ngoài mà tạo kết nối outbound tới ứng dụng đã được phê duyệt.

Cách này giảm rủi ro phơi bày trực tiếp ứng dụng nội bộ ra Internet và đơn giản hóa chính sách tường lửa.

Ứng dụng web có thể được bảo vệ theo kiểu reverse proxy, còn các giao thức phi web như SSH, RDP, cơ sở dữ liệu có thể cần connector chuyên dụng hoặc agent.

Kiểu agent cho phép nhận dạng thiết bị và kiểm soát mạng chi tiết, nhưng khó cài đặt trên thiết bị không được quản lý hoặc thiết bị của đối tác.

Kiểu agentless dễ truy cập chỉ bằng trình duyệt, nhưng khả năng kiểm soát các chức năng như truyền tệp, clipboard, máy in cục bộ có thể bị hạn chế.

Do đó, kết hợp các phương thức theo giao thức của ứng dụng, loại người dùng và độ nhạy cảm của dữ liệu.

Nếu connector có thể truy cập quá mức vào mọi mạng nội bộ, ZTNA có thể trở thành một đường di chuyển ngang mới.

Cần tối thiểu hóa tài nguyên đích, quyền thực thi, phân đoạn mạng, đường cập nhật của từng connector và giám sát chính connector như một tài sản.

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

A. Các loại áp dụng

Thứ nhất là loại đặt proxy ứng dụng giữa người dùng từ xa và ứng dụng web nội bộ.

Proxy nhận yêu cầu từ trình duyệt, kiểm tra xác thực và chính sách, rồi chỉ chuyển các yêu cầu đã được phê duyệt tới backend.

Thứ hai là loại dùng agent trên thiết bị và broker đám mây để kết nối cả giao thức phi web.

Người dùng trông như đang kết nối tới ứng dụng qua địa chỉ mạng ảo, nhưng agent chỉ cho đi qua các host và cổng đã được phê duyệt.

Thứ ba là loại áp dụng danh tính workload cho truy cập giữa máy chủ và dịch vụ.

Khi một microservice gọi API của dịch vụ khác, chứng chỉ dịch vụ, namespace, thông tin triển khai và phạm vi yêu cầu được dùng làm đầu vào chính sách.

Thứ tư là loại cung cấp truy cập tạm thời cho đối tác, nhân lực thuê ngoài và thiết bị không được quản lý.

Trong trường hợp này, chính sách phải bao gồm thời hạn hiệu lực tài khoản, thời gian truy cập, ghi hình màn hình, di chuyển tệp, người phê duyệt và thu hồi tự động khi kết thúc hợp đồng.

B. So sánh VPN, ZTNA và SASE

Phân loại	VPN truyền thống	ZTNA	ZTNA theo góc nhìn SASE
Đối tượng cơ bản	Phân đoạn mạng	Ứng dụng·tài nguyên	Ứng dụng·dịch vụ tại biên đám mây
Căn cứ tin cậy	Vị trí mạng sau xác thực	Chính sách danh tính·thiết bị·ngữ cảnh·tài nguyên	Danh tính·ngữ cảnh và chính sách bảo mật tích hợp
Phạm vi kết nối	Mạng tương đối rộng	Tài nguyên·phiên được phép	Kết hợp đường tối ưu và chức năng bảo mật tại biên
Di chuyển ngang	Khả năng phơi bày tương đối lớn	Thu hẹp theo đơn vị ứng dụng	Kiểm soát cùng SSE·DLP·SWG
Trọng tâm vận hành	Đường hầm·địa chỉ·tường lửa	Chính sách·danh tính·trạng thái thiết bị	Tích hợp dịch vụ mạng·bảo mật
Hạn chế chính	Vấn đề tin cậy nội bộ và khả năng mở rộng	Độ phức tạp chính sách·liên kết, tương thích legacy	Phụ thuộc đám mây·nhà cung cấp·chủ quyền dữ liệu

Khác biệt giữa VPN và ZTNA không chỉ được quyết định bởi việc có mã hóa đường hầm hay không.

VPN hiện đại cũng có thể hỗ trợ MFA và chính sách phân đoạn, nên khẳng định “VPN luôn không an toàn” là không chính xác.

Khác biệt cốt lõi nằm ở việc đưa người dùng vào mạng hay chỉ trung chuyển một phiên cụ thể tới tài nguyên được bảo vệ.

ZTNA không hoàn thiện bảo mật chỉ bằng việc ẩn địa chỉ mạng, mà chỉ phát huy hiệu quả khi xác thực, phân quyền, tuân thủ của thiết bị, log và vận hành chính sách cùng trưởng thành.

SASE là kiến trúc dịch vụ kết hợp ZTNA với SWG, CASB, FWaaS, DLP, SD-WAN…

Vì vậy, ZTNA có thể được triển khai như một chức năng của SASE, hoặc được triển khai trước như một hệ thống truy cập ứng dụng độc lập cho trung tâm dữ liệu nội bộ.

C. Lựa chọn giữa RBAC và ABAC

Kiểm soát truy cập dựa trên vai trò (RBAC) ánh xạ chức vụ hoặc vai trò tổ chức vào quyền, nên dễ hiểu và quản lý đơn giản.

Tuy nhiên, để biểu diễn các thuộc tính biến đổi như làm việc từ xa, tổ chức theo dự án, đối tác, mức rủi ro thiết bị thì số vai trò có thể tăng quá nhiều.

Kiểm soát truy cập dựa trên thuộc tính (ABAC) kết hợp thuộc tính của người dùng, tài nguyên và môi trường để biểu diễn điều kiện chi tiết.

Ví dụ, có thể đánh giá đồng thời phòng ban người dùng=tài chính, tuân thủ thiết bị=bình thường, cấp độ dữ liệu=nội bộ, vị trí=quốc gia được phép, hành vi=tra cứu.

ABAC chi tiết nhưng phụ thuộc vào chất lượng thuộc tính và khả năng giải thích chính sách.

Tổ chức có thể cân nhắc cách lai: quản lý vai trò công việc cơ bản bằng RBAC, và bổ sung các điều kiện động như trạng thái thiết bị, thời gian, mức rủi ro, cấp độ dữ liệu bằng ABAC.

Nếu không quản lý phiên bản và kiểm thử chính sách như mã nguồn, điều kiện càng tăng thì xung đột và ngoại lệ càng tích tụ.

5. Quy trình triển khai và tình huống giả định

A. Quy trình triển khai theo từng bước

Bước 1 là xác định đối tượng cần bảo vệ và luồng công việc.

Lập danh mục ứng dụng, phòng ban sở hữu, cấp độ dữ liệu, người dùng truy cập, giao thức và các dịch vụ phụ thuộc.

Bước 2 là chuẩn hóa nền tảng danh tính và thiết bị.

Loại bỏ tài khoản dùng chung, liên kết định danh của IdP, MFA, quản lý thiết bị, EDR, và phân loại các tài sản không được quản lý.

Bước 3 là áp dụng chính sách ở chế độ quan sát cho các ứng dụng rủi ro thấp.

Ở chế độ quan sát, thu thập mẫu truy cập thực tế và các phụ thuộc không lường trước để hiệu chỉnh danh sách cho phép.

Bước 4 là chuyển đổi bắt đầu từ các nghiệp vụ dùng VPN nhiều và có ranh giới ứng dụng rõ ràng.

Ví dụ, các đối tượng dễ kiểm chứng theo đơn vị ứng dụng như intranet, dashboard phát triển, cổng thông tin đối tác là phù hợp.

Bước 5 là áp dụng chính sách tăng cường cho dữ liệu rủi ro cao và truy cập quản trị.

Với shell quản trị, cơ sở dữ liệu production, tải xuống hàng loạt, xem xét phê duyệt riêng, phiên ngắn, kiểm soát lệnh và ghi lại phiên.

Bước 6 là đo lường liên tục và cải tiến chính sách.

So sánh với đường cơ sở các chỉ số như tỷ lệ truy cập thành công, tỷ lệ xác thực thất bại, số phiên rủi ro bị chặn, số ngoại lệ chính sách, sự cố ứng dụng, thời gian trung bình thu hồi quyền.

B. Tình huống giả định: Truy cập từ xa của đối tác doanh nghiệp sản xuất

Doanh nghiệp sản xuất giả định A đang cấp tài khoản VPN cho nhân viên đối tác và mở nhiều cổng của máy chủ quản lý sản xuất.

Có các vấn đề như tài khoản hết hợp đồng không được thu hồi ngay, hoặc khó kiểm tra trạng thái bảo mật của thiết bị đối tác.

Trước hết, A xác định cổng web quản lý sản xuất là đối tượng bảo vệ, và đăng ký đối tác, xưởng làm việc, thời hạn công việc làm thuộc tính tài khoản.

Chính sách được áp dụng để nhân viên đối tác thực hiện MFA trên IdP và chỉ truy cập cổng từ trình duyệt đã được phê duyệt.

Khi hết thời hạn công việc, tài khoản tự động bị vô hiệu hóa, và màn hình quản trị ngoài phạm vi công việc không hiển thị nếu không có phê duyệt riêng.

Truy cập chẩn đoán thiết bị theo phương thức phi web được giới hạn tới host và cổng cụ thể qua connector chuyên dụng.

Chính sách chỉ cho phép khi thỏa mãn đồng thời trạng thái hợp đồng=hiệu lực, vai trò người làm việc=chẩn đoán, mức rủi ro thiết bị=cho phép, thời gian truy cập=ca làm việc đã phê duyệt.

Tải xuống tệp hàng loạt và thực thi lệnh bất thường bị chặn, và mọi phiên đều lưu thông tin người làm việc, thiết bị, tài nguyên, người phê duyệt.

Thành quả cốt lõi của tình huống này không phải là việc đã thay thiết bị VPN, mà là đã áp dụng đặc quyền tối thiểu theo đơn vị tài nguyên, giới hạn thời hạn và bằng chứng kiểm toán ngay cả cho chủ thể nằm ngoài mạng là đối tác.

6. Chuyên sâu — ZTNA cloud-native và mức độ trưởng thành

Trong môi trường cloud-native, không chỉ người dùng mà cả dịch vụ và workload cũng gọi API của nhau.

NIST SP 800-207A mô tả mô hình áp dụng đồng thời chính sách tầng mạng và chính sách tầng danh tính cho ứng dụng cloud-native đa đám mây, đa vị trí, và tận dụng API gateway, sidecar proxy, hạ tầng danh tính dịch vụ (NIST SP 800-207A).

Từ góc nhìn này, ZTNA vượt ra ngoài vai trò thay thế VPN cho người dùng từ xa, mở rộng thành hệ thống chính sách hợp nhất truy cập người dùng–ứng dụng, dịch vụ–dịch vụ và người vận hành–mặt quản trị.

mTLS của service mesh có thể cung cấp mã hóa giao tiếp giữa dịch vụ và xác thực workload, nhưng không tự động giải quyết chính sách quyền nghiệp vụ và hành vi trên dữ liệu.

Vì vậy, phải tách biệt và liên kết việc cho phép kết nối ở tầng mạng, quyền API ở tầng ứng dụng, và kiểm soát tra cứu/xuất dữ liệu ở tầng dữ liệu.

CISA Zero Trust Maturity Model 2.0 đưa ra năm trụ cột Identity, Devices, Networks, Applications and Workloads, Data cùng các năng lực xuyên suốt Visibility and Analytics, Automation and Orchestration, Governance (CISA Zero Trust Maturity Model).

Thay vì đưa mọi hạng mục lên mức tối ưu cùng lúc, tổ chức nên bắt đầu từ nhận dạng tài sản và bảo đảm khả năng quan sát, rồi trưởng thành dần tới tự động hóa, chính sách động và quản trị.

Trong các hiện thực mới nhất, truy cập agentless, cô lập trình duyệt (browser isolation), đánh giá rủi ro liên tục, danh tính dịch vụ và tự động hóa phân tích bảo mật có thể được kết hợp.

Tuy nhiên, sản phẩm có nhiều chức năng không có nghĩa là mức trưởng thành cao.

Phải kiểm chứng chính sách có thực sự được thực thi ngay trước tài nguyên hay không, ngoại lệ có được truy vết không, lỗi tín hiệu có làm tê liệt công việc không, và khi sự cố có khôi phục an toàn không.

7. Các điểm cần cân nhắc và hàm ý

Ưu tiên bề mặt cần bảo vệ: Thay vì bao bọc mọi tài nguyên bằng ZTNA cùng lúc, hãy xác định trước các bề mặt bảo vệ có tác động xâm phạm lớn như dữ liệu cá nhân, sở hữu trí tuệ, mặt quản trị, API nghiệp vụ cốt lõi.
Chất lượng chính sách và khả năng giải thích: Người vận hành phải giải thích được lý do truy cập bị từ chối và căn cứ được cho phép. Quản lý xung đột chính sách, ngoại lệ, ngày hết hạn, người phê duyệt bằng phiên bản và nhật ký kiểm toán.
Tính sẵn sàng và ứng phó sự cố: IdP, broker, connector, DNS, chứng chỉ đều có thể trở thành phụ thuộc của đường truy cập. Kiểm thử trước dự phòng kép, phạm vi cho phép của cache, tài khoản khẩn cấp và thủ tục khôi phục có giới hạn khi sự cố.
Tương thích legacy: Client cũ, thiết bị yêu cầu IP cố định, giao thức phi chuẩn khó được bảo vệ chỉ bằng proxy ứng dụng. Vận hành song song bảo mật phân đoạn và connector chuyên dụng trong giai đoạn chuyển tiếp, và lập kế hoạch hiện đại hóa dài hạn.
Thiết bị và chủ thể phi con người: Nếu chỉ tăng cường MFA cho người dùng mà bỏ mặc tài khoản dịch vụ, API key, token tự động hóa thì vẫn còn đường vòng. Quản lý đồng thời việc cấp phát, xoay vòng, thu hồi và phạm vi gọi của danh tính phi con người.
Dữ liệu cá nhân và giám sát: Thu thập vị trí, hành vi, trạng thái thiết bị hữu ích cho bảo mật nhưng giám sát quá mức có thể gây phản kháng về pháp lý và tổ chức. Rà soát mục đích thu thập, thời hạn lưu trữ, quyền truy cập, che dữ liệu, yêu cầu thông báo và đồng ý.
Đo lường hiệu quả: Thay vì số lượng triển khai, đánh giá đồng thời tỷ lệ ứng dụng được bảo vệ, tỷ lệ chặn thiết bị không được quản lý, mức giảm đặc quyền dư thừa, thời gian đánh giá lại rủi ro phiên, phạm vi di chuyển ngang trong sự cố xâm phạm và độ trễ công việc.
Tổ chức và vận hành: Nếu đội mạng chỉ quản lý đường hầm còn đội bảo mật chỉ quản lý chính sách thì sẽ có khoảng trống trách nhiệm. Xác định RACI cho thay đổi chính sách và ứng phó sự cố với sự tham gia của chủ sở hữu ứng dụng, IAM, endpoint, mạng và SOC.
Phụ thuộc nhà cung cấp và chủ quyền dữ liệu: Xác nhận trong hợp đồng và kiểm chứng kỹ thuật về region của broker đám mây, vị trí lưu log, đường thay thế khi dịch vụ gián đoạn, hỗ trợ giao thức chuẩn và khả năng xuất chính sách.

Từ góc nhìn Kỹ sư chuyên nghiệp (Professional Engineer), ZTNA không phải vấn đề triển khai sản phẩm mà là “mô hình vận hành chuyển niềm tin từ vị trí mạng sang tài nguyên, danh tính, ngữ cảnh và bằng chứng”.

Do đó, khi thiết kế kiến trúc, không chỉ nhấn mạnh tính bảo mật mà phải tối ưu hóa đồng thời tính liên tục của công việc, trải nghiệm người dùng, tuân thủ quy định, tự động hóa vận hành và tổng chi phí sở hữu.

Tài liệu tham khảo

Tóm tắt một câu: ZTNA là kiến trúc truy cập thay vì tin vào vị trí mạng và mở mạng nội bộ, sẽ xác minh người dùng, thiết bị, ngữ cảnh và tài nguyên ở mỗi yêu cầu để thực thi đặc quyền tối thiểu theo đơn vị ứng dụng, và để thành công phải cùng làm trưởng thành danh tính, chính sách, connector, khả năng quan sát và quản trị.