TL;DR
Cloudflare One là nền tảng SASE/SSE của Cloudflare, gom nhiều khả năng bảo mật hiện đại vào một control plane: Zero Trust access, secure web gateway, private network connectivity, data protection, browser isolation và giám sát.
Thay vì vận hành riêng lẻ VPN, SWG, CASB, DLP, RBI, email security và nhiều dashboard khác nhau, Cloudflare One cố gắng đưa các khả năng đó về một kiến trúc thống nhất: người dùng đi qua Cloudflare edge, identity và thiết bị được kiểm tra, policy được áp dụng, log được ghi lại, rồi mới cho phép truy cập tài nguyên.
Bài này là Part 1 của series Cloudflare One Handbook. Mục tiêu không phải hướng dẫn bấm từng menu trong dashboard, mà là dựng một mô hình tư duy đủ rõ để các bài sau, Access, Gateway, Tunnel, WARP, DLP, CASB, DEX, có chỗ bám.
Luận điểm chính của bài:
Đừng học Cloudflare One theo danh sách tính năng. Hãy học theo request path: client, identity, policy, resource. Khi hiểu request đi qua tầng nào, bạn sẽ biết nên dùng sản phẩm nào và vì sao.
Dành cho ai
Bài này dành cho:
- Kỹ sư bảo mật đang tìm hiểu Cloudflare One, Zero Trust hoặc SASE.
- Kỹ sư nền tảng cần thay thế VPN truyền thống cho ứng dụng nội bộ.
- Trưởng nhóm IT đang cân nhắc giữa Cloudflare One, Zscaler, Netskope hoặc mô hình best-of-breed.
- Nhóm đã dùng Cloudflare cho website công khai và muốn mở rộng sang enterprise access/security.
Bạn nên biết trước một chút về DNS, HTTPS, VPN, SSO và private network. Không cần đã từng triển khai Cloudflare One.
Sau bài này, bạn sẽ hiểu:
- Cloudflare One thực chất gồm những nhóm khả năng nào.
- SASE, SSE, Zero Trust và ZTNA khác nhau ở đâu.
- Access, Gateway, Tunnel, WARP, DLP, CASB, RBI, DEX nằm ở tầng nào.
- Khi nào Cloudflare One phù hợp, khi nào nên cân nhắc lại.
- Nên bắt đầu triển khai từ đâu để không biến triển khai Zero Trust thành một mớ tính năng rời rạc.
Bài này không nói về gì
Bài này chưa đi sâu vào cách cấu hình Access, Gateway, Tunnel, WARP, DLP hay CASB. Những phần đó sẽ nằm ở các bài sau trong series.
Mục tiêu của Part 1 là tạo mô hình tư duy trước. Nếu chưa có mô hình tư duy, bạn rất dễ rơi vào trạng thái bật từng tính năng một cách rời rạc: hôm nay bật WARP, mai tạo Access app, tuần sau thêm Gateway rule, rồi cuối cùng không ai trong nhóm trả lời được policy nào đang kiểm soát request nào.
Cloudflare One không khó vì thiếu tính năng. Nó khó vì có quá nhiều tính năng, và mỗi tính năng chỉ có ý nghĩa khi được đặt đúng chỗ trong kiến trúc.
Khái niệm
Trước khi nói về Cloudflare One, cần phân biệt một vài thuật ngữ sẽ xuất hiện xuyên suốt series.
SASE
SASE, Secure Access Service Edge là mô hình kết hợp network và security vào một kiến trúc cloud-native. Thay vì kéo toàn bộ traffic về datacenter để kiểm soát, người dùng đi tới một edge network gần nhất, policy được áp dụng tại đó, rồi traffic mới đi tiếp tới Internet, SaaS hoặc private application.
Một nền tảng SASE thường bao gồm các thành phần như:
- ZTNA: Zero Trust Network Access
- SWG: Secure Web Gateway
- CASB: Cloud Access Security Broker
- DLP: Data Loss Prevention
- FWaaS: Firewall as a Service
- SD-WAN hoặc private connectivity
SSE
SSE, Security Service Edge là phần security của SASE. Nói đơn giản, SSE thường bao gồm SWG, CASB, ZTNA, DLP và FWaaS, nhưng không nhất thiết bao gồm toàn bộ lớp network/WAN.
Trong thực tế, nhiều nhóm bắt đầu từ SSE trước vì pain point rõ hơn: thay VPN, kiểm soát Internet access, áp dụng device posture, ghi log access event, chống data leak.
Zero Trust
Zero Trust không phải là một sản phẩm. Đây là mô hình bảo mật dựa trên nguyên tắc: không tin bất kỳ người dùng, thiết bị hoặc network nào mặc định.
Mỗi request cần được đánh giá dựa trên nhiều tín hiệu:
- Người dùng là ai?
- Đăng nhập qua IdP nào?
- Thiết bị có được quản lý không?
- Posture có đạt không?
- Request tới app nào?
- Từ vị trí nào?
- Có khớp policy không?
- Có rủi ro data exfiltration không?
ZTNA
ZTNA, Zero Trust Network Access là cách áp dụng Zero Trust cho truy cập vào ứng dụng nội bộ. Thay vì cho người dùng vào toàn bộ network như VPN truyền thống, ZTNA cho phép truy cập theo từng ứng dụng, từng user group, từng device posture và từng ngữ cảnh cụ thể.
Trong Cloudflare One, Cloudflare Access là thành phần ZTNA chính.
SWG
SWG, Secure Web Gateway, kiểm soát traffic của người dùng đi ra Internet. SWG có thể filter DNS, inspect HTTP/HTTPS, chặn malware/phishing, kiểm soát category, áp dụng tenant restriction, hoặc áp dụng DLP policy.
Trong Cloudflare One, Cloudflare Gateway là thành phần SWG chính.
Bài Part 2 sẽ đi sâu hơn vào cách phân biệt SASE, SSE, Zero Trust và ZTNA.
Cloudflare One, Cloudflare Zero Trust và Magic WAN khác nhau thế nào?
Một điểm dễ gây nhầm lẫn: Cloudflare One, Cloudflare Zero Trust, Access, Gateway, Tunnel, WARP, Magic WAN nghe giống các sản phẩm riêng lẻ, nhưng thực tế chúng nằm trong cùng một kiến trúc lớn hơn.
Cách dễ hiểu nhất:
- Cloudflare One là nền tảng umbrella cho SASE/SSE.
- Cloudflare Zero Trust là phần user/security-facing mà hầu hết nhóm sẽ dùng trước: Access, Gateway, WARP, Tunnel, DLP, CASB, Browser Isolation, DEX.
- Magic WAN / Magic Transit thuộc lớp network connectivity rộng hơn, phù hợp với branch connectivity, WAN modernization, network-level traffic steering và DDoS/network protection.
Trong series này, trọng tâm sẽ là phần Cloudflare Zero Trust nằm trong Cloudflare One, vì đây là phần liên quan trực tiếp tới access control, device posture, Gateway policy và private application access.
Bối cảnh: Vì sao SASE xuất hiện
Trước khi có SASE, enterprise security stack thường được ghép từ nhiều sản phẩm riêng biệt:
Mô hình này từng hợp lý khi phần lớn người dùng ngồi trong văn phòng, ứng dụng nằm trong datacenter, và traffic có thể backhaul về một perimeter cố định.
Nhưng mô hình đó bắt đầu vỡ khi ba thứ xảy ra cùng lúc:
-
Người dùng không còn ở một nơi cố định Hybrid work khiến người dùng truy cập từ nhà, quán cà phê, khách sạn, sân bay, văn phòng chi nhánh hoặc mobile network.
-
Ứng dụng không còn chỉ nằm trong datacenter Khối lượng công việc nằm rải rác giữa on-prem, AWS, Azure, GCP, SaaS và nhiều môi trường dev/uat/prod khác nhau.
-
Compliance cần visibility tập trung hơn Nhóm bảo mật cần trả lời được: ai truy cập app nào, từ thiết bị nào, qua policy nào, bị chặn vì lý do gì, và log nằm ở đâu.
Vấn đề không chỉ là VPN chậm. Vấn đề lớn hơn là perimeter cũ không còn phản ánh đúng cách enterprise vận hành.
VPN cho người dùng vào network. Nhưng enterprise hiện đại cần kiểm soát ở mức request, identity, device, application, data và policy.
Đó là lý do SASE/SSE trở thành hướng kiến trúc hợp lý hơn: đưa enforcement point ra cloud edge, gần người dùng hơn, nhất quán hơn, và dễ mở rộng hơn so với mô hình backhaul truyền thống.
Vì sao Cloudflare có lợi thế khi làm SASE
Cloudflare không bắt đầu từ VPN hay CASB. Cloudflare bắt đầu từ network.
Cloudflare đã có sẵn global anycast network phục vụ CDN, DNS, WAF, bảo vệ DDoS và reverse proxy cho public Internet. Cloudflare One là cách Cloudflare mở rộng cùng edge network đó sang trường hợp sử dụng enterprise security: không chỉ bảo vệ website công khai, mà còn bảo vệ người dùng, thiết bị, ứng dụng nội bộ, SaaS access và Internet traffic.
Điểm khác biệt nằm ở chỗ: cùng một edge network có thể xử lý nhiều luồng traffic khác nhau.
Đây là lý do vị thế của Cloudflare One khác hẳn các nhà cung cấp SASE truyền thống. Nó không chỉ là một security proxy. Nó là một nền tảng bảo mật được xây trên một global edge network đã có sẵn.
Mô hình tư duy: 4 tầng của Cloudflare One
Nếu chỉ nhớ một phần trong bài này, hãy nhớ phần này.
Mình thường lập luận về Cloudflare One bằng 4 tầng.
Mỗi khi thêm một khả năng vào Cloudflare One, hãy tự hỏi:
Khả năng này đang kiểm soát tầng nào trong request path?
Ví dụ:
| Khả năng | Tầng chính | Vai trò |
|---|---|---|
| WARP Client | Client | Đưa traffic từ thiết bị vào Cloudflare edge |
| Cloudflare Tunnel | Resource / Connectivity | Kết nối private resource ra Cloudflare không cần inbound port |
| Microsoft Entra ID / Okta | Identity | Xác thực người dùng và group |
| SCIM | Identity | Đồng bộ vòng đời user/group |
| Device Posture | Identity / Context | Kiểm tra trạng thái thiết bị |
| Cloudflare Access | Policy | Quyết định người dùng có được vào private app không |
| Cloudflare Gateway | Policy | Kiểm soát DNS/HTTP/Network traffic |
| DLP | Policy / Data | Phát hiện và ngăn dữ liệu nhạy cảm rời khỏi tổ chức |
| CASB | Policy / SaaS | Kiểm tra SaaS config, permission và risk |
| Browser Isolation | Resource / Threat containment | Render web content từ xa để giảm rủi ro trên endpoint |
| DEX | Cross-cutting | Theo dõi trải nghiệm và chất lượng kết nối |
Cách học theo tầng giúp bạn tránh một lỗi rất phổ biến: triển khai theo tính năng thay vì theo kiến trúc.
Luồng request tổng quát
Với private application, request thường đi như sau:
Với managed device truy cập Internet hoặc SaaS, luồng thường là:
Với private network access qua WARP:
Ba luồng trên khác nhau, nhưng cùng dùng một nguyên tắc: request đi qua Cloudflare edge, được kiểm tra bằng identity/context/policy, rồi mới tới tài nguyên.
6 nhóm khả năng chính trong Cloudflare One
Có nhiều cách chia Cloudflare One. Với mục tiêu triển khai thực tế, mình chia thành 6 nhóm sau.
| Nhóm | Sản phẩm chính | Tầng | Giải quyết vấn đề |
|---|---|---|---|
| Identity & Access | Cloudflare Access | 2, 3 | Thay VPN cho private app, áp dụng ZTNA |
| Connectivity | WARP, Cloudflare Tunnel | 1, 4 | Đưa thiết bị và private resource vào Cloudflare network |
| Traffic & Policy | Cloudflare Gateway | 3 | SWG cho DNS, Network, HTTP traffic |
| Data Protection | DLP, CASB, Email Security | 3 | Giảm rủi ro data leak, SaaS exposure, phishing |
| Advanced Threat Protection | Browser Isolation | 3, 4 | Cô lập nội dung rủi ro khỏi endpoint |
| Monitoring & Experience | DEX | Cross-cutting | Theo dõi chất lượng kết nối và trải nghiệm người dùng |
1. Identity & Access
Cloudflare Access là thành phần ZTNA cốt lõi.
Nếu VPN truyền thống cho người dùng vào network, thì Access cho người dùng vào từng ứng dụng cụ thể dựa trên identity, group, posture và policy.
Ví dụ luồng sau, giống luồng private application bên trên, nhưng nhìn từ góc Access:
Access kết hợp ba vai trò:
-
SSO front door Người dùng phải xác thực qua IdP trước khi vào ứng dụng.
-
Authorization engine Policy quyết định user/group/device/context nào được phép truy cập.
-
Audit layer Login event, allow/deny decision và session activity có thể được ghi log để phục vụ điều tra và compliance.
Trường hợp sử dụng điển hình:
- Admin portal nội bộ
- GitLab/Jenkins/Jira tự host
- Ứng dụng Dev/UAT
- Database admin UI
- Kubernetes dashboard
- Truy cập cho nhà cung cấp/nhân sự thuê ngoài
- Ứng dụng cần MFA/device posture nhưng chưa hỗ trợ SSO native
Điểm quan trọng: Access không chỉ là “SSO trước app”. Giá trị lớn nhất của Access là biến truy cập ứng dụng nội bộ thành một quyết định policy có audit trail.
2. Connectivity
Cloudflare One cần hai đầu kết nối: một đầu ở user/device, một đầu ở private resource.
WARP Client
WARP là agent cài trên laptop hoặc thiết bị di động. Nó đưa traffic của managed device vào Cloudflare edge để Gateway, Access, DLP hoặc private routing có thể áp dụng policy.
WARP thường xử lý các trường hợp sử dụng:
- DNS filtering
- HTTP/HTTPS inspection
- Private network access
- Tín hiệu device posture
- Split tunnel routing
- User-to-application traffic steering
Cloudflare Tunnel
Cloudflare Tunnel là outbound-only connector từ hạ tầng của bạn ra Cloudflare edge. Daemon cloudflared chạy trong datacenter, VM, Kubernetes hoặc cloud VPC.
Điểm quan trọng: Tunnel không yêu cầu mở inbound port từ Internet vào origin.
Tunnel phù hợp cho:
- Ứng dụng web nội bộ
- Dịch vụ nội bộ non-HTTP
- Truy cập SSH/RDP
- API nội bộ
- Ứng dụng trong VPC hoặc datacenter
- Trường hợp sử dụng cần giảm public exposure
WARP và Tunnel là hai đầu của cùng một đường ống: WARP đưa thiết bị vào Cloudflare network, Tunnel đưa private resource vào Cloudflare network, và policy ở Cloudflare edge quyết định request nào đi xuyên từ WARP sang Tunnel.
3. Traffic & Policy: Gateway
Cloudflare Gateway là Secure Web Gateway của Cloudflare One. Nếu Access kiểm soát private app, thì Gateway kiểm soát traffic đi ra Internet, SaaS hoặc private network.
Gateway có ba lớp policy chính:
DNS Policy
DNS filtering là lớp đơn giản và ít intrusive nhất.
Trường hợp sử dụng:
- Chặn malware domain
- Chặn phishing
- Chặn category như gambling, adult, newly seen domains
- Áp dụng safe search
- Log DNS query
- Áp policy theo user/group/device
DNS policy thường là điểm bắt đầu tốt vì impact thấp, dễ quan sát, dễ khôi phục.
Network Policy
Network policy kiểm soát ở L3/L4: IP, port, protocol.
Trường hợp sử dụng:
- Cho phép SSH/RDP tới một số private IP cụ thể
- Chặn outbound port rủi ro
- Kiểm soát traffic tới private CIDR
- Áp dụng rule theo user group hoặc device posture
Network policy rất quan trọng khi thay VPN, vì không phải mọi dịch vụ nội bộ đều là web app.
HTTP Policy
HTTP policy cho phép inspect request ở tầng ứng dụng.
Trường hợp sử dụng:
- Chặn URL/path cụ thể
- Áp tenant restriction cho SaaS
- Kiểm soát upload/download
- Áp dụng DLP
- Chặn loại file rủi ro
- Áp policy theo HTTP hostname, path, method, header
HTTP policy mạnh hơn nhưng cũng phức tạp hơn vì có thể cần TLS inspection. Với enterprise, đây là phần cần triển khai cẩn thận theo phase, tránh bật quá rộng ngay từ đầu.
4. Data Protection
Cloudflare One không chỉ kiểm soát connection. Nó cũng có các khả năng để kiểm soát data movement.
DLP
Data Loss Prevention scan traffic để phát hiện dữ liệu nhạy cảm như credential, token, PII, financial data hoặc pattern tùy chỉnh.
Trường hợp sử dụng:
- Chặn upload file chứa dữ liệu nhạy cảm lên SaaS không được phép
- Phát hiện secret/token bị copy ra ngoài
- Log hoặc chặn data exfiltration qua browser
- Áp policy khác nhau theo user group hoặc destination
CASB
CASB nhìn vào SaaS ở góc độ cấu hình và posture, không chỉ traffic.
Trường hợp sử dụng:
- Phát hiện file public trong Google Workspace/Microsoft 365
- Kiểm tra permission quá rộng
- Rà soát SaaS misconfiguration
- Phát hiện tích hợp third-party app rủi ro
Khác biệt quan trọng:
- Gateway kiểm soát traffic.
- CASB kiểm tra trạng thái và cấu hình của SaaS.
- DLP kiểm soát dữ liệu trong quá trình di chuyển.
Ba thứ này bổ trợ cho nhau, không thay thế nhau.
Email Security
Email Security giúp phát hiện phishing, link độc hại, impersonation và mối đe dọa trước khi email tới người dùng hoặc trong mailbox.
Trường hợp sử dụng:
- Chống phishing
- Phát hiện attachment/link độc hại
- Bảo vệ mailbox của lãnh đạo
- Giảm rủi ro credential harvesting
Với nhiều tổ chức, email vẫn là điểm vào phổ biến nhất của kẻ tấn công. Do đó Email Security là một phần hợp lý trong nền tảng SASE/SSE, dù không phải nhóm nào cũng triển khai ngay từ đầu.
5. Advanced Threat Protection: Browser Isolation
Remote Browser Isolation render web content trong môi trường cô lập, sau đó truyền nội dung an toàn về người dùng.
Thay vì để browser trên laptop trực tiếp xử lý website rủi ro, Cloudflare render phiên duyệt web từ xa. Nếu site có exploit, exploit đó đánh vào môi trường cô lập thay vì endpoint thật.
Trường hợp sử dụng:
- Người dùng mở link lạ trong email
- Admin cần truy cập website không tin cậy
- Nhân sự thuê ngoài cần vào app nhạy cảm nhưng không muốn phơi data trực tiếp
- Nhóm rủi ro cao cần policy cô lập nghiêm ngặt hơn
- Truy cập SaaS chỉ cho xem, không cho tải/copy/paste
RBI không phải thứ nên bật đại trà ngay từ đầu. Nó phù hợp hơn với high-risk destination, high-risk user group hoặc quy trình rủi ro cao.
6. Monitoring: DEX
Digital Experience Monitoring trả lời câu hỏi mà nhóm bảo mật thường bị hỏi nhưng khó trả lời:
“Vì sao người dùng nói ZTNA chậm?”
Không phải sự cố nào cũng là vấn đề bảo mật. Có thể là Wi-Fi, ISP, DNS, WARP client, tunnel connector, Cloudflare edge, application backend hoặc route nội bộ.
DEX giúp quan sát:
- Device connectivity
- WARP status
- Network quality
- Synthetic tests
- Application reachability
- Trải nghiệm người dùng từ endpoint tới tài nguyên
Với triển khai Zero Trust quy mô lớn, DEX là khả năng rất đáng chú ý vì nó giúp giảm tranh luận cảm tính giữa nhóm bảo mật, network, helpdesk và nhóm ứng dụng.
So sánh Cloudflare One với Zscaler và Netskope
Ba nhà cung cấp thường được so sánh trong không gian SASE/SSE là Zscaler, Netskope và Cloudflare One.
Mỗi nhà cung cấp có điểm xuất phát khác nhau:
| Chiều | Zscaler | Netskope | Cloudflare One |
|---|---|---|---|
| Khởi nguồn | SWG-first | CASB-first | Network-first |
| Điểm mạnh truyền thống | Secure Web Gateway, policy maturity | SaaS visibility, CASB, DLP | Global edge network, developer experience, tích hợp |
| ZTNA | ZPA | Netskope Private Access | Cloudflare Access |
| SWG | ZIA | Netskope Intelligent SSE | Cloudflare Gateway |
| CASB/DLP | Có | Sâu (inline/out-of-band, SaaS coverage rộng) | Có, đang mature dần |
| Developer experience | Enterprise-sales oriented | Enterprise-sales oriented | API/Terraform/docs khá mở |
| Phù hợp với | Enterprise cần SASE mature | Tổ chức SaaS-heavy, data-centric | Nhóm muốn nền tảng thống nhất, network reach tốt, triển khai nhanh |
Cloudflare One không nhất thiết là best ở từng category riêng lẻ.
Zscaler có nhiều năm đi trước ở SWG/SASE enterprise. Netskope rất mạnh ở CASB, SaaS visibility và data security. Cloudflare có lợi thế ở global network, reverse proxy heritage, developer-facing model và khả năng kết hợp security với edge platform.
Câu hỏi đúng không phải là “nhà cung cấp nào tốt nhất tuyệt đối”. Câu hỏi đúng là:
Với ràng buộc của tổ chức mình, identity, network, SaaS, compliance, quy mô nhóm, ngân sách, operating model, nhà cung cấp nào giảm được nhiều complexity nhất mà vẫn đáp ứng yêu cầu rủi ro?
Khi nào Cloudflare One phù hợp
Cloudflare One phù hợp nếu tổ chức của bạn có một hoặc nhiều đặc điểm sau.
1. Muốn thay VPN cho ứng dụng nội bộ
Nếu pain point lớn nhất là VPN chậm, khó scale, cấp quyền quá rộng hoặc thiếu audit trail, Cloudflare Access + Tunnel là điểm bắt đầu rất hợp lý.
Bạn có thể bắt đầu với vài ứng dụng quan trọng, áp dụng SSO/MFA/device posture, rồi mở rộng dần thay vì chuyển đổi toàn bộ trong một lần.
2. Đã dùng Cloudflare cho website công khai
Nếu tổ chức đã dùng Cloudflare DNS, CDN, WAF hoặc DDoS protection, việc thêm Cloudflare One giúp tận dụng cùng account, zone, dashboard, API và operating model.
Điều này không tự động làm triển khai dễ, nhưng giảm đáng kể đường cong học tập và phân mảnh nhà cung cấp.
3. Nhóm thích tự động hóa và policy-as-code
Cloudflare có API và Terraform provider tương đối dễ tiếp cận. Với nhóm platform/security engineering, đây là lợi thế lớn.
Ở quy mô enterprise, policy bấm tay trong dashboard sẽ nhanh chóng trở thành nợ kỹ thuật. Nếu muốn quản trị Access app, Gateway rule, tunnel route, list và reusable policy theo GitOps/IaC, Cloudflare là một lựa chọn đáng cân nhắc.
4. Người dùng phân tán nhiều địa lý
Với nhóm làm việc từ nhiều quốc gia hoặc nhiều khu vực, edge footprint của Cloudflare là lợi thế thực tế. Người dùng không cần backhaul về datacenter chỉ để ra Internet hoặc vào private app.
5. Muốn bắt đầu nhỏ rồi mở rộng dần
Cloudflare One cho phép bắt đầu từ một số trường hợp sử dụng cụ thể: Access cho private app, Gateway DNS filtering, hoặc WARP cho nhóm thí điểm. Đây là cách phù hợp với tổ chức chưa muốn cam kết ngay một chương trình SASE lớn.
Khi nào nên cân nhắc lại
Cloudflare One không phải lựa chọn mặc định cho mọi tổ chức.
1. Môi trường on-prem quá nặng và yêu cầu data locality rất nghiêm ngặt
Nếu tổ chức có yêu cầu rất chặt về data residency, traffic locality hoặc regulatory constraint theo quốc gia, cần đánh giá kỹ Cloudflare One theo từng loại log, traffic path, inspection mode và hợp đồng enterprise.
2. Đã đầu tư sâu vào Zscaler hoặc Netskope
Nếu Zscaler/Netskope đã được triển khai ổn định, chính sách đã trưởng thành, log đã tích hợp SIEM, nhóm vận hành đã quen, thì chi phí chuyển đổi có thể lớn hơn lợi ích trong 1-2 năm đầu.
Trong trường hợp này, Cloudflare One có thể phù hợp cho một trường hợp sử dụng riêng như Access cho một nhóm app, không nhất thiết thay toàn bộ nền tảng ngay.
3. Chỉ cần một khả năng chuyên sâu
Nếu chỉ cần CASB rất sâu cho SaaS governance, Netskope có thể là lựa chọn mạnh hơn. Nếu chỉ cần email security chuyên sâu, Proofpoint hoặc các nhà cung cấp email security chuyên biệt có thể phù hợp hơn.
Cloudflare One mạnh ở hướng tích hợp nền tảng. Nếu bài toán của bạn là một domain rất sâu, best-of-breed vẫn có lý do tồn tại.
Những hiểu nhầm phổ biến
”Cloudflare One là VPN mới”
Không chính xác.
VPN chủ yếu giải quyết connectivity. Cloudflare One rộng hơn: identity, device posture, access policy, secure web gateway, data protection, browser isolation, private routing và giám sát.
Access + Tunnel có thể thay thế nhiều trường hợp sử dụng VPN, nhưng Cloudflare One không chỉ là phương án thay VPN.
”Cài WARP là đã triển khai Zero Trust”
Sai.
WARP chỉ là client và traffic steering layer. Zero Trust chỉ thật sự có ý nghĩa khi bạn đã có:
- Identity rõ ràng
- Vòng đời group sạch
- Device posture đáng tin
- Policy được thiết kế đúng
- Logging vào SIEM
- Xử lý ngoại lệ
- Khôi phục path
- Người phụ trách cho từng ứng dụng/CIDR
Cài agent là phần dễ. Thiết kế governance mới là phần khó.
”SASE là mua một nhà cung cấp rồi bật hết tính năng”
Sai.
SASE là kiến trúc vận hành, không phải shopping list.
Một nhà cung cấp duy nhất có thể giảm chi phí tích hợp, nhưng không thay thế được identity hygiene, thiết kế network, vòng đời chính sách, quản lý thay đổi và playbook ứng phó sự cố.
”Zero Trust nghĩa là chặn càng nhiều càng tốt”
Không hẳn.
Zero Trust nghĩa là xác minh đúng thứ, đúng lúc, theo đúng ngữ cảnh rủi ro. Một chính sách quá chặt nhưng không vận hành được sẽ bị vòng tránh. Một chính sách thực dụng, đo được, triển khai theo giai đoạn và có ngoại lệ rõ ràng thường đem lại kết quả bảo mật tốt hơn.
Quyết định thiết kế khi bắt đầu
Một nhà cung cấp SASE duy nhất hay best-of-breed?
| Phương án | Ưu điểm | Nhược điểm | Phù hợp khi |
|---|---|---|---|
| Một nhà cung cấp SASE duy nhất | Ít dashboard hơn, chính sách thống nhất hơn, tích hợp đơn giản hơn | Có thể không mạnh nhất ở từng mảng | Nhóm nhỏ/vừa, muốn giảm độ phức tạp vận hành |
| Best-of-breed | Chọn được nhà cung cấp mạnh nhất cho từng khả năng | Tăng tích hợp, hợp đồng, pipeline log và trôi chính sách | Nhóm bảo mật lớn, yêu cầu sâu, có năng lực vận hành nhiều nền tảng |
Khuyến nghị thực tế: nếu nhóm chưa đủ lớn để vận hành 5-7 nền tảng bảo mật riêng biệt, hướng nền tảng đơn thường hợp lý hơn.
Thay VPN trước hay Gateway trước?
| Hướng bắt đầu | Ưu điểm | Nhược điểm |
|---|---|---|
| ZTNA trước | ROI rõ, người dùng thấy ngay lợi ích, dễ tạo đà | Cần kiểm kê private app và identity group tốt |
| Gateway trước | Có khả năng quan sát traffic Internet sớm | Dễ gây ma sát nếu TLS inspection triển khai quá nhanh |
Với phần lớn tổ chức, mình sẽ bắt đầu từ ZTNA cho một nhóm ứng dụng nội bộ cụ thể, sau đó mới mở rộng Gateway/DLP.
Lý do: thay VPN là trường hợp sử dụng dễ chứng minh giá trị nhất. Người dùng thấy ít ma sát hơn, nhóm bảo mật có log rõ hơn, chủ sở hữu ứng dụng hiểu lợi ích nhanh hơn.
Big bang hay triển khai tăng dần?
Không nên làm kiểu big bang.
Chuyển đổi SASE/Zero Trust nên đi theo giai đoạn:
| Giai đoạn | Phạm vi | Mục tiêu |
|---|---|---|
| Giai đoạn 1 | Thí điểm nội bộ Security/IT | Xác nhận identity, posture, routing, logging |
| Giai đoạn 2 | 5-10 private apps | Thay VPN cho trường hợp sử dụng rõ ràng |
| Giai đoạn 3 | Nhóm engineering/admin | Áp dụng device posture và MFA |
| Giai đoạn 4 | Gateway DNS/HTTP | Kiểm soát traffic Internet/SaaS |
| Giai đoạn 5 | DLP/CASB/RBI | Bảo vệ dữ liệu và quy trình rủi ro cao |
| Giai đoạn 6 | Tối ưu | IaC, dashboard SIEM, rà soát chính sách, quản trị ngoại lệ |
Triển khai Zero Trust tốt giống một chương trình chuyển đổi nền tảng hơn là một dự án cài công cụ.
Bài học từ triển khai thực tế
1. Identity là điểm bắt đầu, không phải WARP
Nhiều nhóm bắt đầu bằng việc cài agent cho toàn bộ laptop. Làm vậy tạo cảm giác tiến độ nhanh, nhưng chưa chắc tạo kết quả bảo mật tốt.
Nếu identity group chưa sạch, vòng đời người dùng chưa rõ, SCIM chưa ổn, device posture chưa đáng tin, thì chính sách phía sau sẽ rất khó quản trị.
Thứ tự tốt hơn, identity trước, WARP sau:
2. Đừng bật tất cả khả năng cùng lúc
Cloudflare One có nhiều thứ hấp dẫn: Access, Gateway, Tunnel, WARP, DLP, CASB, RBI, DEX. Nhưng bật quá nhiều tính năng cùng lúc sẽ làm truy nguyên rất khó.
Khi người dùng báo lỗi, bạn sẽ không biết lỗi nằm ở đâu:
- IdP?
- Access policy?
- Device posture?
- WARP profile?
- DNS policy?
- Split tunnel?
- Gateway inspection?
- Tunnel route?
- Origin app?
Hãy chọn một trường hợp sử dụng có pain rõ nhất, làm đến nơi đến chốn, rồi mới mở rộng.
3. Logging phải thiết kế từ đầu
Zero Trust không chỉ là allow/block. Nó còn là khả năng kiểm toán.
Tối thiểu nên trả lời được:
- Người dùng nào truy cập?
- Thiết bị nào?
- Ứng dụng nào?
- Policy nào khớp?
- Kết quả allow hay block?
- Lý do chặn là gì?
- Posture nào fail?
- Source IP/location là gì?
- Request/session ID là gì?
- Log đã về SIEM chưa?
Nếu không có log tốt, mỗi sự cố sẽ biến thành tranh luận giữa helpdesk, network, nhóm bảo mật và nhóm ứng dụng.
4. Private routing là phần dễ bị đánh giá thấp
Với private app đơn giản, Cloudflare Tunnel khá dễ chạy. Nhưng ở enterprise, vấn đề thật sự thường nằm ở định tuyến:
- CIDR overlap
- Route ownership
- Split tunnel mode
- Local domain fallback
- DNS resolver path
- Nhiều môi trường dev/uat/prod
- Nhiều VPC/datacenter
- Giao thức non-HTTP
- Kiểm soát truy cập theo port
Đừng xem Tunnel chỉ là connector. Hãy xem nó là một phần của kiến trúc truy cập nội bộ.
5. Vòng đời policy cần được quản trị như code
Dashboard rất tiện cho giai đoạn thí điểm. Nhưng production ở quy mô lớn nên có IaC/GitOps.
Lý do:
- Rà soát được thay đổi
- Khôi phục dễ hơn
- Tránh trôi chính sách
- Tránh rule/list/group mồ côi
- Dễ chuẩn hóa quy ước đặt tên
- Dễ kiểm toán ai đổi gì, khi nào, vì sao
Với Cloudflare One, chính sách-dưới-dạng-mã (policy-as-code) là hướng nên nghĩ sớm, không nên chờ tới khi có vài trăm rule mới bắt đầu dọn.
Danh sách kiểm tra bắt đầu với Cloudflare One
Trước khi triển khai rộng, nên kiểm tra các điểm sau:
- Đã xác định trường hợp sử dụng đầu tiên: thay VPN, Gateway filtering hay SaaS/data protection?
- Đã có danh sách ứng dụng nội bộ cần bảo vệ?
- Đã mapping chủ sở hữu ứng dụng?
- Đã chuẩn hóa identity provider?
- Đã có quy ước đặt tên group?
- Đã bật hoặc lên kế hoạch SCIM?
- Đã xác định baseline device posture?
- Đã chọn nhóm thí điểm?
- Đã có đường khôi phục nếu người dùng không truy cập được?
- Đã xác định log nào cần đẩy về SIEM?
- Đã có dashboard cho allow/block/posture failure?
- Đã kiểm tra split tunnel và private route?
- Đã có xử lý ngoại lệ?
- Đã có người phụ trách cho Access app, Gateway policy và Tunnel route?
- Đã có kế hoạch chuyển từ bấm dashboard sang IaC?
Nên bắt đầu từ đâu?
Nếu mình phải bắt đầu lại từ đầu, mình sẽ không bắt đầu bằng câu hỏi “Cloudflare One có những tính năng gì?”
Mình sẽ bắt đầu bằng 5 câu hỏi:
-
Trường hợp sử dụng đầu tiên là gì? Thay VPN, filter Internet, bảo vệ SaaS hay chống data leak?
-
Tài nguyên nào quan trọng nhất? Ứng dụng nội bộ, private IP, SaaS app hay Internet destination?
-
Ai được truy cập? User group, nhà cung cấp, admin, developer, nhân sự thuê ngoài?
-
Thiết bị cần đạt điều kiện gì? Managed device, phiên bản OS, EDR, mã hóa ổ đĩa, domain joined?
-
Log cần trả lời câu hỏi kiểm toán nào? Ai vào đâu, khi nào, bằng thiết bị nào, policy nào cho phép hoặc chặn?
Khi trả lời được 5 câu này, việc ánh xạ sản phẩm sẽ rõ hơn rất nhiều.
Kết luận
Cloudflare One không nên được hiểu như một gói tính năng. Nó nên được hiểu như một kiến trúc đường đi thực thi chính sách cho enterprise access và security.
Ở tầng client, bạn có WARP và browser. Ở tầng identity, bạn có IdP, SCIM, user group và device posture. Ở tầng policy, bạn có Access, Gateway, DLP, CASB và Browser Isolation. Ở tầng tài nguyên, bạn có ứng dụng nội bộ, private network, SaaS và Internet.
Điểm mạnh của Cloudflare One không phải là mỗi khả năng đều sâu nhất thị trường. Điểm mạnh là khả năng gom nhiều kiểm soát vào một edge network và một mặt phẳng điều khiển tương đối nhất quán.
Nhưng công cụ không tự tạo ra Zero Trust. Cài WARP không đồng nghĩa đã Zero Trust. Tạo vài Access policy không đồng nghĩa đã thay được VPN. Bật Gateway không đồng nghĩa đã có kiến trúc secure web gateway.
Zero Trust chỉ bắt đầu có giá trị khi identity sạch, định tuyến rõ, chính sách có người phụ trách, log đầy đủ, ngoại lệ có quy trình và triển khai được thiết kế theo giai đoạn.
Nếu phải nhớ một câu, hãy nhớ câu này:
Cloudflare One là một nền tảng. Zero Trust là mô hình vận hành. SASE là kiến trúc. Đừng triển khai theo tính năng, hãy triển khai theo đường đi của request.
Tài liệu tham khảo
Trong series này:
- Tiếp theo → Part 2: SASE, SSE, Zero Trust, phân biệt thuật ngữ
- Xem toàn bộ → Series Cloudflare One Handbook
