Configuring and using data auditing

Set options in dse.yaml for configuring and using data auditing.

The location of the dse.yaml file depends on the type of installation:
Installer-Services /etc/dse/dse.yaml
Package installations /etc/dse/dse.yaml
Installer-No Services install_location/resources/dse/conf/dse.yaml
Tarball installations install_location/resources/dse/conf/dse.yaml

The audit logger logs information on the node set up for logging. For example, node 0 has audit turned on, node 1 does not. Issuing updates and other commands on node 1 does not generally show up on node 0’s audit log. To get the maximum information from data auditing, turn on data auditing on every node.

Audit logs can be written to filesystem log files using log4j, or to a Cassandra table. When you turn on audit logging, the default logger is to log to log4j filesystem log files.

For simple installations, logging to log4j files is typically easier. The log files can be read from a terminal to troubleshoot queries or manage security. However, larger clusters can make log4j audit logs cumbersome. The log files grow extremely large, and it's difficult to analyze all the messages. The format of the log file is also not flexible. Each node's log files are local to the machine, making it difficult to find out what is happening across the cluster.

As your cluster scales up, logging audit data to a Cassandra table is more useful. The data can be queried like any other table, making analysis easier and custom audit reports possible.

Audit logging of queries and prepared statements submitted to the DataStax drivers, which use the CQL binary protocol, is supported.

When using audit logging with Kerberos authentication, the login events take place on Kerberos and are not logged in DataStax Enterprise. Authentication history is available only on Kerberos. When DataStax Enterprise is unable to authenticate a client with Kerberos, a LOGIN_ERROR event is logged.

When using audit logging with Cassandra native protocol authentication, the login events take place as part of connection negotiation and are not logged in DataStax Enterprise.

Procedure

  1. Open the dse.yaml file in a text editor.
    <p conkeyref="DSEcommons/dse-yaml" id="dseyaml" audience="htmlonly" />
  2. In the audit_logging_options section, set enabled to true. 
    # Audit logging options
audit_logging_options:
    enabled: true
  3. Set the logger option to either:
    • CassandraAuditWriter

      Logs to a Cassandra table.

    • Log4JAuditWriter

      Logs to a log4j file.

    By default, logger is set to Log4JAuditWriter.

  4. Optional: Include or exclude event categories from being logged by adding the event types to include_categories or exclude_categories.
    You can set either included_categories or exclude_categories, but not both.
    Setting Logging
    ADMIN Logs describe schema versions, cluster name, version, ring, and other administration events.
    AUTH Logs login events.
    DML Logs insert, update, delete and other DML events.
    DDL Logs object and user create, alter, drop, and other DDL events.
    DCL Logs grant, revoke, create user, drop user, and list users events.
    QUERY Logs all queries.
  5. Optional: Include or exclude Cassandra keyspaces from being logged by adding the keyspaces to included_keyspaces or excluded_keyspaces.
    You can set either included_keyspaces or excluded_keyspaces, but not both.
  6. If you are logging to a Cassandra table, set the retention time for logged events by setting the retention_time option to the number of hours the events should be retained. The default value is 0, which retains all event data indefinitely.
  7. Configure the audit logging writer.

Example

The following example sets the audit logger to log to a Cassandra table.

# Audit logging options
audit_logging_options:
    enabled: true
    logger: CassandraAuditWriter