DLP: pattern, classification và 55% false positive

TL;DR

DLP (Data Loss Prevention) không phải “công cụ bật là chạy”. Đây là chương trình: tinh chỉnh liên tục, đào tạo người dùng, chấp nhận không hoàn hảo. Công cụ pattern quét nội dung đi qua Gateway hoặc nằm trong SaaS, tìm PCI/PII/secret/IP, nhưng bản thân nó phần lớn sai ban đầu.

Mình sẽ mở bài bằng một case study thật (công ty ~400 nhân viên, triển khai DLP 2024): tuần 1 tỉ lệ cảnh báo sai 55%. Tuần 6 xuống 3%. Khác biệt không phải công cụ khác, là phương pháp khác.

Bài này đi qua (theo thứ tự triển khai thực):

• Case study từng tuần từ FP 55% → 3%.
• Cấu trúc pattern: vì sao regex một mình vô dụng; Luhn + context + EDM là chìa khoá.
• Khi nào regex đủ, khi nào cần EDM (Exact Data Match): ý kiến cụ thể.
• Profile có sẵn + tuỳ chỉnh cho Việt Nam (CCCD, STK, SĐT).
• 5 lệnh mình chạy khi triage ticket FP.
• Khi nào KHÔNG nên triển khai DLP (không phải tổ chức nào cũng cần).

Part này là Part 19 của Cloudflare One Handbook, trong block Advanced Security.

---

Dành cho ai

• Kỹ sư bảo mật vừa bật DLP lần đầu, đang nhận 500+ ticket người dùng than “bị chặn oan”.
• Cán bộ tuân thủ cần bằng chứng “kiểm soát dữ liệu nhạy cảm” cho kiểm toán PCI/HIPAA/GDPR.
• Kỹ sư nền tảng nối DLP vào CI/CD cho quét secret.
• Quản lý đang đánh giá “có nên mua DLP không”: cuối bài có mục “khi nào bỏ qua”.

Đọc trước: Part 12 HTTP + TLS decrypt (DLP inline chạy ở tier này), Part 18 CASB (quét at-rest dùng chung API).

---

Case study: 55% → 3% FP trong 6 tuần

Tổ chức 400 người. Kết hợp Google Workspace + Salesforce + web app nội bộ. Phạm vi DLP: inline (Gateway HTTP upload/paste) + at-rest (CASB Drive).

Bật profile: PCI (credit card), PII (passport/CCCD), Secrets (AWS key, GitHub PAT, JWT), Source code (pattern React/Java).

Tuần 1: chỉ log, giai đoạn sốc

Chế độ hành động: chỉ log. Không chặn, không cảnh báo.

Tổng match: 14,320 trong 7 ngày.

Triage ngẫu nhiên 200 mẫu:

Profile	Total (7d)	True positive	FP	FP rate
PCI	4,100	1,230	2,870	70%
PII (CCCD 9-12 digit)	6,800	510	6,290	92%
Secrets (AWS key pattern)	1,200	680	520	43%
Source code	2,220	1,400	820	37%
Total	14,320	3,820	10,500	73%

Lãnh đạo hỏi: “công cụ hỏng à?” Không. Đây là kiểm tra thực tế cho ai nghĩ pattern DLP chạy ngay out-of-box.

FP đại diện:

• PCI: 70% FP vì order ID của app nội bộ có pattern giống regex Visa (4[0-9]{15}). Pattern khớp nhưng không phải credit card.
• PII CCCD 92% FP vì regex \b[0-9]{9}(?:[0-9]{3})?\b khớp mọi số 9 hoặc 12 chữ số: gồm cả số điện thoại có mã vùng, transaction ID, timestamp epoch milli.
• Secrets 43% FP vì regex AWS key khớp UUID, tiền tố hash.

Tuần 2: chẩn đoán + tinh chỉnh

Hành động: vẫn chỉ log. Tinh chỉnh profile.

# Lệnh 1: group FP theo hostname để thấy đâu là source chính
SELECT profile, dest_host, COUNT(*) FROM dlp_matches
WHERE week = 1 AND confirmed_fp = true
GROUP BY profile, dest_host ORDER BY 3 DESC LIMIT 20;

Kết quả: 65% FP đến từ 5 hostname nội bộ (CRM nội bộ, công cụ analytics, UI admin data warehouse). Các nơi này chứa đầy số giống credit card nhưng là order ID, user ID, transaction ID.

Hành động: danh sách ngoại lệ, bỏ qua quét DLP khi đích nằm trong domain admin nội bộ. Không phải điểm yếu, đây là phạm vi đúng (hệ thống nội bộ không cần kiểm tra exfil với chính nó).

dlp_exclusion:
  - dest_host_in: [".internal.company.com", "admin.crm.company.com", "dw.company.com"]
  - profiles: all

Thứ hai: bắt buộc context cho PCI + PII.

profile: PCI
pattern:
  regex: '\b4[0-9]{12}(?:[0-9]{3})?\b'
  validations:
    - luhn_mod10
    - bin_range_visa
  context_required:
    any:
      - within_50_chars: ["card", "visa", "mastercard", "cvv", "exp", "pan"]
      - same_line: ["payment", "billing"]

Bắt buộc context cắt FP rõ rệt: số 16 chữ số trơ xuất hiện trong database = không flag. Số 16 chữ số với “card number:” 30 chữ trước = flag.

Thứ ba: CCCD profile validate prefix.

profile: vietnam_cccd
pattern:
  regex: '\b[0-9]{12}\b'  # chỉ 12 digit (CCCD mới), bỏ 9-digit legacy
  validations:
    - prefix_check:
        # First 3 digits = mã tỉnh valid 001-096
        regex: '^(0(0[1-9]|[1-9][0-9])|0[1-8][0-9]|09[0-6])'
  context_required:
    any:
      - within_30_chars: ["CCCD", "căn cước", "CMND", "chứng minh"]

Mỗi thay đổi tăng precision nhưng giảm recall, sẽ miss một số trường hợp thật. Quyết định: chấp nhận được vì DLP không thay thế đào tạo + kiểm toán.

Tuần 3-4: vẫn log, đo

Sau tinh chỉnh, đo lại 200 mẫu:

Profile	Total	TP	FP	FP rate
PCI	480	430	50	10%
PII CCCD	120	98	22	18%
Secrets	720	620	100	14%
Source code	1,100	820	280	25%
Total	2,420	1,968	452	19%

Giảm đáng kể. Khối lượng xuống 10x vì ngoại lệ + bắt buộc context. Còn tinh chỉnh nữa.

Tuần 5: hành động cảnh báo cho PCI + Secrets

Với PCI + Secrets FP < 15%, bật cảnh báo. Người dùng thấy overlay “có dữ liệu nhạy cảm tiềm năng, tiếp tục?”, click-through được log.

Tỉ lệ click-through tuần 5:

• Cảnh báo PCI: 8% người dùng click “tiếp tục” (đa số chấp nhận dừng).
• Cảnh báo Secrets: 12% (quy trình dev: paste key vào UI secret manager, hợp lệ).

PII CCCD vẫn chỉ log (FP 18% cao, chưa đủ tự tin để cảnh báo).

Tuần 6: chặn quan trọng, trạng thái ổn định

Bật chặn cho 2 profile:

• AWS key rời tổ chức đến endpoint không được duyệt (không phải github.company.com, không phải secret-manager.corp).
• PCI với Luhn + BIN + context trong 20 ký tự.

Còn lại vẫn cảnh báo hoặc log.

6 tuần sau khi bật DLP đầy đủ, ticket về đường cơ sở (~3-5/tuần). Tỉ lệ FP đo ngẫu nhiên = ~3%.

Bài học: công cụ DLP nào cũng có FP cao tuần đầu. Công cụ tốt là công cụ dễ tinh chỉnh. CF DLP có context + Luhn + BIN + chuỗi validator có sẵn, nên tinh chỉnh nhanh, 6 tuần tới production.

---

Pattern anatomy: vì sao regex không đủ

Ví dụ Visa credit card. Regex đơn giản:

\b4[0-9]{12}(?:[0-9]{3})?\b

Khớp mọi chuỗi 13 hoặc 16 chữ số bắt đầu với 4. Vấn đề:

• 4532015112830366 trong order ID, log transaction: khớp.
• 4321098765432109 trong dữ liệu kiểm thử: khớp.
• 4111111111111111 (credit card kiểm thử chuẩn): khớp.

Chỉ dùng regex → 60-90% FP.

Sửa 1: Luhn checksum

Visa/Master/Amex dùng thuật toán Luhn (mod-10). Số 16 chữ số ngẫu nhiên fail Luhn ~90% trường hợp. Thêm Luhn validation cắt 80-90% rác.

# Luhn logic
def luhn_check(card):
    digits = [int(d) for d in card[::-1]]
    checksum = sum(d if i % 2 == 0 else sum(divmod(d*2, 10))
                   for i, d in enumerate(digits))
    return checksum % 10 == 0

Sửa 2: Dải BIN

6 chữ số đầu = BIN (Bank Identification Number). BIN Visa là tập con 4xxxxx, không phải toàn bộ. Thẻ kiểm thử 4111-1111-1111-1111 là dải kiểm thử, không phải vấn đề thật.

Sửa 3: Context

Đây là nước sốt bí mật. Số trơ trọi không có ý nghĩa. Số kèm “card number:” hoặc “visa” trong 50 ký tự = gần như chắc chắn là credit card.

Thực hiện: Cloudflare DLP hỗ trợ rule context_required. Trường hợp không có context → không flag.

Sửa 4: Context phủ định (nâng cao)

Thêm anti-pattern để giảm FP:

context_negative:
  - within_20_chars: ["order_id", "transaction_ref", "user_id", "txn"]

Số có “order_id” trong 20 ký tự → loại trừ tường minh. Cắt phần FP còn lại trong log app nội bộ.

Độ nhạy vs độ đặc hiệu

Strategy	Recall (catch TP)	Precision (low FP)
Regex only	99%	30%
Regex + Luhn	98%	55%
Regex + Luhn + BIN	97%	70%
Regex + Luhn + BIN + context	92%	95%
+ negative context	88%	97%

Mục tiêu production: precision > 95% cho profile chặn. Thấp hơn → người dùng tìm cách bypass công cụ. Recall 85-95% là đánh đổi chấp nhận được.

---

Built-in profiles: cái nào đáng bật từ ngày 1

CF cung cấp 6 danh mục có sẵn. Thứ tự ưu tiên theo góc nhìn của mình:

Tier 1: bật ngày 1 (ROI cao, có thể dự đoán)

1. AWS access key (AKIA...) + GitHub PAT (ghp_...) + private key block (-----BEGIN PRIVATE KEY-----).

   • Pattern rất rõ, FP < 5% ngay.
   • Mức nghiêm trọng cao (rò rỉ credential = vector breach trực tiếp).
   • Bật chỉ log tuần 1, chặn tuần 2.

2. Credit card với Luhn + BIN + context.

   • FP < 10% sau tinh chỉnh.
   • Bằng chứng tuân thủ PCI.

Tier 2: chỉ log tuần 1, lặp lại

3. National ID cho quốc gia mà tổ chức hoạt động (US SSN, pattern EU, VN CCCD).

   • FP cao (20-60%) cho chữ số không có cấu trúc.
   • Bắt buộc context + xác minh tiền tố.

4. URL database với mật khẩu (postgres://user:pwd@host/db).

   • FP trung bình (file config hợp lệ cũng khớp).
   • Chặn nếu đích bên ngoài.

Tier 3: nâng cao, đợi nhóm quen

5. Fingerprint source code.

   • Đa số FP vì code mã nguồn mở (có ở mọi nơi).
   • Chỉ hữu ích nếu tổ chức có framework độc quyền: cần fingerprint nội bộ.

6. PHI (y tế).

   • Chỉ cho tổ chức HIPAA. Pattern khó (Medicare ID, ICD-10 cần context hồ sơ bệnh nhân).
   • Thuê ngoài cho nhà cung cấp chuyên y tế (Proofpoint Healthcare, Symantec) nếu nghiêm túc.

Tier 4: mới nổi, thử nghiệm

7. Trọng số model / dữ liệu huấn luyện.
   • Bảo vệ AI IP nổi lên từ 2024+.
   • Pattern mới, chưa được kiểm chứng. Giữ chỉ log 3+ tháng trước khi chặn.

---

Pattern tuỳ chỉnh: locale Việt Nam

Pattern có sẵn không cover locale VN. Pattern tuỳ chỉnh cho 3 định dạng phổ biến:

CCCD (căn cước công dân)

name: "Vietnam CCCD"
pattern:
  regex: '\b[0-9]{12}\b'
  validations:
    - length_eq: 12
    - prefix_check:
        # 3 digit đầu = mã tỉnh (001-096 hiện hành)
        regex: '^(00[1-9]|0[1-8][0-9]|09[0-6])'
    - date_check:
        # Digit 4-5 = gender + century code (0-3 nam, 4-7 nữ theo thế kỷ)
        pos_4: "[0-7]"
context_required:
  any:
    - within_30_chars: ["CCCD", "căn cước", "CMND", "chứng minh", "ID number"]
confidence_threshold: high

9-digit CMND (ID cũ) bỏ vì tỉ lệ FP quá cao (mọi số 9 digit).

Số tài khoản ngân hàng

name: "Vietnam bank account"
pattern:
  regex: '\b[0-9]{8,16}\b'
context_required:
  any:
    - within_30_chars: ["STK", "số tài khoản", "account number"]
    - same_line_any_of: ["Vietcombank", "Techcombank", "BIDV", "MBBank", "VPBank",
                          "ACB", "Sacombank", "Agribank", "VietinBank"]
confidence_threshold: medium

Context tên ngân hàng quan trọng. Số tài khoản trơ không có ý nghĩa.

Điện thoại di động

name: "Vietnam mobile"
pattern:
  regex: '(?:\+?84|0)(3|5|7|8|9)[0-9]{8}\b'
context_required:
  any:
    - within_30_chars: ["phone", "số điện thoại", "SĐT", "di động", "mobile"]
confidence_threshold: low

Số điện thoại VN giờ đủ tiền tố chuẩn hóa (0[3|5|7|8|9]), chỉ regex cũng đủ precision. Context thêm độ tin cậy.

---

Exact Data Match: khi regex không đủ

Vấn đề regex không giải được

Danh sách khách hàng với 10.000 tên + email + phone. Regex cho “tên tiếng Việt” không tồn tại (tên đủ kiểu). Regex cho email khớp mọi email, không cụ thể khách hàng.

Cách EDM giải

1. Xuất dataset từ DB ra CSV: email, phone, customer_id, name.
2. Hash phía client mỗi field với HMAC-SHA256 + salt.
3. Tải lên danh sách hash (không phải dữ liệu thô) lên CF.
4. Engine quét hash nội dung đến, so với danh sách.
5. Khớp chính xác → flag với độ chắc chắn ~100%.

Ý kiến: khi nào dùng EDM

Dùng EDM khi:

• Dataset ổn định (danh sách khách hàng, danh sách nhân viên).
• Kích thước vừa (1K-1M bản ghi, kiểm tra giới hạn CF).
• Cần FP cực thấp (bằng chứng tuân thủ, phòng tranh chấp pháp lý).
• Dataset không quá nhiều PII (EDM đòi xuất ra filesystem: chính việc đó là rủi ro cần kiểm soát).

Bỏ EDM khi:

• Dataset thay đổi > 1 lần/ngày. Nhịp làm mới không kịp.
• Regex + context đạt precision cần (~95%). Chi phí thiết lập EDM không đáng.
• Dataset chứa PII độ nhạy cao mà xuất ra để hash là rủi ro thêm (mâu thuẫn với việc bảo vệ).

Cạm bẫy triển khai

• Salt hash phải an toàn, không rò (salt không nằm trong repo CF, quản lý tách biệt).
• Nhịp làm mới tối thiểu hàng tuần cho dataset đang hoạt động.
• Bản ghi bị xoá: khi khách hàng churn, bản ghi bỏ khỏi dataset. Có nên vẫn quét lịch sử 30 ngày để bắt exfil sau khi xoá? Quyết định chính sách.

---

Integration: Gateway inline vs CASB API

Cùng profile, 3 điểm áp dụng:

Gateway HTTP inline

• Thời điểm: người dùng đang tải lên / dán.
• Hành động: chặn thời gian thực.
• Độ phủ: chỉ lưu lượng đi qua Gateway (WARP + giải mã HTTP bật).
• Độ trễ: thêm 20-50ms cho quét.
• Cạm bẫy: file đã mã hoá / nén: DLP không quét được. Người dùng zip + mật khẩu = bypass.

CASB API at rest

• Thời điểm: sau khi tải lên, ở chu kỳ quét tiếp theo.
• Hành động: cảnh báo, phát hiện trong dashboard.
• Độ phủ: toàn bộ file trong tenant SaaS (trong Google Drive, SharePoint).
• Độ trễ: chu kỳ quét (1-24h).
• Bắt được: dữ liệu lịch sử: file tải lên 2 năm trước có CC bên trong.

Email outbound (Part 20)

• Thời điểm: người dùng gửi mail, trước relay.
• Hành động: chặn, cách ly, cảnh báo.
• Độ phủ: nội dung email + file đính kèm.
• Giao thoa: nhiều PII rò qua email tới đối tác (cc ra ngoài do nhầm).

Production: cả ba

Khôn ngoan là bật cả 3 với profile giao thoa. Người dùng dán CC vào form tải lên → Gateway inline chặn. Người dùng tải lên file lịch sử → CASB API bắt. Người dùng email đính kèm → Email DLP bắt.

Giao thoa = phòng thủ theo chiều sâu, không thừa (mỗi lớp miss khác nhau).

---

5 lệnh mình chạy khi triage ticket FP

Người dùng ping Slack: “em tải file báo cáo lên bị chặn, báo là credit card.” Playbook mình chạy:

Lệnh 1: định vị phát hiện

# CF dashboard → Logs → DLP → filter by user_email + timestamp
# Hoặc API
curl -H "Authorization: Bearer $TOKEN" \
  "https://api.cloudflare.com/client/v4/accounts/$ACC/gateway/logs?email=user@co.com&action=block&since=1h"

Output: event ID, profile kích hoạt, pattern khớp, đoạn nội dung.

Lệnh 2: lấy đoạn khớp

# Get specific event detail
curl -H "Authorization: Bearer $TOKEN" \
  "https://api.cloudflare.com/client/v4/accounts/$ACC/dlp/matches/$EVENT_ID"

Output: 200 ký tự quanh khớp. Quyết định: TP hay FP?

Lệnh 3: query DB: pattern có phổ biến trong dữ liệu nội bộ không

-- Chạy trong data warehouse
SELECT hostname, COUNT(*) AS matches,
       SUM(CASE WHEN confirmed_fp THEN 1 ELSE 0 END) AS known_fp
FROM dlp_events
WHERE profile = 'PCI'
  AND timestamp >= now() - interval '7 day'
  AND match_snippet LIKE '%<PATTERN>%'
GROUP BY hostname ORDER BY matches DESC;

Nếu cùng pattern xuất hiện 100x trên hostname CRM nội bộ → FP cấu trúc, thêm ngoại lệ.

Lệnh 4: kiểm thử pattern trên mẫu

# Local test: pattern change giảm FP không?
from dlp_test import apply_pattern
old_matches = apply_pattern(corpus, old_profile)
new_matches = apply_pattern(corpus, new_profile_with_negative_context)
print(f"Old: {len(old_matches)} matches, {fp_rate(old_matches):.1%} FP")
print(f"New: {len(new_matches)} matches, {fp_rate(new_matches):.1%} FP")

Corpus = nội dung bị chặn trong 1 tuần lịch sử (đã redacted).

Lệnh 5: triển khai tinh chỉnh

# Update profile via API, rollout
curl -X PATCH "https://api.cloudflare.com/client/v4/accounts/$ACC/dlp/profiles/$PID" \
  -d @updated_profile.json

# Monitor FP rate next 7d
# Alert nếu FP rate jump > 10%, có thể over-tighten

Commit thay đổi vào repo config (Terraform / git). Cần audit trail.

---

Triển khai theo giai đoạn: không phải tuỳ chọn

6 giai đoạn, 10-14 tuần:

1. Chỉ log (4 tuần), đường cơ sở FP, không chặn/cảnh báo.
2. Tinh chỉnh (2 tuần), danh sách ngoại lệ, bắt buộc context, ngưỡng.
3. Cảnh báo (2 tuần), đào tạo người dùng, đo click-through.
4. Chặn quan trọng (2 tuần), AWS key, PCI với context.
5. Quét at-rest (liên tục), CASB API quét lịch sử.
6. Tinh chỉnh liên tục (mãi mãi), rà soát FP hàng tháng, làm mới profile hàng quý.

Anti-pattern: bỏ qua giai đoạn 1-2, chặn ngay. Mình thấy 2 tổ chức làm vậy. Cả 2 phải lùi lại trong tuần đầu vì cơn bão helpdesk. Sau đó lãnh đạo mất niềm tin vào công cụ, triển khai lần hai khó hơn.

---

Khi nào KHÔNG triển khai DLP

Quan trọng như khi nào nên triển khai:

1. Tổ chức chưa có chính sách phân loại dữ liệu. DLP áp dụng chính sách; không có chính sách → không có gì để áp dụng. Phân loại trước (Bảo mật / Nội bộ / Công khai), DLP sau.

2. Nhóm bảo mật < 2 người. DLP triage 50-200 ticket FP/tuần. Công việc toàn thời gian cho 1 kỹ sư. Bán thời gian = tồn đọng, công cụ bị tắt.

3. Tổ chức chưa có HTTPS everywhere + giải mã TLS sẵn sàng. DLP inline cần giải mã (Part 12). Nếu không giải mã được (pháp lý chặn), DLP inline không thấy nội dung → chỉ CASB at-rest bao phủ ~50% kịch bản.

4. Tuân thủ không yêu cầu + không có mô hình mối đe dọa cụ thể. Chi phí DLP (giấy phép + vận hành) $200k+/năm cho tổ chức cỡ vừa. Biện minh bằng sự cố đã ngăn được hoặc đạt kiểm toán. Nếu không có lý do nào, dời lại.

5. Dataset quá biến động, startup ra sản phẩm mới hàng tuần, schema thay đổi liên tục. EDM làm mới không kịp; profile regex lỗi thời. Ổn định sản phẩm trước.

6. Quyền riêng tư không cho phép quét nội dung, hợp đồng công đoàn / works council chặn việc kiểm tra nội dung nhân viên. Rà soát pháp lý trước.

---

Bài học mình sẽ giữ

1. FP 40-70% tuần đầu là bình thường, không phải công cụ hỏng. Lên kế hoạch năng lực triage.
2. Bắt buộc context cắt FP 70-80% là thiết lập quan trọng nhất trong mọi profile.
3. Context phủ định (danh sách anti-pattern) cắt FP còn lại trong app nội bộ. Không profile có sẵn nào, cần tuỳ chỉnh theo từng tổ chức.
4. EDM tốn công thiết lập nhưng precision ~100%. Đáng làm cho danh sách khách hàng + danh sách nhân viên. Bỏ qua cho mục đích chung.
5. Cảnh báo > Chặn cho đa số pattern. Đào tạo người dùng làm được điều chặn không làm được, nội tâm hoá “đừng dán PII vào ChatGPT”.
6. Profile source code ROI thấp. Trừ khi có fingerprint độc quyền sẵn, bỏ qua.
7. Hành động chặn chỉ cho profile precision cao (AWS key > 95%, PCI với context). Precision trung bình → cảnh báo. Precision thấp → chỉ log mãi mãi.
8. Chỉ log mãi mãi không phải thất bại. Log cho điều tra pháp chứng + bằng chứng tuân thủ, không phải ngăn chặn.

---

Kết luận

DLP không plug-and-play. Là 6-12 tháng lặp đi lặp lại tới trạng thái ổn định. Công cụ nào cũng FP cao tuần đầu. Công cụ tốt = công cụ dễ tinh chỉnh.

CF DLP mạnh nhất ở: context_required, chuỗi validator Luhn + BIN, danh sách ngoại lệ, EDM có sẵn. Yếu nhất: fingerprint source code (chung chung), DLP ảnh (không có OCR).

Nếu phải nhớ một câu:

DLP là chương trình, không phải công cụ. Precision > 95% và FP < 5% là mục tiêu 2 tháng, không phải tuần 1. Đuổi theo sớm hơn = kiệt sức nhóm + người dùng bypass.

Trong Part 20 phần cuối Advanced Security: Email Security (Area 1 / Cloudflare Email Security), chống phishing, BEC, phát hiện mạo danh. DLP ở Part 19 giao với quét email outbound; Part 20 nói sâu về bản đồ mối đe dọa email và cạm bẫy khi triển khai DMARC.

---

Tài liệu tham khảo

• Cloudflare DLP overview
• Built-in profiles
• Custom profile
• Exact Data Match
• Luhn algorithm
• Vietnam CCCD format

Trong series này:

• ← Part 18: CASB
• Tiếp theo → Part 20: Email Security Area 1
• Xem toàn bộ: Series Cloudflare One Handbook