Vault Best Practices After Landing Zone Implementation

Backup and restore lets you take a point-in-time snapshot of your vault. Your backup can be stored offline locally or in an Object Storage bucket (in the same region or in a different region) and restored at any time. Restores are additive, so no keys will be lost during restore. The backup can be restored within the same region as your original vault (with the same OCIDs), or it can be restored in a different region from your original vault (with different OCIDs).

Use Cases

The primary use case for backup and restore is the ability to protect against accidental deletion of your keys or vault. Backups can also be used for disaster recovery in a second region. This is easier with cross-region replication because OCIDs won't match restores, whereas key and vault OCIDs in cross-region replication are the same across regions.

Back up data encrypted with your KMS key (such as for database backups). You can decrypt your data backups if you need to restore them later. This lets you delete keys in the meantime, freeing up capacity in your private vault.

Workarounds

It's possible to back up your encryption key materials using different ways; however not every way works for all users.

Workaround 1: Generate your own key materials and keep this as a backup. Import the key materials into KMS.

Workaround 2: Use KMS software keys, and export your key materials as a backup.

Both of these methods let you back up your unencrypted key materials. There's a limitation when you use KMS keys to encrypt an OCI resource (for example, block volume or object storage bucket). Since the KMS key OCID is associated with the resource, you need a KMS key with the same OCID to decrypt your resource. The only way to do this is by using the KMS backup and restore feature.

Note: Backup and restore is available only for private vaults.

Enabling cross-region replication on your vault will automatically replicate any changes to your source vault to a secondary region that you choose. The vaults will be identical and have the following qualities:

• Vault and key resource OCIDs are identical.
• Keys and the key versions added in the primary region will be replicated in the secondary region.
• Any deletions performed in the primary region will also be reflected in the secondary region.

The only difference between your vaults will be management and crypto endpoints: the region in the endpoint will reflect the vault's region.

Use Cases

The use cases for cross-region replication include disaster recovery across regions. Some customers might also have a need to locate data in two separate regions that are encrypted with the same key.

Note: Cross-region replication is available only for private vaults.

With KMS, key materials are usually generated within the HSM and can never leave the HSM. In some cases, you might have your own key material that you want to store in KMS HSMs for use in your OCI tenancy.

Use Cases

The use cases for key import include the ability to use the same key materials across multiple environments, including across different cloud providers. This also gives you flexibility to use the same encryption keys across regions or tenancies in OCI without using restore features, replication features, or cross-tenancy access. Key import gives you the ability to back up your key materials without using the KMS backup feature.

The following information describes the multiple tenancies scenario.

Use Cases

You can share vaults and keys across tenancies (including parent/child tenancies) using cross-tenancy access.

The following example shows how to allow Group B in Tenancy B to have access to keys in Compartment C in Tenancy A.

Policy in source tenancy (Tenancy A):

define tenancy TenancyB as < ocid for TenancyB >
define group GroupB as < ocid for GroupB in TenancyB >
 
admit group GroupB to use keys in compartment CompartmentC
 
// In order to associate a key in TenancyA with a resource in TenancyB:
admit group GroupB of tenancy TenancyB to use key-delegate in compartment < compartment of keys >
admit group GroupB of tenancy TenancyB to associate keys in compartment < compartment of keys > with < resource-type > in tenancy TenancyB
 
// To use this with another OCI service, such as associating a KMS key with your Block Storage block volume, add the appropriate service principal
allow service < service principal > to use keys in compartment CompartmentC

Policy in destination tenancy (Tenancy B):

define tenancy TenancyA as < ocid for TenancyA >
 
endorse group GroupB to use keys in TenancyA
 
// In order to associate a key in TenancyA with a resource in TenancyB:
endorse group GroupB to use key-delegate in tenancy TenancyA
endorse group GroupB to associate < resource-type > in compartment < compartment of resource > with keys in tenancy TenancyA

External Key Management lets you use your on-premises HSMs to protect your data in OCI. For external management, see the External Key Management Service in OCI Announcement and the External Key Management Service documentation.

Dedicated Key Management gives you full access to and control over your HSM in OCI. With KMS vaults, OCI declares ownership of the HSM, manages the HSM, and provides APIs for access. With dedicated key management, you declare ownership of the HSM, manage the HSM, and access the HSM directly. For more information, see Dedicated Key Management.