Secure Data and Applications (part 2)

To read part 1 please click here

Key Vault Keys

Cryptographic keys in Key Vault are represented as JSON Web Key (JWK) objects. There are two types of keys, depending on how they were created:

Soft Keys- They are the keys processed in software by Key Vault, but is encrypted at rest using a system key that is in a Hardware Security Module (HSM).
Hard Keys- They are the keys processed in HSM and are protected in one of the Key Vault HSM Security Worlds (there's one security world per geography to maintain isolation).

Key Operations

Key Vault supports many operations on key objects, they are:

Create- It allows a client to create a key in Key Vault. The value of the key is generated by Key Vault and stored, not released to the client. Asymmetric keys can also be created in the Key Vault.

Import- It allows a client to import an existing key to the Key Vault. Asymmetric keys can also be imported to the Key Vault by using a number of different packaging methods within a JWK construct.

Update- It allows a client with sufficient permissions to modify the metadata (key attributes) associated with a key previously stored within the Key Vault.

Delete- It allows a client with sufficient permissions to delete a key from the Key Vault.

Cryptographic Operations

Once a key has been created in the Key Vault, the following cryptographic operations can be performed using the key:

Sign and Verify- This operation is strictly "sign hash" or "verify hash", as Key Vault doesn't support hashing of content as a part of signature creation. Verification of the signed hashes is supported as a convenience operation for the applications that may not have access to [public] key material.

Key Encryption/Wrapping- A key stored in the Key Vault may be used to protect another key, typically a symmetric Content Encryption Key (CEK). When the key in the Key Vault is symmetric, key wrapping is used but when it is asymmetric, key encryption is used.

Encrypt and Decrypt- A key stored in the Key Vault may be used to encrypt or decrypt a single block of data. The encrypt operation is provided for convenience, particularly for the applications that may not have access to [public] key material.

Application Services Plan

Azure Key Vault provides the secrets management policies adopted by the various organizations (to store secrets centrally with expectations around expiration and access control), to your applications in Azure. But some applications can't easily take on code changes to start integrating with it, hence the Key Vault references are a way to introduce secrets management into your app without any code changes.

The app's system-assigned identity is used to securely fetch the secret and make it available to the app as an environment variable, which means that the teams can just easily replace the existing secrets stored in app settings with references to the same secret in the Key Vault, while the app will continue to operate normally.

Configure a Hardware Security Module (HSM) Key-generation Solution

For added assurance, whenever you use Azure Key Vault, you can always import or generate keys in HSMs that can never leave the HSM boundary, which is often referred to as Bring Your Own Key (BYOK). Azure Key Vault uses Thales nShield family of HSMs to protect your keys. (This functionality is not available for Azure China).

Generating and transferring an HSM-protected key over the Internet:

You generate the key from an offline workstation, which reduces the attack surface.
The key is encrypted with a Key Exchange Key (KEK), which stays encrypted until it is transferred to the Azure Key Vault HSMs. Only the encrypted version of your key leaves the original workstation.
The toolset sets the properties of your tenant key that binds your key to the Azure key Vault security world. This binding is enforced by the Thales HSMs.
The KEK that encrypts your key is generated inside the Azure key Vault HSMs, and is not exportable. In addition, the toolset includes attestation from Thales that the KEK is not exportable and was generated inside a genuine HSM that was manufactured by Thales.
The toolset also includes attestation that the Azure Key Vault security world was also generated on a genuine HSM manufactired by Thales.
Microsoft uses separate KEKs and security worlds in each geographical region. This separation ensures that your key can be used only in data centers in the region in which you encrypted it.

Customer Managed Keys

Once you have created your Key Vault and have populated it with keys and secrets, the next step is to set up a rotation strategy for the values you store as the Key Vault secrets. Secrets can be rotated in several ways:

As a part of manual process
Programmatically by using REST API calls
Through an Azure Automation script

Key Vault secrets

Key Vault offers a secure storage of secrets, such as passwords and database connection strings and its service doesn't provide semantics for secrets, it merely accepts the data, encrypts it, stores it, and returns a secret identifier ("id") that can be used to retrieve the secret at the later time.

It also supports the contentType field for secrets. Cients may specify the content type of a secret to assist in interpreting the secret data when it is retrieved. For instance, an implementation may store both the passwords and certificates as secrets, then use this field to differentiate. There are no predefined values.

As shown above, the values for Key Vault Secrets are:

Name-value pair- Name must be unique in the Vault
Value can be any UTF-8 string- max of 25 KB in size
Manual or certificate creation
Activation date
Expiration date

Azure Storage Account Key Management

Key Vault can manage Azure storage account keys:

Internally, Key Vault can list (sync) keys with an Azure storage account.
Key Vault regenerates (rotates) the keys periodically.
Key values are never returned in response to caller.
Key Vault manages the keys of both the storage accounts and classic storage accounts.

Storage Account Access Control

The following permissions can be used when authorizing a user or application principle to perform operations on a managed storage account:

Permissions for managed storage account and SaS-definition operations:

get- Gets information about the storage account
list- List storage accounts managed by a Key Vault
update- Update a storage account
delete- Delete a storage account
recover- Recover a deleted storage account
backup- Backs up a storage account
restore- Restore a backed-up storage account to a Key Vault
set- Create or update a storage account
regeneratekey- Regenerate a specified key value for a storage account
getsas- Get information about a SaS definition for a storage account
listsas- List storage SaS definitions for a storage account
deletesas- Delete a SaS definition from a storage account
setsas- Create or update a new SaS definition/attributes for a storage account

Permissions for privileged operations:

purge- Purge (permanently delete) a managed storage account

Key and Secret Rotation

Once you have keys and secrets stored in the Key Vault, it is very important to think about a rotation strategy. There are several ways to rotate the values:

As part of a manual process
Programmatically by using API calls
Through an Azure Automation script

The following diagram shows that how Event Grid and Logic Apps can be used to automate the process-

30 days before expiration date of a secret, Key Vault publishes the "near expiry" event to Event Grid.
Event Grid then checks the event subscriptions and uses HTTP POST to call the function app endpoint subscribed to the event.
The function app receives secret information, and generates a new random password, as well as creates a new version for the secret with the new password in the Key Vault.
Lastly, the function app updates SQL Server with the new password.

Hence, you can easily rotate the values without any problem and ensure better security.

To read part 1 please click here

Search This Blog

Blogs by Ashwin