To support debugging and internal and external compliance, Unique provides logs of user and system events.

About audit logs

The audit log lists events triggered from API interactions within Unique. This includes versioned/public APIs as well as internal APIs (refer to APIs & Integrations).

Each audit log entry has an action that signals the performed operation. Depending on the action, additional information might be present in the data field.

Additionally, each entry contains the following fields:

• app - The service executing the operation

• clientIpAddress - The caller's IP address, certain limitations apply, see https://unique-ch.atlassian.net/wiki/spaces/SD/pages/940015656/Audit+Logs#Limitations

• companyId - The caller's company id

• userId - The caller's user id

• serviceId - The caller’s service id executing the request (in case the caller is a machine)

• type - Whether it was a REST, GraphQL or WebSocket request

Scope

The scope of the audit logs is to support forensic analysis in case of incidents and to log accountability for privileged actions. The goal is not to enable content filtering on requests or responses.

For this Unique recommends https://unique-ch.atlassian.net/wiki/spaces/SD/pages/500105333/Data+Leakage+Prevention+DLP#I-DLP-Proxy or https://unique-ch.atlassian.net/wiki/spaces/SD/pages/500105333/Data+Leakage+Prevention+DLP#II-Analytics-APIs.

Exclusions

Certain actions and/or endpoints are excluded, namely:

• Health probes

• All operations that require no privileged Roles and Permissions and query non-sensitive data (e.g. a user asking for their companies name or theme)

• All operations that require no privileged Roles and Permissions and query data about the calling identity itself (e.g. a user loading his own profile)

• All operations that require no privileged Roles and Permissions and create or update data affecting only the calling identity (e.g. a user creating a new chat for themselves)

Unique is opting for a secure by default approach, so the Audit Log is written implicitly on any operation using interceptors. Due to this enforced security, the amount of audit logs can grow exponentially if no exclusions are defined. The exclusions above balance the demand for security and compliance against the total cost of ingesting and storing large amounts of data.

Destinations

Audit Logs are written by line as JSON and their log level is 35 or audit respectively.

Console

In order to output to the console, set AUDIT_LOG_DIR to /dev/stdout.

File

In order to output to a directory, point AUDIT_LOG_DIR to a mounted volume that can host a large amount of data. Unique services will automatically rotate files in order to keep them smaller compared to the overall amount.

Modi

The Audit Logs have two log modi. Unique defaults to basic except when explicitly specified per service (environment) as AUDIT_LOG_MODE.

basic

Includes the fields as described above in About audit logs.

Example

verbose_including_cid

Since this mode is explicitly opt-in, Unique waives all liability when using this mode and the client is solely responsible to handle the logs including their sensitive content responsibly.

If verbose_including_cid is enabled, all log entries will, additionally to the basic fields include:

• Full HTTPS request object

• Full HTTPS response object

Both of these can include sensitive and/or CID data.

Limitations

Implicitness

Due to the implicit and enforced nature of the current audit logs, the list of events in non-deterministic and cannot be documented beforehand. Unique can provide an example set of actions as well as their documentation but ultimately, with any new product change, new events might be introduced that are audit-logged by default.

clientIpAddress

Unique leverages request-ip which tries to pin the clients IP as best as possible. This field (not a vulnerability of Unique but a factoid of the internet) is spoofable, which means, users savvy enough can submit another source of their request. Also, FSI clients often route traffic through upstream services, proxies or firewalls which might naturally modify the original IP to their own resulting in all audit logs then featuring exactly the same IP, the one from the upstream service. See in request-ip which headers are honoured.

Single and Multi Tenant Clients

Multi Tenant

Audit Logs are retained for 90 days using basic level. Clients requiring a longer audit log duration must upsell their contract to a single or customer managed tenant.

Upon request Unique can provide an excerpt of the audit logs. The granularity is business days and the maximum to request at once is 5 business days. Preparing an audit log export for multi tenant customers takes at least 3 business days. In that case, the client is responsible to provide a secure channel for transfer of the log export. This process is available once per quarter except when presenting a legal dispute or data leak investigation.

Single Tenants

Audit logs are retained for 5 years (1825 days) using basic level.

Upon request Unique can provide temporary limited access to the audit log location. Preparing an audit log export for Single Tenants takes at least 3 business days. This process is available once per quarter except when presenting a legal dispute or data leak investigation.

Unique does not provide Single Tenant Audit Logs to a clients location of choice as this includes actively processing the data potentially by a human which is against Uniques security policies. The client will receive a Azure Storage Account SAS token that is valid for the agreed time (max. 5 business days). The client is responsible to download the files on their own behalf during this time.

Unique will not delete audit logs even after ending a contract (legal and compliance requirements). Unique will continue holding the logs until the 5 years expired.