Protect Azure Data Stores, Databases, Keys, Secrets, and Certificates

Harden Azure Storage, SQL, Cosmos DB, Key Vault, encryption, identities, private access, secret rotation, logging, soft delete, and purge protection.

Assess Azure Data Protection Review Azure Security Audit Services

Protect the data plane

Secure Azure data, identities, keys, secrets, and network paths as one system

Azure Storage and Key Vault security depends on more than encryption at rest. A storage account or database can be encrypted yet still exposed through a public endpoint, a shared key, an excessive role, a leaked connection string, an overprivileged managed identity, or an unmonitored export. Key Vault can protect secrets and cryptographic material, but weak RBAC, public access, poor rotation, or missing deletion safeguards can turn it into a concentration point for privilege.

This guide covers Azure Storage, Azure SQL, Cosmos DB, other data services by extension, Key Vault, managed identities, authorization, private access, secure transport, encryption, shared keys, SAS, secret lifecycle, soft delete, purge protection, logging, backup, and evidence.

Classify before configuring. Identify the business purpose, data owner, sensitivity, legal or contractual duty, residency, retention, recovery objective, and permitted consumers. The right control depends on what the service stores and how applications use it.

Data access path

Require identity, private reachability, least privilege, and observable use

Workload identityManaged identity or approved application identity

→

AuthorizationNarrow Azure RBAC and service data role

→

Private pathPrivate endpoint · DNS · restricted public network

→

Data serviceEncryption · secure configuration · recovery controls

→

EvidenceResource logs · data audit · alerts · access review

Prefer identity-based authorization and short-lived tokens over embedded shared credentials. A managed identity removes credential storage, but its permissions and host workload still require protection.

Azure Storage

Control public access, shared authorization, transport, and data operations

Review each storage service used by the account—blob, file, queue, table, hierarchical namespace, static website, SFTP, NFS, or other enabled capability—because exposure and authorization differ.

Control	What to check	Risk signal	Validation
Public network access	Enabled from all networks, selected networks, network security perimeter, private endpoint, service endpoint	Public endpoint accepts traffic without a documented requirement	Resolve and connect from authorized and unauthorized networks
Blob public access	Account-level allow setting and container access level	Anonymous read or listing on sensitive or unknown data	Attempt unauthenticated access to representative objects
Entra authorization	Storage Blob, Queue, Table, or File data roles; managed identities; user delegation SAS	Users or apps rely on account keys for ordinary access	Test token-based access and confirm least-privilege scope
Shared Key	AllowSharedKeyAccess, key custody, rotation, use, logging, dependencies	Long-lived key in code, scripts, tickets, or broad admin access	Identify callers, migrate, disable safely, and monitor failures
SAS	Type, permissions, services, resources, protocol, start, expiry, IP, revocation plan	Account SAS or long expiry with broad permission	Generate controlled user delegation SAS and test expiration/revocation
Secure transfer	HTTPS-only, minimum TLS, SMB security, SFTP and NFS requirements	Legacy protocol or transport remains allowed	Test approved clients and reject older protocols
Encryption	Microsoft-managed or customer-managed keys, infrastructure encryption need, key identity, rotation	CMK design lacks Key Vault protection or recovery	Confirm key access, rotation, failure behavior, and recovery
Data protection	Blob soft delete, container soft delete, versioning, point-in-time restore, immutability, change feed	Deletion or overwrite cannot be recovered within business objectives	Perform an authorized recovery test
Logging and threat protection	Resource logs, metrics, Defender for Storage, alerts, diagnostic settings	Data access or exfiltration cannot be investigated	Generate a benign test event and trace the telemetry
Lifecycle and replication	Retention, lifecycle policies, redundancy, cross-region design, object lock, legal holds	Policy deletes data prematurely or replication fails the recovery need	Review policy simulation and representative restore

Storage administrator procedure

Move applications away from broad shared credentials

Identify every consumer. Use application documentation, code and secret scans, Key Vault references, logs, metrics, network flows, and owner interviews to locate account-key and SAS use. Include backup products, data transfer tools, automation, vendors, and legacy applications.
Assign a managed identity. Use a system-assigned or user-assigned managed identity according to lifecycle and reuse requirements. Protect the workload that can obtain the token.
Grant a narrow data role. Choose the service-specific data role and smallest scope that supports the required operation. Avoid granting Owner or Contributor because the application needs to read blobs.
Update and test the application. Use the Azure Identity library or supported authentication method. Test normal work, failure, token renewal, regional recovery, and logging.
Rotate shared keys. Rotate any key that may have been exposed and update remaining dependencies. Monitor for failed Shared Key requests.
Disable Shared Key where supported. After dependencies are removed and Conditional Access needs are understood, disable shared authorization. Preserve rollback and verify no critical workflow broke.

SAS review

Prefer user delegation SAS when supported
Use HTTPS only
Grant only required service, resource, and permission
Use a short expiration tied to the business transaction
Avoid setting an early start time unless needed for clock skew
Restrict source IP when the workflow permits it
Maintain revocation through user delegation key, stored access policy where supported, or key rotation
Never place a SAS in public source code, a permanent document, or an unrestricted log

Azure SQL

Protect authentication, network access, encryption, auditing, and database privilege

Identity and authorization

Configure a Microsoft Entra administrator and use Entra authentication for users, groups, managed identities, and applications where supported. Evaluate Entra-only authentication, contained users, database roles, ownership, service principals, managed identities, and privileged SQL accounts. Remove dormant users and avoid shared SQL credentials.

Network and transport

Use private endpoints or tightly restricted firewall rules according to the architecture. Review “Allow Azure services” behavior, public network access, virtual network rules, DNS, proxy endpoints, minimum TLS, connection encryption, failover groups, and administrative tools. Test the path from each authorized application.

Data protection and detection

Confirm Transparent Data Encryption, customer-managed key requirements, backup retention, geo-replication, auditing, Defender for SQL, vulnerability assessment, data classification, Dynamic Data Masking or Always Encrypted where justified, and alert routing. Encryption does not replace restrictive query and role permissions.

Database audit evidence must be usable. Decide which events matter, where logs are written, how long they are retained, who can access or delete them, how alerts are investigated, and how high-volume data is controlled.

Azure Cosmos DB

Restrict local keys and public exposure where identity-based access can replace them

NetworkPrivate endpoints · public network disabled or restricted · network security perimeter · DNS validation

IdentityManaged identities · Entra data-plane RBAC · control-plane RBAC · key-based access decision

EncryptionService-managed or customer-managed keys · Key Vault protection · rotation · recovery

MonitoringControl-plane logs · data-plane diagnostics · Defender for databases · anomalous access alerts

ResilienceRegions · consistency · backup mode · point-in-time recovery · failover tests

Cosmos DB local keys can grant broad access. Where application support allows, use managed identities and Entra-native data-plane RBAC, then disable local authentication after a controlled migration. Review custom role definitions, scopes, stored procedures, change feed consumers, cross-region paths, and every application that caches credentials.

Azure Key Vault

Separate secret use, secret administration, and vault administration

Control	What to check	Frequent weakness	Evidence and test
Permission model	Azure RBAC or legacy access policies, role scope, separation, custom roles	Contributor can grant themselves data access or broad administrator role is permanent	Role export, privilege path analysis, effective access test
Network access	Public network, firewall, trusted services, private endpoints, DNS	Public endpoint open to all networks or trusted-services option misunderstood	Connect from authorized and unauthorized sources
Soft delete	Enabled state, retention, recovery procedure	Team assumes deleted objects can always be recovered	Property export and controlled recovery test
Purge protection	Enabled state, retention implications, policy enforcement	Compromised administrator can permanently purge deleted material	Property export, policy compliance, attempted prohibited purge in lab
Rotation and expiration	Key rotation policy, secret and certificate expiration, notifications, owner	Non-expiring secrets and certificates with unknown consumers	Inventory, Event Grid or monitoring, rotation record, application test
Managed identities	Application identity, Key Vault role, secret scope, host exposure	Runtime identity reads all secrets in a shared vault	Role assignments, access logs, negative access test
Logging	Diagnostic settings, resource logs, retention, alerts, workspace protection	Secret access cannot be attributed or retained	Generate a test read and confirm query and alert
Key assurance	Software or HSM protection, BYOK requirements, rotation, backup, key release	Complex customer-managed key design lacks recovery and separation	Architecture, key properties, rotation and failure exercise

Secret lifecycle checklist

Assign a business and technical owner
Record the consuming application and environment
Prefer identity or federation over a secret when supported
Use a unique secret per consumer
Set expiration and an automated renewal path
Distribute only through an approved secure mechanism
Prevent secret values from entering code, logs, tickets, chat, and build output
Monitor access and lifecycle events
Rotate immediately after suspected exposure
Revoke and delete safely when the dependency ends

Rotation engineering

Rotate without causing an outage

Rotation needs application support. Use dual credentials or overlapping validity when the service permits it. Generate the new credential, place it in the approved store, update or signal consumers, confirm new use, monitor failures, revoke the old credential, and record evidence. Applications should cache secrets only as long as necessary, handle Key Vault throttling with backoff, and refresh after rotation.

For customer-managed keys, understand service identity, Key Vault permissions, key version behavior, auto-rotation support, revocation, deletion, region, subscription, tenant, and recovery dependencies. A key that is unavailable can make protected data or a service unavailable; customer control also creates customer operational responsibility.

Never include secret values in screenshots, exported reports, or assessment packages. Capture identifiers, version, dates, policy, and access evidence without exposing the material itself.

Logging and recovery

Prove that data access can be investigated and restored

Enable the resource-log categories needed for Storage, databases, and Key Vault, then route them to a Log Analytics workspace, storage account, or event hub according to investigation and retention requirements. Monitor public-network changes, firewall changes, role assignments, shared-key enablement, Key Vault access, key or secret deletion, purge attempts, unusual data access, Defender alerts, diagnostic-setting changes, and export activity.

Review platform backups, service-managed recovery, customer-managed backups, point-in-time restore, geo-redundancy, immutability, legal holds, and application-consistent recovery. Test a representative restoration and verify permissions, connection strings or identities, DNS, keys, encryption, application function, and data integrity. A database restored into an insecure network or with unavailable customer-managed keys is not a successful recovery.

See the Azure logging and Microsoft Sentinel guide and the Azure backup resilience guide for broader design and evidence.

Assessment and implementation

Protect data without breaking the applications that depend on it

OC Security Audit can assess exposure, authorization, cryptographic controls, logging, evidence, and risk. The IT Perfection Azure Storage security guide can support administrators planning implementation work.

Closure standard

Repeat access tests from authorized and unauthorized identities and networks, confirm public endpoint behavior, verify logging, rotate affected credentials, test application function, and preserve the before-and-after evidence.

Official guidance

Primary sources for continued review

Microsoft updates Azure capabilities, portal locations, licensing, defaults, feature status, and prerequisites. Confirm the current product documentation before a production change.

Authorize operations for Azure Storage data accessMicrosoft official guidance Apply Zero Trust principles to storage in AzureMicrosoft official guidance Enforce a minimum required TLS version for Azure StorageMicrosoft official guidance Security best practices for Azure SQL Database and Managed InstanceMicrosoft official guidance Secure your Azure Cosmos DB for NoSQL accountMicrosoft official guidance Secure your Azure Key VaultMicrosoft official guidance Best practices for protecting secretsMicrosoft official guidance

Practical questions

Frequently asked questions

Should Azure Storage Shared Key be disabled?

Where supported applications can use Microsoft Entra authorization, disabling Shared Key can reduce broad credential risk. Inventory dependencies, migrate, rotate, test, and monitor before disabling it.

Does a private endpoint disable public access?

Not automatically for every service. Create and validate the private path, then configure public network access according to the service and architecture. Test from authorized and unauthorized sources.

Why enable Key Vault purge protection?

Purge protection prevents permanent purge during the soft-delete retention period, helping defend against accidental or malicious deletion. Understand retention and recovery consequences before deployment.

Are customer-managed keys always more secure?

They provide additional control but also create key availability, permission, rotation, recovery, and operational responsibilities. Use them when risk, contract, or regulation justifies the complexity.

How should secrets be rotated?

Use an owner, expiration, automation, overlapping credentials when possible, secure distribution, monitored application update, old-credential revocation, failure handling, and evidence without revealing the secret.

About the author

Azure security guidance by Ali Hassani, CISO

Reviewed for practical Azure security, evidence, and remediation guidance by Ali Hassani, CISO, with 25+ years of IT and cybersecurity experience.

Meet Ali Hassani

This material is for initial guidance only and does not replace a professional cybersecurity audit, compliance assessment, penetration test, or legal/compliance review. Validate configuration, licensing, service availability, architecture, and business impact before production changes.