Lesson 07 — Azure Key Vault Security

Welcome

Azure Key Vault is a managed service used to protect sensitive security material such as:

Passwords
Application secrets
API tokens
Database connection strings
Encryption keys
Signing keys
TLS certificates
Automation credentials

During an Azure penetration testing engagement, Key Vault is considered a high-value resource.

A compromised Key Vault identity or permission may allow an attacker to access credentials used by applications, databases, automation systems, virtual machines, serverless workloads, and other Azure services.

The objective of this lesson is not to retrieve production secrets unnecessarily. Your objective is to understand the Key Vault attack surface, identify excessive access, map connected attack paths, and validate risk using safe and authorised techniques.

Learning Objectives

By the end of this lesson, you will be able to:

Explain the purpose and architecture of Azure Key Vault.
Differentiate between secrets, keys, and certificates.
Understand Key Vault management-plane and data-plane access.
Compare Azure RBAC with legacy Key Vault access policies.
Identify sensitive Key Vault roles and permissions.
Assess service-principal and managed-identity access.
Review public access, firewalls, and private endpoints.
Assess secret expiration and rotation controls.
Review soft delete and purge protection.
Perform authorised Key Vault enumeration.
Build realistic Key Vault attack paths.
Document findings without exposing sensitive values.

Mission Context

You are continuing the authorised Azure penetration test for CloudNova Technologies.

The organisation uses Azure Key Vault to support:

Azure Virtual Machines
Azure Functions
App Services
Azure Kubernetes Service
CI/CD pipelines
Automation Accounts
Enterprise applications
Storage services
Production databases

The vaults contain:

Application credentials
Database passwords
API tokens
TLS certificates
Encryption keys
Service-principal secrets

Your objective is to determine whether unauthorised or excessive access could allow an attacker to:

Discover sensitive vaults
Enumerate stored object metadata
Retrieve secrets
Use cryptographic keys
Export certificates
Modify protected values
Establish persistent access
Move laterally into connected services
Delete or disrupt critical cryptographic material

All activities must remain within the authorised tenant, subscription, resource groups, vaults, test identities, and Rules of Engagement.

What Is Azure Key Vault?

Azure Key Vault provides centralised storage and access control for sensitive security objects.

Azure Key Vault
│
├── Secrets
│   ├── Passwords
│   ├── API tokens
│   ├── Client secrets
│   └── Connection strings
│
├── Keys
│   ├── Encryption keys
│   ├── Signing keys
│   └── Key-wrapping keys
│
└── Certificates
    ├── TLS certificates
    ├── Client certificates
    └── Private-key material

Key Vault security depends on several connected controls:

Microsoft Entra ID
        +
Azure RBAC or access policies
        +
Network restrictions
        +
Object lifecycle protection
        +
Logging and monitoring

A weakness in any of these areas may create an exploitable attack path.

Azure Key Vault Objects

Secrets

Secrets are protected values consumed by users, applications, and automation processes.

Examples include:

Passwords
API keys
Client secrets
Database connection strings
Access tokens
Storage credentials
Application configuration values

A secret may contain multiple versions.

Older versions may remain available unless they are disabled, expired, or removed according to organisational policy.

Keys

Keys are cryptographic objects used for operations such as:

Encryption
Decryption
Signing
Signature verification
Key wrapping
Key unwrapping

An application may be authorised to use a key without retrieving the private key material.

The ability to use a key can still be highly sensitive.

For example, permission to decrypt data may provide access to protected business information even when the key itself is non-exportable.

Certificates

Certificates may contain:

Public certificate information
Private-key material
Issuer configuration
Renewal settings
Certificate policies
Associated secret and key objects

Certificates may support:

TLS encryption
Application authentication
Client authentication
Device identity
Code signing

Exportable certificates require particularly strong governance because compromise of the private key may allow identity impersonation outside Azure.

Management Plane and Data Plane

Azure Key Vault uses two important permission areas.

Management Plane

Management-plane access controls the Azure resource itself.

Examples include:

Creating or deleting a vault
Configuring networking
Creating private endpoints
Changing the authorisation model
Configuring diagnostic settings
Assigning Azure roles
Managing resource properties

Management access does not always provide permission to retrieve secret values.

However, management permissions may sometimes allow security controls to be changed, creating an indirect path to protected objects.

Data Plane

Data-plane access controls the objects stored inside the vault.

Examples include:

Listing secret metadata
Retrieving secret values
Creating or updating secrets
Deleting secrets
Using cryptographic keys
Managing certificates
Recovering deleted objects
Purging protected objects

A complete assessment must review both planes.

Management-plane access
        +
Data-plane access
        =
Complete Key Vault permission picture

Key Vault Authorisation Models

Azure Key Vault environments may use:

Azure role-based access control
Legacy Key Vault access policies

The active model must be identified before evaluating permissions.

Azure RBAC

Azure RBAC uses standard Azure role assignments.

Security principal
+
Role definition
+
Scope

The security principal may be:

A user
A group
A service principal
A managed identity

The scope may be:

Subscription
Resource group
Key Vault
Supported individual object

Azure RBAC provides centralised governance and inherited access.

Broad assignments at subscription or resource-group scope may affect multiple vaults.

Legacy Access Policies

Access policies assign vault-specific permissions directly to identities.

Permissions may include operations against:

Secrets
Keys
Certificates

Potential risks include:

Excessive permissions
Old identities remaining in policies
Broad access granted to application identities
Identities able to modify access policies
Weak separation between vault administration and object access

The assessment must determine who can modify the policy, not only who currently has access.

Important Key Vault Roles

Key Vault Reader

Allows access to certain object metadata but not normally to protected secret values.

Metadata may still reveal:

Secret names
Key names
Certificate names
Expiration dates
Version information
Enabled status

Descriptive names may expose details about internal applications or infrastructure.

Key Vault Secrets User

Allows retrieval of secret values at the assigned scope.

This is a sensitive data-plane role.

Key Vault Secrets Officer

Provides broad secret-management permissions.

Depending on configuration, this may include:

Reading secrets
Creating secrets
Updating secrets
Deleting secrets
Recovering secrets

Key Vault Crypto User

Allows authorised cryptographic operations using stored keys.

Key Vault Crypto Officer

Provides broad key-management permissions.

Key Vault Certificates Officer

Provides certificate-management capabilities.

Key Vault Administrator

Provides broad data-plane administration over secrets, keys, and certificates.

This role should be tightly controlled, monitored, and narrowly scoped.

Key Vault Contributor

Primarily manages the Key Vault resource.

It does not automatically mean the identity can retrieve secret values when Azure RBAC data-plane authorisation is used.

However, the role may still provide control over sensitive vault configuration.

Identity-Based Access

Azure Key Vault may be accessed by:

Human users
Microsoft Entra groups
Service principals
Managed identities
Federated workload identities

Each identity should have only the permissions required for its business function.

Managed Identities

Managed identities allow Azure workloads to authenticate without storing traditional credentials in application code.

Common consumers include:

Virtual Machines
Azure Functions
App Services
Logic Apps
Automation Accounts
Kubernetes workloads

Example:

Azure Function
        ↓
Managed identity
        ↓
Key Vault Secrets User
        ↓
Application secret

Managed identities reduce the need for embedded credentials but do not eliminate the risk of excessive permissions.

Managed-Identity Attack Path

Compromised workload
        ↓
Access to managed identity context
        ↓
Key Vault permission
        ↓
Secret retrieval
        ↓
Access to connected service

The impact depends on:

The workload that controls the identity
The scope of the Key Vault role
The sensitivity of accessible secrets
The security of connected services

User-Assigned Managed Identities

A user-assigned managed identity exists independently and may be attached to multiple workloads.

Assessment questions include:

Which resources use the identity?
Who can attach the identity to additional resources?
What Key Vault permissions does it hold?
Is the same identity shared between development and production?
Is access regularly reviewed?

A broadly reusable identity with production-vault access may create a cross-environment attack path.

Service Principals

Applications may authenticate to Key Vault through service principals.

Potential risks include:

Long-lived client secrets
Unrotated certificates
Credentials embedded in code
Broad permissions across multiple vaults
Shared application identities
Unused service principals
Insecure application ownership

Where possible, organisations should reduce reliance on long-lived secrets and use managed or federated identities.

Secret Metadata

Metadata may include:

Object name
Version
Enabled state
Creation time
Update time
Expiration date
Content type
Tags

Secret names such as the following may reveal useful reconnaissance information:

prod-database-admin-password
payment-api-key
backup-storage-token
global-application-secret

Metadata access should therefore be assessed and protected appropriately.

Secret Expiration

Secrets should have a defined lifecycle.

Assessment questions include:

Do secrets have expiration dates?
Are expired secrets disabled?
Are non-expiring secrets justified?
Are owners notified before expiration?
Are applications able to consume rotated secrets?
Is emergency rotation documented?

A credential that never expires may provide long-term unauthorised access if compromised.

Secret Rotation

A mature rotation process should define:

Secret owner
Rotation frequency
Dependent applications
Testing procedure
Rollback process
Notification requirements
Emergency rotation process
Evidence and audit requirements

A written policy is not enough.

The organisation should be able to rotate a secret without causing unacceptable business disruption.

Old Secret Versions

Older secret versions may remain accessible.

Potential issues include:

Previous credentials still working
Old API tokens remaining active
Credentials belonging to retired systems
Historical versions accessible to broad identities
Applications using an outdated version

Do not test old credentials against connected services unless specifically authorised.

Key Permissions

Sensitive key operations may include:

Encrypt
Decrypt
Sign
Verify
Wrap key
Unwrap key
Create
Import
Delete
Recover
Purge
Rotate

The risk depends on the business purpose of the key.

For example:

Permission to decrypt
        ↓
Access to protected application data

or:

Permission to sign
        ↓
Ability to produce trusted signed content

Certificate Security

Certificate assessment should review:

Expiration
Renewal
Issuer
Private-key handling
Exportability
Access permissions
Deployment process
Revocation
Ownership

Exportable Certificate Risk

Certificate permission
        ↓
Private key exported
        ↓
Service identity copied
        ↓
Persistent impersonation

Production private keys must not be exported during testing without explicit written authorisation.

Key Vault Networking

Key Vault access may be controlled through:

Public network access
Firewall rules
Approved IP ranges
Virtual Network rules
Private endpoints
Trusted Microsoft-service exceptions

Network restrictions provide defence in depth but do not replace identity permissions.

Public Network Access

A Key Vault may expose a public endpoint while still requiring authentication.

Assessment questions include:

Is public access required?
Is access allowed from all networks?
Are approved administrative ranges configured?
Can workloads use private connectivity?
Are public access attempts monitored?

Public reachability is not automatically a vulnerability, but it increases the accessible attack surface.

Key Vault Firewall

Review:

Default network action
Allowed IP ranges
Virtual Network rules
Trusted-service bypass
Private endpoint connections
Public access state

Weaknesses may include:

All networks allowed
Excessively broad IP ranges
Undocumented exceptions
Public access remaining enabled after private endpoint deployment

Private Endpoints

A private endpoint assigns a private IP address to the Key Vault service.

Review:

Connected vault
Subnet
Private IP
Approval status
Private DNS configuration
Public-network state
Network access from connected environments

A private endpoint does not automatically disable public access.

Both controls must be assessed.

Private DNS

Private connectivity normally depends on correct DNS resolution.

Review:

Private DNS zones
VNet links
DNS records
Custom DNS forwarding
Split-horizon behaviour
Resolution from connected networks

Poor DNS configuration may cause applications to use the public endpoint unexpectedly.

Trusted Microsoft Services

Some Azure services may be allowed to bypass network restrictions.

Assessment questions include:

Which service requires the exception?
Is the requirement documented?
Which identity authenticates?
Is access narrowly scoped?
Is the activity logged?
Can the exception be reduced?

Soft Delete

Soft delete allows deleted vaults and objects to remain recoverable for a retention period.

Protected objects may include:

Secrets
Keys
Certificates
Vault resources

Review:

Retention period
Recovery permissions
Operational recovery procedures
Monitoring of deletion events

Purge Protection

Purge protection prevents permanently deleting protected objects before the retention period ends.

This reduces the risk of:

Malicious destruction
Ransomware
Accidental deletion
Insider abuse
Permanent loss of encryption keys

Recovery Attack Scenario

Privileged identity compromised
        ↓
Encryption key deleted
        ↓
Purge protection missing
        ↓
Key permanently destroyed
        ↓
Dependent service unavailable

Security and availability must be considered together.

Logging and Monitoring

Useful Key Vault telemetry may include:

Azure Activity Logs
Key Vault audit events
Microsoft Entra sign-in logs
Diagnostic settings
Log Analytics
Microsoft Sentinel
Microsoft Defender for Cloud

Important monitored actions include:

Secret retrieval
Secret modification
Secret deletion
Key usage
Certificate export
RBAC changes
Access-policy changes
Firewall modifications
Private-endpoint changes
Recovery and purge operations

Diagnostic Settings

Key Vault logs may be sent to:

Log Analytics
Storage Accounts
Event Hubs
Supported security platforms

Assessment questions include:

Are diagnostics enabled?
Are logs centralised?
Is retention sufficient?
Are sensitive activities alerted?
Can vault administrators modify logging?
Are the log destinations themselves protected?
Does the security team review the events?

Common Key Vault Misconfigurations

Excessive Secret Access

Large operations group
        ↓
Key Vault Secrets User
        ↓
Access to production credentials

Broad Subscription-Level Role

Key Vault Administrator
assigned at subscription scope
        ↓
Access inherited by multiple vaults
        ↓
Large credential exposure

Privileged Managed Identity

Compromised application
        ↓
Managed identity
        ↓
Production Key Vault
        ↓
Database secret
        ↓
Production database access

Access-Policy Modification

Identity controls access policies
        ↓
Identity grants itself secret access
        ↓
Protected value retrieved

Changing permissions requires explicit testing approval.

Public Access with Weak Network Restrictions

Public endpoint enabled
        +
All networks permitted
        ↓
Exposed credentials usable remotely

Missing Purge Protection

Privileged access
        ↓
Key deleted and purged
        ↓
Permanent loss
        ↓
Business disruption

Non-Expiring Secrets

Long-lived credential
        ↓
Credential exposed
        ↓
Persistent unauthorised access

Exportable Certificate

Certificate exported
        ↓
Private key obtained
        ↓
Service impersonation

Azure Key Vault Assessment Methodology

Stage 1 — Confirm Scope

Record:

Tenant ID
Subscription ID
Authorised resource groups
Authorised Key Vaults
Permitted identities
Permitted object types
Secret-value restrictions
Prohibited operations

Stage 2 — Inventory Key Vaults

Document:

Vault name
Region
Resource group
Authorisation model
Public-network state
Private endpoints
Soft-delete configuration
Purge-protection configuration

Stage 3 — Review Management Access

Identify:

Owners
Contributors
User Access Administrators
Key Vault Contributors
Custom roles
Identities that can change networking
Identities that can change authorisation

Stage 4 — Review Data-Plane Access

Identify access to:

Secrets
Keys
Certificates
Recovery operations
Purge operations

Determine whether access comes from:

Azure RBAC
Access policies
Group membership
Managed identity
Service principal

Stage 5 — Review Object Metadata

Where authorised, review:

Object names
Versions
Enabled status
Creation dates
Update dates
Expiration dates
Rotation settings

Avoid retrieving production values unless required and authorised.

Stage 6 — Review Network Controls

Assess:

Public access
Firewall default action
IP rules
Virtual Network rules
Private endpoints
Private DNS
Trusted-service exceptions

Stage 7 — Review Recovery Protections

Assess:

Soft delete
Retention
Purge protection
Recovery permissions
Documented recovery procedures

Stage 8 — Review Logging

Assess:

Diagnostic settings
Log destinations
Retention
Alerting
Security-operations ownership

Stage 9 — Build Attack Paths

Compromised workload
        ↓
Managed identity
        ↓
Key Vault role
        ↓
Secret
        ↓
Connected business service

Stage 10 — Validate Safely

Prefer:

Configuration review
Role analysis
Metadata enumeration
Dedicated test objects
Read-only access
Minimal evidence
Reversible actions

Authorised Azure CLI Enumeration

Confirm the current context:

az account show --output table

List authorised Key Vaults:

az keyvault list --output table

Display vault configuration:

az keyvault show \
  --resource-group "<authorised-resource-group>" \
  --name "<authorised-key-vault>"

Review network rules:

az keyvault network-rule list \
  --resource-group "<authorised-resource-group>" \
  --name "<authorised-key-vault>"

Capture the vault resource ID:

KEYVAULT_ID=$(az keyvault show \
  --resource-group "<authorised-resource-group>" \
  --name "<authorised-key-vault>" \
  --query id \
  --output tsv)

List role assignments scoped to the vault:

az role assignment list \
  --scope "$KEYVAULT_ID" \
  --include-inherited \
  --output table

Review legacy access policies where applicable:

az keyvault show \
  --resource-group "<authorised-resource-group>" \
  --name "<authorised-key-vault>" \
  --query properties.accessPolicies

List secret metadata where authorised:

az keyvault secret list \
  --vault-name "<authorised-key-vault>" \
  --output table

List key metadata:

az keyvault key list \
  --vault-name "<authorised-key-vault>" \
  --output table

List certificate metadata:

az keyvault certificate list \
  --vault-name "<authorised-key-vault>" \
  --output table

Review the attributes of an authorised test secret:

az keyvault secret show \
  --vault-name "<authorised-key-vault>" \
  --name "<authorised-test-secret>" \
  --query attributes

Do not display production secret values unless explicitly authorised.

Authorised Azure PowerShell Enumeration

List Key Vaults:

Get-AzKeyVault

Display a specific vault:

Get-AzKeyVault `
    -ResourceGroupName "<authorised-resource-group>" `
    -VaultName "<authorised-key-vault>"

List vault role assignments:

Get-AzRoleAssignment `
    -Scope "<authorised-key-vault-resource-id>"

List secret metadata:

Get-AzKeyVaultSecret `
    -VaultName "<authorised-key-vault>"

List key metadata:

Get-AzKeyVaultKey `
    -VaultName "<authorised-key-vault>"

List certificate metadata:

Get-AzKeyVaultCertificate `
    -VaultName "<authorised-key-vault>"

Do not convert protected secret values into plain text unless the assessment explicitly requires and authorises it.

Safe Secret Validation

Use the least sensitive validation method.

Confirm the authorised identity.
Confirm the assigned role or access policy.
Review the permitted operations.
Review metadata.
Use a dedicated test secret.
Retrieve only the test value where required.
Avoid production secrets.
Redact evidence.
Remove approved test artefacts.
Report unexpected access immediately.

Safe Key Validation

Where authorised, validation may include:

Reviewing key metadata
Confirming permitted operations
Using an approved test key
Performing a controlled signing or encryption operation
Recording non-sensitive output

Do not:

Decrypt production information
Sign unauthorised content
Modify production keys
Disable keys
Rotate keys
Delete keys
Purge keys

without explicit approval.

Safe Certificate Validation

Certificate validation may include:

Reviewing certificate metadata
Checking expiration
Reviewing issuer configuration
Confirming export settings
Using an authorised test certificate

Do not export production private keys without explicit written approval.

Actions Requiring Explicit Approval

Do not perform the following without specific authorisation:

Retrieve production secret values
Create or modify production secrets
Delete, recover, or purge objects
Rotate or disable keys
Decrypt production information
Sign production content
Export certificate private keys
Modify access policies
Create role assignments
Change the authorisation model
Modify firewall rules
Change public-network access
Create or remove private endpoints
Change diagnostic settings
Delete a Key Vault

Evidence Collection

For each finding, record:

Subscription ID
Resource group
Vault name
Vault resource ID
Region
Authorisation model
Identity
Identity type
Role or access policy
Assignment scope
Object type
Permitted operation
Network configuration
Soft-delete status
Purge-protection status
Logging status
Validation method
Business impact
Recommended remediation

Never include:

Secret values
Private keys
Access tokens
Passwords
Complete connection strings
Unredacted certificate material

Example Finding

Finding Title

Development Managed Identity Can Access Production Key Vault Secrets

Observation

A user-assigned managed identity used by a development application has the Key Vault Secrets User role over a production Key Vault.

The identity may be attached to multiple Azure workloads.

Potential Attack Path

Compromised development application
        ↓
User-assigned managed identity
        ↓
Production Key Vault
        ↓
Database and application secrets
        ↓
Production-service access

Business Impact

Compromise of a lower-trust development workload could expose production credentials and provide access to sensitive business services.

Recommendation

Separate production and development identities.
Remove production-vault access from the development identity.
Restrict permissions to the minimum required.
Review every resource using the identity.
Restrict who can attach the user-assigned identity.
Rotate potentially exposed secrets.
Monitor secret retrieval events.
Apply stronger environment separation.

Risk Rating Considerations

The severity of a Key Vault finding depends on:

Object sensitivity
Permission type
Identity privilege
Assignment scope
Secret usability
Key purpose
Certificate exportability
Network exposure
Authentication strength
Monitoring coverage
Recovery protections
Connected services
Business impact

Metadata access to an empty training vault may be low risk.

Access to production database credentials may be critical.

Remediation Principles

Common recommendations include:

Apply least privilege.
Use narrow assignment scopes.
Separate management-plane and data-plane administration.
Remove unused assignments and access policies.
Prefer managed or federated identities.
Avoid long-lived application secrets.
Separate production and non-production identities.
Restrict public-network access.
Use private endpoints for sensitive workloads.
Review trusted-service exceptions.
Enable soft delete.
Enable purge protection where required.
Configure expiration for secrets, keys, and certificates.
Implement automated rotation.
Monitor expiring certificates.
Enable diagnostic logging.
Alert on sensitive operations.
Protect log destinations.
Review historical object versions.
Test recovery procedures.
Assign ownership to every protected object.

Evidence and Portfolio Outcome

Create an Azure Key Vault Security Assessment containing:

Vault Inventory

Document:

Vault name
Resource group
Region
Business purpose
Connected workloads
Authorisation model

Access Review

Document:

Users
Groups
Service principals
Managed identities
Azure roles
Access policies
Assignment scopes

Object Governance Review

Document metadata for:

Secrets
Keys
Certificates
Expiration
Rotation
Versions
Enabled state

Do not include sensitive values.

Network Review

Document:

Public-network access
Firewall rules
Private endpoints
Private DNS
Trusted-service exceptions

Recovery Review

Document:

Soft delete
Retention
Purge protection
Recovery permissions
Recovery procedures

Monitoring Review

Document:

Diagnostic settings
Log destination
Retention
Alerting
Security-operations ownership

Attack-Path Diagram

Create one safe, hypothetical attack path.

Compromised workload
  ↓
Managed identity
  ↓
Key Vault
  ↓
Application secret
  ↓
Production service

Recommendations

Provide prioritised remediation guidance based on business impact.

Key Takeaways

Azure Key Vault protects secrets, keys, and certificates.
Management-plane and data-plane permissions must be assessed separately.
Azure RBAC and legacy access policies use different authorisation models.
Secret metadata can reveal valuable architectural information.
Managed identities require least-privilege permissions.
Key usage can be sensitive even when a key cannot be exported.
Exportable certificates may enable long-term impersonation.
Private endpoints do not automatically disable public access.
Soft delete and purge protection support recovery.
Sensitive object values should not be retrieved unless explicitly authorised.
Key Vault findings should be connected to the workloads and services that use them.

Knowledge Check

What objects can Azure Key Vault store?
What is the difference between management-plane and data-plane access?
How does Azure RBAC differ from a Key Vault access policy?
Why can secret metadata create security risk?
How can a managed identity become part of a Key Vault attack path?
Why can permission to use a cryptographic key be sensitive?
What risk is associated with exportable certificates?
What is the purpose of soft delete?
What additional protection does purge protection provide?
Why does a private endpoint not automatically remove public access?
Why should development and production workloads use separate identities?
What is the safest approach to validating secret access?

Next Lesson

➡️ Lesson 08 — Azure Functions

In the next lesson, you will examine Azure Functions architecture, triggers, bindings, authentication, application settings, managed identities, deployment methods, network exposure, monitoring, and authorised serverless attack paths.