1.0 Introduction
This article describes the best practices for Fortanix-Data-Security-Manager (DSM) with Google Cloud Platform (GCP) services integration.
1.1 Infrastructure Requirement
It is important to understand the Google External Key Manager (EKM) process flow. During the Fortanix DSM cluster configuration, you should keep the following in mind:
In a Google EKM integration for any Google service, the Google service reaches out to the Fortanix DSM service to access the CMEK (Customer Managed Encryption Key).
For any on-premises cluster, you must expose the Fortanix DSM service to the GCP service with appropriate network access restrictions and considerations.
Figure 1: EKM access low Google services
1.2 Pre-requisites for Integration
The Fortanix DSM application (app) name must match the identity of the GCP service account in the format
"service-[PROJECT-NUMBER]@gcp-sa-ekms.iam.gserviceaccount.com", where[PROJECT-NUMBER]is the project number of your Google Cloud Platform project.To ensure proper connectivity between Google EKM and Fortanix DSM, make sure that Fortanix DSM supports all GCP regions.
Enable the External Key Manager API in your Google Cloud project.
Select a Google service account with key management privileges.
In the app authentication method options, you must select Google Service Account as the authentication method.
Create an app access policy that includes key justification reasons. You can choose to allow all requests or customize it according to your requirements. The access policy can be created for a new app or an existing app.
1.3 Key Management Operations
Fortanix supports AES key for Google EKM.
Automatic rotation for the CMEK is not supported by Google.
You can rotate a key from Fortanix DSM and use the new EKM key version URL to rotate the key in Google KMS. This process is manual.
1.4 Best Practices
Cloud EKM enables enterprises to mitigate their security and compliance risk by retaining control of their encryption keys and securing them outside of the public cloud. To ensure the availability of keys, we recommend the following list of requirements when implementing external key management:
High availability – The EKM used with Cloud EKM Service should be at least as available as the GCP KMS service with which it integrates.
Disaster recovery – If the EKM is destroyed and keys are lost, there must be a method to recover the keys.
Load balancing – Fortanix DSM provides automatic load balancing for hybrid or multi-cloud deployments.
Performance - Latency and throughput should remain within acceptable limits.
Role-based access control - Access to the EKM keys must be tightly controlled within the EKM.
Auditability - While GCP logs activities inside the cloud, enterprises expect operations performed outside the cloud on the EKM to be logged with a similar level of granularity.
2.0 High Availability
High availability is critical for GCP Cloud EKM because if the EKM key is not available to Big Query or Google Compute Engine (GCE), then the service would be unavailable to the user. These are often business-critical services for an enterprise.
Fortanix DSM is architected to always work as a cluster of three or more nodes to ensure high availability. The cluster allows for the service to be available and the keys to be usable if most of the nodes are available in the cluster. In the event of loss of the majority of nodes, Google Cloud EKM keys remain usable, but the ability to create new keys is lost.
The cluster of nodes can easily be spread across physically separate data centers, allowing for resilience against the failure of entire data centers or connectivity issues between them. The service remains fully available if most of the nodes are available in the cluster. In a multi-data-center deployment scenario, a global load balancer routes incoming traffic to the nearest data center.
3.0 Disaster Prevention and Recovery
While HA provides continuous access to the EKM key, it would still be disastrous if the EKM key is permanently lost or deleted, whether through human error, software malfunction, or a hardware-level disaster. Services like Big Query would lose all data in this scenario, so it is critical to have measures to recover from such a disaster.
Fortanix DSM provides several mechanisms to minimize the risk of key loss and to facilitate rapid recovery should a disaster occur.
3.1 Disaster Prevention
To prevent accidental or malicious deletion of an EKM key or changes to its permissions, Fortanix DSM supports quorum-based policies that enforce an approval process where multiple administrators need to approve sensitive actions, such as key deletion or permission changes. Customers are recommended to configure a Quorum approval policy with multiple administrators on the group used to create and store the Google Cloud EKM keys.
3.2 Disaster Recovery
If a key is deleted or lost even after having a Quorum approval policy configured, there are two ways to recover it.
Setting a Key Undo Policy for a Fortanix DSM group: To prevent accidental sensitive operations on keys, Fortanix DSM allows users to configure a Key Operations Reversible Policy, which, when set, the keys go through a two-step process in which sensitive operations the sensitive operations are reversible for a specified period before becoming permanent. The following sensitive operations are reversible:
Change group
Destroy Key, Delete Key
Deactivate Key
Mark a key as compromised
Remove private key
Remove sensitive key operations such as encrypt, decrypt, sign, verify, and so on.
Figure 2: Key reversible policy
3.3 Restore From Full Backup
In a worst-case scenario where a key gets deleted and the above measures were not implemented, or if there is data corruption, it is still possible to restore a Fortanix DSM cluster from a previously taken backup. This would revert the cluster to an earlier state, which means that data created in the interim would be lost. However, if all other measures fail, this method ensures that an EKM key can still be restored.
4.0 Load Balancing
Fortanix DSM has built-in load balancing using round-robin and requires an additional Virtual IP to be assigned to the cluster. However, it also supports external load balancing such as F5 LTM and GTM. Round-robin load balancing is recommended.
5.0 Performance
There are three important aspects of performance: throughput, latency, and quality of service. For enterprises using Google Cloud EKM, there are often expectations regarding peak throughput and maximum latency. Additionally, they require these performance metrics to be predictable and consistent, which imposes quality of service (QoS) requirements.
Throughput – The clustered architecture of Fortanix DSM allows for a linear increase in capacity with the size of the cluster. Capacity planning is done by measuring the current load and estimating the capacity for a given cluster size, based on traffic received through the Google Cloud EKM interface.
Latency – Big Query and Google Compute Engine (GCE) expect consistently low latency to the EKM to operate efficiently. The biggest component of the latency is often the network latency between Google Cloud KMS and the EKM. As a result, the best latency for Cloud EKM is often obtained from a Google Cloud region closest to the deployment of Fortanix DSM. Conversely, Fortanix DSM should be deployed and used from a site that is closest to the Google Cloud region where BigQuery or GCE is running for good performance and low latency. The clustered architecture of Fortanix DSM enables low latency by replicating keys across a geographically distributed region and configuring a global load balancer to route traffic to the nearest region.
Quality of Service – A multi-tenant external key manager may be susceptible to a denial-of-service attack, where a rogue tenant consumes excessive resources for the KMS. Fortanix DSM allows configuration for a minimum quality of service that can be controlled by the system administrators to assure predictable and consistent performance for Google Cloud EKM.
6.0 Role-Based Access Control (RBAC)
As we have seen above, the Google Cloud EKM key is highly sensitive, and access to it must be managed very strictly by a very small set of administrators within an organization. This is achieved using a very elaborate role-based access control (RBAC) system in Fortanix DSM. Users and keys can be organized in separate groups, and access to keys for users is determined by their group membership and their assigned roles. By following the principle of least privileged access, it is possible to restrict access to a small number of users who can create and manage the EKM keys. As mentioned above, sensitive operations can further be restricted by configuring a quorum-based approval policy.
Figure 3: Quorum approval policy
7.0 Auditability
Auditability of operations is often a critical requirement for enterprises. While this may seem simple, getting a consistent set of logs from a cluster deployed across multiple sites is challenging. Fortanix DSM provides a secure way to store and manage such cluster-wide logs, capturing various types of operations, such as administrative (user creation, group creation, and so on), authentication (all login and logout actions are logged), and cryptographic (key creation, editing, usage, and so on).
Figure 4: Audit logs
The logs collected in Fortanix DSM can be forwarded to a log collection software or services in real-time with Splunk or any Syslog-based logging systems. Fortanix DSM also provides native support for forwarding logs to Google Cloud StackDriver. This enables users of Google Cloud EKM to stay in the Google Cloud ecosystem and use more native Google Cloud services.
.png?sv=2022-11-02&spr=https&st=2025-07-04T02%3A18%3A27Z&se=2025-07-04T02%3A37%3A27Z&sr=c&sp=r&sig=YjYQ9HQt5xVfTJL13%2B0rxQ3fr%2BBYAQk5p3JtR2iN6t8%3D)
Figure 5: Log management integrations
8.0 Frequently Asked Questions
How do I access Fortanix Data Security Manager (DSM)?
Fortanix DSM is a cloud-ready key management service that can be deployed in a public cloud, hybrid cloud, or on-premises infrastructure. Please check here to see which model suits your needs:https://www.fortanix.com/platform/data-security-manager.
We provide a free trial instance at https://smartkey.io/. Please keep in mind that this is a test instance and not supported for production use. Supported use for production workloads requires engaging Fortanix and Google Cloud. Please email [email protected] for more information.
Can I deploy Fortanix DSM in a private cloud?
Yes, Fortanix DSM can be deployed in a private cloud using Intel SGX-enabled processors. For on-premises deployments, Fortanix offers a FIPS 140-2 Level 3 appliance.
Where should I locate the Fortanix DSM system providing supporting Google External Key Manager cryptographic operations?
We suggest locating the Fortanix DSM system near the GCP region where your workload is running to minimize latency.
How many Fortanix DSM accounts can I create?
An organization may choose to create a single account or multiple accounts in Fortanix DSM. While a single account may be easier to manage and can be centrally administered, multiple accounts may be desirable for an organization with multiple business units that may want their own account administrators corresponding to their accounts. Regardless of the number of accounts, Fortanix DSM provides a single point of management across the entire deployment.
How to decide the IAM roles for administrators?
Customers should identify individuals for the Fortanix DSM roles such as SysAdmin, Sys Operator, Account Admin, Account Member, and Account Auditor. In some cases, the same individual can serve multiple roles. However, Fortanix recommends that high-value keys inside Fortanix DSM require a quorum approval process to provide additional security controls.
For every Fortanix DSM instance, Fortanix recommends having two Account Administrators and one Account Auditor.
In every account, there may be multiple applications that integrate with Fortanix DSM. The Account Administrator has the option to create a group for every application or use-case. Fortanix recommends that the application owner act as an account member and the group administrator. This allows the account member to invite other members from his team to his group.