Zero Trust với Cloudflare: Bảo vệ domain, email và hạ tầng doanh nghiệp
Hướng dẫn thực tế giúp doanh nghiệp xây dựng nền tảng Zero Trust với Cloudflare: bảo vệ DNS và domain, xác thực email bằng SPF, DKIM, DMARC, triển khai WAF, Cloudflare Tunnel, Access, WARP và Gateway.
Trong nhiều doanh nghiệp nhỏ và vừa, domain, email, website, API, máy chủ và công cụ quản trị thường được triển khai ở nhiều nơi khác nhau. DNS có thể nằm tại nhà đăng ký tên miền, email dùng Microsoft 365 hoặc Google Workspace, ứng dụng chạy trên VPS hoặc Kubernetes, còn nhân sự truy cập hệ thống nội bộ qua VPN truyền thống. Mỗi thành phần có một lớp bảo mật riêng, nhưng không có một chính sách thống nhất để xác minh người dùng, thiết bị và từng yêu cầu truy cập.
Zero Trust giải quyết vấn đề này bằng nguyên tắc: không mặc định tin cậy bất kỳ kết nối nào chỉ vì nó đến từ mạng nội bộ. Mỗi yêu cầu phải được xác minh dựa trên danh tính, trạng thái thiết bị, ngữ cảnh truy cập và quyền tối thiểu cần thiết. Với Cloudflare, doanh nghiệp có thể bắt đầu từ những lớp cơ bản như DNS, SSL/TLS và WAF, sau đó mở rộng sang Cloudflare Tunnel, Access, WARP và Gateway mà không cần thay đổi toàn bộ hạ tầng trong một lần.
Điểm quan trọng
Cloudflare không thay thế nhà cung cấp email như Microsoft 365 hoặc Google Workspace. Cloudflare quản lý DNS và bổ sung các lớp bảo vệ, còn việc gửi và nhận email vẫn do nhà cung cấp mail đảm nhiệm.
Hướng dẫn
Zero Trust với Cloudflare gồm những lớp nào?
Các kiểm soát và quyết định triển khai cần được đánh giá theo rủi ro thực tế.
Một kiến trúc thực tế có thể chia thành bốn lớp. Lớp thứ nhất bảo vệ domain và DNS. Lớp thứ hai bảo vệ email và danh tính thương hiệu. Lớp thứ ba bảo vệ website, API và các dịch vụ public. Lớp cuối cùng kiểm soát truy cập vào ứng dụng nội bộ, máy chủ và mạng private.
Hướng dẫn
1. Bảo vệ domain và DNS: nền móng của toàn bộ hệ thống
Các kiểm soát và quyết định triển khai cần được đánh giá theo rủi ro thực tế.
Khi chuyển DNS authoritative về Cloudflare, doanh nghiệp có một vị trí tập trung để quản lý record, bật DNSSEC, kiểm soát proxy, theo dõi thay đổi và tự động hóa bằng API hoặc Terraform. Tuy nhiên, việc chuyển nameserver chỉ là bước đầu. Một zone production cần được rà soát record, phân loại record nào được proxy qua Cloudflare và record nào phải để DNS only.
Các record cơ bản cần hiểu đúng
Các điểm cần triển khai
Các kiểm soát nên được áp dụng theo mức độ ưu tiên, rủi ro và khả năng vận hành thực tế.
A hoặc AAAA
ánh xạ hostname đến địa chỉ IPv4 hoặc IPv6. Website và API có thể bật proxy nếu giao thức được Cloudflare hỗ trợ.
CNAME
ánh xạ một hostname đến hostname khác. Thường dùng cho www, app, api hoặc dịch vụ SaaS.
MX
chỉ định máy chủ nhận email. MX luôn là DNS only.
TXT
dùng cho SPF, DKIM, DMARC, xác minh domain và nhiều cơ chế bảo mật khác.
CAA
giới hạn tổ chức phát hành chứng chỉ được phép cấp chứng chỉ TLS cho domain.
SRV
khai báo vị trí dịch vụ theo giao thức và cổng, thường gặp ở một số hệ thống mail hoặc communication.
Không proxy record mail
Các hostname phục vụ SMTP, IMAP, POP3 hoặc MX không nên bật proxy màu cam. Cloudflare reverse proxy tiêu chuẩn không proxy các giao thức mail này. Hãy để chúng ở trạng thái DNS only.
Baseline DNS production
Các điểm cần triển khai
Các kiểm soát nên được áp dụng theo mức độ ưu tiên, rủi ro và khả năng vận hành thực tế.
Bật xác thực đa yếu tố cho tài khoản Cloudflare và ưu tiên passkey hoặc security key
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Không dùng Global API Key trong automation
tạo API Token theo nguyên tắc least privilege.
Bật DNSSEC sau khi nameserver hoạt động ổn định và xác nhận DS record tại registrar
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Rà soát record cũ, record staging, IP không còn sử dụng và các subdomain có nguy cơ dangling DNS
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Dùng CAA nếu doanh nghiệp đã chuẩn hóa nhà cung cấp chứng chỉ
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Xuất hoặc quản lý DNS bằng Terraform để có lịch sử thay đổi và quy trình review
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Tách quyền quản trị DNS, security và billing
không chia sẻ một tài khoản chung cho cả đội.
Hướng dẫn
2. Bảo vệ email doanh nghiệp bằng SPF, DKIM và DMARC
Các kiểm soát và quyết định triển khai cần được đánh giá theo rủi ro thực tế.
Domain email có thể bị giả mạo ngay cả khi hệ thống mail không bị xâm nhập. Kẻ tấn công chỉ cần gửi email với địa chỉ From giống domain doanh nghiệp để thực hiện phishing, lừa thanh toán hoặc đánh cắp tài khoản. Ba cơ chế SPF, DKIM và DMARC giúp máy chủ nhận email xác minh nguồn gửi và quyết định cách xử lý thư không hợp lệ.
SPF: máy chủ nào được phép gửi email?
SPF là TXT record tại root domain, liệt kê các hệ thống được phép gửi email thay mặt domain. Doanh nghiệp cần tổng hợp đầy đủ Microsoft 365, Google Workspace, CRM, nền tảng marketing, hệ thống ticket và dịch vụ transactional email. Một domain chỉ nên có một SPF record; nếu có nhiều nguồn gửi, hãy hợp nhất chúng trong cùng record.
@ TXT "v=spf1 include:spf.protection.outlook.com -all"
Ví dụ trên phù hợp với domain chỉ gửi qua Microsoft 365, nhưng giá trị chính xác phải lấy từ nhà cung cấp đang sử dụng. Không sao chép record mẫu vào production nếu chưa kiểm kê toàn bộ nguồn gửi.
DKIM: email có đúng được ký bởi hệ thống hợp lệ?
DKIM sử dụng chữ ký mật mã để chứng minh nội dung email không bị thay đổi và được ký bởi hệ thống nắm private key. Public key được công bố qua DNS, thường dưới dạng TXT hoặc CNAME tại selector._domainkey. Mỗi nhà cung cấp có selector và record riêng.
selector1._domainkey CNAME selector1-example-com._domainkey.provider.example
DMARC: xử lý email giả mạo như thế nào?
DMARC yêu cầu SPF hoặc DKIM phải pass đồng thời domain phải alignment với địa chỉ From. Doanh nghiệp nên bắt đầu bằng p=none để thu thập báo cáo, sửa các nguồn gửi hợp lệ còn thiếu, sau đó nâng lên quarantine và cuối cùng reject.
_dmarc TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s; pct=100"
Không chuyển thẳng sang p=reject
Nếu chưa kiểm kê hết SaaS, CRM và hệ thống gửi mail, p=reject có thể làm email hợp lệ bị từ chối. Hãy quan sát báo cáo DMARC và triển khai theo giai đoạn.
Hướng dẫn
3. Bảo vệ website và API bằng Cloudflare WAF
Các kiểm soát và quyết định triển khai cần được đánh giá theo rủi ro thực tế.
Khi record website hoặc API được proxy qua Cloudflare, lưu lượng đi qua edge trước khi đến origin. Tại đây doanh nghiệp có thể áp dụng managed rules, custom rules, rate limiting, bot controls và các chính sách TLS. Mục tiêu không phải bật mọi rule ở mức cao nhất, mà là giảm bề mặt tấn công mà không gây false positive cho người dùng thật.
Bộ rule baseline nên có
Các điểm cần triển khai
Các kiểm soát nên được áp dụng theo mức độ ưu tiên, rủi ro và khả năng vận hành thực tế.
Managed WAF rules cho các lỗ hổng web phổ biến và payload độc hại
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Rate limiting cho /login, /forgot-password, /reset-password, /otp và các endpoint API tốn tài nguyên
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Managed Challenge cho traffic bất thường thay vì block ngay khi chưa đủ dữ liệu
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Chặn truy cập đến path quản trị không sử dụng hoặc chỉ cho phép qua Cloudflare Access
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Giới hạn HTTP method theo endpoint
ví dụ endpoint chỉ đọc không cần chấp nhận PUT hoặc DELETE.
Chặn hoặc challenge theo ASN, quốc gia hoặc threat signal khi phù hợp với mô hình kinh doanh
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Không cache response có dữ liệu cá nhân, token, session hoặc nội dung tenant-specific
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
(http.request.uri.path eq "/api/auth/login" and http.request.method eq "POST")
Expression trên có thể dùng làm điều kiện cho rate limiting rule bảo vệ endpoint đăng nhập. Ngưỡng cụ thể cần dựa trên lưu lượng thực tế, hành vi ứng dụng và cơ chế retry của frontend.
Hướng dẫn
4. Ẩn origin bằng Cloudflare Tunnel
Các kiểm soát và quyết định triển khai cần được đánh giá theo rủi ro thực tế.
Một website đã bật WAF vẫn có thể bị bypass nếu kẻ tấn công tìm được public IP của origin. Cloudflare Tunnel giải quyết vấn đề này bằng cách để cloudflared chủ động tạo kết nối outbound từ máy chủ hoặc cluster đến Cloudflare. Doanh nghiệp không cần mở inbound port từ Internet đến origin và có thể đóng public access của reverse proxy, dashboard hoặc API nội bộ.
Mô hình triển khai production
Các điểm cần triển khai
Các kiểm soát nên được áp dụng theo mức độ ưu tiên, rủi ro và khả năng vận hành thực tế.
Chạy ít nhất hai cloudflared connector cho workload quan trọng để tránh single point of failure
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Không nhúng tunnel token trực tiếp vào image hoặc Git repository
lưu trong Kubernetes Secret, secret manager hoặc vault.
Giới hạn egress và quyền của service account chạy cloudflared
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Giám sát trạng thái connector, restart, latency và lỗi kết nối
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Tách tunnel theo môi trường hoặc trust boundary thay vì gom toàn bộ production và staging vào một connector
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Với Kubernetes, ưu tiên deployment có PodDisruptionBudget và anti-affinity khi cluster có nhiều node
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Hướng dẫn
5. Cloudflare Access: thay VPN cho ứng dụng nội bộ
Các kiểm soát và quyết định triển khai cần được đánh giá theo rủi ro thực tế.
Cloudflare Access đặt một lớp identity-aware proxy trước ứng dụng. Thay vì chỉ kiểm tra người dùng có kết nối VPN hay không, Access có thể yêu cầu đăng nhập qua Microsoft Entra ID, Google Workspace hoặc nhà cung cấp danh tính khác, kiểm tra group, email domain, MFA và các tín hiệu thiết bị trước khi cấp quyền.
Các điểm cần triển khai
Các kiểm soát nên được áp dụng theo mức độ ưu tiên, rủi ro và khả năng vận hành thực tế.
Chỉ nhóm DevOps được truy cập Argo CD, Grafana hoặc dashboard hạ tầng
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Chỉ nhóm Finance được truy cập công cụ billing nội bộ
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Nhà thầu chỉ được truy cập một ứng dụng trong thời gian dự án
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Service-to-service sử dụng service token hoặc mTLS thay vì tài khoản người dùng
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Ứng dụng staging có thể được bảo vệ bằng Access dù vẫn dùng hostname public
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Access không chỉ là màn hình đăng nhập
Chính sách nên dựa trên group từ IdP, trạng thái thiết bị và mức độ nhạy cảm của ứng dụng. Không nên tạo một rule Allow chung cho toàn bộ email domain nếu ứng dụng chứa dữ liệu quan trọng.
Hướng dẫn
6. WARP và Gateway: kiểm soát thiết bị và lưu lượng người dùng
Các kiểm soát và quyết định triển khai cần được đánh giá theo rủi ro thực tế.
Cloudflare One Client, trước đây thường được gọi là WARP client, có thể mã hóa và chuyển DNS hoặc network traffic của thiết bị qua Cloudflare. Gateway áp dụng DNS, network và HTTP policies để chặn domain độc hại, phishing, malware, command-and-control hoặc các danh mục không phù hợp với chính sách doanh nghiệp.
Đối với tài nguyên private, Cloudflare Tunnel quảng bá private route, còn thiết bị đã enroll sử dụng client để truy cập CIDR nội bộ. Mô hình này phù hợp cho SSH, RDP, database, dịch vụ TCP/UDP hoặc ứng dụng không nên public ra Internet.
Các policy khởi đầu thực tế
Các điểm cần triển khai
Các kiểm soát nên được áp dụng theo mức độ ưu tiên, rủi ro và khả năng vận hành thực tế.
Block malware, phishing, newly observed domain và command-and-control theo mức độ phù hợp
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Chặn DNS over HTTPS không được quản lý để tránh bypass DNS policy
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Chỉ cho thiết bị compliant truy cập private network hoặc ứng dụng nhạy cảm
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Tách policy cho nhân viên, contractor và thiết bị quản trị
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Ghi log và quan sát trước khi block các category có nguy cơ ảnh hưởng công việc
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Hướng dẫn
Lộ trình triển khai Cloudflare Zero Trust cho doanh nghiệp SMB
Các kiểm soát và quyết định triển khai cần được đánh giá theo rủi ro thực tế.
Giai đoạn 1 — Domain và email
Các điểm cần triển khai
Các kiểm soát nên được áp dụng theo mức độ ưu tiên, rủi ro và khả năng vận hành thực tế.
Chuyển DNS sang Cloudflare và kiểm tra toàn bộ record
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Bật MFA, API Token least privilege và DNSSEC
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Chuẩn hóa SPF, bật DKIM cho từng nguồn gửi
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Triển khai DMARC p=none và theo dõi báo cáo
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Loại bỏ record và subdomain không còn sử dụng
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Giai đoạn 2 — Website và API
Các điểm cần triển khai
Các kiểm soát nên được áp dụng theo mức độ ưu tiên, rủi ro và khả năng vận hành thực tế.
Bật proxy cho hostname web phù hợp
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Cấu hình SSL/TLS Full (strict) với certificate hợp lệ tại origin
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Bật managed WAF rules, rate limiting và log review
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Thiết lập redirect HTTPS, security headers và cache rules an toàn
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Giới hạn origin chỉ nhận traffic qua Cloudflare nếu kiến trúc cho phép
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Giai đoạn 3 — Ứng dụng nội bộ
Các điểm cần triển khai
Các kiểm soát nên được áp dụng theo mức độ ưu tiên, rủi ro và khả năng vận hành thực tế.
Triển khai Cloudflare Tunnel với connector dự phòng
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Bảo vệ dashboard bằng Access và tích hợp IdP
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Phân quyền theo group và deny by default
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Loại bỏ public IP hoặc inbound firewall rule không còn cần thiết
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Thiết lập service token cho automation
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Giai đoạn 4 — Thiết bị và private network
Các điểm cần triển khai
Các kiểm soát nên được áp dụng theo mức độ ưu tiên, rủi ro và khả năng vận hành thực tế.
Enroll thiết bị bằng Cloudflare One Client
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Áp dụng Gateway DNS và network policy
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Kết nối private CIDR qua Tunnel
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Thêm device posture cho tài nguyên nhạy cảm
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Tích hợp log với SIEM hoặc nền tảng observability
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Hướng dẫn
Những sai lầm thường gặp
Các kiểm soát và quyết định triển khai cần được đánh giá theo rủi ro thực tế.
Các điểm cần triển khai
Các kiểm soát nên được áp dụng theo mức độ ưu tiên, rủi ro và khả năng vận hành thực tế.
Bật proxy cho MX hoặc hostname mail và làm gián đoạn SMTP/IMAP
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Tạo nhiều SPF record thay vì hợp nhất thành một record
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Đặt DMARC p=reject trước khi quan sát và xử lý toàn bộ nguồn gửi
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Cho phép toàn bộ email domain truy cập mọi ứng dụng nội bộ
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Vẫn để origin public dù đã dùng Cloudflare Tunnel
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Dùng một tunnel token hoặc API token quyền rộng cho nhiều môi trường
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Bật rule WAF quá mạnh nhưng không theo dõi false positive
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Xem Zero Trust như một sản phẩm mua một lần thay vì một mô hình vận hành liên tục
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Hướng dẫn
Checklist vận hành sau triển khai
Các kiểm soát và quyết định triển khai cần được đánh giá theo rủi ro thực tế.
Các điểm cần triển khai
Các kiểm soát nên được áp dụng theo mức độ ưu tiên, rủi ro và khả năng vận hành thực tế.
Review DNS và subdomain ít nhất hàng quý
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Theo dõi DMARC report và xử lý nguồn gửi không xác định
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Rà soát Access policy, user group và contractor hết hạn
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Theo dõi WAF events, rate limit và top blocked paths
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Kiểm tra tunnel health và diễn tập failover connector
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Rotate API token, service token và tunnel credential theo chính sách
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Kiểm tra restore, incident response và quy trình break-glass
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Đưa cấu hình quan trọng vào Terraform và pull-request review
Kiểm soát này cần được cấu hình, kiểm thử và theo dõi phù hợp với môi trường production.
Hướng dẫn
Kết luận
Các kiểm soát và quyết định triển khai cần được đánh giá theo rủi ro thực tế.
Cloudflare Zero Trust không nhất thiết phải bắt đầu bằng một dự án lớn. Với doanh nghiệp SMB, lộ trình hiệu quả nhất là chuẩn hóa domain và email trước, bảo vệ website và API bằng WAF, sau đó dùng Tunnel và Access để loại bỏ public exposure của ứng dụng nội bộ. Khi tổ chức đã có quy trình danh tính và thiết bị rõ ràng, WARP và Gateway sẽ mở rộng chính sách Zero Trust đến người dùng và private network.
Giá trị lớn nhất không nằm ở số lượng tính năng được bật, mà ở việc mọi yêu cầu truy cập đều được xác minh, ghi log và giới hạn theo đúng nhu cầu công việc. Đó là cách Zero Trust chuyển từ khẩu hiệu bảo mật thành một mô hình vận hành có thể kiểm soát.
FlowNexa
Xây dựng lộ trình Cloudflare Zero Trust phù hợp với hạ tầng hiện tại
FlowNexa hỗ trợ doanh nghiệp đánh giá DNS, email security, WAF, Cloudflare Tunnel, Access và private network; từ đó thiết kế lộ trình triển khai theo mức độ ưu tiên, ngân sách và rủi ro thực tế.
Liên hệ FlowNexa
https://flownexa.ai/vi/contact
