Azure Policy Governance and Key Vault Protection

Create, assign, and interpret policies and initiatives in Azure Policy

Azure Policy is a governance service that enforces rules on Azure resources. A policy definition specifies a condition (for example, "resource must be in a specific region") and an effect (such as deny, audit, or append). Multiple policy definitions can be grouped into an initiative (also called a policy set) to enforce a broader compliance goal, like "ensure all resources meet security baseline." To apply a policy or initiative, you create an assignment at a management group, subscription, or resource group scope. The assignment evaluates existing resources and applies the effect to new resources during creation or update. When a resource violates a policy, Azure Policy can block the operation (deny), log the violation (audit), or add missing tags (append). You interpret compliance by viewing the policy's compliance state on the Azure portal or via Azure Resource Graph, which shows which resources are compliant, non-compliant, or excluded. The relationship between definition, initiative, and assignment is hierarchical: definitions are reusable, initiatives combine them, and assignments tie them to a scope.

Configure Azure Key Vault network settings

Azure Key Vault stores secrets, keys, and certificates. To restrict network access, you configure firewalls and virtual networks. By default, Key Vault accepts traffic from all networks. You can enable a firewall that blocks all traffic except from specified IP address ranges or from selected virtual networks. When you allow a virtual network, you must also enable the Microsoft.KeyVault service endpoint on that subnet. This ensures that traffic from the subnet stays within the Azure backbone and does not traverse the public internet. You can also choose to allow trusted Microsoft services (such as Azure Resource Manager or Azure Backup) to bypass the firewall. The network settings apply at the vault level; each vault has its own firewall configuration. If a client cannot reach the vault, the request is denied before any authentication or authorization check occurs, so network rules act as the first gate.

Configure access to Key Vault, including vault access policies and Azure Role Based Access Control

Access to a Key Vault is controlled by two separate authorization models: vault access policies and Azure RBAC. Vault access policies are the older model and grant permissions directly to users, groups, or service principals for operations like get, list, set, delete on secrets, keys, and certificates. You can assign up to 1024 access policy entries per vault. Azure RBAC is the newer model and uses built-in roles such as Key Vault Secrets User or Key Vault Administrator to control access at the vault scope. RBAC is preferred for centralized management because it integrates with Azure's broader role-based system. You can choose one model or use both, but they are independent: a principal must have permission through at least one model to perform an operation. When configuring access, consider the principle of least privilege—grant only the specific permissions needed (for example, read-only for an application that retrieves secrets, not full control). The decision between models depends on whether you want granular per-vault control (vault access policies) or unified RBAC across all Azure resources.

Manage certificates, secrets, and keys

Key Vault stores three types of objects: secrets (such as connection strings or passwords), keys (cryptographic keys used for encryption or signing), and certificates (X.509 certificates managed by Key Vault). Secrets are simple byte strings; you can set an expiration date and enable automatic rotation. Keys are stored in a hardware security module (HSM) backed by FIPS 140-2 Level 2 or Level 3, depending on the vault SKU. You can create keys, import existing keys, and perform cryptographic operations without the key leaving the HSM. Certificates in Key Vault can be self-signed or issued by a certificate authority (CA). Key Vault can handle the full lifecycle: creation, renewal, and revocation. Each object has a unique identifier (URL) and can have versions. Managing these objects involves setting access policies, configuring expiration dates, and monitoring for upcoming expirations via alerts. The relationship between secrets, keys, and certificates is that they are all stored in the same vault but have different operations and permissions.

Configure key rotation

Key rotation is the process of replacing a cryptographic key with a new one to limit the impact of a compromised key. In Azure Key Vault, you can configure automatic rotation for keys and secrets. For keys, you set a rotation policy that specifies a rotation period (for example, every 90 days) and optionally a time offset before expiration to trigger rotation. Key Vault will create a new key version automatically and mark the old version as disabled or expired based on the policy. For secrets, you can enable automatic rotation by linking the secret to a Key Vault certificate that has a rotation policy. You can also rotate keys manually by creating a new version and updating applications to use the new version identifier. The key rotation lifecycle includes: current active version, previous versions (which may be retained for decryption of older data), and expired versions (which are no longer usable). When configuring rotation, consider the applications that use the key: they must be able to handle version changes, often by referencing the key by name rather than a specific version.

Perform backup and recovery of certificates, secrets, and keys

Key Vault provides backup and restore operations for secrets, keys, and certificates. A backup downloads an encrypted blob that contains the object and its metadata (including all versions). You can store this blob in Azure Storage or another location. To restore, you upload the blob to the same or a different Key Vault in the same Azure region and subscription. The restore operation recreates the object with its original name and versions. Backup is useful for disaster recovery or when you need to move objects between vaults. However, backup does not include the vault's access policies or network settings—those must be configured separately. Note that backup and restore are not supported for Key Vault Managed HSM; that service uses a different disaster recovery mechanism. The relationship: backup creates a portable copy of the object, and restore recreates it in a target vault, preserving the object's unique identifier and version history.

Implement security controls to protect backups

Backups of Key Vault objects (secrets, keys, certificates) must themselves be protected. The backup blob is encrypted at rest by Azure, but you should store it in a secure location such as an Azure Storage account with restricted access. Use Azure RBAC or storage account keys to control who can read or delete the backup files. Additionally, enable soft delete on the storage account to recover accidentally deleted backups. For extra protection, you can encrypt the backup blob with a customer-managed key before storing it. The backup blob contains sensitive material (the actual secret values or key material), so treat it with the same security as the original object. You should also implement a retention policy: delete old backups when they are no longer needed to reduce exposure. The control flow: backup is created from Key Vault, stored in a protected storage container, and restored only when needed, with access logged via Azure Monitor.

Implement security controls for asset management

Asset management in Azure involves tracking and governing all resources (virtual machines, storage accounts, databases, etc.) to ensure they meet security and compliance requirements. Key controls include using Azure Policy to enforce tagging (e.g., "Environment" or "Owner") and to deny creation of resources without required tags. Use Azure Resource Graph to query and inventory resources across subscriptions. Implement Azure Blueprints to define a repeatable set of policies, RBAC roles, and resource templates that enforce a baseline for new subscriptions. For cost and security, use Azure Management Groups to organize subscriptions hierarchically and apply policies at the group level. Additionally, enable Azure Defender for Cloud (formerly Security Center) to assess resource configurations and provide recommendations. The relationships: management groups contain subscriptions, subscriptions contain resource groups, and resource groups contain resources. Policies applied at a higher scope cascade down, so a single policy at the management group level can govern all subscriptions underneath. Asset management ensures that every resource is accounted for, properly tagged, and compliant with organizational standards.