Для настройки имени файла журнала аудита установите системную переменную audit_log_file при запуске сервера. Имя по умолчанию — audit.log в каталоге данных сервера. Для повышения безопасности записывайте журнал аудита в каталог, доступный только серверу MySQL и пользователям, имеющим право на просмотр журнала.

Плагин интерпретирует значение audit_log_file как состоящее из необязательного ведущего имени каталога, базового имени и необязательного суффикса. Если сжатие или шифрование включены, фактическое имя файла (имя, фактически используемое для создания файла журнала) отличается от настроенного имени файла, так как оно содержит дополнительные суффиксы:

Фактическое имя файла журнала аудита — это имя, полученное путем добавления соответствующих суффиксов сжатия и шифрования к настроенному имени файла. Например, если настроенное значение audit_log_file равно audit.log, фактическое имя файла — одно из значений, приведенных в следующей таблице.

pwd_id указывает идентификатор пароля, используемого для шифрования или расшифровки файла. Формат pwd_id — pwd_timestamp-seq, где:

Вот пример значений идентификатора пароля pwd_id:

20190403T142359-1
20190403T142400-1
20190403T142400-2

Для построения соответствующих идентификаторов хранилища ключей для хранения паролей в хранилище ключей плагин журнала аудита добавляет префикс audit_log- к значениям pwd_id. Для приведенных выше примеров идентификаторов паролей соответствующие идентификаторы хранилища ключей:

audit_log-20190403T142359-1
audit_log-20190403T142400-1
audit_log-20190403T142400-2

Идентификатор пароля, текущего используемого для шифрования плагином журнала аудита, — это тот, у которого наибольшее значение pwd_timestamp. Если несколько паролей имеют это значение pwd_timestamp, текущий идентификатор пароля — тот, у которого наибольший порядковый номер. Например, в приведенном выше наборе идентификаторов паролей два из них имеют наибольшую метку времени, 20190403T142400, поэтому текущий идентификатор пароля — тот, у которого наибольший порядковый номер (2).

Плагин журнала аудита выполняет определенные действия во время инициализации и завершения работы на основе фактического имени файла журнала аудита:

Для настройки формата файла журнала аудита установите системную переменную audit_log_format при запуске сервера. Доступны следующие форматы:

Подробная информация о каждом формате приведена в разделе 8.4.5.4 «Форматы файлов журнала аудита».

MySQL Enterprise Audit предоставляет возможность устанавливать интервал обновления для автоматического удаления кеша в оперативной памяти. Задача сброса, настроенная с помощью системной переменной audit_log_flush_interval_seconds, по умолчанию имеет значение ноль, что означает, что задача не запланирована для выполнения.

Когда задача настроена на выполнение (значение не равно нулю), MySQL Enterprise Audit пытается вызвать компонент планировщика при его инициализации и настроить регулярный, повторяющийся сброс своего кеша в памяти:

Аналогично, MySQL Enterprise Audit вызывает компонент scheduler при завершении инициализации и отменяет повторяющийся сброс, который он запланировал. Он сохраняет активную ссылку на службу регистрации планировщика до тех пор, пока запланированная задача не будет отменена, гарантируя, что компонент scheduler не может быть загружен, пока существуют активные запланированные задачи. Все результаты выполнения планировщика и его задач записываются в журнал ошибок сервера.

Чтобы запланировать задачу сброса журнала аудита:

В MySQL 8.4 вы можете расширить файлы журналов в формате JSON дополнительными полями данных, чтобы отобразить время выполнения запроса, количество отправленных и полученных байтов, количество строк, возвращенных клиенту, и количество обработанных строк. Эти данные доступны в журнале медленных запросов для соответствующих запросов, и в контексте журнала аудита они аналогичным образом помогают обнаруживать выбросы для анализа активности. Расширенные поля данных могут быть добавлены только тогда, когда журнал аудита находится в формате JSON (audit_log_format=JSON), что не является значением по умолчанию.

Статистика запросов передается в журнал аудита через сервисы компонентов, которые вы настраиваете как функцию фильтрации журнала аудита. Эти сервисы называются mysql_audit_print_service_longlong_data_source и mysql_audit_print_service_double_data_source. Вы можете выбрать любой тип данных для каждого выходного элемента. Для времени выполнения запроса longlong выводит значение в микросекундах, а double выводит значение в секундах.

Вы добавляете статистику запросов, используя функцию журнала аудита audit_log_filter_set_filter(), как элемент service синтаксиса фильтрации JSON, следующим образом:

SELECT audit_log_filter_set_filter('QueryStatistics',
                                   '{ "filter": { "class": { "name": "general", "event": { "name": "status", "print" : '
                                   '{ "service": { "implementation": "mysql_server", "tag": "query_statistics", "element": [ '
                                   '{ "name": "query_time",     "type": "double" }, '
                                   '{ "name": "bytes_sent",     "type": "longlong" }, '
                                   '{ "name": "bytes_received", "type": "longlong" }, '
                                   '{ "name": "rows_sent",      "type": "longlong" }, '
                                   '{ "name": "rows_examined",  "type": "longlong" } ] } } } } } }');

Для того, чтобы поля bytes_sent и bytes_received были заполнены, системная переменная log_slow_extra должна быть установлена на ON. Если значение системной переменной равно OFF, в файл журнала записывается нулевое значение для этих полей.

Если вы хотите прекратить сбор статистики запросов, используйте функцию журнала аудита audit_log_filter_set_filter() для удаления фильтра, например:

SELECT audit_log_filter_remove_filter('QueryStatistics');

Сжатие файлов журнала аудита может быть включено для любого формата ведения журнала.

Чтобы настроить сжатие файлов журнала аудита, установите системную переменную audit_log_compression при запуске сервера. Разрешенные значения — NONE (без сжатия; значение по умолчанию) и GZIP (сжатие GNU Zip).

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

Шифрование файлов журнала аудита можно включить для любого формата ведения журнала. Шифрование основано на паролях, заданных пользователем (за исключением исходного пароля, который генерирует плагин аудита). Для использования этой функции необходимо включить хранилище ключей MySQL, поскольку для хранения паролей используется журнал аудита. Можно использовать любой компонент или плагин хранилища ключей; инструкции см. в Раздел 8.4.4, «Хранилище ключей MySQL».

Чтобы настроить шифрование файлов журнала аудита, установите системную переменную audit_log_encryption при запуске сервера. Разрешенные значения — NONE (без шифрования; значение по умолчанию) и AES (шифрование шифром AES-256-CBC).

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

Дополнительную информацию о функциях шифрования журнала аудита см. в Функции журнала аудита.

При инициализации плагина журнала аудита, если он обнаруживает, что включено шифрование файла журнала, он проверяет, содержит ли хранилище ключей пароль шифрования журнала аудита. Если нет, плагин автоматически генерирует случайный начальный пароль шифрования и сохраняет его в хранилище ключей. Чтобы получить этот пароль, вызовите audit_log_encryption_password_get().

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

Файлы аудита можно распаковать и расшифровать с помощью стандартных инструментов. Это следует делать только для закрытых (архивированных) файлов аудита, которые больше не используются, а не для файла, в который в настоящее время записывает плагин аудита. Вы можете распознать архивированные файлы аудита по тому, что плагин аудита переименовал их, добавив отметку времени в имя файла сразу после базового имени.

Для этого обсуждения предположим, что audit_log_file установлено в значение audit.log. В этом случае, архивированный файл аудита имеет одно из имен, показанных в следующей таблице.

Как обсуждалось в Конвенциях именования файлов аудита, формат pwd_id имеет формат pwd_timestamp-seq. Таким образом, имена архивированных зашифрованных файлов аудита фактически содержат две отметки времени. Первая указывает время вращения файла, а вторая указывает время создания пароля шифрования.

Рассмотрим следующий набор имен архивированных зашифрованных файлов аудита:

audit.20190410T205827.log.20190403T185337-1.enc
audit.20190410T210243.log.20190403T185337-1.enc
audit.20190415T145309.log.20190414T223342-1.enc
audit.20190415T151322.log.20190414T223342-2.enc

Каждое имя файла имеет уникальную отметку времени вращения. Напротив, отметки времени пароля не уникальны:

Чтобы вручную распаковать сжатый файл аудита, используйте команду gunzip, gzip -d или аналогичную команду. Например:

gunzip -c audit.timestamp.log.gz > audit.timestamp.log

Чтобы вручную расшифровать зашифрованный файл аудита, используйте команду openssl. Например:

openssl enc -d -aes-256-cbc -pass pass:password -md sha256
    -in audit.timestamp.log.pwd_id.enc
    -out audit.timestamp.log

Для выполнения этой команды вам необходимо получить password, пароль шифрования. Для этого используйте audit_log_encryption_password_get(). Например, если имя файла аудита - audit.20190415T151322.log.20190414T223342-2.enc, идентификатор пароля - 20190414T223342-2, а идентификатор хранилища ключей - audit-log-20190414T223342-2. Восстановите пароль хранилища ключей следующим образом:

SELECT audit_log_encryption_password_get('audit-log-20190414T223342-2');

Если для аудита включены и сжатие, и шифрование, то сжатие выполняется перед шифрованием. В этом случае к имени файла добавляются суффиксы .gz и .pwd_id.enc, соответствующие порядку выполнения этих операций. Для восстановления исходного файла вручную выполните операции в обратном порядке. То есть, сначала расшифруйте файл, затем распакуйте его:

openssl enc -d -aes-256-cbc -pass pass:password -md sha256
    -in audit.timestamp.log.gz.pwd_id.enc
    -out audit.timestamp.log.gz
gunzip -c audit.timestamp.log.gz > audit.timestamp.log

Плагин аудита может использовать различные стратегии для записи логов. Независимо от стратегии, логирование происходит по принципу наилучшего усилия, без гарантии согласованности.

Для задания стратегии записи установите системную переменную audit_log_strategy при запуске сервера. По умолчанию значение стратегии — ASYNCHRONOUS, и плагин записывает в буфер асинхронно, ожидая, если буфер заполнен. Вы можете указать плагину не ожидать (PERFORMANCE) или записывать синхронно, используя кэширование файловой системы (SEMISYNCHRONOUS) или принудительно выводя результат с помощью вызова sync() после каждого запроса записи (SYNCHRONOUS).

Во многих случаях плагин записывает напрямую в лог-файл аудита в формате JSON, если текущий запрос слишком велик для буфера. Стратегия записи определяет, как плагин увеличивает счётчик прямых записей. Вы можете отслеживать количество прямых записей с помощью системной переменной статуса Audit_log_direct_writes.

Для асинхронной стратегии записи системная переменная audit_log_buffer_size — размер буфера в байтах. Установите эту переменную при запуске сервера, чтобы изменить размер буфера. Плагин использует единственный буфер, который выделяется при инициализации и удаляется при завершении работы. Плагин не выделяет этот буфер для стратегий записи, не являющихся асинхронными.

Асинхронная стратегия логирования обладает следующими характеристиками:

При асинхронном логировании целостность лог-файла может быть нарушена, если возникнет проблема во время записи в файл или если плагин не завершается корректно (например, если хост сервера неожиданно выходит из строя). Для снижения этого риска установите audit_log_strategy для использования синхронного логирования.

Недостатком стратегии PERFORMANCE является то, что она пропускает события, когда буфер заполнен. На сильно загруженном сервере в логе аудита могут отсутствовать события.