Журналы безопасности
К перечню журналов безопасности относятся журнал событий безопасности системы и журналы безопасности на уровне ОС.
Журнал событий безопасности системы security.log по умолчанию располагается:
- На Windows — в каталоге C:\Program Data\Infomaximum\logs
- На Linux — в контейнере /var/log/infomaximum
Логирование событий осуществляется в формате, основанном на спецификации RFC 5424 (The Syslog Protocol). Для временных меток используется формат RFC 3339.
Подробное описание формата представлено в спецификации RFC 5424:
Формат временных меток описан в спецификации RFC 3339.
Используется EnterpriseId 729368, не зарегистрированный в IANA.
Размер журналов безопасности системы
Предположительный размер файлов лога системы вычисляется по формуле:
Память в год = Количество сотрудников*1 Мб.
Файл logback.xml позволяет настраивать ротацию логов. Логи безопасности по умолчанию хранятся 3 года. Если период недостаточен, необходимо изменить файл конфигурации.
Описание журналов безопасности
Формат записи:
37<1> <time> <hostname> infomaximum <pid> <MSGID> [meta sequenceId=""][system@729368 version.core="1.0.0" version.proceset="1.0.0"][source@729368 ...][event@729368 ...][target@729368 ...]
Пример записи в журнале безопасности:
<37>1~2019-03-26T16:07:06+03:00~infomaximum61~infomaximum~9160~update~[metasequenceId="80"]~[system@729368 version.platform="1.0.0" version.proceset="1.0.0"]~[source@729368 sessionHash="3915d830623a26b61a044d1ad9c1bebb6e61705a969559e1c5f436d2210aabcc" id="1" type="employee" login="admin" remoteAddress="10.0.75.1"]~[event@729368 old_first_name="Денис" old_email=petr@gmail.com new_first_name="Владимир" new_email="email@gmail.com"]~[target@729368 module="platform" id="2" type="employee" login="vpetrov"]
Спецификация полей журнала безопасности
| № | Описание | Комментарий | Зарезервированное значение |
|---|---|---|---|
| 1 | Приоритет | Все сообщения идут с одним приоритетом: 4*8+5 | 37 |
| 2 | Версия syslog | 1 | |
| 3 | HOSTNAME | Имя сервера, если определить не удалось или имя не соответствует требованиям RFC 5424, то "-" | |
| 4 | Имя процесса | Нарушение спецификации. Спецификация требует указать имя приложения (java), но это не обеспечивает уникальность продукта | infomaximum |
| 5 | ID процесса (PID) | Если pid определить не удалось, то '-' | |
| 6 | MSGID события | Уникальный идентификатор события, основан на «инкрементирующем значении». Строковое значение типа события |
Соответствие видов событий журнала
| Информация о событии в терминах СЗИ | Элемент в строке в журнале безопасности | Примечание |
|---|---|---|
| Уникальный номер строки о событии ИБ | [meta sequenceId="80"] | Значение meta sequenceId является уникальным номером строки о событии |
| Название АС-источника информации о событии | [source@729368 … type="employee"…] | Значение type в source является типом источника события. Подробнее в таблице Блоки записи в журнале безопасности |
| Версия источника информации о событии | [system@729368 version.platform= "1.0.0"] | Значение version.platform является информацией об источнике события.Подробнее в таблице Блоки записи в журнале безопасности |
| Системное имя (логин) пользователя-инициатора события | [source@729368 … id="1" type="employee" login="admin"…] | Значение id="1", "login="admin" является информацией о пользователе-инициаторе, а именно: login – логин, id – порядковый номер пользователя. Подробнее в таблице Блоки записи в журнале безопасности |
| IP-адрес хоста-источника события | [source@729368… remoteAddress="10.0.75.1"] | Значение remoteAddress является IP-адресом хоста-источника события Важно: В лог-файле корректно отображается IP пользователя только при стандартном запуске Docker. В rootless-режиме IP подменяется. При проксировании через Nginx реальный IP сохраняется в remote_proxy, а не в remote_address |
| Системное имя (логин) пользователя получателя | [target@729368 …id="1" type="employee" login="admin"] | Значения в target id="1" type="employee" login="admin" являются информацией о пользователе-получателе, где:id – порядковый номер пользователяlogin – логин пользователяtype – тип получателя |
| Системный идентификатор сообщения о событии | update | Идентификатором-сообщением о событии может быть значение <MSGID> Подробнее в таблицах со структурированными данными для каждого модуля |
| Системное время источника события | 2019-03-26T16:07:06+03:00 | Время источника события фиксируется в строке под <time> Формат даты: yyyy-MM-ddTHH:mm:ssZ |
| Текст сообщения в максимально подробном виде, включая старые и новые значения измененных свойств | [event@729368 old_first_name="Денис" old_email=petr@gmail.com new_first_name="Владимир" new_email="email@gmail.com] | old_first_name – старое значение имениold_email – старое значение электронного адресаnew_first_name – новое значение имениnew_email – новое значение электронной почты |
| Полное имя процесса(службы) результат (успех/отказ) | Результат (успех/отказ) фиксируется не для всех событий в системе |
Блоки записи в журнале безопасности
| Поле | Описание |
|---|---|
| Meta | |
sequenceId | Идентификатор события, основан на «инкременте» |
| Система: system@729368 | |
version.platform | Версия ядра |
| Источник: source@729368 | |
system | Внутреннее действие системы |
remote_addressremote_proxy | Запросы без авторизации. Тип источника: «anonymous». remoteAddress – удаленный адрес, с которого пришел запрос remoteProxy – адрес прокси-сервера |
remoteAddress remoteProxy id sessionHash login | Запрос пользователя. Тип источника: «employee». remoteAddress – удаленный адрес, с которого пришел запрос remoteProxy – адрес прокси-сервера id – идентификатор пользователя sessionHash – SHA256 от строкового значения сессии login – логин пользователя |
subtype remote_address remote_proxy id name login_AD domain_name | Запрос ключа API. Тип источника: «api_key». subtype ="AD" – тип авторизации через ключ API посредством политик AD certificate – тип авторизации через ключ API посредством клиентской аутентификации (сертификатов безопасности) none – тип авторизации только через ключ API remote_address – удаленный адрес, с которого пришел запрос remote_proxy – адрес прокси-сервера id – идентификатор ключа API name – название ключа API login_AD – логин пользователя в AD (появляется только в том случае, если есть интеграция с AD) domain_name – доменное имя (появляется только в том случае, если есть интеграция с AD) |
| Объект, над которым произведено действие: target@729368 |
Ротация журнала безопасности
Все журналирование системы основано на компоненте Logback (https://logback.qos.ch).
По умолчанию в системе применяется файл конфигурации logback.xml, расположенный:
- На Windows — в каталоге
C:\ProgramData\Infomaximum - На Linux — в контейнере
/var/lib/infomaximum
Также в системе возможны варианты с переопределением файла конфигурации, при этом используется механизм приоритизации загрузки файла конфигурации.
Подробно о формате файла конфигурации, а также о приоритетах загрузки файлов конфигурации можно посмотреть в документации:
https://logback.qos.ch/manual/configuration.html.
По умолчанию в системе включена ротация логов, для журнала безопасности применяются следующие правила: файл журнала безопасности упаковывается в архив и переименовывается в соответствии с шаблоном ("security.%d{yyyy-MM-dd}.%i.log.gz") при следующих условиях:
- Наступили следующие сутки
- Журнал лога превысил размер в 50 Мб
По умолчанию файлы журнала безопасности хранятся 3 года. По истечении этого времени старые журналы безопасности удаляются. Параметры, которые отвечают за ротацию логов, настраиваются в файле logback.xml.
Горячее обновление конфигурации
В системе по умолчанию предусмотрен механизм «горячего» обновления конфигурации. За это отвечают параметры «scan» и «scanPeriod». Сканирование происходит каждые 30 секунд. Этот механизм позволяет временно изменять правила логирования, вплоть до полного его отключения (<configuration scan="true" scanPeriod="30 seconds">).
Была ли статья полезна?