Assigning Permissions in Azure Security Center

by Scott Muniz | Sep 21, 2020 | Azure, Technology, Uncategorized

This article is contributed. See the original author and article here.

Over the course of the last couple weeks, I have been asked many questions about how the different RBAC roles in Azure Security Center  and how they should be assigned. In this blog post, I will discuss how to assign the roles used across Azure Security Center 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:

1. Log into the Azure portal > type “Subscriptions” in the search bar > select your subscription > then look for Access Control (IAM).  
2. 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 Azure Security Center. 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 Security Center Alerts API Connector or a Security Center 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 Azure Security Center 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 Azure Security Center. 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 Azure Security Center 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 Azure Security Center 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 ASC scoping Scenarios – and the why

Azure Security Center 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, ASC 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:

1. Security is owned (and enforced) by a central team
2. Security is owned by resource owners
3. 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:

1. There is no central visibility for security threats and security posture information
2. Without enforcement, resource owners decide if they want to remediate security controls and recommendations, what might lead to security issues.
3. 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.
4.  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 ASC, 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 ASC 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 Azure Security Center 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

Azure Arc Launch Server Providers

by Scott Muniz | Sep 21, 2020 | Azure, Technology, Uncategorized

This article is contributed. See the original author and article here.

We have worked with the following partners during the preview of Azure Arc. We have trained their engineers and collaborated with them to develop unique proof of concepts. We have found that these partners demonstrate expertise with Azure Arc and are well positioned to help their customers transform their digital infrastructure leveraging Azure Arc. 

Please reach out to the following partners if you need help with Azure Arc in your IT environment.

Microsoft doesn’t accept any liability on behalf of these partners.

Database copy preview on Azure SQL Database Hyperscale

by Scott Muniz | Sep 21, 2020 | Azure, Technology, Uncategorized

This article is contributed. See the original author and article here.

Database copy provides a way to create a transactionally consistent snapshot of the source database as a new database on the same server or different server. It also enables copy across regions, subscriptions, and Azure tenants using the same or different service level objective.

On Azure SQL Hyperscale the time taken by database copy depends on the source and destination chosen for the copy

• If the destination is the same region as the source, then the copy is created from snapshots of blobs created by database backups. This kind of copy is a fast operation regardless of database size.
• If the destination region for the copy is different from the source region, the copy is a size of data operation. Page server blobs are copied in parallel, so the copy time is not directly proportional to the size of data, yet it is a potentially long running size of data operation.

Below are some sample durations for database copy in Hyperscale:

Creating a Database Copy

Database copy can be created started with PowerShell, Azure CLI, REST API, or T-SQL. Cross subscription and cross tenant copy is only supported using T-SQL. If you do not specify a service objective for the target database, the default service objective and configurations are used, which is HS_Gen5_2 with 1 additional replica which can be used for reads.

Azure CLI

az sql db copy --resource-group "sourceRG" --server sourceServer --name "sourceDB" --dest-resource-group destDB --dest-server destServer --dest-name destDB --service-objective HS_Gen5_2 --read-replicas 0

PowerShell

New-AzSqlDatabaseCopy -ResourceGroupName "sourceRG" -ServerName sourceServer  `-DatabaseName "sourceDB" `
-CopyResourceGroupName "destinationRG" -CopyServerName destServer -CopyDatabaseName "destDB"

TSQL

CREATE DATABASE Database2 AS COPY OF SourceServer.Database1;

Portal

Another way to copy the database is via the Azure portal.

Portal

Monitoring database copy:

In the master database:

select * from sys.dm_operation_status

GO

sys.dm_operation_status

Note: the progress status values are limited to 0/50/100%.

Current preview Limitations

• sys.dm_database_copies  does not currently track progress of database copy, this will be addressed before GA.
• Currently portal target database allows choice of elastic pool but the copy will fail as Hyperscale does not support Elastic pools