Welcome to the Fortanix Data Security Manager (DSM) Extended Virtual Keys guide. The purpose of this guide is to describe the following:
- What is Fortanix DSM Extended Virtual Keys?
- Use case of Fortanix Extended Virtual Keys.
- Advantages of Fortanix DSM Extended Virtual Keys.
- Fortanix DSM workflow for Extended Virtual Keys.
2.1 DSM Extended Virtual Keys
Extended Virtual Keys allows customers to deploy a virtualized instance of their encryption management solution (for example DSM) in the cloud alongside their business applications they are hosting in the cloud.
You can connect a group in a Fortanix DSM account (secondary group) with a group in another Fortanix DSM account (primary group) in the same/different cluster such that the new keys are physically generated and stored in the DSM primary group. The DSM Extended Virtual Keys are keys that store the cached key material of the DSM primary keys in the DSM secondary group so that the keys are replicated across DSM clusters. This way applications can fall back to a different cluster if one is down.
2.2 Use Case of DSM Extended Virtual Keys
You can use Extended Virtual Keys in the following scenarios:
- When you want the key generation to happen from a single source making that the source of truth. For example, this allows you to generate some keys from a more secure on-prem source and have that key available everywhere. You can also choose to generate some keys directly in the cloud DSM cluster without having to come back to the on-prem DSM cluster.
- When you want selected keys to be available in the cloud for applications running in the cloud. This will be useful when:
- You do not want every on-prem key to be available in the cloud.
- You want the same on-prem key to be available to more than one cloud DSM cluster.
- When you want to minimize latency for applications to consume keys.
2.3 Advantages of DSM Extended Virtual Keys
The following are the advantages of the Fortanix DSM Extended Virtual Keys solution:
- With Extended Virtual Keys, keys can be replicated across clusters. For example, between on-prem and multiple cloud clusters.
- Applications can fall back to a different cluster if one is down.
- The destination cluster can store the key material of external keys so that cryptographic operations can be done locally when the source cluster is down.
- Minimize latency for applications to consume keys
- On-prem crypto workloads to consume keys from on-prem DSM.
- Crypto workloads in the cloud to consume keys from the cloud-deployed DSM.
3.0 DSM Workflow for Extended Virtual Keys
Figure 1: DSM Extended Virtual Keys
- A connection is made between the DSM primary group (on-prem/SaaS/Cloud) and the DSM secondary group (on-prem/SaaS/Cloud).
- The secondary group initiates a key scan request on the primary group.
- The primary group returns the keys (with key material) to the secondary group.
- The primary keys are stored as virtual keys in the secondary group with the cached key material to perform local crypto operations when the primary cluster is down.
3.1 Example Workflow
In this example workflow, we will use on-prem deployment as the source of truth and explain the flow when a key is created in DSM on-prem using a cloud-deployed DSM cluster.
- Keys created on the on-prem cluster:
- Link groups in a cloud-deployed DSM cluster with a group in an on-prem DSM cluster.
- Automatic sync will discover newly created keys and copy the key material of these keys to the cloud-deployed DSM cluster. This will be an asynchronous process.
- Workloads deployed in the cloud can use keys directly from the cloud-deployed DSM cluster.
- Keys created from a cloud-deployed DSM cluster:
- If a key generation happens in a linked group, a key will be created in the DSM on-prem cluster, and the key material will be copied to the cloud cluster.
- This process will be synchronous.
- Workload deployed in an on-premises cluster can use the key from the on-premises cluster.
4.0 DSM Source and Destination Cluster Dependency for Extended Virtual Keys
This section enumerates various scenarios for dependencies between two Fortanix DSM clusters connected for Extended Virtual Keys and their impact.
|New keys generated||If connectivity between the DSM primary cluster and the DSM secondary cluster is down, then any new keys generated in the DSM primary cluster will not be synced to the DSM secondary cluster and it will not be available for crypto operation on the DSM secondary cluster.|
|Existing keys in the source updated/deleted||
If connectivity between the DSM secondary cluster and the DSM primary cluster is down, then any update (including deletion) of existing keys in the DSM primary cluster will not be synced to the DSM destination cluster and the DSM secondary cluster will have stale information.
After the connectivity is restored, the automatic asynchronous syncing process will automatically sync up the changes to the DSM secondary Cluster. No manual intervention is needed.