Azure Key Vault Integration
KMES Series 3 Integration Guide
From Microsoft’s documentation website: “Azure Key Vault is a cloud service used to manage keys, secrets, and certificates. Key Vault eliminates the need for developers to store security information in their code. It allows you to centralize the storage of your application secrets which greatly reduces the chances that secrets may be leaked. Key Vault also allows you to securely store secrets and keys backed by Hardware Security Modules or HSMs. The HSMs used are Federal Information Processing Standards (FIPS) 140-2 Level 2 validated. In addition, key vault provides logs of all access and usage attempts of your secrets so you have a complete audit trail for compliance.”
For more general information about Azure Key Vault, please refer to the following article on Microsoft’s documentation website: https://docs.microsoft.com/en-us/azure/key-vault/general/overview
Azure Key Vault’s BYOK (Bring Your Own Key) feature allows importing existing asymmetric keys into a Key Vault. For this integration, this means being able to create asymmetric HSM Protected keys on a KMES Series 3 device, and then pushing those keys to an Azure Key Vault via the KMES application interface. Keys that are pushed to a Key Vault can be used with other services inside Azure, such as the following:
Azure Key Vault also has it’s own API that customers can use with their own applications to access and use keys stored in Azure Key Vault.
For this integration, keys will be created and stored on the KMES Series 3, synchronized to an Azure Key Vault, and then subsequently managed via the KMES application interface.
The Azure Key Vault BYOK / KMES Series 3 integration provides several benefits:
The Futurex Certification Process is a rigorous and standardized approach to testing and certifying integrations between third-party applications and Futurex’s HSMs and key management servers (i.e., KMES Series 3). The certification process is designed to ensure that third-party application integrations are fully tested and validated in a lab environment before they are deployed in a production environment. Futurex’s Integration Engineering team implements this process so that customers can have confidence that third-party applications will integrate seamlessly with Futurex’s HSMs and KMES Series 3 devices, and that all operations will result in the expected behavior. The certification process involves several steps, including research, testing, troubleshooting, and certification, and is fully documented in an integration guide for each integration. The full process is outlined below:
Overall, following these steps helps ensure that the integration between the third-party application and the Futurex device is fully tested and validated, and that any errors or issues are resolved before the integration is certified as fully supported.
Before the KMES Series 3 can push keys to an Azure Key Vault, credentials must be created inside of Azure and configured on the KMES. In Azure, these credentials will take the form of an App Registration. On the KMES, the credentials will take the form of a Cloud Credential.
NOTE: An existing Key Vault can be used rather than creating a new one, but it must be in the Premium service tier to include support for HSM backed keys.
This section will cover creating a Cloud Credential and an Azure Key Group on the KMES Series 3.
As mentioned previously, the three IDs (i.e., Tenant ID, Client ID, and Client Secret) that were gathered for the App Registration in Azure will now be used to create a Cloud Credential on the KMES.
The key group that will be created on the KMES in this section will essentially be the “key” in the Azure Key Vault. Azure Key Vault’s holds keys, and each key has versions. In the KMES’ parlance, this translates to the key group representing your key and the keys inside that group representing versions of that key. Furthermore, the KMES only shows keys for which key material was created on the KMES. Pulling private key data generated entirely on the Key Vault is not possible.
Keys can now be added to this group per the usual process. No synchronization of key material is done unless manually specified, as in the next step, or when automatic rotation is triggered on the schedule set for the group.
This section will explain the process for creating a key on the KMES, pushing key material to Azure, rotating key material on Azure, and deleting key material from Azure.
NOTE: If a firewall is configured in your environment, ensure that the following endpoints are allowed from the KMES out to the internet:
This new key, until another is pushed, will become the active key material for that key name in Azure Key Vault.
When the time for rotation comes (if scheduled during key group creation), a new key is generated locally on the KMES, given a name based on the group’s name, and synchronized to Azure. Since pushing a new key to Azure with the same name as the old key is the same thing as pushing a new version of that key, the new key material will become the active material.
Force rotation of the key material can also be done by right-clicking the key group and selecting Cloud -> Force Rotation. This will create a new key locally and automatically synchronize it to Azure.
Rotation will also set the “last rotated” timestamp on that particular group, if the rotation succeeds.
Deleting the local key material and deleting the cloud key material are two different actions. Deleting the local key material does not delete the key material on the Key Vault, if it’s been pushed.
To delete the cloud key material:
This section will explain how to track the progress/status of jobs related to Azure, view general Azure Service logs, and export Azure Service logs.
It has already been mentioned in previous sections that the progress/status of jobs related to Azure can be view under Logging and Reporting -> Jobs. Events specific to this integration that would initiate a new job include the following:
All log events specific to Azure can be viewed by navigating to Logging and Reporting -> System Logs and then selecting Azure Service in the dropdown at the top of the window.
The following are the different categories of log events:
To provide an example of what you could expect to see in the Azure Service logs, see the image below showing all of the logs events that would occur for successfully pushing a key to an Azure Key Vault, and then remotely deleting that key.
Azure Service logs can be exported by completing the following steps: