Security auditing

Audit trail enables accountability for actions. The common use cases are to detect unauthorized access to the system, trace changes to the configuration and prevent inappropriate actions through accountability.

You can enable the detailed audit trail log by using the graphdb.audit.role configuration parameter. Here is an example:

graphdb.audit.role=USER

The hierarchy of audit roles is as follows:

  1. ANY

  2. USER

  3. REPO_MANAGER

  4. ADMIN

  5. Logging form (always logged!)

In addition to this, logging for repository access can be configured by using the graphdb.audit.repository property. For example:

graphdb.audit.repository=WRITE

will lead to all write operations being logged. READ permissions also include WRITE operations.

The detail of the audit trail increases depending on the role which is configured. For example, configuring the audit role for REPO_MANAGER means that access to the repository management resources will be logged, as well as access to the administration resources and the logging form. Configuring the audit role to ADMIN will only log access to the administration resources and the logging form.

The ANY role lists all requests towards resources where that require authentication.

The following fields are logged for every successful security check:

  • Username

  • Source IP address

  • Response status code

  • Type of request method

  • Request endpoint

  • X-GraphDB-Repository header value or - if missing - which repository is being accessed

  • Serialization of the request headers specified in the graphdb.audit.headers parameter

  • Serialization of all input HTTP parameters and the message body, limited by the graphdb.audit.request.max.length parameter

By default, no headers are logged. The parameter which configures this, graphdb.audit.headers can take multiple values. For instance, if you want to log two headers, you will simply list them with commas.

Graphdb.audit.headers = Referer,User-Agent

The amount of bytes from the message body which get logged defaults to 1024 if the graphdb.audit.request.max.length parameter is not set.

Note

Logs can be space-intensive, in particular if you toggle them to level 1 or 2, as described above.