IAM = Identity AND ACCESS management.
When you use a CASB, you are delegating ACCESS management to the CASB.
What is a CASB?
- Sanctioning (determining ACCESS to apps)
- ACCESS management (a component of IAM)
- Session management (Data in Motion DLP)
- Labeling data and determining ACCESS
- UEBA (threat policies)
- Governance (monitoring and actioning API and app deprecation and determining risk)
- SSPM (SaaS Posture Management)
When you have a CASB AND you are using it, you have delegated ACCESS management (of IAM) to the CASB.
How is this achieved? Oauth.
When you use a CASB, you are delegating ACCESS management to the CASB.
What is a CASB?
- Sanctioning (determining ACCESS to apps)
- ACCESS management (a component of IAM)
- Session management (Data in Motion DLP)
- Labeling data and determining ACCESS
- UEBA (threat policies)
- Governance (monitoring and actioning API and app deprecation and determining risk)
- SSPM (SaaS Posture Management)
When you have a CASB AND you are using it, you have delegated ACCESS management (of IAM) to the CASB.
How is this achieved? Oauth.
For those who like pictures, we are talking about here: 
When you create an ACCESS or SESSION policy of any type, it's required to be present in the Conditional Access App Control settings.
Most orgs do not have full Defender XDR unless they are E5 tenants. But, mant orgs have addons that include Defender for Cloud Apps. I have the standalone addon. It costs about 6$ per user per month.
For you to be able to have CASB functionality, it requires the Apps to be listed here:
If your apps already exist in Entra AND are being used, they will show up automagically in Conditional Access App Control Settings (above post). Nothing else needs to be done. However, if you use other IdPs, you have to create an app in the other IdP to bring in their catalogue OR you can onboard them manually, your choice depending on OOB solutions for your IdP. For example, with Okta, Ping One, ADFS, you can just bring in the catalog.
If you bought Defender for Cloud Apps standalone product or bundled with another addon, this is the functionality you bought. If you have E5, you already have all of this. If you're in GCCH, be cognizant that the the Defender for Cloud Apps service is hosted in Azure commercial cloud and data is cached there. It's not stored at rest though in the commercial service in Azure.
The only reason the CAP is required for session and access control is to tell entra to do the reverse proxy with Defender for Cloud Apps. That is all. If you have a 3rd party IdP where you are onboarding the catalogue, you don't need this cap because the session and access control happens in the reverse proxy configured in the 3rd party IdP.
If you bought Defender for Cloud Apps standalone product or bundled with another addon, this is the functionality you bought. If you have E5, you already have all of this. If you're in GCCH, be cognizant that the the Defender for Cloud Apps service is hosted in Azure commercial cloud and data is cached there. It's not stored at rest though in the commercial service in Azure.
The only reason the CAP is required for session and access control is to tell entra to do the reverse proxy with Defender for Cloud Apps. That is all. If you have a 3rd party IdP where you are onboarding the catalogue, you don't need this cap because the session and access control happens in the reverse proxy configured in the 3rd party IdP.
This thread demonstrated why you need IAM experience to implement CASB
• • •
Missing some Tweet in this thread? You can try to
force a refresh
