Azure Policy for Security Compliance

Azure Policy is a service in Azure that allows you to create, assign, and manage policies that enforce rules and effects over your resources. These policies evaluate resource compliance and can take actions such as denying non-compliant resources, auditing existing resources for compliance, or deploying configurations automatically (e.g., installing an anti-malware agent). The primary purpose of Azure Policy is to enforce organizational standards and assess compliance at scale. It is central to security governance because it ensures resources adhere to security requirements (e.g., only allowing certain VM SKUs, requiring encryption at rest, or restricting public network access).

Azure Policy operates on a resource-level evaluation model. When a policy is assigned to a scope (management group, subscription, or resource group), the policy engine evaluates all resources within that scope against the policy definition. The evaluation occurs: - During resource creation or update (PUT/PATCH requests): The policy engine intercepts the request, evaluates the resource properties against the policy rules, and if the policy effect is 'Deny', the request is rejected before the resource is created. - On a periodic compliance scan: By default, a full compliance scan runs every 24 hours. This scan evaluates existing resources against all assigned policies and updates the compliance state. - On-demand: You can trigger a compliance scan manually using Azure CLI, PowerShell, or the portal.

The core components of Azure Policy are: - Policy Definition: A JSON document that describes the resource conditions (using 'if' block) and the effect to take (using 'then' block). Example definition that denies VMs not using managed disks:

{
  "if": {
    "allOf": [
      {
        "field": "type",
        "equals": "Microsoft.Compute/virtualMachines"
      },
      {
        "field": "Microsoft.Compute/virtualMachines/storageProfile.osDisk.managedDisk.id",
        "exists": "false"
      }
    ]
  },
  "then": {
    "effect": "deny"
  }
}

- Initiative Definition (Policy Set): A collection of policy definitions grouped together to achieve a broader goal, such as the 'Azure Security Benchmark' initiative. - Assignment: The process of applying a policy definition or initiative to a specific scope. Assignments can include parameters (e.g., allowed locations) and exclusions (e.g., a specific resource group). - Effect: The action taken when a resource is evaluated as non-compliant. Effects include: - Deny: Prevents the resource creation or update. Returns a 403 (Forbidden) error. - Audit: Logs a warning event in the activity log but does not block the request. - Append: Adds additional fields to the resource during creation or update (e.g., add a tag). - AuditIfNotExists: Audits resources that do not have a related resource (e.g., audit VMs without a backup). - DeployIfNotExists: Deploys a template to remediate non-compliant resources (e.g., deploy a Log Analytics agent to VMs). - Disabled: Effectively turns off the policy. - Modify: Adds, updates, or removes properties on a resource (similar to Append but can modify existing properties).

az policy definition create --name "deny-unmanaged-disks" --display-name "Deny VMs without managed disks" --description "This policy denies VMs that do not use managed disks." --rules '{"if":{"allOf":[{"field":"type","equals":"Microsoft.Compute/virtualMachines"},{"field":"Microsoft.Compute/virtualMachines/storageProfile.osDisk.managedDisk.id","exists":"false"}]},"then":{"effect":"deny"}}' --mode All

az policy assignment create --name "deny-unmanaged-disks-assignment" --policy "deny-unmanaged-disks" --scope /subscriptions/{subscriptionId}

az policy state trigger-scan --resource-group myResourceGroup

az policy state list --resource-group myResourceGroup

az policy remediation create --name "myRemediation" --policy-assignment "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/policyAssignments/deny-unmanaged-disks-assignment" --resource-discovery-mode ReEvaluateCompliance

policyresources
| where type == 'microsoft.authorization/policyassignments'
| project policyAssignmentId, scope, properties.policyDefinitionId

In a large enterprise with thousands of subscriptions, Azure Policy is used to enforce security baselines. For example, a financial services company must ensure that all storage accounts have encryption at rest enabled and that no public network access is allowed. They create a custom initiative 'Financial Security Baseline' with policies: 'Storage accounts should have encryption at rest enabled', 'Storage accounts should deny public network access', and 'Virtual machines should have disk encryption enabled'. They assign this initiative at the root management group level, affecting all subscriptions. Exclusions are made for a specific resource group used for testing. The compliance dashboard shows that 95% of resources are compliant; remediation tasks are created for the non-compliant ones. A common issue is that some application teams accidentally disable encryption, and the deny effect prevents them from doing so; they must request an exception via a policy exemption (which is a separate feature). Performance considerations: With tens of thousands of resources, the compliance scan may take several hours, but it is a background process. Remediation tasks should be run during off-peak hours to avoid impacting production. Another scenario: A healthcare organization uses Azure Policy to enforce HIPAA compliance. They assign the built-in 'HIPAA/HITRUST' initiative and also create custom policies to require specific tags (e.g., 'DataClassification: PHI') on all resources. They use the 'Append' effect to automatically add missing tags during resource creation. Misconfiguration example: If a policy with 'Deny' effect is assigned incorrectly (e.g., denying all VMs in a region where VMs are needed), it can block critical deployments. To avoid this, always test policies using 'Audit' effect first before switching to 'Deny'. Also, be aware of policy conflicts: if two policies assign different effects to the same resource, 'Deny' takes precedence, which can cause unexpected denials.