Configuring Key Rotation and Backup

Complete the full lesson to earn 25 points — 50 with Pro

Work through each section, then tap “Mark as Complete” on the last one.

Section 1 of 8

✦ Skip the page breaks, the wait, and see fewer ads — read each lesson on a single page with Pro

Configuring Key Rotation and Backup in Microsoft Defender for Cloud and Sentinel

Introduction: The Foundation of Cloud Security Governance

In the modern digital landscape, the security of your cloud infrastructure relies heavily on two fundamental pillars: the integrity of your cryptographic keys and the availability of your data. When we talk about cloud governance, we are essentially defining the guardrails that keep an organization’s digital assets safe from unauthorized access and catastrophic loss. Microsoft Defender for Cloud and Microsoft Sentinel serve as the central nervous system for these governance efforts, providing the visibility and automation required to enforce strict security policies across complex, multi-cloud environments.

Key rotation and data backup are not merely "maintenance tasks" that IT departments perform when they have a spare moment; they are critical security controls. If a cryptographic key is compromised and remains in use, an attacker can decrypt sensitive data at will, often without triggering traditional intrusion detection systems. Similarly, without a verified, immutable backup strategy, an organization is entirely vulnerable to ransomware attacks, accidental data deletion, or configuration errors that could wipe out production environments.

This lesson explores how to implement automated key rotation and robust backup governance using the Microsoft ecosystem. We will move beyond the basic checkboxes and look at how to architect these solutions so they scale with your business. Whether you are managing a small startup or a large enterprise, the principles of least privilege, automated remediation, and policy-as-code remain the same. By the end of this module, you will understand how to integrate these practices into your daily operations to ensure your cloud footprint is not only functional but resilient against modern threats.

Part 1: The Critical Role of Cryptographic Key Rotation

Cryptographic keys are the "master passwords" of your cloud infrastructure. They secure everything from virtual machine disks and database records to application secrets and identity tokens. Over time, the risk of a key being intercepted, leaked, or misused increases. This is where key rotation comes into play.

Key rotation is the process of replacing an existing cryptographic key with a new one. By rotating keys periodically, you limit the amount of data that can be decrypted if a specific key is compromised. If a key is used for a year and then leaked, the attacker has access to a year's worth of data. If you rotate that key every 30 days, the potential blast radius of a breach is reduced by over 90 percent.

Understanding Key Vault Integration

Microsoft Azure Key Vault is the primary service for managing these keys. Defender for Cloud monitors these vaults to ensure that keys are not only present but are also being rotated according to your organization's compliance standards. The governance aspect involves setting up Azure Policy definitions that automatically audit or deny the creation of vaults that do not have automated rotation enabled.

Callout: Key Rotation vs. Key Revocation It is important to distinguish between these two concepts. Key rotation is a proactive security measure that involves generating a new version of a key while keeping the old one accessible for decrypting existing data. Key revocation is a reactive measure used when a key is known or suspected to be compromised, effectively rendering that key unusable immediately to prevent further unauthorized access.

Implementing Automated Rotation

To implement automated rotation, you typically use Azure Key Vault’s built-in automation features, often triggered by Event Grid. When a key is nearing its expiration date, an event is fired, triggering an Azure Function that generates a new key version and updates the application references.

Best Practices for Key Rotation

Define a Rotation Schedule: Most compliance frameworks, such as SOC2 or PCI-DSS, require rotation at least every 90 days. Align your technical settings with these audit requirements.
Version Control: Always ensure that your applications are designed to fetch the "latest" version of a key rather than hardcoding a specific version string.
Automated Testing: Before enforcing a rotation policy, test the rotation process in a staging environment to ensure that your applications handle the key update without service interruption.
Audit Logging: Enable diagnostic logging on your Key Vaults so that you have a clear trail of who accessed the keys and when rotation events occurred.

Part 2: Governance Strategies for Cloud Backups

Data backup is the ultimate insurance policy. In the context of cloud governance, backup is not just about having a copy of the data; it is about ensuring that the copy is consistent, recoverable, and protected from the same threats that might target your primary environment. Microsoft Defender for Cloud provides the "Backup and Recovery" recommendation suite, which tracks whether your Azure resources are protected by Azure Backup or other integrated solutions.

The Immutable Backup Requirement

Modern ransomware attacks specifically target backup files. If an attacker gains administrative access, their first move is often to delete your backups, leaving you with no choice but to pay the ransom. This is why "Immutable Backups" are now an industry standard. An immutable backup is a copy of your data that cannot be modified or deleted for a set period, even by an administrator.

Configuring Backup Policies via Policy-as-Code

Rather than manually configuring backups for every new virtual machine or database, you should use Azure Policy to enforce backup requirements. By applying a policy to your subscription or resource group, you ensure that any new resource created without an associated backup policy is automatically flagged or blocked.

Step-by-Step: Enabling Backup Governance

Define the Scope: Decide whether your backup policy applies to the entire subscription or specific resource groups.
Select the Policy: Use the built-in policy named "Configure backup on virtual machines."
Assignment: Assign this policy to your target scope.
Remediation: Enable "Remediation Tasks" within the policy assignment. This allows Azure to automatically apply the backup configuration to non-compliant resources.
Monitoring: Use the Defender for Cloud "Regulatory Compliance" dashboard to track the health of your backup posture.

Note: Always perform "Restore Drills" at least once per quarter. A backup that has never been tested for restoration is essentially a backup that does not exist.

Part 4: Practical Implementation Code Snippets

To truly govern these services, you need to be comfortable using infrastructure-as-code tools like Bicep or Terraform. Below is an example of a Bicep snippet that ensures a Key Vault is configured with a specific rotation policy.

// Bicep snippet for configuring Key Vault rotation
resource keyVault 'Microsoft.KeyVault/vaults@2023-02-01' = {
  name: 'mySecureVault'
  location: resourceGroup().location
  properties: {
    sku: { family: 'A', name: 'standard' }
    tenantId: subscription().tenantId
    accessPolicies: []
    enableSoftDelete: true
    softDeleteRetentionInDays: 90
    // Ensure the key is rotated every 90 days
    keyRotationPolicy: {
      attributes: {
        expiryTime: 'P90D'
      }
    }
  }
}

This code snippet demonstrates how to define the lifecycle of a key at the time of creation. By embedding this into your deployment pipelines, you ensure that security is "baked in" rather than "bolted on."

Monitoring Compliance with KQL

Microsoft Sentinel uses Kusto Query Language (KQL) to hunt for security issues. If you want to check for virtual machines that are not currently backed up, you can use a query similar to this:

// KQL query to identify non-compliant VMs
SecurityRecommendations
| where RecommendationName contains "Backup"
| where Status == "Unhealthy"
| project TimeGenerated, ResourceName, RecommendationName, RemediationSteps

This query provides a clean list of resources that require attention, allowing your security team to prioritize their efforts based on the actual risk to the environment.

Part 5: Comparing Governance Approaches

When deciding how to manage keys and backups, you generally have two paths: manual management or policy-driven automation. The following table compares these approaches across several key metrics.

Feature	Manual Management	Policy-Driven Automation
Consistency	Low (prone to human error)	High (enforced by code)
Scalability	Poor (does not grow with env)	Excellent (scales automatically)
Auditability	Difficult (requires manual logs)	Easy (built-in reporting)
Speed of Response	Slow (depends on human action)	Near-Instant (automated)
Cost	High (labor-intensive)	Low (efficiency through code)

Part 6: Best Practices for Enterprise Governance

To maintain a secure posture, you must treat your governance policies as a living document. Technology changes, and so do the threats targeting your infrastructure.

Establish a "Security Baseline"

Every organization should have a defined security baseline. This baseline outlines the minimum required settings for every resource in your environment. For example, your baseline might state:

All storage accounts must have "soft delete" enabled.
All keys must be rotated every 90 days.
All VMs must have a backup policy linked to a Recovery Services Vault.

Periodic Audits

Even with automated tools, it is vital to conduct manual audits. Automated tools can sometimes have "false negatives" where a resource appears compliant but is configured incorrectly in a way the policy doesn't detect. A quarterly review of your Defender for Cloud "Compliance Score" is a non-negotiable task for any cloud administrator.

The Principle of Least Privilege

Apply this principle aggressively to your Key Vaults. Only the identities (service principals or users) that absolutely need to perform cryptographic operations should have access to those keys. Use Azure RBAC to grant "Key Vault Crypto Service Encryption User" roles rather than broad administrative access.