Azure Key Vault Overview

Hello, this blog posting is a high-level description of Azure Key Vault for those looking to sort out exactly what AKV is. This will be followed by postings providing a more detailed description and walk throughs on how to use Azure Key Vault. This blog posting will most likely evolve over time to include updated an expanded information.

What is Azure Key Vaults Purpose?

To increase security you need to limit who knows the private key for a key or certificate, or who knows the secret. Azure Key Vault is the tool used to limit who can access and hence gain knowledge of the keys or secret. Also, since Azure Key Vault lives in Azure it can be accessed over the Azure network which means those keys and secrets can be secured and used across Azure. So, my definition of Azure Key Vault is: A security service that allows secrets, keys, or certificates to be securely access and managed in Azure.

Azure Key Vault Common Uses

What are some common uses for Azure Key Vault? Common scenarios include encryption for Storage Accounts, Azure Disk Encryption, SQL Server Always Encrypted, secrets store for Azure Kubernetes Service. Also, securely storing and accessing keys, certificates, and secrets for Azure App Service. You can also code your application to use Key Vault to secure and securely access keys, secrets, and certificates that are utilized by said application.

Azure Key Vault Standard vs Azure Key Vault Premium

This website has more information on Azure Key Vault and other Microsoft key management solutions: How to choose the right key management solution – How to choose between Azure Key Vault, Azure Managed HSM, Azure Dedicated HSM, and Azure Payment HSM | Microsoft Learn

The main differences between Standard and Premium is higher level of FIPS compliance with Premium and that Premium uses an HSM to protect keys.

Keys, Certificates, and Secrets

Many services leverage keys, certificates, or secrets for security. Keys and certificates can be used for authentication or encryption.

Secrets

Secrets can be leveraged for authentication. A secret is just a string of characters that is kept private or secret.  One example of a secret is a password. An application or identity provider knows the secret that is used to authenticate a user, unlock an application, or decrypt data. And that secret is inputted into the application and if it matches the secret the application or identity provider is expecting you get authenticated or unencrypt the data. A secret can be thought of as a symmetric key.

Keys

Keys and certificates are kinda similar in that a certificate has keys, it’s just the public key and hence the private key are bound to a digital document called a certificate. The certificate includes additional information used for a number of purposes, but the main purpose of the certificate is to include a digital identity such as a person, services, computer, and so on. In that way the keys can be used as proof of ownership of that identity. So, keys and certificate in terms of Azure Key Vault are a asymmetric keys. Meaning there is a public/private key pair. And hence Keys are going to use Public Key Algorithms such as RSA.

Certificates

Certificates are a digital document that binds and identity to a public key. So, certificates have keys, asymmetric keys. So, like keys which is covered above, the private key needs to be protected. That means that the key must not only be protected from export, but also that processes that use that key are protected so that the keys are protected. Such operations are encryption and signing.

Secrets, Keys, and Certificates Summary

So, to summarize the previous paragraph keys, certificates, and secrets can be used to access an application, service, or data.

Azure Key Vault Access

Permissions

Access to Secrets, Keys, and Certificates are restricted by permissions on the Key Vault and the Keys, Secrets, and Certificates themselves. This permissioning can follow and RBAC model or more of an ad hoc model where individual permissions are given. There are a number of pre-defined RBAC roles that can be used to provision access.

Network Security

Network Access to the key vault can be restricted. You can have access wide open, disable network access, or restrict what networks have access to the key vault.  You can also restrict access to Private Endpoints.

Summary of Access

So, at the Key Vault level you can protect the key vault by restricting what networks have access to the Key Vault. Also, at the Key Vault you can use access control to limit who has access to the Key Vault. At the Secret, Key, or Certificate level you can use access control to limit access. Role assignments are inherited from the Key Vault level to the Secrets, Keys, and Certificates level.

Monitoring

Alerts

You can setup alerts so that when certain thresholds are reached or certain events happen that an action is taken such as an email alert or app notification.

Metrics

Similar to performance monitor in Windows you can setup monitors to view when certain thresholds are reached via a graph that is generated.

Diagnostic Settings

You can configure where you want the logs generated by AKV to be sent for collection.

Logs

Logs are sent to Log Analytics, however, this must be configured. Once logs are sent to Log Analytics you can use tools like KQL and Workbooks to report on the collected data.

Insights

Insights are pre-defined graphs and tables. These are data sets that Microsoft feels are important and relevant in terms of monitoring AKV and AKV usage.

Workbooks

Workbooks are used to summarize and report on logs sent to Log Analytics.

Conclusion

This posting was a high-level definition of Azure Key Vault. Next blog posting will be a more in-depth description of Azure Key Vault for those looking for more technical details.