• https://docs.microsoft.com/en-us/learn/modules/azure-key-vault/
• Key Vault is used to store and manage tokens, passwords, certificates, encryption keys, API keys, and other secrets.
• Authentication and authorization for Key Vault is handled by Azure AD.
• There are two levels of the service, standard and premium.
  • Only premium can use hardware (HSM) for key encryption. This is the only difference between standard and premium Key Vault.
• A third option is a Managed HSM that only supports HSM backed keys. It does not support any other type of secrets.

• Soft keys: A key processed in software by Key Vault, but is encrypted at rest using a system key that is in an Hardware Security Module (HSM). Clients may import an existing RSA or EC (Elliptic Curve) key, or request that Key Vault generate one.
• Hard keys: A key processed in an HSM (Hardware Security Module). These keys are protected in one of the Key Vault HSM Security Worlds (there's one Security World per geography to maintain isolation). Clients may import an RSA or EC key, in soft form or by exporting from a compatible HSM device. Clients may also request Key Vault to generate a key.

• There are two methods for managing access to key vaults and their contents. One is vault access policies and the other is RBAC role policies.
• The control plane is where the key vault and access is created/modified/ deleted and the data plane is where the contents of the key vault are accessed.

To access a key vault in either plane, all callers (users or applications) must have proper authentication and authorization. Authentication establishes the identity of the caller. Authorization determines which operations the caller can execute.

Both planes use Azure AD for authentication. For authorization, the management plane uses RBAC, and the data plane can use either newly added RBAC or a Key Vault access policy.

If a user has contributor permissions (RBAC) to a key vault management plane, they can grant themselves access to the data plane by setting a key vault access policy. We recommend that you tightly control who has contributor access to your key vaults, to ensure that only authorized persons can access and manage your key vaults, keys, secrets, and certificates.

• Sign and Verify: Strictly, this operation is “sign hash” or “verify hash”, as Key Vault doesn't support hashing of content as part of signature creation. Applications should hash the data to be signed locally, then request that Key Vault sign the hash. Verification of signed hashes is supported as a convenience operation for applications that may not have access to [public] key material.
• Key Encryption / Wrapping: A key stored in Key Vault may be used to protect another key, typically a symmetric content encryption key (CEK). When the key in Key Vault is asymmetric, key encryption is used. When the key in Key Vault is symmetric, key wrapping is used.
• Encrypt and Decrypt: A key stored in Key Vault may be used to encrypt or decrypt a single block of data. The size of the block is determined by the key type and selected encryption algorithm. The Encrypt operation is provided for convenience, for applications that may not have access to [public] key material.

• Hardware Security Module is a hardware based solution for storing keys.
• https://docs.microsoft.com/en-us/learn/modules/azure-key-vault/12-azure-hardware-security-module

• When using ARM Templates that need to reference Key Vaults you can use linked templates to dynamically generate the resource id for the key vault.
  • A dynamic resource id cannot be generated in a parameters file because template expressions are not supported there.