✳ The reference desk / In practice

CASB

A control point for observing or constraining use of cloud services, including unsanctioned ones.

Cloud access security broker

What it means

A CASB helps an organization understand and control how people use cloud applications. Some deployments inspect traffic passing through a proxy; others connect to an application programming interface (API) to inspect stored files, sharing settings, or activity. Those positions provide different coverage and response times. An integration that reviews files after upload cannot necessarily stop the upload itself. A useful evaluation begins with the services and actions the organization needs to see, then checks which integrations, identities, and devices the proposed control actually covers.

The idea at a glance / Cloud

Reviewing a stored copy is not stopping its transfer.

Compare API review after a stored transfer with enforcement on a covered upload path.

Synthetic F181 is retained by Maya. In one isolated DocSpace run, an upload stores public C181 before a read-only CASB API review records A181. In a separate fresh run, an inline policy refuses the selected external upload before storage, while an approved internal upload works. Sam’s restriction task Q181 is unapplied. No school records or real SaaS service are used.

CASB: Compare API review after a stored transfer with enforcement on a covered upload path. The explanation below describes the relationships.DocSpace · two isolated CASB runsAfter storage versus covered uploadMaya · retained original F181Same synthetic bytes in both runsNo original file is removedAPI-connected reviewStored C181 → finding A181Public C181 read still returns 200Traffic-path policyExternal 403 · no stored copyInternal 201 · copy read backSam · restriction task Q181Stored-copy removal unappliedApplication / verification openCONTROL POSITION CHANGES EFFECT

READ THE PICTURE

Position beside effect

API review finds an already-stored public copy; it does not remove it. A separate covered inline test refuses external storage and still permits the internal copy.

Keep in mindThe two runs have separate stores and explicit exercise policies. Read-only API review is not inline prevention; other API integrations may support later actions. Only the configured proxy path is gated. Identity, metadata and protected channels are assumed. No malware classification, prior download history, complete client coverage or actual CASB product is demonstrated.

Read the complete example
  1. Position beside effect. API review finds an already-stored public copy; it does not remove it. A separate covered inline test refuses external storage and still permits the internal copy. Maya’s original F181 remains in both isolated runs. In the API run, upload 201 actually stores public C181. The read-only connector retrieves that record, compares its sharing policy and stores finding A181; mutation is refused. A fresh public read still returns C181 with 200. Sam’s Q181 restriction remains applied=false and verified=false. In the inline run, a known synthetic label/destination rule returns 403 before the external origin receives an upload; its copy count stays zero. A permitted internal upload reaches its origin with 201 and an independent read returns the retained bytes. These are distinct stores and actual operation results, not a claim that post-upload review prevented the earlier transfer. Other clients, later remediation and historical copies are unassessed.

The two runs have separate stores and explicit exercise policies. Read-only API review is not inline prevention; other API integrations may support later actions. Only the configured proxy path is gated. Identity, metadata and protected channels are assumed. No malware classification, prior download history, complete client coverage or actual CASB product is demonstrated.

Diagram references: NIST SP 800-215: cloud controls, ZTNA and combined networking/security · Microsoft: supported session controls and paths that can bypass them

AN ILLUSTRATIVE SCENARIO

After-upload review beside inline prevention

The API run stores public C181, then records A181 without removing it; a fresh public read still works. A separate inline run refuses an external upload before storage and permits the internal copy. Vera’s F181 stays unchanged and Sloane’s Q181 is unapplied. Actual stored-copy readbacks explain the difference between deployment positions.

Put it to work

  1. Inventory approved cloud services and common ways staff use them. Identify sensitive data and decide which sharing or download behaviors warrant an alert or restriction.
  2. For each integration, document the permissions it requires, inspection position, supported actions, and delay. Test with synthetic records and review privacy implications before examining staff content.
  3. Pilot alert-only policies, tune noisy matches, and assign someone to investigate. Enable automatic restrictions only when their effect, exceptions, and reversal procedure are understood.

How to check your work

Create a synthetic file in each supported service and exercise permitted and prohibited sharing paths. Confirm the expected alert or block, measure the delay, and record which paths produced no evidence instead of calling them safe.

Connect the ideas

  • SSE

    Cloud-delivered security services such as secure web access without requiring the networking half of SASE.

  • DLP

    Controls that detect or block sensitive data leaving a channel such as email, web, or endpoint.

  • Shared responsibility

    The split of security duties between a cloud or SaaS provider and the customer, which varies by service.

Explore a field lesson

Find your next idea.

Tip: press / to open search. Escape closes this window.