Модуль аудита

Пример на GitHub: audit_log

Модуль аудита позволяет записывать различные события, происходящих в Tarantool. Каждое событие – это действие, связанное с авторизацией и аутентификацией, манипуляцией данными, действиями администратора или системными событиями.

Модуль предоставляет подробные отчеты об этих действиях и помогает находить и устранять уязвимости для защиты бизнеса. Например, можно увидеть, кто и когда создал нового пользователя.

Каждая компания самостоятельно решает, какие именно действия подвергать аудиту и какие меры принимать. Системные администраторы, инженеры по безопасности и руководство компании могут аудитировать разные события по разным причинам. Tarantool поддерживает все эти варианты для каждого из них.

В этом разделе описано, как включить и настроить журналирование аудита, а также записывать журналы в выбранное место назначения – файл, канал или системный журнал.

Подробнее см. справочник по настройке журнала аудита.

Чтобы включить журналирование аудита, задайте место записи журнала с помощью параметра audit_log.to в конфигурационном файле. Возможные места записи журнала:

• Файл;
• Канал;
• Системный журнал.

В приведенной ниже конфигурации для параметра audit_log.to установлено значение file. Это означает, что журналы записываются в файл. По умолчанию журналы аудита сохраняются в файл var/log/{{ instance_name }}/audit.log. Чтобы явно указать путь к файлу журнала аудита, используйте параметр audit_log.file.

 
audit_log:  to: file  file: 'audit_tarantool.log'

При записи в файл Tarantool повторно открывает журнал аудита при получении сигнала SIGHUP.

Чтобы отключить журналирование аудита, установите для параметра audit_log.to значение devnull.

Широкие возможности фильтрации в Tarantool позволяют записывать в журнал аудита только нужные события. Для выбора записываемых событий используйте параметр audit_log.filter. Его значением может быть список событий и групп событий. Фильтры можно настраивать и комбинировать для решения различных задач. Возможные варианты фильтрации:

• Фильтрация по событию. Можно задать список событий для записи. Например, выберите password_change, чтобы отслеживать пользователей, сменивших пароли:

   
  audit_log:  filter: [ password_change ]

• Фильтрация по группе. Можно задать список групп событий для записи. Например, выберите auth и priv, чтобы видеть события, связанные с авторизацией и выданными привилегиями:

   
  audit_log:  filter: [ auth,priv ]

• Фильтрация по группе и событию. Можно указать группу и отдельное событие в зависимости от задачи. В приведенной ниже конфигурации выбраны user_create, data_operations, ddl и custom, чтобы видеть события, связанные с:

  • Созданием пользователей;
  • Созданием, изменением и удалением спейсов;
  • Изменением или выборкой данных из спейсов;
  • Пользовательскими событиями (любыми событиями, добавленными вручную через API модуля аудита).

 
filter: [ user_create,data_operations,ddl,custom ]  format: json  spaces: [ bands ]  extract_key: truegroups:  group001:    replicasets:      replicaset001:        instances:          instance001:            iproto:              listen:              - uri: '127.0.0.1:3301'

Используйте параметр audit_log.format, чтобы выбрать формат событий журнала аудита – простой текст, CSV или JSON.

 
format: json  spaces: [ bands ]  extract_key: truegroups:  group001:    replicasets:      replicaset001:        instances:          instance001:            iproto:              listen:              - uri: '127.0.0.1:3301'

По умолчанию используется JSON. Этот формат удобнее для получения событий журнала, их анализа и при необходимости интеграции с другими системами. Формат plain эффективно сжимается. Формат CSV позволяет просматривать события журнала аудита в табличном виде.

Параметр audit_log.spaces используется для указания списка имен спейсов, для которых следует записывать события операций с данными.

В приведенной ниже конфигурации в журнал записываются только события из спейса bands:

Если установлено значение true, параметр audit_log.extract_key заставляет подсистему аудита записывать в DML-операциях первичный ключ вместо полного кортежа.

 
extract_key: truegroups:  group001:    replicasets:      replicaset001:        instances:          instance001:            iproto:              listen:              - uri: '127.0.0.1:3301'

В этом примере используется следующая конфигурация журнала аудита:

 
audit_log:  to: file  file: 'audit_tarantool.log'  filter: [ user_create,data_operations,ddl,custom ]  format: json  spaces: [ bands ]  extract_key: true

Создайте спейс bands и проверьте записи в файле журнала после создания:

 
box.schema.space.create('bands')

Запись в журнале аудита для события space_create может выглядеть следующим образом:

 
{  "time": "2024-01-24T11:43:21.566+0300",  "uuid": "26af0a7d-1052-490a-9946-e19eacc822c9",  "severity": "INFO",  "remote": "unix/:(socket)",  "session_type": "console",  "module": "tarantool",  "user": "admin",  "type": "space_create",  "tag": "",  "description": "Create space Bands"}

Затем вставьте один кортеж в спейс:

 
box.space.bands:insert { 1, 'Roxette', 1986 }

Если для параметра extract_key установлено значение true, система аудита выводит первичный ключ вместо полного кортежа:

 
{  "time": "2024-01-24T11:45:42.358+0300",  "uuid": "b437934d-62a7-419a-8d59-e3b33c688d7a",  "severity": "VERBOSE",  "remote": "unix/:(socket)",  "session_type": "console",  "module": "tarantool",  "user": "admin",  "type": "space_insert",  "tag": "",  "description": "Insert key [1] into space bands"}

Если для параметра extract_key установлено значение false, система аудита выводит полный кортеж следующим образом:

 
{  "time": "2024-01-24T11:45:42.358+0300",  "uuid": "b437934d-62a7-419a-8d59-e3b33c688d7a",  "severity": "VERBOSE",  "remote": "unix/:(socket)",  "session_type": "console",  "module": "tarantool",  "user": "admin",  "type": "space_insert",  "tag": "",  "description": "Insert tuple [1, "Roxette", 1986] into space bands"}

Модуль журнала аудита Tarantool может записывать различные события, которые можно отслеживать, чтобы решить, нужно ли действовать:

• Действия администратора – события, связанные с действиями, выполняемыми администратором. Например, в таких журналах записывается создание пользователя.
• События доступа – события, связанные с авторизацией и аутентификацией пользователей. Например, в таких журналах записываются неудачные попытки доступа к защищенным данным.
• Доступ к данным и их изменение – события, связанные с манипуляцией данными в хранилище.
• Системные события – события, связанные с изменением или настройкой ресурсов. Например, в таких журналах записывается замена спейса.
• Пользовательские события – любые события, добавленные вручную с помощью API модуля аудита.

Полный список доступных событий журнала аудита приведен в таблице ниже:

Каждое событие журнала аудита содержит ряд полей, которые можно использовать для фильтрации и агрегации полученных логов. Пример записи журнала аудита Tarantool в формате JSON:

 
{    "time": "2024-01-15T13:39:36.046+0300",    "uuid": "cb44fb2b-5c1f-4c4b-8f93-1dd02a76cec0",    "severity": "VERBOSE",    "remote": "unix/:(socket)",    "session_type": "console",    "module": "tarantool",    "user": "admin",    "type": "auth_ok",    "tag": "",    "description": "Authenticate user Admin"}

Каждое событие состоит из следующих полей:

Встроенные группы событий используются для фильтрации типов событий, которые нужно аудитировать. Например, можно настроить запись только событий авторизации или только событий, связанных со спейсом.

В Tarantool предусмотрены следующие группы событий:

• all – все события.

• audit – событие audit_enable.

• auth – события авторизации: auth_ok, auth_fail.

• priv – события, связанные с аутентификацией, авторизацией, пользователями и ролями: user_create, user_drop, role_create, role_drop, user_enable, user_disable, user_grant_rights, user_revoke_rights, role_grant_rights, role_revoke_rights.

• ddl – события создания, изменения и удаления спейсов: space_create, space_alter, space_drop.

• dml – события изменения данных в спейсах: space_insert, space_replace, space_delete.

• data_operations – события изменения или выборки данных из спейсов: space_select, space_insert, space_replace, space_delete.

• compatibility – события, доступные в Tarantool до версии 2.10.0: auth_ok, auth_fail, disconnect, user_create, user_drop, role_create, role_drop, user_enable, user_disable, user_grant_rights, user_revoke_rights, role_grant_rights. role_revoke_rights, password_change, access_denied. Эта группа обеспечивает совместимость с более ранними версиями Tarantool.

В Tarantool предусмотрен API для записи пользовательских событий в журнал аудита. Чтобы включить эти события, задайте значение custom для параметра audit_log.filter:

Для записи события используйте функцию audit.log(), которая принимает одно из следующих значений:

• Строка сообщения. Выводится в журнал аудита с типом message:

 
audit.log('Hello, Alice!')

• Строка форматирования и аргументы. Передаются в функцию форматирования строки, а затем выводятся в журнал аудита с типом message:

 
audit.log('Hello, %s!', 'Bob')

• Таблица со значениями полей журнала аудита. Таблица должна содержать как минимум одно поле – description.

В качестве альтернативы, с помощью audit.new() можно создать новый модуль логирования. Благодаря этому можно избежать передачи всех пользовательских полей журнала аудита при каждом вызове audit.log(). Функция audit.new() принимает таблицу со значениями полей журнала аудита (как и audit.log()). Поле type модуля логирования для записи пользовательских событий должно иметь значение message или начинаться с префикса custom_.

 
local my_audit = audit.new({ type = 'custom_hello', module = 'my_module' })my_audit:log('Hello, Alice!')my_audit:log({ tag = 'admin', description = 'Hello, Bob!' })

Большинство полей пользовательского журнала аудита можно перезаписать с помощью audit.new() или audit.log(). Единственное поле журнала аудита, которое нельзя перезаписать – time.

Если значения опущены, полю session_type присваивается тип текущей сессии, а полю remote – адрес удаленного узла.

По умолчанию пользовательские события имеют уровень важности INFO. Чтобы переопределить уровень, можно:

• Задать поле severity;
• Использовать функцию-ярлык.

Доступны следующие функции-ярлыки:

Пример

При записи в файл размер журнала аудита Tarantool ограничен дисковым пространством. При записи в системный журнал размер журнала аудита Tarantool ограничен системным журналом. При записи в канал размер сообщения аудита Tarantool ограничен системным буфером. Если audit_log.nonblock = false, если audit_log.nonblock = true, ограничений нет.

Рекомендуется настроить расписание проверок в вашей компании. Журналы аудита следует просматривать как минимум каждые 3 месяца.

Рекомендуется хранить журналы аудита не менее одного года.

Для этой задачи рекомендуется использовать SIEM-системы.