Records
Audit records are logs of auditable events viewable in CipherTrust Manager in a user-friendly JSON format. To view audit records for CipherTrust Manager activity in the GUI, go to Records > Server Records.
You can also view the audit records that are uploaded from the CipherTrust Manager Clients (for example, CTE). To view these records in the GUI, go to Records > Client Records. Consult documentation for a specific connector for information on configuring and interpreting client records. The Logs chapter of CTE Agent for Linux Advanced Configuration and Integration Guide contains details on CTE client record format and effects codes.
Audit records can be locally fetched and searched using the CipherTrust Manager REST API, CLI, or the GUI. The records available through these queries are scoped to the domain permissions of the logged in user.
Records can also be sent to an external syslog server and to an Elasticsearch or Loki log forwarder.
Both server and client records can be configured to raise alarms.
Note
To reduce cluster traffic and disk usage for deployments that support a large number of transactions, it is recommended to configure CipherTrust Manager to disable local database audit logging and enable logging using remote Syslog servers.
Server Records Parameters
Parameters (Columns) | Description |
---|---|
Severity | Severity of the record. Severity types are: • INFO • CRITICAL • WARNING • ERROR |
Event Created | Date and time when the event was created. |
Action | Operation performed by the user. |
Details | Details associated with the operation performed. |
By | User who initiated the operation. |
Source | User friendly name set on the CipherTrust Manager server where the logs are generated. Note: To see the real source of the incoming records, the user should change the server name so that each CipherTrust Manager node in the cluster has a unique name. To change the server name, go to Admin Settings > System Properties. Set name in the Server Info field. |
Client | IP of the client from where the operation request has been received. |
Disabling local database audit logging
Server and client audit records are logged to a local database by default. This is suitable for production systems and clusters with a limited load. However, for clusters that support a large number of transactions, it is recommended to configure CipherTrust Manager to disable logging to a local database and enable logging using a remote Syslog server. This significantly reduces cluster traffic and disk usage.
There are additional technical preview options to view records when local database logging is disabled, which are not yet recommended for production usage. When local database logging is disabled, records for the local node are automatically logged to an internal Loki Grafana log aggregation microservice, where they can be queried. You can also configure log forwarders to view records aggregated from the entire cluster.
Note
Only data for the local node is logged to the Loki Grafana microservice, not any other cluster nodes.
Example
ksctl properties modify -n ENABLE_RECORDS_DB_STORE -p false
Note
This is a cluster wide setting and only needs to be run against one node in the cluster.
Note
To prevent the Server Audit Records database table from growing too large, it is automatically trimmed when it reaches 10 million records in size. If a permanent record is required, syslog should be used and the audit records stored elsewhere.
Listing and Querying Records With Local Database Logging
If your server and client audit records are logged to the local database, as is default, you can list server audit records with ksctl records list
and client audit records with ksctl client-records list
.
The response looks like:
{
"skip": 0,
"limit": 10,
"total": 40,
"Resources": [
{
"id": "18ef98f1-0704-4dec-a6f0-e87a581ce52f",
"uri": "kylo:kylo:audit:records:18ef98f1-0704-4dec-a6f0-e87a581ce52f",
"account": "kylo:kylo:admin:accounts:kylo",
"application": "system:system:admin:applications:system",
"devAccount": "kylo:kylo:admin:accounts:kylo",
"createdAt": "2018-05-22T18:34:05.239823Z",
"message": "Create Token",
"service": "kylo",
"requestId": "45a8dcef-0b9e-44e2-b3e1-51b3d2ef99ca",
"instanceId": "",
"instanceTime": "0001-01-01T00:00:00Z",
"instanceTz": "",
"success": true,
"username": ""
}
]
}
There will be a number of records returned (10 shown in the example above). Most have been removed in the above example for space reasons. Note that the response indicates that there are 40 records available ("total": 40,). These records can be returned with options in the ksctl records and ksctl client-records commands to filter which records are returned. Type the following commands to get more information:
ksctl records list --help
ksctl client-records list --help
Listing and Querying Records Without Local Database Logging
Caution
This feature is a technical preview for evaluation in non-production environments. A technical preview introduces new, incomplete functionality for customer feedback as we work on the feature. Details and functionality are subject to change. This includes API endpoints, UI elements, and CLI commands. We cannot guarantee that data created as part of a technical preview will be retained after the feature is finalized.
If you have disabled local database logging, you can list records in the Loki Grafana microservice with ksctl loki query_range --server-audit-records
and ksctl loki query_range --client-audit-records
from the previous 10 days. Records older than 10 days are deleted to ensure performance.
You can also query both server audit records and client audit records from the local CipherTrust Manager node to return records during a specified time range.
Note
Only data for the local node is logged to the Loki Grafana microservice, not any other cluster nodes.
The query parameters follow Loki Grafana's LogQL syntax for doing a query over a specified time range. Use ksctl loki query_range
commands to input parameters for limit
, start
, end
, step
, interval
, and direction
.
Configuring remote Syslog server
Server audit records can optionally be sent to one or more external Syslog server(s). By default, server audit records are stored in the local database and continue to do so even if Syslog connections are configured. Each server audit record will be sent to each configured Syslog connection.
A Syslog connection can either use UDP or TCP + TLS as the transport protocol. When TCP + TLS is used a trusted CA certificate in PEM format must also be provided.
All Syslog messages are generated with severity notice and facility local0.
An example entry looks as follows:
2019-08-12 06:22:16 keysecure1 KeySecure: <134>1 2019-08-12 06:22:16 keysecure KeySecure - b7999852-dd64-46e9-b924-c3999eca9fad [msg="Update Syslog Connection" sev="6" details="'Update Syslog Connection' succeeded”
({"createdAt":"2019-08-12T06:22:16.113081Z", "details":{"id":"e847e529-d331-45f9-a494-83ee7ce6ab69"},"message":"Update Syslog Connection","service":"kylo","success":true,"username":"admin","severity":"info","lineage":"","source":""})"]
The first time stamp is generated and added by Syslog and the second time stamp is the time of the actual audit record.
In a multi-node clustered environment, the Syslog connection configurations are automatically synchronized and each node is aware of all Syslog servers. The Syslog message is sent from the currently active node. This means that if an event that results in a server audit record is performed on node 1, the Syslog message originates from node 1. Similarly, if a server audit event is performed on node 2, the Syslog message originates from node 2.
Note
The Syslog connection configuration can take up to five minutes to apply to all nodes in the cluster.
Syslog Connections API
The Syslog connections API supports listing, adding, deleting, getting, and updating Syslog connections. Refer to the API guide, CLI Guide, or the GUI for more details.
Refer to Syslogs for instructions on configuring connection to a Syslog server on the CipherTrust Manager console.
Configuring alarm triggers based on a record
CipherTrust Manager can be configured to trigger one or more alarms based on the content of a record. To create an alarm configuration:
Log on to the CipherTrust Manager console as administrator.
In the left pane, click Records. Click Server Records or Client Records depending on your desired record type.
Click the Alarm Configurations tab.
Click Configure Alarm Configuration. The Alarm Config - Create dialog box is displayed.
Specify the following details:Severity: Defines the nature of the alarm. It can be Info, Error, Critical, or Warning.
Note
This value is independent from the severity included with server records. If you want an alarm to inherit the severity of a server record, you can create the alarm configuration using the REST API or CLI and omit the severity option.
Name: Name of the alarm.
ErrorThreshold: The maximum number of times the trigger condition is met in the specified time Interval before the alarm is raised.
Interval: The time duration in seconds, in which if the trigger condition is met for a defined number of times (Error Threshold value) , the alarm is raised.
Description: A description for the alarm.
Condition: Conditional properties/events that triggers an alarm.
Note
Multiple alarms may be triggered using a single record.
Example (For Windows)
Note
In Windows environment, ensure to use backslash ('\') as an escaped character with double quotes (\").
!yaml
ksctl records alarm-configs create --name "Weak RSA Key" --description "RSA key should be 2048 bits or higher" --severity "critical" --condition "input.success; input.message == \"Create Key\"; input.details.algorithm == \"RSA\"; input.details.size <= 1024"
Example (For Linux)
ksctl records alarm-configs create --name "Weak RSA Key" --description "RSA key should be 2048 bits or higher" --severity critical --condition 'input.success; input.message == "Create Key"; input.details.algorithm == "RSA"; input.details.size <= 1024'
Response (For Windows and Linux):
{
"id": "4bf23269-3985-42f3-995c-8f3c8f8b6543",
"uri": "kylo:kylo:audit:alarm-configs:4bf23269-3985-42f3-995c-8f3c8f8b6543",
"account": "kylo:kylo:admin:accounts:kylo",
"application": "ncryptify:gemalto:admin:apps:kylo",
"devAccount": "ncryptify:gemalto:admin:accounts:gemalto",
"createdAt": "2019-08-27T14:37:19.145946719Z",
"name": "Weak RSA Key",
"condition": "input.success; input.message == \"Create Key\"; input.details.algorithm == \"RSA\"; input.details.size <= 1024",
"description": "RSA key should be 2048 bits or higher",
"severity": "critical"
}
To trigger this alarm, create a weak RSA key:
$ ksctl keys create --name mysmallkey --alg RSA --size 1024
The alarm should be triggered and this can be confirmed by listing the alarms:
$ ksctl alarms list --state on
Here is an abbreviated response for brevity:
{
"resources": [
{
"name": "Weak RSA Key",
"state": "on",
"description": "RSA key should be 2048 bits or higher",
"severity": "critical",
"details": {
"details": {
"id": "f2ec44f6977edf2d6ff7fa327b5499301732dc6b395284a71e47ac0346cf72d6",
"uri": "kylo:kylo:vault:keys:mysmallkey-v0",
"name": "mysmallkey",
"size": 1024,
"ownerId": "local|fa0e4dfa-e6fd-413b-a4a0-48c356cf0557",
"algorithm": "RSA",
"usageMask": 3,
"objectType": "Private Key"
},
"message": "Create Key",
"success": true,
}
}
]
}
Creating Alarm Trigger for Certificate Expiration
If it is desired to create an Alarm Trigger (and receive Email Notifications) for these events, follow the steps mentioned in the Configuring alarm triggers based on a record section, and specify the Condition action as input.message == "Certificate Expiry Check"
.
Note
The action Certificate Expiry Check can be created in the root domain only.
After saving this Alarm Configuration, the recipients in the email address list will receive email notifications every time a certificate expiration related record is logged. The emails will contain the certificate IDs, expiration dates, and the domain name.
Creating Alarm Trigger for Client Certificate Expiration
If it is desired to create an Alarm Trigger (and receive Email Notifications) for these events, follow the steps mentioned in the Configuring alarm triggers based on a record section, and specify the Condition action as input.message == "Client Certificate Expiry Check"
.
Note
The action Client Certificate Expiry Check can be created in the root domain only.
After saving this Alarm Configuration, the recipients in the email address list will receive email notifications every time a client certificate expiration related record is logged.
The emails will contain the following information:
Client name
Client type if available
Whether certificate is expired
Expiration duration in days (if
expired
flag isfalse
) or expired duration in days (ifexpired
flag istrue
)Domain name
Creating Alarm Trigger for Connection Certificate Expiration
If it is desired to create an Alarm Trigger (and receive Email Notifications) for these events, follow the steps mentioned in the Configuring alarm triggers based on a record section, and specify the Condition action as input.message == "Connection Certificate Expiry Check"
.
Note
The action Connection Certificate Expiry Check can be created in the root domain only.
After saving this Alarm Configuration, the recipients in the email address list will receive email notifications every time a client certificate expiration related record is logged.
The emails will contain the following information:
Domain name
Whether certificate is expired (
expired
flag set totrue/false
)Expiration duration in days (
days_since_expired
, ifexpired
flag istrue
) and (days_to_expire
, ifexpired
flag isfalse
)
Creating Alarm Trigger for Interface Certificate Expiration
If it is desired to create an Alarm Trigger (and receive Email Notifications) for these events, follow the steps mentioned in the Configuring alarm triggers based on a record section, and specify the Condition action as input.message == "Interface Certificate Expiry Check"
.
Note
The action Interface Certificate Expiry Check can be created in the root domain only.
After saving this Alarm Configuration, the recipients in the email address list will receive email notifications every time a client certificate expiration related record is logged.
The emails will contain the following information:
Interface name
Whether certificate is expired (
expired
flag set totrue/false
)Expiration duration in days (
days_since_expired
, ifexpired
flag istrue
) and (days_to_expire
, ifexpired
flag isfalse
)