Cloud Access Security Broker (CASB)
A Cloud Access Security Broker (CASB) is a security enforcement layer positioned between users and cloud service providers. Its role is to apply enterprise security policies when users access cloud-based resources.
A CASB does not replace identity providers or firewalls. Instead, it observes usage, analyzes risk, and enforces policy based on organizational rules.
Microsoft Defender for Cloud Apps (MDCA)
Microsoft Defender for Cloud Apps (MDCA) is Microsoft’s CASB solution. It is designed to provide:
Visibility into cloud app usage.
Control over data movement.
Threat detection across Microsoft and third-party cloud services.
MDCA integrates natively with Microsoft Entra, Microsoft Defender XDR, and Conditional Access, allowing identity-based enforcement rather than relying only on network controls.
Why MDCA is necessary
Users can access apps from unmanaged devices.
IT may not know which SaaS apps are in use.
OAuth apps can gain persistent access to data.
Data can leave the organization without visibility.
MDCA addresses these challenges by identifying cloud apps, assigning risk scores, and enabling policy-based control.
MDCA architecture and integration points
Cloud Discovery analyzes firewall and proxy logs to discover apps.
App connectors use provider APIs for deep inspection.
Conditional Access App Control uses reverse proxy for real-time session control.
Policies provide continuous monitoring and enforcement.
This architecture allows both passive discovery and active control, depending on configuration.
Cloud Discovery
Cloud Discovery identifies cloud apps by analyzing network traffic logs. These logs can come from:
Firewalls.
Secure web gateways.
Proxy servers.
Manual snapshot discovery, using uploaded log files.
Continuous discovery, using log collectors for ongoing visibility.
Cloud Discovery is primarily used to identify shadow IT.
Reviewing the Cloud Discovery Dashboard
Start with the high-level usage overview to understand overall cloud adoption.
Review top app categories and determine which are sanctioned.
Drill into the Discovered apps tab to see individual apps.
Review top users and source IP addresses to identify heavy usage.
Examine the App Headquarters map to understand geographic risk.
Review the risk score and discovery alerts for each app.
Risk scores help prioritize remediation but can be customized to reflect business priorities.
Filtering discovered apps
App tag, including sanctioned, unsanctioned, or custom tags.
Apps and domains, for targeted searches.
Categories, such as storage, collaboration, or social media.
Compliance risk factors, such as HIPAA or ISO 27001.
General risk factors, such as data center location.
Security risk factors, such as encryption or MFA support.
Usage filters, based on users or data uploads.
Legal risk factors, related to data protection and privacy policies.
These filters help admins focus on the most critical risks first.
Sanctioning and unsanctioning apps
MDCA maintains a cloud app catalog of over 16,000 apps, scored using more than 80 risk factors.
Sanction apps that are approved for use.
Unsanction apps that should be avoided.
Customize risk scoring based on organizational standards.
Sanctioning does not automatically block access. It informs governance decisions and policy enforcement.
Active Directory Federation Services (AD FS)
Active Directory Federation Services (AD FS) is an on-premises identity federation service that enables SSO across trusted systems.
SaaS applications.
Custom line-of-business applications.
Partner applications.
AD FS often exists alongside Microsoft Entra ID in hybrid environments.
Why migrate apps from AD FS to Microsoft Entra ID
Centralized access control.
Built-in Conditional Access.
Reduced infrastructure and maintenance costs.
Improved visibility and reporting.
However, not all AD FS apps are immediately compatible, which is why discovery and assessment are required.
AD FS application activity report
The AD FS application activity report identifies applications that authenticate through AD FS and assesses migration readiness.
Shows apps with user sign-ins in the last 30 days.
Assesses compatibility with Microsoft Entra ID.
Provides migration guidance per app.
The report is available to several reader and admin roles, not just Global Administrators.
Migration readiness statuses
Ready to migrate, meaning no changes are required.
Needs review, meaning some settings must be adjusted.
Additional steps required, meaning current configuration is unsupported.
These statuses are frequently tested in scenario-based questions.
Types of apps to migrate
SaaS applications, typically using modern protocols.
Line-of-business applications, which may use legacy authentication.
Best practice is to migrate apps using SAML or OpenID Connect first, then address legacy apps using Application Proxy or Microsoft Entra Domain Services.