Azure Key Vaults for Newbies: Secure Your Secrets with Ease
I’m sure that you’ve had situations where you have asked yourself “OK, I have some certificates that we are using for SSL/TLS, also a few of the passwords and database connection strings, and encryption keys to encrypt our data but where can I save them securely?”
This is where Azure Key Vault comes in.
Azure Key Vault Overview
First and foremost its purpose is to solve the following problems:
- Secrets management — control access to passwords, tokens, certificates, API keys, etc.
- Key management — easy way to create and control encryption keys used to encrypt your data.
- Certificate management — provisioning, managing, and deploying public and private TLS/SSL certificates to use with Azure and internally connected resources.
It comes in two service tiers:
Standard — encrypts with a software key using industry-standard algorithms and key lengths.
Premium — also includes hardware security modules (HSM) protected keys which provide additional assurance.
Authentication to Azure Key is done via Microsoft Entra ID. Authorization may be done via Azure role-based access control (Azure RBAC) or Key Vault access policy. Azure RBAC can be used for both management of the vaults and accessing data stored in a vault, while the key vault access policy can only be used when attempting to access data stored in a vault.
As a secure store in Azure, Key Vault has been used to simplify scenarios like:
- Azure Disk Encryption
- The always encrypted and Transparent Data Encryption functionality in SQL Server and Azure SQL Database
- Azure App Service.
Key Vault itself can integrate with storage accounts, event hubs, and log analytics.
Keys inside Azure Key Vault
Key Vault supports Rivest–Shamir–Adleman (RSA) and Eliptic Curve (EC) keys, while Managed HSM supports RSA, EC, and symmetric keys.
Most typical usage scenarios for keys are Azure server-side data encryption with customer-managed keys, client-side data encryption (blobs for example), and Keyless TLS (using client libraries for programming)
Tell me your Secrets…
Key Vault provides secure storage of generic secrets, such as passwords and database connection strings as mentioned above.
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 extra layers of protection for data. Encrypting data using a separate protection key prior to storage in Key Vault is one example.
All secrets in your Key Vault are stored encrypted. Key Vault encrypts secrets at rest with a hierarchy of encryption keys, with all keys in that hierarchy protected by modules that are FIPS 140–2 compliant. This encryption is transparent and requires no action from the user. The Azure Key Vault service encrypts your secrets when you add them, and decrypts them automatically when you read them.
Key Vault also provides you access to secrets through access control:
For more information on working with secrets, see Secret operations in the Key Vault REST API reference. For information on establishing permissions, see Vaults — Create or Update and Vaults — Update Access Policy.
Verify your ownership with Certificates
Azure Key Vault certificate support provides for the management of your X.509 certificates and also certain behaviors:
- Allows a certificate owner to create a certificate through Azure Key Vault or import existing certificates which can be both self-signed and generated from certificate authority (CA)
- Allows a certificate owner to create a policy that directs Key Vault to manage the lifecycle of a certificate
- Allows a certificate owner to provide contact information for notifications about the lifecycle events of expiration and renewal
- Supports automatic renewal with selected issuers — Key Vault partner X.509 certificate providers and CAs
When a certificate is created, an addressable key and secret are also created with the same name. Key Vault allows key operations, and the Key Vault secrete allows retrieval of the certificate value as a secret. Key Vault certificate also contains public X.509 certificate metadata.
Creation of self-signed certificate on Azure Key Vault
To add a certificate to the vault, you just need to take a couple of additional steps. In this case, we add a self-signed certificate that could be used by an application. The certificate is called ExampleCertificate.
- On the Key Vault properties pages, select Certificates.
- Click on Generate/Import.
- On the Create a Certificate screen choose the following values:
- Method of Certificate Creation: Generate.
- Certificate Name: ExampleCertificate.
- Subject: CN=ExampleDomain
Leave the other values to their defaults. (By default, if you don’t specify anything special in Advanced policy, it’ll be usable as a client auth certificate.)
4. Click Create.
Export of self-signed certificate
By clicking the “Download in CER format” or “Download in PFX/PEM format” button, you can download the certificate.
There is also a whole procedure of how you can do the same with Certificates signed by CA like DigiCert or GlobalSign but I won't get into much detail with that besides leaving a link to the steps.
Best practices with Azure Key Vault
- Use separate Key Vaults — the recommendation is to use a vault per application per environment (development, preproduction, and production), per region. Granular isolation helps you not share secrets across applications, environments, and regions, and it also reduces the threat if there is a breach.
- Control access to your Key Vault:
- Lock down access to your subscription, resource group, and key vaults using the role-based access control (RBAC) permission model for the data plane.
- Assign RBAC roles at Key Vault scope for applications, services, and workloads requiring persistent access to Key Vault
3. Assign just-in-time eligible RBAC roles for operators, administrators, and other user accounts requiring privileged access to Key Vault using Privileged Identity Management (PIM)
4. Require at least one approver
5. Enforce multi-factor authentication
6. Restrict network access with Private Link, firewall, and virtual networks
- Turn on data protection for your vault — Turn on purge protection to guard against malicious or accidental deletion of the secrets and key vault even after soft-delete is turned on.
- Turn on logging — Turn on logging for your vault. Also, set up alerts.
- Backup — Purge protection prevents malicious and accidental deletion of vault objects for up to 90 days. In scenarios, when purge protection is not a possible option, it is recommended to backup vault objects, which can’t be recreated from other sources like encryption keys generated within the vault.
Useful documentation
Conclusion
As always thank you for reading the article, I hope it was useful and comprehensive. If you’ve liked the article, give me a few claps, share it around, and leave me your feedback. It would mean a lot. On the same note, check out the articles written by Martina on the EDR/MDR/XDR topics and Hrvoje with his articles related to Penetration testing, ethical hacking, and reverse engineering.
For all the questions and all the feedback on the subject, you can find me on LinkedIn and read the rest of our articles on Cyberdnevnik:
Cheers,
Vedran.
