Security engineering turns a workload requirement into a control that can be tested, monitored, and safely removed. In Azure, that work spans the Microsoft Entra tenant, Azure Resource Manager within a subscription, and each service’s data plane, so an apparently correct setting may still protect the wrong scope.
We will use one bounded development workload in the fictional resource group rg-orders-dev. Its purpose is to expose the decisions, evidence, and boundaries that a cloud security engineer must establish before treating a configuration as protection.
Begin with a requirement tied to an asset and threat. For example, an order-processing API must retrieve a secret without exposing the secret over the public internet. A control is the configured mechanism intended to satisfy that requirement, while evidence is an observable record that supports a limited claim about its configuration or activity.
Our workflow is consistent. We identify the asset, data boundary, identity, and threat; choose the smallest appropriate control; define the expected failure if access is denied or traffic takes an unintended route; then verify the intended result with configuration and runtime evidence. Cleanup removes temporary permissions, test secrets, or diagnostic settings when they are no longer needed, preventing testing artifacts from becoming standing exposure.
Configuration evidence and runtime evidence answer different questions. A role assignment or private endpoint configuration demonstrates intended control-plane state. A Key Vault audit event, storage diagnostic log, or application failure demonstrates an observed data-plane attempt within its recorded time window. Neither alone establishes that every path is secure or that an incident has no other cause.
Recommendations identify posture gaps, but enforcement must come from a deny policy or the control itself.
Microsoft secures the underlying Azure physical infrastructure, while the customer remains responsible for workload data, application behavior, identities, and access choices. This shared-responsibility boundary does not mean that a platform-managed service needs no customer security work. It means we must identify which party owns each layer before selecting evidence or remediation.
The Microsoft Entra directory authenticates users, applications, and managed identities. Azure Resource Manager, often called ARM, is Azure’s control plane for creating and configuring resources in a subscription or resource group. Azure RBAC role assignments at these scopes authorize control-plane actions such as changing a storage account’s networking configuration.
A service data plane is the service-specific interface that reads, writes, or uses protected data. Key Vault secret retrieval and Blob data access occur on their respective data planes, where their data-plane authorization and network controls apply independently of ARM authorization. A Contributor who can configure a vault is not thereby authorized to read its secrets.
The reusable rule is to name the principal, action, scope, and plane before judging whether access should succeed.
Our fictional workload is app-orders-api, an Azure App Service app in rg-orders-dev, within a fictional subscription <subscription-id>. It runs in a chosen Azure region and uses vnet-orders-dev for outbound virtual network integration. The application needs order data in stordersdev and a secret in kv-orders-dev, while law-sec-01 is the Log Analytics workspace used by Microsoft Sentinel.
The virtual network is the application’s network boundary, not the location of every Azure service resource. stordersdev and kv-orders-dev remain Azure platform services outside vnet-orders-dev; private endpoints place private network interfaces for those services in the virtual network. Private DNS and the service’s network settings must direct the API’s outbound request to those endpoint addresses rather than a public endpoint.
The app’s managed identity will later need separate data-plane permissions for its intended Key Vault and Storage actions. Sentinel runs on law-sec-01, where connectors and diagnostic settings determine which records arrive for analysis. A workspace can support investigation only for data that was actually collected into it.
Trace the workload boundary from the API to its private endpoints and monitoring workspace.