This is the fourth of a five-part series focused on enterprise governance in Microsoft Azure.
In parts one, two, and three, we discussed the four levels of management in the Azure Enterprise Portal, the guiding principles behind dividing resources into resource groups and/or subscriptions, cloud cost management, managing identities through Azure Active Directory (AD), role-based access control (RBAC), and privileged identity management (PIM). In this article we will examine enforcement mechanisms and supporting features and tools such as Azure Policy, Resource Locks, Blueprints, and Azure Automation.
Another means of applying controls to your organization’s Azure environment is through Azure Policy. It enforces various rules over Azure resources to ensure compliance with internal and external standards is maintained. Policies focus on resource properties during deployment and for already deployed resources can enforce and/or audit for compliance or non-compliance. Examples of policies are allowed storage account SKUs, allowed locations, enforce resource tag and its value, allowed resource types, etc. These policies provide guardrails for your Azure environment and help to ensure your Azure resources maintain compliance with corporate standards.
Figure 1. Azure Policy
Policies are applied within a scope (management group, subscription, resource group) and apply to all of the resources within the scope. Exclusions can be configured for a single resource or group of resources based on attribute (resource group, resource tag, etc.). These policies surface violations before deployment and build compliance checks into the deployment process.
Certain policies are able to automatically remediate non-compliant resources through bulk updates. These policies use a managed identity managed by Azure Active Directory to deploy the remediation for non-compliant resources. A common policy used in this scenario is to apply appropriate resource tags across a subscription or a resource group or to update a resource tag within that scope. Environment, criticality, or application are example resource tags that may be applicable for this policy depending on how your subscriptions and resource groups are organized.
Resource tags are key/value pairs that you can apply to resources for logical organization. An example of this would be a key of “Environment” and a value of “Development” on a development VM. Each resource is limited to 15 directly applied resource tags, which are visible across multiple resource groups for a wide context view. Azure policies can be used to enforce consistent application of resource tags, which is useful for ensuring that a department or application name is tagged on all resources in a resource group, for example. This can help with automating processes against logical groupings of resources as well as with billing chargebacks in environments with multiple departments or business units. Resource tags are available on billing reports in the Enterprise Portal for resource grouping and filtering purposes.
Resource tagging strategies are used to identify the metadata useful to the organization (e.g., Owner, BillTo, Environment, etc.) and can be enforced for each of the following:
Application Service Environments/web servers
Resource tags can be applied in the Azure Portal, using PowerShell, using the Azure CLI, or in resource templates and can be enforced through Azure Policy. Example resource tags are found below:
protecting resources with resource locks
When we discussed the centralized resource group model, one of the primary benefits was that shared infrastructure resources like virtual networks would be segregated into resource groups controlled by centralized IT engineering teams. Resource Locks represent another layer of protection to critical resources that could cause significant business disruption if modified or deleted. For example, an organization may want to prevent their ExpressRoute Gateway from being removed when their critical apps rely on hybrid network connectivity or prevent the deletion of a storage account that hosts critical data. Two types of locks are available in Azure Resource Manager, CanNotDelete and ReadOnly. They can be implemented in the Resource Manager portal, with PowerShell using the “New-AzResourceLock” cmdlet, or via Bash cmdlet using “az lock resource,” or lastly via ARM templates. Locks can be applied at the subscription, resource group, or individual resource level, and are typically created by users with the owner or user access administrator roles. Once they are added, they apply to all resources or policies within that scope for all users within the organization.
Azure Policy, Resource Manager (ARM) templates, resource groups, and RBAC each play a role in ensuring Azure environments adhere to organizational requirements and standards. Azure Blueprints package these key environment artifacts into a single design definition. Administrators can use Azure Blueprints to design and quickly deploy a repeatable collection of Azure resources that are always compliant with organizational standards. These reusable artifacts are stored and version controlled within the Azure portal. Blueprint definitions can be built from scratch or deployed from templates found in the portal. Some examples of available standards-based templates are ISO 27001, NIST SP 800-53 R4, PCI-DSS v3.2.1, and HIPAA HITRUST. Azure Blueprints can be stored and applied at the management group or subscription level. They can also be locked to prevent any defined parameters from being changed into a non-compliant state. The current limitation of blueprint locking is it applies to all defined parameters and cannot be done at a more granular level.
Figure 2. Templatizing infrastructure with Azure Blueprints
Another standardization tool targeted toward operations is Azure Automation. Rather than performing common, repetitive tasks individually through the Azure Portal or PowerShell, you can use Azure Automation Runbooks to automate resource management and processes, reducing implementation time and the possibility of error. In addition, PowerShell Desired State Configuration (DSC) is available to help automate configuration management, ensuring standardized and enforced settings in deployed nodes.
Runbooks can take the form of text-based PowerShell or PowerShell Workflow, as well as graphical versions of each of those. A convenient way to get started is with the Runbook Gallery. From there, you can take runbooks for common tasks such as shutting down or deploying VMs and customize them to your specific needs. While those are simple examples, runbooks are also scalable up to complex workflows requiring multiple steps.
Figure 3. Azure Runbooks
Scenarios for utilizing Azure Automation are often focused on the lifecycle management of resources. Build and Deploy tasks can be accomplished through Runbooks or Azure Resource Manager (ARM) templates that integrate into tools like Jenkins and Azure DevOps. Once deployed, VMs can be configured using Desired State Configurations at the infrastructure and application layer.
Identify changes on machines that result in errors and escalate appropriately using built-in workflows connected to management systems.
Automate the quarantine of identified at-risk VMs and configure notifications in the event of an incident.
Utilize RBAC to control access to resources and identify unused resources through Automation’s governance capabilities.
enforce controls and standards
Azure Policy, Resource Locks, Tagging, Azure Blueprints, and Automation capabilities provide the building blocks and tools required to enforce controls and standards within your Azure environment. In our fifth and final article in this series, we will discuss the options and tools available to review, monitor, and track the activity and security posture of your Azure workloads through Azure Security Center, Azure Monitor, Azure Sentinel, and Advisor.
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, contact us at firstname.lastname@example.org.