9.2 Azure Key Vault Deep Dive & Secrets Lifecycle

6.2 Azure Key Vault Deep Dive & Secrets Lifecycle

Azure Key Vault serves as the central cryptographic repository for securing application secrets, encryption keys, and TLS certificates across Azure services. Removing hardcoded credentials, connection strings, and certificates from application code is a fundamental requirement of cloud security. Mastering Key Vault requires a granular understanding of its object types, data plane access models, network boundaries, lifecycle protections, and automated rotation patterns.

---

Key Vault Object Types: Secrets, Keys & Certificates

Azure Key Vault manages three primary object categories, each designed for specific cryptographic and operational use cases:

+-----------------------------------------------------------------------------------+
|                              KEY VAULT OBJECT TYPES                               |
+--------------------------+--------------------------+-----------------------------+
|         SECRETS          |           KEYS           |        CERTIFICATES         |
| Octet strings up to 25KB | RSA / EC Cryptographic   | X.509 PKI Lifecycle         |
| Passwords, connection    | Data encryption, signing | Integrated CAs & auto-      |
| strings, PFX blobs.      | Key wrapping in HSM.     | renewal automation.         |
+--------------------------+--------------------------+-----------------------------+

1. Secrets

Secrets are arbitrary sequence byte arrays or UTF-8 string values up to 25 KB in size. Common examples include database connection strings, API tokens, passwords, and private SSH keys. Secrets are stored securely in Key Vault and returned in plaintext to authenticated applications over HTTPS TLS 1.2+ endpoints.

2. Cryptographic Keys

Keys are RSA or Elliptic Curve (EC) cryptographic key pairs used for encryption, decryption, digital signatures, and key wrapping operations (such as wrapping storage account keys). Crucial Design Rule: Cryptographic operations using Key Vault Keys take place inside the Key Vault service boundary. The private key material never leaves the Key Vault vault or HSM hardware.

3. Certificates

Certificates simplify the management, deployment, and renewal of X.509 public key certificates. Key Vault can generate self-signed certificates, integrate with partner Certificate Authorities (DigiCert, GlobalSign) for automated issuance, or import externally generated PFX certificates.

---

Access Control Models: Vault Access Policies vs. Azure RBAC

Azure Key Vault separates operations into two distinct administrative layers:

• Management Plane: Managed via Azure Resource Manager (ARM). Controls vault creation, deletion, tag management, and ARM access (Microsoft.KeyVault/vaults/*).
• Data Plane: Controls access to the actual secrets, keys, and certificates stored inside the vault.

Azure Key Vault supports two distinct authorization models for Data Plane operations:

Key Vault Access Policies (Legacy Model)

Access Policies grant permissions grouped by object type (Key Permissions, Secret Permissions, Certificate Permissions) to security principals (users, groups, or managed identities). Major Constraint: Access Policies apply globally at the vault level. If a principal is granted Secret Get permission via an Access Policy, they can read every secret within that entire vault.

Azure RBAC for Key Vault (Recommended Model)

Azure RBAC for Key Vault integrates Data Plane access into standard Azure Role-Based Access Control. This enables granular role assignments at fine scopes—down to an individual secret, key, or certificate:

• Key Vault Administrator: Full management of vault data plane objects and RBAC assignments.
• Key Vault Secrets Officer: Read, write, and delete secret contents.
• Key Vault Secrets User: Read secret contents only (Get / List).
• Key Vault Crypto Officer: Create, rotate, and execute cryptographic key operations.
• Key Vault Crypto User: Perform cryptographic operations (Encrypt/Decrypt/Wrap) using keys.

---

Network Isolation: Private Endpoints & Service Firewalls

By default, Key Vault exposes a public HTTPS FQDN (<vault-name>.vault.azure.net). To prevent unauthorized network exposure, security engineers must enforce network isolation:

1. Disable Public Access: Set publicNetworkAccess = "Disabled" on the vault resource.
2. Virtual Network Service Firewalls: Restrict inbound traffic to specific public IP CIDR ranges or delegated VNet subnets using Virtual Network Service Endpoints.
3. Azure Private Link (Private Endpoints): Assign a dedicated private IP address from a VNet subnet to Key Vault. All application traffic travels over internal Azure backbone routes. Private Endpoint resolution requires a Private DNS Zone named privatelink.vaultcore.azure.net linked to the application VNet.

---

Soft-Delete & Purge Protection Lifecycle

Accidental or malicious deletion of encryption keys or database secrets can cause catastrophic system outages or permanent data loss. Key Vault includes two essential lifecycle safety features:

+-----------------------------------------------------------------------------------+
|                         KEY VAULT DELETION LIFECYCLE                              |
+-----------------------------------------------------------------------------------+
|  Active Vault Object  ---> [Delete Executed] --->  Soft-Deleted Retention State   |
|                                                    (Configured for 7-90 Days)     |
|                                                                 |                 |
|     +-----------------------------------------------------------+                 |
|     |                                                           |                 |
|     v                                                           v                 |
| [Purge Protection DISABLED]                         [Purge Protection ENABLED]    |
| Authorized admin can immediately                    Purge command rejected by     |
| purge & permanently destroy item.                   service! Item MUST expire.    |
+-----------------------------------------------------------------------------------+

Soft-Delete

Soft-Delete retains deleted vaults, secrets, keys, and certificates for a configurable retention period between 7 and 90 days (default: 90 days). While in the soft-deleted state:

• The object cannot be recreated using the same name.
• The object can be fully restored (recover) back to an active state with its history intact.
• Soft-Delete is mandatory and permanently enabled on all Azure Key Vaults.

Purge Protection

Under basic Soft-Delete, a privileged identity with Purge permissions can manually bypass the retention timer and permanently delete objects. Purge Protection blocks manual purging during the retention window:

• Once Purge Protection is enabled on a Key Vault, it cannot be disabled by any user, Global Administrator, or Microsoft Support.
• Soft-deleted items must remain in the retention buffer until the retention timer fully expires.
• This protects against ransomware, insider threats, and compromised administrative accounts attempting to destroy master encryption keys.

---

Hardware Security Modules (HSM) Tier Comparison

Azure offers three distinct architectural tiers for Key Vault based on security compliance requirements:

1. Standard Tier: Software-protected keys backed by multi-tenant cryptographic modules validated to FIPS 140-2 Level 2.
2. Premium Tier: Supports HSM-protected keys (Hardware Security Modules) processed in multi-tenant HSM hardware validated to FIPS 140-2 Level 3.
3. Azure Key Vault Managed HSM: A fully managed, dedicated (single-tenant), highly available FIPS 140-2 Level 3 HSM cluster. Provides complete customer domain control, Local RBAC data plane governance, and confidential key isolation.

---

Automated Secret Rotation Architecture

Rotating credentials regularly minimizes exposure windows. Native Key Vault integration with Azure Event Grid enables event-driven automated secret rotation.

Event-Driven Secret Rotation Flow

1. Expiry Configuration: Secret or key objects are configured with an Expiration Date (exp).
2. Event Grid Notification: As the secret approaches expiration, Key Vault publishes a Microsoft.KeyVault.SecretNearExpiry event to an Azure Event Grid System Topic.
3. Automation Execution: Event Grid triggers an Azure Function (or Azure Automation Runbook).
4. Credential Update: The Azure Function connects to the target service (e.g., Azure SQL Database), generates a new random password, updates the database account, and writes the new secret version into Key Vault.