1.0 Infrastructure Requirement
It is important to understand the Google EKM process flow and during the Fortanix-Data-Security-Manager (DSM) cluster configuration you should keep the following in mind:
In a Google EKM integration for any Google services, the Google service reaches out to Fortanix DSM service to access the CMEK (Customer Managed Encryption Key).
For any on-premises cluster, you need to expose the Fortanix DSM service to GCP service with proper network access restrictions and considerations.
EKM Access Flow Google Services
2.0 Pre-requisites for Integration
The Fortanix DSM 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 External Key Manager API in your Google project.
Choose a Google Service Account with Key Management Privileges.
You must Choose Google Service Account as the authentication method in the method options.
Create an app access policy that includes Key Justification Reasons. You can choose to allow all requests or customize it according to your requirement. Access Policy can be created for a new app or an existing app.
3.0 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 and use the new EKM key version URL to rotate the key in Google KMS. This process is manual.
4.0 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– External Key Manager (EKM) used with Cloud EKM Service should be at least as available as the GCP KMS service with which it integrates.
Disaster recovery- If EKM is destroyed and keys are lost, there should be a way to recover the keys.
Load balancing – Fortanix Data Security Manager (DSM) provides automatic load balancing for hybrid or multi-cloud deployments.
Performance- Latency and throughput should be within acceptable limits.
Role-based access control- Access to the EKM keys should be tightly controlled in the external key manager.
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.
4.1 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 provide high availability. The cluster allows for the service to be available and the keys to be usable as long as a majority of nodes are available in the cluster. In case of loss of a majority of nodes, Google Cloud EKM keys are still usable, but the ability to create new keys is lost.
The cluster of nodes can easily be spread across physically separate data centers, thus allowing for failure of entire data centers or failure of connectivity between data centers. The service still stays fully available if a majority of nodes are available in the cluster. In a multi-data-center deployment scenario, a global load balancer is used to route incoming traffic to the nearest data center.
4.2 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, either accidentally by a human error, through a software error, or through a hardware failure or disaster at the facilities. Services like Big Query would lose all data in this scenario, so it is critical to have measures to recover from such a disaster.
4.2.1 Disaster Prevention
Preventing against accidental or malicious deletion of an EKM key or change of permissions: Fortanix DSM supports quorum-based policies to build an approval process where multiple administrators need to approve before a sensitive action can be performed with a key, for example, deletion of key or change of permissions. Customers are recommended to configure a quorum policy with multiple administrators on the group which they use to create and store the Google Cloud EKM keys.
Fortanix DSM provides several mechanisms to prevent disasters from happening and to recover from disasters when they might happen.
4.2.2 Disaster Recovery
In case if the key does get deleted or lost even after having a quorum policy configured, there are two ways to recover the key.
Setting a Key Undo Policy for a Fortanix DSM group: To stop accidental sensitive operations on keys, Fortanix DSM allows a user to add a Key Undo Policy which when set, the keys goes through a 2-step process where the sensitive operations are reversible until a certain time set by the user before the changes become 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 encrypt, decrypt, sign, verify and so on.
Figure 1: Key Reversible Policy
4.2.3 Restore From Full Backup
In a worst-case scenario where a key gets deleted and the above measures were not implemented, or there is some other form of data corruption, it is still possible to restore a cluster of Fortanix DSM from a backup taken at some point of time previously. This would revert the state of the cluster to an earlier time which means that data created in the interim would be lost. However, if all other measures fail, this method would ensure that an EKM key can still be restored.
4.3 Load Balancing
Load balancing is inbuilt into Fortanix DSM using round-robin and requires an extra 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.
4.4 Performance
There are three important aspects of performance – throughput, latency, and quality of service. For enterprises using Google Cloud EKM, they may have a certain peak throughput and maximum latency they expect from the external key manager. They also want these numbers 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 having an estimate of the capacity for a given cluster size for traffic coming 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. The implication of this is that 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 Big Query 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 may hog all 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.
4.5 Role-Based Access Control (RBAC)
As we have seen above, the Google Cloud EKM key is very sensitive, and access to the key should be managed very strictly by a very small set of administrators in an organization. This is achieved using a very elaborate RBAC system in Fortanix DSM. Users and keys may be organized in separate groups, and access to keys for users is determined by their group membership and roles in those groups. By following the principles 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, actions can further be restricted by configuring a quorum-based policy.
Figure 2: Quorum Policy
4.6 Auditability
Auditability of operations is often a major 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 3: 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. We also have 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.
Figure 4: Log management integrations
5.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 then to invite other members from his team to his group.