Zero Trust Network Access (ZTNA) trên FortiGate — Cấu hình Access Proxy chi tiết

1. Liên hệ thực tế

Công ty của anh Nam vừa chuyển sang mô hình làm việc hybrid: một nửa nhân viên ngồi văn phòng, một nửa làm việc từ nhà hoặc quán cà phê. Trước đây, ai cần truy cập server nội bộ (RDP vào máy chủ kế toán, SSH vào server backup) đều phải bật SSL-VPN, xin cấp tài khoản VPN, rồi khi vào trong mạng thì gần như "muốn đi đâu cũng được" — vì VPN chỉ kiểm tra một lần lúc đăng nhập.

Sau một sự cố nhỏ — laptop của một bạn sale bị dính mã độc, và vì bạn ấy đang bật VPN nên máy độc hại đó có thể quét được cả dải mạng nội bộ — chị Lan quyết định ngồi lại với anh Nam để thiết kế lại cách truy cập từ xa.

"Anh Nam thấy vấn đề ở đâu không?" chị Lan hỏi.

"Dạ, chắc là do VPN cho vào rồi thì tin luôn, không kiểm tra lại." anh Nam trả lời.

"Đúng vậy. VPN truyền thống là mô hình 'trust once, access everything' — xác thực một lần, sau đó gần như tin tưởng toàn bộ traffic từ IP đó. Đó là lý do FortiOS 7.0 trở về sau tích hợp Zero Trust Network Access (ZTNA) ngay trong FortiGate, không cần thêm thiết bị. Nguyên tắc ở đây là 'never trust, always verify' — mỗi lần user muốn chạm vào một ứng dụng cụ thể, FortiGate sẽ xác minh lại danh tính người dùng, tình trạng thiết bị, và ngữ cảnh truy cập, chứ không cấp quyền tràn lan vào cả mạng."

Bài này chúng ta sẽ tìm hiểu ZTNA hoạt động ra sao trên FortiGate, phân biệt các loại triển khai, và cách cấu hình cơ bản.

2. Kiến thức cốt lõi

2.1 ZTNA khác VPN truyền thống ở điểm nào

⚠️ Lưu ý: ZTNA trên FortiGate không thay thế hoàn toàn VPN trong mọi trường hợp — với các nhu cầu truy cập broadcast/multicast nội bộ hoặc ứng dụng legacy cần IP thật trong subnet, VPN (đã trình bày ở Site-to-Site IPSec VPN và SSL-VPN Tunnel/Web mode) vẫn còn phù hợp. ZTNA mạnh nhất cho truy cập ứng dụng cụ thể theo mô hình publish từng dịch vụ.

2.2 Hai thành phần bắt buộc: FortiGate Access Proxy và FortiClient EMS

ZTNA trên FortiGate hoạt động theo mô hình access proxy (reverse proxy): FortiGate đóng vai trò cổng trung gian, nhận kết nối HTTPS từ client, xác thực, rồi mới forward traffic thật tới server phía sau. Client không bao giờ kết nối trực tiếp tới server nội bộ.

Hai thành phần chính:

• FortiGate ZTNA Access Proxy: định nghĩa một VIP (external IP + port) mà client kết nối vào, cùng ánh xạ service/server mapping tới địa chỉ thật của server nội bộ.
• FortiClient EMS (Enterprise Management Server): đóng vai trò CA (Certificate Authority) cấp client certificate cho từng thiết bị, đồng thời liên tục chấm điểm tình trạng bảo mật thiết bị (security posture) — ví dụ máy có bật antivirus không, có phát hiện file độc hại không, hệ điều hành có patch đầy đủ không — rồi gắn Security Posture Tag (trước đây gọi là ZTNA Tag) cho thiết bị đó. FortiGate đồng bộ các tag này qua Fabric Connector và dùng chúng làm điều kiện trong policy.

Nói cách khác: EMS trả lời câu hỏi "thiết bị này có đáng tin không", còn FortiGate trả lời câu hỏi "với mức độ tin cậy đó, được phép chạm vào server nào".

Sơ đồ dưới đây minh họa toàn bộ luồng xử lý:

2.3 Hai chế độ truy cập: Full ZTNA (Access Proxy) và IP/MAC Filtering

Fortinet cung cấp 2 cách áp dụng ZTNA, dễ gây nhầm lẫn vì đều dùng chung khái niệm "ZTNA tag":

Full ZTNA (Access Proxy) — đúng nghĩa Zero Trust: client kết nối HTTPS tới access proxy VIP trên FortiGate, không cần biết IP thật của server. FortiGate làm reverse proxy, xác thực certificate, đối chiếu posture tag, rồi mới forward traffic. Có 2 dạng con:

• ZTNA HTTPS Access Proxy: publish ứng dụng web (HTTP/HTTPS).
• ZTNA TCP Forwarding Access Proxy (TFAP): tunnel TCP thuần (RDP, SSH, SMB...) qua HTTPS, dùng khi ứng dụng không phải web.

IP/MAC Filtering (ZTNA tag trong firewall policy thông thường) — đây không phải access proxy. Đây là cách gắn thêm điều kiện ztna-ems-tag vào một firewall policy Layer 3/4 bình thường, dùng để lọc theo IP/MAC + posture tag như một lớp kiểm tra bổ sung, chứ traffic vẫn đi thẳng theo policy route như một kết nối thông thường — không qua reverse proxy.

⚠️ Phân biệt quan trọng: "ZTNA" trong tên gọi của cả hai chế độ dễ khiến người mới nhầm là một. Full ZTNA che giấu địa chỉ IP thật của server (client chỉ biết VIP), còn IP/MAC Filtering chỉ thêm điều kiện posture tag vào policy đang route trực tiếp tới IP thật. Nếu mục tiêu là ẩn hạ tầng nội bộ và bắt buộc đi qua proxy kiểm soát, phải dùng Full ZTNA access proxy — không phải IP/MAC Filtering.

2.4 Cấu hình ZTNA Server (Access Proxy) — ví dụ TCP Forwarding

Ví dụ cấu hình publish quyền RDP tới một server nội bộ 10.88.0.1:3389 qua access proxy VIP 10.0.3.11:8443.

Bước 1 — Tạo ZTNA Server (access proxy + service/server mapping):

config firewall access-proxy
    edit "ZTNA-tcp-server"
        set vip "ZTNA-tcp-vip"
        config api-gateway
            edit 1
                set service tcp-forwarding
                config realservers
                    edit 1
                        set ip 10.88.0.1
                        set port 3389
                    next
                end
            next
        end
    next
end

Bước 2 — Tạo VIP cho access proxy:

config firewall vip
    edit "ZTNA-tcp-vip"
        set type access-proxy
        set extip 10.0.3.11
        set extintf "port3"
        set extport 8443
        set ssl-certificate "Fortinet_Factory"
    next
end

Bước 3 — Tạo ZTNA policy (proxy-policy) đối chiếu posture tag:

config firewall proxy-policy
    edit 1
        set name "ZTNA-RDP-allow"
        set proxy access-proxy
        set access-proxy "ZTNA-tcp-server"
        set srcintf "port3"
        set srcaddr "all"
        set dstaddr "all"
        set ztna-ems-tag "EMS1_CLASS_Low"
        set ztna-tags-match-logic or
        set action accept
        set schedule "always"
        set logtraffic all
        set utm-status enable
        set ssl-ssh-profile "certificate-inspection"
    next
end

🔄 Khác biệt version FortiOS: Từ FortiOS 7.4 trở đi, giao diện GUI gộp cấu hình ZTNA rule vào thẳng Policy & Objects > Firewall Policy với trường Type = ZTNA, thay vì tab riêng "ZTNA Rules" như ở 7.0/7.2. Cú pháp CLI config firewall proxy-policy với tham số ztna-ems-tag vẫn giữ nguyên logic, chỉ khác cách hiển thị GUI.

Ở bước 3, tham số ztna-ems-tag đang tham chiếu tên tag EMS1_CLASS_Low — đây là posture tag do FortiClient EMS sinh ra tự động theo cấu trúc <tên EMS fabric connector>_<loại tag>_<giá trị>. Để tra đúng tên tag hiện có trên hệ thống, không nên gõ tay đoán mò mà nên vào Policy & Objects > ZTNA > Security Posture Tag trên GUI để xem danh sách tag thực tế đang đồng bộ từ EMS, hoặc dùng CLI get firewall proxy-policy sau khi chọn tag qua GUI rồi copy lại tên chính xác.

2.5 Security Posture Tag và quy tắc DENY nên đặt trước ALLOW

Một pattern rất hay dùng trong thực chiến: dùng posture tag để chặn thiết bị có nguy cơ, đặt policy DENY phía trên policy ALLOW.

config firewall policy
    edit 9
        set name "ZTNA-Deny-Malicious"
        set srcintf "port3"
        set dstintf "any"
        set srcaddr "all"
        set dstaddr "ZTNA-webserver"
        set ztna-ems-tag "EMS1_ZTNA_Malicious-File-Detected"
        set schedule "always"
        set logtraffic all
    next
    edit 10
        set name "ZTNA-Allow-Simple"
        set srcintf "port3"
        set dstintf "any"
        set action accept
        set srcaddr "all"
        set dstaddr "ZTNA-webserver"
        set ztna-ems-tag "EMS1_CLASS_Low"
        set schedule "always"
        set logtraffic all
        set nat enable
    next
end

Khi EMS phát hiện thiết bị dính file độc hại (ví dụ do Zero Trust Tagging Rule quét thấy file khớp mẫu) và gắn tag Malicious-File-Detected, ngay cả khi user đó vẫn đang trong phiên kết nối, request tiếp theo sẽ khớp rule DENY ở trên trước — vì FortiOS xử lý policy theo thứ tự từ trên xuống, giống nguyên tắc đã học ở Firewall Policy: cấu trúc, thứ tự xử lý — và bị chặn dù trước đó đã được allow.

Đây chính là điểm khác biệt cốt lõi so với VPN: posture không chỉ kiểm tra một lần lúc đăng nhập, mà được đánh giá lại liên tục theo mỗi kết nối mới tới ứng dụng.

2.6 Chứng chỉ (Certificate) trong ZTNA

Khi client kết nối tới access proxy VIP, FortiGate trình diện server certificate đã cấu hình (mặc định Fortinet_Factory, hoặc nên thay bằng certificate CA nội bộ/công khai đã import — xem lại bài Certificate trên FortiGate). Ngược lại, FortiClient cũng trình diện client certificate do EMS cấp (EMS đóng vai trò CA nội bộ) để FortiGate xác minh danh tính thiết bị trước khi cho qua bước kiểm tra posture tag.

⚠️ Lưu ý: Nếu client certificate hết hạn hoặc EMS ngắt kết nối fabric connector với FortiGate, ZTNA policy sẽ không đồng bộ được tag mới — nên khi troubleshoot lỗi "không truy cập được dù đã cấu hình đúng policy", việc đầu tiên cần kiểm tra là trạng thái kết nối EMS fabric connector, không phải bản thân policy.

3. Hỏi & Đáp

ZTNA có bắt buộc phải có FortiClient EMS không?

Có, đối với Full ZTNA access proxy. EMS đóng vai trò CA cấp certificate cho thiết bị và là nguồn sinh ra Security Posture Tag. Không có EMS, FortiGate vẫn tạo được access proxy nhưng sẽ thiếu cơ chế đánh giá posture liên tục — lúc đó chỉ còn xác thực user/certificate cơ bản chứ không phải Zero Trust đầy đủ.

ZTNA có thay thế hoàn toàn SSL-VPN không?

Không nhất thiết. Với ứng dụng web hoặc TCP đơn giản (RDP, SSH), ZTNA access proxy phù hợp và an toàn hơn. Nhưng với nhu cầu truy cập rộng vào nhiều dịch vụ trong subnet, hoặc ứng dụng cần broadcast/multicast, VPN truyền thống vẫn cần thiết. Nhiều doanh nghiệp triển khai song song cả hai, chọn theo từng nhóm ứng dụng.

Client ngồi trong văn phòng (on-net) có cần qua ZTNA không?

Có thể áp dụng. Đây là điểm khác VPN — ZTNA không phân biệt vị trí mạng của client. Ngay cả máy tính ngồi cùng LAN với server vẫn có thể bị bắt buộc đi qua access proxy và kiểm tra posture, giúp giảm rủi ro lateral movement nếu một máy trong mạng nội bộ bị chiếm quyền.

Nếu không có FortiClient EMS, có cách nào triển khai ZTNA cơ bản không?

Có thể dùng chế độ IP/MAC Filtering (mục 2.3) trong firewall policy như một hình thức lọc thêm, nhưng đây không phải Full ZTNA access proxy và không có khả năng ẩn IP thật của server hay đánh giá posture liên tục. Muốn dùng đúng nghĩa Zero Trust, EMS gần như là điều kiện bắt buộc.

4. Quiz

Câu 1: Điểm khác biệt cốt lõi giữa ZTNA và VPN truyền thống là gì?

• A. ZTNA nhanh hơn VPN về tốc độ mã hóa
• B. ZTNA xác thực và đánh giá lại theo từng kết nối tới ứng dụng, không cấp quyền tràn lan vào cả mạng
• C. ZTNA không cần certificate
• D. ZTNA chỉ dùng được cho user ngồi trong văn phòng

Câu 2: Thành phần nào đóng vai trò cấp client certificate và sinh Security Posture Tag cho ZTNA?

• A. FortiAnalyzer
• B. FortiManager
• C. FortiClient EMS
• D. FortiSwitch

Câu 3: Trong ví dụ cấu hình policy DENY/ALLOW theo posture tag, vì sao policy DENY phải đặt phía trên policy ALLOW?

• A. Vì FortiOS luôn ưu tiên xử lý policy DENY bất kể thứ tự
• B. Vì FortiOS xử lý policy theo thứ tự từ trên xuống, policy khớp trước sẽ được áp dụng trước
• C. Vì policy ALLOW không thể tồn tại chung file cấu hình với policy DENY
• D. Thứ tự không quan trọng, FortiOS tự động sắp xếp lại

Câu 4: Chế độ "IP/MAC Filtering" dùng ZTNA tag khác gì so với "Full ZTNA Access Proxy"?

• A. Hai chế độ này hoàn toàn giống nhau, chỉ khác tên gọi
• B. IP/MAC Filtering thêm điều kiện posture tag vào policy route trực tiếp tới IP thật, không qua reverse proxy như Full ZTNA
• C. IP/MAC Filtering yêu cầu FortiAnalyzer, Full ZTNA thì không
• D. Full ZTNA chỉ dùng được cho traffic UDP

👉 Đáp án

Câu 1: B ZTNA đánh giá lại tin cậy theo từng phiên kết nối tới ứng dụng cụ thể (per-application, per-session), khác với VPN chỉ xác thực một lần rồi cấp quyền vào cả dải mạng.

Câu 2: C FortiClient EMS đóng vai trò CA cấp client certificate cho thiết bị và là nguồn sinh Security Posture Tag dựa trên các tagging rule cấu hình sẵn.

Câu 3: B FortiOS xử lý firewall policy tuần tự từ trên xuống dưới (top-down), dừng lại ở policy đầu tiên khớp điều kiện — nên rule DENY dựa trên posture nguy hiểm phải nằm trước rule ALLOW để được ưu tiên chặn.

Câu 4: B Full ZTNA access proxy là reverse proxy thật sự, ẩn IP server và bắt buộc traffic đi qua FortiGate xác thực trước. IP/MAC Filtering chỉ là điều kiện lọc thêm trong policy Layer 3/4 thông thường, traffic vẫn route trực tiếp.

📚 Bài viết thuộc khóa học FortiGate của VNExperts

🧭 Điều hướng