Azure Governance Part 3: Applying Controls and Security Policies

This is part three of a four-part series on Enterprise Governance in Microsoft Azure.

In part one, we discussed the four levels of management in the Azure Enterprise Portal: the Enterprise Agreement, departments, accounts, and subscriptions. In part two, we talked about the guiding principles behind dividing resources into resource groups and/or subscriptions. This blog post will explore how Azure Active Directory, role-based access control, and ARM policies work together to enforce organizational standards throughout your Azure environment.

Azure AD and RBAC: Better Together

The goal of security-minded organizations should be to give employees the exact permissions they need to do their jobs. Excessive permissions expose your cloud environment to risk from without and within. However, too few permissions mean that employees can’t get their work done efficiently. Properly utilizing Azure Active Directory (AD) and role-based access control (RBAC) within the Azure hierarchy facilitates segregation of duties and least privilege.

Each Azure subscription is associated with a single Azure Active Directory instance. Administrators can assign access rights using the Azure portal, Azure command-line tools, and Azure Management APIs to allow users and groups from that directory to manage resources in the Azure subscription. Leveraging Azure AD user accounts instead of Microsoft IDs is crucial because Microsoft IDs are privately owned by individuals and not managed by the organization. Therefore, they are not subject to password policies and cannot be quickly disabled in the event they are compromised.

To get started with Azure AD, there are a few different paths to consider. First, if your organization already uses Microsoft Office 365, then you already have an Azure AD tenant. You can use identities from this directory when establishing your Azure Enterprise enrollment, creating subscriptions, and assigning RBAC permissions. If you are starting from scratch, you can also create a new Azure AD tenant in the Azure Account Portal. In most circumstances, identity management and billing for existing Pay-As-You-Go Azure subscriptions can be centralized by associating the existing account with your Enterprise Agreement and transferring ownership to an Azure AD account through the Azure Enterprise Portal. If your organization uses traditional Windows Server Active Directory, Azure AD allows you to synchronize your on-premises identities, most commonly using Azure AD Connect. This process opens the doors for centralized identity management, federation, and single sign-on, which reduces administrative overhead and improves the user experience.

It is important to understand how Azure AD fits into the Azure hierarchy. Each subscription in Azure trusts only one Azure AD directory. However, within an Enterprise Agreement multiple subscriptions can be associated with the same Azure AD directory. This is important because it allows an organization to use a uniform set of users and groups across the enterprise. As you move down the hierarchy a resource group can belong to only one subscription, and each resource belongs to only one resource group. Administrators grant access by assigning the appropriate role to users and groups at a specified scope. The scope of a role assignment can be anywhere in this hierarchy: a subscription, a resource group, or a single resource. Bear in mind that access granted at a parent scope is inherited by its child scopes. For example, a user with access to a resource group can manage all the resources it contains, like websites, virtual machines, and subnets.

Leveraging RBAC empowers administrators to segregate duties within the organization and grant users only the amount of access they need to do their jobs. Instead of the old classic mode model that gave everybody unrestricted permissions to Azure subscriptions and resources, Resource Manager and RBAC can delegate specific tasks. For example, RBAC can allow one employee to manage virtual machines in a subscription, while another can only manage SQL databases within the same subscription.

Azure RBAC comes in three general flavors:

• Owner – Has full access to all resources including the right to delegate access to others.

• Contributor – Can create and manage all types of Azure resources but can’t grant access to others.

• Reader – Can view existing Azure resources.

Each subscription has over 30 built-in roles with granular resource-based permissions. Some examples of these are Network Contributor, SQL DB Contributor, and Virtual Machine Contributor.

Custom RBAC Roles

However, if Azure’s built-in roles don’t meet your organization’s specific delegation needs, you can also create custom roles. Custom roles are stored in the Azure AD directory and can therefore be shared across all subscriptions within an Enterprise Agreement. Just like built-in roles, custom roles can be assigned to users, groups, and applications at the subscription, resource group, and resource level. Custom roles can be created using Azure PowerShell, the Azure Command-Line Interface (CLI), or via the REST API. The most straightforward way to create a custom role is to use the New-AzureRmRoleDefinition PowerShell cmdlet and a JSON input file. The easiest way to build the JSON input file is to use Get-AzureRmRoleDefinition to export an existing role to a JSON file and customize it for the new role you want to create. The custom properties that must be configured in the JSON file are these:

• Actions – A collection of operation strings that identify securable operations of Azure resource providers to which the role grants access.

• NotActions – Used if the set of operations that you wish to allow is more easily defined by excluding restricted operations (not a deny).

• AssignableScopes – Specifies the scopes (subscriptions, resource groups, or resources) within which the custom role is available for assignment and controls who can view, modify, and delete the role.

Enforcing Standards with ARM Policies

Another means of applying controls to your organization’s Azure environment are Azure Resource Manager (ARM) custom policies. ARM policies are an explicit deny mechanism which can prevent users from breaking standards needed to manage your organization’s resources. Custom policies are commonly used to enforce naming conventions, control the types of resources that can be provisioned, require resource tags, and restrict the locations in which the resources can be provisioned. The first step in applying a policy is creating a policy definition. Policy definitions describe the actions or resources that are specifically denied. Policy definitions are created using JSON input files that include parameters, condition/logical operators, and a deny or audit effect (logging). For example, an administrator can create a policy that enforces a server naming convention. Policy definitions can be created using the New-AzureRmPolicyDefinition PowerShell cmdlet and then applying it at a scope such as the subscription, resource group, or an individual resource.

New-AzureRmPolicyDefinition -Name ServerNamingPolicyDefinition -Description “Policy to enforce server naming convention” -Policy “C:\json\policyServerNaming.json”

Like RBAC, inheritance principles apply to ARM policies. If a policy is applied to a subscription or resource group, it is applicable to all the resources within it.

In summary, we recommend employing Azure Active Directory, role-based access control, and ARM policies within the Azure hierarchy to enforce organizational standards across all cloud resources and facilitate sound security practices such as segregation of duties and least privilege. In part four of our series we will discuss resource locks, Azure automation, and Azure Security Center.  

Need Help?

Are you interested in exploring Microsoft Azure but concerned about governance and how to make public cloud fit within your IT model? Credera has extensive experience in cloud infrastructure design and implementation. If you have questions or would like to discuss cloud and infrastructure solutions, reach out to us at findoutmore@credera.com.

Explore Our Microsoft Consulting Services  →

• Microsoft Azure
• Azure
• Azure AD
• Microsoft Office 365
• Azure RBAC
• ARM Policies
• Azure Resource Manager