IM Engineer Study Notes
← Back to list
Security & Privacy
#CASB#섀도IT#클라우드보안#DLP#SSE
Last updated · 2026-09-28

CASB (Cloud Access Security Broker)

1. Overview

CASB is a policy enforcement point that sits between cloud service consumers (devices and users) and cloud service providers (SaaS/IaaS/PaaS), consistently enforcing an organization's security policies along the cloud access path. First coined by Gartner in 2012, it is defined by four pillars: Visibility, Compliance, Data Security, and Threat Protection.

The fundamental driver behind CASB's emergence is that enterprise work shifted rapidly from on-premises applications to SaaS, creating areas that traditional perimeter security could not control. In the past, data and applications lived inside the corporate data center, so placing firewall, proxy, and DLP appliances at the perimeter allowed most traffic to be inspected. As work moved to SaaS such as Microsoft 365, Salesforce, Google Workspace, and Slack, however, paths opened for employees to reach the cloud directly from unmanaged personal devices or off-corporate networks, bypassing the perimeter firewall. Security teams found themselves unable to even determine "who is using which cloud app."

The Shadow IT problem grew especially severe. As departments and individuals adopted SaaS on their own without IT or security approval, organizations were exposed to the risk of corporate data circulating outside their control. Indeed, many surveys have reported that the number of cloud apps an enterprise actually uses is several to over a dozen times the number the IT department is aware of. On top of this, regulations such as the Personal Information Protection Act, GDPR, and financial-sector cloud usage guidelines demanded control over the location, encryption, and access of cloud data, creating the need for a broker that provides visibility and control over cloud usage from a single point. CASB fills this gap with the idea of "brokering all access flowing to and from the cloud to extend the security controls (visibility, DLP, access control, threat detection) once done on-premises out to the cloud."

Since Gartner's coinage in 2012, CASB grew rapidly as standalone startup products (Skyhigh Networks, Netskope, Bitglass, etc.), and through acquisitions by large security and cloud companies around 2017–2018 was reorganized into part of comprehensive security suites. With the emergence of SASE in 2019 and SSE in 2021, CASB moved from a standalone category to one function of an integrated platform. This evolutionary path itself shows the trend that "cloud security converges not into point products but into integrated control spanning identity, network, and data."

Pinning down why existing security appliances alone struggled to solve this problem is the key to understanding CASB's necessity. Perimeter firewalls and IPS see traffic only at the IP/port level and cannot grasp app context such as "who shared which file externally" inside an HTTPS-encrypted SaaS session. SWGs are strong at web URL filtering but cannot distinguish detailed activities inside a specific SaaS app (tenant separation, admin-account status, access to particular fields). Endpoint security (EDR) reaches only managed devices, leaving BYOD and partner devices as blind spots. In other words, a dedicated layer that understands cloud apps at the app level and controls data and behavior across both managed and unmanaged devices was needed, and CASB fills that role. CASB's characteristics can be summarized in four points: ① app-aware policy, ② unified control across managed and unmanaged devices, ③ simultaneous protection of data-at-rest and data-in-transit, and ④ extension of on-premises security policy to the cloud.

2. CASB's Conceptual Structure and Four Pillars

CASB observes traffic and API activity at the brokering point between users and cloud services and applies policy. The concept diagram below shows how CASB intervenes as a broker when managed and unmanaged devices access various cloud services.

graph LR
    U1["Managed device(corp PC)"] --> CASB
    U2["Unmanaged device(BYOD)"] --> CASB
    U3["Mobile/remote user"] --> CASB
    CASB["CASB brokering point<br/>(policy enforcement PEP)"] --> S1["SaaS(M365·Salesforce)"]
    CASB --> S2["IaaS/PaaS(AWS·Azure)"]
    CASB --> S3["Shadow IT(unsanctioned apps)"]
    IDP["IdP/directory<br/>(identity·groups)"] -.identity link.-> CASB
    POL["policy engine<br/>(DLP·access·threat)"] -.policy.-> CASB

CASB's value is explained through four functional pillars. First, Visibility. CASB analyzes firewall and proxy logs or brokers traffic to identify every cloud app the organization actually uses, and provides a cloud app risk registry scoring each app's risk level. This lets the security team discover Shadow IT, block risky apps, and steer users toward sanctioned apps of similar function. For example, it detects—through log analysis—signs of internal documents leaking via a personal file-sharing app and adds that app to a block list. App risk scores are generally computed from factors such as the following.

  • Data residency and sovereignty: storage region, cross-border transfer, level of at-rest/in-transit encryption applied
  • Authentication and access control: MFA/SSO (SAML) support, admin-privilege granularity, session and password policies
  • Compliance history: certifications held (ISO 27001, SOC 2, CSAP, etc.), past breach incidents
  • Ownership and operational transparency: provider trustworthiness, data ownership/deletion policy, disclosure of subprocessors

Based on the resulting scores, the organization sets a three-tier "allow / conditional allow / block" policy, differentiating control strength by, for example, auto-blocking high-risk apps while only warning and logging for medium-risk apps. Visibility is the premise for the other three functions—if you do not know what is being used, you cannot pinpoint the target for compliance, data protection, or threat detection.

Second, Compliance. It checks whether data stored and processed in the cloud violates the Personal Information Protection Act, GDPR, PCI-DSS, or industry-specific regulations. For instance, it scans whether resident registration numbers or card numbers are stored in SaaS in violation of the rules, and detects whether data stored in an overseas region violates data sovereignty. Extending regulatory compliance out to the cloud is the core. The compliance function does not stop at mere violation detection; its value lies in providing supporting evidence for audits and certification responses (logs and reports on what data is where and who accessed it). The more heavily regulated the industry—finance, healthcare, public sector—the more often this function becomes the primary driver of CASB adoption.

Third, Data Security. CASB performs DLP (data loss prevention) on sensitive information in the cloud. It identifies sensitive data based on content inspection, regular expressions, keywords, and fingerprints to block or quarantine external sharing and downloads, and when needed stores data encrypted or tokenized with keys the organization manages. By applying on-premises DLP policy to the cloud unchanged, it maintains policy consistency. In particular, encrypting with keys the organization directly manages (BYOK, Bring Your Own Key) means even the cloud provider cannot access the plaintext, which matters practically because it preserves data confidentiality even amid a provider breach or a compelled-disclosure request.

Fourth, Threat Protection. It detects account takeover, insider threats, and abnormal access through user and entity behavior analytics (UEBA). For example, it catches anomalies such as an account logged in from Seoul connecting from overseas minutes later ("impossible travel"), mass downloads, and late-night mass deletions, and inspects malware uploaded to the cloud. Combined with threat intelligence, it also blocks communication with known malicious IPs and domains. These four functions are not independent but cyclical—compliance criteria are applied to the apps and data found by visibility, data security blocks leaks, and the results of responding to anomalies via threat protection accumulate back into visibility data, refining policy.

The table below organizes the four pillars from the perspectives of purpose, representative techniques, and outputs. The table is a summary only, however; for each function to actually take effect, alignment with identity, data classification, and the policy engine—as explained above—is the premise.

Pillar Purpose Representative techniques Key outputs
Visibility Grasp usage and risk Log analysis, app risk scoring Cloud app inventory, Shadow IT list
Compliance Check regulatory violations Content scanning, data location check Violation reports, remediation
Data Security Block leaks and protect DLP, encryption, tokenization Blocked/quarantined/encrypted data
Threat Protection Detect and respond to anomalies UEBA, malware scanning, threat intel Risk alerts, automated response (quarantine, re-auth)

3. CASB Deployment Modes

The ways CASB intervenes in traffic and activity divide broadly into API-based (out-of-band) and proxy-based (inline), with the proxy further split into forward proxy and reverse proxy. The detailed architecture diagram below shows the data-path differences among the three modes.

graph TB
    subgraph API["API-based(out-of-band)"]
      A1["data already stored in cloud"] --> A2["CASB calls CSP API"]
      A2 --> A3["after-the-fact scan·policy(non-real-time)"]
    end
    subgraph FWD["forward proxy(inline)"]
      F1["managed device(agent)"] --> F2["CASB proxy"]
      F2 --> F3["real-time inspection then forward to cloud"]
    end
    subgraph REV["reverse proxy(inline)"]
      R1["unmanaged device(BYOD)"] --> R2["routed via CASB through IdP"]
      R2 --> R3["real-time control without an agent"]
    end

These three modes differ fundamentally in where and when they intervene in the data path, and coverage, real-time capability, and deployment difficulty diverge accordingly. Below we examine the principle and pros and cons of each mode in turn.

The API-based (out-of-band) mode has CASB call the management APIs exposed by the cloud service provider to query and inspect data already stored in the cloud along with its configuration and sharing state. Because it does not insert itself into the traffic path, it has no impact on user experience, and it has the advantage of being able to scan all data regardless of managed device, unmanaged device, or mobile app. Typically, it finds and remediates long-neglected public share links or misconfigured permissions in SaaS after the fact. However, because it inspects after data is stored, real-time blocking is impossible, and it is limited to apps for which the CSP provides an API.

The forward proxy mode distributes an agent or proxy configuration (PAC file) to devices so that CASB intercepts and inspects the traffic a user sends to the cloud in real time before forwarding it. It can perform DLP and blocking at the moment of upload, enabling real-time control, but because an agent must be installed and managed on devices, it suits managed devices the organization controls. Its weakness is that installing an agent on personally owned BYOD devices is difficult.

The reverse proxy mode is the concept of placing the proxy on the cloud-service side rather than on the device, redirecting the session to CASB when the user logs in via an IdP (SSO) so that traffic is routed through it. Its greatest advantage is that, requiring no agent, it can apply real-time control even to unmanaged devices (BYOD) and partner devices. However, SAML-based SSO integration is mandatory, and the proxy is sensitive to changes in the cloud app's URLs and APIs, which can cause compatibility issues.

In practice, multimode CASB, which uses the three modes complementarily together, has become the standard—using API to inspect stored data after the fact, forward proxy to control managed devices' real-time traffic, and reverse proxy to cover BYOD. This is because the areas the three modes cover do not overlap but are complementary. For example, if an organization applies upload-time DLP to office PCs via forward proxy, applies SSO-routed control to remote workers' personal laptops via reverse proxy, and cleans up years of documents already accumulated in the cloud via API scanning, it brings all three paths under one policy and console. The important design principle here is to maintain a single source of policy—even with three deployment modes, DLP rules, blocking criteria, and logs must be managed in one place to ensure consistency and audit traceability. When using an inline proxy, TLS decryption is unavoidable, so given performance degradation and privacy concerns, a compromise of selectively decrypting only sensitive traffic such as finance and healthcare and processing the rest based on metadata is commonly used.

4. Comparison of Deployment Modes and Adjacent Technologies

The first design decision one hits when actually deploying CASB is the choice of deployment mode. This is not a matter of mere technical taste but a comprehensive judgment tangled with the organization's device management level (share of managed devices), whether SSO is deployed, regulatory demands, and performance requirements. The choice of deployment mode is split by "what you are trying to control" and "which devices you target." The table below compares the characteristics of the three modes.

Category API-based Forward proxy Reverse proxy
Intervention timing After the fact (post-storage) Real-time (inline) Real-time (inline)
Agent Not needed Needed Not needed
Target devices All Managed devices Managed and unmanaged (BYOD)
Strength Broad scanning, non-disruptive Blocking at upload Real-time control of BYOD
Limitation No real-time blocking Hard to apply to BYOD SSO required, compatibility

The reason for these differences is that each mode occupies a different position relative to the traffic path. API inspects the output (stored data) from outside the path, so it lacks real-time capability but has broad scope; the proxy is on the path, so real-time blocking is possible but a means to enforce that path (an agent or SSO) is needed. The practical implication is clear—if real-time leak blocking is the goal, the proxy suits; if remediating neglected data and misconfigurations is the goal, API suits; and since most cases need both, they are configured as multimode. Conversely, deploying only one always leaves a blind spot. With only API, you learn of leaks only after the fact; with only a proxy, you miss already-accumulated data and machine-to-machine traffic accessible only via API.

CASB is often confused with adjacent security technologies but differs in focus. SWG (Secure Web Gateway) focuses on URL filtering and malware blocking across web traffic in general, whereas CASB recognizes and controls detailed activity inside a specific cloud app (sharing, downloading, particular fields). For example, an SWG "allows/blocks access to this site," but CASB applies fine-grained policy according to in-app context, such as "allow this SaaS but only with company accounts, and block file sharing to external domains." The two functions are not exclusive but are used together in layers. If on-premises DLP prevents data leaks on the internal network and endpoints, CASB extends that DLP to cloud stored and transmitted data. Whereas ZTNA focuses on "allowing/blocking access to the application itself based on identity," CASB is complementary in that it controls "the data activity occurring inside the app after access is allowed." Today these functions are integrated into SSE (Security Service Edge), and CASB has become one of the core pillars composing SSE alongside SWG, ZTNA, and FWaaS. In other words, CASB is trending toward being absorbed and evolving from a standalone product into one function of the SASE/SSE platform.

5. Adoption Cases and Quantitative Effects

CASB's value shows up not as an abstract control concept but as concrete risk reduction. Below are four representative use cases repeatedly confirmed in practice, each showing how the four pillars explained above lead to actual incident prevention. Commonly, CASB realizes the cycle of "making unknown risk visible, blocking visible risk with policy, and detecting and responding to remaining risk." A representative use case is discovering and cleaning up Shadow IT. Suppose an organization analyzed its firewall and proxy logs with CASB and found only a few dozen sanctioned apps the IT department was aware of, while the cloud apps actually in use numbered over a dozen times that, many of them classified as high-risk with inadequate data encryption and compliance. CASB ranks these by risk score, blocks the top high-risk apps, and steers users toward sanctioned apps of similar function, drastically reducing uncontrollable data-leak paths. The core achievement in this process is converting the fundamental problem of "not knowing what is used" into "knowing what is used and blocking only the risky ones."

The second case is remediating misconfigured and over-sharing in SaaS collaboration tools. Files made public to "anyone with the link" in collaboration storage, sensitive documents shared with external domains, and access rights left on former-employee accounts are frequent causes of incidents. CASB's API-based scanning inspects millions of already-stored files and their sharing settings after the fact, automatically recalling or making private the violating shares or warning the owner. It fills the gap the proxy mode misses, in that it cleans up this hard-to-control-in-real-time area without disruption.

The third case is account takeover response. When a SaaS account phished and taken over logs in from an unusual country or time zone and attempts a mass download, CASB's UEBA catches it as a sudden spike in risk score and automatically triggers session blocking, re-authentication (step-up MFA), and admin alerts. For example, if "impossible travel"—the login point shifting from Seoul to overseas within minutes—and a download more than ten times the usual volume are observed simultaneously, an auto-quarantine policy is triggered. In this way, CASB completes the cycle of visibility → control → detection and response in a single layer.

The fourth case is preventing data exfiltration by departing and transferring personnel. It is a classic form of insider leak for a prospective leaver to move large volumes of material to a personal cloud account around their last working day, or for a department transferee to keep viewing prior work materials. CASB integrates with state changes in the HR system and IdP to intensify monitoring of or block that user's downloads and external sharing, and automatically revokes access rights. This extends the insider-threat scenario controlled on-premises to the cloud environment, a representative example of identity lifecycle (joiner-mover-leaver) management meshing with CASB.

6. Deep Dive — Integration into SSE/SASE and Recent Trends

CASB started in the early 2010s as a group of independent startup products (Skyhigh Networks, Netskope, etc.), but around 2018 large security and network companies acquired them en masse, reorganizing CASB into a component of integrated platforms. Gartner presented SASE in 2019 and, in 2021, SSE (Security Service Edge)—the security half carved off from it—which fuses CASB, SWG, ZTNA (and FWaaS) into a single cloud service. Therefore, in today's new deployments, adopting the CASB function of an SSE/SASE platform rather than a standalone CASB is common.

The practical significance of this integration is the unification of policy, logs, and management console. In the past, SWG, CASB, DLP, and ZTNA were operated with different vendors and consoles, fragmenting policy and creating blind spots; once integrated into SSE, a single policy engine consistently controls web, SaaS, and private-app access and audits with a single log. This lightens the burden on operations staff and speeds threat response. However, an integrated platform heightens the risk of vendor lock-in, so at deployment one must weigh the balance between functional maturity and dependence.

A prominent recent trend on the functional side is the combination with SSPM (SaaS Security Posture Management). If CASB controls traffic and data access, SSPM continuously checks and remediates the SaaS's own security settings (excessive privileges, unapplied MFA, external-sharing policies, etc.). When the two combine, a dual defense of "data-flow control (CASB) + configuration hygiene management (SSPM)" is completed. Further, linking with DSPM (Data Security Posture Management), which manages storage location, sensitivity, and access rights from the data's own perspective, allows an integrated view of "what data is where, who accesses it, and how it flows."

Also, controlling generative-AI usage has emerged as a new demand. As the risk of employees pasting internal sensitive information or source code into generative-AI services such as ChatGPT grew, AI access control—where CASB inspects and blocks data uploads to AI apps via DLP—has become a core use case. The main points of generative-AI control are as follows.

  • Input (prompt) inspection: detect, mask, or block when customer personal data, unreleased source code, or trade secrets are included in a prompt
  • App visibility and grading: identify the AI apps used in the organization and classify them by risk to apply allow/block policy
  • Path enforcement: steer requests only to a sanctioned internal AI gateway or enterprise plan (blocking shadow AI)
  • Audit and logging: log who sent what to which AI to secure regulatory response and after-the-fact tracing

This can be seen as the logic of Shadow IT control examined above extended to "shadow AI," showing that the focus of data loss prevention is shifting from file sharing to conversational AI input.

Domestically, too, SaaS adoption is spreading centered on finance and the public sector, increasing demand for CASB/SSE, and cases of it being used as grounds for cloud-usage control under the Cloud Computing Act and the CSAP (Cloud Security Assurance Program) framework are rising. In particular, amid a trend of network-separation regulation being eased and reshaped, the shift of the center of gravity toward CASB/ZTNA-based data- and identity-centric control instead of a physical perimeter is a recent issue worth addressing in a Professional Engineer answer.

7. Considerations and Implications

  • Point-product vs. platform selection strategy: An organization already operating many SaaS apps and urgently needing deep control of a specific app should first secure mature CASB functionality, but over the medium to long term should choose CASB on a SSE/SASE roadmap integrated with SWG and ZTNA to avoid fragmentation of policy, logs, and management console. The newer the deployment, the more an integrated platform is favorable in total cost of ownership (TCO) and operational efficiency.
  • Designing deployment-mode trade-offs: Since real-time blocking (proxy) and broad visibility (API) are not mutually exclusive, make multimode—covering managed devices with forward proxy, BYOD with reverse proxy, and stored data with API—the default design. However, since inline proxy entails latency, privacy, and certificate-management burdens from decryption (SSL interception), a selective-inspection policy that bypasses low-sensitivity traffic is needed.
  • Alignment with identity and governance: CASB policy takes effect as least-privilege, conditional access when linked with the users, groups, and roles of the IdP/directory. Under the zero-trust principle (always verify), it should enforce "verified identity + controlled data flow" together in combination with ZTNA, and DLP policy should be designed consistently with the data classification scheme (sensitivity labeling) to reduce false positives and over-blocking.
  • Minimizing visibility blind spots: CASB's effect is proportional to coverage. Apps for which API is unsupported, machine-to-machine automated traffic, and native mobile apps that bypass the proxy can remain blind spots, so log sources (firewall, proxy, EDR) should be broadly integrated and deployment modes combined into multimode to continuously widen the control scope.
  • Managing privacy and legal risk: Traffic decryption and user-behavior monitoring can invite disputes over worker surveillance and violation of communication secrecy, so the inspection scope, purpose, and retention period should be disclosed in advance and legitimacy secured through labor-management agreement and internal rules. Data-sovereignty demands over data stored in overseas regions are managed through CASB's location and configuration checks.
  • Performance and availability design: Because an inline proxy sits on the traffic path, CASB itself can become a single point of failure (SPOF). Global PoPs, redundancy, and a fail-open/fail-close policy for outages should be defined in advance, and capacity sized so the decryption load does not harm perceived performance. Whether to choose fail-close for security or fail-open for availability is best applied differentially by traffic type according to asset sensitivity.
  • Operational maturity and tuning burden: For CASB, operation rather than deployment itself is the crux. False positives in DLP rules disrupt work, and excessive blocking drives users to find workaround paths (Shadow IT again). Therefore a gradual approach is needed—first learning and tuning policy in monitoring (detection) mode, then transitioning stepwise to blocking (enforcement) mode—balancing security and productivity by combining risk-score thresholds, exception lists, and user coaching (allow after warning).
  • Coordinated operation with other security systems: CASB does not operate alone. It should feed detected threat and violation events to SIEM/SOAR to ride an integrated response workflow, and exchange policy and context with IdP, EDR, and DLP to multiply effectiveness. That is, CASB is the "eyes and hands" of cloud security, but only when meshed with the enterprise-wide security operations (SOC) system that processes its signals does it become complete control.
  • Outlook and related technologies: CASB is being absorbed from a standalone category into the data/app security layer of SSE, evolving into "cloud- and data-centric integrated security" in combination with SSPM, DSPM (Data Security Posture Management), and generative-AI control. From a Professional Engineer's perspective, what is required is not mere deployment but the capability for integrated design aligned with EA, cloud-transition strategy, and zero-trust architecture. Likely exam directions include describing CASB's four pillars and deployment modes, comparing its relationship with SASE/SSE and ZTNA, and presenting Shadow IT and generative-AI control cases; an answer is effectively structured along the flow "why it is needed (perimeter dissolution) → what it does (four pillars) → how it is applied (deployment, multimode) → where it is heading (SSE integration)."

References

In one line: CASB is a security control layer that enforces the four functions of visibility, compliance, data security, and threat protection via API/proxy modes at the brokering point between users and cloud services, blocking Shadow IT and SaaS data leaks while today integrating and evolving into a core pillar of SSE/SASE.