TSM Audit Logging Integration

The TSM allows integrating audit logging with other log frameworks using the fluentd service.

The fluentd service allows taking inputs from various sources and sending it to different log systems, such as Splunk or Cloudwatch.

Setting up the fluentd service

The fluentd service has a docker image that can be used to launch the service. The following docker-compose snippet should launch the service:

auth-server:
    image: fluent/fluentd:edge-debian
    ports:
      - "9080:9080"
    networks:
      - tsm
    volumes:
      - ./config/:/fluentd/etc
      - ./logs/:/tmp/logs

This starts the service to listen on port 9080 and will load the configuration from the ./config directory. The ./logs/ directory is used to demonstrate how to write to files in the following output examples.

Configuration

This will discuss some of the simple options when using the fluentd service. The service allows a multitude of plugins to communicate with different services. Check the documentation link for more complicated setups.

The configuration needs to be inserted into the file ./config/fluent.conf if the above docker-compose is used.

Input handler

To get the audit logs from the TSM, an input handler needs to be defined. The port defined in the following examples must match the port in the docker-compose. The simplest handler is:

<source>
  @type http
  port 9080
  bind 0.0.0.0
</source>

This should automatically parse the input as JSON due to the content type of the communication. If this does not happen, a JSON parsing can be forced with:

<source>
  @type http
  port 9080
  bind 0.0.0.0
  <parse>
    @type json
  </parse>
</source>

Once this is inserted in the configuration file, the audit log events from the TSM will be handled in the fluentd server and raise log events that can be handled by various plugins.

Output handler

Fluentd allows outputting logs to various output plugins. We will cover a few simple options relevant for running fluentd as a stand-alone audit log server. Output in fluentd is done in a match section, which can contain one or more output options. The first example logs to a single output in JSON format on stdout:

<match **>
  @type stdout
  <format>
    @type json
  </format>
</match>

If multiple outputs are used, the type needs to be set to copy. Each output option is then specified in different store sections. The following example logs to two different file formats and outputs a shortened version to stdout:

<match **>
  @type copy

<store>
    @type file
    path /tmp/logs/json
    <format>
      @type json
    </format>
  </store>

<store>
    @type file
    path /tmp/logs/tag-value
    <format>
      @type ltsv
      delimiter "\t"
      label_delimiter " => "
    </format>
  </store>

<store>
    @type stdout
    <format>
      @type csv
      fields timestamp,userID,algorithm,keyID,operation,parameters
      force_quotes false
    </format>
  </store>
</match>

If signatures need to be validated, it is advised to save the log entries in JSON format. For more information on validation, refer to the relevant documentation.

Setting up the TSM

To set up audit logging in the TSM, simply add the [Audit] section to the configuration:

[Audit]
ReceiverURL="http://auth-server:9080"                             # The URL of the audit server
LogEntrySigningKeySeed="9L/49DsAFKtZrTFiq49T6j2LXlVU+6A0Nbw5FIWemVw=" # The seed for signing

The signing key can be the same for all TSMs, but using separate keys increases security. Additional options like MaxBatchSize, MinWaitTime, and MaxWaitTime can instruct the TSM on uploading entries. For HTTPS setups, use ReceiverPublicKey for TLS public keys, and ClientPrivateKey for client keys in mTLS setups.