Top.Mail.Ru
Audit Logs
CTRL+K

Audit Logs

In this article
  • Audit Logs
  • System Audit Log Size
  • Description of Audit Logs
  • Audit Log Field Specification
  • Audit Log Event Mapping
  • Log Record Blocks
  • Audit Log Rotation
  • Hot Configuration Reload

The list of audit logs includes the system security event log and OS-level security logs.

The system security event log security.log is located by default at:

  • On Windows — in the directory C:\Program Data\Operavix\logs
  • On Linux — in the container /var/log/operavix

Event logging is performed in a format based on the RFC 5424 (The Syslog Protocol) specification. For timestamps, the RFC 3339 format is used.

A detailed description of the format is provided in the RFC 5424 specification.

The timestamp format is described in RFC 3339.

EnterpriseId 729368 is used, which is not registered with IANA.

Events are logged per individual node:

  • If the Automation Agent is installed on the same node as Operavix, all events are written to a single log file
  • If the Automation Agent is installed on a separate node, Operavix and Automation Agent events are recorded in separate log files on their own nodes

System Audit Log Size

The estimated size of the system log files is calculated using the formula:

Memory per year = Number of employees * 1 MB

The logback.xml file allows you to configure log rotation. By default, audit logs are retained for 3 years. If this period is insufficient, you need to modify the configuration file.

Description of Audit Logs

Log entry format:

37<1> <time> <hostname> operavix <pid> <MSGID> [meta sequenceId=""][system@729368 version.core="1.0.0" version.operavix="1.0.0"][source@729368 ...][event@729368 ...][target@729368 ...]

Example of an audit log entry:

<37>1~2019-03-26T16:07:06+03:00~operavix61~operavix~9160~update~[metasequenceId="80"]~[system@729368 version.platform="1.0.0" version.operavix="1.0.0"]~[source@729368 sessionHash="3915d830623a26b61a044d1ad9c1bebb6e61705a969559e1c5f436d2210aabcc" id="1" type="employee" login="admin" remoteAddress="10.0.75.1"]~[event@729368 old_first_name="John" old_email=john@example.com new_first_name="Pete" new_email="pete@example.com"]~[target@729368 module="platform" id="2"type="employee" login="pete"]

Audit Log Field Specification

#DescriptionCommentReserved Value
1PriorityAll messages use the same priority: 4*8 + 537
2Syslog Version1
3HOSTNAMEServer name; if unavailable or non-compliant with RFC 5424, "-" is used
4Process NameViolates specification. Specification requires the application name (java) but it does not ensure product uniquenessoperavix
5Process ID (PID)If PID cannot be determined, "-" is used
6Event MSGIDUnique event identifier based on an "incrementing value". String value of event type

Audit Log Event Mapping

Event Information in Information Security TermsLog Entry ElementNote
Unique information security event record number[meta sequenceId="80"]The meta sequenceId value is the unique event record number
Event information source system name[source@729368 … type="employee"…]The type value in source is the event source type.
See Log Record Blocks table for details
Event information source version[system@729368 version.platform="1.0.0"]The version.platform value is the information about source version.
See Log Record Blocks table for details
System username (login) of user-initiator[source@729368 … id="1" type="employee" login="admin"…]The login value is the username;
id is the sequential number of user.
See Log Record Blocks table for details
Source host IP address[source@729368… remoteAddress="10.0.75.1"]remoteAddress value is the source host IP.
Note: The IP of user is only correctly logged with standard Docker startup. In rootless mode, the IP is substituted. When proxying through Nginx, the real IP is stored in remote_proxy, not remote_address
System username (login) of user-recipient[target@729368 …id="1" type="employee" login="admin"]Values in target:
id – sequential number of user,
login – username,
type – recipient type
System event message identifierupdateThe <MSGID> field serves as the system message identifier. See module-specific structured data tables for more details
System event source timestamp2019-03-26T16:07:06+03:00Timestamp is recorded in the <time> field in yyyy-MM-ddTHH:mm:ssZ format
Full event message with old and new values[event@729368 old_first_name="John" old_email=john@example.com new_first_name="Pete" new_email="pete@example.com"]old_first_name – previous value of name
old_email – previous value of email
new_first_name – updated value of name
new_email – updated value of email
Full process/service name
Result (success/failure)
The result (success/failure) is not logged for all system events

Log Record Blocks

FieldDescription
Meta
sequenceIdEvent identifier based on an "incrementing counter"
System: system@729368
version.platformCore version
Source: source@729368
systemInternal system action
remote_address
remote_proxy
Unauthenticated requests.
Source type: anonymous.
remoteAddress – remote request origin
remoteProxy – proxy server address
remoteAddress
remoteProxy
id
sessionHash
login
User request.
Source type: employee.
remoteAddress – request origin
remoteProxy – proxy address
id – user ID
sessionHash – SHA256 of session string value
login – user login
subtype
remote_address
remote_proxy
id
name
login_AD
domain_name
API key request.
Source type: api_key.
subtype = "AD" – API key with AD-integrated authorization
"certificate" – API key with client certificate authorization
"none" – API key only authorization
remote_address – request origin
remote_proxy – proxy address
id – API key ID
name – API key name
login_AD – AD user login (only with AD integration)
domain_name – domain name (only with AD integration)
Action target object: target@729368

Audit Log Rotation

All system logging is based on the Logback component.

By default, the system uses the logback.xml configuration file located at:

  • On Windows — in the directory C:\ProgramData\Operavix
  • On Linux — in the container /var/lib/operavix

The system also supports overriding the configuration file, with a prioritization mechanism for loading configuration files.

Detailed information about the configuration file format and the priorities for loading configuration files can be found in the Logback documentation.

By default, log rotation is enabled in the system, and the following rules apply to the audit log: the audit log file is compressed into an archive and renamed according to the pattern ("security.%d{yyyy-MM-dd}.%i.log.gz") when:

  • A new day begins
  • The log file exceeds 50 MB

By default, audit log files are stored for 3 years. After this period, old audit logs are deleted. The parameters responsible for log rotation are configured in the logback.xml file.

Hot Configuration Reload

By default, the system provides a "hot" configuration reload mechanism. This is controlled by the scan and scanPeriod parameters. Scanning occurs every 30 seconds. This mechanism allows temporary changes to logging rules, up to and including completely disabling logging: (<configuration scan="true" scanPeriod="30 seconds">)

Was the article helpful?

Yes
No
Previous
Implemented Information Security Protection Measures in the System
We use cookies to improve our website for you.