CASB, shadow IT detection, and the shared responsibility line

Why this matters

Domain 2 is 27% of the exam and this is its first objective, which CompTIA describe in a single bullet covering everything from access brokers to serverless. Three lessons carry it here, and this one establishes the framing the other two depend on: who is responsible for what, and how you find the services nobody told you about.

The shared responsibility model is the highest-yield concept in the domain. Nearly every cloud security incident in the public record resolves to a control that one party assumed the other was providing, and exam scenarios are built on exactly that ambiguity. Being able to state the line precisely for a given service model converts a large class of questions into a lookup.

The shadow IT half matters because the model only helps for services you know about. An estate's most exposed data is often in a service the security team has never heard of, bought legitimately by a team solving a real problem.

The lesson

API-based and proxy-based CASB: what each can see, and what each cannot

A cloud access security broker is a control point between users and cloud services. There are two fundamentally different ways to build one, and the difference is examinable because their blind spots are opposite.

API-based (out-of-band). The broker connects to the cloud service's own management API and inspects what is already there.

• Sees: data at rest in the service, sharing and permission settings, configuration, historical activity from the service's audit log, and files uploaded by any route — including from unmanaged devices and from other services.
• Cannot: block anything in real time. It finds a publicly shared file after it was shared, and remediates retrospectively.
• Requires: the service to expose an API, so it works only for sanctioned, integrated services.

Proxy-based (in-line). Traffic is routed through the broker, either by configuring endpoints (forward proxy) or by redirecting the service's authentication flow (reverse proxy).

• Sees: traffic as it happens, so it can block, redact, or require step-up authentication before an action completes.
• Cannot: see anything that does not pass through it — an unmanaged device on a home network, a mobile application using certificate pinning, or a service-to-service transfer that never touches a user's connection.
• Costs: latency, and an operational dependency on a component in the data path that breaks when the provider changes its client.

The conclusion scenarios test: the two are complementary, not alternatives. API-based gives complete retrospective coverage of sanctioned services; proxy-based gives real-time control over traffic you can route. An organisation with only one has a predictable gap, and the question is usually asking you to name which gap.

Discovering shadow IT from egress logs and identity provider data

Discovery is a data problem, and three sources do most of the work.

Egress telemetry. Firewall, proxy and DNS logs show which cloud services are being reached, from where, and in what volume. Correlating destinations against a catalogue of known services turns raw traffic into a list of applications with usage counts. Volume matters as much as presence: a service receiving large sustained uploads is a data-exfiltration question regardless of how legitimate it is.

Identity provider data, which is the source most often overlooked and frequently the most valuable. Two signals live here. Federated sign-ins reveal which third-party applications users authenticate to with corporate identity. Consent grants and application registrations reveal which third-party applications hold delegated permission to read corporate data — frequently persistent, frequently broader than anyone realised, and frequently granted by an individual on behalf of the whole tenancy.

Financial data. Expense claims and card statements reveal services bought outright. This finds the ones that never touch corporate identity or network, which are otherwise invisible.

Two more sources close specific gaps: certificate transparency logs surface hostnames issued for your domains by services you did not authorise, and endpoint management inventories reveal installed clients.

What discovery produces is a list needing triage, and the triage criteria are risk-shaped: what data classification could reach it, does it hold corporate credentials or a delegated token, how many users, and what does the provider's own assurance look like. A service with three users holding a tenancy-wide read token outranks one with three hundred users and no data access.

The shared responsibility model stated precisely for IaaS, PaaS and SaaS

The model divides responsibility between provider and customer, and the boundary moves with the service model. Stated as layers:

Three rules follow, and they answer most questions in this area.

The bottom three rows never move. Identity, configuration and data are the customer's at every service model, including SaaS. A breach caused by an over-permissive share, a weak administrative account or an unclassified data set is the customer's responsibility no matter how managed the service is. This single fact resolves a large share of scenarios.

The provider is responsible for security of the cloud; the customer for security in it. The provider secures the infrastructure and the service itself; the customer secures what they put in and how they configure it.

Responsibility is not the same as capability. A customer is responsible for data in a SaaS product but may have no ability to encrypt it with their own keys, no access to logs at the granularity they need, and no way to test. Where responsibility exceeds capability, the gap is closed by contract and by supplier assurance — which is why lesson eight's third-party work matters here.

The control that becomes the customer's the moment a model changes

The most dangerous moment in the model is a change of service model, because responsibility transfers silently.

The classic direction is managed-to-self-managed. An organisation using a managed database service, where the provider patches the engine, migrates to running the database on virtual machines for cost or feature reasons. Patching the engine is now the customer's, and unless the migration explicitly assigned it, nobody has it. The system runs perfectly for months.

The reverse direction fails differently. Moving from self-managed to managed means the customer's existing controls — agents, local logging, configuration management — frequently cannot be installed on the managed service. The control does not transfer to the provider; it disappears, and its absence is only noticed at the next audit.

Other transitions with the same shape: adopting a serverless platform, where host-level controls have no equivalent; moving from a self-hosted application to its SaaS edition, where log access changes entirely; and a provider changing what is included in a service tier.

The governance control is a responsibility assignment reviewed as part of architecture change review, naming, for each control class, who performs it after the change. That is the RACI from lesson three applied to a cloud boundary, and it is the artefact a scenario is missing when it describes a control that "was in place before the migration".

Sanctioning a discovered service instead of blocking it, and when blocking is right

Discovery produces a decision per service, and the default answer is more often "adopt" than candidates expect.

Sanctioning means bringing the service inside: connect it to the identity provider so access follows joiners, movers and leavers; integrate its audit log into monitoring; apply an API-based broker for data visibility; assess the supplier proportionately; and record it as an asset with an owner. The service keeps solving the problem it was bought to solve, and the exposure is managed.

This is usually right because shadow IT is a demand signal. Staff adopted it to do their jobs, and blocking it without an alternative moves the same activity to somewhere with less visibility — personal accounts, personal devices, personal email. The measurable outcome of a pure blocking strategy is usually not less use but less visible use.

Blocking is right in identifiable circumstances, and scenarios signal them:

• The data classification makes the risk unacceptable regardless of controls — the table from lesson seven should already decide this.
• The provider cannot meet an obligation that applies to the data, such as residency or a breach notification clock.
• The service cannot be integrated with identity, so access cannot be revoked when someone leaves.
• Due diligence found something disqualifying.
• An equivalent sanctioned service already exists, in which case the block comes with a migration and a communication, not on its own.

The programme that works pairs a fast sanctioning path with selective blocking and publishes the catalogue of what is already approved. The alternative — a slow approval process and broad blocking — reliably produces more shadow IT, which is the causal link a scenario describing both is asking you to see.