Key Vault backup to Storage Account fails due to firewall restrictions after enabling network rules

We’re implementing automated Key Vault backups to a Storage Account, but the backup operation keeps failing with a 403 Forbidden error. The Storage Account has firewall rules enabled to allow access only from specific VNets and IP ranges for security compliance.

Backup command being used:


az keyvault backup start --hsm-name prod-keyvault --storage-account-name backupstorageacct --blob-container-name keyvault-backups

Error returned:


ERROR: (Forbidden) This request is not authorized to perform this operation.
Code: 403
Message: This request is not authorized to perform this operation using this permission.

The Key Vault has a managed identity assigned, and we’ve given it Storage Blob Data Contributor role on the storage account. However, the storage account firewall is set to “Enabled from selected networks” with our on-premises IP ranges and Azure VNets whitelisted. I suspect the managed identity requests are being blocked by the firewall, but I’m not sure how to properly configure the firewall rules to allow Key Vault’s managed identity through while maintaining our security posture. Any guidance on the correct firewall configuration for backup automation would be appreciated.

Here’s a comprehensive solution addressing all aspects of your Key Vault backup configuration:

Storage Account Firewall Rules: Your 403 error occurs because the Storage Account firewall blocks requests that don’t originate from your whitelisted networks. When Key Vault’s managed identity performs backup operations, requests come from Azure’s internal infrastructure, not from your specified networks.

Solution - Enable trusted Microsoft services:


az storage account update --name backupstorageacct --resource-group <rg> --bypass AzureServices

Or via Portal:

  1. Storage Account > Networking > Firewalls and virtual networks
  2. Under Exceptions, check “Allow trusted Microsoft services to access this storage account”
  3. Save changes

This allows Azure first-party services (Key Vault, Backup, Site Recovery) to bypass firewall rules while maintaining your network restrictions for other access.

Key Vault Managed Identity Configuration: You’ve correctly assigned Storage Blob Data Contributor role. Verify the assignment:


az role assignment list --assignee <keyvault-managed-identity-object-id> --scope /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/backupstorageacct

The managed identity needs these specific permissions:

  • Storage Blob Data Contributor (for write access)
  • Or custom role with: Microsoft.Storage/storageAccounts/blobServices/containers/write, Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey/action

Security Best Practices:

  1. Resource Instance Rules (Recommended): For tighter security, use resource instance rules instead of blanket trusted services:

az storage account network-rule add --account-name backupstorageacct --resource-id /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/prod-keyvault

This allows ONLY your specific Key Vault instance, not all Azure Key Vaults.

  1. Least Privilege Access: Create custom role for backup operations only:

{
  "Name": "Key Vault Backup Writer",
  "Actions": [
    "Microsoft.Storage/storageAccounts/blobServices/containers/write",
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write"
  ],
  "AssignableScopes": ["/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/backupstorageacct/blobServices/default/containers/keyvault-backups"]
}
  1. Container-Level Access: Restrict managed identity access to backup container only, not entire storage account.

Backup Automation Implementation:

Create Azure Automation runbook for scheduled backups:


# Pseudocode - Automated backup workflow:
1. Authenticate using managed identity
2. Verify storage account connectivity
3. Execute backup command with error handling
4. Log backup status to Log Analytics
5. Send notification on failure
6. Update backup inventory table

Schedule via Azure Automation:

  • Daily backups at 02:00 UTC
  • Weekly full backups on Sundays
  • Retention: 30 days for daily, 90 days for weekly

Lifecycle Management: Automate backup retention with lifecycle policy:


az storage account management-policy create --account-name backupstorageacct --policy @policy.json

policy.json:


{
  "rules": [{
    "name": "DeleteOldBackups",
    "type": "Lifecycle",
    "definition": {
      "filters": {"blobTypes": ["blockBlob"], "prefixMatch": ["keyvault-backups/"]},
      "actions": {"baseBlob": {"delete": {"daysAfterModificationGreaterThan": 30}}}
    }
  }]
}

Monitoring and Compliance:

  1. Backup Verification: Implement monitoring for backup failures:

az monitor metrics alert create --name KeyVaultBackupFailures --resource <keyvault-id> --condition "count backup_failed > 0" --window-size 1h
  1. Audit Logging: Enable diagnostic settings on both Key Vault and Storage Account:
  • Log backup operations to Log Analytics
  • Monitor for unauthorized access attempts
  • Track backup size trends
  1. Compliance Reporting: Query backup status:

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.KEYVAULT"
| where OperationName == "BackupComplete"
| summarize LastBackup=max(TimeGenerated) by Resource

Security Validation:

The “trusted Microsoft services” exception with RBAC provides:

  • Network-level protection (firewall blocks non-trusted services)
  • Identity-level protection (only your Key Vault’s managed identity has access)
  • Action-level protection (RBAC controls what operations are allowed)
  • Resource-level protection (resource instance rules limit to specific vault)

This multi-layered approach meets most compliance frameworks (PCI-DSS, HIPAA, ISO 27001).

Troubleshooting Steps:

If backup still fails after enabling trusted services:

  1. Verify managed identity is enabled on Key Vault
  2. Check RBAC role assignment scope (must be storage account or container level)
  3. Ensure storage account allows blob public access (can be disabled for security)
  4. Verify no Azure Policy blocking the operation
  5. Check for storage account locks preventing writes
  6. Review Key Vault diagnostic logs for detailed error messages

Final Configuration Checklist:

  • [ ] Enable Key Vault managed identity
  • [ ] Assign Storage Blob Data Contributor role to managed identity
  • [ ] Enable “Allow trusted Microsoft services” on storage firewall
  • [ ] OR configure resource instance rule for specific Key Vault
  • [ ] Create dedicated backup container with appropriate access tier (Cool)
  • [ ] Implement lifecycle management for automatic cleanup
  • [ ] Set up Azure Automation runbook for scheduled backups
  • [ ] Configure monitoring alerts for backup failures
  • [ ] Enable diagnostic logging on both services
  • [ ] Test backup and restore procedures
  • [ ] Document configuration for compliance audits

This configuration provides secure, automated Key Vault backups while maintaining strict firewall controls and meeting security compliance requirements.

For additional security, consider using resource instance rules instead of the blanket trusted services exception. With resource instance rules, you can specify exactly which Key Vault instance can access the storage account. This provides more granular control. The syntax is: `/subscriptions//resourcegroups//providers/Microsoft.KeyVault/vaults/

Good point on resource instance rules. Also remember to set up lifecycle management policies on your backup container to automatically delete old backups after your retention period. This prevents storage costs from growing indefinitely and helps with compliance by ensuring old encryption keys aren’t retained longer than necessary.

The “trusted services” exception only allows Microsoft services that have been explicitly granted RBAC permissions on your storage account. It doesn’t give blanket access to all Azure services. So in your case, only your Key Vault (via its managed identity with Storage Blob Data Contributor role) can access the storage. Other services without RBAC roles assigned will still be blocked. This is documented in Microsoft’s security baseline for storage accounts.

You’re correct that the firewall is blocking the backup operation. When Key Vault’s managed identity tries to write to the storage account, it’s coming from Azure’s internal service IPs, not from your whitelisted networks. You need to enable “Allow trusted Microsoft services” in the storage account firewall settings. This allows Azure first-party services like Key Vault to bypass the firewall rules.