Time and time again, many people get that go ahead for cloud but don't want to unleash everyone into the environment. This is with good understanding. Without policies and governance in place, cloud spend can go unmonitored or resources deployed not following your company's standards. Getting a good standard in place with Azure Policy can make sure you and your team keep an organized Azure environment in the short term and long term as the footprint grows. Security should always be first of mind as well.
Simplicity is key in establishing your definitions and making sure they align to your business needs. Get stakeholders involved and start with some fundamental policies to get established.
Below are common business concerns:
| Risk |
Description |
Indicators |
Resolution |
| Financial accuracy |
If resources are deployed in Azure and there is no consistent metadata strategy, it will be difficult to appropriately map costs back through the CFO office. |
Resources exist with no tagging metadata |
Create a policy statement and enforce standards. |
| Data location |
Some requirements require data sovereignty and for this use case data must remain in the U.S. |
Resources can be deployed to various regions outside of the US by default. |
Create a policy for Azure regions. |
| Unnecessary spending |
Resources provisioned that are no longer utilized or were not properly de-provisioned during development periods introduce waste to the business. In addition, over provisioning resources creates additional unneeded costs. |
Resources underutilized or identified as over provisioned |
Create policy statement and enforce periodic reviews for “waste”. |
| Management inefficiencies |
Inconsistent naming or tagging of resources can make it difficult for IT support teams to troubleshoot incidents, as well as support day to day requests from impacting application teams. Ensuring a consistent naming and tagging standard helps IT to respond more quickly.
|
X% of resources do not have a compliant naming or tagging structure in place |
Create policy statement and enforce via automation. |
| Business interruption |
Established SLAs are needed to ensure that systems are built in compliance with business requirements. Systems should be designed around SLAs and investigated if they are not meeting them.
|
Critical systems are experiencing less than 99.95% uptime |
Create policy statement for production systems. |
Now what policies can we use to address these concerns? Right away three come to mind - Allow specific VM sizes, allow specific resource regions and block resource types.
Built in Azure Policies
| Azure Policy |
Description |
Allowed Options |
| Allowed virtual machine size SKUS |
Create an Azure policy JSON template to limit the instance types that can be created in Azure |
D Series instances of all types. Fe series all types |
| Allowed locations |
Control the physical location where resources can be deployed |
Only allow West US2, Central US and East US |
| Not allowed resource types |
Specify resource types that your organization cannot deploy. |
Do not allow SQL Managed Instances
*microsoft.sql/managedinstances
|
Other built in polices to consider in Azure
| Policy |
Description |
Decision |
Values |
| Storage accounts should be limited by allowed SKUs |
Restrict the set of storage account SKUs that your organization can deploy. |
Do not allow Geo-Redundant storage only Local-Redundant |
Standard_LRS, Premium_LRS |
| Storage accounts should have infrastructure encryption. |
Enable infrastructure encryption for higher level of assurance that the data is secure. When infrastructure encryption is enabled, data in a storage account is encrypted twice. |
For compliance storage accounts will be encrypted |
No parameters needed for this |
| Require a tag and its value on resources |
Enforces a required tag and its value. Does not apply to resource groups. |
Require cost center tags for chargeback |
Required Tag Name: Cost Center
Required Tag Value: 1984 |
| Managed disks should disable public network access |
Disabling public network access improves security by ensuring that a managed disk isn't exposed on the public internet. Creating private endpoints can limit exposure of managed disks. Learn more at: https://aka.ms/disksprivatelinksdoc. |
Do not expose public network to managed disk resource |
No parameters needed for this |
| Only approved VM extensions should be installed. |
This policy governs the virtual machine extensions that are not approved. |
Approve Disk encryption and Windows Security Center agent |
AzureDiskEncryption
WindowsAgent.AzureSecurityCenter
|
| Audit machines with insecure password security settings |
This initiative deploys the policy requirements and audits machines with insecure password security settings. For more information on Guest Configuration policies, please visit https://aka.ms/gcpol |
This is actually an initiative containing policies for maximum password age, reusing previous passwords etc |
NOTE: it is important when assigning these policies to use the Initiative. The DeployIfNotExists policy loads the VM extension, which is a requirement for Audit/AuditIfNotExists policies in Guest Configuration to work properly. |
These again are just policies commonly deployed in the wild. Your requirements will vary. Once a standard is agreed upon and Azure Polices are defined. You can make sure your environment has the policies enforced and compliant.
Note - Azure Policy uses a JSON format to form the logic the evaluation uses to determine whether a resource is compliant or not.
We will dive deeper into policy inheritance, grouping and automation in the next post.
