CASB: posture và misconfig SaaS (GWorkspace, M365, SF)

TL;DR

CASB (Cloud Access Security Broker) là cách bạn thấy và kiểm soát cái gì đang xảy ra bên trong SaaS tenant, nơi Gateway chỉ thấy “traffic ra cổng 443”. Mở OAuth admin phạm vi tới Google Workspace / M365 / Salesforce, CASB duyệt qua files, config, OAuth grants, sharing, và báo lại: file công khai chứa PII, app bên thứ ba đang có quyền đọc toàn bộ mail, tài khoản admin không bật MFA.

Nếu phải tóm tắt trong 2 câu:

API trước, inline sau. Inline (qua Gateway HTTP) chặn thời gian thực tốt nhưng chỉ thấy traffic đi qua proxy; API scan thấy trạng thái toàn tenant, không bị đi vòng qua bởi BYOD hay ứng dụng mobile. Lần scan đầu thường trả về 3,000-10,000 finding, đừng mất bình tĩnh, đừng chặn ngay.

Bài này không phải spec tính năng. Đây là 3 bài học từ đánh giá nhà cung cấp + 1 triển khai thực tế:

4 trụ cột Gartner là khung tư duy hữu ích nhưng không phải danh sách kiểm tra khi đi mua tool: đọc đúng phạm vi.
Đánh đổi Inline vs API: quan điểm rõ, nếu chỉ chọn 1, chọn API.
Rà soát shadow IT biến con số “60 SaaS đã duyệt” thành “240 SaaS đang dùng” trong tuần đầu.
Tenant lock (Google X-GOOGLE-HD, M365 Restrict-Access-To-Tenants) là thắng lợi nhỏ nhưng lớn nhất cho phòng ngừa BEC.
Khi nào KHÔNG dùng CASB: không phải ngành dọc nào cũng cần (khác với Access hay Gateway vốn phổ quát).

Bài này là Part 18, giữa block Advanced Security. Part 17 (Browser Isolation) xử lý traffic web bên ngoài; CASB xử lý SaaS bạn chủ động dùng.

Dành cho ai

Kỹ sư bảo mật vừa được giao đánh giá CASB (CF vs Netskope vs Defender for Cloud Apps).
SaaS admin Google Workspace / M365 cần chứng minh với auditor rằng tenant đã cấu hình theo thực hành tốt.
Compliance officer chuẩn bị SOC 2 audit, cần bằng chứng liên tục cho “SaaS controls tested quarterly”.
CISO muốn biết hoá đơn SaaS $2M/năm đang thực sự phủ baseline nào.

Đọc trước:

Part 5, IdP: mô hình tư duy OAuth, nếu chưa thiết lập IdP thì bước 1 cài CASB sẽ khó.
Part 12, HTTP + TLS decrypt: CASB inline chạy trên tầng này.

Không nói về

CSPM cho AWS/Azure/GCP IaaS: khác vùng bài toán. CASB hỏi “SaaS có config đúng không?”; CSPM hỏi “cloud account có config đúng không?”.
SSPM nhà cung cấp riêng (AppOmni, Obsidian): chuyên sâu hơn CF CASB cho SaaS-native, nhưng bài này tập trung tính năng native Cloudflare One.
Shadow IT tài chính (tối ưu chi phí): nhóm procurement lo, khác mục tiêu.

4 trụ cột Gartner và sai lầm khi đọc

CASB 4 pillar framework: visibility, compliance, data security, threat protection

Gartner định nghĩa 4 trụ cột: Visibility, Compliance, Data Security, Threat Protection. Đa số blog của nhà cung cấp nhắc lại 4 từ này rồi coi như xong. Vấn đề: đây không phải danh sách kiểm tra khi đi mua tool.

Thực tế triển khai, 4 trụ cột có mức ưu tiên rất khác nhau:

Trụ cột	Chi phí để có giá trị	Thời gian tới thắng lợi đầu tiên	ROI
Visibility (shadow IT)	Thấp, Gateway log đã có sẵn	1 ngày	Cao
Compliance (posture)	Trung bình, thiết lập OAuth + triage	1-2 tuần	Cao (mùa audit sau)
Data Security (DLP trong SaaS)	Cao, tinh chỉnh pattern nặng	1-3 tháng	Trung bình (FP đau)
Threat Protection	Cao, baseline ML + tích hợp SOC	3-6 tháng	Thấp tuần đầu, cao dần

Nếu mới bắt đầu CASB, Visibility + Compliance trước. Data Security và Threat Protection là nâng cao, chạm tới sau khi 2 cái kia ổn định. Demo của nhà cung cấp thường làm nổi Threat Protection (cool nhất) nhưng đó là trụ cột cuối nhóm của bạn sẽ thành thạo.

Sai lầm cá nhân mình đã thấy ở 2 CISO: mua CASB, cấu hình alert Threat Protection, SOC ngộp vì nhiễu → mute → sau 3 tháng CASB bị gán nhãn “không hiệu quả”. Thực ra tool OK, thứ tự bật sai.

Inline vs API: quan điểm: API trước

Inline CASB (Gateway HTTP proxy) vs API CASB (OAuth into SaaS tenant)

Hai chế độ khác nhau căn bản. Đa số bài viết nói “dùng cả hai”, đúng nhưng vô dụng. Câu hỏi thật: nếu lấy 1 cái trước, lấy cái nào?

Mình chọn API trước. Lý do:

Lý do 1: phạm vi phủ hoàn toàn khác

Inline thấy traffic đi qua Gateway. WARP disconnect, ứng dụng mobile native không qua proxy, thiết bị BYOD cá nhân truy cập Salesforce qua cellular: không có trong log.
API thấy toàn bộ trạng thái tenant: mọi file, mọi người dùng, mọi OAuth grant, mọi cấu hình. Không bị đi vòng qua bởi lựa chọn endpoint.

Tỉ lệ traffic thực sự qua Gateway so với tổng tương tác SaaS, trong org mình đo được: ~65%. 35% còn lại (mobile, BYOD, partner guest) chỉ API thấy.

Lý do 2: dữ liệu lịch sử

File share public 3 năm trước vẫn còn đó. Inline chỉ bắt đang share lúc này (qua Gateway). API scan toàn bộ drive, tìm ra sharing tồn đọng từ lâu, thường là 80% finding đầu tiên.

Lý do 3: config drift

Admin tắt MFA qua admin console (không qua browser). Inline mù. API scan chu kỳ polling tiếp theo phát hiện → cảnh báo. Đây là trường hợp SOC rất quan tâm vì insider threat / admin bị compromise thông tin xác thực.

Khi nào inline thắng

Hai trường hợp:

Tenant lock thời gian thực, chặn người dùng đăng nhập Gmail cá nhân trên máy công ty. API không làm được (bị động).
DLP chặn upload tại thời điểm, người dùng kéo file có PII lên Dropbox public, inline chặn ngay. API scan sẽ phát hiện 5 phút sau (nếu may).

Cả hai đều quan trọng nhưng ở tầng sau. Tầng trước: “mình có biết app OAuth nào đang có quyền đọc mail không?”, chỉ API trả lời được.

Khuyến nghị triển khai

Tuần 1-4: API kết nối tất cả SaaS quan trọng (Google Workspace, M365, Salesforce). Triage findings.
Tuần 5-8: Inline tenant lock cho Google + M365. TLS decryption đã có từ Part 12.
Tháng 3+: Inline DLP chặn upload (giao với Part 19).

First scan: phản ứng đúng khi 8000 finding trút xuống

Trong 1 lần triển khai CASB mình làm cho org 400 nhân viên (Google Workspace + M365 + Salesforce + GitHub), lần scan đầu sau 4 giờ trả về 8,247 finding.

Phản ứng đầu tiên của leadership: “sao nhiều thế? Tool hỏng à?”. Không hỏng, đây là misconfig tích luỹ 6 năm của 3 admin khác nhau + 2 lần tích hợp M&A. CASB không tạo ra misconfig; nó phơi ra.

Bóc tách 8,247

4,100 (50%): Drive file “anyone with link” share (nhiều trong đó là doc nội bộ hợp lệ dùng link share thay vì thêm người dùng tường minh).
1,800 (22%): Tài khoản cũ còn được bật (> 90 ngày không hoạt động).
920 (11%): OAuth app với phạm vi quá rộng (người dùng cũ cấp cho app truy cập Drive).
580 (7%): Rule forwarding ra ngoài (inbox → Gmail cá nhân, 1 trường hợp là cựu nhân viên, đáng lo ngại hợp lý).
420 (5%): SharePoint site public / Teams external access.
427 (5%): còn lại (GitHub public repo, Salesforce quyền quá mức, …).

Làm gì với 8k finding

Không chặn theo lô. Mình thấy nhóm khác đã làm: “script revoke tất cả public link” → 200 ticket trong 2 giờ, trong đó 150 là doc wiki nội bộ hợp lệ dùng link share.

Playbook thực tế:

Ngày 1: Critical severity (secret trong public file, OAuth với Directory.ReadWrite.All, forwarding ra ngoài từ user đang hoạt động) → triage thủ công trong 4 giờ đầu. Ước chừng 30-80 trường hợp (< 1% tổng).
Tuần 1: High severity (public file với DLP hit) → email người phụ trách kèm link tự khắc phục. Theo dõi bao nhiêu khắc phục so với bỏ qua.
Tuần 2-4: Medium (tài khoản cũ, role quá rộng) → xử lý theo lô với SaaS admin, không ping người dùng.
Tháng 2+: Low severity + ở mức chính sách (retention, default sharing) → đưa vào tenant baseline, không xử lý từng finding.

Đừng đặt SLA “24h đóng hết critical” ngay tuần đầu. Nhóm kiệt sức, tỉ lệ false positive chưa biết.

Nhịp ở trạng thái ổn định

Sau 6 tuần org mình làm, finding giảm từ 8,247 → 340, đa số là cái không thể hoặc không cần sửa (CEO forward email tới trợ lý là dự kiến). Đừng đuổi theo zero. Trạng thái ổn định: finding mới ~30-60/tuần, đóng 80% trong SLA.

Tích hợp SaaS: đọc theo threat

CASB SaaS integrations: Google Workspace, M365, Salesforce, Dropbox, GitHub, Atlassian

Thay vì liệt kê mỗi SaaS có tính năng nào, mình tổ chức theo threat chính của từng nhà cung cấp.

Google Workspace: OAuth app tràn lan

Threat chính: nhân viên cấp cho app bên thứ ba qua OAuth, phạm vi https://mail.google.com/ (đọc/ghi toàn bộ inbox). App kiểu này thường vô hại (productivity tool) nhưng vector compromise cao.

Kiểm tra của CASB: kiểm kê toàn bộ OAuth app, gắn cờ cái phạm vi rộng, khuyến nghị admin-consent-required cho phạm vi > low.

Cạm bẫy thực tế: tài khoản Google Workspace cũ (người đã nghỉ) vẫn có OAuth grant đang hoạt động. Thu hồi tài khoản không tự thu hồi grant. CASB bắt được.

Microsoft 365: inbox rule exfil

Threat chính: attacker compromise tài khoản → tạo inbox rule auto-forward tới email bên ngoài. Nạn nhân không thấy gì; attacker đọc mail công ty trong nhiều tháng.

Kiểm tra của CASB: scan mail rule, gắn cờ rule có forward ra ngoài.

Câu chuyện thực: 1 org mình rà soát, CASB phát hiện 12 tài khoản có rule forwarding tới Gmail/Yandex/Hotmail. 3 là BEC đang hoạt động (nạn nhân chưa biết).

Salesforce: profile “Modify All Data” tràn lan

Threat chính: role người dùng được cấp “Modify All Data” thoải mái. Developer cần query API → admin cấp profile “System Admin” cho tiện → ngồi đó 2 năm.

Kiểm tra của CASB: kiểm kê profile, khuyến nghị least-privilege.

Dropbox / Box / personal storage

Threat chính: “Team folder” share với email domain bên ngoài. Hoặc public link không có thời hạn.

GitHub: secrets + outside collaborator

Threat chính:

Repo public với credential đã commit (AWS key, private key).
Outside collaborator có quyền admin trên private repo.
PAT (personal access token) với phạm vi rộng.

Kiểm tra của CASB: quét secret + rà soát quyền.

Góc nhìn của mình: GitHub org phải có tích hợp CASB riêng (không chỉ “scan repos for secrets”). Rà soát outside collaborator hàng quý là tối thiểu.

Atlassian: truy cập ẩn danh

Confluence space “anyone can view”, dễ bị ai đó tìm thấy doc nội bộ trên Google. CASB phát hiện gắn cờ truy cập ẩn danh.

Slack / Teams: kênh ngoài tràn lan

Slack Connect shared channel với partner → partner có thể mời người khác → dữ liệu phân tán. CASB báo mỗi kênh ngoài mới.

Shadow IT: từ 60 SaaS approved tới 240 thực tế

Shadow IT discovery luồng from Gateway HTTP log to inventory report

Đây là trụ cột Visibility thực sự có giá trị. Câu chuyện thực:

Nhóm procurement: “Chúng ta duyệt 60 SaaS.”
Lần scan đầu Gateway log: “Bạn có 247 SaaS đang hoạt động.”
Đối chiếu với báo cáo chi phí: “50 SaaS có giấy phép trả phí; 197 là free tier hoặc chỉ OAuth-grant (AI plugin, CRM helper, meeting note AI).”

AI tràn lan 2024-2026

Xu hướng nặng nhất: AI plugin. Mỗi tuần nhân viên thử tool mới, ChatGPT plugin, Claude extension, Perplexity, Cursor, biến thể Copilot. Tool nào cần OAuth là tự động chia sẻ dữ liệu công ty. Phần lớn nhà cung cấp không có hợp đồng enterprise.

Trong org 400 người mình nhắc, 34 SaaS liên quan AI được phát hiện trong tháng đầu 2025. 12/34 có dữ liệu xử lý không rõ (ai sẽ train model trên đầu vào?).

Khung hành động

Không phân loại SaaS chỉ theo “risk score CASB gợi ý”. Điểm lấy từ threat intel công khai, không tính ngữ cảnh org của bạn.

Dùng 4 tầng:

Sanctioned: được duyệt, bật tích hợp CASB, áp dụng tenant lock nếu có.
Tolerated: trường hợp sử dụng hợp lệ, không có hợp đồng enterprise, giám sát chặt, cân nhắc chặn download/share.
Transitional: đang trong quá trình rà soát. Cho phép tạm thời, đặt hạn quyết định (4 tuần).
Blocked: vi phạm rõ hoặc threat intel đỏ.

Nhận định quan trọng: nhóm “tolerated” không phải né tránh. Nhân viên dùng tool vì nó giải quyết vấn đề bạn chưa giải quyết. Nếu chặn hết → shadow IT di cư sang mobile hotspot, mất luôn khả năng quan sát. Cho phép kèm lan can > chặn để tạo động lực đi vòng qua.

Nhịp khám phá

Hàng ngày: scan hostname mới, ML cluster thành SaaS ứng viên.
Hàng tuần: thay đổi xu hướng (SaaS mới, số người dùng tăng > 20%, traffic spike).
Hàng tháng: quyết định hành động theo lô: chuyển tolerate → sanctioned hoặc block.
Hàng quý: rà soát toàn bộ chính sách với leadership.

Lưu ý về chi phí: volume Gateway log cho khám phá shadow IT không rẻ. Thảo luận ở Part 14 về R2 data lake áp dụng trực tiếp.

Tenant lock: thắng lợi đơn lẻ lớn nhất về phòng ngừa BEC

Không phải trụ cột nổi tiếng nhưng ROI cao nhất. Chế độ CASB inline (qua Gateway HTTP filter Part 12) inject header khi người dùng truy cập Google/M365/Dropbox.

Google Workspace

name: "Google Workspace tenant lock"
applies_to: "*.google.com"
decrypt: required
policy_logic: |
  IF http.request.uri.host matches "*.google.com"
    AND http.request.header["X-GOOGLE-HD"] != "company.com"
  THEN block

X-GoogApps-Allowed-Domains là header Gateway inject vào request tới Google để giới hạn đăng nhập chỉ domain công ty. Nếu người dùng cố đăng nhập personal@gmail.com trong browser công ty → Google thấy header → chặn với trang “IT policy: use company Google account only”. (Ví dụ policy ở trên minh hoạ ý tưởng; tên header chính thức là X-GoogApps-Allowed-Domains, không phải X-GOOGLE-HD.)

Lý do BEC: attacker phish nhân viên, nạn nhân nhập credential vào trang đăng nhập giả company.com.phish.xyz. Tenant lock chặn vì đích đến không phải google.com thật. Đây là phòng thủ nhiều lớp sau khi link phish đi vòng qua bộ lọc DNS.

Microsoft 365

Dùng header Restrict-Access-To-Tenants do Gateway inject. Phía tenant M365 xác minh và áp đặt ranh giới tenant.

header_rewrite:
  path: "*.office.com/*"
  inject:
    - "Restrict-Access-To-Tenants: company.onmicrosoft.com, company.com"
    - "Restrict-Access-Context: <company-tenant-id>"

Dropbox không có header native

Dropbox không chuẩn hoá header nhận diện tenant. Đường vòng: chặn dropbox.com ở Gateway, chỉ cho phép qua IP egress dedicated (cách tiếp cận của M365/Google không áp dụng được). Hơi chắp vá; nếu Dropbox quan trọng, cân nhắc độ phủ chỉ bằng API CASB.

Đo lường

Trong org 400 người, sau khi bật tenant lock:

Sự kiện chặn Gmail cá nhân: ~15-25/ngày (phần lớn là tiện lợi, kiểm tra email cá nhân trong giờ làm).
Sự kiện chặn liên quan BEC: 1-2/tháng (domain phishing nhái google.com).
Than phiền: tuần đầu 8-10 ticket “sao không vào được personal email”. Cung cấp phương án: thiết bị cá nhân / điện thoại / giờ nghỉ qua wifi khách.

Top misconfig: và cái nào nên fix vs accept

Top 10 CASB findings with severity ratings

10 finding thường xuất hiện. Nhưng không phải cái nào cũng đáng chú ý như nhau. Mình xếp theo actionability × severity:

#	Finding	Độ khó sửa	Ưu tiên
1	OAuth app với phạm vi rộng (Mail.ReadWrite.All)	Dễ (revoke qua admin)	Sửa ngay
2	Rule forwarding inbox ra ngoài	Dễ (tắt ở mức tenant)	Sửa ngay
3	Xác thực cũ (basic auth, SMTP không MFA)	Trung bình (chuyển đổi 30d)	Sửa tháng 1
4	Public file với dữ liệu nhạy cảm (PII, credit card, secret)	Khó (case-by-case, nhiều FP)	Sửa 30% TP, chịu đựng 70%
5	Global Admin dư thừa	Trung bình (thiết kế lại role)	Sửa trong quý
6	Không MFA trên tài khoản admin	Dễ (áp dụng chính sách)	Sửa ngay
7	Tài khoản cũ > 90 ngày	Dễ (SCIM Part 7)	Theo lô hàng quý
8	GitHub không có branch protection	Trung bình (mỗi repo)	Tự áp dụng qua template
9	Thiếu chính sách lưu trữ	Ưu tiên thấp (trừ khi compliance)	Chấp nhận nếu không bị quy định
10	Confluence space ẩn danh	Khó (kiểm tra nội dung)	Sprint tập trung hàng năm

Tại sao một số “đừng sửa”

Thiếu retention trong môi trường dev = OK nếu chỉ là dữ liệu test. Đáng quan tâm compliance chỉ cho dữ liệu prod.
Public Drive share thực tế: 50-70% là wiki nội bộ dùng link share thay vì thêm tường minh. Không phải lỗ hổng.

Xử lý ngoại lệ

Bất kỳ finding nào nhóm chấp nhận không sửa phải có:

Ticket với lý do nghiệp vụ.
Người rà soát (không phải người chấp nhận).
Thời hạn (tối đa 1 năm, rà lại).
Kiểm soát bù trừ nếu áp dụng được (VD: public file được, nhưng trong folder có DLP scan liên tục).

Không có quy trình này → “rủi ro được chấp nhận” biến thành “rủi ro bị quên lãng”.

Findings workflow: làm sao không làm quá tải nhóm

Findings lifecycle: detect, triage, assign, remediate, verify, close

Mẫu SLA:

Severity	Triage	Khắc phục
Critical	1 giờ	24 giờ
High	4 giờ	1 tuần
Medium	1 ngày	2 tuần
Low	1 tuần	1 tháng

Đây là mẫu. SLA thực tế điều chỉnh theo quy mô nhóm + volume finding. Org 400 người, 1 kỹ sư bảo mật bán thời gian → Critical 4h triage thực tế hơn.

Nút thắt cổ chai mình hay thấy

Triage 1h không khả thi nếu volume finding > 50/ngày. Giải pháp: tự gán severity, tự đóng FP hiển nhiên (domain dữ liệu test, wiki nội bộ).
Gán người phụ trách mơ hồ: “Drive public file” người phụ trách là ai? Chủ file? Chủ sở hữu dữ liệu? Trưởng phòng? Cần quyết định rule trước: mặc định người phụ trách = người sửa gần nhất; chuyển lên nếu người sửa gần nhất đã nghỉ.
Ngoại lệ chồng đống: finding được chấp nhận không có thời hạn → quý sau auditor hỏi “sao vẫn mở?”. Buộc phải có ngày hết hạn.

Tích hợp thực tế

Jira/ServiceNow: finding → ticket tự động với nhãn severity.
Slack đến người phụ trách: thông báo kèm nút “finger-click” khắc phục cho trường hợp đơn giản (revoke share, tắt rule forwarding).
Email tóm tắt hàng tuần cho quản lý: số ticket mở theo nhóm.
Dashboard: xu hướng MTTR. Nếu MTTR tăng → nhóm quá tải → đàm phán giảm ưu tiên.

Privacy: CASB scan khi nào cross line

CASB scan nội dung, body file, subject email, message Slack. Đây là thông tin nhạy cảm về privacy, đặc biệt ở EU (GDPR Art. 88 về giám sát nhân viên).

Thông báo bắt buộc

Sổ tay nhân viên nhắc phạm vi giám sát SaaS.
Banner hoặc wiki doc truy cập được.
Cụ thể: cái gì scan (file trong Drive công ty), cái gì không (Gmail cá nhân, Slack DM giữa hai người dùng).

Rà soát pháp lý khi scan

Đức, Pháp, Bắc Âu: tham vấn works council (Betriebsrat / CE) thường bắt buộc. Dành 30-60 ngày.
Mỹ: ít quy định hơn nhưng hợp đồng lao động nên cover.
Việt Nam: ít nghiêm hơn nhưng thực hành tốt vẫn nên thông báo.

Data residency

CF CASB scan diễn ra ở region gần nhất. Nếu compliance yêu cầu đường đi dữ liệu chỉ trong EU, xác minh với nhóm CF, có thể cần tier trả phí.

Quyền xem findings

RBAC chặt: chỉ nhóm bảo mật thấy nội dung finding. SaaS admin thấy tóm tắt. Quản lý thấy chỉ số ở mức nhóm, không phải nội dung từng file.

Cấu hình tham khảo

Chính sách khởi điểm mình khuyến nghị cho org mới:

# 1. Google Workspace, API connect
google_workspace:
  admin_oauth_scopes:
    - drive.readonly
    - admin.directory.user.readonly
    - admin.reports.audit.readonly
  scan_cadence: daily
  alerts:
    critical:
      - oauth_scope_high      # Mail.ReadWrite.All or similar
      - mfa_not_enforced
      - external_forwarding_rule
    high:
      - public_drive_file_with_dlp_hit
      - stale_admin_account

# 2. Microsoft 365, API via Graph
microsoft_365:
  admin_consent: required
  scan_cadence: daily
  alerts:
    critical:
      - app_registration_high_privilege
      - mail_rule_external_forward
      - legacy_auth_enabled
    high:
      - sharepoint_public_share
      - teams_external_owner

# 3. Inline tenant lock (Gateway HTTP policy)
gateway_http:
  tenant_locks:
    google:
      host: "*.google.com"
      require_header: "X-GOOGLE-HD == company.com"
    microsoft:
      host: "*.microsoft.com"
      inject_header: "Restrict-Access-To-Tenants: company.com"

# 4. Shadow IT discovery
shadow_it:
  source: gateway_http_log
  cadence: daily
  retention: 90d
  alert_threshold:
    new_saas_per_week: 10
    user_count_spike: 20  # percent

Khi nào KHÔNG dùng CASB

Quan trọng như khi nào nên dùng:

Org chỉ có 1-2 SaaS (VD: chỉ Google Workspace). Tool Google Admin native + Workspace audit log là đủ. CASB quá mức cần thiết về chi phí.
Bị siết chặt trong khung cụ thể (FedRAMP High, HIPAA với BAA nghiêm). CASB scan nội dung = dữ liệu được xử lý; nhà cung cấp cần BAA. Nếu nhà cung cấp CASB chưa đạt, dùng tool compliance SaaS native + audit thủ công.
Startup giai đoạn sớm chưa có nhóm bảo mật riêng. Triage 500 finding/tuần là công việc toàn thời gian. Tốt hơn: tenant lock cơ bản (inline) + audit Google Admin thủ công hàng quý.
Stack on-prem hoàn toàn, exchange email on-prem, không cloud storage. CASB không có gì để scan.
Nhóm không có quyền admin OAuth. Nghe hiển nhiên nhưng trong enterprise, SaaS admin = IT trung tâm, không chia sẻ admin consent với nhóm bảo mật → độ sâu của CASB bị giới hạn.

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

“Chấp nhận rủi ro” cần có thời hạn. Nếu không, cuối cùng mọi finding đều được chấp nhận → tool vô dụng.
Tenant lock có ROI cao nhất trong inline. Nếu chỉ chọn 1 rule inline, chọn cái này.
Đặt kỳ vọng lần scan đầu với leadership. “Tool sẽ tìm 5,000+ finding tuần đầu. Đây là bình thường. Không phải tool hỏng.” Gửi email trước khi bật.
AI tràn lan là threat 2025. Mỗi tuần 1-3 AI tool mới nhân viên thử. Dashboard khám phá phải tách riêng nhóm AI.
Rà soát OAuth app hàng quý. Nhân viên nghỉ nhưng OAuth grant còn. Chỉ CASB thấy được gọn gàng.
GitHub cần tích hợp riêng. Độ phủ CASB chung cho GitHub không đủ; cần outside collaborator + secret + branch protection cùng nhau.
“Public share” phần lớn hợp lệ. Đừng tự revoke. Email người phụ trách tự xử lý tốt hơn.

Kết luận

CASB biến SaaS từ “hộp đen” thành “hộp kính”. Không tool khác làm được, Gateway chỉ thấy traffic, SIEM chỉ thấy sự kiện, CASB thấy trạng thái.

Bắt đầu với trụ cột Visibility + Compliance, API trước. Tenant lock inline là lớp hai. Data Security + Threat Protection là lớp ba, sau khi nhóm quen với quy trình findings.

Mỗi lần nhìn 8,000 finding đầu tuần, nhớ: đây là nợ tích luỹ nhiều năm, không phải thảm hoạ mới. Lên ngân sách triage thực tế, truyền đạt kỳ vọng với leadership, và đừng đuổi theo zero.

Trong Part 19 chuyển sang DLP, Data Loss Prevention, khớp mẫu trong nội dung. Giao với trụ cột 3 của CASB (Data Security), nhưng đi sâu vào kỹ thuật: regex + context + Luhn + EDM, khi nào tool nào thắng.

Tài liệu tham khảo

Trong series này:

← Part 17: Browser Isolation
Tiếp theo → Part 19: DLP deep dive
Xem toàn bộ: Series Cloudflare One Handbook