Secure storage, databases, and networking
Storage Account Security
CoreProtect storage accounts with secure defaults, network restrictions, data authorization, controlled delegation, and Defender threat protection.
Aligned to the live SC-500 guide, which publishes no skills-measured date; guide and product behavior verified September 23, 2026.
Why this matters
Storage is both a data plane and a common attack target. Encryption, network reachability, Microsoft Entra authorization, shared access signatures, access policies, logging, and threat detection solve different risks.
Must Know
- Require secure transfer, choose appropriate minimum TLS, disable unnecessary anonymous blob access, and prefer Microsoft Entra authorization over shared keys where supported.
- Storage firewall rules restrict the public endpoint by networks or resource instances; a private endpoint provides a private address and still requires correct DNS and authorization.
- Defender for Storage supplies threat detection and optional capabilities such as malware scanning or sensitive-data threat detection according to the configured plan.
- Azure RBAC data roles authorize blob, queue, table, or file operations; management roles alone do not necessarily grant data access.
- A service SAS scopes access to one service, an account SAS can span services, and a user delegation SAS is secured with Microsoft Entra credentials for Blob storage.
- A stored access policy can govern service SAS start, expiry, and permissions and provides a revocation point; ad hoc SAS tokens must be managed individually.
Compare and Distinguish
- Firewall and private endpoint determine reachability; RBAC, keys, and SAS determine data authorization.
- User delegation SAS avoids signing with the account key; an account SAS remains tied to the storage account key.
- Defender for Storage detects suspicious activity; encryption and immutability prevent or constrain different classes of data risk.
Scenario examples
- Scenario: A partner needs read access to one container for six hours without an account key. Think: use a narrowly scoped, time-limited delegation mechanism.
- Scenario: An app reaches a private storage address but receives authorization failure. Think: fix its data-plane role rather than reopening the public endpoint.
- Scenario: Uploaded files must be scanned for malware. Think: enable the relevant Defender for Storage capability and plan for scan results and cost.
Exam traps
- Allowing a subnet through the firewall does not grant any blob permissions.
- Reader can view resource metadata but is not Storage Blob Data Reader.
- Rotating an account key invalidates dependencies that still use that key, including SAS tokens signed by it.
- A private endpoint for Blob does not automatically provide private endpoints for File, Queue, or Table.
Key takeaways
- Prefer identity-based, least-privileged data access and short-lived delegation.
- Design network paths per storage subresource and validate private DNS.
- Use Defender for Storage as detection, not as a substitute for preventive controls.
How it works
- A storage request reaches a service endpoint and is checked against network policy plus its authorization proof.
- Platform logs and Defender analytics observe accepted or attempted activity and produce separate evidence.
Objects and administrative surfaces
- Storage account configuration for transport, public access, shared-key authorization, encryption, networking, and diagnostics.
- Containers, access policies, IAM data roles, SAS generation, keys, and private endpoint connections.
- Defender for Cloud environment settings and Defender for Storage alerts or plan components.
When to use it
- Use private endpoints for private PaaS access and firewall rules when controlled public endpoints remain appropriate.
- Use short-lived user delegation SAS for constrained Blob delegation when direct RBAC cannot fit the client flow.
Security and governance implications
- Inventory anonymous containers, shared-key use, long-lived SAS tokens, broad data roles, and public network exposure.
- Protect diagnostic settings and Defender plan configuration from unreviewed changes.
Troubleshooting signals
- Resolve the service FQDN from the client, confirm the route and endpoint approval, then inspect the presented identity or signature.
- For blocked data access, inspect storage firewall decision, RBAC propagation, token audience, and SAS validity independently.
More detail
- Configure secure transfer, public access, keys, encryption, and diagnostic settings.
- Apply firewall, service endpoint, resource-instance, or private endpoint rules to the intended path.
- Select Azure RBAC, user delegation SAS, service SAS, or stored access policy from the requirement.
- Enable and tune Defender for Storage components deliberately.
Ready for the quiz?
- Which role lets a workload read blob data but not manage the account?
- When does a stored access policy improve SAS revocation?
- Why might Blob work through Private Link while Azure Files does not?
Related objectives
- D2.1.S1 — Implement and configure security for storage accounts
- D2.1.S2 — Configure Azure Storage firewall rules
- D2.1.S3 — Implement Defender for Storage threat protection configurations
- D2.1.S4 — Manage access to storage, including access policies