Ghi chép sau 3 tháng triển khai Zero Trust

TL;DR

• Sau 3 tháng triển khai Cloudflare Zero Trust cho tổ chức hàng ngàn người dùng (Access + Tunnel + WARP + Gateway + SIEM pipeline), bài học lớn nhất: Zero Trust là dự án identity trước khi là dự án network.
• Tunnel + Access tạo giá trị nhanh nhất — chuyển control plane từ “vào được network” sang “user này, thiết bị này, ngữ cảnh này, vào được app này”; không cần inbound port.
• Device posture phải triển khai theo 6 giai đoạn: Observe → Report → Notify → Pilot enforce → Progressive enforce → Full enforce — bật chặn ngay làm bùng ticket.
• Đặt tên group có cấu trúc kiểu ZTNA.Platform.CICD.Admin / ZTNA.Vendor.AppX.Support thay vì Allow IT — tên dài hơn nhưng audit và sự cố nhanh hơn nhiều.
• Tránh big-bang migration — DNS + routing + group IdP + posture + browser cache + firewall cũ trộn lẫn khi cùng lúc sẽ thành hỗn loạn truy nguyên; chia theo cụm dịch vụ.
• 3 tích hợp làm sớm: IdP (vòng đời user/group, joiner/mover/leaver), endpoint posture (baseline + dashboard), log Access + Tunnel + Gateway vào SIEM từ ngày đầu.
• Để sau: Browser Isolation, DLP, SaaS posture, advanced egress — chỉ thêm phức tạp khi nền identity/posture/log chưa vững.

Bài này dành cho kỹ sư bảo mật, trưởng nhóm IT hoặc nhóm hạ tầng đang chuẩn bị triển khai Zero Trust cho một tổ chức quy mô hàng ngàn người dùng.

Đây không phải bài giải thích Zero Trust là gì.

Những bài đó đã có quá nhiều.

Bài này là phần còn lại ít được nói hơn: sau khi đã chọn nền tảng, đã có giấy phép, đã có sơ đồ kiến trúc, đã có vài buổi đào tạo, thì điều gì thật sự xảy ra khi bắt đầu đưa Zero Trust vào vận hành?

Sau 3 tháng triển khai Cloudflare Zero Trust, điều tôi nhận ra rõ nhất là:

Zero Trust không khó nhất ở phần cấu hình. Nó khó ở phần biến kiểm soát truy cập thành một năng lực vận hành có người phụ trách, có quy trình, có log, có kiểm toán và có khả năng mở rộng.

Nói cách khác, đây không chỉ là một dự án thay VPN.

Đây là một dự án sửa lại cách tổ chức cấp quyền, kiểm soát thiết bị, phát hành ứng dụng nội bộ và quan sát hành vi truy cập.

Bối cảnh

Dự án bắt đầu vào khoảng tháng 10/2025, với phạm vi tổ chức ở quy mô hàng ngàn người dùng.

Mục tiêu ban đầu khá rõ:

• Giảm phụ thuộc vào VPN truyền thống cho các hệ thống nội bộ và admin plane
• Đưa truy cập ứng dụng về mô hình dựa trên identity, group và ngữ cảnh
• Áp dụng device posture trước khi cho phép truy cập tài nguyên nhạy cảm
• Ghi nhận log Access, log Gateway và sự kiện Tunnel về SIEM
• Chuẩn hóa quy trình cấp quyền theo group thay vì xử lý thủ công theo từng người dùng

Stack chính được sử dụng là Cloudflare Zero Trust, bao gồm:

• Cloudflare Access cho kiểm soát truy cập ở tầng ứng dụng
• Cloudflare Tunnel để phát hành dịch vụ nội bộ mà không cần mở inbound port
• Cloudflare WARP cho enroll thiết bị, định tuyến riêng và posture
• Cloudflare Gateway cho chính sách DNS, HTTP, network và ghi log
• Đường ống SIEM để phục vụ giám sát, điều tra và kiểm toán

Nghe qua thì giống một bài toán kỹ thuật thuần túy.

Nhưng khi đi vào thực tế, phần kỹ thuật chỉ là một nửa câu chuyện.

Nửa còn lại là làm sạch identity, xác định người phụ trách group, xử lý ngoại lệ, quy trình duyệt, truyền thông với người dùng, và niềm tin của các nhóm đang dùng hệ thống cũ mỗi ngày.

Điều đầu tiên học được: Zero Trust là dự án identity trước khi là dự án network

Khi nói về Zero Trust, rất dễ bắt đầu từ network:

• App này đi qua Tunnel nào?
• Route này nằm ở virtual network nào?
• Service này dùng private IP hay public hostname?
• Có cần split tunnel không?
• Có cần WARP không?

Những câu hỏi đó quan trọng.

Nhưng câu hỏi quan trọng hơn là:

User này là ai, thuộc nhóm nào, đang dùng thiết bị gì, và có thật sự cần truy cập hệ thống này không?

Nếu phần identity chưa sạch, mọi chính sách phía sau chỉ là tự động hóa một nguồn dữ liệu chưa đáng tin.

Ví dụ, một chính sách rất đơn giản:

Allow users in ZTNA.Platform.CICD.Admin to access CI/CD Admin Portal

Nhìn thì rõ ràng.

Nhưng trong thực tế, nó kéo theo hàng loạt câu hỏi:

• Group này do ai sở hữu?
• Ai được quyền thêm người dùng vào group?
• Người dùng đổi nhóm thì có bị gỡ khỏi group không?
• Nhân sự thuê ngoài có đang nằm chung với nhân viên chính thức không?
• Group này đại diện cho phòng ban, vai trò hay quyền truy cập?
• Có rà soát định kỳ không?
• Có group nào được tạo tạm nhưng tồn tại mãi không?

Ở quy mô vài chục người, các vấn đề này có thể xử lý bằng trí nhớ và tin nhắn nội bộ.

Ở quy mô hàng ngàn người dùng, cách đó không còn an toàn.

Chỉ một group sai thành viên có thể mở quyền cho nhiều ứng dụng. Chỉ một group không có người phụ trách có thể khiến việc thu hồi quyền bị trì hoãn. Chỉ một quy ước đặt tên không rõ có thể làm kiểm toán trở thành một buổi đoán ý tập thể.

Vì vậy, bài học đầu tiên rất rõ:

Đừng bắt đầu Zero Trust bằng chính sách. Hãy bắt đầu bằng mô hình identity.

Cần làm sạch vòng đời người dùng, vòng đời group, quy ước đặt tên, người phụ trách, người duyệt và quy trình joiner/mover/leaver trước khi kỳ vọng chính sách Access hoạt động đúng.

Đây là phần không hào nhoáng.

Nhưng nó là nền móng.

Điều hoạt động tốt nhất: Tunnel làm thay đổi cách phát hành ứng dụng nội bộ

Cloudflare Tunnel là một trong những phần tạo ra giá trị nhanh nhất.

Với các hệ thống dạng web admin, dashboard nội bộ, CI/CD, giám sát, Git, kho artifact, wiki nội bộ hoặc công cụ vận hành, Tunnel giúp thay đổi hoàn toàn mô hình truy cập.

Trước đây, mô hình phổ biến thường là:

1. Người dùng bật VPN
2. VPN cấp route
3. Người dùng truy cập IP hoặc DNS nội bộ
4. Firewall cho phép theo subnet
5. Kiểm toán chủ yếu dựa trên VPN log, firewall log hoặc log ứng dụng rời rạc

Mô hình này chạy được, nhưng có nhiều điểm yếu:

• Quyền truy cập thường gắn với network hơn là identity
• Một khi vào VPN, phạm vi truy cập dễ bị rộng hơn nhu cầu thực tế
• Khó phân biệt người dùng cần vào app A nhưng không nên vào app B
• Khó áp dụng posture theo từng ứng dụng
• Khó có dấu vết kiểm toán rõ ràng ở lớp truy cập ứng dụng

Khi đưa dịch vụ qua Tunnel và Access, trải nghiệm thay đổi đáng kể.

Người dùng không cần nghĩ về tuyến, subnet hay VPN profile. Họ mở URL, đăng nhập qua SSO, qua chính sách, và truy cập ứng dụng.

Nhóm bảo mật cũng có nhiều kiểm soát hơn:

• Không cần mở inbound port
• Không phơi dịch vụ trực tiếp ra Internet
• Chính sách gắn với identity, group, posture và ngữ cảnh
• Có log kiểm toán theo từng ứng dụng
• Có thể thu hồi quyền theo group nhanh hơn
• Có thể áp điều kiện khác nhau cho production, non-production, nhà cung cấp hoặc truy cập đặc quyền

Điểm quan trọng ở đây không phải là “Tunnel thay VPN”.

Điểm quan trọng là Tunnel giúp chuyển mặt phẳng điều khiển từ truy cập theo network sang truy cập ứng dụng theo identity.

Đây là khác biệt rất lớn.

VPN trả lời câu hỏi:

Người dùng có được vào network này không?

Zero Trust Access trả lời câu hỏi cụ thể hơn:

Người dùng này, từ thiết bị này, trong điều kiện này, có được vào ứng dụng này không?

Hai câu hỏi nghe giống nhau, nhưng về mặt kiến trúc bảo mật là hai thế giới khác nhau.

Device posture: phần giúp Zero Trust không biến thành VPN có SSO

Một sai lầm phổ biến là nghĩ rằng có SSO là đã đủ Zero Trust.

Thực tế, nếu chỉ có SSO, ta mới xác thực được người dùng. Ta chưa đánh giá đầy đủ thiết bị mà họ đang dùng.

Trong nhiều tình huống, rủi ro không nằm ở identity bị sai, mà nằm ở endpoint không đạt chuẩn:

• Máy không thuộc quản lý của công ty
• EDR không chạy
• Phiên bản OS quá cũ
• Ổ đĩa không được mã hóa
• WARP chưa enroll
• Thiết bị không còn đạt chuẩn nhưng vẫn giữ session
• Người dùng đúng nhưng đang dùng một endpoint không nên được truy cập production

Device posture giúp bổ sung lớp kiểm soát này.

Một số tín hiệu posture nên có trong baseline:

• Thiết bị do công ty quản lý
• EDR/AV đang chạy
• Phiên bản OS tối thiểu
• Mã hóa ổ đĩa
• Domain joined hoặc đã enroll MDM
• Đã enroll WARP
• Certificate hoặc tín hiệu định danh thiết bị

Tuy nhiên, posture là con dao hai lưỡi.

Nếu áp dụng quá sớm, ticket sẽ tăng mạnh. Nếu chỉ quan sát mãi, posture không thực sự giảm rủi ro.

Cách triển khai tốt hơn là đi theo từng giai đoạn:

1. Quan sát, thu thập tín hiệu posture, chưa chặn
2. Báo cáo, tạo dashboard theo người dùng, nhóm, OS, trạng thái thiết bị
3. Thông báo, nhắc người dùng/nhóm chưa đạt chuẩn
4. Thí điểm thực thi, áp chính sách cho một nhóm nhỏ hoặc ứng dụng ít rủi ro
5. Thực thi dần, mở rộng theo đơn vị kinh doanh hoặc nhóm ứng dụng
6. Thực thi toàn bộ, áp dụng cho hệ thống nhạy cảm và truy cập production

Bài học ở đây là:

Posture không chỉ là ô đánh dấu kỹ thuật. Nó là một chương trình thay đổi hành vi endpoint.

Muốn posture thành công, cần dashboard, truyền thông, quy trình xử lý ngoại lệ và lộ trình rõ ràng.

Không thể chỉ bật rule chặn rồi mong người dùng tự hiểu.

Điều không hiệu quả: kỳ vọng người dùng tự yêu cầu quyền một cách hoàn hảo

Trên lý thuyết, yêu cầu cấp quyền nghe rất đẹp.

Người dùng cần quyền thì yêu cầu. Người phụ trách duyệt. Bảo mật kiểm toán. Mọi thứ có log.

Nhưng trong thực tế, nếu quy trình chậm hoặc không rõ, người dùng sẽ tìm đường khác.

Họ sẽ nhắn trực tiếp cho người quen. Họ sẽ xin quyền rộng hơn để khỏi yêu cầu nhiều lần. Họ sẽ dùng lại tài khoản dùng chung. Họ sẽ quay về VPN cũ. Hoặc họ sẽ leo thang vì “đang cần gấp”.

Vấn đề không phải người dùng thiếu kỷ luật.

Vấn đề là quy trình cấp quyền không theo kịp tốc độ vận hành.

Ở quy mô hàng ngàn người dùng, yêu cầu cấp quyền không thể vận hành bằng một vài người nhớ để xử lý thủ công. Nó cần trở thành một quy trình có thiết kế.

Tối thiểu cần có:

• Người sở hữu ứng dụng rõ ràng
• Người duyệt rõ ràng
• SLA rõ ràng
• Điều kiện cấp quyền rõ ràng
• Thời hạn quyền rõ ràng
• Cơ chế truy cập khẩn cấp
• Dấu vết kiểm toán cho từng quyết định
• Quy trình thu hồi khi người dùng đổi vai trò hoặc hết nhu cầu

Nếu không có những thành phần này, quy trình duyệt sẽ biến thành nút thắt cổ chai.

Và khi kiểm soát bảo mật trở thành nút thắt, người dùng sẽ tạo đường vòng.

Trong bảo mật, đường vòng thường nguy hiểm hơn cả vấn đề ban đầu.

Điều tạo nợ kỹ thuật nhanh nhất: chính sách quá rộng

Trong giai đoạn đầu, rất dễ tạo một chính sách lớn kiểu:

Allow all employees

Nó giúp triển khai nhanh. Demo tốt. Ít ticket. Ít phàn nàn.

Nhưng nó cũng tạo nợ rất nhanh.

Khi mọi nhân viên đều có quyền vào một app, câu hỏi kiểm toán trở nên khó hơn:

• Ai thật sự cần quyền này?
• Nhóm nào đang dùng?
• Nhân sự thuê ngoài có được vào không?
• Người dùng đã chuyển nhóm có còn quyền không?
• App production và non-production có bị trộn quyền không?
• Khi sự cố xảy ra, thu hồi quyền của nhóm nào?

Chính sách quá rộng thường không gây đau ngay ngày đầu.

Nó gây đau khi tổ chức cần kiểm toán, gỡ nhân sự, xử lý sự cố hoặc tách quyền theo môi trường.

Cách tốt hơn là thiết kế group và chính sách theo phạm vi truy cập ngay từ đầu.

Ví dụ:

ZTNA.Platform.CICD.Admin
ZTNA.Platform.CICD.ReadOnly
ZTNA.Security.SIEM.Analyst
ZTNA.Security.SIEM.Admin
ZTNA.Production.Monitoring.ReadOnly
ZTNA.Vendor.AppX.Support
ZTNA.Data.Analytics.User

Tên dài hơn một chút, nhưng ý nghĩa rõ hơn nhiều.

Một chính sách tốt không chỉ giúp cho phép hay chặn. Nó phải giúp trả lời nhanh:

Ai được truy cập cái gì, với vai trò nào, từ thiết bị nào, trong điều kiện nào, và ai đã duyệt quyền đó?

Đó mới là chính sách có thể kiểm toán được.

Điều nên tránh: chuyển đổi kiểu big bang

Một bài học khá đắt là không nên chuyển đổi theo kiểu big bang.

Mình từng thử chuyển nhiều dịch vụ từ VPN sang Tunnel trong cùng một đợt. Về lý thuyết, kế hoạch có vẻ hợp lý: chuẩn bị trước, kiểm thử trước, chọn thời điểm ít người dùng, có đường lùi.

Nhưng khi triển khai thật, số lượng biến số quá nhiều:

• DNS
• định tuyến
• group IdP
• chính sách Access
• kiểm tra posture
• hành vi browser
• phụ thuộc dịch vụ
• firewall rule cũ
• thói quen người dùng
• đường break-glass
• kế hoạch lùi phiên bản

Khi lỗi xảy ra, rất khó xác định nguyên nhân nằm ở đâu.

Một người dùng không vào được app có thể do group sai, posture thất bại, DNS chưa cập nhật, dịch vụ đứng sau Tunnel lỗi, cache browser, hoặc xung đột tuyến.

Nếu nhiều dịch vụ cùng chuyển một lúc, việc truy nguyên sẽ nhanh chóng trở thành hỗn loạn.

Cách làm tốt hơn là chia nhỏ việc chuyển đổi theo nhóm dịch vụ:

1. Dashboard nội bộ ít rủi ro
2. Giám sát
3. CI/CD
4. Git hoặc kho artifact
5. Admin portal
6. Production admin plane
7. Ứng dụng legacy phức tạp

Mỗi nhóm dịch vụ nên có:

• Người dùng thí điểm
• Người sở hữu ứng dụng
• Kịch bản kiểm thử
• Tiêu chí thành công
• Đường lùi
• Dashboard log
• Truyền thông trước và sau khi chuyển
• Đánh giá lại sau khi chuyển

Chuyển đổi từng phần nhìn có vẻ chậm hơn, nhưng thực tế lại nhanh hơn vì ít phải lùi phiên bản, ít mất niềm tin và dễ truy nguyên hơn.

Trong chuyển đổi hạ tầng, niềm tin của người dùng là một tài sản rất quan trọng.

Mất niềm tin một lần, lần chuyển tiếp theo sẽ khó hơn nhiều.

Ba tích hợp đáng làm sớm nhất

Nếu chỉ được chọn ba phần để làm thật tốt ngay từ đầu, tôi sẽ chọn ba thứ sau.

1. Identity Provider

IdP là mặt phẳng điều khiển của Zero Trust.

Tất cả chính sách đều bắt đầu từ identity. Nếu identity không sạch, chính sách sẽ không đáng tin.

Cần làm rõ ngay từ đầu:

• Vòng đời người dùng
• Vòng đời group
• Người phụ trách group
• Quy ước đặt tên
• Quy trình joiner/mover/leaver
• Định danh cho nhân sự thuê ngoài/nhà cung cấp
• Chính sách MFA
• Rà soát nhóm đặc quyền
• Định danh break-glass

Đây không phải phần phụ trợ.

Đây là phần lõi của kiến trúc.

2. Endpoint posture

Endpoint posture giúp phân biệt giữa:

Người dùng đúng

và:

Người dùng đúng, nhưng thiết bị không đạt chuẩn để truy cập tài nguyên này.

Đây là lớp kiểm soát rất quan trọng cho truy cập production, admin plane và các ứng dụng nhạy cảm.

Không cần áp dụng toàn bộ ngay ngày đầu. Nhưng cần có baseline, dashboard và lộ trình áp dụng rõ ràng.

Nếu không, Zero Trust rất dễ dừng lại ở mức “SSO trước app nội bộ”.

3. Đường ống log vào SIEM

Kiểm soát truy cập mà không có log thì rất khó vận hành như một biện pháp bảo mật nghiêm túc.

Các log tối thiểu nên được đưa về SIEM:

• Quyết định Access
• Định danh người dùng
• Ứng dụng
• IP nguồn
• Kết quả kiểm tra device posture
• Chính sách đã khớp
• Sự kiện Tunnel
• Sự kiện Gateway DNS
• Sự kiện Gateway HTTP
• Sự kiện Gateway network
• Quyết định chặn/cho phép
• Hoạt động admin

Không có log, không có phát hiện.

Không có phát hiện, không có điều tra.

Không có điều tra, không có niềm tin khi sự cố xảy ra.

Đường ống log nên được làm từ ngày đầu, không phải sau khi triển khai xong.

Những khả năng nên để sau

Một số tính năng rất hấp dẫn, nhưng không nên làm quá sớm nếu nền tảng chưa vững:

• Browser Isolation
• DLP
• Kiểm soát bảo mật SaaS
• Render browser từ xa
• Chính sách chiều ra nâng cao
• Chấm điểm rủi ro chi tiết theo từng request
• Quy trình bảo vệ dữ liệu phức tạp

Những khả năng này có giá trị.

Nhưng nếu IdP chưa sạch, posture chưa ổn, log chưa vào SIEM, quy trình duyệt chưa có SLA, thì thêm khả năng mới sẽ chủ yếu làm tăng độ phức tạp.

Thứ tự triển khai hợp lý hơn:

1. Nền tảng identity
2. Mô hình chính sách Access
3. Phát hành ứng dụng nội bộ qua Tunnel
4. Enroll thiết bị
5. Device posture
6. Log về SIEM
7. Quy trình duyệt
8. Phân vùng chi tiết
9. DLP, Isolation và các kiểm soát nâng cao

Zero Trust nên được xây như một nền tảng, không phải một tập tính năng rời rạc.

Một số bài học thực tế

1. Quy ước đặt tên quan trọng hơn tưởng tượng

Tên group, tên app, tên chính sách và tên rule cần được thiết kế để người khác đọc cũng hiểu.

Không nên đặt kiểu:

Allow IT

Nên đặt rõ hơn:

Allow-Platform-Team-to-CICD-Admin-Portal-With-Managed-Device

Tên dài hơn, nhưng khi kiểm toán hoặc sự cố xảy ra, nó tiết kiệm rất nhiều thời gian.

2. Xử lý ngoại lệ phải có từ đầu

Không có hệ thống nào áp dụng 100% mà không có ngoại lệ.

Sẽ luôn có nhà cung cấp, thiết bị legacy, truy cập khẩn cấp, ứng dụng cũ, OS chưa kịp nâng cấp hoặc tình huống nghiệp vụ đặc biệt.

Điều quan trọng không phải là không có ngoại lệ.

Điều quan trọng là ngoại lệ phải:

• Có người phụ trách
• Có lý do
• Có thời hạn
• Có người duyệt
• Có log
• Có rà soát định kỳ
• Có kế hoạch xử lý dứt điểm

Ngoại lệ không được quản lý sẽ trở thành đường vòng vĩnh viễn.

Đường vòng vĩnh viễn là nơi Zero Trust bắt đầu mất giá trị.

3. Break-glass không phải dấu hiệu thất bại

Zero Trust không loại bỏ nhu cầu break-glass.

Nó chỉ làm cho break-glass cần được thiết kế nghiêm túc hơn.

Một mô hình break-glass tốt nên có:

• Tài khoản riêng
• MFA mạnh
• Phạm vi quyền tối thiểu
• Thời hạn sử dụng
• Log đầy đủ
• Cảnh báo khi được dùng
• Rà soát sau khi dùng
• Không dùng cho vận hành hằng ngày

Nếu không thiết kế break-glass, nhóm vận hành sẽ tự tạo đường vòng.

Và đường vòng tự phát thường nguy hiểm hơn nhiều.

4. Truyền thông quyết định mức độ chấp nhận của người dùng

Nhóm bảo mật thường tập trung vào policy, posture và log.

Người dùng lại quan tâm đến câu hỏi rất thực tế:

• Tôi truy cập app cũ bằng cách nào?
• Khi bị chặn thì liên hệ ai?
• Vì sao trước đây vào được, giờ không vào được?
• Tôi cần làm gì để thiết bị đạt chuẩn?
• Yêu cầu cấp quyền mất bao lâu?
• Có ảnh hưởng công việc hôm nay không?

Nếu không truyền thông rõ, người dùng sẽ nhìn Zero Trust như một lớp cản trở.

Nếu truyền thông tốt, họ sẽ hiểu đây là cách truy cập mới an toàn hơn, có kiểm soát hơn và ít phụ thuộc VPN hơn.

Triển khai Zero Trust không chỉ là bật policy.

Nó là thay đổi trải nghiệm truy cập của người dùng.

Điều rút ra sau 3 tháng

Sau 3 tháng, có vài kết luận rất rõ.

Thứ nhất, Zero Trust là dự án identity trước khi là dự án network. Network vẫn quan trọng, nhưng identity mới là nơi chính sách bắt đầu.

Thứ hai, device posture là phần biến SSO thành kiểm soát bảo mật có ngữ cảnh. Không có posture, ta mới biết người dùng là ai, nhưng chưa biết thiết bị có đáng tin không.

Thứ ba, ghi log vào SIEM phải đi cùng triển khai từ đầu. Không có log, rất khó chứng minh hiệu quả, điều tra sự cố hoặc vận hành chính sách ở quy mô lớn.

Thứ tư, quy trình duyệt là một phần của kiến trúc. Nếu cấp quyền quá chậm, người dùng sẽ tạo đường vòng. Nếu cấp quyền quá rộng, bảo mật mất kiểm soát.

Thứ năm, chuyển đổi từng phần luôn an toàn hơn big bang. Càng nhiều dịch vụ, càng nhiều người dùng, càng cần chia nhỏ triển khai để giữ niềm tin và khả năng truy nguyên.

Kết

Ba tháng đầu triển khai Zero Trust thường tạo cảm giác tiến độ chậm.

Không phải vì nhóm không làm được việc, mà vì phần lớn công sức nằm ở những việc nền tảng:

• Làm sạch identity
• Chuẩn hóa group
• Xác định người phụ trách
• Thiết kế mô hình policy
• Enroll thiết bị
• Thu thập posture
• Đưa log về SIEM
• Xây quy trình duyệt
• Giải thích cho người dùng cách truy cập mới

Những việc này không tạo cảm giác “ra mắt tính năng” mỗi ngày.

Nhưng chúng quyết định hệ thống có vận hành được ở quy mô hàng ngàn người dùng hay không.

Khi nền tảng đã ổn, tốc độ triển khai tăng rất nhanh.

Mỗi ứng dụng mới không còn cần mở VPN route riêng, firewall rule riêng, hướng dẫn truy cập riêng và ngoại lệ riêng. Nó chỉ cần được đưa vào đúng mô hình:

• Ứng dụng có người phụ trách
• Group có mục đích
• Policy có điều kiện
• Thiết bị có posture
• Truy cập có log
• Ngoại lệ có thời hạn
• Quyền có thể kiểm toán

Đó là lúc Zero Trust bắt đầu tạo ra giá trị thật.

Không phải vì nó là một công nghệ mới hơn VPN.

Mà vì nó buộc tổ chức vận hành truy cập theo cách có kiểm soát hơn, có điều kiện hơn, đo lường được hơn và phù hợp hơn với môi trường enterprise hiện đại.