Intro.- Defense in depth Azure Key Vault.

Manage certificates in Azure Key Vault

Azure Key Vault supports two certificate issuance models.

Self-signed certificates are generated by the vault itself-Key Vault acts as the CA. Only systems that explicitly import it as a trusted root trusts the certificate. Appropriate for internal service-to-service communication in controlled environments and nonproduction testing. They're inappropriate for public-facing endpoints where browsers, operating systems, and Transport Layer Security (TLS) clients validate against a trusted CA chain.

CA-integrated certificates are issued by a trusted certificate authority with a public root in browser trust stores. Azure Key Vault has native partnerships with DigiCert and GlobalSign for automated, end-to-end certificate lifecycle management.

Source: learn.microsoft.com

Configure an integrated CA issuer

Before Key Vault can issue or renew certificates through DigiCert or GlobalSign, you configure an issuer object in the vault. This object stores the CA account credentials and contract details:

Source: learn.microsoft.com

1. In the Azure portal, navigate to your key vault and select objets > Certificates > Certificates Authorities.
2. Select Add and choose the provider (DigiCert or GlobalSign).
3. Enter your CA account ID, API key or password, and any organization details required by the provider.
4. Save the issuer. The vault now has a named issuer object (for example, contoso-digicert-issuer) that certificate policies can reference.

Configure lifetime actions for autorenewal

A certificate policy in Key Vault defines both what the certificate looks like and the certificate management over time.

You configure the trigger as one of:

1. A percentage of lifetime remaining (for example, autorenew when 80% of the certificate's lifetime elapses). Percent lifetime is relative and works well for certificates with varying validity periods.
2. Days before expiry (for example, autorenew 30 days before expiry). A set number of days is absolute and predictable.

Certificate contacts

Are email addresses or distribution lists registered at the vault level—the same contacts apply to every certificate in the vault, not to individual certificates. They're notified when:

• A certificate is nearing expiry.
• An autorenewal attempt succeeded.
• An autorenewal attempt failed.

Certificate exportability

A certificate's exportability is controlled by the exportable key property in its certificate policy. When set to nonexportable, the private key lives in the vault and is never included in the secret representation that callers retrieve.

Exportable certificates allow the private key to be retrieved as a PFX or PEM file, which is required for workloads that need the certificate injected into a virtual machine, container, or platform that can't natively call the Key Vault API.

Key Vault stores the private key as an addressable secret with the same name as the certificate. The Key Vault Secrets User role grants this access; the Key Vault Certificate User role grants access to the full certificate including its private key portion.

Enabling Key Vault resource logs

Diagnostic logging for Key Vault isn't enabled by default. I'll enable it through the Diagnostic settings screen in the Azure portal.

1. Navigate to your key vault and select Diagnostic settings under the Monitoring section.
2. Select Add diagnostic setting.
3. Name the setting keyvault-audit-to-law.
4. Under Category groups, select Audit (the AuditEvent category). This captures all control plane and data plane operations on the vault.

5. Under Destination details, choose one or more destinations:

   • Send to log Analytics Workspace - recommended for interactive query and alert creation.
   • Archive to Storage account - for long-term archive retention (useful for compliance requirements with multi-year log retention).
   • Stream to an event hub - for streaming log data into a Security Information and Event Management (SIEM) such as Microsoft Sentinel.

6. Select Save.

Identifying key fields in AuditEvent logs

Every AuditEvent log record captures the context needed for security investigation. The most important fields for a security analyst are:

Log-based alert rules

Storing logs isn't enough, I need to act on them. Create KQL-based alert rules in Log Analytics for high-severity vault events that should never happen silently.

Alerts I should configure immediately:

• Secret deletion (operationName == "SecretDelete" or operationName == "SecretPurge"): Deleted secrets with purge protection disabled are recoverable for a limited time, but every deletion warrants review. Purge operations are irreversible.
• Access failures (resultType == "Failure"): A service principal repeatedly failing to access a secret can indicate a misconfigured application. Or it could be a revoked certificate, or an attacker testing credentials and running into access policy boundaries.
• Vault property changes (operationName == "VaultPatch"): Changes to vault properties including network rules, soft-delete settings, and access policy modifications on legacy policy-based vaults are logged with this operation. For vaults using Azure RBAC, role assignment changes are recorded in the Azure Activity Log under Microsoft.Authorization/roleAssignments/write and Microsoft.Authorization/roleAssignments/delete, not in the Key Vault AuditEvent log. Alert on both sources for complete coverage.
• Key deletion (operationName == "KeyDelete" or operationName == "KeyPurge"): Deleted keys can break encryption for dependent services. Purged keys destroy access to encrypted data permanently.

Scan for exposed secrets using Defender Cloud Security Posture Management (CSPM)

Defender Cloud Security Posture Management (CSPM) secret scanning finds those misplaced credentials before attackers can exploit them.

Defender CSPM uses agentless scanning—there's no agent to deploy, no network connection required from the virtual machine (VM), and no performance issues on running workloads.

The scanning engine searches for a broad range of secret types:

• Azure SQL connection strings
• Storage account connection strings and SAS tokens
• SSH private keys
• Azure Cosmos DB credentials
• AWS access keys
• Microsoft Entra ID client secrets
• API tokens
• Personal access tokens for services like Azure DevOps and GitHub

SSH keys found on VM disks are verified against reachable machines in your environment. If a key can be used to authenticate to another VM, Defender for Cloud flags it as an exploitable lateral movement path not just a low-severity finding.

Cloud deployment resource scanning analyzes infrastructure-as-code (IaC) resources for exposed credentials in the same categories supported by machine scanning. This covers scenarios where a secret wasn't on a VM disk but in the template used to deploy infrastructure. This scanning type requires the Defender CSPM plan.

Scan code repositories for leaked secrets

Code repository scanning integrates with Azure DevOps and, through GitHub Advanced Security, with GitHub repositories to surface these exposures.

Review findings in Defender for Cloud

When the scanning engine finds secrets, recommendations are triggered under the Remediate vulnerabilities security control on the Defender for Cloud Recommendations page.

The key recommendations to monitor are:

• Machines should have secrets findings resolved - for Azure VMs
• EC2 instances should have secrets findings resolved - for AWS instances
• VM instances should have secrets findings resolved - for GCP instances

What is attack path analysis? Attack paths show the riskiest security issues in your environment so you can prioritize your remediation efforts on exploitable paths attackers might use.

one scans the environment for misplaced secrets; the other monitors the vault itself for suspicious access patterns.

Cloud's Cloud Workload Protection Platform (CWPP) - that provides threat detection specific to Key Vault. Being part of CWPP distinguishes it from CSPM plans, which focus on posture and exposure. CWPP plans like this one focus on active threats against running workloads.

Defender for Cloud was active on the subscription, but activating Defender for Cloud doesn't automatically activate every workload protection plan. Each plan must be explicitly enabled

Enabling Microsoft Defender for Key Vault

1. Microsoft Defender for Cloud > Environment settings
2. Select your subscription
3. Toggle on Microsoft Defender for Key Vault

Identifying what Defender for Key Vault monitors

Defender for Key Vault analyzes access patterns and logs from Azure Key Vault's control plane and data plane operations.

• Access from a suspicious IP address or TOR exit node : (KV.SuspiciousIPAccess, KV.TORAccess) Access to the vault originated from an IP address associated with a known threat actor, a scanning infrastructure, or The Onion Router (TOR) exit node.

• High volume of operations (KV.OperationVolumeAnomaly) The vault received an unusually high number of operations in a short time window.

• Suspicious policy change followed by secret queries (KV.PutGetAnomaly) A vault access policy was modified and then, within a short period, secrets were retrieved by an identity that typically doesn't access this vault.
• Unusual application usage (KV.AnomalousAccessOperation) The vault was accessed by an application identity not previously seen on this vault, or an application that changed its access behavior.

When Defender for Key Vault generates an alert, it surfaces in three places:

• The Security page of the specific Key Vault in the Azure portal
• The Workload protections dashboard in Defender for Cloud
• The Security alerts page in Defender for Cloud

Configure notifications under Defender for Cloud > Environment settings > Email notifications

Differences between Defender for Key Vault and CSPM scanning

Defender for Key Vault protects the vault from external threats. Defender CSPM scanning protects the environment from secrets exposed outside the vault.

When an alert fires, follow these four steps:

1. Identify the source - determine the identity that triggered the alert and is it recognized.
2. Respond to the immediate threat - restrict or remove access to stop further exposure.
3. Measure the impact - determine which secrets were accessed and for how long.
4. Take action - rotate affected credentials and notify downstream application owners.

Identify the source (Step 1)

Your first task is to determine whether the access was from a known identity in your Azure tenant.

Cross-reference the Object ID against my Microsoft Entra ID to find the identity:

• A user account
• A service principal
• A managed identity
• An AI agent workload identity.

If I recognize the identity, contact the application owner or the user directly and ask whether the activity was expected.

Respond to the immediate threat (Step 2)

The response action depends on where the suspicious access originated.

• Unrecognized IP address or The Onion Router (TOR) exit node: The vault firewall is your first control. Navigate to the Key Vault in the Azure portal, open Networking, and enable the firewall if it isn't already active.
• Unauthorized application or suspicious user: Navigate to Key Vault > Access control (IAM) and remove the role assignment for the suspicious identity.

Measure the issue (Step 3)

Open the Security page on the affected Key Vault and select the triggered alert. Review the list of secrets and keys that were accessed and their access timestamps. The list gives your SOC team the starting point they need: which vault, which objects, and when.

Take action (Step 4)

With the threat contained and the issue measured, complete the response.

• Rotate all affected credentials. For each secret, key, or certificate that the suspicious identity accessed: disable or delete the current version in Key Vault and create a new version.
• Notify downstream application owners. Identify each application that uses the rotated credentials.
• For service-to-service credentials: If a compromised service principal is the source, work with the identity team to rotate the client secret or certificate for that service principal, and audit other resources that service principal had access to.
• Monitor the vault after remediation. After rotating credentials and removing compromised access, watch the vault closely for 48 to 72 hours using the Security alerts page in Defender for Cloud.

Security recommendations : Microsoft Cloud Security Benchmark (MCSB)

• Key vaults should have soft delete enabled: Prevents accidental or malicious permanent deletion of vault objects
• Key vaults should have purge protection enabled: Prevents bypass of soft-delete retention.
• Diagnostic logs in Key Vault should be enabled: Ensures you have the audit data needed for Step 3 of every incident response.