Data Security in Azure Workloads

Simple explanation

The Three States of Data

Every piece of data exists in one of three states at any moment:

At rest — Stored on disk (Azure Storage, SQL databases, VM disks, Cosmos DB). Not currently being processed.
In transit — Moving between locations (client to server, service to service, on-premises to cloud). Vulnerable to interception.
In use — Actively being processed in memory. Traditionally, data must be decrypted to be processed.

The security architect designs protection for all three states. A gap in any state creates a vulnerability:

Encrypted at rest but sent unencrypted in transit → interception risk
Encrypted in transit but stored unencrypted at rest → data breach if disk is compromised
Encrypted at rest and in transit but decrypted in memory → vulnerable to memory dumps, insider threats, and cloud provider access

Data at Rest: Encryption Architecture

Azure Default Encryption

All Azure storage services encrypt data at rest by default using AES-256 encryption:

Azure Storage (blobs, files, queues, tables) — Storage Service Encryption (SSE)
Azure SQL Database — Transparent Data Encryption (TDE)
Azure Managed Disks — Server-side encryption
Cosmos DB — Encryption at rest enabled by default
Azure Data Lake Storage — Encrypted by default

This means the architect doesn’t need to “turn on” encryption. The decision is about key management.

Platform-Managed Keys vs Customer-Managed Keys

Key Management Options
	Platform-Managed Keys (PMK)	Customer-Managed Keys (CMK)
Who manages the key?	Microsoft generates, stores, and rotates the encryption key	Your organisation generates and stores the key in Azure Key Vault (or Managed HSM). You control rotation.
Key visibility	You cannot see or access the key. Microsoft manages it entirely.	You see and control the key. You can rotate, revoke, or audit access.
Compliance	Sufficient for most compliance frameworks (SOC 2, ISO 27001)	Required by some regulations (certain financial services, government). Demonstrates key custody.
Operational overhead	None — fully automated by Azure	Moderate — you manage key rotation, Key Vault access policies, key availability. If the key is deleted or Key Vault is unavailable, data becomes inaccessible.
Data sovereignty	Microsoft manages keys in the same region as the data	Full control — you can use keys stored in a specific region or on-premises HSM via Key Vault with BYOK
Risk	Trust in Microsoft's key management security	Risk of data loss if key is accidentally deleted without soft-delete/purge protection. Operational complexity.
Cost	Included at no extra cost	Key Vault costs + operational costs for key management

The Architect’s Decision Framework

Use PMK when:

The compliance framework accepts Microsoft-managed encryption (most do)
The organisation doesn’t need to demonstrate key custody
Operational simplicity is a priority

Use CMK when:

Regulations specifically require customer key custody (certain financial, government, or healthcare requirements)
The organisation needs the ability to revoke access to data independently (crypto-shredding — deleting the key renders all encrypted data permanently inaccessible)
Data sovereignty requirements demand that encryption keys are stored in a specific jurisdiction

CMK architectural requirements:

Azure Key Vault with soft delete and purge protection enabled (prevents accidental key deletion)
RBAC on Key Vault — only the encryption service’s managed identity has key access
Key rotation procedure — automated rotation with defined schedule
Backup and recovery plan for keys — Key Vault backup, multi-region replication for Managed HSM
Monitoring and alerting — alerts on key access, rotation, deletion attempts

🎯 Exam Tip: PMK vs CMK Questions

SC-100 will present a scenario and ask whether PMK or CMK is appropriate. The deciding factor is almost always regulatory requirement or the need for crypto-shredding. If the scenario mentions “regulatory compliance requires the organisation to maintain key custody” or “the organisation must be able to independently revoke access to all data,” the answer is CMK. If neither of these is mentioned, PMK is sufficient and simpler.

Data in Transit: Network Encryption

TLS Enforcement

All Azure services support TLS 1.2. The architect’s job is ensuring minimum TLS version enforcement:

Azure Storage: Set the minimum TLS version to 1.2 on the storage account. Reject connections using TLS 1.0 or 1.1.
Azure SQL: TLS 1.2 enforced by default on newer servers. Verify on legacy servers.
App Service: Configure minimum TLS version in app settings.
API Management: Configure TLS policy to reject older protocols.

VPN and ExpressRoute

For data flowing between on-premises and Azure:

Site-to-site VPN: IPsec/IKE encrypted tunnel over the public internet. Good for moderate bandwidth needs. Encryption is automatic.
ExpressRoute: Private connection through a connectivity provider. Traffic doesn’t traverse the public internet, but it’s not encrypted by default (it’s a private circuit, not a public one).
ExpressRoute with MACsec: Layer 2 encryption for the link between your edge router and Microsoft’s. Encrypts the physical circuit.
VPN over ExpressRoute: Run an IPsec VPN tunnel through the ExpressRoute circuit for end-to-end encryption of the private connection.

The architect chooses based on the sensitivity of the data:

Standard enterprise data → ExpressRoute (private, not encrypted at the link level but traffic is isolated)
Highly sensitive data → VPN over ExpressRoute (private circuit + encrypted tunnel)
Classified government data → ExpressRoute with MACsec + application-layer encryption

Data in Use: Confidential Computing

This is the newest frontier of data protection. Traditional encryption protects data at rest and in transit, but data must be decrypted for processing. During processing, data is vulnerable in memory to:

Memory dump attacks
Side-channel attacks
Insider threats (cloud provider administrators)
Compromised hypervisor or host OS

Azure Confidential Computing addresses this by processing data inside hardware-based Trusted Execution Environments (TEEs) — secure enclaves that isolate data even from the host operating system and Azure administrators.

Confidential Computing Options

Confidential VMs — The entire VM runs inside a TEE. The VM’s memory is encrypted, and even the Azure host operator cannot access it. Uses AMD SEV-SNP or Intel TDX hardware.
Confidential containers on AKS — Container workloads run inside TEEs on AKS nodes. The container’s memory is isolated from the host.
Application enclaves — Only the sensitive portion of the application runs inside an enclave (using Intel SGX). The rest of the application runs normally. More complex to develop but provides the smallest trusted computing base.

When to Use Confidential Computing

Confidential computing adds complexity and cost. The architect recommends it when:

Processing data from multiple parties who don’t trust each other (multi-party computation)
Regulatory requirements demand protection from cloud provider access (certain banking, healthcare, government workloads)
Processing highly classified or sensitive data where even theoretical cloud provider access is unacceptable

🏛️ Scenario: Torres Evaluates Confidential Computing

Commander Torres at the Department of Federal Systems is evaluating whether classified data processing can move to Azure. Colonel Reeves is sceptical: “How do we ensure Microsoft can’t access our data while it’s being processed?”

Torres designs a confidential computing architecture:

Confidential VMs with AMD SEV-SNP for all classified workloads — VM memory is encrypted with keys held in the hardware, inaccessible to Azure operators
Attestation verification — before sending data to a confidential VM, the client verifies the VM is running inside a genuine TEE with the expected software configuration
Private endpoints + ExpressRoute with MACsec — data in transit is encrypted at all layers
CMK with Managed HSM — data at rest is encrypted with government-controlled keys

Torres presents to Colonel Reeves: “With this architecture, data is encrypted at rest with our keys, encrypted in transit through our private connection, and processed inside hardware enclaves that Azure cannot access. At no point is our data accessible to Microsoft.”

Azure SQL Security Architecture

Azure SQL provides multiple security layers that the architect designs as defence-in-depth:

Security Layers

Network isolation — Private endpoints. The SQL server is never accessible from the public internet.
Authentication — Entra ID authentication (preferred) or SQL authentication. Managed identities for application access.
Authorisation — Database-level RBAC. Principle of least privilege.
Transparent Data Encryption (TDE) — Encrypts the database, backups, and transaction logs at rest. On by default with PMK; configurable with CMK.
Always Encrypted — Client-side encryption. Data is encrypted before it reaches the database. The database server never sees the plaintext. Keys are held in the client application (via Key Vault).
Dynamic Data Masking — Obfuscates sensitive data in query results for non-privileged users. The data is stored in plaintext but displayed masked (e.g., credit card shows as XXXX-XXXX-XXXX-1234).
Row-Level Security — Filters rows based on the user’s context. A sales rep sees only their customer records; a manager sees all.
Auditing — Logs all database operations to Azure Storage, Log Analytics, or Event Hub for compliance and investigation.

Always Encrypted: The Deep Dive

Always Encrypted is architecturally significant because it provides true encryption-in-use for database workloads — without Confidential Computing:

Data is encrypted by the client application using Column Master Keys (CMKs) stored in Key Vault
The database server stores and processes encrypted data — it never has access to the plaintext
Even a database administrator with full server access cannot read the encrypted columns
Queries on encrypted columns use deterministic encryption (equality queries work) or randomised encryption (no querying, maximum security)

When to use Always Encrypted:

Sensitive columns that must be protected from database administrators (e.g., personal health information, government ID numbers)
Compliance requirements demanding separation between data owners and database operators
Scenarios where the database server (even Azure) should never see certain data values

☁️ Scenario: Rajan’s Healthcare Database Design

Rajan at Skyline Security Consulting is advising a healthcare client whose patient database must comply with HIPAA. The client’s requirement: database administrators must be able to manage the database (backups, index tuning, performance monitoring) but must not be able to read patient health records.

Rajan designs an Always Encrypted architecture:

Patient ID, diagnosis codes, and treatment notes are encrypted with Always Encrypted (randomised encryption for maximum security)
Column Master Keys are stored in Azure Key Vault, accessible only to the clinical application’s managed identity
Database administrators have full management access to the server but cannot decrypt patient data — they see encrypted binary values
The clinical application retrieves data through the Always Encrypted-aware driver, which decrypts at the client side

Deepak Malhotra (the client’s CTO) asks: “Does this affect query performance?” Rajan explains that deterministic encryption allows equality queries (WHERE PatientID = @id) but randomised encryption does not support querying (you can’t search for all patients with a specific diagnosis through the encrypted column). The architect must carefully choose which columns use which encryption type based on query requirements.

Azure Storage Security

Storage Security Layers

Authentication: Entra ID RBAC (recommended) or shared access keys. Never use account-level shared keys in production — a single leaked key gives full access to the entire storage account.
SAS tokens: Scoped access to specific containers, blobs, or operations with time-limited validity. Three types:
- Account SAS — Broad access to the storage account (avoid)
- Service SAS — Access to a specific service (blob, file, queue, table)
- User delegation SAS — Created using Entra ID credentials. Most secure — traceable to a specific user and revocable.
Private endpoints: Storage account accessible only through the virtual network. Disable public network access entirely.
Immutable storage: Write-Once-Read-Many (WORM) policies that prevent modification or deletion of blobs for a defined retention period. Required for SEC 17a-4, FINRA, and CFTC compliance.
Encryption: SSE with PMK (default) or CMK. Infrastructure encryption adds a second layer of encryption using a different algorithm.

💰 Scenario: Ingrid’s Encryption Strategy for Trading Data

Ingrid designs the data security architecture for Nordic Capital’s trading platform on Azure:

Azure SQL (Trading database):

TDE with CMK (regulatory requirement — FMA requires key custody for financial data)
Always Encrypted for client account numbers and portfolio values
Row-level security: traders see only positions in their assigned portfolios
Dynamic data masking: support staff see masked account numbers
Private endpoints only — no public access
Auditing to Log Analytics with 7-year retention

Azure Storage (Document archive):

CMK for encryption at rest (same Key Vault as SQL keys)
Immutable storage with 7-year retention for regulatory records
User delegation SAS for external auditor access (time-limited, traceable, revocable)
Private endpoints — auditor access through a dedicated VPN

Azure Key Vault:

Managed HSM for the most critical keys (trading platform encryption keys)
Standard Key Vault for application secrets and certificates
Soft delete + purge protection enabled (mandatory — accidental key deletion would make all trading data permanently inaccessible)
Separate Key Vaults for production and non-production (prevent accidental cross-environment access)
Key rotation: automated 90-day rotation for storage encryption keys, annual rotation for SQL TDE keys

Cosmos DB (Real-time market data):

Default encryption at rest (PMK sufficient — market data is not proprietary)
Private endpoints for access from the trading application only
RBAC with managed identity for application access

Ingrid’s design principle: “Not all data needs the same protection. CMK for regulated financial data, PMK for market data. Always Encrypted for the most sensitive columns, TDE for the rest. The architecture matches protection intensity to data sensitivity.”

Knowledge Check

A financial services company needs to encrypt customer data in Azure SQL so that database administrators can manage the server but cannot read customer records. Which Azure SQL feature should the architect recommend?

Knowledge Check

An organisation uses Azure Storage for regulatory records that must be retained for 7 years per SEC 17a-4. The records must not be modifiable or deletable during the retention period, even by administrators. What should the architect implement?

Knowledge Check

Commander Torres needs to process classified data in Azure. The requirement is that data must be protected from access by Azure operators during processing. What Azure capability addresses this requirement?

Knowledge Check

Question

When should a security architect recommend customer-managed keys (CMK) over platform-managed keys (PMK)?