Audit Logs
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 (not registered with IANA).
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"]
Security Log Field Specification
| No. | Description | Comment | Reserved Value |
|---|---|---|---|
| 1 | Priority | All messages have the same priority: 4*8+5 | 37 |
| 2 | Syslog Version | 1 | |
| 3 | HOSTNAME | Server name, if it cannot be determined or the name does not meet RFC 5424 requirements, then "-" | |
| 4 | Process Name | Violation of the specification. The specification requires specifying the application name (java), but this does not ensure product uniqueness | operavix |
| 5 | Process ID (PID) | If the pid cannot be determined, then "-" | |
| 6 | MSGID Event | Unique event identifier, based on an "incrementing value". A string value representing the event type |
Correspondence of Log Event Types
| Security Event Information in SI Terms | Element in the Security Log Line | Note |
|---|---|---|
| Unique line number of the security event | [meta sequenceId="80"] | The meta sequenceId value is the unique number of the event line |
| Name of the AS - source of event information | [source@729368 … type="employee"…] | The type value in source is the event source type. See table Security Log Entry Blocks for details |
| Version of the event information source | [system@729368 version.platform= "1.0.0"] | The version.platform value is information about the event source.See table Security Log Entry Blocks for details |
| System name (login) of the user initiating the event | [source@729368 … id="1" type="employee" login="admin"…] | The id="1", "login="admin" values are information about the initiating user, namely: login – login, id – user serial number.See table Security Log Entry Blocks for details |
| IP address of the event source host | [source@729368… remoteAddress="10.0.75.1"] | The remoteAddress value is the IP address of the event source host Important: The user's IP is correctly displayed in the log file only during standard Docker launch. In rootless mode, the IP is substituted. When proxying through Nginx, the real IP is stored in remote_proxy, not remote_address |
| System name (login) of the recipient user | [target@729368 …id="1" type="employee" login="admin"] | The values in target id="1" type="employee" login="admin" are information about the recipient user, where:id – user serial numberlogin – user logintype – recipient type |
| System identifier (message) of the event | update | The event identifier-message can be the <MSGID> value |
| System time of the event source | 2019-03-26T16:07:06+03:00 | The event source time is fixed in the line under <time>Date format: yyyy-MM-ddTHH:mm:ssZ |
| Message text in the most detailed form, including old and new values of changed properties | [event@729368 old_first_name="John" old_email=johndoe@mail.com new_first_name="Jack" new_email="email@mail.com] | old_first_name – old first name valueold_email – old email address valuenew_first_name – new first name valuenew_email – new email address value |
| Full name of the process (service) result (success/failure) | The result (success/failure) is not recorded for all events in the system |
Security Log Entry Blocks
| Field | Description |
|---|---|
| Meta | |
sequenceId | Event identifier, based on an increment |
| System: system@729368 | |
version.platform | Kernel version |
| Source: source@729368 | |
system | Internal system action |
remote_addressremote_proxy | Requests without authorization. Source type: "anonymous". remoteAddress – remote address from which the request came remoteProxy – if the server is behind a proxy, the real IP can be specified via the HTTP header X-Real – IP |
remoteAddress remoteProxy id sessionHash login | User request. Source type: "employee". remoteAddress – remote address from which the request came remoteProxy – if the server is behind a proxy, the real IP can be specified via the HTTP header X-Real – IP id – user identifier sessionHash – SHA256 from the string value of the session login – user login |
subtype remote_address remote_proxy id name login_AD domain_name | API key request. Source type: "api_key". subtype ="AD" – authorization type via API key using AD policies certificate – authorization type via API key using client authentication (security certificates) none – authorization type only via API key remote_address – remote address from which the request came remote_proxy – if the server is behind a proxy, the real IP can be specified via the HTTP header X-Real – IP id – API key identifier name – API key name login_AD – user login in AD (appears only if there is AD integration) domain_name – domain name (appears only if there is AD integration) |
| Object on which the action was performed: 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?