Auditing is not supported by all Seq subscription types. Please refer to the subscription tier details on datalust.co and contact us if you need any help with licensing.
Seq's internal auditing produces a detailed external log of security-relevant events and configuration changes on the Seq server.
You may choose to enable auditing:
- To detect suspicious activity taking place on the server,
- To aid in responding to security incidents and attacks, or
- To demonstrate compliance with various policies, rules, standards, or regulations.
Seq auditing is designed with the following goals, scope and capabilities in mind.
Audit events are written to an external location separate from Seq's metadata and event stores. The auditing target can be physically separate from the Seq server being audited to ensure that the audit is preserved regardless of activities on the audited server.
Auditing is configured via the host server's filesystem/environment, and cannot be switched off through the Seq API at runtime. This increases the difficulty of manipulating auditing settings through a breached user account.
Because Seq apps execute under the Seq service account on the server machine, and therefore could potentially influence local configuration, app installation can be locked down using the
appHost.executionPolicysettings in order to harden this feature if required.
Seq auditing only captures user events initiated through the Seq UI and HTTP API. For a full listing of events supported by the current Seq version, see Audit Events. Contact Seq support for advice on capturing events not currently listed on that page.
Full audit events are generated for local (username/password) and Active Directory authentication operations. Currently, some OpenID Connect/Azure Active Directory events are recorded, however the authentication provider itself must be used for login auditing in this configuration.
Audit events with the
Record types are synchronously written to the audit target, with changes fully flushed, before Seq continues executing the audited operation. If auditing fails, an exception will be internally thrown, and the operation will be blocked from proceeding.
This ensures that audit records always exist for critical operations, but does introduce implications for performance and stability:
- Auditing may reduce the perceived responsiveness of some operations in the Seq UI, and
- If the audit target becomes unavailable for writes, certain Seq features and operations will not be usable until either the auditing target recovers, the auditing target is changed to an available destination, or auditing is disabled.
Broken auditing will prevent some operations
To preserve the integrity of the audit log Seq will not be able to complete audited activities if auditing is enabled but not working (e.g. if the audit server is not reachable).
Ingestion will not be affected.
Auditing is disabled by default, and must be enabled by configuring an audit target, which must be either a second Seq instance, or a local file.
Once auditing has been enabled using the instructions for the required target, you can confirm that auditing is enabled by downloading a diagnostic report from Settings > Diagnostics > Download a full diagnostic report. If auditing is correctly configured, the Auditing section of the report will show the text "Auditing is enabled".
The recommended target for auditing is a second, isolated, locked down Seq instance. To configure it, specify the Seq server's address and an API key for ingestion.
seq config set -k audit.auditServerUrl -v https://seq.example.com:45341 seq secret set -k audit.auditServerApiKey -v abcde12345 seq service restart
In most auditing scenarios, the target servers should expose only an ingestion port to most client IP ranges, should require API keys for ingestion, and should serve only HTTPS requests. For assistance with configuring Seq as an audit target, please contact Seq support.
To reverse this configuration, remove/clear the
Seq also supports auditing to a set of log files in newline-delimited JSON format.
File auditing is not recommended for long-term use. It's provided as a fallback that can be used during provisioning or maintenance of a secondary Seq audit server.
To configure file auditing, specify a path accessible to the Seq instance where audit files can be written:
seq config set -k audit.auditPath -v "E:\Audit\" seq service restart
Files will be written using names in the format
YYYYMMDD is the file creation year, month, and day (UTC), and
SESSION is the unique audit session identifier.
For performance reasons, Seq will write to a single audit file for an entire application run. To roll to a new file, restart the Seq service or container.
To reverse this configuration, remove/clear the
Audit events include the details of searches, queries, and various related entities which may under some circumstances involve personally-identifiable information (PII), for example, when this is incorporated into searches and queries by users, or when it appears unexpectedly in internal error descriptions.
Audit events never contain raw log event data.
Updated 2 months ago