Over the course of the last couple weeks, I have been asked many questions about how the different Microsoft Defender for Cloud RBAC roles in and how they should be assigned. In this blog post, I will discuss how to assign the roles used across Microsoft Defender for Cloud and the types of scenarios that determine how they could be assigned.
Assigning permissions to users for specific workloads
To assign permissions for Azure workloads:
- Log into the Azure portal > type “Subscriptions” in the search bar > select your subscription > then look for Access Control (IAM).
- Once in Access Control (IAM) you will need to add a role assignment, click on “Role assignment”> Add role assignment. The role assignment pane will open and you will select the role assignment to be granted to user.
To perform remediation of recommendations, users will need the appropriate permissions and access to those workloads. For example, to remediate recommendations related to virtual machines, the user will need the Security Admin or Contributor on resource group level for people that should manage resources. This role allows users with that role assignment to view Virtual machines in the portal to make changes.
Assigning permissions for using Logic Apps/Workflow Automation
One thing that might be confusing in terms of permissions are Logic Apps, which are used in the Workflow Automation part of Microsoft Defender for Cloud. These Logic Apps can be automatically triggered once a new alert or recommendation appears. You cannot use any type of Logic App for Workflow Automation, but only those with a Microsoft Defender for Cloud Alerts API Connector or a Microsoft Defender for Cloud Recommendations API Connector. So, if you want to configure workflow automation, you must create a Logic App which then can be triggered.
The LogicApp itself uses a Managed Identity which can be granted access to resources, if necessary. For example, when your Logic App is supposed to get information about all resources in a subscription from Azure Resource Graph or the Microsoft Defender for Cloud Assessments API once a new recommendation pops up, the Managed Identity would need to be assigned the Reader or Security Reader role on the subscription.
The person who creates a new workflow automation does not necessarily have access to all the resources the Logic App will access, because the automation artifact itself has its own permissions. But what level of access is needed to create a workflow automation?
Your user account needs to have the right to create a new workflow automation in a particular resource group and at the same time, to trigger the Logic App you want to use in your workflow automation. So, it’s not enough to only see the Logic App so you can use it, and it is also not enough to only be able to manage Microsoft Defender for Cloud. You will have to make sure that your account will get at least the following permissions:
- Logic App Contributor on the Logic App’s scope, so you can trigger it
- Microsoft.Security/automations/write on the resource group you want to create the workflow automation in. This level of access is included in the Security Admin and the Contributor roles.
It is important to understand, that the Security Admin role alone does not allow you to see or manage resources, but only security-related information and settings.
Permissions for Quick Fixes
Quick Fix Remediation enables you to quickly remediate a recommendation directly in the console and improve your secure score quickly. Quick Fixes, use a template deployment or REST PATCH or PUT API call to configure the resource. To view the list of recommendations with Quick Fixes, you can click here.
Users that will be using the “Quick Fix” feature in Microsoft Defender for Cloud may require additional permissions depending on the logic/action the in the specific recommendation.
The screenshot below shows the result of the Diagnostic logs in Logic Apps should be enabled recommendation for a test user which I’ve granted three different sets of access rights on three different resource groups in a test subscription.
With the Security Reader role, the user will see the assessment result for a particular recommendation, but in order to be able to remediate it, the account would need either the Security Administrator, or Contributor roles assigned.
If we take a deeper look at the Security Admin role, we realize that this role does not allow an account to directly access resources, such as storage accounts, VMs, virtual networks, but it will give your account the right to create resource deployments and configure everything which is related to security.
As you learned above, the quick fix option in Microsoft Defender for Cloud leverages a REST PATCH or PUT API call which is what is incorporated in the Microsoft.Resources/deployments/* set of access rights. So, in case you want to build a custom role in addition to Security Reader (which will enable you to only see, but not change security configurations), you need to make sure to include the deployments rights as sketched above.
Depending on the scope you grant access rights on, the Secure Score within one subscription might change between user accounts. So, for example, if you have one subscription with several resource groups, and you assign one account the Security Admin role on subscription level, and a second account the Security Reader role on two of these resource groups, the second account might see a higher Secure Score, than the overall Secure Score the first account might see for the subscription. This is because the Secure Score calculation takes place on the scope of resources you can see related information for. The owner of the second account, who only sees Security Recommendations and Alerts for a subset of resources, might think that the overall Secure Score is a lot higher than what is true for the subscription. We will cover that topic with more details in an upcoming blog post.
Common Microsoft Defender for Cloud scoping Scenarios - and the why
Microsoft Defender for Cloud is a tool that can give you tenant-wide visibility into your security posture depending on the level and scope of access rights your user account has in your Azure environment. For example, if your account has a role assignment for the Security Reader role on your Tenant Root Group (the upmost Management Group in every Azure Tenant), you will , existing, and future ones, within your company’s environment, r. If your account has been assigned the Contributor role on a single Resource Group in one of your subscriptions only, Microsoft Defender for Cloud will exclusively provide you with information about resources within this scope.
For the purpose of this post, we will focus on the three most common scenarios:
- Security is owned (and enforced) by a central team
- Security is owned by resource owners
- A mix of both
In the first scenario, a central team is responsible for enforcing security over all subscriptions. It is common practice to assign this team the Security Administrator and Contributor roles on a central scope, such as the Tenant Root Management Group, so they can:
- Enforce security policies across all subscriptions
- Remediate security controls and recommendations for all resources in the environment
- Enforce resource eviction (quarantine) in case a security threat or configuration issue is found
This is a scenario which will give the security team a lot of power and responsibility, which is good from a process point of view, but what also might lead to bad situations in terms of service availability. Therefore, this approach should be chosen for companies only that have a very high level of automation so it can be made sure that security won’t break their business.
In the second scenario, there is no central IT security team, or at least, the team does not own security for the company’s Azure subscriptions, which makes the resource owners responsible for security. In this scenario, the central team does not have access to any of the subscriptions, so subscription (or resource group) owners will have the Owner or Contributor roles assigned to their accounts on either subscription or resource group level. In this scenario, every resource owner will see security alert, controls, and recommendations for their owned resources only. However, this approach comes with at least four:
- There is no central visibility for security threats and security posture information
- Without enforcement, resource owners decide if they want to remediate security controls and recommendations, what might lead to security issues.
- Resource owners only see security controls and recommendations for their particular scope. If there is no one who owns the overall security (and gets visibility into subscription- and tenant-wide recommendations), they will never be seen and remediated.
- Security policy is assigned per subscription and can be changed and controlled by the subscription owners
This is why most of my customers chose to go with the third scenario: Resource owners will own security for their resources, but there is a central team that gets insights into the overall security posture. Role assignments for this scenario might be:
- Owner or Contributor roles for resource owners on subscription or resource group level which will enable them to see security controls and alerts for their resources and to remediate recommendations within their scope.
- Security Reader role on Management Group level for a central IT security team so they can gather insights for all subscriptions and make resource owner accountable for improving their resources’ security postures.
- Custom RBAC role(s) on Management Group level for the central team to enable them doing advanced tasks, such as create a security policy on Management Group level which can then be assigned by the resource owners only.
Let's talk more about custom RBAC. As you learned before, you need to have the Microsoft.Resources/deployments/* access rights to remediate recommendations using the quick fix feature in Microsoft Defender for Cloud, which is part of both, Security Admin and Contributor roles. But in the third scenario, we might not want to give this level of access to the central team, because they only should get visibility but not remediation rights. However, imagine they should be able to create new policy definitions that can be used by resource owners to enforce different settings in their subscriptions or resource groups. For example, you want to give resource owners the option to enable the Microsoft Defender for Cloud Standard Pricing tier on their resource scope, only. In this case, you could create a custom RBAC role which will give the central team the right to create a new policy definition on Management Group level, but not the right to assign the definition. This RBAC role definition could be created with the following access rights:
{
"Name": "Policy Definition Contributor",
"Id": null,
"IsCustom": true,
"Description": "Allows to create Policy Definitions",
"Actions": [
"Microsoft.Authorization/policyDefinitions/*",
"Microsoft.Authorization/policySetDefinitions/*",
"Microsoft.Management/managementGroups/read"
],
"NotActions": [],
"AssignableScopes": [
"/providers/microsoft.management/managementGroups/<Root Management Group ID>"
]
}
With that role assigned to the central team, they can then create one or several central deploy if not exists policies (DINE), as you can find them in the Microsoft Defender for Cloud GitHub repository.
You learned that not only security alerts and recommendations, but also your Secure Score itself will always depend on the set of access rights your account will have. In a future blog post, we will cover this aspect more deeply because it is mandatory to understand how the overall Secure Score might be different from a Secure Score that is true for a subset of resources, only.
Contributors:
Tom Janetscheck, Senior Program Manager
Fernanda Vela, Program Manager
Reviewers:
Yuri Diogenes, Principal Program Manager
Meital-Taran-Gutman, Principal PM Manager
Liron Kachko, Senior Software Engineer