TL;DR
HTTP filtering là lớp 3 của Gateway (sau DNS và Network): kiểm tra HTTP/HTTPS request sau khi Gateway kết thúc TLS, chạy rule URL/header/body, DLP, CASB. Khác DNS filter, chi tiết tới path/method/body chứ không chỉ domain.
TLS decryption là bắt buộc cho phần lớn rule HTTP hữu ích. Không giải mã thì chỉ thấy SNI + siêu dữ liệu kết nối, không thấy URL đầy đủ, header, body.
Bài này đi qua:
- Khi nào bộ lọc HTTP đáng giá thêm so với DNS.
- Cơ chế giải mã TLS: Gateway đóng vai MITM, Cloudflare root CA, cài ở endpoint.
- Cert pinning: ứng dụng nào từ chối giải mã (ngân hàng, Apple, một số app mobile) và cách đặt ngoại lệ.
- Ví dụ HTTP rule: chặn upload file, chặn đăng nhập shadow IT, khoá tenant CASB.
- DLP: khớp mẫu credit card/PII/source code trong body HTTP.
- Pháp lý & quyền riêng tư: GDPR/luật địa phương bạn phải cân nhắc trước khi giải mã traffic người dùng.
- Playbook triển khai: tránh sự cố ngày đầu khi bật giải mã.
Luận điểm chính:
Giải mã TLS là mạnh nhưng đắt, gánh nặng hiệu năng, rủi ro mất niềm tin người dùng, phức tạp pháp lý. Bật khi bạn cần DLP, CASB, hoặc kiểm soát URL chi tiết. Đừng bật chỉ để “thấy rõ hơn”. Bắt đầu với DNS + Network; giải mã chỉ khi có trường hợp sử dụng nghiệp vụ cụ thể.
Bài này là Part 12 của Cloudflare One Handbook, tiếp theo Part 11 (DNS) và trước Part 13 (Network L4).
Dành cho ai
- Kỹ sư bảo mật cần DLP, CASB, hoặc kiểm soát mức URL.
- Nhóm compliance yêu cầu kiểm tra traffic outbound (PCI, HIPAA, bí mật thương mại).
- Kỹ sư platform chuẩn bị triển khai CA cert qua MDM.
Bạn nên đã đọc:
- Part 9, WARP (client đưa traffic vào Gateway).
- Part 11, DNS filtering (lớp trước HTTP).
Sau bài này bạn sẽ:
- Biết khi nào nên bật giải mã TLS (và khi nào không).
- Có playbook cài Cloudflare CA qua MDM (Jamf, Intune, Chrome, GPO).
- Biết danh sách ngoại lệ cho ứng dụng cert-pinned để tránh sự cố.
- Viết được HTTP rule cho DLP và kiểm soát tenant CASB.
- Hiểu framework pháp lý/quyền riêng tư để thuyết phục nhóm pháp lý.
Bài này không nói về gì
- Network policy L4: Part 13 (lọc non-HTTP, chặn DoH, rule ứng dụng).
- Browser Isolation: part tiếp theo (render link rủi ro trong browser từ xa).
- Tích hợp CASB native chi tiết (Salesforce, Workday, kết nối Box API): chỉ nhắc qua.
- Email Security (Area 1): tách khỏi Gateway.
- Tinh chỉnh DLP nâng cao (mô hình ML tuỳ chỉnh, fingerprint chi tiết): tính năng enterprise, chỉ nhắc qua.
Khái niệm
- SWG (Secure Web Gateway): proxy chuyển tiếp kiểm tra traffic HTTP(S) từ client.
- TLS interception / MITM: Gateway làm trung gian, kết thúc TLS từ client, thiết lập lại TLS tới origin.
- Root CA: cert CA của Cloudflare mà endpoint phải tin cậy để không báo cảnh báo.
- Cert pinning: ứng dụng tự kiểm tra public key/cert origin, từ chối bất kỳ CA khác, giải mã fail.
- SNI (Server Name Indication): hostname trong TLS ClientHello, Gateway thấy được kể cả khi không giải mã.
- ECH (Encrypted ClientHello): thế hệ tiếp theo mã hoá SNI. Cần cấu hình endpoint tắt ECH khi muốn giải mã.
- DLP (Data Loss Prevention): khớp mẫu nội dung (credit card, PII, source code) trong upload.
- CASB (Cloud Access Security Broker): kiểm soát ứng dụng SaaS (Google Workspace, Microsoft 365, Salesforce) chi tiết: khoá tenant, kiểm soát hành động.
- Shadow IT: ứng dụng nhân viên dùng không qua phê duyệt của IT (Gmail cá nhân, Dropbox consumer).
Khi nào bộ lọc HTTP đáng giá thêm so với DNS
DNS đã chặn 60-80% threat phổ thông. HTTP thêm được gì?
DNS không thấy
- URL path:
legit-cms.com/adminvslegit-cms.com/public: DNS chỉ thấy cùng domain. - HTTP method: chặn POST nhưng cho GET.
- Header: User-Agent, Referer, Cookie.
- Body: upload file, dữ liệu form, JSON payload: DLP cần body.
- TLS client identity: cookie tenant cho CASB.
Hạ tầng dùng chung
- Workspaces (Google Docs, Microsoft 365): tất cả trên
docs.google.com/onedrive.live.com. - CDN: nhiều site cùng domain edge. Chặn DNS = chặn tất cả.
- Serverless (Vercel, Netlify, Cloudflare Pages): ứng dụng dev và phishing cùng domain gốc.
Trường hợp sử dụng chi tiết
- CASB: chỉ cho phép tenant Google Workspace của công ty, chặn
@gmail.comcá nhân. - DLP: chặn tải lên CSV có PII tới lưu trữ bên ngoài.
- URL rủi ro: chặn
evil-ui.legit-saas.comnhưng cho phép phần còn lại. - Kích hoạt Browser Isolation: click rủi ro sẽ cô lập, không chặn hẳn.
Nếu trường hợp sử dụng của bạn chỉ là “chặn domain malware” thì DNS đủ. Nếu cần DLP/CASB/URL chi tiết thì HTTP + giải mã TLS là cần thiết.
Giải mã TLS: cơ chế
Gateway làm MITM
Không giải mã:
Client ═TLS═> Gateway ═TLS═> Origin
(chỉ thấy SNI, size, timing)
Có giải mã:
Client ═TLS(A)═> Gateway ═TLS(B)═> Origin
↑ uses CF leaf cert ↑ real origin cert
(signed by CF root CA) (Gateway verifies as normal)
Gateway sinh leaf cert cho mỗi hostname theo thời gian thực, ký bởi Cloudflare root CA. Endpoint tin cậy root CA thì không có cảnh báo.
4 điều kiện để giải mã hoạt động
- Endpoint tin cậy CF root CA, cài sẵn qua MDM/GPO hoặc thủ công.
- HTTP policy bật “Decrypt”, Gateway UI → policy → bật hành động Decrypt.
- Hostname trong phạm vi giải mã, có thể giải mã tất cả, hoặc allowlist/blocklist.
- Ứng dụng không pin cert, nếu ứng dụng pin public key thì giải mã fail.
Chi phí
- CPU: client + Gateway giải mã rồi mã hoá lại. Phần cứng hiện đại xử lý 1Gbps+.
- Độ trễ: +5-15ms round-trip.
- Bộ nhớ: Gateway cần buffer đủ cho inspection.
- Quyền riêng tư: cẩn trọng, xem mục “Pháp lý & quyền riêng tư”.
Cài Cloudflare root CA ở endpoint
Tải CA
Cloudflare dashboard → Zero Trust → Settings → Network → Root Certificate → Download. Các định dạng:
.pem: Linux, Firefox..crt: Windows, Android..cer: iOS, macOS.
Một root CA cho tenant của bạn. Xoay ~5 năm, cần kế hoạch cài lại.
Windows: GPO
# Import to trusted root on domain-joined machines
Import-Certificate -FilePath "\\share\cloudflare-root.crt" `
-CertStoreLocation "Cert:\LocalMachine\Root"
GPO path: Computer Config → Policies → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities → import.
Xác nhận endpoint: certlm.msc → Trusted Root → tìm “Cloudflare”.
macOS: MDM (Jamf, Intune)
Jamf: Configuration Profile → payload Certificate → upload CA.
Intune: Devices → Configuration Profiles → Trusted certificate (macOS) → upload .cer.
Xác nhận: Keychain Access → System → tìm cert Cloudflare → “Always Trust”.
iOS / Android: MDM
iOS: cùng profile Trusted Certificate của MDM. Bước thêm: Settings → General → About → Certificate Trust Settings, người dùng phải thủ công bật tin cậy (thiết kế bảo mật iOS, MDM không thể tự bật).
Android: MDM push CA. Một số phiên bản Android yêu cầu xác nhận từ người dùng.
Linux
# Debian/Ubuntu
sudo cp cloudflare-root.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates
# RHEL/CentOS
sudo cp cloudflare-root.pem /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust
Firefox: store riêng
Firefox không dùng CA hệ thống. Tùy chọn:
- Policy enterprise:
policies.json→"Certificates": { "ImportEnterpriseRoots": true }, Firefox tin cậy root hệ thống. - Thủ công:
about:preferences#privacy→ Certificates → Import.
Chrome: store OS
Chrome dùng CA hệ thống. Không cần bước riêng.
Thứ tự triển khai
- Nhóm IT trước (1 tuần), xác nhận quy trình + truy nguyên.
- Nhóm pilot 5-10% người dùng (2 tuần), bắt các vấn đề tương thích ứng dụng.
- Triển khai diện rộng, MDM push tới tất cả thiết bị quản lý.
- Policy BYOD, yêu cầu cài trước khi truy cập tài nguyên công ty, ghi rõ.
Cert pinning: cái gì không giải mã được
Một số ứng dụng nhúng public key/cert fingerprint vào binary. CA chain không khớp thì từ chối kết nối, không cờ cảnh báo, chỉ fail.
Ví dụ thực tế
- Ứng dụng ngân hàng (Chase, BofA, Vietcombank…): hầu hết pin.
- Dịch vụ Apple: iCloud sync, App Store checkout. Pin nghiêm ngặt.
- Google Play và ứng dụng Google Workspace trên mobile: pin.
- WhatsApp, Signal, Telegram: pin.
- Chống malware (CrowdStrike, SentinelOne telemetry): pin để chống MITM.
- Một số VPN enterprise (kênh cập nhật Cisco AnyConnect): pin.
Ai quản pinning
- Ứng dụng mobile: pinning trong code ứng dụng, developer kiểm soát.
- Ứng dụng desktop: pinning trong binary.
- Web browser: HSTS + HPKP (HPKP đã bị loại bỏ, hiếm pin).
- Cert Transparency + public key fingerprint DNS (CAA, DNSSEC): không phải pin chặt.
Giải pháp
Không thể “sửa” pinning. Phải đặt ngoại lệ, không giải mã các hostname này.
# HTTP policy: Do Not Decrypt list
do_not_decrypt:
- "*.apple.com"
- "*.icloud.com"
- "*.mzstatic.com"
- "*.appstore.com"
- "*.whatsapp.net"
- "*.whatsapp.com"
- "*.signal.org"
- "*.vietcombank.com.vn"
- "*.openbank.com"
- "*.crowdstrike.com"
- "*.sentinelone.com"
- "*.windowsupdate.com" # Microsoft pins update CA
- "*.microsoft.com" # some paths pin
Cloudflare có danh sách curated sẵn cho các dịch vụ pin phổ biến. Bắt đầu với đó, thêm custom khi gặp ứng dụng fail.
Phát hiện cert pinning
Khi bật giải mã mà người dùng báo ứng dụng fail:
- Gateway logs → HTTP → lọc theo người dùng + hostname ứng dụng.
- Xem lỗi: “TLS handshake fail”, “Cert verification fail”.
- Kiểm tra danh sách pinning sẵn của Cloudflare, có trong đó không?
- Nếu không, thêm hostname vào Do Not Decrypt.
- Test: người dùng thử lại ứng dụng, chạy được.
Thực hành tốt: triển khai giải mã theo từng đợt, sẵn sàng thêm ngoại lệ khi người dùng báo cáo.
Ví dụ HTTP rule
1. Chặn tải lên file > 10MB tới lưu trữ ngoài
name: "Block large upload to external storage"
action: block
condition: |
http.request.method == "POST"
and http.request.body.size > 10485760 # 10MB
and any(http.request.uri.host in {
"wetransfer.com",
"sendanywhere.com",
"dropbox.com", # personal Dropbox, CASB whitelist company tenant separately
"pcloud.com"
})
block_page: "Large uploads to external storage require approval, contact IT"
2. CASB: chỉ tenant Google Workspace công ty
name: "Google Workspace tenant lock"
action: allow
condition: |
any(http.request.uri.host matches "*.google.com")
and http.request.header["X-GOOGLE-HD"] == "company.com"
name: "Block other Google Workspace tenants"
action: block
condition: |
any(http.request.uri.host matches "*.google.com")
and http.request.header["X-GOOGLE-HD"] != "company.com"
# Header X-GOOGLE-HD added by Google based on domain; Gateway can inspect once decrypted
3. DLP: chặn credit card trong body
name: "Block credit card number exfil"
action: block
condition: |
http.request.method == "POST"
and dlp.profiles["PCI-DSS"].matches
block_page: "Sensitive data detected, this action is blocked and logged"
# DLP profile "PCI-DSS": built-in pattern for Visa/Master/Amex/Discover
4. Chặn tải lên/soạn email cá nhân
name: "Block personal email"
action: block
condition: |
any(http.request.uri.host in {
"mail.google.com/u/0/#inbox", # personal, not workspace
"outlook.live.com", # personal outlook
"yahoo.com/mail"
})
and http.request.method == "POST"
# Block POST (compose/send) but allow GET (passive read)
5. Tải xuống rủi ro → Browser Isolation
name: "Isolate risky download"
action: isolate
condition: |
http.request.uri.path matches ".*\\.(exe|msi|dmg|bat|ps1)$"
and not (http.request.uri.host in $trusted_download_list)
# File renders in remote browser; user can choose to proceed or cancel
6. Chặn AI chat nếu có rủi ro DLP
name: "Warn AI chat"
action: warn
condition: |
any(http.request.uri.host in {
"chat.openai.com", "claude.ai", "gemini.google.com"
})
and http.request.method == "POST"
# Warn page: "Sensitive data policy applies. Do not paste customer PII or source code."
# User click "Proceed" → log + allow. For strict: switch action to "isolate" or "block".
DLP: Data Loss Prevention
Profile dựng sẵn
Cloudflare có DLP profile cho các trường hợp phổ biến:
- PCI: credit card Luhn + BIN.
- PII: SSN, passport, ID quốc gia.
- PHI (HIPAA): định danh y tế.
- Secrets: AWS access key, Google service account key, chặn private key.
- Source code: fingerprint framework phổ biến.
Profile tuỳ chỉnh
name: "Customer PII"
patterns:
- type: regex
value: '\\b\\d{9}\\b' # Vietnam national ID (simplified)
name: "VN ID"
confidence: medium
- type: regex
value: '\\b\\d{10,12}\\b' # phone
name: "VN phone"
confidence: low
# Logic: block if ≥ 2 PII types in same body
trigger: "count >= 2"
Kích hoạt (trigger)
- Block: từ chối request, ghi log sự kiện, thông báo người dùng.
- Warn: hiển thị trang cảnh báo, người dùng click để tiếp tục, log quyết định.
- Chỉ log: cho phép nhưng log (chế độ giám sát).
Triển khai DLP
- Chỉ log 2-4 tuần, đo false positive.
- Warn 2 tuần, giáo dục người dùng.
- Block rule tin cậy cao (credit card, secret rõ).
- Lặp các rule tin cậy thấp hơn theo phản hồi.
Cạm bẫy DLP
- False positive cao nếu regex quá lỏng: số 9 chữ số có thể là order ID, không phải ID quốc gia.
- Dữ liệu Base64/encoded đi vòng qua regex: DLP nâng cao cần giải mã nội dung (Cloudflare có giới hạn).
- Dữ liệu hình ảnh: mẫu text DLP không thấy text trong ảnh chụp màn hình. DLP dựa trên OCR hiện chỉ có enterprise.
- Body nén / mã hoá: kỳ vọng của khách là không kiểm tra được.
CASB: Cloud Access Security Broker
CASB làm gì
- Kiểm soát tenant: chỉ cho tenant công ty của Google/Microsoft/Dropbox.
- Kiểm soát hành động: cho tải xuống nhưng chặn chia sẻ ra ngoài.
- Quản trị dữ liệu: phân loại tài liệu nhạy cảm, ngăn chia sẻ ra ngoài.
- Phát hiện Shadow IT: log truy cập SaaS chưa được biết đến.
Các chế độ CASB của Cloudflare
Chế độ 1, Inline (qua bộ lọc HTTP của Gateway):
- Chặn thời gian thực dựa trên giải mã + kiểm tra header.
- Ví dụ: chặn Gmail cá nhân, khoá tenant Workspace.
- Nhanh, không cần tích hợp ứng dụng.
Chế độ 2, Dựa trên API (tích hợp CASB):
- Gateway kết nối API SaaS (Google Drive API, Microsoft Graph).
- Quét các file hiện có để tìm vi phạm.
- Phát hiện chia sẻ ra ngoài, quyền rủi ro.
- Chậm hơn (quét vài phút đến vài giờ).
- Cần cấp OAuth từ admin SaaS.
Enterprise điển hình dùng cả hai: inline để phòng ngừa thời gian thực, API để kiểm tra posture.
Thắng nhanh với CASB
- Google Workspace: kiểm tra tenant qua header
X-GOOGLE-HD. - Microsoft 365: header
Restrict-Access-To-Tenants(đặt qua rewrite khi decrypt). - Dropbox: header
X-Dropbox-Use(cũ) hoặc áp dụng qua OAuth. - Salesforce: hạn chế CIDR dựa trên IP ở phía Salesforce + Gateway áp dụng IP.
Pháp lý và quyền riêng tư: không thể bỏ qua
Giải mã TLS = bạn đọc traffic HTTPS của người dùng. Đụng tới quyền riêng tư/pháp lý.
GDPR (EU) / tương đương
- Minh bạch: người dùng phải biết traffic bị kiểm tra. Privacy policy + banner.
- Tương xứng: chỉ giải mã đủ cho mục đích cụ thể (bảo mật), không giám sát hàng loạt.
- Tối thiểu hoá dữ liệu: log tối thiểu cần thiết. Mặc định không log body đã giải mã.
- Đồng ý của nhân viên / BYOD: không được giải mã thiết bị cá nhân nếu không có đồng ý rõ ràng. BYOD nên loại trừ hoàn toàn hoặc yêu cầu opt-in.
Domain nhạy cảm phải loại trừ
Bắt buộc loại khỏi giải mã:
- Ngân hàng, tài chính.
- Y tế (bảo hiểm sức khỏe, cổng bệnh nhân).
- Chính phủ / thuế (người dùng có thể xử lý thuế cá nhân qua thiết bị công ty).
- HR/payroll của tài khoản cá nhân của nhân viên.
- Sức khỏe tâm thần, tôn giáo, chính trị.
- Dịch vụ pháp lý.
Không chỉ là “nice to have”, nhiều khu vực pháp lý yêu cầu theo luật.
Danh sách kiểm tra trước khi giải mã
- Privacy Impact Assessment (PIA) / DPIA đã hoàn tất.
- Nhóm pháp lý ký duyệt.
- Thông báo người dùng: công bố, banner, cập nhật privacy policy.
- Tài liệu phạm vi: giải mã cái gì, loại trừ cái gì.
- Chính sách lưu trữ: log tối đa bao lâu, ai truy cập.
- Data Processing Agreement với Cloudflare (GDPR Article 28: Cloudflare cung cấp DPA).
- Danh sách loại trừ: ngân hàng/y tế/chính phủ/HR/cá nhân.
- Policy BYOD rõ ràng: giải mã hay không.
- Phản ứng sự cố: log breach, phàn nàn từ người dùng.
Mặc định an toàn hơn
- Chỉ giải mã traffic quản lý bởi công ty (WARP enrollment qua IdP công ty).
- Loại trừ các category cá nhân phổ biến (Financial, Health, Government, Adult).
- Log chỉ siêu dữ liệu (URL, method, quyết định), KHÔNG log body.
- Kiểm tra body tại chỗ cho DLP: quét, kích hoạt rule, loại bỏ (không lưu).
- Lưu trữ ≤ 90 ngày cho HTTP logs (so với 1 năm+ cho sự kiện bảo mật).
Cấu hình tham khảo
Phạm vi giải mã khởi điểm
decrypt:
enable: true
default: decrypt
do_not_decrypt:
# Cert pinned services
- "*.apple.com"
- "*.icloud.com"
- "*.mzstatic.com"
- "*.whatsapp.*"
- "*.signal.org"
- "*.crowdstrike.com"
- "*.sentinelone.com"
# Privacy-sensitive (GDPR)
- category: "Financial Services"
- category: "Health and Medicine"
- category: "Government"
# Personal productivity (BYOD)
- "*.apple.com"
- "*.icloud.com"
- "mail.google.com/u/0/#inbox" # personal Gmail inbox path
- "outlook.live.com" # personal Outlook
# Updates/packages
- "*.windowsupdate.com"
- "*.microsoft.com/update"
- "*.microsoftonline.com/update"
- "*.apt.ubuntu.com"
- "*.debian.org"
- "*.npmjs.com"
- "*.pypi.org"
Cảnh báo thay vì chặn: để đào tạo người dùng
name: "AI assistants, warn about DLP"
action: warn
condition: |
any(http.request.uri.host in {
"chat.openai.com", "claude.ai", "gemini.google.com", "copilot.microsoft.com"
})
warn_page: |
Your organization allows AI assistants but reminds you:
- Do not paste customer PII, source code, or secrets.
- Do not rely on AI output for legal/medical/financial decisions.
[Proceed] [Cancel]
Cân nhắc bảo mật
Mức Gateway
- CA private key: Cloudflare quản lý, lưu trong HSM. Khách không phơi ra.
- Cert transparency: leaf cert của CF KHÔNG được đăng lên CT log công khai (liên quan quyền riêng tư).
- Xoay khoá: root CA ~5 năm. Kế hoạch cửa sổ cài lại.
Phía khách hàng
- Quản lý tin cậy root CA: compromise CA là attacker MITM được mọi thứ. Bảo vệ kênh phân phối (ký MDM, toàn vẹn GPO).
- Local admin / BYOD: người dùng có local admin có thể cài CA giả. Kiểm toán định kỳ.
- Playbook xoay cert: khi CF xoay, endpoint cần nhận cert mới trước khi hết hạn.
Bề mặt tấn công mới
- Người dùng thấy cert TLS “Cloudflare” cho
bank.comcó thể báo là tấn công MITM. Truyền thông trước. - Vượt cert pinning (jailbreak, app đã patch): attacker có thể giải mã sau khi root.
- Vượt DLP qua mã hoá trong body: nghiên cứu tấn công.
Vận hành và giám sát
Chỉ số
- Thông lượng giải mã: giám sát phía CF theo tenant.
- Số lần trúng Do Not Decrypt: đảm bảo không quá nhiều (> 30% traffic được miễn = cấu hình quá dễ dãi).
- Tỉ lệ lỗi TLS: tăng vọt = có thể cert pinning mới, endpoint lạ, hoặc vấn đề CA.
- Số lần DLP kích hoạt: baseline + bất thường (tăng = chiến dịch, tụt = rule hỏng).
- Vi phạm tenant CASB: theo người dùng, xác định hành vi rủi ro.
Cảnh báo
- Lỗi TLS > 5% cho bất kỳ PoP nào, gọi CF support.
- Rule DLP quan trọng kích hoạt (credit card, secret) > N/giờ, báo SOC.
- Người dùng kích hoạt DLP ≥ 3 lần / ngày, thông báo quản lý + đào tạo.
- Thông lượng Gateway tiến gần 80% giới hạn plan, lập kế hoạch dung lượng.
Đường ống log: HTTP
- Cùng cơ chế Logpush như DNS.
- Kích thước log HTTP lớn hơn nhiều (siêu dữ liệu theo request so với theo query).
- Dataset:
gateway_http. - Các trường: URL, method, response status, quyết định giải mã, trigger DLP.
- KHÔNG log body theo mặc định: quyền riêng tư + lưu trữ.
{
"Timestamp": "2026-05-13T09:22:17Z",
"UserID": "u_abc",
"Email": "alice@company.com",
"URL": "https://personal-dropbox.com/upload",
"Method": "POST",
"Host": "personal-dropbox.com",
"Action": "block",
"PolicyID": "p_block_personal_storage",
"DLPProfiles": [],
"Decrypted": true,
"UpstreamStatus": 0
}
Truy nguyên thường gặp
”Ứng dụng X không chạy sau khi bật giải mã”
- Gateway logs → HTTP → lọc theo người dùng + hostname ứng dụng.
- Lỗi “TLS handshake fail” hoặc “Cert mismatch”.
- Thêm hostname vào Do Not Decrypt.
- Test: người dùng thử lại.
- Ghi lại: cập nhật danh sách ngoại lệ pinning.
”Browser cảnh báo cert không tin cậy”
- Endpoint thiếu CF root CA. Kiểm tra trạng thái push MDM.
- Firefox dùng store riêng, chính sách chưa bật.
- Chrome trên Linux: kiểm tra
/etc/ssl/certs/+ chạyupdate-ca-certificates.
”DLP false positive”
- Người dùng tải lên file lành, DLP chặn.
- Log để xem profile nào kích hoạt + pattern khớp.
- Chỉnh ngưỡng confidence HOẶC pattern HOẶC thêm allowlist theo phòng ban/hostname.
- Nếu là true positive: giáo dục người dùng, có thể chuyển sang kênh được DLP phê duyệt.
”Giải mã làm ứng dụng ngân hàng mobile fail”
- Như dự kiến: ứng dụng ngân hàng pin cert.
- Thêm domain ngân hàng vào Do Not Decrypt.
- Người dùng test, phải chạy được.
”Hiệu năng giảm sau khi bật giải mã”
- Gánh nặng dự kiến nhỏ (5-15ms).
- Lớn hơn 100ms phải điều tra: vị trí PoP, giới hạn thông lượng tenant, rule cụ thể đắt.
- Liên hệ Cloudflare support để tinh chỉnh mức tenant.
”Phàn nàn quyền riêng tư từ nhân viên”
- Kiểm tra privacy notice đã gửi chưa.
- Xác nhận phạm vi giải mã khớp với công bố.
- Ghi lại trường hợp và chuyển tiếp cho pháp lý/HR.
- Cân nhắc bổ sung vào danh sách loại trừ.
Playbook triển khai: tránh sự cố
Giai đoạn 1: Lập kế hoạch (2-4 tuần)
- Pháp lý + quyền riêng tư ký duyệt.
- Ghi lại trường hợp sử dụng (chặn / phát hiện cái gì).
- Dự thảo danh sách loại trừ.
- Kế hoạch truyền thông cho nhân viên.
Giai đoạn 2: Triển khai CA (2-4 tuần)
- MDM push CA tới thiết bị được quản lý.
- Kiểm tra xác nhận (tuân thủ MDM).
- Policy BYOD + hướng dẫn cài thủ công.
- Nhóm IT trước, rồi nhóm pilot.
Giai đoạn 3: Giải mã chỉ log (2-4 tuần)
- Bật giải mã, nhưng mọi rule đặt hành động là log.
- Giám sát Gateway logs: tỉ lệ lỗi TLS, số lần trúng Do Not Decrypt.
- Thêm ngoại lệ khi người dùng báo fail.
Giai đoạn 4: Bật rule (tăng dần)
- Bắt đầu với tin cậy cao (cert bị compromise, category malware rõ ràng kèm ngữ cảnh HTTP).
- Hành động Warn để giáo dục người dùng.
- Hành động Block chỉ khi độ tin cậy cao + quy trình xử lý ngoại lệ đã sẵn sàng.
Giai đoạn 5: DLP + CASB
- Rule DLP chỉ log trước, chỉnh pattern.
- Rồi warn, rồi block dần.
- Kiểm soát tenant CASB bắt đầu với Google Workspace/Microsoft 365 (phạm vi rộng nhất).
Giai đoạn 6: Trưởng thành vận hành
- Runbook cho từng loại rule.
- Vòng lặp phản hồi từ người dùng.
- Rà soát hàng quý: thêm/bớt rule dựa trên bức tranh toàn cảnh threat + thay đổi nghiệp vụ.
Đánh đổi và quyết định thiết kế
| Quyết định | Phương án A | Phương án B | Khuyến nghị |
|---|---|---|---|
| Bật giải mã? | Luôn luôn (mọi traffic) | Không bao giờ (chỉ DNS + Network) | Chỉ khi có trường hợp sử dụng cụ thể (DLP, CASB, URL chi tiết). Không mặc định. |
| Cách cài CA | Chỉ MDM | MDM + thủ công | MDM + thủ công làm phương án dự phòng. Mở rộng với BYOD. |
| Phạm vi Do Not Decrypt | Tối thiểu | Rộng rãi | Rộng rãi, thêm category Finance/Health/Gov. Quyền riêng tư > khả năng quan sát. |
| Log body | Có (forensic) | Không (quyền riêng tư) | Mặc định không. Chọn tham gia theo nhóm người dùng rủi ro cao, có pháp lý ký duyệt. |
| Hành động DLP khởi điểm | Block | Warn / Log | Log 4 tuần, Warn 2 tuần, rồi Block. Đừng bắt đầu bằng block. |
| Giải mã BYOD | Bao gồm | Loại trừ | Loại trừ. BYOD chỉ có DNS + Network. Giải mã cần đồng ý + không vượt lằn ranh pháp lý. |
| AI chat (ChatGPT, Claude) | Block | Warn | Warn, cấm AI sẽ chặn năng suất. Thay bằng giáo dục về DLP. |
Danh sách kiểm tra: trước khi production HTTP giải mã
Pháp lý & compliance:
- PIA / DPIA đã hoàn tất.
- Nhóm pháp lý ký duyệt.
- Đã gửi thông báo người dùng (email + banner portal).
- Đã cập nhật privacy policy.
- Data Processing Agreement với Cloudflare.
- Chính sách lưu trữ (≤ 90 ngày cho chi tiết HTTP).
Triển khai CA:
- MDM push CA (Windows, macOS, iOS, Android).
- Fleet Linux quản lý đã cập nhật.
- Policy Firefox đã triển khai.
- Đã công bố hướng dẫn tự cài cho BYOD.
- Query xác nhận (tuân thủ endpoint).
Phạm vi giải mã:
- Danh sách Do Not Decrypt bao gồm: ngân hàng, y tế, chính phủ, HR cá nhân, cập nhật OS.
- Ứng dụng cert-pinned đã loại trừ (Apple, Microsoft update, agent bảo mật).
- Phạm vi BYOD được tách (loại trừ nếu không có đồng ý).
Rule:
- Rule đã test ở chế độ chỉ log trong 2-4 tuần.
- Đã tinh chỉnh pattern DLP theo tỉ lệ FP.
- Đã test kiểm soát tenant CASB cho từng SaaS.
- Trang Warn đã tuỳ chỉnh (thương hiệu công ty, liên hệ helpdesk).
Vận hành:
- Runbook: ứng dụng người dùng fail, chẩn đoán + quy trình ngoại lệ.
- Cảnh báo: lỗi TLS tăng vọt, trigger DLP quan trọng, giới hạn thông lượng.
- Logpush sang SIEM cho HTTP.
- Lịch rà soát hàng quý đã đặt.
Lan can quyền riêng tư:
- Mặc định không log body.
- Hạn chế truy cập HTTP logs (RBAC).
- Kiểm toán truy cập log (ai truy vấn cái gì, khi nào).
- Cơ chế khiếu nại của nhân viên.
Bài học thực tế
- Giải mã không miễn phí: chi phí hiệu năng, pháp lý, niềm tin người dùng. Chứng minh luận điểm kinh doanh trước khi bật.
- Danh sách cert pinning mọc hàng tháng. Mỗi bản phát hành ứng dụng mới có thể bắt đầu pin. Duy trì danh sách.
- BYOD luôn là điểm đau. Tách phạm vi hoàn toàn: BYOD = không giải mã.
- DLP false positive là chuyện thường tháng đầu. 40-60% trigger là lành. Đừng hoảng, chỉnh pattern.
- Giáo dục người dùng > chặn cứng. Warn + proceed kèm log thắng chặn cứng trong 80% trường hợp. Chặn cứng chỉ dành cho DLP tin cậy cao.
- Dung lượng log bùng nổ. HTTP logs to hơn DNS 10-100x. Lấy mẫu / gộp cần từ đầu.
- Firefox luôn là cái bẫy. Store cert riêng = đường triển khai riêng. Đừng quên.
- Đừng giải mã iCloud/WhatsApp dù tò mò. Rủi ro pháp lý + phản ứng người dùng lớn hơn mọi cái được.
- Test luồng ngoại lệ trước khi ra mắt. Người dùng có ứng dụng fail sẽ liên hệ ai, bao lâu sửa? Ghi lại.
Kết luận
Bộ lọc HTTP + giải mã TLS là lớp mạnh nhất của SWG nhưng cũng rủi ro nhất. Cần ghép với DLP/CASB cho trường hợp sử dụng cụ thể, khung pháp lý vững, và triển khai theo giai đoạn.
Khi làm đúng, bạn có:
- DLP ngăn rò dữ liệu do sơ suất.
- CASB khoá tenant, ngăn shadow IT.
- Browser Isolation hứng các click rủi ro.
- Kiểm soát URL chi tiết thay vì chặn cả domain.
Khi làm sai, bạn có:
- Người dùng mất niềm tin (cảnh báo cert, lo ngại quyền riêng tư).
- Sự cố ứng dụng do cert pinning.
- Rủi ro pháp lý do giải mã khu vực nhạy cảm.
- Vấn đề hiệu năng ảnh hưởng năng suất.
Nếu phải nhớ một câu:
Giải mã TLS là công cụ mạnh, dùng như dao mổ, không như cưa máy. Phạm vi hẹp, ý thức về quyền riêng tư, triển khai theo giai đoạn. Giải mã toàn bộ để “thấy rõ hơn” là phản mẫu.
Trong Part 13 chuyển sang Network policy (L4): chặn traffic non-HTTP, ngăn đi vòng DoH, rule ứng dụng (SSH, RDP, SMTP), và kết thúc block Policy & Filtering.
Tài liệu tham khảo
- Cloudflare Gateway HTTP policies
- TLS decryption overview
- Install Cloudflare root CA
- Cloudflare DLP
- Cloudflare CASB
- Browser Isolation
Trong series này:
- ← Part 11: Gateway DNS filtering
- Tiếp theo → Part 13: Network policy L4, non-HTTP traffic
- Xem toàn bộ: Series Cloudflare One Handbook