Secure Data at Rest and in Transit

Data security in Azure has two fundamental modes: protecting data at rest and protecting data in transit. Data at rest means any data stored persistently — on a disk, in a database, in a backup, or in a file share. Data in transit means data actively moving across a network — between a user's browser and a web server, between two Azure services, or between an on-premises data centre and the cloud.

Azure secures data at rest primarily through encryption. Encryption is the process of scrambling data using a secret key so that only someone with the correct key can read it. Think of it like a lockbox: you put the data in, turn the key, and the lockbox becomes unreadable gibberish to anyone else. Azure offers two types of encryption keys: platform-managed keys (PMKs), where Microsoft manages the lockbox for you automatically, and customer-managed keys (CMKs), where you control the key yourself, often using a hardware security module (HSM) — a dedicated physical device that stores keys in a tamper-proof enclosure.

Azure Storage Service Encryption (SSE) encrypts data at rest automatically for Azure Blob Storage, Azure Files, Azure Queue Storage, and Azure Table Storage. SSE uses 256-bit Advanced Encryption Standard (AES-256), which is the same encryption standard used by banks and governments. Azure SQL Database also encrypts data at rest through Transparent Data Encryption (TDE), which encrypts the entire database file on disk without requiring changes to the application. TDE can use a service-managed key or a customer-managed key stored in Azure Key Vault.

Azure Key Vault is a central cloud service for storing and managing secrets like encryption keys, passwords, and certificates. It integrates with other Azure services to handle key rotation (regularly replacing old keys with new ones), key expiration, and access auditing. For DP-203, you should know that Key Vault supports two tiers: Standard (software-protected keys) and Premium (hardware-protected keys using HSMs).

Data in transit is protected using different encryption protocols. Transport Layer Security (TLS) is the primary protocol for encrypting data moving over the internet or internal networks. When you visit a website using HTTPS, your browser and the web server negotiate a TLS session, exchanging digital certificates to verify each other's identity, then encrypt all data exchanged. Azure enforces TLS 1.2 or later for all communications between its services and clients. Internet Protocol Security (IPsec) is another protocol used for site-to-site VPN connections between an on-premises network and Azure. IPsec encrypts the entire IP packet, wrapping it in a secure tunnel.

Azure also provides encryption at the network layer using Virtual Network encryption and Azure ExpressRoute. ExpressRoute is a private, dedicated network connection from your on-premises data centre to Azure that bypasses the public internet entirely. Even though ExpressRoute avoids the internet, Microsoft still recommends enabling encryption over the connection, because private circuits can still be physically tapped.

Beyond encryption, access control is a critical part of securing data at rest and in transit. Azure uses Role-Based Access Control (RBAC) to define who can read, write, or delete data. RBAC is like a door key system: you assign roles (like "Storage Blob Data Reader") to users or groups, and those roles determine which data they can access. Managed identities are another important concept: they give an Azure service (like a virtual machine or an Azure Function) an automatically managed identity in Microsoft Entra ID, so the service can authenticate to other Azure services without storing credentials.

Firewalls and network security groups (NSGs) add another layer. A firewall is like a bouncer at a club: it checks every incoming request and only allows traffic from approved IP addresses or networks. NSGs are simpler filters that control traffic between Azure resources inside a virtual network. For example, you can create an NSG rule that says "only allow traffic from the corporate VPN IP range to the SQL database."

Finally, Azure Policy and Microsoft Defender for Cloud help enforce and monitor security configurations. Azure Policy can automatically apply encryption requirements to all new storage accounts, so no one can accidentally create an unencrypted resource. Microsoft Defender for Cloud scans your environment, detects misconfigurations (like a storage account with public access enabled), and alerts you to threats like unusual access patterns or potential data exfiltration.

For DP-203, you need to understand the difference between encryption at rest (always on by default for most Azure storage) and encryption in transit (often optional, but must be enabled explicitly for some services). You also need to know how to choose between platform-managed and customer-managed keys, and when to use Azure Key Vault, RBAC, firewalls, and NSGs together to create a defence-in-depth strategy — that is, multiple layers of security so that if one layer fails, another still protects the data.

Imagine you are a data engineer at a healthcare company migrating patient records to Azure. The compliance team insists that all Protected Health Information (PHI) must be encrypted both at rest and in transit, and access must be logged. You set up the following architecture.

First, you create an Azure Storage account to store the patient data. By default, Azure Storage Service Encryption (SSE) with Microsoft-managed keys encrypts all data at rest. But the compliance requirement demands customer-managed keys, so you create an Azure Key Vault instance with the Premium tier, generate a key using a hardware security module (HSM), and configure the storage account to use that key. You also enable key rotation — every 90 days, Key Vault automatically creates a new key to replace the old one.

Next, you configure encryption in transit. The application that writes patient data runs on an Azure Virtual Machine. You ensure that the application uses HTTPS (TLS 1.2 minimum) when connecting to the storage account. You also set up a firewall on the storage account that only allows traffic from the virtual machine's private IP address inside the virtual network. To be even more restrictive, you add a service endpoint — a secure connection from the virtual network directly to the storage account, bypassing the public internet entirely.

For the database, you migrate the patient records to Azure SQL Database. You enable Transparent Data Encryption (TDE) with customer-managed keys from the same Key Vault. You also configure a server-level firewall rule that blocks all traffic except from the application tier's IP range. To encrypt connections to the database, you enforce TLS 1.2 by setting the "Minimum TLS version" property on the Azure SQL logical server.

Now, access control. You create a managed identity for the virtual machine and grant it the "Storage Blob Data Contributor" role on the storage account. This means the VM can read and write blobs without any stored passwords — the identity automatically authenticates through Microsoft Entra ID. You assign the "SQL DB Contributor" role to the same identity so it can query the database. You also set up an Azure Policy called "Require encryption at rest for storage accounts" and apply it to the entire subscription. Any new storage account created in the future will automatically get encryption enabled, preventing accidental misconfiguration.

Finally, you enable Azure Monitor and Microsoft Defender for Cloud. Defender for Cloud alerts you if someone tries to access the storage account from an unexpected location, or if a key in Key Vault is nearing expiration. You set up an action group that sends an email to the security team when such an alert fires. You also configure diagnostic settings to send all access logs for the storage account, Key Vault, and SQL database to a Log Analytics workspace for audit review.

A typical day: a senior developer asks for read-only access to the patient data for a research query. You do not give them the storage account key or the database password. Instead, you assign their Microsoft Entra ID user account the "Storage Blob Data Reader" role and the "DB Datareader" role. They authenticate via Azure CLI, and all their actions are logged. Six months later, during a compliance audit, you can show the auditor exactly who accessed what, when, and from which IP address.