1.0 Introduction
This article describes how to integrate Fortanix-Data-Security-Manager (DSM) with External logging systems. Fortanix DSM automatically maintains an internal audit log of system operations. You can configure Fortanix DSM to send these audit log entries to an external logging system.
This article explains how to configure Fortanix DSM to send audit logs to the following external logging systems:
Splunk
Google Cloud’s operations suite
Syslog Server
Azure Log Analytics (Azure Monitor)
Typical enterprises have a requirement to collect and maintain logs of all systems including Fortanix DSM in a single place. Enterprises write rules with external logging systems such as Splunk, Google Cloud’s operations suite, Syslog, and Azure Log Analytics to define rules and generate actions such as alerts, emails, and so on to match on logs or events. Fortanix DSM supports pushing logs/system events to Splunk, Google Cloud’s operations suite, Syslog, and Azure Log Analytics for external logging.
2.0 Fortanix DSM External Logging
NOTE
Only an account administrator can set up integration with external logging systems.
In the Fortanix DSM user interface (UI), navigate to Settings → LOG MANAGEMENT tab.
.png?sv=2022-11-02&spr=https&st=2025-05-28T23%3A04%3A02Z&se=2025-05-28T23%3A28%3A02Z&sr=c&sp=r&sig=pByvIaI%2Byn4F3TBGsmvRcMWNQ8%2BOeDPMHl21El4uQxs%3D)
Figure 1: Log Management tab
2.1 Fortanix DSM Audit Log
The Fortanix DSM external event logging is configured on a per-account basis. Logs or events of an account are not visible to another account within an enterprise. Fortanix DSM automatically maintains an internal audit log of system operations.
To view the audit log, click the Audit Log menu item in the Fortanix DSM UI.
For convenience, when viewing the details of a Security-object and other Fortanix DSM objects, the most recent audit log entries applicable to the object are shown in the right-hand pane in the detailed view of a security object.
2.2 Set Retention Period for Audit Log
By default, audit log entries older than three months are automatically deleted.
Perform the following steps to set the retention period of audit logs for each account:
In the Fortanix DSM UI, navigate to Settings → LOG MANAGEMENT tab.
In the Retention period for Audit Logs section, click EDIT to set the retention period.
Select the Keep log entries forever option to retain the audit logs permanently or specify a future date.
Figure 2: Set retention period
Click SAVE to save the changes.
NOTE
This setting can only be enabled if you have an account Quorum approval policy configured with the Log Management option selected, since changes to the log management settings require a quorum approval.
Audit logs that have already been forwarded to external log management integrations such as Syslog, Splunk, and so on will not be impacted because of this setting. This is applicable for all accounts, including system administration audit logs.
2.3 Log Invalid API Requests
Applications may sometimes send invalid API requests that result in 4XX errors, such as a 400 (Bad Request) error. Fortanix DSM logs them through the LOG MANAGEMENT feature to assist with debugging.
In the Fortanix DSM UI, navigate to Settings → LOG MANAGEMENT tab.
On the Log management page, enable the Logging invalid API requests toggle.
Figure 3: Logging invalid API requests
Click the Audit Logs tab in the Fortanix DSM UI to view the 4XX logs.
2.4 High Volume Security Objects
In scenarios where a security object is used for cryptographic operations with very high usage, audit logging related to these operations can be explicitly disabled for the security object. This is the only scenario where audit logs can be disabled for an object.
NOTE
Audit logs related to only cryptographic operations are disabled. Logs related to key management operations on the security object are still enabled.
Perform the following steps to disable the audit log on an existing security object:
Go to the detailed view of the security object and disable the Keep detailed log for the object toggle.
If the group has a quorum policy configured, the Quorum approval request dialog box displays HIGHVOLUME under the Key operations permitted section. The presence of the HIGHVOLUME operation indicates a request to disable audit logging.
Perform the following steps to disable the audit log for a security object during object creation:
Scroll to the bottom of the security object Generate or Import page.
Clear the Keep detailed log for the object option.
2.5 Log Management
Currently, Fortanix DSM supports the following logging systems:
Splunk
Google Cloud’s operations suite
Syslog
Azure Log Analytics (Azure Monitor)
To integrate with the logging systems, navigate to the Settings → LOG MANAGEMENT tab in the Fortanix DSM UI.

Figure 4: Custom log management integrations
It is possible to have more than one integration active at the same time. Logs will be pushed from Fortanix DSM to all logging facilities that are configured.
NOTE
Only an account administrator in Fortanix DSM can add the log management integrations with Splunk, Google Cloud’s operations suite, Syslog, and Azure Log Analytics.
2.6 Sending Audit Logs to Splunk
You can configure Fortanix DSM to send audit log entries to a Splunk server using the HTTP Event Collector (HEC).
Perform the following steps to configure logging events to Splunk:
Navigate to the Settings → LOG MANAGEMENT tab.
In the Custom Log Management Integrations section, click ADD INTEGRATION for Splunk.
On the Splunk Log Management Integration form, enter the following:
Host: Enter the hostname or IP address of your Splunk server.
Enable HTTPS: Select this check box to communicate with the Splunk server over a secure connection using HTTPS (recommended). Also, select the Enable SSL check box in the Splunk Global Settings. Refer to the Appendix for a sample screenshot.
NOTE
If you are using an HTTP connection, clear the Enable HTTPS check box in the Fortanix DSM Log management screen and also clear the Enable SSL check box in the Splunk Global Settings. Refer to the Appendix for the screenshot.
Host validation: Select the Validate host check box to ensure that the Splunk server hostname mentioned above matches the hostname specified in the server certificate.
Validate certificate:
If you are using a certificate signed by a well-known public CA, select Global Root CAs.
If your organization uses a self-signed certificate issued by an internal Certificate Authority (CA), select Custom CA Certificate. Click UPLOAD A FILE to upload your CA certificate. When Fortanix DSM, acting as a client, connects to the Splunk server and receives the server’s certificate, it validates the certificate using the uploaded custom CA certificate.
Run the following command to generate the CA certificate:
openssl s_client -connect <endoint/ipaddress>:port -showcerts
Where,
ipaddress
refers to the IP address of the Splunk server.port
refers to the value of the Management port, under Server settings → General settings in the Splunk Server. Refer to the Appendix for the sample screenshot.
If the Custom CA Certificate's Common Name (CN) does not match the server on which Splunk is deployed, clear the Validate host check box. This prompts Fortanix DSM to ignore the hostname of the Splunk deployment instance. In this case, only the certificate chain will be validated.
Port: The default port for the Splunk server is 80. If you are running on a different port, add the applicable port number. If you enable HTTPS above, then the default port number is 443.
Index: Enter the name of the Splunk index to submit events. Use the same index name configured in your Splunk instance. When you push the logs to Splunk, you must push them to a specific index. Fortanix DSM sends this value to the Splunk server. You can set the index name as needed to differentiate logs from various sources. For example, you can push Fortanix DSM logs to a Splunk index named
SDKMS
. Refer to the Appendix for a sample screenshot.Authentication token: Enter a valid authentication token to connect to the HTTP Event Collector (HEC) of your Splunk instance. Fortanix DSM uses this token to authenticate as a client and push events to Splunk. For instructions on generating HEC authentication tokens, refer to the Splunk documentation.
NOTE
For security reasons, the authentication token is not displayed in the interface when editing an existing configuration.
Figure 5: Splunk integration form
Click ADD INTEGRATION to save the Splunk integration.
2.7 Sending Audit Logs to Google Cloud’s operations suite
You can configure Fortanix DSM to send audit log entries to Google Cloud’s operations suite.
Perform the following steps to configure logging events to Google Cloud’s operations suite:
In the Custom Log Management Integrations section, click ADD INTEGRATION for Google Cloud’s operations suite.
On the Google Cloud's operations suite Log Management Integration form, enter the following:
Log ID: Enter the log ID of the log to write to. The log ID must be URL-encoded and included within the log name, which is the resource name of the log to which this log entry belongs. For example,
organizations/1234567890/logs/cloudresourcemanager.googleapis.com%2Factivity
For more information, refer to Google Cloud's Operations Suite reference URL.
Service account key: Upload the service account key or configuration file. To connect Fortanix DSM to Google Cloud’s Operations Suite, you must upload a configuration file that contains the service account key and related authentication details using UPLOAD A FILE.
Figure 6: Google cloud operation integration form
Click ADD INTEGRATION to save the Google Cloud Operation integration.
2.8 Sending Audit Logs to Syslog
You can configure Fortanix DSM to send audit log entries to the Syslog server.
Perform the following steps to configure logging events to the Syslog:
In the Custom Log Management Integrations section, click ADD INTEGRATION for Syslog.
On the Syslog Log Management Integration form, enter the following:
Host: Enter the hostname or IP address of your Syslog server.
Enable TLS: Select this check box to communicate with the Syslog server over a secure connection using TLS.
Host validation: Select the Validate host check box to ensure that the Syslog server hostname mentioned above matches the hostname specified in the server certificate. To skip hostname verification, clear the Validate host check box.
Validate certificate: You can connect to the Syslog server over a non-secure connection or a secure TLS connection. Depending on the type of TLS certificate that the Syslog server is using:
If you are using a certificate signed by a well-known public CA, select Global Root CAs.
If your organization uses a self-signed certificate issued by an internal Certificate Authority (CA), select Custom CA Certificate. Click UPLOAD A FILE to upload your CA certificate. When Fortanix DSM, acting as a client, connects to the Syslog server and receives the server’s certificate, it validates the certificate using the uploaded custom CA certificate.
Port (TCP): The default port for the Syslog server is 514. If you are using a different port, update the port number accordingly.
Facility: When you log an event in Syslog, you can choose to log it in different facilities. Use this setting to filter logs by a specific facility, such as User, Local0, Local1, and others that are well-defined in the Syslog protocol. For example, configure Fortanix DSM to use the Local0 facility to easily filter logs from a specific appliance.
Figure 7: Syslog integration form
Click SAVE to add the Syslog integration.
2.9 Sending Audit Logs to Azure Log Analytics
You can configure Fortanix DSM to send audit log entries to Azure Log Analytics in the Azure Portal to write log queries and interactively analyse the Fortanix DSM log data.
Perform the following steps to configure logging events to the Azure Log Analytics:
Ensure that you have already created a Log Analytics Workspace in the Azure portal. For more information, refer to Create a Log Analytics workspace. In the log analytics workspace, click the Agents tab to see the Workspace ID and Primary key.
Figure 8: Workspace ID
In the Custom Log Management Integrations section, click ADD INTEGRATION for Azure Log Analytics.
On the Azure Log Management Integration page, enter the following:
Workspace ID: Enter the workspace ID, which is a globally unique identifier (GUID) that identifies your Log Analytics workspace in the Azure portal. You can find this value in Step 1. For more information on how to create a log-analytics workspace, refer to Create a Log Analytics Workspace.
Primary shared key: Enter the primary shared key, which is the primary key of your Log Analytics workspace in the Azure portal. You can locate this key in Step 1.
Figure 9: Azure integration form
NOTE
For security reasons, the Primary Shared Key is not displayed in the interface when editing an existing shared key.
Click SAVE CHANGES to save the Azure Log Analytics integration.
In the Azure portal, execute the following query in Log Analytics and click Run:
DSM_AUDIT_LOG_CL
Figure 10: Run the query
Running the query retrieves Fortanix DSM audit log entries from Azure Log Analytics, allowing you to analyze, filter, and monitor them.
The Custom Log Type is set to “
DSM_AUDIT_LOG_CL
” for all event logs published to the Azure Log collector from Fortanix services. This field is set in theHTTP POST
request header of all the logs published to the Azure log collector, and therefore, it is used to query logs from Fortanix services in Azure Log Analytics Workspace. For more information, refer to Use Queries in Log Analytics.Figure 11: DSM event log query
2.10 Sending Audit Logs to Rapid7 InsightIDR
For a detailed list of instructions on how to export the Fortanix DSM log files to the Rapid7 InsightIDR centralized log management utility, refer to Using Fortanix DSM with Rapid7 InsightIDR.
2.11 Log Structure
A system event in Fortanix DSM generates a log that has the following components:
Log Severity – Severity of the message (Critical issues, Errors, Warnings, and Info). As of today, the backend for Logging only supports the Severities – “Info” and “Errors”. A severity is logged as “Error” when logging requests have failed for some reason, such as client error or internal server error. For all the other cases where the audit logs describe crypto operations, object updates, and so on, the severity is logged as “Info”.
Groups – The Fortanix DSM group that the event belongs to.
IP-Address – This is the IP address of the client/user whose request triggered the log message. The client IP is recorded whenever it is available. For some logs, the IP address field might appear empty due to one of the following reasons:
When Kubernetes is used for load balancing instead of an external load balancer, Kubernetes reroutes requests and does not preserve the original client IP address. This is something Fortanix will address in the future.
Since this was a new field introduced recently, the older logs would have the IP_Address field empty.
Apps/Users – The log message can be a user event or an application event.
Time – Timestamp of when the event occurred.
Type – Type of event (Administrative, Auth, and Crypto Operations).
Administrative - Operations that users can perform, such as importing/updating/deleting a key and creating/deleting/updating apps, groups, and accounts, are classified as “Administrative” events.
Crypto Operation – Operations such as generating/encrypting/decrypting/signing/verifying/wrapping/unwrapping a key are classified as “Crypto Operation” events.
Auth – Operations such as logging in or logging out, applications authenticating to get a session, or terminating their session are classified as “Auth” events.
When a log is pushed to a third-party external logging system, the log structure with all the log components above is sent to the server.
The format of a message logged on any external logging system is as follows:
<message string> ip_addr=<corresponding client ip address> acct_id=<corresponding account id> groups=[corresponding group ids] actor=<Actor type>:<Actor Id> obj=<Object Id> action=<Action type>
Where,
All the
ids
are UUIDs of the respective objectActor type
can be a User or AppAction type
can be Administrative, Auth, or Crypto Operation
For Example,
User "[email protected]" created key "key_test" ip_addr=123.123.123.123 acct_id=8fb9b132-0b68-4d33-aba2-f1f9db3ab0e9 groups=[5f1d12e9-614a-4f5b-a4ed-837d9fb001b8] actor=User:9dbd5192-ee09-46f6-89fd-812e96863aa4 obj=3da3bf54-610b-4e89-816d-d4931f59f102 action=CRYPTOOPERATION
NOTE
Time and severity are set based on the logging system and they are not included in the actual message logged.
3.0 DSM Performance With/Without External Logging System
You can integrate both Splunk and Syslog servers with Fortanix DSM simultaneously. Below are the DSM performance numbers with/without Splunk and Syslog.
Item | Specification |
---|---|
Number of Cores | 18 (6 core per DSM node) |
CPU | Intel(R) Xeon(R) CPU E5-2673 v4 @ 2.30GHz |
RAM | 32 GiB |
DSM With/Without External Logging System | Throughput (Operations/second on a 3-node S2 cluster) |
---|---|
DSM with Splunk and Syslog integration (AES 256: CBC Encryption) | 4,587 |
DSM without Splunk and Syslog integration (AES 256: CBC Encryption) | 4,812 |
NOTE
A 3-5% performance degradation is seen when both Splunk and Syslog servers are integrated with Fortanix DSM.
The throughput observed above may vary depending on the environment and circumstances.
4.0 Appendix
The following are the Splunk Server screenshots:
If you are using an HTTPS connection, then in the Global Settings:
Select the Enable SSL check box.
Select the Default Source Type as
sdkms_audit
.Figure 12: Enable SSL
Port number on the Splunk server used for generating the Custom CA Certificate.
Figure 13: Management port number
The index value in the Fortanix DSM Splunk Log Management Integration form should be the same as the Default Index value.
Figure 14: Fortanix DSM system events