Turning Azure Policy Signals into Actionable Governance Insights
Most Azure Policy reporting stops at compliance status. Useful, yes — but not enough. When a control fails, teams need to know what failed, why it matters, and who should act. That gap becomes obvious at enterprise scale. A failed policy evaluation is only a signal. By itself, it does not tell you whether the issue affects recovery, auditability, telemetry, or another control leaders care about. That is why joining PolicyStates with PolicyAssignments matters. One tells you the outcome. The other tells you which control was applied, where, and in what governance context. Together, they turn Azure Policy from a compliance feed into a control intelligence layer. The problem: PolicyStates alone tells you what is non-compliant, but not always why it matters Microsoft’s sample ARG queries quickly show which resources are non-compliant. Helpful, but still incomplete. They show the result, not the business meaning. At enterprise scale, that distinction matters. A storage account without blob soft delete is a recovery risk. Missing Azure Activity logs creates an audit gap. A virtual machine without Azure Monitor Agent creates a telemetry blind spot. Azure Policy shows the state. The join to PolicyAssignments explains why it matters. There is also a technical reason to care about assignments. The same PolicyDefinitionId can appear in multiple assignments across different scopes. That makes PolicyAssignmentId the operational key. How Azure Policy compliance data flows Azure Policy evaluates resources against JSON-based rules. Those rules are packaged as policy definitions and can be grouped into initiatives. Once assigned to a scope, the policy engine evaluates matching resources during creation, updates, assignment changes, and regular compliance cycles. The results are exposed through PolicyStates and PolicyEvents, and can also be queried through Azure Resource Graph. This is the architecture flow for turning the ARG query into a scheduled governance report through Logic App: The key shift is operational. A Logic App can run the ARG query on a schedule, format the results, and email them to stakeholders. That turns a manual check into a repeatable governance report. The analytical pattern: enrich compliance with assignment context The analytical flow is straightforward: Configure a Recurrence trigger in Logic App so the report runs on the schedule you need. Use an HTTP action with managed identity to run the ARG query against PolicyStates and join it to PolicyAssignments. Filter on the control assignments that matter to your organisation and shape the response into a compact HTML table or CSV. Send the output by email to governance, engineering, or audit stakeholders so the insight reaches people without requiring them to open the portal. In practice, the query starts with non-compliant resources and enriches them with assignment details such as the assignment name and optional metadata like owner. That is the shift from raw signal to governance insight. A simple implementation pattern is: schedule the Logic App, run the ARG query with managed identity, format the output, and send the report. HTML works well for leadership emails; CSV is better for downstream analysis. ARM template for the Logic App If you want to deploy this pattern instead of building it step by step, I have also published an ARM template for the Logic App in my GitHub repository. The template is intended to help you stand up the scheduled policy compliance workflow faster and then customise the query, email recipients, and formatting for your own environment. This makes the architecture in this post directly reusable: schedule the Logic App, run the ARG query, shape the output, and send a control-focused report without having to assemble the workflow from scratch. See the repository for the template and related Microsoft Sentinel automation content. Reference ARG query policyResources | where type =~ 'microsoft.policyinsights/policystates' | where properties.complianceState == 'NonCompliant' | extend ResourceId = tostring(properties.resourceId), PolicyAssignmentId = tolower(trim(@" ", tostring(properties.policyAssignmentId))), SubscriptionId = tostring(subscriptionId), LastEvaluated = todatetime(properties.timestamp) | extend ResourceName = tostring(extract(@"[^/]+$", 0, ResourceId)) | extend ResourceProvider = tostring(extract(@"providers/([^/]+)/", 1, ResourceId)) | extend ResourceCategory = case( ResourceId has "Microsoft.Compute/virtualMachines", "VM", ResourceId has "Microsoft.Storage/storageAccounts", "Storage", ResourceId has "Microsoft.Network/virtualNetworks", "Network", ResourceId has "Microsoft.Sql/servers", "SQL", ResourceId has "Microsoft.KeyVault/vaults", "Key Vault", ResourceProvider =~ "Microsoft.Compute", "Compute", ResourceProvider =~ "Microsoft.Storage", "Storage", ResourceProvider =~ "Microsoft.Network", "Network", ResourceProvider =~ "Microsoft.KeyVault", "Key Vault", "Other" ) | project ResourceId, ResourceName, ResourceCategory, SubscriptionId, PolicyAssignmentId, LastEvaluated | join kind=inner ( policyResources | where type =~ 'microsoft.authorization/policyassignments' | extend AssignmentName = tostring(properties.displayName), AssignmentId = tolower(trim(@" ", tostring(id))), Scope = tostring(properties.scope), PolicyOwner = tostring(properties.metadata.owner) | where AssignmentName has "CSTM--Configure blob soft delete on a storage account" or AssignmentName has "Configure Azure Activity logs to stream to specified Log Analytics workspace" or AssignmentName has "Audit diagnostic setting for selected resource types" | project AssignmentId, AssignmentName, Scope, PolicyOwner ) on $left.PolicyAssignmentId == $right.AssignmentId | project SubscriptionId, ResourceId, ResourceName, ResourceCategory, AssignmentName, AssignmentId, Scope, ['LastEvaluated[UTC]'] = LastEvaluated What this query is doing — in plain English This query finds Azure resources that are currently NonCompliant with Azure Policies by reading data from the PolicyStates table in Azure Resource Graph. It extracts useful details such as Resource ID, Resource Name, Resource Type/Category, Subscription ID, Policy Assignment ID, and the last evaluation timestamp. Resources are categorized into groups like VM, Storage, Network, SQL, and Key Vault based on their resource type/provider. It then joins the non-compliant resources with specific policy assignments (three named policies) to show which policy caused the non-compliance, along with the policy scope, and evaluation time. Why CISOs and governance leaders should care For a CISO, this is not about counting failed evaluations. It is about knowing whether critical controls are drifting, where the risk sits, and who owns the response. Three use cases stand out: Audit readiness: show control-focused evidence instead of a flat list of resource IDs. Ownership: enrich assignments with metadata so findings can be routed to the right team faster. Prioritization: focus on the controls that matter now, not every non-compliant resource in the estate. Operational benefits: scalable, repeatable, and security-friendly From an engineering perspective, this pattern is attractive because it is repeatable, scalable, and aligned to the native Azure Policy data model. It also fits naturally into operational tooling. The enriched output can feed workbooks, dashboards, Sentinel content, and alerting workflows. Closing thought At small scale, Azure Policy can be reviewed in the portal. At enterprise scale, that quickly becomes noise. The better question is not Which resources are non-compliant? It is Which important controls are failing, where, and who should act? That is what makes this pattern powerful: it turns Azure Policy from a compliance dashboard into a control intelligence layer that works for both engineers and executives.Understanding Azure SQL Data Sync Firewall Requirements
Why IP Whitelisting Is Required and What Customers Should Know Azure SQL Data Sync is commonly used to synchronize data between on‑premises SQL Server databases and Azure SQL Database. While the setup experience is generally straightforward, customers sometimes encounter connectivity or configuration issues that are rooted in network security and firewall behavior. This blog explains why Azure SQL Data Sync requires firewall exceptions, what type of IP addresses may appear in audit logs, and how to approach this topic from a security and documentation standpoint—based on real troubleshooting discussions within the Azure SQL Data Sync ecosystem. The Scenario: Sync Agent Configuration Fails Despite Valid Setup A frequently reported issue occurs when the Azure SQL Data Sync Agent (installed on an on‑premises server) fails to save its configuration. The error typically indicates that a valid agent key is required—even when: The agent key was freshly generated from the Azure SQL Data Sync portal Connection tests succeed The agent has been reinstalled or the server restarted New sync groups were created Despite these efforts, synchronization does not proceed until a specific public IP address is allowed through the Azure SQL Database firewall. Why Firewall Rules Matter for Azure SQL Data Sync Azure SQL Database is protected by a server‑level firewall that blocks all inbound traffic by default. Any external client—including the Data Sync Agent—must be explicitly allowed to connect. In Azure SQL Data Sync: The Data Sync Agent runs on‑premises It connects outbound over TCP port 1433 It uses the public endpoint of the Azure SQL logical server The Azure SQL firewall must allow the public IP address used by the agent If this IP is not allowed, the agent cannot complete configuration or perform synchronization operations—even if authentication and permissions are otherwise correct. Identifying the Required IP Address In the referenced discussion, the required IP address was identified by reviewing Azure SQL audit logs, which revealed connection attempts being blocked at the firewall layer. Once this IP address was added to the Azure SQL server firewall rules, synchronization completed successfully. This highlights an important point: Audit logs can be a reliable way to identify which IP address must be whitelisted when Data Sync connectivity fails. Is This IP Address Owned by Microsoft? Can It Change? A natural follow‑up question is whether the observed IP address is Microsoft‑owned, and whether it can change. From the discussion: Azure SQL Data Sync relies on Microsoft‑managed service infrastructure Some outbound connectivity may originate from Azure service IP ranges Microsoft publishes official IP ranges and service tags for transparency However, documentation does not guarantee that a single static IP will always be used. Customers should therefore treat firewall configuration as a network security requirement, not a one‑time exception. Related Microsoft Resources While Azure SQL Data Sync documentation focuses on setup and troubleshooting, firewall requirements are often implicit rather than explicitly called out. The following Microsoft resources were referenced in the discussion to help customers understand Azure service IP ownership and ranges: Gateway IP addresses – Azure Synapse Analytics Download Azure IP Ranges and Service Tags – Public Cloud These resources can help security teams validate Microsoft‑owned IPs and plan firewall policies accordingly. Key Takeaways for Customers ✅ Azure SQL Data Sync requires firewall access to Azure SQL Database ✅ The public IP used by the Data Sync Agent must be explicitly allowed ✅ Audit logs are useful for identifying blocked IPs ✅ IP addresses may belong to Microsoft infrastructure and can change over time ✅ Firewall configuration is a security prerequisite, not an optional step Closing Thoughts Azure SQL Data Sync operates securely by design, leveraging Azure SQL Database firewall protections. While this can introduce configuration challenges, understanding the network flow and firewall requirements can significantly reduce setup friction and troubleshooting time. If you're implementing Azure SQL Data Sync in a locked‑down network environment, we recommend involving your network and security teams early and validating firewall rules as part of the initial deployment checklist.Unlocking Private IP for Azure Application Gateway: Security, Compliance, and Practical Deployment
If you’re responsible for securing, scaling, and optimizing cloud infrastructure, this update is for you. Based on my recent conversation with Vyshnavi Namani, Product Manager on the Azure Networking team, I’ll break down what private IP means for your environment, why it matters, and how to get started. Why Private IP for Application Gateway? Application Gateway has long been the go-to Layer 7 load balancer for web traffic in Azure. It manages, routes, and secures requests to your backend resources, offering SSL offloading and integrated Web Application Firewall (WAF) capabilities. But until now, public IPs were the norm, meaning exposure to the internet and the need for extra security layers. With Private IP, your Application Gateway can be deployed entirely within your virtual network (VNet), isolated from public internet access. This is a huge win for organizations with strict security, compliance, or policy requirements. Now, your traffic stays internal, protected by Azure’s security layers, and only accessible to authorized entities within your ecosystem. Key Benefits for ITPRO 🔒 No Public Exposure With a private-only Application Gateway, no public IP is assigned. The gateway is accessible only via internal networks, eliminating any direct exposure to the public internet. This removes a major attack vector by keeping traffic entirely within your trusted network boundaries. 📌 Granular Network Control Private IP mode grants full control over network policies. Strict NSG rules can be applied (no special exceptions needed for Azure management traffic) and custom route tables can be used (including a 0.0.0.0/0 route to force outbound traffic through on-premises or appliance-based security checkpoints). ☑️ Compliance Alignment Internal-only gateways help meet enterprise compliance and data governance requirements. Sensitive applications remain isolated within private networks, aiding data residency and preventing unintended data exfiltration. Organizations with “no internet exposure” policies can now include Application Gateway without exception. Architectural Considerations and Deployment Prerequisites To deploy Azure Application Gateway with Private IP, you should plan for the following: SKU & Feature Enablement: Use the v2 SKU (Standard_v2 or WAF_v2). The Private IP feature is GA but may require opt-in via the EnableApplicationGatewayNetworkIsolation flag in Azure Portal, CLI, or PowerShell. Dedicated Subnet: Deploy the gateway in a dedicated subnet (no other resources allowed). Recommended size: /24 for v2. This enables clean NSG and route table configurations. NSG Configuration: Inbound: Allow AzureLoadBalancer for health probes and internal client IPs on required ports. Outbound: Allow only necessary internal destinations; apply a DenyAll rule to block internet egress. User-Defined Routes (UDRs): Optional but recommended for forced tunneling. Set 0.0.0.0/0 to route traffic through an NVA, Azure Firewall, or ExpressRoute gateway. Client Connectivity: Ensure internal clients (VMs, App Services, on-prem users via VPN/ExpressRoute) can reach the gateway’s private IP. Use Private DNS or custom DNS zones for name resolution. Outbound Dependencies: For services like Key Vault or telemetry, use Private Link or NAT Gateway if internet access is required. Plan NSG and UDRs accordingly. Management Access: Admins must be on the VNet or connected network to test or manage the gateway. Azure handles control-plane traffic internally via a management NIC. Migration Notes: Existing gateways may require redeployment to switch to private-only mode. Feature registration must be active before provisioning. Practical Scenarios Here are several practical scenarios where deploying Azure Application Gateway with Private IP is especially beneficial: 🔐 Internal-Only Web Applications Organizations hosting intranet portals, HR systems, or internal dashboards can use Private IP to ensure these apps are only accessible from within the corporate network—via VPN, ExpressRoute, or peered VNets. 🏥 Regulated Industries (Healthcare, Finance, Government) Workloads that handle sensitive data (e.g., patient records, financial transactions) often require strict network isolation. Private IP ensures traffic never touches the public internet, supporting compliance with HIPAA, PCI-DSS, or government data residency mandates. 🧪 Dev/Test Environments Development teams can deploy isolated environments for testing without exposing them externally. This reduces risk and avoids accidental data leaks during early-stage development. 🌐 Hybrid Network Architectures In hybrid setups where on-prem systems interact with Azure-hosted services, Private IP gateways can route traffic securely through ExpressRoute or VPN, maintaining internal-only access and enabling centralized inspection via NVAs. 🛡️ Zero Trust Architectures Private IP supports zero trust principles by enforcing least-privilege access, denying internet egress, and requiring explicit NSG rules for all traffic—ideal for organizations implementing segmented, policy-driven networks. Resources https://docs.microsoft.com/azure/application-gateway/ https://learn.microsoft.com/azure/application-gateway/configuration-overview https://learn.microsoft.com/azure/virtual-network/network-security-groups-overview https://learn.microsoft.com/azure/virtual-network/virtual-network-peering-overview Next Steps Evaluate Your Workloads: Identify apps and services that require internal-only access. Plan Migration: Map out your VNets, subnets, and NSGs for a smooth transition. Enable Private IP Feature: Register and deploy in your Azure subscription. Test Security: Validate that only intended traffic flows through your gateway. Final Thoughts Private IP for Azure Application Gateway is an improvement for secure, compliant, and efficient cloud networking. If you’re an ITPRO managing infrastructure, now’s the time check out this feature and level up your Azure architecture. Have questions or want to share your experience? Drop a comment below. Cheers! Pierre
New blog post | Microsoft bolsters cloud-native security in Defender for Cloud with new API security
Application Programming Interfaces (APIs) power modern applications, fuel digital experiences, and enable faster business growth. APIs are at the heart of communication between users, cloud services, and data – more and more so as organizations move from monolithic to microservice based application architectures. But the interesting challenge is that APIs are loved by developers and threat actors alike. Threat actors increasingly use APIs as their primary attack vector to breach data from cloud applications, which means API security is now a critical priority for CISOs. Microsoft bolsters cloud-native security in Defender for Cloud with new API security capabilities - Microsoft Community Hub
