Secure Compute, Storage, and Databases
Encryption, keys, and secrets
Azure Storage is encrypted at rest by default with platform-managed keys (storage service encryption). You can switch to customer-managed keys in Key Vault, and you can enable infrastructure encryption (double encryption) only at account creation. Azure Disk Encryption (BitLocker/DM-Crypt inside the guest) is different from SSE for managed disks; encryption at host covers the temp disk and disk cache. Key Vault supports access policies or Azure RBAC (choose per vault), soft delete, purge protection (irreversible once enabled), and Managed HSM for FIPS 140-2 Level 3 keys.
Data services
For Azure SQL, Transparent Data Encryption encrypts the whole database at rest; Always Encrypted encrypts chosen columns client-side so the service never sees plaintext; Dynamic Data Masking only masks values in query results and does not encrypt anything. Storage authorization preference: Entra ID with managed identity, then user delegation SAS, then service SAS bound to a stored access policy, then account key last. A stored access policy is how you revoke a service SAS.
Compute hardening
Use Trusted Launch (secure boot, vTPM, boot integrity monitoring) for VMs, just-in-time VM access to close management ports, and Defender for Servers for endpoint and vulnerability coverage. Prefer managed identities over connection strings and keys in App Service and AKS; use workload identity for pods pulling from Key Vault or ACR.
Worked example. Give an App Service app read-only Key Vault access: enable a system-assigned managed identity on the app, grant it the Key Vault Secrets User role at vault scope, and reference the secret with the Key Vault reference syntax. Traps: purge protection cannot be turned off; secure transfer required enforces HTTPS on storage; account SAS is the broadest and should be avoided.