Azure Key Vault

Posted on Edited on In Waline:

Azure Key Vault is a tool for securely storing and accessing secrets. A secret is anything that you want to tightly control access to, such as API keys, passwords, or certificates. A vault is logical group of secrets.

The above paragraph is the description of the official Azure documentation. After reading the Microsoft Azure documentation, the author extracted and summarized the basic concepts, and added some of his own understanding to the original text. After reading the Chinese version, you can have a general understanding of key vault. The original English version is a more professional description, which does not affect the understanding.

What is Azure Key Vault

In simple terms, Azure Key Vault is a place where you can store your sensitive data securely, and you have to pass the identity verification and permission verification to get this data, so we can put sensitive information like certificates, database configuration, etc. here without hard-coding it into the code. When we store the sensitive information on the key vault, we will get the corresponding name, we just need to go to the key vault through the api to get the corresponding information by name (you can also add the version information), this information can be the key (only get public key), certificate information, or some configuration information. Of course, this information is not anyone directly to call the api can get, but you need your Identity information is used to create the Key Vault by the Tenant under the Subscription recognized, there are many ways to get recognized, can be through the id-token, or password, etc…

Azure Key Vault helps solve the following problems:

  • Secret Management - Azure Key Vault can be used to securely store and tightly control access to tokens, passwords, certificates, API keys and other secrets.
  • Key Management - Azure Key Vault can also be used as a key management solution. Use Azure Key Vault to easily create and control the encryption keys used to encrypt your data.
  • Certificate Management - Azure Key Vault is also a service that enables you to easily provision, manage and deploy public and private Secure Socket Layer / Transport Layer Security (SSL / TLS) certificates for use with Azure and on-premise connected resources.
  • Storage is supported by a hardware security module Confidential-Secret and keys can be protected by software or FIPS 140-2 Level 2 validated HSM.

With Azure Key Vault, you can centrally store confidential application data and control the distribution of that data. And because developers can eliminate the need to hard-code security information into their applications, they can greatly improve the security of their applications.

Information stored in Azure Key Vault is preserved with reliable encryption algorithms.

Azure Key Vault can also control access based on Azure AD, and can record who accessed which data at which time.

Azure Key Vault basic concepts

  • Tenant/Tenant ( Tenant ): A tenant is an organization that owns and manages a specific instance of a Microsoft cloud service. Most commonly used to refer to an organization’s Azure and Office 365 service set.
  • Vault owner: The vault owner can create a key vault and gain full access and control over it. The vault owner can also set up auditing to record who has access to the secrets and keys. Administrators can control the key lifecycle. They can roll over to a new version of the key, make backups and perform related tasks.
  • Vault consumer ( Vault consumer ): Vault consumer can perform operations on the assets in the key vault when the vault owner grants the user access. The available operations depend on the privileges granted.
  • Resources ( Resource ): Resources are items that can be managed through Azure. Common examples include virtual machines, storage accounts, web applications, databases, and virtual networks. And many more.
  • Resource group ( Resource group ): A resource group is a container that contains the resources associated with an Azure solution. A resource group can contain all the resources of the solution, or it can contain only the resources that you want to manage as a group. You can decide how to assign resources to a resource group based on the decisions that make the most sense for your organization.
  • Service principal: An Azure service principal is a secure identity that is used by user-created applications, services and automation tools to access specific Azure resources. It can be thought of as a “user identity” (username, password, or credentials) with specific roles and tightly controlled permissions. Unlike a general user identity, a service subject only needs to do certain things. Security can be improved if it is granted only the minimum level of privileges needed to perform administrative tasks.
  • Azure Active Directory (Azure AD): Azure AD is a tenant’s Active Directory service. Each directory has one or more domains. A directory can have many subscriptions associated with it, but only one tenant. Each organization can have one tenant, which has its own ID to identify itself, and each Tenant has its own one or more SubScriptions, and the Subscriptions are in a many-to-one relationship with the Azure AD directory. Each person can go to Azure to apply for their own account, this account is called Identity on Azure, each Identity can create Azure AD account. if your Azure AD account in a Tenant’s Azure AD directory, and the Tenant granted you If your Azure AD account is in a Tenant’s Azure AD directory, and the Tenant grants you access to a Subscription, you can use the Services under that Subscription. directory-whatis)
  • Azure Tenant ID ( Azure tenant ID ): The tenant ID is a unique way to identify an Azure AD instance in an Azure subscription.
  • Managed identities ( Managed identities ): Azure Key Vault provides a way to securely store credentials and other keys and secrets, but your code needs to be authenticated through Key Vault to retrieve them. By using a managed identity, you can simplify the steps to resolve this issue by providing an automated managed identity for Azure services in Azure AD. You can use this identity to authenticate against Key Vault or any service that supports Azure AD authentication, without having to include any credentials in your code.

Anybody with an Azure subscription can create and use key vaults. Although Key Vault benefits developers and security administrators, it can be implemented and managed by an organization’s administrator who manages other Azure services.

Security

This section focuses on how Azure Key Vault ensures that your information can only be seen by those you authorize to see it.

There are two levels of Key Vault management, which correspond to two access models. The first level is called management plane, and this level of relationship can operate on the Key Vault itself, and can create and delete a Key Vault. However, regardless of the level, the identity verification is achieved through Azure AD, which determines what kind of operations a user can do to the Key Vault through Role Based Access Control (RBAC).

RBAC made under different levels only applies to users under that level, for example, the RBAC you make under the level of Subscription only applies to users under that Subscription.

At the same time for the secret, key, certificate permissions management is separate, that is to say, you the same Subscription under the user in the same Key Vault may have access to the secret, but for the key but not.

You need to protect encryption keys and secrets like certificates, connection strings, and passwords in the cloud so you are using Azure Key Vault. Since you are storing sensitive and business critical data, you need to take steps to maximize the security of your vaults and the data stored in them.

Identity and access management

When you create a key vault in an Azure subscription, it’s automatically associated with the Azure AD tenant of the subscription. Anyone trying to manage or retrieve content from a vault must be authenticated by Azure AD.

  • Authentication establishes the identity of the caller.
  • Authorization determines which operations the caller can perform. Authorization in Key Vault uses a combination of Role based access control (RBAC) and Azure Key Vault access policies.

Access model overview

Access to vaults takes place through two interfaces or planes. These planes are the management plane and the data plane.

  • The management plane is where you manage Key Vault itself and it is the interface used to create and delete vaults. You can also read key vault properties and manage access policies.
  • The data plane allows you to work with the data stored in a key vault. You can add, delete, and modify keys, secrets, and certificates.

To access a key vault in either plane, all callers (users or applications) must be authenticated and authorized. Both planes use Azure Active Directory (Azure AD) for authentication. For authorization, the management plane uses role-based access control (RBAC) and the data plane uses a Key Vault access policy.

The model of a single mechanism for authentication to both planes has several benefits:

  • Organizations can control access centrally to all key vaults in their organization.
  • If a user leaves, they instantly lose access to all key vaults in the organization.
  • Organizations can customize authentication by using the options in Azure AD, such as to enable multi-factor authentication for added security

Managing administrative access to Key Vault

When you create a key vault in a resource group, you manage access by using Azure AD. You grant users or groups the ability to manage the key vaults in a resource group. You can grant access at a specific scope level by assigning the appropriate RBAC roles. To grant access to a user to manage key vaults, you assign a predefined key vault Contributor role to the user at a specific scope. The following scopes levels can be assigned to an RBAC role:

  • Subscription: An RBAC role assigned at the subscription level applies to all resource groups and resources within that subscription.
  • Resource group: An RBAC role assigned at the resource group level applies to all resources in that resource group.
  • Specific resource: An RBAC role assigned for a specific resource applies to that resource. In this case, the resource is a specific key vault.

Controlling access to Key Vault data

Key Vault access policies grant permissions separately to keys, secrets, or certificate. You can grant a user access only to keys and not to secrets. Access permissions for keys, secrets, and certificates are managed at the vault level.

Network access

You can reduce the exposure of your vaults by specifying which IP addresses have access to them. The virtual network service endpoints for Azure Key Vault allow you to restrict access to a specified virtual network. The endpoints also allow you to restrict access to a list of IPv4 (internet protocol version 4) address ranges. Any user connecting to your key vault from outside those sources is denied access.

After firewall rules are in effect, users can only read data from Key Vault when their requests originate from allowed virtual networks or IPv4 address ranges. This also applies to accessing Key Vault from the Azure portal. Although users can browse to a key vault from the Azure portal, they might not be able to list keys, secrets, or certificates if their client machine is not in the allowed list. This also affects the Key Vault Picker by other Azure services. Users might be able to see list of key vaults, but not list keys, if firewall rules prevent their client machine.

Azure Key Vault security worlds and geographic boundaries

Azure Key Vault is a multi-tenant service where the same Azure Location uses the same HSM and enjoys the same security perimeter, i.e., in the same security world.

Also Azure Key Vault can back up data, but the backup needs to meet two conditions:

  • Two Azure locations in the same geographic location
  • Two key vaults belong to the same subscription

Secure access to a key vault

Access model overview

Access to the keystore is controlled through two interfaces: the management plane and the data plane. The management plane is where you manage the key vault itself. Operations in this plane include creating and deleting key vaults, retrieving key vault properties, and updating access policies. The data plane is where you work with the data stored in the key vault. You can add, delete, and modify keys, secrets, and certificates.
To access the keystore in either plane, all callers (users or applications) must have proper authentication and authorization. Authentication establishment

Active Directory authentication

When you create a key vault in an Azure subscription, it’s automatically associated with the Azure AD tenant of the subscription. All callers in both planes must register in this tenant and authenticate to access the key vault. In both cases, applications can access Key Vault in two ways:

  • User plus application access: The application accesses Key Vault on behalf of a signed-in user. Examples of this type of access include Azure PowerShell and the Azure portal. User access is granted in two ways. Users can access Key Vault from any application, or they must use a specific application (referred to as compound identity).
  • Application-only access: The application runs as a daemon service or background job. The application identity is granted access to the key vault.

For both types of access, the application authenticates with Azure AD. The application uses any supported authentication method based on the application type. The application acquires a token for a resource in the plane to grant access. The resource is an endpoint in the management or data plane, based on the Azure environment. The application uses the token and sends a REST API request to Key Vault. To learn more, review the whole authentication flow.

The model of a single mechanism for authentication to both planes has several benefits:

  • Organizations can control access centrally to all key vaults in their organization.
  • If a user leaves, they instantly lose access to all key vaults in the organization.
  • Organizations can customize authentication by using the options in Azure AD, such as to enable multi-factor authentication for added security.

Resource endpoints

Applications access both planes through endpoints.

The access controls for the two planes work independently. To grant an application access to use keys in a key vault, you grant data plane access by using a Key Vault access policy. To grant a user read access to Key Vault properties and tags, but not access to data (keys, secrets, or certificates), you grant management plane access with RBAC. **

Certificate

About keys, secrets, and certificates

Azure Key Vault enables Microsoft Azure applications and users to store and use several types of secret/key data

  • Cryptographic key (Cryptographic key): supports multiple key types and algorithms and allows to use Hardware Security Module (HSM) for high value keys. We can actually only get the public key through the api.
  • Confidential (Secrets): Provides confidential and secure storage, such as passwords and database connection strings.
  • Certificates (Certificates): Supports certificates built on keys and secrets, and adds auto-renewal functionality.
  • Azure Storage (Azure Storage): Enables you to manage keys for your Azure Storage account. Internally, Key Vault can list (synchronize) keys using Azure Storage accounts and regenerate (rotate) keys periodically.

Key Vaults keys

Encryption keys in Key Vault are represented as JSON Web Key [JWK] objects. the JWK / JWA base specification has also been extended to enable key types specific to Key Vault implementations. For example, keys that can only be used in Key Vault HSM can be securely transported using an HSM vendor-specific package import key.

  • “Soft” key: A key that Key Vault processes in software but encrypts at rest using the system key in HSM. Customers can import an existing RSA or EC (elliptic curve) key, or request Key Vault to generate one.
  • “Hard” keys: Keys processed in the HSM (Hardware Security Module). These keys are protected in one of the Key Vault HSM secure worlds (one for each geographic region to maintain isolation). Clients can import RSA or EC keys in soft form or by exporting them from a compatible HSM device. Clients can also request Key Vault to generate keys. This key type adds the key_hsm attribute to the JWK fetch to carry HSM key material.

After creating a key in the keystore, you can use the key to perform the following encryption operations:

  • Sign and verify: Technically, this operation is a “signed hash” or “verified hash” because Key Vault does not support content hashing as part of signature creation. The application should hash the data to be signed locally and then request Key Vault to sign the hash. For applications that may not have access to [public] key material, support for verification of the signed hash is provided for ease of operation. For best application performance, verify that the operation is performed locally.
  • Key Encryption/Packaging: A key stored in Key Vault can be used to protect another key, usually a symmetric content encryption key (CEK). When the key in the Key Vault is not symmetric, key encryption will be used. For example, RSA-OAEP and WRAPKEY / UNWRAPKEY operations are equivalent to ENCRYPT / DECRYPT. If the key in the Key Vault is symmetric, then key wrapping is used. For example, AES-KW supports WRAPKEY operation for applications that do not have access to [public] key information. For best application performance, WRAPKEY operations should be performed locally.
  • Encryption and Decryption: The key stored in Key Vault can be used to encrypt or decrypt a single block of data. The size of the block is determined by the key type and the selected encryption algorithm. For convenience, the Encrypt operation is provided for applications that may not have access to [public] key information. For best application performance, encryption operations should be performed locally.

Key Vault secrets

From a developer’s perspective, Key Vault APIs accept and return secret values as strings. Internally, Key Vault stores and manages secrets as sequences of octets (8-bit bytes), with a maximum size of 25k bytes each. The Key Vault service doesn’t provide semantics for secrets. It merely accepts the data, encrypts it, stores it, and returns a secret identifier (“id”). The identifier can be used to retrieve the secret at a later time.

For highly sensitive data, clients should consider additional layers of protection for data. Encrypting data using a separate protection key prior to storage in Key Vault is one example.

Key Vault also supports a contentType field for secrets. Clients may specify the content type of a secret to assist in interpreting the secret data when it’s retrieved. The maximum length of this field is 255 characters. There are no pre-defined values. The suggested usage is as a hint for interpreting the secret data. For instance, an implementation may store both passwords and certificates as secrets, then use this field to differentiate. There are no predefined values.

Key Vault Certificates

Key Vault certificates support provides for management of your x509 certificates and the following behaviors:

  • Allows a certificate owner to create a certificate through a Key Vault creation process or through the import of an existing certificate. Includes both self-signed and Certificate Authority generated certificates.
  • Allows a Key Vault certificate owner to implement secure storage and management of X509 certificates without interaction with private key material.
  • Allows a certificate owner to create a policy that directs Key Vault to manage the life-cycle of a certificate.
  • Allows certificate owners to provide contact information for notification about life-cycle events of expiration and renewal of certificate.
  • Supports automatic renewal with selected issuers - Key Vault partner X509 certificate providers / certificate authorities.

This article is only an introduction to the basic concepts of Azure Key Vault and the relationships between them. For more detailed information, such as how Key Vault monitors, throttles, authentication, request parameters, and other details, please check the official documentation at the end of this article.

Reference article:

https://docs.microsoft.com/en-us/azure/key-vault/

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-whatis

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-how-subscriptions-associated-directory

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-manage-groups