AZ-500 Microsoft Azure Security Technologies Exam

Vault Access Policies and RBAC

Azure Key Vault offers two main ways to control access: vault access policies and Azure Role-Based Access Control (RBAC). Vault access policies are set directly on each vault. They let you grant specific permissions for keys, secrets, and certificates. In contrast, Azure RBAC works through the Azure Resource Manager to assign roles at different levels, from broad management groups down to individual vaults. Understanding both models helps you choose the right approach for your security needs.

Vault access policies create explicit permission grants for individual vaults. You specify which operations—like get, list, create, or delete—are allowed on keys, secrets, and certificates. These policies live inside each vault and apply only to that vault. By defining only the operations needed, you enforce a least-privilege approach. This reduces the risk of unwanted access to sensitive cryptographic materials.

Azure RBAC integrates Key Vault access into your overall Azure governance. You assign built-in roles or custom roles to security principals at various scopes. Built-in roles include:

• Key Vault Reader: View vault properties without accessing data.
• Key Vault Contributor: Manage vault settings but not data.
• Key Vault Secrets Officer: Handle secret operations.
• Key Vault Crypto User: Perform cryptographic tasks on keys.

Custom roles let you include only the exact permissions you need, such as Microsoft.KeyVault/secrets/get/action. This flexibility helps maintain a consistent access model across all Azure resources.

Role assignments can be scoped to different levels to keep permissions tight:

• Management Group: Applies to all subscriptions and vaults under it.
• Subscription: Covers all resource groups and vaults in the subscription.
• Resource Group: Limits access to vaults within a specific group.
• Resource: Targets a single Key Vault instance.

Choosing the narrowest scope that meets your needs is key to minimizing security risk.

When planning your access controls, decide whether to use vault access policies, Azure RBAC, or a mix of both. Azure RBAC is recommended for consistent management across subscriptions and for integrating with Azure Policy. Use vault access policies for granular control on critical vaults when needed. Always allow for Azure Resource Manager to refresh its cache after role changes and actively monitor audit logs to ensure your setup stays secure and compliant.

Conclusion

In this section, we examined two ways to secure your Azure Key Vault: vault access policies and Azure RBAC. Vault access policies give you precise control at the vault level, while Azure RBAC ties Key Vault access into a broader Azure governance framework.

We saw how defining roles and scopes—from management groups down to single vaults—helps enforce a least-privilege model. Using built-in or custom roles lets you tailor permissions exactly to what each user or application needs.

Finally, we highlighted best practices: pick the right model for your scenario, choose the narrowest scope, and keep an eye on audit logs. By combining these strategies, you can protect your keys, secrets, and certificates while maintaining a clear, manageable access structure.