6.4.5.5 Configuring Audit Logging Characteristics — MySQL 5.7

6.4.5.5 Настройка характеристик ведения аудита

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

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

Плагин журнала аудита также может контролировать, какие события аудита записываются в файл журнала аудита, на основе содержимого события или учетной записи, из которой происходят события. См. Раздел 6.4.5.7, «Фильтрация журнала аудита».

Правила именования файлов журнала аудита

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

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

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

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

Включенные функции	Фактическое имя файла
Без сжатия и шифрования	`audit.log`
Сжатие	`audit.log.gz`
Шифрование	`audit.log.enc`
Сжатие, шифрование	`audit.log.gz.enc`

До версии MySQL 5.7.21 настроенное и фактическое имена файла журнала были одинаковыми. Например, если настроенное значение audit_log_file равно audit.log, плагин журнала аудита записывает в audit.log.

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

Начиная с MySQL 5.7.21:

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

До MySQL 5.7.21 доступны только форматы XML-журналов, и плагин выполняет рудиментарную проверку целостности:

Во время инициализации плагин проверяет, заканчивается ли файл тегом </AUDIT>, и обрезает тег перед записью любых элементов <AUDIT_RECORD>. Если файл журнала существует, но не заканчивается на </AUDIT> или тег </AUDIT> не может быть обрезан, плагин считает файл неверным и переименовывает его. (Такое переименование может произойти, если сервер завершился неожиданно с работающим плагином журнала аудита.) Затем плагин записывает в новый пустой файл журнала аудита.
При завершении переименование файла не происходит.
При переименовании во время инициализации плагина переименованный файл имеет .corrupted, метку времени и .xml в конце. Например, если имя файла — audit.log, плагин переименовывает его на значение, такое как audit.log.corrupted.15081807937726520.xml. Значение метки времени похоже на метку времени Unix, при этом последние 7 цифр представляют дробную часть секунды. Для получения информации об интерпретации метки времени см. Управление дисковым пространством для файлов журнала аудита.

Выбор формата файла журнала аудита

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

NEW: Новый формат XML. Это значение по умолчанию.
OLD: Старый формат XML.
JSON: Формат JSON.

Подробнее о каждом формате см. в разделе 6.4.5.4, «Форматы файлов журнала аудита».

Если вы измените audit_log_format, рекомендуется также изменить audit_log_file. Например, если вы установите audit_log_format на JSON, установите audit_log_file на audit.json. В противном случае новые файлы журнала будут иметь другой формат, чем старые, но все они будут иметь одинаковое базовое имя без каких-либо указаний о смене формата.

Примечание

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

Остановите сервер.
Либо измените значение системной переменной audit_log_file, чтобы плагин записывал в другой файл, либо вручную переименуйте текущий файл журнала аудита.
Перезапустите сервер с новым значением audit_log_format. Плагин журнала аудита создаст новый файл журнала и запишет в него записи в выбранном формате.

Сжатие файлов журнала аудита

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

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

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

Шифрование файлов журнала аудита

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

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

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

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

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

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

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

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

Вручную распаковка и расшифровка файлов журнала аудита

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

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

Включенные функции	Имя архивированного файла
Без сжатия или шифрования	`audit.timestamp.log`
Сжатие	`audit.timestamp.log.gz`
Шифрование	`audit.timestamp.log.enc`
Сжатие, шифрование	`audit.timestamp.log.gz.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.enc
    -out audit.timestamp.log

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

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

END_OF_DOCUMENT_MARKER

Управление размером файлов журнала аудита

Файл журнала аудита может значительно увеличиться и занять много места на диске. Для управления используемым пространством можно использовать ротацию логов. Это включает переименование текущего файла журнала, а затем открытие нового текущего файла журнала с использованием исходного имени. Ротация может выполняться вручную или настраиваться на автоматическое выполнение.

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

Если audit_log_rotate_on_size равна 0 (значение по умолчанию), автоматическая ротация файла журнала отключена:
- Ротация не происходит, если не выполняется вручную.
- Чтобы выполнить ротацию текущего файла, переименуйте его вручную, а затем включите audit_log_flush для закрытия файла и открытия нового текущего файла журнала с использованием исходного имени; см. Вручную.
Если audit_log_rotate_on_size больше 0, автоматическая ротация файла журнала аудита включена:
- Автоматическая ротация происходит, когда запись в текущий файл журнала приводит к превышению размера значения audit_log_rotate_on_size, а также при определенных других условиях; см. Автоматическая ротация журнала аудита. При ротации плагин журнала аудита переименовывает текущий файл журнала и открывает новый текущий файл журнала с использованием исходного имени.
- При включенной автоматической ротации audit_log_flush не оказывает никакого влияния.

Примечание

Для файлов журналов в формате JSON ротация также происходит при изменении значения системной переменной audit_log_format_unix_timestamp во время выполнения. Однако это не происходит для целей управления пространством, а скорее для того, чтобы для заданного файла журнала в формате JSON все записи в файле либо включали, либо не включали поле time.

Примечание

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

В следующих разделах более подробно описана ротация файлов журналов.

Вручную

Если audit_log_rotate_on_size равно 0 (по умолчанию), ротация журнала не происходит, если не выполняется вручную. В этом случае плагин журнала аудита закрывает и повторно открывает файл журнала, когда значение audit_log_flush меняется с отключенного на включенное. Переименование файла журнала должно выполняться вне сервера. Предположим, что имя файла журнала — audit.log, и вы хотите сохранить три последних файла журнала, циклически используя имена audit.log.1 по audit.log.3. В Unix вручную выполнить ротацию можно так:

Из командной строки переименуйте текущие файлы журналов:
```
mv audit.log.2 audit.log.3
mv audit.log.1 audit.log.2
mv audit.log audit.log.1
```
Эта стратегия перезаписывает содержимое текущего audit.log.3, ограничивая количество архивированных файлов журнала и используемое ими место.
В этот момент плагин по-прежнему записывает в текущий файл журнала, который был переименован в audit.log.1. Подключитесь к серверу и очистите файл журнала, чтобы плагин закрыл его и открыл новый файл audit.log:
```
SET GLOBAL audit_log_flush = ON;
```
audit_log_flush отличается тем, что его значение остается OFF, так что вам не нужно явно отключать его перед повторной активацией для выполнения другой очистки.

Примечание

При журнале в формате JSON ручное переименование файлов журналов аудита делает их недоступными для функций чтения журнала, поскольку плагин журнала аудита больше не может определить, что они являются частью последовательности файлов журнала (см. Раздел 6.4.5.6, «Чтение файлов журнала аудита»). Рассмотрите возможность установки значения audit_log_rotate_on_size больше 0, чтобы использовать ротацию на основе размера вместо этого.

Автоматическая ротация

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

Автоматическая ротация на основе размера также происходит в следующих случаях:

Во время инициализации плагина, если файл с именем файла журнала аудита уже существует (см. Соглашения об именовании файлов журнала аудита).
Во время завершения работы плагина.
При вызове функции audit_log_encryption_password_set() для установки пароля шифрования.

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

Начиная с MySQL 5.7.21, в переименованном файле время метки времени вставляется после базового имени и перед суффиксом. Например, если имя файла — audit.log, плагин переименовывает его в значение, подобное audit.20180115T140633.log. Метка времени — это значение UTC в формате YYYYMMDDThhmmss. Для XML-журналов метка времени указывает время ротации. Для журналов JSON — время последнего записанного события в файл.

Если файлы журналов зашифрованы, исходное имя файла уже содержит метку времени, указывающую время создания пароля шифрования (см. Соглашения об именовании файлов журнала аудита). В этом случае имя файла после ротации содержит две метки времени. Например, зашифрованный файл журнала, названный audit.log.20180110T130749-1.enc, переименовывается в значение, подобное audit.20180115T140633.log.20180110T130749-1.enc.
До MySQL 5.7.21 переименованный файл имеет метку времени и .xml в конце. Например, если имя файла — audit.log, плагин переименовывает его в значение, подобное audit.log.15159344437726520.xml. Значение метки времени похоже на метку времени Unix, где последние 7 цифр представляют дробную часть секунды. Вставив десятичную точку, значение можно интерпретировать с помощью функции FROM_UNIXTIME():
```
mysql> SELECT FROM_UNIXTIME(1515934443.7726520);
+-----------------------------------+
| FROM_UNIXTIME(1515934443.7726520) |
+-----------------------------------+
| 2018-01-14 06:54:03.772652        |
+-----------------------------------+
```

Стратегии записи в журнал аудита

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

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

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

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

Минимальное влияние на производительность и масштабируемость сервера.
Блокировка потоков, генерирующих события аудита, на самое короткое время; то есть время выделения буфера плюс время копирования события в буфер.
Данные направляются в буфер. Отдельный поток обрабатывает запись данных из буфера в файл журнала.

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

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