Channel: CodeSection,代码区,网络安全 - CodeSec
Viewing all articles
Browse latest Browse all 12749

Microsoft Azure and Security Best Pratices Part 1 Identity


So let me startthispost off with a story…

A Couple of weeksago I had some issues with a demo environmentI was hosting in Microsoft Azure, where I had automated all of the infrastructure setups using ARM but there was still a lot of work done manually. The demo environment was setup using a single admin account which had access to the domain. Now one day before I had a speaking session, I got into an issue that the account password expired and I didn’t have a simple way to access the environment since I wasn’t able to disable NLA I couldn’t reset the password remotely since I don’t have console access to the environment. So basically locked out of my own environmentwith the single user account I had, so how could I solve this in Microsoft Azure?

First of I intended to use the “Password reset” option that Azure provides in the portal but that is by design disabled if you want to run it on a domain controller so therefore that was not an option.

Microsoft Azure and Security Best Pratices   Part 1 Identity

I ended up with using a Custom Script Azure Extensionrunning a PowerShell Script (Set-ADUser -Identity $_.SamAccountName -PasswordNeverExpires:$FALSE) to disable the password expiration of my user before I had my presentation, which was run in Azure and therefore allowed me to gain access again. Of course I was thrilled that I got access again before my session, but… and this brings me to the point of this post which is to show about best practices and how we can properly secure an Azure environment, because in theory I didn’t have any access to the virtual environment but because of my access in Azure I could run some scripts and gain access in, this first post is going to be focused on Identity and role based access control in Microsoft Azure.


First, of we need to start with securing the users which has access to Azure and also define a proper access control to resources and services. Azure access is given either on a subscription level or resource group. We have 4 different types of roles that can be given to a user.
Microsoft Azure and Security Best Pratices   Part 1 Identity
Owner (Has access to everything inside the subscription and also assign others to the same level) Contributor (Has access to everything inside the subscription but cannot assign others to the same level) Reader (Has read-only access to everything inside the subscription) Custom Predefined roles (Azure comes with many predefined roles) Custom Roles.

We should always as often as possible restrict the number of users with Owner access on a subscription level. When you are given an Azure role you are actually given access to perform actions within a resource provider. So, for instance, owner role is allowed to perform all Action against all registered Resource providers. So my ability to install a guest extension within a virtual machine in Azure is based upon my access against the Resource ProviderMicrosoft.Compute/virtualMachines/extensions and having Write access there.

All Resource Providers and Actions are documented here >https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations

As a best practice, we should create custom roles to define proper access to users who need access to Microsoft Azure, so if we needed to create a custom role which only has certain actions they can perform against a resource provider, we would need to define a custom JSON file. Now within a custom role JSON there some required attributes.

Use of Custom Roles

Example Role:

Name: is the name of the role in Azure

Actions:Define which type of actions that a user can perform against a resource provider. (All Actions against the different resource providers can be found here > https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations ) or you can view actions from a resource provider directly from PowerShell here >

Get-AzureRMProviderOperation “Microsoft.Compute/virtualMachines/*” | FT OperationName, Operation, Description -AutoSize

AssignableScopes: Define if this role can be targeted directly at a subscription level or against a resource group. As an example we can have subscriptions listed here,

“AssignableScopes” : [ “/subscriptions/{subscriptionId1}” , “/subscriptions/{subscriptionId2}”




“Name” : “VM Restarter” ,

“Id” : “88888888-8888-8888-8888-888888888888” ,

“IsCustom” : true ,

“Description” : “Can restart virtual machines.” ,

“Actions” : [

“Microsoft.Storage/*/read” , “Microsoft.Network/*/read” , “Microsoft.Compute/*/read” , “Microsoft.Compute/virtualMachines/restart/action” , “Microsoft.Authorization/*/read” , “Microsoft.Resources/subscriptions/resourceGroups/read” , “Microsoft.Insights/alertRules/*” , “Microsoft.Insights/diagnosticSettings/*” , “Microsoft.Support/*”


“NotActions” : [ ], “DataActions” : [ ], “NotDataActions” : [ ], “AssignableScopes” : [




Once we have created this as a JSON file we can import this custom role into Azure using PowerShell or CLI > az role definition create role-definition ~/vmrestarter.json

Role Access in Azure

Also having a predefined role that we want to give to a particular user we also need to define that to the correct scope or level or access. Might be that we have a subscription with multiple resource group where we have multiple virtual machines or resources and we should ensure that we only give access on a certain level or to a certain resource beneath. In Azure we can define if a user should have access to multiple resource or multiple resource groups. It is important to remember that access that you assign at a parent scope is inherited at the child scope. Also important to define access to resources based upon groups and not using individual users.
Microsoft Azure and Security Best Pratices   Part 1 Identity

Group based Access

Combining this with dynamic groups we can also ensure that once a user has access to the Azure Portal we can customize if the user should have access based upon department or if the user has a approved device or not (NOTE: Do not confuse this with Conditional Access. CA does a real-time check before the end-user is allowed to gain access to for instance the Azure Portal based upon conditions. Dynamic attribute groups can be used to limit access inside the Azure Portal itself) there are multiple attributes that we can use to configure dynamic groups, most of them are found here > https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/groups-dynamic-membership also combine this with proper naming standards on Azure AD Groups which can be done using the latest PowerShell modules on Azure AD here >

Viewing all articles
Browse latest Browse all 12749

Latest Images

Trending Articles

Latest Images