Classify the data and distinguish Azure SQL deployment models

Before selecting a firewall rule or encryption option, identify the data owner, application workload, users, administrative team, external integrations, regional constraints and recovery requirements. Azure SQL Database, Azure SQL Managed Instance and SQL Server on virtual machines differ in networking, operations, patching and shared responsibility. A database holding public reference data may tolerate a different access pattern from a production payment ledger; security should be derived from consequences and service boundaries rather than a generic checklist.

Start with the operations that must be possible: an application reading selected customer records, a reporting process creating aggregates, a database operator tuning performance, and a security analyst examining audit events. Separate each identity and enumerate required permissions. In particular, the ability to manage an Azure SQL logical server or instance through Azure resource management is not identical to permission to query database tables. Application access is governed inside the data service by the database's authorization model.

A trustworthy threat model follows the full path from the caller and API to network routing, token or credential, SQL authorization, sensitive table and audit sink. Record what would happen if the application's managed identity or deployment pipeline were compromised. The Azure cloud security architecture article can help frame the resource and ownership boundaries around this path.

Prefer Entra identity and remove avoidable SQL passwords

For supported clients and services, use Microsoft Entra authentication and narrowly scoped database permissions rather than long-lived shared SQL credentials. A managed identity can acquire a token for the target database, removing a static application password from configuration and CI/CD logs. But the principal still needs an explicit database user and appropriate roles. A managed identity with broad database rights is not least privilege simply because it never stores a password.

Microsoft's Entra-only authentication guidance documents how to enable and test Entra-only authentication in supported Azure SQL Database and Managed Instance configurations. Migration should begin with an inventory of service integrations, drivers, external tools and emergency maintenance workflows that use SQL login authentication. Removing SQL authentication prematurely can interrupt backups or operational processes that were never designed for Entra tokens.

Test the application's real effective permission, not just successful login. A reporting principal should be able to execute its approved stored procedure or read a curated view while failing to update customer tables, create high-privilege users or change auditing settings. Use separate deployment and runtime identities when the application needs schema migrations. The managed identities and least privilege pattern makes the separation easier to operate and review.

Decide the network exposure model independently of login authorization

A database can be strongly authenticated yet unnecessarily exposed to the internet. Decide whether applications must reach Azure SQL through private endpoints, selected public addresses, managed VNet integrations, or supported hybrid connectivity. Design the path for each application and administrator location before making public access changes. A private endpoint is useful when reachability should be constrained, but it does not automatically repair overly permissive database grants or unsafe application queries.

Private access demands DNS and service-specific configuration. Test hostname resolution, the expected private address, effective routes, port access and SQL login from a workload inside the intended network. Repeat the test from a disallowed source to confirm it cannot reach the database. Include administrative tools and disaster-recovery clients; an architecture that works only from one application subnet may fail during an outage when the approved response team needs access through a different path.

Document permitted exceptions such as approved external data-integration services and time-bounded migration clients. Broad public firewall rules that appear during a project often survive long after the need ends. Use changes in Azure Policy, network rules and related configuration as security signals. The Private Link security patterns guide explains why end-to-end negative tests are necessary to prove isolation.

Apply TDE, Always Encrypted and key ownership to distinct risks

Transparent data encryption protects data at rest in supported Azure SQL services, but it does not stop an authorized or stolen application identity from querying decrypted rows. Microsoft's SQL security best-practice playbook distinguishes TDE from Always Encrypted and the operational consequences of cryptographic choices. Always Encrypted can protect sensitive column values from database administrators in supported scenarios, at the cost of driver, query and key-management complexity.

Select encryption based on the threat being addressed. If the risk is loss of storage media or database files, at-rest encryption is relevant. If the organization needs a separation between database operators and highly sensitive plaintext, client-side column encryption may be appropriate for selected fields. If the primary risk is an overprivileged application identity, encryption at rest does not replace strict SQL permissions, input validation and authorization checks at the application boundary.

Customer-managed keys and Always Encrypted column-master-key storage introduce dependencies on Key Vault authorization, access review and recovery. Document key rotation, service identity, disaster-recovery region and application impact before switching a production encryption mode. Test a restore where the new environment must retrieve the correct key; a retained encrypted backup is not usable if its key was deleted or the recovery identity cannot access it. The Key Vault access-design article covers the independent management and data-plane roles around those dependencies.

Use SQL authorization, masking and row-level controls deliberately

A database role should represent a concrete business operation. Avoid using db_owner for ordinary application data access or convenience during debugging. Grant permissions to specific schemas, views, procedures or roles where this gives a maintainable least-privilege boundary. Enforce who may call a business operation in the application as well as in the database; protecting one database view will not save an API that already authorizes every tenant to request another tenant's data.

Row-level security can implement supported database-side tenant or business filtering, but its predicates and execution context must be reviewed carefully. Dynamic data masking can change what a user sees in a result but should not be marketed as a substitute for true authorization or encryption. Sensitive data discovery and classification can support governance decisions, but a label by itself does not stop an overprivileged principal from reading the table. Controls should be selected for their actual enforcement semantics.

Run negative tests with a second low-privilege identity, not only with the database owner. Attempt a cross-tenant read, a schema change, and a direct table query outside the application-approved path. Document expected denials and review whether an administrator can bypass the chosen control by changing roles or executing privileged commands. Track administrative and data-access rights separately so a developer with application deployment access does not implicitly inherit production records access.

Engineer auditing for investigations, not only compliance checkboxes

Azure SQL auditing should capture the security events the response team can actually use: privileged role and permission changes, authentication anomalies, significant data access, schema modifications and suspicious queries where supported. Choose destination, retention and access controls deliberately. Diagnostic events written to a storage account or Log Analytics workspace are themselves sensitive data; an attacker who can erase or edit audit evidence may make a breach difficult to investigate.

Design a simple evidence question: after a service account is compromised, which principal connected, from where, what statement or operation was attempted, what was the result and what data might have been affected? Configure auditing and supporting application telemetry to answer the question without indiscriminately logging every value or exposing secrets in diagnostic text. UTC timestamps, correlation identifiers and business context help connect SQL activity with Entra, API gateway and incident events.

Test detection with a safe operation in a controlled environment, then confirm that the event lands in the intended destination and can be queried by the responsible analyst. Record ingestion delay and gaps. A setting may be enabled while logging is incomplete because of permissions, destination failure, filtering or unsupported action types. Audit evidence should support incident handling and periodic privilege review rather than become a dashboard no one owns.

Configure Defender for Databases and interpret findings in context

The Defender for Azure SQL Databases plan helps identify potential vulnerabilities and alerts on anomalous activities in supported Azure SQL services. It is not a replacement for Entra authentication, firewall policy, SQL authorization or backups. Review what resource types are protected, how the plan is enabled, where alerts go and what investigative context appears in an actual finding. An operator should know whether a subscription plan covers the specific database or instance in question.

Vulnerability findings should be evaluated against actual application behavior and business consequence. One permissive database account accessible only from an isolated laboratory may be lower priority than a narrower but public-facing path to sensitive production records. Combine database vulnerabilities with the cloud security graph, identity roles, network exposure and owner information where available. The Defender attack-path model is useful for prioritizing the relationships that create material risk.

Validate alerting with supported safe test procedures rather than running potentially destructive statements against production data. Record what the alert proves and what it cannot prove. Defender may recognize suspicious behavior without capturing every application-level authorization failure; the API and SQL audit system must still provide enough context to establish who accessed what and whether a business transaction was authorized.

Protect backups, failover and remediation from the same compromise

Availability and confidentiality intersect during ransomware or malicious database administration. Decide who can restore, delete or export backups and how credentials and keys are protected. Verify the database service's supported point-in-time restore and long-term-retention capabilities against the business recovery objective rather than assuming all Azure SQL offerings and tiers behave identically. A failover group or geo-replica improves some availability scenarios but is not equivalent to an immutable recovery copy protected from a powerful compromised identity.

Perform a recovery exercise using a nonproduction target: restore a suitable point, re-establish network access, validate Entra principals and database users, recover encryption dependencies and confirm the application can perform its approved work. The test should include denial of access to an identity that should not have been brought forward. Account for schema and data migration drift when recovery crosses environments, and keep audit evidence available for post-incident investigation.

Close by translating repeated findings into templates and ownership. If public access rules, overly broad SQL roles or missing audit settings reappear with each deployment, fix the deployment pattern and Azure Policy baseline. A secure Azure SQL design is one where identity, query authorization, network exposure, encryption, detection and tested recovery each have evidence—and no one incorrectly assumes that one enabled control protects the entire database lifecycle.