Using Azure Policy to Enforce Security Standards for .NET Resources

Australian development teams operating in Sydney, Melbourne, Brisbane, and Perth have spent the last few years shifting .NET workloads into Azure regions such as Australia East and Australia Southeast. That migration brings speed and scale, but it also brings the question of how to keep every resource — from App Service plans to Storage accounts backing an API — aligned with security baselines. Azure Policy answers that question by turning written rules into automated guardrails, so that every .NET deployment, whether authored by a contractor in Parramatta or a permanent team in Docklands, is judged against the same controls.

The technology is essentially a policy-as-code engine built directly into the Azure control plane. Engineers can author definitions in JSON, group them into initiatives, and assign those initiatives at management group, subscription, or resource group scope. When a .NET developer spins up a new Azure SQL database, a Linux App Service, or a Key Vault instance, the platform evaluates the request against the assigned policies before the resource is created. Anything that violates a rule is denied, audited, or remediated, depending on the chosen effect.

Why governance matters for .NET workloads hosted in Azure

.NET applications rarely live in isolation. A modern solution typically weaves together App Service, Functions, API Management, Azure SQL, Storage, Key Vault, Application Insights, and sometimes Container Apps. Each of those components exposes its own configuration surface, and small mistakes compound quickly. A Storage account with public blob access enabled, or a Cosmos DB account without Entra ID-only authentication, can quietly create a path for data leakage. Azure Policy lets platform engineers encode these expectations once, then apply them across every subscription that hosts a .NET estate.

The regulatory environment in Australia adds weight to this conversation. Many enterprises fall under the Prudential Standard CPS 234 from APRA, the Notifiable Data Breaches scheme, or the Australian Privacy Principles enforced by the Office of the Australian Information Commissioner. Healthcare providers interact with the My Health Records Act, while government agencies follow the Australian Government Information Security Manual. Azure Policy initiatives can be tailored to mirror these obligations, mapping controls such as "audit VMs without managed identity" or "deny Storage accounts without private endpoints" to specific compliance frameworks.

There is also a practical engineering benefit. When teams in Adelaide or the Sunshine Coast onboard a new .NET microservice, the policy assignment already guarantees that resources comply with encryption, tagging, and diagnostic settings. Code reviewers stop arguing about infrastructure hygiene and focus on business behaviour. Time spent in pull-request discussions shrinks, and production incidents caused by misconfigured resources drop noticeably.

Core building blocks of Azure Policy for .NET deployments

The vocabulary of Azure Policy is small but precise. A definition describes a rule using JSON, with an if block that selects resources through Azure Resource Graph queries and a then block that declares what should happen. An initiative bundles several definitions into a single assignment, which is convenient when representing a complete standard such as the CIS Microsoft Azure Foundations Benchmark. An assignment binds the definition or initiative to a scope, and an effect determines the action: Deny, Audit, Append, Modify, DeployIfNotExists, or AuditIfNotExists.

For .NET workloads, the most common effects are Deny for hard guardrails (such as blocking public Storage blobs), Audit for visibility (such as reporting App Service instances without HTTPS only), and Modify for lightweight remediation (such as adding a missing tag or configuring minimum TLS version). DeployIfNotExists is valuable when a resource must always travel with a companion — for example, ensuring every App Service has Application Insights linked through a DeployIfNotExists rule that adds the instrumentation key.

Built-in definitions cover many scenarios out of the box. The "Audit Windows VMs without managed identity" rule, "Deny storage accounts without minimum TLS version 1.2", and "Append tag and its value to resources" definitions are useful starting points. Custom definitions extend these patterns, and the Azure Policy GitHub repository hosts community samples that can be cloned and adapted.

Authoring and assigning policies for .NET scenarios

Most teams start by running the Azure Policy compliance scan against a pilot subscription. The portal's Compliance blade surfaces non-compliant resources, which often include legacy App Service plans with managed identity disabled, classic Storage accounts, and older API Management SKUs. Once the baseline is understood, an initiative is authored that combines relevant built-in definitions with a small number of custom rules tailored to .NET realities.

A useful custom pattern is to enforce secure deployment practices for .NET APIs. A definition can use the Microsoft.Web/sites resource type, check kind equals api, and assert that httpsOnly is true, clientAffinityEnabled is false, and siteConfig.minTlsVersion is at least 1.2. Another definition can target Microsoft.Sql/servers and require an Azure AD administrator, which matters when .NET services connect using Microsoft Entra authentication. Yet another can target Microsoft.KeyVault/vaults and require that enableSoftDelete is true and enablePurgeProtection is enabled, since many .NET apps cache secrets in vault references.

Common custom patterns worth adding to a .NET initiative include:

• Deny App Service deployments without HTTPS only and minimum TLS 1.2
• Require an Azure AD administrator on every SQL server used by .NET data services
• Enforce Key Vault soft delete and purge protection on secret references
• Append standard tags such as environment, ownerEmail, and costCentre to new resources

Assignment is where the rules become real. Many Australian enterprises attach the initiative at the management group that covers their production landing zones, while leaving developer subscriptions in Audit mode so that experimentation is not blocked. A common pattern is to maintain two parallel initiatives — one strict assignment for production with Deny effects, and one advisory assignment for non-production with Audit and DeployIfNotExists effects. Exemptions can be granted through the policy exemption feature, with an expiry date and a business justification stored alongside it.

When teams adopt Infrastructure-as-Code using Bicep or Terraform, policy assignments can be co-deployed with the platform resources, ensuring that every new subscription comes with the governance baseline already attached. This reduces the chance of a well-meaning developer spinning up an environment that escapes review.

Operational workflow and tooling around Azure Policy

Policy work is never finished. Definitions need versioning, initiatives need revision histories, and assignments drift as subscriptions move. The recommended workflow is to store definitions in a Git repository, review changes through pull requests, and deploy them through a pipeline that uses the Azure CLI, PowerShell, or AzOps. This mirrors the same engineering discipline that .NET developers already apply to application code, and it keeps governance auditable.

Remediation tasks handle existing non-compliant resources. When a definition such as "Configure Azure Activity log to use a specified workspace" is assigned with DeployIfNotExists, Azure creates a remediation task that lists each non-compliant resource. Engineers can trigger remediation from the portal, run it through PowerShell with Start-AzPolicyRemediation, or wire it into a GitHub Actions pipeline that runs nightly against staging environments before promoting to production.

Monitoring closes the loop. Activity log events, compliance state changes, and remediation outcomes can be streamed into a Log Analytics workspace. A simple Kusto query such as PolicyStates | where IsCompliant == false | summarize count() by PolicyDefinitionName gives a quick view of which rules are firing most often. Many Australian platform teams ship a Power BI dashboard on top of Log Analytics, surfacing compliance percentages per business unit. This data also feeds internal risk reviews, which often include the chief information security officer and representatives from legal and finance.

A practical checklist for day-to-day operations looks like this:

• Review non-compliant resources weekly through the Compliance blade
• Triage remediation tasks before they age beyond thirty days
• Reassign expired exemptions or convert them into compliant resources
• Refresh built-in definitions quarterly to pick up new Microsoft releases

For teams adopting GitOps, the same repository that stores Bicep modules for .NET APIs can hold policy definitions. Pull-request reviewers can then validate that a new rule does not accidentally break production workloads by checking the assignment scope and exemption list before merge.

Scaling maturity across multiple Australian teams

Once a single subscription is governed, the next step is extending the model across the organisation. A federated model works well for distributed teams in places like Canberra, Hobart, and the Gold Coast. Platform engineering owns the canonical initiative, while individual business units can layer additional definitions through subscription-level assignments. This balance preserves central standards while allowing local flexibility, which is important when teams have different workloads and risk appetites.

Maturity shows up in concrete habits that are easy to observe:

• Every .NET service carries an ownerEmail tag, enforced by a Modify policy and audited monthly
• Non-compliance trends are reviewed in a recurring governance forum with finance and security representatives
• The policy codebase is versioned semantically, with deprecation notices and migration guides whenever behaviour changes

The long-term value of Azure Policy for .NET resources is that security standards become a property of the platform rather than a checklist that developers remember to follow. New services inherit compliance automatically, and the cost of maintaining a secure posture decreases over time. Australian organisations that combine Azure Policy with broader practices — defender for cloud, secure DevOps pipelines, and threat modelling — find that their .NET estates become measurably safer without slowing delivery.