By John Lewis
Security administrators often focus on best practices for securing their company’s users, apps, services, and devices. It can be easy to forget that Security Administrators are also “users” and equally if not more important to secure within the organization. What is the best way to secure administrator accounts? This blog provides guidance on how to configure Azure AD Conditional Access to secure administrative access to Microsoft Cloud App Security (MCAS) and Defender for Identities (formerly Azure ATP).
Let’s quickly refresh our knowledge of the RBAC models for both MCAS and Defender for Identities.
In MCAS, admin access is provided by default for users within specific Azure AD roles such as Global and Security Administrators. It’s worth noting that these roles are overarching and provide access to services across M365 and Azure. Additionally, Cloud App Security provides specific admin roles for further granularity; these can be used to override roles set in Azure AD. More information on RBAC for MCAS can be found here.
Azure AD Global and Security admin roles provide access to the Defender for Identities portal. Once the service is provisioned, three Azure AD security groups (Azure ATP {instance name} Administrators, Azure ATP {instance name} Users, and Azure ATP {instance name} Viewers) are created to provide different levels of access. More information on RBAC for Defender for Identities can be found here.
Enforcing MFA
It is best practice to configure admins accounts with “just enough” access to perform their tasks. But first, admins need to have MFA enabled.
If you aren’t familiar with Azure AD’s security defaults, please pause here and take a quick read. This feature provides a preconfigured basic level of security for your tenant at no additional cost.
We can protect both MCAS and Defender for Identities with MFA using an Azure AD Conditional Access Policy. Note that while this blog is focused solely on MCAS and Defender for Identities, these concepts can be expanded to include other apps and conditions to meet the security needs of your environment.
The setup is simple, create a new policy and scope your configuration. I’ve done so in the example below by including a specific user (Alex Wilber) and with the Defender for Identities administrative security group. This ensures my policy will only be applicable for those users.
Next, we want to select the apps this policy will apply to. Search for both Microsoft Cloud App Security and Azure Advanced Threat Protection in the cloud application catalog to add them.
Before we configure the Access controls to grant users access, I want to highlight, applying additional conditions (such as locations to include or exclude your trusted locations from the policy) could further strengthen the security of your accounts. A great use-case for this type of configuration is with the usage of a service account. When using a service account, such as an account provisioned explicitly for API access, it is important to clamp the access down as tight as possible. Typically, a service account would only be used inside your corporate network from a specific set of servers or from a set of trusted IP locations for a service provider. Limiting where your accounts can connect from, minimizes your environment’s risk exposure.
As a final step, you will need to configure the grant Access controls and require multi-factor authentication. If you aren’t using Azure MFA, you can leverage custom controls to support 3rd party MFA providers. More information for onboarding users to Azure MFA can be found here.
Denying Access to Default Azure AD Roles
As mentioned earlier in the blog post, many of the Azure AD roles have access to MCAS and Defender for Identities by default. By denying access to these roles, we ensure that only specific MCAS and Defender for Identities admins will be allowed access. Additionally, this level of authorization can meet the needs of legal and compliance boundaries as well as providing least privilege access for viewing application data and security events.
Like our MFA policy, begin by specifying the users and groups scope. By selecting the directory roles for Global Administrator, Security Administrator, Compliance Administrator, Compliance Data Administrator, Security Operator, Security Reader, and Global Reader we can prevent default access to our apps.
Next, define MCAS and Defender for Identities (Azure Advanced Threat Protection) to your Cloud apps scope.
Lastly, select the Block access control.
When a user belonging to one of the Azure AD roles attempts to login, access is denied.
That’s it, you've now secured your privileged accounts by enforcing MFA and denying access to the Azure AD built-in roles! Let us know in the comments what you are doing to protect your privileged accounts.
Microsoft
