A storage account and an Azure SQL database may contain the same customer’s information, yet they fail in different ways. Storage may be compromised through a broadly scoped shared key, public blob access or a leaked shared access signature (SAS). A SQL service can have strict network rules but still expose sensitive rows through excessive database privileges or a vulnerable application. SC-500 engineers must combine identity, networking, data protection and threat monitoring without treating one service’s security features as universal controls.
Imagine a fictional claims-processing service. Customers upload supporting evidence to Blob Storage, a back-end process reads it, and a SQL database stores verified claim state. Only the application and authorized reviewers should access the data. The security goal is not to make every request succeed; it is to make the allowed path work and document exactly why a forbidden or suspicious request is stopped or investigated.
Map the complete storage-to-database trust path
Draw four stages: authenticated user, application workload identity, object store and SQL database. Label which stage authenticates the user, which requests its own managed identity token, which private network endpoint is used and which role authorizes the actual data operation. An employee’s ability to view a claim in a web application should not automatically allow direct unrestricted access to the storage account or SQL server.
Keep production and development data separate where business risk justifies it. Azure Storage account keys are a broad trust boundary; sharing an account among unrelated customers or environments increases the blast radius of a key leak. SQL permissions should reflect application functions, such as reading a specific schema, not the blanket assumption that the application’s login can modify every database object.
Securing Azure Storage and Azure SQL requires following a specific caller through each service’s actual data plane. A service may have encryption enabled but still accept an overly broad storage credential, an incorrect SQL role or network traffic from an unintended path. Test a legitimate application identity that should read one dataset and an alternate principal that must be denied; record the token or credential type, effective permission, chosen network route, audit record and application result. Then simulate key exposure or a private-endpoint DNS mismatch without quietly granting administrator rights as a workaround. Data retention and recoverability are separate from read authorization, so verify that sensitive information remains protected during an emergency restore. In an independent SC-500 storage-and-database practice scenario, an answer that only notices encryption is enabled misses the defect. Identify the exposed principal, credential scope, SQL permission or network route, then propose the smallest corrective change and a denied-access test that proves it works.
Prefer Entra-based storage authorization to shared keys
Microsoft’s Azure Storage security recommendations advise using Microsoft Entra authentication and managed identities when the data service and client support them. A storage account key provides broad account-level control and is difficult to scope to one operation. A Storage Blob Data Reader role assigned at a suitable container or other supported scope is much closer to the intended least-privilege boundary.
Separate management-plane roles from data-plane roles. An administrator might manage account configuration but should not necessarily browse every customer’s object. Conversely, an application that reads a blob does not need permission to change firewall settings or rotate account keys. Build a negative test with a principal allowed to download an authorized blob and confirm that the same principal cannot delete the storage account or read another restricted container.
Some tools or legacy clients still depend on Shared Key. Inventory them before disabling it. The relevant property can reject requests authorized through Shared Key, but changing it without migration can break service SAS, account SAS and applications that signed requests with account keys. Treat this as a controlled release: observe actual authorization usage, migrate eligible clients, stage the setting and verify failures by service rather than assuming every SAS uses the same authorization model.
Select a SAS type by its signing identity and scope
A SAS token delegates an approved set of operations to a holder for a limited interval. Microsoft distinguishes user-delegation, service and account SAS in its explanation of shared access signatures. User-delegation SAS relies on an Entra-associated user delegation key for supported service/API operations; service and account SAS use storage-account keys. The target service, SDK/API version and whether Shared Key is disabled matter when designing a real client path.
Suppose a support employee needs to upload one fictional evidence file without receiving a general storage credential. A trusted service can authenticate the employee and issue a narrowly scoped short-lived SAS for that operation, where supported. Set only the required permission, expiry, resource and HTTPS restrictions. Do not log the full URL including its signature; possession of the token may be enough to use its delegated capability until it expires or is invalidated.
A signed SAS does not itself prove that the current HTTP caller is the employee originally approved. The service must enforce business identity and request purpose before issuing it. Plan revocation and incident response according to the SAS type; a key-signed SAS and a user-delegation SAS have different invalidation strategies. An overly broad account SAS is not acceptable merely because it is easy to generate in a portal.
Secure storage networking and exfiltration paths
Identity protection must be paired with an intentional network path. Use Storage firewall rules, selected networks or private endpoints when the workload needs isolation, and test the client route and DNS. A private endpoint gives a private IP connection to the supported service, but it does not replace storage authorization. The application still needs the right token or SAS, and a compromised overprivileged identity may still misuse that private route.
Test both positive and denied flows. The hosted back end should reach the intended storage endpoint, while an unapproved external client should not. Confirm that uploads do not accidentally fall back to a public endpoint after a private DNS change. When troubleshooting, inspect the storage authorization response and the network decision separately; treating a 403 as a pure network failure often leads teams to widen firewall rules unnecessarily.
Enable Defender for Storage threat protection according to subscription and plan support. Its detections can help investigate suspicious file activity or abuse, but it does not automatically enforce correct business authorization on every application object. Pair service telemetry with source-identity and object-version evidence instead of assuming an alert contains everything needed to reconstruct an incident.
Restrict Azure SQL identities and database privileges
For Azure SQL, build a deliberate authentication and privilege model. Prefer supported Microsoft Entra principals and narrow database roles over a shared SQL administrator login for routine application traffic. Distinguish the Azure SQL logical server configuration from permissions inside the database. A developer able to manage an Azure resource does not automatically require rights to select sensitive financial rows.
Consider a role permitted to read approved claim status but not to modify payment amounts or database security settings. Use appropriate database permissions and test as the application’s actual principal. Review how secrets and connection strings are handled; moving a database password into Key Vault is beneficial, but replacing a secret with managed identity can remove another long-lived credential entirely when supported.
Network-level protection should include supported firewall rules or private endpoints, TLS and required outbound dependencies. Enforcing private access without verifying name resolution, certificate validation and the application connection path can cause an outage that is misdiagnosed as a SQL authorization defect.
Implement auditing as evidence, not prevention
Azure SQL Database auditing can send selected database-event records to a storage account, a Log Analytics workspace or Event Hubs. Microsoft’s guidance on Azure SQL auditing describes these destinations and cautions that unusually high activity or network load can leave configured audit events unrecorded. Do not promise a flawless event ledger or substitute auditing for permission enforcement.
Choose audit action groups to match the threat model: failed authentication, successful administrative activity, changes to sensitive objects and other relevant operations. Balance investigative value against volume, retention and privacy. A compliance requirement should name the needed event, how long the record must remain, who can read it and what happens if the logging destination is unavailable.
Rehearse a denied login and an authorized change against synthetic records; verify the right audit records appear in their destination within the expected time. Also simulate failure of the chosen audit sink and document which logs can still be recovered. Sending audit data to a storage account under the same broad admin key as the production database’s integration secrets can undermine the purpose of preserving evidence.
Use Defender for SQL for vulnerability and threat context
Microsoft Defender for Azure SQL Databases provides supported vulnerability assessment and threat-detection capabilities through Defender for Cloud. It may identify risky configuration and anomalous behavior, including patterns consistent with SQL injection or attempted abuse. An alert is a lead for investigation, not automatically proof that a particular actor exfiltrated records. Correlate the finding with actual SQL permissions, audit evidence and application events.
A vulnerable or unreviewed application query should be fixed at the application boundary as well. Parameterized queries, input validation and restricted data roles protect against consequences that monitoring alone cannot stop. A Defender recommendation about weak database configuration requires a concrete owner and a verified change; dismissing it because one query works does not remove the weakness.
Azure Storage authentication methods clarify the difference between Microsoft Entra data roles, account keys and scoped SAS credentials. That foundation matters when reviewing a workload that touches Azure Storage and SQL: a restricted blob reader may still have an overly privileged database identity, or a correct SQL permission may be undermined by publicly reachable storage. Trace the authenticated principal, requested operation, credential lifetime and data path through both services. If a secret is exposed, determine its actual scope and usage before choosing rotation or network remediation; a superficially successful key change does not prove unauthorized access ended.
Run a data-protection release matrix
Build an isolated synthetic dataset with two customer containers, one SQL database and three principals: approved application, separate reviewer and unauthorized external account. Test permitted blob access, denied cross-customer access, SAS expiry, Shared Key denial where configured, and failure of the private DNS path. For SQL, test the application role’s permitted query, a blocked privileged operation, failed authentication and an audit record for the meaningful events.
Add a controlled incident where a SAS URL is accidentally included in a diagnostic log; revoke or expire it according to the supported mechanism and verify no lasting access remains. Add a SQL audit-destination interruption; document the remaining visibility instead of fabricating full coverage. Finally, check whether Defender alerts and data-plane logs can be tied to the actual request and principal.
A protected claims system proves both sides of security: authorized customers can complete their permitted work, and unauthorized identities or leaked credentials are contained. Storage RBAC, SAS design, network isolation, SQL permissions, auditing and Defender detections each address a different failure. SC-500 readiness comes from implementing and verifying those layers without making broad exceptions when an integration becomes inconvenient.