TL;DR
Mọi request đi qua Cloudflare One đều trải qua 4 tầng theo thứ tự cố định: Client → Identity → Policy → Resource.
- Tầng 1 (Client) sinh ra tín hiệu về device, browser, posture, network context.
- Tầng 2 (Identity) trả lời “who are you”: user, group, role, MFA method, lifecycle state.
- Tầng 3 (Policy) đánh giá tín hiệu từ hai tầng trên, ra một trong 5 kết quả: allow, block, allow-with-conditions, step-up MFA, isolate (RBI).
- Tầng 4 (Resource) là đích: ứng dụng nội bộ qua Tunnel, SaaS, Internet, hoặc browser render từ xa (RBI).
Luận điểm chính:
Khi bạn đang cấu hình một tính năng Cloudflare One hoặc truy nguyên một sự cố, việc đầu tiên cần hỏi là: tầng nào? Câu trả lời sẽ chỉ thẳng bạn tới đúng dashboard, đúng log, đúng người phụ trách, đúng cách sửa.
Bài này là Part 3 của Cloudflare One Handbook, và là mô hình tư duy bạn sẽ gặp lại trong mọi bài sau.
Dành cho ai
- Kỹ sư bảo mật và kỹ sư nền tảng chuẩn bị cấu hình Access, Gateway, Tunnel, WARP.
- Trưởng nhóm IT cần khung chung để thảo luận với nhà cung cấp/tư vấn/nhóm nội bộ.
- Bất kỳ ai đã đọc Part 1-2 nhưng chưa biết bắt đầu từ đâu khi nhìn dashboard Cloudflare Zero Trust.
Bạn nên đã đọc:
- Part 1, Cloudflare One là gì (giới thiệu mô hình 4 tầng ở mức overview)
- Part 2, SASE, SSE, Zero Trust, ZTNA (phân biệt thuật ngữ)
Sau bài này, bạn sẽ có:
- Danh mục tín hiệu cụ thể sinh ra ở mỗi tầng: không phải khái niệm chung, mà tên field thật.
- Hiểu 5 kết quả khả dĩ khi đánh giá chính sách.
- Bảng ánh xạ “triệu chứng → tầng nào → kiểm tra đâu” để truy nguyên nhanh.
- Nguyên tắc thiết kế khi chính sách phải kết hợp tín hiệu từ nhiều tầng.
- Cách quyết định tầng nào phụ trách cái gì khi nhóm lớn.
Bài này không nói về gì
Bài này chưa đi sâu vào từng sản phẩm cụ thể (thiết lập Access, cú pháp chính sách Gateway, cấu hình Tunnel). Những phần đó ở Part 4 trở đi.
Bài này cũng không phải NIST SP 800-207 dịch ra tiếng Việt. NIST có lớp trừu tượng khác (PE, PA, PEP), tốt cho tài liệu tuân thủ, không tiện khi cấu hình thực tế trên dashboard Cloudflare. Mô hình tư duy 4 tầng ở đây đơn giản hơn và ánh xạ trực tiếp với cách Cloudflare tổ chức UI + API.
Vì sao cần một mô hình tư duy?
Dashboard Cloudflare Zero Trust có hơn 30 mục menu khác nhau. Nếu bạn tiếp cận theo kiểu “thử hết” hoặc “cài cái này trước vì thấy tên hay”, rất dễ:
- Bật WARP trước khi có IdP rõ ràng: chính sách sau này phải viết dựa trên IP thay vì nhóm.
- Tạo Access application trước khi bật device posture: chính sách không xác minh được thiết bị.
- Viết chính sách Gateway HTTP trước khi xác định identity provider: rule chỉ lọc theo URL, không theo nhóm người dùng.
- Truy nguyên lỗi “người dùng không vào được ứng dụng” nhưng không biết log nào cần kiểm tra: đi một vòng giữa log WARP, log IdP, Access audit, log Tunnel, log origin.
Mô hình tư duy 4 tầng giải quyết cả hai bài toán:
- Triển khai theo thứ tự, xây từ tầng dưới lên: identity sạch trước, chính sách sau.
- Truy nguyên theo tầng, triệu chứng nào gần tầng nào, kiểm tra dashboard tương ứng.
Bốn tầng: nhìn tổng quan
Nhắc lại mô hình tư duy ở Part 1 (đây là anchor của toàn series, sẽ gặp lại nhiều lần):
Mỗi tầng có 3 thuộc tính quan trọng:
| Thuộc tính | Ý nghĩa |
|---|---|
| Tín hiệu | Dữ liệu mà tầng này sinh ra / cung cấp cho tầng sau |
| Quyết định | Quyết định nào xảy ra tại tầng này (nếu có) |
| Người phụ trách | Nhóm nào chịu trách nhiệm cấu hình / vận hành tầng này |
Ba thuộc tính này khác nhau ở mỗi tầng, đó là lý do tầng 2 không thể chồng chéo với tầng 3, và người phụ trách tầng 4 thường không trùng với người phụ trách tầng 2.
Tầng 1: Client
Tín hiệu sinh ra: mọi thứ về thiết bị, browser, và trạng thái kết nối tại thời điểm request.
Những tín hiệu đáng chú ý
- Danh tính thiết bị: serial number, UUID, phiên bản OS, đã join domain, client certificate. WARP gửi lên khi thiết bị đã enroll; cloudflared gửi lên khi connector bắt đầu.
- Tín hiệu posture: mã hóa ổ đĩa, firewall, EDR (CrowdStrike/SentinelOne/Defender), bản vá OS, khóa màn hình, tuân thủ MDM. Đây là điểm khác biệt của ZTNA so với VPN: VPN không hỏi những câu này.
- Network context: source IP, quốc gia, ASN, WARP được bật, trạng thái split tunnel. Dùng cho rule “chỉ allow từ managed network” hoặc “chặn traffic từ quốc gia rủi ro cao”.
- Trạng thái session: user agent, TLS fingerprint (JA3/JA4), client certificate, cookies. Quan trọng cho chống bot và phát hiện lạm dụng API.
Sản phẩm Cloudflare ở tầng này
- WARP client (Cloudflare One Client): agent trên laptop, điện thoại. Thu thập posture + định tuyến traffic vào edge.
- cloudflared: daemon cho tunnel phía server. Tự định danh bằng tunnel token.
- Browser: khi người dùng truy cập
yourapp.example.comtừ browser thường, không qua WARP. Access vẫn chạy nhưng tín hiệu giới hạn (không có posture).
Quyết định nào xảy ra?
Không có quyết định tại đây. Tầng 1 chỉ gửi tín hiệu lên. Thực thi chính sách hoàn toàn ở tầng 3. Điều này quan trọng: đừng kỳ vọng WARP client “chặn” thứ gì, nó chỉ thu thập và chuyển tiếp. Nếu bạn muốn áp dụng (ví dụ “chặn nếu ổ đĩa chưa mã hóa”), rule phải ở chính sách Gateway/Access (tầng 3).
Người phụ trách
Thường là nhóm IT/Endpoint, họ quản managed device, triển khai MDM, định nghĩa baseline posture. Không phải nhóm bảo mật thuần túy, không phải nhóm network.
Khi nào tầng 1 là nút thắt cổ chai?
- Chưa có thiết bị managed: ví dụ nhân sự thuê ngoài dùng laptop cá nhân. Không có posture → chính sách Access không verify được → phải dùng phương án dự phòng là device cert hoặc yêu cầu MFA bổ sung.
- WARP chưa triển khai xong: traffic đi ngoài WARP không có tín hiệu tầng 1. Chính sách Gateway không lọc được.
- Tình huống BYOD: chỉ truy cập qua browser, không có client. Chỉ có tín hiệu session, không có thiết bị.
Tầng 2: Identity
Tín hiệu sinh ra: mọi thứ về user, đến từ IdP qua OIDC/SAML/SCIM.
Những tín hiệu đáng chú ý
- Thuộc tính người dùng: email, username, loại nhân viên, manager, cost center. Claim từ IdP (Okta/Entra/Google). Chính sách có thể neo trên bất kỳ claim nào Cloudflare nhận được.
- Thành viên nhóm: nhóm bảo mật, dept, role. Đây là neo chính cho 80% chính sách. Chất lượng nhóm quyết định chất lượng chính sách.
- Phương thức xác thực: password, loại MFA (TOTP/SMS/FIDO2), kết quả Conditional Access, tuổi session MFA. Chính sách có thể yêu cầu “phải có FIDO2 trong 24h qua” cho ứng dụng nhạy cảm.
- Trạng thái vòng đời: active/disabled, điểm rủi ro từ IdP (Entra ID trả về), các lần đăng nhập thất bại gần đây, trạng thái offboarding. SCIM sync đưa trạng thái này lên thời gian thực (< 1 phút) nếu cấu hình đúng.
Sản phẩm Cloudflare ở tầng này
- Tích hợp IdP: Cloudflare Access connector với Okta, Entra ID, Google Workspace, SAML chung, OIDC chung, GitHub, AD, one-time PIN.
- Cấp phát SCIM: đồng bộ thành viên nhóm tự động khi user đổi nhóm ở IdP.
- Tương quan device posture: không phải tín hiệu tầng 2 nhưng Cloudflare Access cho phép kết hợp với identity trong cùng rule.
Quyết định nào xảy ra?
Xác thực (authentication) xảy ra ở đây, IdP verify password/MFA và trả assertion về Cloudflare. Nhưng cấp quyền (authorization) thì ở tầng 3. Phân biệt rõ:
- Tầng 2: “Bạn có phải
alice@example.comkhông?” → IdP trả lời. - Tầng 3: “Alice có được vào
gitlab.internalkhông?” → chính sách Access trả lời.
Người phụ trách
Thường là nhóm IAM hoặc nhóm Identity engineering. Không phải nhóm bảo mật chung. Ở tổ chức nhỏ hơn, đây có thể là IT manager kiêm nhiệm.
Khi nào tầng 2 là nút thắt cổ chai?
- Nhóm bẩn: nhóm
Engineeringcó 200 người nhưng 30 người không còn ở engineering. Chính sách dựa vào nhóm này sẽ fail open. - Trễ SCIM: người dùng thôi việc ở IdP 9h sáng nhưng Cloudflare chưa sync tới 12h trưa. Trong 3h đó, token cũ vẫn hiệu lực. Bài Part 7 sẽ đi sâu vấn đề này.
- Ánh xạ claim sai: IdP gửi claim
departmentnhưng rule Cloudflare dùngdept. Rule tưởng chừng đúng mà không khớp ai.
Tầng 3: Policy
Đây là bộ não của Cloudflare One. Mọi tín hiệu từ tầng 1+2 đổ về đây, rule chính sách đánh giá, ra quyết định.
5 kết quả khả dĩ
Đa số nhóm nghĩ chính sách chỉ có 2 kết quả (allow/block). Thực tế Cloudflare One có 5, và dùng đúng kết quả cho đúng mức rủi ro giúp chính sách thực dụng hơn:
| Kết quả | Khi nào dùng | Ví dụ |
|---|---|---|
| Allow | Khớp hoàn toàn rule, đường dẫn tin cậy đầy đủ | Nhân viên + thiết bị managed + FIDO → Jira |
| Block | Fail-closed, không đủ điều kiện, hoặc từ chối tường minh | Người dùng chưa MFA → từ chối ứng dụng Access nhạy cảm |
| Allow with conditions | Cho vào nhưng hạn chế hành vi | SaaS chỉ đọc, không cho tải, không cho paste |
| Step-up MFA | Rủi ro trung bình, xác thực lại với phương thức mạnh hơn | Truy cập database production → hỏi FIDO dù đã đăng nhập Password+TOTP |
| Isolate (RBI) | Truy cập được nhưng qua browser render từ xa | Nhân sự thuê ngoài vào admin panel nội bộ, browser cô lập, không có session local |
Sản phẩm Cloudflare ở tầng này
- Cloudflare Access: chính sách cho ứng dụng nội bộ. Tạo Access application, định nghĩa rule kết hợp identity + posture + network context.
- Cloudflare Gateway: lọc DNS, firewall mạng, chính sách inspect HTTP cho traffic ra Internet/SaaS.
- DLP: chính sách dựa trên nội dung, inspect dữ liệu trong body/response của request.
- CASB: chính sách cho SaaS API (quét cấu hình sai, exfiltration).
Quyết định nào xảy ra?
Toàn bộ cấp quyền xảy ra ở đây. Đây là lớp mà nhóm bảo mật đổ công sức vào.
Một điểm dễ bỏ sót: thứ tự rule quan trọng. Cloudflare Gateway và Access đánh giá rule theo thứ tự, khớp đầu tiên thắng. Viết rule sai thứ tự (allow rộng trước block hẹp) có thể vô hiệu hóa rule hẹp.
Người phụ trách
Nhóm bảo mật, họ phụ trách logic chính sách. Nhưng chính sách phụ thuộc vào chất lượng của tầng 2 (nhóm), tầng 1 (posture). Nếu nhóm bảo mật viết chính sách dựa trên nhóm bẩn từ nhóm IAM, lỗi xuất hiện ở tầng 3 nhưng nguyên nhân gốc ở tầng 2. Đây là lý do quyền sở hữu phải rõ ràng, không thể “bảo mật lo hết”.
Khi nào tầng 3 là nút thắt cổ chai?
- Quá nhiều chính sách, trùng nhau: 400 Access application, 200 rule Gateway, không ai biết cái nào đang ảnh hưởng cái nào. Kiểm toán rất khó.
- Xung đột thứ tự rule: Allow “Engineering đi đâu cũng được” ở trên, Block “không ai được vào admin panel” ở dưới → Engineering vẫn vào admin panel.
- Chính sách drift: bấm tay trong dashboard thay vì IaC. Ai sửa gì không có log, lùi phiên bản khó. Bài Part 4 sẽ nói về policy-as-code cho Access.
Tầng 4: Resource
Đích của request. Khi quyết định chính sách = Allow, Cloudflare forward hoặc proxy tới đây.
4 loại tài nguyên
| Loại | Sản phẩm Cloudflare liên quan | Pattern truy cập |
|---|---|---|
| Ứng dụng nội bộ | Cloudflare Tunnel | Chỉ outbound từ hạ tầng, không cần IP public |
| Ứng dụng SaaS | CASB, DLP | Trực tiếp tới SaaS với traffic qua Gateway + chính sách |
| Internet | Gateway (SWG) | Traffic qua Cloudflare edge + inspect |
| Browser cô lập | Browser Isolation (RBI) | Render từ xa, truyền pixel, không có code chạy local |
Sản phẩm Cloudflare ở tầng này
- Cloudflare Tunnel (
cloudflared): chỉ outbound, đưa ứng dụng nội bộ vào phạm vi Cloudflare edge. - WARP connector / Magic WAN: đưa cả network segment vào phạm vi (thay vì từng ứng dụng).
- Browser Isolation: render browser ở edge, trả pixel về người dùng.
- Gateway egress: proxy traffic ra Internet/SaaS.
Quyết định nào xảy ra?
Không có quyết định chính sách ở tầng 4. Nhưng có quyết định nghiệp vụ quan trọng ở thiết kế:
- Ứng dụng nội bộ có đưa lên Cloudflare Tunnel không? Hay vẫn để VPN?
- Traffic Internet có inspect HTTPS không? Đánh đổi giữa quyền riêng tư và DLP.
- RBI cho ai, cho đích nào? Đánh đổi chi phí.
Người phụ trách
- Ứng dụng nội bộ → Nhóm ứng dụng phụ trách origin, Nhóm nền tảng phụ trách tunnel connector.
- SaaS → Nhóm IT/Admin quản lý tenant.
- Internet → chia sẻ giữa Nhóm bảo mật (chính sách) và Nhóm network (đường egress).
- RBI → Nhóm bảo mật quyết định chính sách, nhưng trải nghiệm người dùng tác động tới toàn nhóm.
Khi nào tầng 4 là nút thắt cổ chai?
- Tunnel chập chờn: connector mất kết nối, replicas không health. Chính sách pass nhưng ứng dụng 502.
- Ứng dụng origin fail: Cloudflare đã cho request đi qua, nhưng backend đang có vấn đề. Log ở Cloudflare sạch, phải đi vào log ứng dụng.
- Cấu hình SaaS tenant sai: CASB phát hiện file public, nhưng người phụ trách không biết ai public.
Tổng hợp: nguyên tắc thiết kế chính sách
Khi viết chính sách, kết hợp tín hiệu từ nhiều tầng. Đây là pattern phổ biến:
Pattern 1: Nhân viên + thiết bị managed → ứng dụng nội bộ
# Access application: gitlab.internal
policy:
- include:
emails_ending_in: ["@example.com"] # Layer 2
groups: ["Engineering", "DevOps"] # Layer 2
- require:
device_posture:
- disk_encrypted # Layer 1
- firewall_enabled # Layer 1
- os_version: ">= macOS 14 | Windows 11" # Layer 1
- exclude:
country: ["KP", "RU"] # Layer 1 (network context)Rule này kết hợp 3 tầng, 2 (nhóm identity), 1 (posture + network), với quyết định là Allow nếu include khớp AND require thỏa mãn AND không khớp exclude.
Pattern 2: Nhân sự thuê ngoài → SaaS chỉ đọc
# SaaS application: salesforce.com
policy:
- include:
groups: ["Contractors"] # Layer 2
- require:
session_mfa_age: "< 4h" # Layer 2
warp_enabled: true # Layer 1
- action: allow_with_conditions
conditions:
- disable_download
- disable_paste
- browser_isolation: required # → Layer 4 RBIKết hợp: identity (nhóm nhân sự thuê ngoài) + trạng thái session (MFA mới) + network (WARP bật) → kết quả là Allow with conditions, dẫn xuống RBI ở tầng 4.
Pattern 3: Step-up cho đường admin
# Access application: admin.internal
policy:
- include:
groups: ["Platform-Admin"] # Layer 2
- require:
mfa_method: ["FIDO2"] # Layer 2
session_mfa_age: "< 30m" # Layer 2
device_posture: [domain_joined, mdm_compliant] # Layer 1
- action: step_up_if_staleBài học chính: chính sách mạnh nhất là khi tận dụng tất cả tầng. Chính sách yếu chỉ dựa vào 1 tầng (ví dụ chỉ domain email) → thiếu phòng thủ theo lớp.
Truy nguyên theo tầng
Khi có sự cố, câu hỏi đầu tiên là “Triệu chứng ở tầng nào?”. Đây là bảng tra nhanh:
Quy trình truy nguyên 4 bước
- Tái hiện, lấy đủ ngữ cảnh (người dùng, thiết bị, ứng dụng, thời điểm).
- Phân loại, triệu chứng gần nhất với tầng nào? (xem bảng).
- Kiểm tra log chính cho tầng đó:
- Tầng 1: trang trạng thái WARP client, đầu ra posture checker
- Tầng 2: log audit IdP, trạng thái SCIM sync
- Tầng 3: Cloudflare Access audit, log Gateway
- Tầng 4: sức khỏe Tunnel connector, log origin
- Nếu log tầng đó sạch, đi ngược lên tầng dưới (ví dụ log Access sạch → kiểm tra Identity → kiểm tra Client).
Nguyên tắc: truy nguyên đi từ tài nguyên (tầng 4) ngược về client (tầng 1) vì đó là chiều người dùng nhìn thấy lỗi cuối cùng. Khi triển khai thì ngược lại, xây từ tầng dưới (identity) lên.
Đánh đổi và quyết định thiết kế
| Quyết định | Phương án A | Phương án B | Khuyến nghị |
|---|---|---|---|
| Mức chặt của chính sách | Chặn mặc định, allowlist ngoại lệ | Cho phép mặc định, blocklist mối đe dọa | Chặn mặc định cho ứng dụng nhạy cảm (admin, DB production). Cho phép mặc định cho Internet (SWG default-allow + chặn theo danh mục) |
| Nguồn device posture | Kiểm tra có sẵn của Cloudflare | Tích hợp với EDR/MDM (CrowdStrike, Intune) | Có sẵn cho nhóm < 100 người dùng. Tích hợp EDR/MDM khi có nhóm bảo mật + EDR/MDM đã chín |
| Kết hợp lớp chặt vs lỏng | Mọi rule đều kết hợp 4 tầng | Chỉ kết hợp khi cần | Bắt đầu lỏng (email + nhóm), thêm lớp khi xác định rủi ro cụ thể. Đừng over-engineer sớm |
| Policy-as-code vs dashboard | Tất cả qua Terraform/API | Bấm tay cho tất cả | Dashboard OK cho pilot/< 20 rule. Đổi sang IaC khi có 50+ rule hoặc 2+ admin. Bài Part 4 sẽ đi sâu |
| Chia quyền sở hữu | Nhóm bảo mật phụ trách toàn bộ chính sách | Chia theo tầng: IT phụ trách 1, IAM phụ trách 2, Bảo mật phụ trách 3, Nhóm ứng dụng phụ trách 4 | Chia theo tầng khi nhóm > 10 người. Rà soát liên nhóm mỗi quý |
Danh sách kiểm tra: dùng mô hình tư duy này khi làm gì?
Trước khi cấu hình:
- Tính năng mình đang bật nằm ở tầng nào? (không phải “nó làm gì”, mà “nó kiểm soát tầng nào”)
- Tín hiệu tầng đó có sẵn chưa? (ví dụ rule posture mà WARP chưa triển khai = không hoạt động)
- Chính sách mình viết có kết hợp đủ tầng không? Hay chỉ dựa 1 tầng?
- Ai phụ trách tầng này? Họ đã duyệt cấu hình chưa?
Trước khi truy nguyên:
- Triệu chứng gần tầng nào nhất? (xem bảng chế độ lỗi)
- Log chính cho tầng đó ở đâu?
- Nếu log sạch, tầng dưới nào là nghi phạm tiếp theo?
Trước khi viết RCA:
- Nguyên nhân gốc ở tầng nào? (khác với triệu chứng: triệu chứng có thể ở tầng 4 nhưng nguyên nhân gốc ở tầng 2)
- Cách khắc phục nên chạm tầng nào? Có gây drift các tầng khác không?
- Ai phụ trách khắc phục?
Bài học thực tế
- Mô hình tư duy này không thay thế kiến thức về từng sản phẩm. Bạn vẫn cần biết cú pháp chính sách Access, thứ tự đánh giá rule Gateway, cấu hình Tunnel ingress. Mô hình tư duy giúp bạn tổ chức kiến thức đó, không thay thế nó.
- Chất lượng nhóm là điểm đau phổ biến nhất. 90% sự cố “chính sách hoạt động sai” mình từng truy nguyên cuối cùng là nhóm ở tầng 2 bẩn (thành viên cũ, nhóm lồng không sync, trễ SCIM). Đầu tư vào identity hygiene trước khi viết chính sách phức tạp.
- Đừng coi tầng 4 là hộp đen. Cloudflare dừng ở tầng 3: ra xong quyết định chính sách, chuyển tiếp request tới origin. Nếu origin chậm, origin sập, origin sai permission, Cloudflare không sửa được. Phải có chủ sở hữu ứng dụng phối hợp.
- Truy nguyên ngược chiều với chiều triển khai. Triển khai đi từ tầng 2 lên (identity → chính sách → WARP → Gateway). Truy nguyên đi từ tầng 4 xuống (người dùng kêu lỗi ứng dụng → kiểm tra origin → kiểm tra tunnel → kiểm tra chính sách → kiểm tra identity → kiểm tra WARP).
Kết luận
Cloudflare One có nhiều sản phẩm, nhiều tính năng, nhiều checkbox. Nhưng nếu nhìn qua lăng kính 4 tầng, mọi thứ đơn giản hơn:
- Tầng 1 (Client): tín hiệu về thiết bị.
- Tầng 2 (Identity): xác thực + thuộc tính.
- Tầng 3 (Policy): quyết định dựa trên tầng 1+2.
- Tầng 4 (Resource): đích của request.
Khi bạn ngồi trước dashboard và không biết bắt đầu từ đâu, hỏi tầng nào trước. Khi người dùng báo lỗi, hỏi triệu chứng gần tầng nào. Khi nhóm tranh cãi về quyền sở hữu, hỏi tầng nào ai phụ trách.
Nếu phải nhớ một câu:
Triển khai xây từ dưới lên (identity hygiene → chính sách → WARP). Truy nguyên đào từ trên xuống (resource → chính sách → identity → client). Đừng đảo chiều.
Trong Part 4 mình sẽ đi vào Cloudflare Access, sản phẩm đầu tiên sẽ dùng mô hình tư duy này một cách cụ thể: tạo Access application, kết nối IdP (tầng 2), viết chính sách với tín hiệu từ tầng 1, test end-to-end.
Tài liệu tham khảo
- Cloudflare Access documentation
- Cloudflare Gateway policies
- Cloudflare device posture
- NIST SP 800-207, Zero Trust Architecture (tham chiếu mô hình tương đương của NIST)
Trong series này:
