Conditional Access and MCAS RBAC!
By Sarahzin_Shane and erin_boris
Hi everyone, we are very excited to bring this blog to you on one of our most asked questions regarding Microsoft Cloud App Security (MCAS) access! These days, many customers have a constant dilemma on how to restrict accesses in line with the security best practice, least privilege. As you may know, access to MCAS can be granted through inherited roles from Azure Active Directory (AAD) or through role-based access control (RBAC) assignments from within the MCAS portal itself.
For more information on overall MCAS RBAC, check out our documentation! It is important to note that you cannot overwrite an AAD admin role with a manually assigned MCAS role as AAD role assignments take precedence over MCAS assigned roles.
As it stands today, AAD Global administrators and Security administrators have full access and permissions in MCAS. They can add admins, create policies and settings, upload logs, and perform governance actions.
The Security administrator role is one of the most popular admin roles assigned; this role has permissions to manage additional security related features and products within the Microsoft stack (Microsoft Defender for Endpoint, Intune, etc.). As our customers continue to use our security products, they’ve come to us asking how to limit AAD role permissions for MCAS, and within other products as well. This blog goes over a customer scenario for MCAS and the steps that can be taken to meet their requirements.
Customer Scenario: We follow a very specific RBAC policy. We have Security administrators assigned to specific groups for access across our entire security stack. However, we want to follow least privilege and give access to specific products with the permissions inherited from the Security administrator role. Not all the products have a product-specific administrator role available in AAD. How do we limit the Security administrator role’s access in MCAS without impacting existing permissions to other products?
Solution: AAD Conditional Access
By navigating to the Azure Portal and selecting AAD Conditional Access, we can scope a policy based on specific conditions. For more information regarding Conditional Access, check out our overview documentation.
Let’s start with a Conditional Access policy named “MCAS Restrictions” and begin our conditions on “Users and Groups” under Assignments.
In the screenshots below, we have configured our policy to include the Azure roles of Security administrators and Global administrators (both roles have access to MCAS by default) and exclude two of our users from the policy, Adele and Allan.
Within the “Cloud App or Action,” we selected Microsoft Cloud App Security to scope this policy to only those users that are attempting to log into MCAS. We also selected an “Access Control” to Block Access.
When Christie Cline, who is currently assigned the Security administrator role, attempts to log into MCAS, she receives the following message:
For larger organizations, it can become challenging to separate duties between roles. Conditional Access offers the capability to quickly deny access to users that may be privileged but do not require the ability to login to MCAS and other security applications. In addition, this process is not limited to only the Security admin; it can be scoped to other directory roles. With proper configuration, Conditional Access will take precedence over AAD directory roles.
Let us know if you have any feedback after trying this Conditional Access policy. What other scenarios would you like us to cover? Feel free to comment below!
Microsoft
