Post cover image
Photo by Shahadat Rahman on Unsplash

July 19, 2026

Data Encryption in Action: A Practical Azure Configuration Demo for Modern Applications

End-to-end Azure data protection — TLS, key custody, identity, and recoverable backups

By Chris Yeung

9 min read

Many teams say an application is encrypted because it uses HTTPS or because Azure SQL shows encryption enabled. That answer is incomplete. Sensitive data moves through several layers before it reaches storage. It also appears in backups, logs, exports and service-to-service connections.

This demo follows a general customer records application on Microsoft Azure. It shows how to protect data in transit, encrypt data at rest, remove credentials from application configuration, manage keys through Azure Key Vault and verify the result through Azure Monitor.

Demo Scenario: A Customer Records Application on Azure

The sample application collects customer names, email addresses, account numbers and uploaded contracts. Azure App Service hosts the application. Azure SQL Database stores structured records. Azure Blob Storage stores documents. Azure Key Vault holds cryptographic keys and any remaining third-party secrets. A Log Analytics workspace receives audit and resource logs.

The application uses a managed identity instead of embedded database passwords or storage account keys. Managed identities let App Service authenticate to supported Azure services through Microsoft Entra ID. This removes credentials from code and database connection strings.

None

The objective is simple. No password, account key or cryptographic key should appear in source code, deployment files, application packages or logs.

Mapping the Data Flow Before Configuring Encryption

The team first maps every place where sensitive data moves or remains stored:

  1. Browser to App Service
  2. App Service to Azure SQL Database
  3. App Service to Blob Storage
  4. App Service to Key Vault
  5. Azure SQL automated backups and exports
  6. Application, storage and Key Vault logs

This separates three different concerns. TLS protects data in transit. Storage encryption protects data at rest. Identity and authorization control who can request decryption or retrieve the data.

Step 1: Classify the Data That Needs Protection

Not every field needs the same control. A practical classification could look like this:

None

This matters because encryption can affect searching, indexing and application logic. Use stronger field-level controls for data that creates the greatest business or regulatory risk.

Step 2: Encrypt Data in Transit

Enforce HTTPS and Modern TLS on App Service

Enable HTTPS-only so App Service redirects normal HTTP requests to HTTPS. Then set the minimum TLS version for both the main application and the SCM site.

The SCM endpoint supports deployments, log streaming and advanced administrative tools. Leaving its TLS configuration weaker than the main application creates an avoidable gap. Microsoft recommends setting both endpoints to TLS 1.2 or later.

az webapp update \
  --resource-group <resource-group> \
  --name <app-name> \
  --https-only true

az webapp config set \
  --resource-group <resource-group> \
  --name <app-name> \
  --min-tls-version 1.2

az resource update \
  --ids "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<app-name>/config/web" \
  --set properties.scmMinTlsVersion=1.2

App Service also supports TLS 1.3. However, TLS 1.2 remains a reasonable minimum when the application must support older integrations or clients. Test client compatibility before enforcing a higher version.

Secure the Azure SQL Connection

Azure SQL Database enforces encrypted TLS connections between the client and database service. Set the logical server minimum TLS version to 1.2 and use a current Microsoft SQL driver. The client should validate the server certificate instead of accepting any certificate presented during the handshake.

TLS protects the session, but it does not replace authentication. The application still needs a controlled identity with limited database permissions.

Require Secure Blob Storage Traffic

Azure Storage can reject REST requests made over HTTP when secure transfer is required. Explicitly set TLS 1.2, disable anonymous Blob access and disable Shared Key authorization after all clients use Microsoft Entra ID.

az storage account update \
  --resource-group <resource-group> \
  --name <storage-account> \
  --https-only true \
  --min-tls-version TLS1_2 \
  --allow-blob-public-access false \
  --allow-shared-key-access false

Disabling Shared Key is important because an account key can authorize broad storage access. Confirm that every application and operational tool supports Entra-based authorization before switching it off.

Audit all clients and automation, perform a phased rollout and maintain a fallback plan before disabling Shared Key because legacy tools or account‑level operations may still require it.

External versus internal TLS

Separate external client TLS from internal service‑to‑service TLS and platform control channels; validate certificates on every client and service and prefer private endpoints or VNet integration to reduce exposure.

Step 3: Encrypt Azure SQL Data and Backups

Transparent Data Encryption, or TDE, is enabled by default for newly created Azure SQL databases. It encrypts database files, transaction logs and associated backups at rest without requiring application changes.

Check its status from the database:

SELECT
    DB_NAME(database_id) AS database_name,
    encryption_state,
    percent_complete,
    key_algorithm,
    key_length
FROM sys.dm_database_encryption_keys;

TDE protects against offline access to database storage. It does not stop an authorized database identity from reading rows through normal queries. Access control and database permissions therefore remain essential. Use field‑level controls for highly sensitive columns.

For stronger key custody, replace the service-managed TDE protector with a customer-managed key stored in Key Vault. Customer-managed TDE gives the organization direct control over key creation, permissions, rotation, auditing and deletion.

The SQL logical server uses a managed identity to access the key. That identity should receive only the cryptographic permissions required for service encryption, such as reading key metadata and performing wrap or unwrap operations. Key Vault provides a dedicated Key Vault Crypto Service Encryption User role for this purpose.

Keep previous TDE key versions available after rotation. Older backups remain tied to the protector used when Azure created them. Removing that key too early can prevent a future restore.

For a small number of highly sensitive columns, consider Always Encrypted. It keeps column master keys outside the database engine and lets an enabled client driver encrypt or decrypt selected values. This adds protection for fields such as tax identifiers, but it changes query and application behavior. Use it selectively rather than applying it to every column.

Step 4: Encrypt Blob Storage and Uploaded Files

Azure Storage encrypts stored data by default. A customer-managed key adds separation of duties and gives the organization direct control over the key lifecycle.

A hardened storage configuration should include:

  • Secure transfer required
  • Minimum TLS 1.2
  • Anonymous Blob access disabled
  • Shared Key access disabled where feasible
  • Azure RBAC scoped to the required container or account
  • A customer-managed key when policy requires direct key control

Assign the App Service identity a data-plane role such as Storage Blob Data Contributor only at the required scope. Avoid subscription-wide role assignments.

When configuring a customer-managed key, omit the key version if the storage account should follow the latest version automatically. Azure Storage checks Key Vault daily for newer versions. Wait at least 24 hours after rotation before disabling the previous version.

Encryption at rest does not prevent authorized reads; never expose sensitive blobs publicly even if storage is encrypted. A file can remain encrypted on disk while a broad permission allows an unauthorized user to request the decrypted object. Encryption and authorization solve different problems.

Step 5: Configure Azure Key Vault Properly

Use Key Vault for two distinct object types. Store API tokens, legacy passwords and connection strings as secrets. Store cryptographic material used by Azure SQL, Storage or application encryption as keys.

Key Vault supports Vault access policies and Azure RBAC. Enable and test the chosen model on the vault because RBAC must be turned on to use RBAC roles. Verify client and SDK compatibility before switching models.

Configure the vault with Azure RBAC, soft delete and purge protection. Soft delete allows recovery during the configured retention period. Purge protection prevents permanent deletion before that period expires, which reduces the risk of losing access to encrypted data because a key disappeared.

Use separate objects for:

  • The Azure SQL TDE protector
  • The Storage customer-managed key
  • Any Always Encrypted column master key
  • Remaining third-party API secrets

Apply the narrowest role that supports each use case. The App Service identity may need Key Vault Secrets User to read a secret. Azure SQL or Storage may need Key Vault Crypto Service Encryption User. The runtime application should not receive Key Vault Administrator or key deletion permissions.

Key Vault supports rotation policies that create new key versions on a schedule. Rotation still requires dependency planning. Verify that Azure SQL, Storage and the application can use the new version before disabling an older one.

Rotation checklist: create new key version; configure the service to use the new version; wait 24–48 hours for propagation; test restore of backups encrypted with the old key; disable old version only after successful restores.

Step 6: Remove Credentials from the Application

Enable a system-assigned managed identity on App Service:

az webapp identity assign \
  --resource-group <resource-group> \
  --name <app-name>

Consider user‑assigned managed identities when you need the same identity across multiple resources or want identity lifecycle decoupled from the App Service instance.

App Service managed identities remove the need to store supported Azure service credentials in the application.

For Azure SQL, configure a Microsoft Entra administrator on the logical server. Then create a contained database user for the App Service identity and grant only the permissions the runtime requires.

CREATE USER [<app-service-name>] FROM EXTERNAL PROVIDER;

ALTER ROLE db_datareader
ADD MEMBER [<app-service-name>];

ALTER ROLE db_datawriter
ADD MEMBER [<app-service-name>];

Use a separate deployment identity for schema changes. The production runtime rarely needs permission to create, alter or delete database objects.

Some external services still require an API key. Store that value in Key Vault and expose it through an App Service Key Vault reference:

@Microsoft.KeyVault(
  VaultName=<vault-name>;
  SecretName=<secret-name>
)

App Service resolves the reference through its managed identity. Application code reads the setting normally, but the secret remains outside the application's direct configuration workflow.

Step 7: Protect Backups and Exports

Azure SQL Database automatically creates backups for point-in-time restoration. TDE protects those automated backups at rest. Configure retention around recovery and compliance requirements, then conduct a test restoration instead of assuming the backup is usable.

Customer-managed TDE creates an additional dependency. The target server must access the historical key version used to protect an older backup.

Treat exports separately. A BACPAC, CSV file or downloaded document becomes a new copy outside the managed database boundary. Microsoft states that data in a normal BACPAC is compressed but not encrypted. Place exports in a private encrypted storage container, restrict download access and apply a deletion policy.

Step 8: Add Basic Monitoring and Audit Evidence

Resource logs are not collected automatically for every Azure resource. Create diagnostic settings for Key Vault, Blob Storage and App Service, then send the required logs to Log Analytics.

az monitor diagnostic-settings create \
  --name "key-vault-audit" \
  --resource <key-vault-resource-id> \
  --workspace <log-analytics-workspace-id> \
  --logs '[{"categoryGroup":"audit","enabled":true}]'

Key Vault audit logs can show which identity accessed a key or secret, which operation it requested and whether Azure allowed it. Blob logs capture data-plane operations and include details such as authentication type, caller identity and TLS version.

Start with alerts for repeated denied Key Vault requests, permission changes, key deletion attempts, unexpected Shared Key usage and unusual document download volume.

Application logs should redact tokens, account numbers, personal identifiers and document contents before telemetry reaches Log Analytics. App Service supports diagnostic settings, Application Insights, log streams, metrics and alerts for operational monitoring.

Step 9: Validate the Configuration

A security configuration is incomplete until the team proves it works.

  1. Request the App Service URL over HTTP and confirm HTTPS enforcement.
  2. Query App Service and verify both site and SCM TLS settings.
  3. Remove the SQL password setting and confirm managed identity access still works.
  4. Remove the Blob role temporarily and confirm uploads fail.
  5. Retrieve a test secret and confirm the event appears in Key Vault logs.
  6. Verify SQL TDE, the TDE protector and Storage encryption key source.
  7. Verify secure transfer, minimum TLS and Key Vault purge protection.
  8. Restore a test database to confirm backup and historical key availability.

The following command checks the App Service TLS configuration:

az webapp show \
  --name <app-name> \
  --resource-group <resource-group> \
  --query "siteConfig.{siteTls:minTlsVersion,scmTls:scmMinTlsVersion}" \
  --output table

For stronger network isolation, add App Service VNet integration and private endpoints for SQL, Storage and Key Vault. VNet integration lets App Service reach resources through a virtual network. Private endpoints provide private addresses, but teams must also configure private DNS and disable unwanted public access.

Common Encryption Mistakes This Demo Exposes

The most common failures are practical, not mathematical:

  • HTTPS protects the browser connection, but internal connections remain unchecked.
  • TDE is enabled, but exports are copied into an open storage location.
  • Storage uses encryption, but anonymous or Shared Key access remains available.
  • Managed identities receive subscription-wide permissions.
  • Teams rotate keys and remove versions needed for old backups.
  • Logs capture tokens or complete request bodies.

The final design must protect the data path, identities, keys and recovery process together.

Encryption in Azure is not a single switch. TLS protects movement. TDE and Storage encryption protect stored data. Managed identities remove credentials. Key Vault controls keys and secrets. Azure Monitor creates evidence that these controls continue to work.