1.0 Introduction
This article provides comprehensive best practices for the deployment, configuration, security, and operation of Fortanix-Data-Security-Manager (DSM), helping organizations maximize performance, resilience, and data protection. Additional information is available on the Fortanix Support Portal. For customer-specific guidance, training, or other professional services, please contact our Customer Success team.
2.0 Deployment Best Practices
2.1 Deployment Options
Select the optimal deployment option for your needs.
On-Premises (self-managed): Use the FIPS 140-2 Level 3 validated FX2200 hardware appliance or the new FIPS 140-3 Level 3 pending FX3400 hardware appliance for the highest levels of security and control. Most customers choose to operate in non-FIPS mode to access the latest features and algorithms. If you need to operate in strict FIPS mode, note that this is a factory setting, please contact Fortanix for further guidance on FIPS mode deployment architecture.
Virtual Appliance / Cloud (self-managed): Deploy the FIPS 140-2 Level 1 compliant virtual appliance in VMware or public cloud environments. When running in SGX-enabled environments (for example, Azure Confidential Computing), security is comparable to FIPS Level 2 or 3. This option is typically used where security requirements are less strict, in lab or test environments, or when cloud-based applications require ultra-low latency (although Fortanix DSM Accelerator is another option in such cases).
SaaS (managed service): If you want to avoid the overhead of building and maintaining a Fortanix DSM cluster in-house, we recommend using Fortanix DSM SaaS. As a leading HSM-as-a-Service solution, it simplifies operations, reduces management effort, and is designed with built-in high availability. Fortanix DSM SaaS leverages FIPS 140-2 Level 3 certified HSMs to securely store encryption keys, with all cryptographic operations performed within the hardware module for enhanced security.
For more information on the Fortanix DSM deployment option, refer to Fortanix Data Security Manager Deployment Options.
2.2 High Availability (For Self-Managed Deployments)
Fortanix DSM uses active-active clustering technology for high availability and disaster recovery (HA/DR); all keys, configurations, and logs are replicated across multiple physical or virtual devices (“DSM nodes”).
It is recommended to deploy clusters with at least three DSM nodes distributed across multiple data centers or cloud availability zones to ensure fault tolerance. The greater the number of nodes and/or physical locations, the higher the level of redundancy and resilience. We recommend using an odd number of nodes in the cluster to achieve greater fault tolerance.
A single-node cluster provides no HA or DR but may be suitable for a simple lab or test environment. A two-node cluster provides DR only. A three-node cluster provides both HA and DR.
Use network interface bonding on physical appliances to aggregate multiple network interfaces for redundancy and higher throughput.
Configure load balancing (Layer 3 or Layer 4) to distribute client requests evenly across cluster nodes, allowing horizontal performance scaling.
For multi-site deployments, it is recommended to use a Global Traffic Manager (GTM) to route traffic to the nearest available data center. Within each data center, use a Local Traffic Manager (LTM) to distribute traffic across the available nodes.
Monitor cluster quorum status and understand Read-only mode behaviour to maintain business continuity during partial outages.
Use external Layer 3 or Layer 4 load balancers to distribute traffic across multiple data centers or cloud availability zones, reducing latency and improving availability.
Consider adding a separate DR node or building a DR cluster with continuous backup and restore, particularly for smaller clusters or where there is concern about the simultaneous loss of all nodes. A DR node also provides rollback capability in the event of a failed software update.
For on-premises deployments, consider maintaining a cold spare appliance to enable rapid replacement if an active device fails, thereby restoring full resilience.
2.3 High Availability (For SaaS Deployments)
DSM SaaS offers a 99.95% availability SLA. However, for mission-critical use cases where any downtime is unacceptable, consider implementing local resilience capabilities (For example, on-premises DR or Fortanix DSM Accelerator).
2.4 Time Synchronization (For Self-Managed Deployments)
Configure NTP (Network Time Protocol) on all nodes to ensure accurate timekeeping, which is essential for cryptographic operations and audit log accuracy.
Use internal NTP servers if public internet access is restricted.
For more information, refer to Identify NTP (Network Time Protocol) Sources.
2.5 Deployment Configuration Settings
<sealing key policy>
<attestation>
<backup>
3.0 Configuration Best Practices
3.1 Account and Group Policies
Define group policies to manage permissions and quorum requirements for sensitive operations.
Use account-level cryptographic policies to enforce allowed key types, sizes, and operations, ensuring compliance with security standards.
3.2 Read-Only Mode Configuration
Label data centers to enable Read-Only mode operation during network partitions or outages.
Understand the limitations of Read-Only mode: no write operations, no key rotations, no user invitations, only read and cryptographic operations are permitted.
3.3 Monitoring and Alerting
Integrate DSM with external monitoring tools (for example, Sensu) to track service health and performance.
Configure alerts for critical events such as quorum loss, node failures, or security policy violations.
For more information, refer to Services to be Implemented.
3.4 Logging and Audit Management
Forward DSM logs to external log management systems (for example, SIEM) for centralized analysis and long-term retention.
Configure log retention policies to manage audit log size on the live system and ensure compliance with organizational data governance requirements.
For more information, refer to Services to be Implemented.
3.5 Network Configuration
Both IPMI and DSM Node access must be configured with static IPs.
4.0 Security Best Practices
4.1 Account-Level Security
Implement Single Sign-On (SSO) integration with identity providers to centralize authentication and improve the user experience.
Create a separate service account to enable password-based authentication for break-glass scenarios when the SSO service is unavailable. Configure Two-Factor Authentication (2FA) for UI users to enhance security.
Use custom roles to implement a least-privilege model, granting only the necessary permissions to users and administrators.
Configure a Quorum approval policy at the account level to prevent unintended changes by any administrators.
4.2 Network and Access Controls
Restrict network access to Fortanix DSM nodes using firewalls and VLAN segmentation. For more information, refer to Firewall Rules.
Restrict IPMI access using VLAN segmentation and limit it to specific users.
Regularly review and update access policies and user roles.
Configure Quorum approval policies to control privileged operations.
4.3 Key Management Best Practices
Rotate keys, secrets, and certificates regularly, in accordance with organizational policies.
Securely store private keys inside Fortanix DSM, and assign operations and permissions as needed.
Create cryptographic keys with a deactivation date to ensure they are not used indefinitely.
Configure a “Key undo policy” to prevent accidental key loss.
Create a “Key metadata policy” to ensure no keys are generated without required custom attributes (for example, project ID, requestor name, and so on).
4.4 Cluster Master Key Rotation
Rotate the Cluster Master Key of a self-managed cluster once a year to ensure the Fortanix DSM cluster uses a new cluster master key (CMK) for deriving other keys.
5.0 Operational Recommendations
5.1 Backup and Disaster Recovery
Perform regular, automatic backups (for example, daily). Note that existing backups are invalidated by a Fortanix DSM software update, so a manual backup should be performed immediately after such an update.
Test recovery procedures regularly to ensure minimal downtime during failures.
Store backups in secure storage to ensure they are protected from corruption or unauthorized modification.
For more information, refer to Services to be Implemented.
5.2 Software Updates and Patch Management
Keep the Fortanix DSM appliance and software up to date with the latest patches and releases from Fortanix (at least the n–1 release). Note that software updates can be performed without system downtime.
Schedule updates during maintenance windows and validate cluster health before and after the update.
Maintain a separate pre-production cluster to validate new Fortanix DSM software releases within your environment before deploying them to the production cluster.
5.3 Documentation
Document the system architecture, deployment configuration, roles, and operational procedures, including DR scenarios.
6.0 References
For information on pre-installation checks, refer to Pre-Installation.