The course is part of this learning path
Configuring and Managing Azure Key Vault starts with a key vault overview before moving on to authenticating and accessing Azure Key Vault as a user and as an application. We then deploy several key vaults to illustrate various creation, authentication, and access scenarios. Next, we create secrets and access them using the .NET and REST API interfaces. We then look at vault business continuity and backup options before seeing how to implement key rotation.
- Overview of Azure Key Vault
- Create an Azure Key Vault
- Create and consume secrets
- Learn about keeping vault data safe
- Learn about key rotation
- Students working towards the AZ-500: Microsoft Azure Security Technologies exam
- Those wanting to learn about Azure Key Vault and how to use it from application and user perspectives
- Students should be familiar with Active Directory concepts such as managed identities and role-based access control
Like most Azure resources, Key Vaults have a built-in level of redundancy to mitigate catastrophic failure, like an Azure region going down. All Azure regions have a mirror region or pair where resources are automatically replicated as part of business continuity. This failover process is automatic and invisible to end users. Region pairing is not configurable; for the most part, paired regions are co-located within the same country. The stated reason for these pairings is proximity and other factors, presumably something like reduced latency and increased speed.
Looking at some of the pairings is food for thought in terms of region-wide failures. For instance, Japan and Norway are thin or narrow countries, so east-west region redundancy doesn't have the same level of isolation as, say, East US versus West US. Proximity and other factors are more about governance and jurisdiction. That is, the paired regions belong to the same security world. For the most part, security worlds are analogous to countries, except for Ireland and the Netherlands, that fall under EU jurisdiction. You can back up and restore key vault resources, but you must follow paired region constraints, backing up and restoring within a security world.
So what do these constraints mean in practical terms? There is no valid way to back up a whole key vault as a single entity. Microsoft has this rather ominous paragraph in Azure Key Vault backup and restore documentation, alluding that it may be possible to back up an entire vault with Azure CLI commands, but it is far from recommended. Other considerations and limitations include; you can't back up more than 500 past versions of certificates, keys, or secrets. Backing up secrets with multiple versions may cause time-out errors, and if there are many versions, you may exceed vault service limits causing throttling and resulting in the backup failing. A vault resource is backed up as a blob file, which can only be restored to a vault in the same geographic region, i.e., security world.
Let's back up the connection string secret by clicking on the secret and selecting download backup. I'll download it onto my PC and then delete the secret from the vault. I want to restore to the same vault to show you some minor issues to look out for. The connection secret is gone, and we're back on the secret's main page. Now I'll restore the backup, selecting it from my PC. Ok, the first issue is not a timing one, as in, I'm performing these operations too quickly, but it is caused by purge protection.
While the secret is no longer visible in the vault, it still exists. I need to purge it completely. I can do that through manage deleted secrets, or so I thought, being the vault owner. This vault is set up to use access policies, and the purge permission wasn't set by default when I created the vault. I'll go into access policies, select the user, click edit, and check purge permission on secrets. Then Click next and save. Right, back to manage deleted secrets, and the purge button is enabled. After confirming the purge, we can complete the restore operation successfully.
Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.