4 of the 13 questions we have for this objective, shown with the answer and the reasoning.
Implement security for storage accounts
Coho Winery runs a web app named app-coho-portal with a system-assigned managed identity. The app must hand browsers short-lived, read-only links to individual blobs in the container named labels in the storage account stcoholabels. Shared Key authorization is disabled on the account, and the security team will not allow any account key or connection string to be stored in the app.
What should you do?
- AAssign the Storage Blob Delegator and Storage Blob Data Reader roles to the app identity and generate user delegation SAS tokens.A user delegation SAS is signed with a Microsoft Entra user delegation key rather than an account key. Storage Blob Delegator allows the identity to request that key, and the data role bounds what the SAS can grant.
- BStore one account key in Azure Key Vault, grant the app identity access to the secret, and generate service SAS tokens.A service SAS is signed with the account key, and Shared Key authorization is disabled, so the tokens would be rejected. It also violates the ban on storing keys.
- CCreate a stored access policy on the labels container and generate service SAS tokens that reference it.Stored access policies apply only to service SAS, which still requires signing with an account key that the app is not allowed to hold and that the account no longer honors.
- DGenerate an account SAS with read permission on the Blob service and embed it in the app configuration.An account SAS is signed with an account key, so it fails when Shared Key is disabled, and a long-lived token in configuration is a stored secret.
Why: When Shared Key authorization is disabled, the only SAS type a storage account accepts is the user delegation SAS, because it is signed with a key obtained through Microsoft Entra ID rather than the account keys. To create one, the calling identity needs permission to request a user delegation key, granted by Storage Blob Delegator, plus a data role whose permissions bound the SAS. The deciding constraints are no stored keys and Shared Key disabled, which eliminate every key-signed token type. The trap is stored access policies, which sound like a security improvement but exist only for service SAS and therefore depend on the account keys.
Implement security for storage accounts
Woodgrove Bank restricted the storage account stwoodgrovelogs to selected virtual networks and IP addresses. Since the change, Azure Monitor diagnostic settings that archive activity logs to the account fail, and Azure Event Grid system topics that publish blob-created events for the account stop delivering. The security team refuses to add any public IP ranges to the firewall and must keep public network access limited.
What should you do?
- AAdd the published Azure datacenter IP ranges for the region to the IP network rules.Datacenter ranges are broad, change over time, and violate the stated refusal to add public IP ranges. This is the pattern the trusted-services exception is designed to replace.
- BEnable the exception Allow Azure services on the trusted services list to access this storage account.Azure Monitor and Azure Event Grid are on the trusted Microsoft services list. The exception lets those platform services reach the account while the firewall continues to block everything else.
- CSet Public network access to Enabled from all networks.This removes the firewall entirely, which contradicts the requirement to keep public network access limited.
- DAdd a virtual network rule for the subnet that hosts the Log Analytics workspace.Log Analytics workspaces and Event Grid are multitenant platform services that do not live in a customer subnet, so there is no subnet to add.
Why: When the storage firewall is enabled, Microsoft platform services that need to write to or read from the account are blocked along with everyone else unless an exception applies. The trusted-services exception grants access to a fixed list of Microsoft services, including Azure Monitor diagnostic settings, Azure Event Grid, Azure Backup, and Azure Site Recovery, without opening any IP ranges. The deciding constraints are that no public IP ranges may be added and public network access must remain restricted, which eliminates datacenter ranges and all-networks access. The trap is trying to model platform services as if they had subnets or stable IP addresses; they do not, which is why the exception exists.
Implement security for storage accounts
Alpine Ski Bank keeps exported customer statements, which contain payment card numbers, in a storage account named stalpinestatements. Microsoft Defender for Storage is enabled on the subscription. The CISO wants a security alert whenever a container or blob that actually contains payment card data is exposed, for example by anonymous access being enabled or by a suspicious download, rather than alerts for every container in the account.
What should you enable?
- ASensitive data threat detection in the Defender for Storage plan.Sensitive data threat detection discovers blobs that match sensitive information types, such as credit card numbers, and raises prioritized alerts when those specific resources are exposed or accessed suspiciously.
- BSensitive data discovery in Defender Cloud Security Posture Management (Defender CSPM).Defender CSPM data-aware posture surfaces recommendations and attack paths about where sensitive data lives. It is a posture feature and does not raise real-time threat alerts on exposure events.
- CAn Azure Monitor alert rule on the StorageBlobLogs table that fires when anonymous requests are logged.A log alert can detect anonymous requests, but it has no knowledge of which blobs contain card numbers, so it would fire for any container in the account.
- DBlob versioning on stalpinestatements.Versioning preserves previous blob states for recovery. It does not classify data or detect exposure.
Why: Sensitive data threat detection is an optional capability of Microsoft Defender for Storage that samples blobs, classifies them with the Microsoft Purview sensitive information types, and then enriches alerts so that exposure or exfiltration events involving sensitive data are prioritized over events involving non-sensitive data. The deciding constraint is that the alert must be tied to the presence of payment card data in the affected resource, which neither a generic log alert nor a posture recommendation provides. The trap is confusing Defender CSPM's data security posture, which is about recommendations and attack paths, with Defender for Storage's threat detection, which is about alerts.
Implement security for storage accounts
Proseware distributes monthly reports to 200 external partners from the container named reports in the storage account stprosewarereports. Partners cannot use Microsoft Entra credentials, so each receives a shared access signature valid for 12 months. Several internal applications still authorize with the account keys. The security team requires the ability to invalidate every partner token for the reports container immediately if one is leaked, without affecting internal applications.
How should you issue the partner tokens?
- AIssue ad hoc service SAS tokens with a 12-month expiry.An ad hoc SAS carries its own start, expiry, and permissions and can be revoked only by rotating the account key that signed it, which would break the internal applications.
- BCreate a stored access policy on the reports container and issue service SAS tokens that reference the policy.A service SAS associated with a stored access policy inherits its expiry and permissions from the policy. Deleting or editing the policy invalidates every token that references it, without touching account keys.
- CIssue account SAS tokens scoped to the Blob service with a 12-month expiry.Account SAS tokens cannot reference stored access policies and can be revoked only by rotating the signing key, which affects the internal applications.
- DIssue user delegation SAS tokens signed with a Microsoft Entra identity.User delegation SAS is revoked by revoking the account's user delegation keys, which invalidates every user delegation SAS across the whole account, not just the reports container, and still requires a Microsoft Entra identity to create each token.
Why: A shared access signature can be revoked only through the credential that signed it. For an ad hoc service SAS or an account SAS that means rotating the account key, and for a user delegation SAS it means revoking the account-wide user delegation keys. Stored access policies, which exist only for service SAS on containers, file shares, queues, and tables, add a revocation point at the resource level: remove the policy and every dependent token dies. The deciding constraints are container-scoped revocation and no impact on key-based internal applications. The trap is choosing user delegation SAS because it is Microsoft Entra based; it is the better default, but its revocation granularity is the account, and the partners here cannot authenticate with Microsoft Entra anyway.