Cloudflare Zero Trust — Hướng dẫn triển khai & thực hành tốt khi onboarding

Playbook triển khai chi tiết, có quan điểm rõ ràng để triển khai nền tảng Zero Trust (SASE) của Cloudflare cùng Cloudflare WAN. Mỗi phần đưa đường dẫn dashboard chính xác, giá trị cấu hình cụ thể, các lưu ý thực hành tốt, ví dụ chính sách đã làm sẵn, bước kiểm tra, và những sai lầm cần tránh.

Đối tượng	Quản trị viên bảo mật / mạng / IT triển khai Cloudflare One từ đầu đến cuối
Phạm vi	Account → Identity → Devices → ZTNA → Gateway → DLP → AI controls → Cloudflare WAN
Bảng điều khiển	Zero Trust: https://one.dash.cloudflare.com · Account: https://dash.cloudflare.com
Gốc tài liệu	developers.cloudflare.com/cloudflare-one/ · …/cloudflare-wan/ · …/reference-architecture/
Lộ trình học chính	Replace your VPN …/learning-paths/replace-vpn/ · Holistic AI security …/learning-paths/holistic-ai-security/
Cập nhật lần cuối	2026-06-08

Ghi chú tên gọi: Client trên thiết bị trước đây gọi là WARP client nay là Cloudflare One Client trong tài liệu và dashboard hiện tại. Hướng dẫn này dùng Cloudflare One Client nhưng hành vi giống hệt WARP. Nhãn menu dashboard cũng thay đổi theo thời gian (các khu vực chính sách được nhóm dưới Access controls và Traffic policies); hãy theo mục gần nhất nếu một nhãn đã được di chuyển.

---

0. Cách dùng hướng dẫn này

Đây là trình tự của một đợt triển khai thực tế. Mỗi giai đoạn phụ thuộc giai đoạn trước, và mỗi giai đoạn được thiết kế để thí điểm trước (5–25 người dùng / một site), kiểm tra, rồi mở rộng.

1 Account/Org → 2 Identity → 3 Devices (Cloudflare One Client)
   → 4 ZTNA (Access) → 5 Gateway (DNS → Network → HTTP → TLS)
      → 6 DLP → 7 AI controls → 8 Cloudflare WAN

10 quy tắc vàng (đọc trước)

1. Triển khai dần, không big-bang. Kiến trúc tham chiếu SASE của chính Cloudflare khuyến nghị ưu tiên một hoặc hai use case (thay VPN, rồi SWG) rồi xếp lớp phần còn lại. Hầu hết đợt triển khai thất bại cố bật mọi thứ cùng lúc.
2. Thí điểm → kiểm tra → mở rộng ở mọi giai đoạn. Không bao giờ đẩy một chính sách thực thi mới tới toàn bộ người dùng nếu chưa có nhóm thí điểm được giám sát và đường rollback.
3. Bắt đầu ở chế độ log/monitor, rồi mới thực thi. Đây là quy tắc đặc biệt với Gateway, DLP và AI controls. Lấy baseline lưu lượng thực trước khi Block.
4. Xây thành phần tái sử dụng, không làm snowflake từng ứng dụng. Dùng Access Groups, Lists và reusable posture checks để một thay đổi lan tới mọi nơi. Có quy ước đặt tên từ ngày đầu.
5. Danh tính là nền tảng. Kết nối IdP doanh nghiệp với group claims và SCIM trước khi viết bất kỳ chính sách nào tham chiếu nhóm.
6. Đặc quyền tối thiểu + xác minh liên tục. Default-deny, thu hẹp phạm vi chính sách, đặt session duration ngắn cho ứng dụng nhạy cảm, và xác minh lại device posture trên mọi request.
7. Giữ đường break-glass. Luôn giữ một phương thức đăng nhập quản trị (OTP / Cloudflare login) và một Super Admin không thể bị khóa bởi chính sách của chính bạn.
8. Inspect có chủ đích. TLS decryption mở khóa HTTP filtering, DLP và AI prompt inspection — nhưng hãy lên kế hoạch ngoại lệ Do Not Inspect (ứng dụng cert-pinned, Microsoft 365) và cân nhắc phạm vi riêng tư/pháp lý.
9. Ghi log mọi thứ về SIEM. Bật Logpush cho Access + Gateway từ đầu; bạn sẽ cần chúng để tinh chỉnh và audit.
10. Để ý entitlement. DLP (custom profiles), advanced posture, Browser Isolation ở quy mô lớn, và Cloudflare WAN yêu cầu Enterprise. Xác nhận trước khi xác định phạm vi.

---

1. Tổng quan nền tảng & mô hình triển khai

Cloudflare Zero Trust (một phần của nền tảng SASE Cloudflare One) thay thế VPN legacy + stack bảo mật on-prem bằng cách thực thi chính sách theo danh tính và ngữ cảnh tại anycast edge toàn cầu của Cloudflare. Vì mọi dịch vụ chạy ở mọi data center, lưu lượng được kết nối, xác minh, lọc và định tuyến trong một lượt gần người dùng — không backhaul, không độ trễ service-chaining.

Khối xây dựng

Khả năng	Sản phẩm	Vai trò
Identity	IdP integrations + SCIM	Người dùng là ai, họ thuộc nhóm nào
Device connectivity	Cloudflare One Client (WARP)	On-ramp mã hóa + tín hiệu device posture
ZTNA	Access	Truy cập theo từng ứng dụng, nhận biết danh tính (thay VPN)
SWG	Gateway	Lọc DNS / network (L4) / HTTP (L7)
Data protection	DLP	Phát hiện & kiểm soát dữ liệu nhạy cảm trong lưu lượng HTTP
AI safety	AI controls / DLP for AI / AI Security for Apps	Quản trị việc dùng GenAI và bảo vệ prompt/dữ liệu
Private connectivity	Cloudflare Tunnel (cloudflared) / WARP Connector / Mesh	Phơi bày ứng dụng/mạng nội bộ mà không mở lỗ inbound trên firewall
Network on-ramp	Cloudflare WAN	Kết nối toàn bộ site, DC và cloud tới Cloudflare

Cách lưu lượng tới Cloudflare (on-ramp) — chọn theo use case

On-ramp	Dùng cho	Ghi chú / thực hành tốt
Cloudflare One Client (WARP)	Laptop/mobile được quản lý & BYOD	On-ramp chuẩn cho người dùng; cũng là nguồn device posture
Cloudflare Tunnel (cloudflared)	Ứng dụng web nội bộ, SSH/RDP, CIDR riêng	Chỉ outbound; khuyến nghị hơn origin hướng ra internet. Chỉ cloudflared proxy public hostnames tới ứng dụng nội bộ
WARP Connector / Mesh	Site-to-site / mesh từ một host Linux	On-ramp phần mềm; hai chiều
Cloudflare WAN (GRE/IPsec/Connector/CNI)	Văn phòng chi nhánh, data center, VPC cloud	On-ramp mạng Enterprise; định tuyến toàn bộ mạng
Clientless (Browser Isolation)	Thiết bị không quản lý/bên thứ ba, không cài đặt	Không agent; chỉ có user identity (không có device posture)

Kiến trúc tham chiếu (logic)

   Managed device ─Client─┐
   BYOD (Include split) ──┤        ┌──────────────────────────────────────────────┐
   Unmanaged (clientless)─┤        │            CLOUDFLARE GLOBAL EDGE             │   Internet
   Branch/DC ─Cloudflare WAN───┼──────► │  Identity ▸ Posture ▸ Access(ZTNA)            │ ─── & SaaS
   Cloud VPC ─MNC/IPsec───┘        │     ▸ Gateway(DNS/L4/HTTP) ▸ DLP ▸ AI controls│ ──►
                                   └───────────────┬──────────────────────────────┘
                                                   │ Cloudflare Tunnel / Access
                                                   ▼
                                       Private apps, servers, internal networks

Các quyết định mô hình triển khai cần chốt ngay từ đầu

• Thiết bị managed vs. BYOD → quyết định chế độ WARP split-tunnel (Exclude cho thiết bị quản lý, Include cho thiết bị cá nhân) và việc bạn có thể yêu cầu posture mạnh hay không.
• Client vs. clientless → clientless (Browser Isolation) không có device posture; dành cho nhà thầu/bên thứ ba.
• Bảo mật internet trước (SWG/DLP) vs. truy cập nội bộ trước (ZTNA) → hầu hết tổ chức bắt đầu bằng thay VPN (ZTNA), rồi thêm SWG/DLP. Hãy chọn rõ use case giai đoạn 1.

Điều kiện tiên quyết

• Một Cloudflare account. Zone đã đăng ký không bắt buộc để bắt đầu, nhưng hữu ích cho ứng dụng Access self-hosted và custom hostname.
• Nhận biết gói: Free / Pay-as-you-go / Enterprise. Enterprise là bắt buộc cho DLP custom profiles, advanced posture providers, và Cloudflare WAN.
• Vai trò admin: Super Administrator (hoặc vai trò Zero Trust đã scoped) để thiết lập.
• Với HTTP filtering / TLS inspection / DLP / AI prompt inspection: cài Cloudflare root CA trên thiết bị và chạy client ở chế độ Gateway with WARP.

---

2. Tạo tài khoản & thiết lập tổ chức

Mục tiêu: Tạo tài khoản, kích hoạt Zero Trust, và chốt team name của tổ chức.

Các bước

1. Tạo / đăng nhập tại https://dash.cloudflare.com; xác minh email tài khoản và bật MFA cấp tài khoản cho admin.
2. Mở Zero Trust (left nav → Zero Trust, hoặc https://one.dash.cloudflare.com). Chọn gói và thêm thanh toán. (Bắt đầu Free/PAYG để đánh giá; đăng ký Enterprise trước khi làm DLP/Cloudflare WAN.)
3. Chọn team name. Đây trở thành team domain: https://<team-name>.cloudflareaccess.com — URL cho App Launcher, đăng nhập Access, và đăng ký client. Đặt/xác minh dưới Settings → Custom Pages / General → Team name.
4. Đặt mặc định tổ chức sớm:
   • Login methods / IdPs → §3.
   • Custom Pages — gắn thương hiệu trang đăng nhập + trang chặn (tạo niềm tin cho người dùng, giảm ticket helpdesk).
   • Account roles — gán vai trò admin theo đặc quyền tối thiểu; giữ ≥2 Super Admins.
   • Logpush — nối log Access + Gateway tới SIEM/kho lưu trữ ngay bây giờ, đừng để sau.
5. Đi qua các luồng Get Started / setup — walkthrough có hướng dẫn ánh xạ tới hướng dẫn này (Replace your VPN, Secure web traffic, Secure DNS for networks, Clientless SSH/RDP, Network-to-network).

Thực hành tốt — team name là mãi mãi. Nó được nhúng vào URL người dùng thấy, cấu hình đăng ký, và chính sách. Chọn giá trị ổn định, dễ nhận (thường là tên viết tắt công ty). Đổi tên sau này làm hỏng bookmark, cấu hình MDM, và trí nhớ thao tác.

Kiểm tra: https://<team-name>.cloudflareaccess.com hiện trang đăng nhập tổ chức; Settings → General hiện đúng gói + team name.

Cạm bẫy: team name dùng tạm; provision DLP/Isolation trước khi entitlement Enterprise có hiệu lực (selector vẫn xám); chỉ một Super Admin (nguy cơ bị khóa).

---

3. Tích hợp nhà cung cấp danh tính (IdP)

Mục tiêu: Xác thực người dùng bằng danh tính doanh nghiệp để mọi chính sách Access và Gateway đánh giá được ai là người dùng và họ thuộc nhóm nào. Danh tính là nền tảng quan trọng nhất — làm đúng trước khi viết chính sách.

Mặc định đã đổi (tháng 5/2026): Cloudflare hiện là IdP mặc định cho các tài khoản Zero Trust mới tạo, thay One-time PIN. Người dùng có thể đăng nhập bằng tài khoản Cloudflare hiện có (có MFA). Với mọi triển khai production bạn vẫn nên kết nối IdP doanh nghiệp để kế thừa người dùng, nhóm và vòng đời thực.

Phương thức đăng nhập được hỗ trợ

• Enterprise SAML / OIDC: Microsoft Entra ID (Azure AD), Okta, Google Workspace, Ping, OneLogin, JumpCloud, ADFS, Centrify, SAML/OIDC generic.
• Consumer / social: Google, GitHub, LinkedIn, Facebook (use case B2B / đối tác).
• Fallback tích hợp sẵn: Cloudflare login (thành viên tài khoản) và One-time PIN (OTP) cho nhà thầu/người ngoài.

Các bước

1. Settings → Authentication → Login methods → Add new → chọn nhà cung cấp.
2. Hoàn tất đăng ký ứng dụng phía provider:
   • OIDC: sao chép Client ID / Secret vào Cloudflare.
   • SAML: trao đổi SSO URL + signing certificate / metadata.
   • Enable group/role claims (Entra ID "groups", Okta "groups", Google "Groups"). Cấp quyền đọc directory mà Cloudflare yêu cầu.
3. Test bằng nút Test tích hợp — nó chạy một lần đăng nhập thật và hiện identity payload (email, groups, claims) mà Cloudflare nhận. Xác nhận groups xuất hiện ở đây trước khi đi tiếp.
4. (Khuyến nghị) Cấu hình SCIM (Entra ID / Okta) để thay đổi user/group và deprovisioning tự lan — và quan trọng hơn, có thể thu hồi session đang hoạt động khi người dùng bị vô hiệu hóa.
5. (Tùy chọn) Thêm nhiều IdP — vd. Entra ID cho nhân viên + OTP cho nhà thầu. Bạn có thể scoped IdP nào áp dụng cho ứng dụng nào sau.

MFA độc lập / toàn cục

Zero Trust → Access controls → Access settings:

• Allow MFA methods, đặt Authentication duration, tùy chọn Use identity provider MFA (tôn trọng claim amr của IdP để tránh hỏi hai lần), và Apply global MFA settings by default. (App Launcher được miễn để người dùng tự đăng ký authenticator.)

Thực hành tốt — danh tính

• SCIM không phải tùy chọn với triển khai thật. Chính sách theo nhóm bị lệch và offboarding thất bại nếu không có. SCIM cũng cho phép thu hồi session khi vô hiệu hóa.
• Xác minh group claims trong output Test — thiếu groups là lý do số 1 khiến "chính sách nhóm của tôi không khớp."
• Giữ một IdP break-glass (OTP hoặc Cloudflare login gắn với admin) để một SAML connector cấu hình sai không khóa bạn ra ngoài.
• Ưu tiên IdP doanh nghiệp hơn consumer cho nhân viên; dành social/OTP cho cộng tác viên bên ngoài và scoped theo từng ứng dụng.

Kiểm tra: IdP Test trả về email + groups mong đợi; một người dùng thí điểm đăng nhập tại team domain qua IdP doanh nghiệp; vô hiệu hóa một user thử trong IdP thu hồi truy cập (chứng minh SCIM).

Cạm bẫy: thiếu group claims; không SCIM (nhóm cũ, offboarding thất bại); không có đăng nhập break-glass; gỡ OTP trước khi SAML được chứng minh.

---

4. Đăng ký thiết bị — Cloudflare One Client (WARP)

Mục tiêu: Kết nối thiết bị được quản lý (và BYOD được chọn) tới Cloudflare để lưu lượng được lọc (Gateway), tunnel tới ứng dụng nội bộ (Access), và đánh giá device posture.

4.1 Khái niệm chính

• Client modes: Gateway with WARP (lọc L3/L7 + DNS đầy đủ — chế độ enterprise chuẩn), Gateway with DoH (chỉ DNS), Secure Web Gateway without DNS filtering, Proxy mode, và Device Information Only (posture, không proxy).
• Device enrollment permissions: quy tắc xác định ai/cái gì được đăng ký thiết bị (vd. email kết thúc @yourco.com, xác thực bởi IdP của bạn). Không có quy tắc khớp → "you are not allowed to enroll."
• Device profiles: thiết lập theo nhóm (mode, split tunnels, switch locks, hành vi captive-portal). Khớp bằng selector để các nhóm thiết bị khác nhau nhận cấu hình khác nhau.
• Device posture: tín hiệu dùng trong chính sách Access/Gateway — phiên bản OS, mã hóa đĩa, firewall, client certificate, danh sách serial-number, cộng EDR bên thứ ba.

4.2 Các bước

1. Định nghĩa enrollment permissions. Settings → WARP Client → Device enrollment permissions → Manage → thêm quy tắc, vd. Include → Emails ending in → @yourco.com, và chọn IdP(s). Đây là cổng cho đăng ký.

2. Cấu hình device profiles. Settings → WARP Client → Device settings:

   • Đặt default profile (mode = Gateway with WARP, allowed protocols, switch locks, auto-connect, captive-portal detection).
   • Thêm group-scoped profiles (vd. servers vs. laptops vs. BYOD) được chọn theo posture/identity.

3. Cấu hình Split Tunnels (theo từng profile):

   • Exclude mode (mặc định, thiết bị quản lý): mọi thứ đi qua WARP trừ các ngoại lệ được liệt kê. Danh sách mặc định gồm 100.64.0.0/10 (CGNAT dùng bởi dịch vụ Cloudflare One). Thực hành tốt: thêm lại mọi dải RFC-1918 / CGNAT bạn thực sự dùng local để tránh xung đột, nhưng ngoài ra hãy giữ tunnel rộng.
   • Include mode (BYOD/thiết bị cá nhân): chỉ IP/domain được liệt kê đi qua WARP — nên Gateway chỉ inspect lưu lượng công ty và lưu lượng cá nhân vẫn riêng tư. Đây là posture khuyến nghị cho BYOD và giảm lo ngại về riêng tư.

4. Phân phối Cloudflare root CA (bắt buộc cho HTTP filtering, TLS decryption, DLP, AI prompt inspection). Đẩy chứng chỉ do Cloudflare quản lý (hoặc của bạn) tới trust store OS/trình duyệt qua MDM.

5. Triển khai client:

   • Thí điểm (thủ công): tải từ trang downloads Cloudflare One; người dùng Login with Cloudflare Zero Trust và nhập team name.
   • Production (MDM — Intune, Jamf, Kandji, Workspace ONE, SCCM): đẩy với tham số đã đặt sẵn cho cài đặt im lặng, đã xác thực trước. Tham số MDM chính:

   Tham số	Mục đích / giá trị thực hành tốt
   organization	Team name của bạn — bắt buộc cho managed enrollment
   auth_client_id + auth_client_secret	Service-token enrollment — đăng ký không cần login tương tác (lý tưởng cho fleet/server)
   service_mode	warp (Gateway with WARP) cho enterprise chuẩn
   onboarding	false → ẩn màn hình chào cho triển khai im lặng
   auto_connect	0 để kết nối ngay (không idle timeout trước khi kết nối)
   display_name / support_url	Thương hiệu + liên kết helpdesk người dùng thấy trong client
   unique_client_id	Định danh thiết bị ổn định cho ánh xạ posture/serial
   enable_post_quantum	Bật crypto tunnel post-quantum khi được hỗ trợ
   organization_configs / configs[]	Chuyển multi-org / config (client mới hơn)

6. Bật device posture checks. Settings → WARP Client → Device posture (hoặc Reusable components → Posture checks). Posture gồm ba nhóm:

   • Client checks (chạy bởi Cloudflare One Client): phiên bản OS, mã hóa đĩa, firewall, client certificate, sự hiện diện file/registry/application, danh sách serial-number, domain-joined.
   • Service-to-service (nhà cung cấp bên thứ ba): CrowdStrike, SentinelOne, Microsoft Intune, Tanium, v.v. — khớp cả trên thiết bị không agent qua ánh xạ email.
   • Access integrations (chỉ ứng dụng Access, không dùng được trong chính sách Gateway).

Thực hành tốt — thiết bị

• Mặc định Exclude mode cho thiết bị quản lý, Include mode cho BYOD. Đừng chạy thiết bị cá nhân ở full-tunnel Exclude mode — nó bắt lưu lượng cá nhân và tạo rủi ro riêng tư/pháp lý.
• Triển khai root CA trước khi bật TLS decryption. Nếu bạn bật decryption trước, HTTPS gãy trên toàn fleet.
• Dùng service-token (auth_client_id/secret) enrollment cho server và fleet lớn để thiết bị đăng ký im lặng và nhất quán.
• Đặt posture thành "latest stable" chứ không "absolute latest." vd. macOS ≥ 15.1 (một phiên bản bạn đã qualify), để một bản OS ra cùng ngày không khóa mọi người.
• Tanium posture không được hỗ trợ trong chính sách Gateway — chỉ trong Access. Lên kế hoạch tương ứng.
• Phân giai đoạn device profiles: bắt đầu Device Information Only (posture, không proxy) để xác thực tín hiệu, rồi chuyển nhóm thí điểm sang Gateway with WARP.

Kiểm tra: thiết bị thí điểm hiện Connected, đúng profile được áp dụng; đăng ký xuất hiện dưới My Team → Devices; một posture check (vd. mã hóa đĩa) báo đúng; WARP diagnostics xác nhận enrollment.

Cạm bẫy: quên root CA (HTTPS gãy / DLP im lặng mù); mục Include-mode quá rộng blackhole lưu lượng local khi chuyển Wi-Fi↔Ethernet; không có quy tắc enrollment-permission.

---

5. ZTNA — Access (ứng dụng & chính sách)

Mục tiêu: Thay VPN cho truy cập ứng dụng. Xuất bản ứng dụng nội bộ và SaaS sau Access để mọi request được xác thực và ủy quyền theo từng ứng dụng — đặc quyền tối thiểu, không tin cậy mạng ngầm.

5.1 Kết nối ứng dụng tới Cloudflare (chọn connector)

• Cloudflare Tunnel (khuyến nghị cho ứng dụng nội bộ): cài cloudflared trên host tới được ứng dụng → Networks → Tunnels → Create → ánh xạ public hostname (wiki.yourco.com → http://localhost:3000) hoặc định tuyến một private CIDR. Không mở cổng inbound trên firewall. (Chỉ cloudflared có thể proxy public hostname tới origin nội bộ.)
• Ứng dụng SaaS: tích hợp qua SAML/OIDC — Access trở thành lớp danh tính phía trước ứng dụng SaaS.
• Mạng / hạ tầng nội bộ: định tuyến CIDR nội bộ qua tunnel; dùng Access for Infrastructure cho SSH/RDP/VNC, tùy chọn clientless (render trên trình duyệt).

5.2 Thêm một Access application

1. Zero Trust → Access → Applications → Add an application.
2. Type: Self-hosted (ứng dụng web), SaaS, Private Network, hoặc Infrastructure.
3. Với Self-hosted: đặt name, public hostname/path, các IdPs được phép, session duration, App Launcher visibility, thiết lập CORS/cookie.

5.3 Viết chính sách Access (lõi của ZTNA)

Chính sách đánh giá từ trên xuống; khớp đầu tiên thắng. Mỗi chính sách = một Action + rules.

• Actions: Allow · Block · Bypass (không auth — tránh với ứng dụng nhạy cảm) · Service Auth (máy-với-máy qua mTLS hoặc service tokens, không trang đăng nhập).
• Rule types: Include (khớp ≥1), Require (khớp tất cả), Exclude (phải KHÔNG khớp — Exclude ghi đè mọi thứ).
• Selectors: emails / email domains, IdP groups, country, IP/CIDR, device posture, gateway (đi qua Gateway), mTLS cert, Lists, auth method/MFA, Cloudflare Account Member.

Ví dụ đã làm sẵn — "Allow Engineering trên thiết bị tuân thủ, yêu cầu MFA":

Rule	Selector	Operator	Value
Include	IdP group	in	Engineering
Require	Device posture	in	Disk encryption, Firewall on
Require	Authentication method	in	MFA
Exclude	Email	in	List: Offboarding

5.4 Khối xây dựng tái sử dụng (làm thế này, không viết rule từng ứng dụng)

• Access Groups (Access controls → Policies → Groups): khối rule có tên, tái sử dụng được (vd. "Secure employees" = thành viên nhóm + 3 posture checks). Tham chiếu cùng nhóm trên nhiều ứng dụng — đổi một lần, áp dụng mọi nơi.
• Lists (Reusable components → Lists): nhập emails (nhà thầu, người dùng rủi ro cao) hoặc serial number thiết bị đã duyệt; cập nhật qua UI hoặc API để tích hợp với hệ thống HR/MDM.
• Reusable posture checks: định nghĩa một lần, tham chiếu trong cả Access và Gateway.

5.5 Mẫu nâng cao

• RBI fallback cho thiết bị không quản lý: giữ Access Allow bình thường cho nhân viên tuân thủ, và thêm chính sách Gateway HTTP Isolate để người dùng vào cùng URL ứng dụng từ thiết bị không tuân thủ nhận phiên remote-browser thay vì bị chặn.
• App Launcher: cổng duy nhất (<team-name>.cloudflareaccess.com) liệt kê các ứng dụng mà từng người dùng được phép.
• MFA theo ứng dụng / session ngắn: ghi đè MFA toàn cục và đặt hết hạn session immediate cho ứng dụng crown-jewel.

Thực hành tốt — ZTNA

• Áp dụng quy ước đặt tên chính sách từ ngày đầu (vd. Allow — Full-time employees, Block — High-risk users). Bạn sẽ tái sử dụng các tên này trên hàng chục ứng dụng; nhất quán làm audit trở nên đơn giản.
• Default-deny. Kết thúc danh sách chính sách mỗi ứng dụng bằng lưới an toàn ưu tiên thấp Block — everyone; đặt chính sách Exclude/Block phía trên Allow rộng (thứ tự quan trọng).
• Session duration = đặc quyền tối thiểu theo thời gian. 24h là điển hình; đặt immediate/short cho ứng dụng nhạy cảm để posture + identity được xác minh lại liên tục.
• Dùng Require gateway để buộc lưu lượng đi qua Gateway (qua client, Browser Isolation, hoặc một site Cloudflare WAN) — linh hoạt hơn chỉ yêu cầu agent, và đảm bảo ghi log/lọc.
• Dùng Service Auth (tokens/mTLS) cho automation/API — không bao giờ dùng chính sách Bypass.
• Di chuyển ứng dụng VPN từng ứng dụng một, kiểm tra, rồi gỡ VPN concentrator (xem lộ trình học Replace your VPN).

Kiểm tra: người dùng được phép tới được ứng dụng sau khi đăng nhập IdP; người không thuộc nhóm bị chặn; Access → Logs / Logpush hiện allow/block kèm ngữ cảnh identity + posture.

Cạm bẫy: Bypass trên ứng dụng nhạy cảm; Allow rộng đặt trên một Block cần thiết; quên default-deny; sprawl rule từng ứng dụng thay vì Access Groups.

---

6. Secure Web Gateway (Gateway)

Mục tiêu: Inspect và lọc lưu lượng DNS, network (L4) và HTTP (L7) chiều ra — chặn mối đe dọa, thực thi acceptable-use, và tạo điểm thực thi mà DLP và AI controls cắm vào. Xây chính sách theo ba lớp, theo thứ tự này (dashboard: Gateway → Firewall Policies, ngày càng nằm dưới Traffic policies).

6.1 Chính sách DNS — bắt đầu ở đây (giá trị nhanh nhất, rủi ro thấp nhất)

1. Gateway → Firewall Policies → DNS → Add a policy.
2. Chặn theo security categories (malware, phishing, C2, DGA, new domains) và content categories theo chính sách acceptable-use của bạn.
3. DNS Locations (Gateway → DNS Locations): với văn phòng/mạng không có client, tạo một location và trỏ resolver tới endpoint IPv4/IPv6, DoH, hoặc DoT được gán — lọc mọi DNS từ site đó mà không cài client.

Thực hành tốt: Triển khai DNS filtering toàn tổ chức trước — nó hoạt động có hoặc không có client, không làm gãy HTTPS, và ngay lập tức chặn phần lớn malware/phishing theo domain. Đây là thực thi giai đoạn 1 an toàn nhất.

6.2 Chính sách Network (L4)

Gateway → Firewall Policies → Network. Kiểm soát theo IP, port, protocol và application — vd. chặn SMTP outbound từ client, hạn chế egress RDP/SSH, hoặc allow-list đích cụ thể. Cần client ở proxy mode (hoặc on-ramp Cloudflare WAN).

6.3 TLS decryption + chính sách HTTP (L7)

1. Bật TLS decryption (Settings → Network → Firewall / TLS decryption). Yêu cầu Cloudflare root CA trên thiết bị (§4). Không có nó, HTTP/DLP/AI inspection không thấy body HTTPS.
2. Tạo ngoại lệ Do Not Inspect trước khi thực thi rộng:
   • Gateway duy trì sẵn loại ứng dụng "Do Not Inspect" cho ứng dụng không tương thích decryption — chọn cả loại trong chính sách Do Not Inspect và Cloudflare sẽ cập nhật.
   • Bật tích hợp lưu lượng Microsoft 365 one-click để tự bypass mọi domain/IP M365.
   • Một số sản phẩm Google dùng chứng chỉ nhúng và cần rule Do Not Inspect (hoặc cấu hình ứng dụng tin Cloudflare cert để giữ visibility).
   • Thêm ứng dụng certificate-pinned (ngân hàng, một số ứng dụng native/mobile) vào Do Not Inspect.
3. Gateway → Firewall Policies → HTTP → Add a policy. Lọc theo application / app type (danh mục ứng dụng chi tiết), domain, URL, content category, file type, chiều request/response, DLP Profile, và selector identity/device.
4. Actions: Allow, Block, Isolate (Browser Isolation), Do Not Inspect, Do Not Scan (bỏ DLP trên ứng dụng tin cậy).
5. Application granular controls: cho phép một ứng dụng nhưng hạn chế hành động cụ thể — vd. allow ChatGPT nhưng block uploads, allow xem Google Drive nhưng block downloads tới tenant cá nhân. Đây cũng là móc cho AI controls (§7).

Thực hành tốt — Gateway

• Thứ tự: chung → cụ thể, với ngoại lệ Do Not Inspect / Bypass gần phía trên, Allow/Block rộng phía dưới. Chính sách đánh giá từ trên xuống.
• Phân giai đoạn TLS decryption: bật chỉ cho nhóm thí điểm, xác nhận HTTPS hoạt động + log hiện chi tiết đã decrypt, rồi mở rộng. Có danh sách Do Not Inspect sẵn trước.
• Scoped các danh mục nhạy cảm về riêng tư (sức khỏe, tài chính) — cân nhắc Do Not Inspect cho chúng để đáp ứng nghĩa vụ riêng tư/pháp lý.
• Dùng dashboard HTTP analytics để theo dõi tỷ lệ Allowed / Isolated / Do-Not-Inspect và phát hiện cấu hình sai.

Kiểm tra: duyệt một danh mục đã biết bị chặn → block page của Cloudflare; Gateway → Logs hiện quyết định DNS/Network/HTTP và chi tiết HTTPS đã decrypt (chứng minh CA + decryption).

Cạm bẫy: chính sách HTTP/Network không làm gì với người dùng không có client/on-ramp (DNS là ngoại lệ); decryption làm gãy ứng dụng cert-pinned nếu bạn bỏ qua Do Not Inspect; decrypt danh mục nhạy cảm mà không có review riêng tư.

---

7. Data Loss Prevention (DLP)

Mục tiêu: Phát hiện và kiểm soát dữ liệu nhạy cảm (PII, credentials, tài chính, source code, pattern tùy chỉnh) đi qua lưu lượng Gateway HTTP. Yêu cầu Zero Trust Enterprise + quyền admin, và phụ thuộc TLS decryption (§6.3).

7.1 DLP hoạt động thế nào

• Profiles định nghĩa cái gì cần phát hiện; detection entries là các pattern (detector định sẵn, custom regex, dictionaries, Exact Data Match (EDM), Microsoft Purview (MIP) sensitivity labels). DLP quét HTTP body (uploads/downloads/posts/chat) — không phải headers.

7.2 Các bước

1. Chọn hoặc xây một profile. Zero Trust → DLP → DLP Profiles.

   • Predefined profiles: vd. Credentials and Secrets, Financial Information, PII. Bật/tắt từng entry để tinh chỉnh phạm vi. Lưu ý: hầu hết predefined profile khớp khi bất kỳ entry đã bật khớp; profile PII Record đặc biệt — nó yêu cầu ≥3 entry duy nhất ở gần nhau trước khi kích hoạt (kiểm soát false-positive tích hợp).
   • Custom profiles: kết hợp entries, thêm custom regex/dictionaries, EDM datasets, hoặc MIP labels.

2. Tinh chỉnh độ nhạy phát hiện:

   • Match count — số khớp tối thiểu trước khi một action kích hoạt (đặt 10 → cần 11+ khớp). Giảm nhiễu trên tài liệu có pattern rải rác.
   • Confidence threshold (Low / Medium / High) — DLP chấm detection bằng proximity keywords (vd. từ "SSN" gần một số 9 chữ số làm tăng confidence). Ngưỡng cao hơn = ít false positive hơn.
   • AI context analysis — mô hình pretrained điều chỉnh confidence từ ngữ cảnh xung quanh (chỉ HTTP/HTTPS). Bật trong DLP settings.
   • OCR — phát hiện văn bản nhạy cảm trong ảnh (.jpg/.png, 4 KB–1 MB). Bật trong DLP settings (OCR cấp profile đang deprecated).

3. Thực thi qua chính sách Gateway HTTP bằng selector DLP Profile. Ví dụ đã làm sẵn:

   Selector	Operator	Value	Logic	Action
   Destination Domain	in	dropbox.com, wetransfer.com	And	Block
   DLP Profile	in	Financial Information (High)	And
   User Group	in	Finance

Thực hành tốt — DLP

• Monitor trước, thực thi sau. Bắt đầu mọi profile với chính sách Allow + log để lấy baseline detection 1–2 tuần, rồi thêm Block cho đích/nhóm rủi ro cao cụ thể.
• Mẫu confidence khuyến nghị = hai chính sách HTTP: Chính sách 1 dùng profile Low-confidence với Allow (log) để có visibility; Chính sách 2 dùng profile High-confidence với Block để thực thi. Bạn có telemetry đầy đủ mà không over-block.
• Luôn scoped theo đích, ứng dụng, hoặc nhóm. Một profile Credentials and Secrets rộng áp dụng cho mọi lưu lượng sẽ ngập false positive (Google, Zoho, ứng dụng nội bộ).
• Dùng "Do Not Scan" cho ứng dụng tin cậy, nhiễu; dùng match count + confidence để chỉnh độ chính xác.
• Không decryption = không DLP. Xác nhận TLS decryption + root CA trước khi kỳ vọng detection.

Kiểm tra: upload một pattern thử vô hại (SSN giả / chuỗi thẻ tín dụng thử) tới đích được giám sát → detection xuất hiện trong Gateway → Logs / DLP với profile đã khớp; selector DLP Profile hiện diện (chứng minh Enterprise + quyền).

Cạm bẫy: profile quá rộng; thiếu decryption (under-detection im lặng); thực thi Block trước khi lấy baseline; "DLP Profile selector missing" = gói không phải Enterprise hoặc vai trò không đủ.

---

8. Kiểm soát an toàn AI

Mục tiêu: Quản trị việc dùng generative AI — phát hiện shadow AI, ngăn dữ liệu nhạy cảm rò vào prompt, và bảo vệ ứng dụng AI bạn xây khỏi mối đe dọa đặc thù LLM. Cloudflare cung cấp các lớp bổ trợ; triển khai theo thứ tự dưới đây.

8.1 Phát hiện shadow AI (visibility trước)

• Gateway → analytics → Shadow IT Discovery: xem ứng dụng AI/SaaS nào người dùng truy cập, đánh dấu approved/unapproved, và định lượng mức dùng. Đây là cơ sở bằng chứng cho chính sách acceptable-use AI của bạn.

8.2 Kiểm soát việc dùng ứng dụng AI bằng Gateway (ngăn rò rỉ)

• Trong một Gateway HTTP policy, nhắm ứng dụng AI (ChatGPT, Google Gemini, Claude, Perplexity, …) và dùng Application granular controls để cho phép ứng dụng nhưng chặn hành động rủi ro (file uploads, gửi prompt) thay vì chặn hẳn.
• Thêm selector DLP Profile vào cùng chính sách để quét prompt/uploads tìm dữ liệu nhạy cảm.

8.3 AI Prompt Protection (DLP cho prompt)

DLP inspect sẵn user prompts tới các ứng dụng AI phổ biến và phân loại chúng:

• Prompt detection cho Google Gemini, ChatGPT, Claude, Perplexity.
• Topic classification: chủ đề Content (PII, Source Code, Credentials & Secrets, Financial Information, Customer Data) và chủ đề Intent (nỗ lực jailbreak, yêu cầu mã độc, nỗ lực trích PII).
• Predefined "AI Prompt" profiles (vd. AI Prompt: AI Security, AI Prompt: PII) gói chúng lại để rollout nhanh. Cấu hình dưới DLP → Detection entries → AI prompt topics, rồi tham chiếu trong chính sách Gateway HTTP.

8.4 DLP for AI Gateway (bảo vệ lưu lượng ứng dụng AI của bạn)

• Nếu bạn chạy AI qua Cloudflare AI Gateway, bật DLP for AI Gateway (AI Gateway → your gateway → features → set up DLP). Nó quét văn bản request tới nhà cung cấp AI và các response tìm dữ liệu nhạy cảm — không yêu cầu Gateway HTTP filtering hay TLS decryption. Lý tưởng cho việc dùng AI theo API / programmatic.

8.5 AI Security for Apps (WAF — cho AI bạn phơi bày)

• Với ứng dụng AI bạn xây và phơi bày, AI Security for Apps (trong WAF) phát hiện mối đe dọa đặc thù LLM — prompt injection, chủ đề không an toàn. Nó bổ trợ DLP: AI Security for Apps xử lý tấn công tầng mô hình; DLP xử lý phát hiện dữ liệu nhạy cảm. Dùng cả hai trên lưu lượng AI.

8.6 MCP server portals (quản trị AI agents/tools)

• Với tổ chức phơi bày server/tool Model Context Protocol (MCP) tới AI agents, Access → AI controls → MCP server portals cho phép bạn xuất bản, cổng kiểm soát, và đổi tên tools/prompts sau chính sách Access.

Rollout AI khuyến nghị: Discover (8.1) → Monitor prompt với AI DLP profiles ở chế độ log (8.3) → Enforce granular controls + DLP block trên ứng dụng được phép (8.2) → thêm DLP for AI Gateway cho AI programmatic (8.4) và AI Security for Apps cho ứng dụng bạn phơi bày (8.5).

Thực hành tốt — đừng hard-block AI. Chặn hẳn đẩy người dùng sang thiết bị/tài khoản cá nhân (shadow AI tệ hơn). Ưu tiên allow + granular control + DLP. Khớp lớp với cách tiêu thụ: prompt inspection (8.2/8.3) cần decryption + client; quản trị API (8.4) thì không.

Cạm bẫy: chặn thay vì quản trị; kỳ vọng prompt inspection mà không có decryption; xem AI Security for Apps và DLP là thay thế lẫn nhau (chúng bổ trợ).

---

9. Cloudflare WAN

Mục tiêu: Kết nối toàn bộ site, data center và mạng cloud tới mạng Cloudflare như một on-ramp — định tuyến lưu lượng chi nhánh/DC qua Cloudflare cho bảo mật (Magic Firewall + Gateway) và kết nối, không cần MPLS hay VPN full-mesh. Cloudflare WAN là subscription mạng Enterprise. Gốc tài liệu: developers.cloudflare.com/cloudflare-wan/.

9.1 Chọn on-ramp

On-ramp	Phù hợp nhất	Ghi chú
Cloudflare WAN Connector (appliance HW/ảo)	Văn phòng chi nhánh; đơn giản nhất	Nhẹ/zero-touch; bootstrap qua DHCP hoặc IP tĩnh (serial console)
IPsec tunnels	Router/firewall hiện có	Theo chuẩn; hỗ trợ BGP
GRE tunnels	Data center / thông lượng cao	Hỗ trợ BGP
CNI / Direct CNI (CNI-P)	Interconnect riêng, băng thông cao	Cross-connect vật lý/ảo tới Cloudflare
Multi-Cloud Networking (MNC)	VPC AWS/Azure/GCP	Tự động hóa tạo on-ramp cloud

9.2 Pre-flight: MSS clamping (làm trước khi bật Cloudflare WAN)

Cloudflare đóng gói packet (header mới), nên bạn phải đặt TCP MSS clamping trên edge để tránh black-hole packet lớn/HTTPS:

• GRE tunnels: clamp interface GRE nội bộ ở 1,436 bytes.
• IPsec tunnels: clamp tối đa 1,360 bytes (thấp hơn, vì interface vật lý thấy packet đã mã hóa).
• Chi tiết từng vendor khác nhau (Cisco ip tcp adjust-mss, Juniper tcp-mss); một số thiết bị tự đặt khi tunnel lên — hãy xác minh, đừng giả định.

9.3 Các bước thiết lập

1. Xác nhận subscription (làm việc với account team).
2. Tạo on-ramp dưới Cloudflare WAN:
   • Connector: đăng ký appliance, cắm WAN/LAN, adopt nó (nó tự xây tunnel dư thừa tới Cloudflare). Cấu hình LAN subnet/DHCP.
   • IPsec/GRE: thêm tunnel với endpoint thiết bị + địa chỉ interface, pre-shared key (IPsec), và thiết lập tunnel health-check. Nhân bản cấu hình trên router/firewall của bạn.
3. Cấu hình routing:
   • Static routes — thêm prefix site/DC vào Magic routing table với tunnel làm next hop; đặt priority/weight cho chia tải ECMP và failover.
   • BGP (over GRE/IPsec) — thiết lập eBGP (MD5 auth) để trao đổi route động và tự thêm/gỡ subnet kèm phát hiện lỗi.
4. Thêm bảo mật: áp dụng rule Magic Firewall (L3/L4), và định tuyến lưu lượng site ra Internet qua Gateway để site không client nhận cùng chính sách DNS/Network/HTTP/DLP như người dùng có client.
5. Cấu hình tunnel health checks + alerts (dashboard / GraphQL) để bạn được báo trước khi người dùng cảm thấy outage.

Thực hành tốt — Cloudflare WAN

• Luôn xây dư thừa: hai tunnel từ hai router riêng. Đầu Cloudflare là anycast — một tunnel đã tới mọi data center Cloudflare, nên độ bền là về phía của bạn. Dual router bảo vệ khỏi lỗi phần cứng on-prem.
• Đặt MSS clamping trước. Triệu chứng kinh điển khi bỏ sót clamp: http:// thường hoạt động nhưng https:// treo. Test bằng curl http://ifconfig.me vs curl https://ifconfig.me.
• Lên kế hoạch không gian IP trước khi thêm route — subnet chồng lấn giữa các site làm gãy Magic routing.
• Ưu tiên BGP cho môi trường đa site/động để thay đổi route không cần sửa tay; dùng static routes cho site đơn giản, ổn định.
• Đừng quên Magic Firewall — lưu lượng mạng không được lọc cho đến khi bạn thêm rule, ngay cả khi lưu lượng client (WARP) đã bị khóa.
• Bật tunnel health alerts và theo dõi băng thông/health qua GraphQL analytics.

Kiểm tra: tunnel/Connector hiện healthy với health check đạt; reachability site-to-site và site-to-private-resource hoạt động; route xuất hiện trong Magic routing table; https://ifconfig.me thành công (MSS đúng); failover hoạt động khi bạn tắt một tunnel; lưu lượng site ra Internet được Gateway lọc.

Cạm bẫy: bỏ sót/sai MSS clamp (HTTPS treo); tunnel một router (không dư thừa thật); subnet chồng lấn; routing bất đối xứng/lệch MTU trên GRE/IPsec; lưu lượng mạng không lọc (không có rule Magic Firewall).

---

10. Kế hoạch triển khai theo giai đoạn

Thí điểm mỗi giai đoạn với một nhóm/site nhỏ, kiểm tra theo tiêu chí hoàn thành, rồi mở rộng.

Giai đoạn	Trọng tâm	Tiêu chí hoàn thành
0 — Foundation	Account, gói, team name, vai trò admin + break-glass, IdP + SCIM đã kết nối và test, Logpush đã nối	IdP Test trả về groups; SCIM deprovision hoạt động; ≥2 Super Admins
1 — Identity + DNS	DNS filtering toàn tổ chức (DNS Locations), Access trên 1–2 ứng dụng rủi ro thấp qua Tunnel	Block page hoạt động; người dùng thí điểm tới được ứng dụng Access qua IdP doanh nghiệp
2 — Devices	Client tới nhóm thí điểm (Info-only → Gateway with WARP), root CA, posture checks, BYOD trên Include split	Thiết bị thí điểm Connected; posture báo đúng
3 — Gateway L4/L7	Chính sách Network + HTTP, TLS decryption phân giai đoạn + Do Not Inspect (M365/cert-pinned), Isolate ứng dụng rủi ro	HTTPS được decrypt trong log; danh mục AUP bị chặn; không ứng dụng bị gãy
4 — ZTNA expansion	Di chuyển ứng dụng VPN sang Access + Tunnel từng ứng dụng; default-deny + posture; gỡ VPN	VPN đã nghỉ cho ứng dụng đã di chuyển; chính sách đặc quyền tối thiểu qua Access Groups
5 — DLP	DLP monitor mode → Low-confidence Allow/log + High-confidence Block trên luồng rủi ro cao	Detection đã có baseline; chính sách block đã scoped đang live
6 — AI controls	Phát hiện shadow-AI → AI prompt DLP (monitor) → thực thi granular; thêm DLP-for-AI-Gateway / AI Security for Apps	Việc dùng AI hiển thị; chính sách prompt nhạy cảm được thực thi
7 — Cloudflare WAN	MSS clamp → tunnel dual-router → route (static/BGP) → Magic Firewall → định tuyến tới Gateway; failover đã test	Tunnel healthy; lưu lượng site được lọc; failover đã xác minh

Danh sách kiểm tra go-live

• [ ] Team name đã chốt; IdP + SCIM doanh nghiệp đã kết nối, test, group claims đã xác minh
• [ ] Đăng nhập admin break-glass được giữ; ≥2 Super Admins
• [ ] Client triển khai qua MDM (service-token enrollment) với root CA; profile default + group + BYOD đã đặt
• [ ] Posture checks đã bật (OS stable mới nhất) và được tham chiếu qua Access Groups
• [ ] Chính sách DNS → Network → HTTP đang live; TLS decryption đã phân giai đoạn; Do Not Inspect (M365 + cert-pinned) đã cấu hình
• [ ] Ứng dụng Access đã di chuyển với default-deny, posture + MFA, đặt tên nhất quán, nhóm tái sử dụng
• [ ] DLP đã tinh chỉnh (match count + confidence); monitor → enforce; scoped theo đích/nhóm
• [ ] Shadow-AI đã review; AI prompt DLP + granular controls đã thực thi; DLP-for-AI-Gateway khi áp dụng
• [ ] Cloudflare WAN: MSS đã clamp, tunnel dual-router healthy, route đúng, rule Magic Firewall đã áp dụng, failover đã test
• [ ] Logpush tới SIEM đang live; tunnel health + cảnh báo chính sách được chuyển tới đúng admin

---

11. Kiểm tra, giám sát & khắc phục sự cố

Khu vực	Xem ở đâu	Kiểm tra nhanh
Identity	IdP Test; Access logs	Login trả về email + groups mong đợi; vô hiệu hóa trong IdP thu hồi (SCIM)
Devices	My Team → Devices; client diagnostics	Thiết bị Connected, đúng profile được áp dụng
Posture	Trạng thái posture checks	Tín hiệu (vd. mã hóa đĩa) báo đúng
Access	Access → Logs, Logpush	Allow/Block kèm ngữ cảnh identity + posture
Gateway	Gateway → Logs / HTTP analytics	Quyết định DNS/Network/HTTP; HTTPS hiện chi tiết decrypted
DLP	Gateway → Logs / DLP	Pattern thử kích hoạt đúng profile/confidence
AI	Shadow IT Discovery; Gateway logs	Ứng dụng AI hiển thị; chính sách prompt kích hoạt
Cloudflare WAN	Dashboard Cloudflare WAN; health checks; GraphQL	Tunnel healthy; route hiện diện; https://ifconfig.me OK; failover hoạt động

Thứ tự khắc phục sự cố (nguyên nhân gốc nhanh nhất trước):

1. Client đã connected và đúng profile được áp dụng chưa?
2. Root CA đã cài chưa (cho HTTPS / DLP / AI prompt inspection)?
3. Thứ tự chính sách có đặt Allow rộng trên một Block cần thiết (hoặc thiếu default-deny) không?
4. IdP groups có trong identity payload không (chạy lại IdP Test)?
5. Tính năng có yêu cầu Enterprise không (DLP custom profiles, advanced posture, Cloudflare WAN)?
6. Cloudflare WAN HTTPS treo / truyền lớn thất bại → MSS clamp sai (GRE 1,436 / IPsec 1,360).
7. Ứng dụng gãy sau decryption → thêm vào Do Not Inspect (cert pinning / chứng chỉ nhúng).

Xuất log Access + Gateway qua Logpush tới SIEM để tinh chỉnh liên tục, phát hiện bất thường, và audit.

---

12. Tóm tắt thực hành tốt (tham chiếu một màn hình)

Lĩnh vực	Làm thế này	Tránh
Rollout	Dần dần, có thí điểm, monitor-trước-khi-enforce	Big-bang; thực thi chính sách chưa test trên toàn fleet
Identity	IdP doanh nghiệp + SCIM + group claims đã xác minh; đăng nhập break-glass	Chính sách nhóm không có SCIM; không có admin dự phòng
Devices	Exclude (managed) / Include (BYOD); root CA trước; MDM enroll bằng service-token; posture stable mới nhất	Full-tunnel trên thiết bị cá nhân; decrypt trước CA; posture OS bleeding-edge
ZTNA	Default-deny; Access Groups + Lists; quy ước đặt tên; session ngắn cho ứng dụng nhạy cảm; Require gateway	Bypass trên ứng dụng nhạy cảm; sprawl rule từng ứng dụng; Allow trên Block
Gateway	DNS trước; phân giai đoạn TLS decryption; Do Not Inspect (M365/cert-pinned) sẵn trước	Decrypt mọi thứ; bỏ qua ứng dụng cert-pinned
DLP	Monitor → enforce; mẫu hai chính sách Low-Allow/High-Block; scoped chặt; match count + confidence	Profile rộng trên mọi lưu lượng; Block trước khi lấy baseline; kỳ vọng DLP mà không decryption
AI	Discover → monitor → quản trị bằng granular controls + DLP; DLP-for-AI-Gateway cho API	Hard-block ứng dụng AI (đẩy shadow AI)
Cloudflare WAN	MSS clamp trước; tunnel dual-router; BGP cho site động; Magic Firewall + định tuyến tới Gateway	Tunnel một router; subnet chồng lấn; bỏ MSS

---

13. Liên kết tham chiếu

• Cloudflare One (Zero Trust) — https://developers.cloudflare.com/cloudflare-one/
• Replace your VPN (learning path) — https://developers.cloudflare.com/learning-paths/replace-vpn/
• SASE reference architecture — https://developers.cloudflare.com/reference-architecture/architectures/sase/
• Designing ZTNA access policies — https://developers.cloudflare.com/reference-architecture/design-guides/designing-ztna-access-policies/
• Identity providers — https://developers.cloudflare.com/cloudflare-one/integrations/identity-providers/
• Cloudflare One Client (WARP) & MDM parameters — https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/deployment/mdm-deployment/parameters/
• Split tunnels — https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/route-traffic/split-tunnels/
• Posture checks — https://developers.cloudflare.com/cloudflare-one/reusable-components/posture-checks/
• Access (ZTNA) controls — https://developers.cloudflare.com/cloudflare-one/access-controls/
• Access Groups — https://developers.cloudflare.com/cloudflare-one/access-controls/policies/groups/
• Cloudflare Tunnel — https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/
• Gateway / Traffic policies — https://developers.cloudflare.com/cloudflare-one/traffic-policies/
• TLS decryption + Do Not Inspect — https://developers.cloudflare.com/cloudflare-one/traffic-policies/http-policies/tls-decryption/
• Data Loss Prevention — https://developers.cloudflare.com/cloudflare-one/data-loss-prevention/
• DLP profile settings (match count / confidence / OCR / AI context) — https://developers.cloudflare.com/cloudflare-one/data-loss-prevention/dlp-profiles/advanced-settings/
• AI controls — https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/
• DLP for AI Gateway — https://developers.cloudflare.com/ai-gateway/features/dlp/
• AI Security for Apps (WAF) — https://developers.cloudflare.com/waf/detections/ai-security-for-apps/
• Holistic AI security (learning path) — https://developers.cloudflare.com/learning-paths/holistic-ai-security/
• Cloudflare WAN / WAN — https://developers.cloudflare.com/cloudflare-wan/
• Cloudflare WAN get started + MSS — https://developers.cloudflare.com/cloudflare-wan/get-started/
• Cloudflare WAN routes (static + BGP) — https://developers.cloudflare.com/cloudflare-wan/configuration/how-to/configure-routes/
• MTU / MSS reference — https://developers.cloudflare.com/cloudflare-wan/reference/mtu-mss/

---

Phụ lục — Thuật ngữ

Thuật ngữ	Ý nghĩa
Cloudflare One	Nền tảng SASE của Cloudflare (Zero Trust + dịch vụ mạng)
Cloudflare One Client	Agent trên thiết bị (trước đây là WARP client)
Team name / team domain	Định danh tổ chức <name>.cloudflareaccess.com của bạn
ZTNA	Zero Trust Network Access — truy cập theo ứng dụng, nhận biết danh tính (Access)
SWG	Secure Web Gateway — lọc DNS/network/HTTP (Gateway)
Access Group	Khối rule chính sách tái sử dụng, được tham chiếu trên nhiều ứng dụng
Posture	Tín hiệu bảo mật thiết bị dùng trong chính sách (client / service-to-service / Access integrations)
Do Not Inspect	Action/loại ứng dụng Gateway bỏ qua TLS decryption cho ứng dụng không tương thích
DLP confidence	Điểm Low/Medium/High dựa trên proximity keywords gần một detection
Match count	Số khớp DLP tối thiểu trước khi một action kích hoạt
On-ramp	Cách lưu lượng tới Cloudflare (Client, Tunnel, IPsec/GRE, Connector, CNI, MNC)
MSS clamping	Giới hạn kích thước segment TCP để vừa header tunnel (GRE 1,436 / IPsec 1,360 bytes)
Magic routing table	Routing phía Cloudflare cho Cloudflare WAN/Transit
MNC	Multi-Cloud Networking — on-ramp cloud tự động
MCP	Model Context Protocol — giao diện cho AI agents/tools

Soạn 2026-06-08. Dựa trên tài liệu Cloudflare hiện hành (Cloudflare One, Cloudflare WAN, và kiến trúc tham chiếu SASE). Xác minh entitlement gói và điều hướng dashboard sống trước khi triển khai production, vì Cloudflare phát hành thay đổi thường xuyên.

1 Account/Org → 2 Identity → 3 Devices (Cloudflare One Client)
   → 4 ZTNA (Access) → 5 Gateway (DNS → Network → HTTP → TLS)
      → 6 DLP → 7 AI controls → 8 Cloudflare WAN

   Managed device ─Client─┐
   BYOD (Include split) ──┤        ┌──────────────────────────────────────────────┐
   Unmanaged (clientless)─┤        │            CLOUDFLARE GLOBAL EDGE             │   Internet
   Branch/DC ─Cloudflare WAN───┼──────► │  Identity ▸ Posture ▸ Access(ZTNA)            │ ─── & SaaS
   Cloud VPC ─MNC/IPsec───┘        │     ▸ Gateway(DNS/L4/HTTP) ▸ DLP ▸ AI controls│ ──►
                                   └───────────────┬──────────────────────────────┘
                                                   │ Cloudflare Tunnel / Access
                                                   ▼
                                       Private apps, servers, internal networks