12.4 Security Controls for Asset Management: Locks, Tags, Resource Graph & Azure Arc

Why Asset Management Is a Security Objective

The Microsoft Cloud Security Benchmark devotes an entire control family to asset management for a simple reason: unknown assets are unmonitored, unpatched, and unowned. Most cloud incidents involve a resource that nobody claimed — a forgotten test VM with a public IP, a storage account left behind by a decommissioned project, a subscription created on a personal credit card. The controls below make assets discoverable, attributable, and hard to delete by accident.

---

Resource Locks

Locks are the bluntest control in Azure and the one candidates most often misjudge.

Properties that get tested:

• Locks apply to every principal, including subscription Owner. RBAC cannot override a lock — you must first have permission to remove the lock (Microsoft.Authorization/locks/*, held by Owner and User Access Administrator).
• Locks are inherited: a lock on a resource group protects every resource inside it, and one on a subscription protects everything beneath.
• ReadOnly is more dangerous than it sounds. Because Azure classifies some read-like calls as POST control-plane operations, a ReadOnly lock blocks things such as listing storage account keys and can put services into a failed state. Test it before applying it broadly; CanNotDelete is the safer default.
• Locks protect against the control plane, not the data plane. A CanNotDelete lock on a storage account does not stop anyone from deleting the blobs inside it.

For fleet-wide, policy-driven protection use the DenyAction policy effect with DELETE as the blocked action. Unlike a lock, it applies automatically to every current and future resource in scope without anyone remembering to create it.

---

Tagging as a Security Control

Tags turn an inventory row into an accountable asset. A minimum security-relevant tag set:

Enforce them, do not request them:

• Deny policy effect to block creation of untagged resources.
• Modify effect with a remediation task to add or inherit tags on existing resources — commonly inheriting from the resource group.
• Tags feed dynamic network groups in Virtual Network Manager, Defender for Cloud filtering, and Sentinel enrichment, so tag hygiene has direct detection value.

Remember that tags are not a security boundary: they are visible to anyone with Reader and can be changed by anyone with write access. Never put secrets or precise sensitivity details in tag values.

---

Inventory at Scale with Azure Resource Graph

Azure Resource Graph queries every resource across every subscription in the tenant using KQL, returning results in seconds where a subscription-by-subscription enumeration would take hours.

Resources
| where type =~ 'microsoft.storage/storageaccounts'
| where properties.allowBlobPublicAccess == true
| project name, resourceGroup, subscriptionId, location, tags

Practical security queries: public IP addresses in use, virtual machines without a specific extension, resources missing an owner tag, storage accounts permitting shared key access, and NSGs with an any-any inbound rule. Resource Graph is also the engine behind Defender for Cloud's Inventory view and behind Virtual Network Manager's dynamic group membership, so the same query language pays off in several places.

---

Structure: Management Groups and Subscriptions

• Build a management group hierarchy that mirrors accountability (for example, root → platform / landing zones → prod / non-prod), and assign security baselines at the highest appropriate level so new subscriptions inherit them on creation.
• Keep production in separate subscriptions from development so blast radius, policy, and RBAC differ by design rather than by convention.
• Watch for rogue subscriptions: an Entra ID user can create a subscription in the tenant. Restrict this in the tenant's subscription policy settings, and monitor for subscriptions appearing outside your hierarchy — they inherit no baseline until moved.

---

Extending Governance with Azure Arc

Azure Arc projects non-Azure assets into Azure Resource Manager as first-class resources:

For AZ-500 the key link is that Defender for Servers coverage of non-Azure machines depends on Arc onboarding (or on the multicloud connector performing that onboarding for you). A scenario that says "on-premises servers must appear in Defender for Cloud with the same recommendations as Azure VMs" is answered by Azure Arc, not by installing an agent alone.

Arc also brings those machines into the same asset inventory, so the tagging, Resource Graph queries, and policy assignments above cover the hybrid estate rather than stopping at the Azure boundary.