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

Фильтрация аудита основана на правилах:

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

Сведения о написании правил фильтрации см. в разделе 8.4.5.8 «Создание определений фильтров аудиторного журнала».

Фильтры аудиторного журнала могут быть определены и изменены с использованием SQL-интерфейса на основе вызовов функций. По умолчанию определения фильтров аудиторного журнала хранятся в базе данных системы mysql, и вы можете отобразить фильтры аудита, выполнив запрос к таблице mysql.audit_log_filter. Можно использовать другую базу данных для этой цели, в этом случае вам следует выполнить запрос к таблице database_name.audit_log_filter. Дополнительную информацию см. в разделе 8.4.5.2 «Установка или удаление MySQL Enterprise Audit».

В рамках текущей сессии значение только для чтения системной переменной audit_log_filter_id указывает, назначен ли фильтр сессии.

audit_log_filter_set_filter(): Определение фильтра.

audit_log_filter_remove_filter(): Удаление фильтра.

audit_log_filter_set_user(): Начало фильтрации учетной записи пользователя.

audit_log_filter_remove_user(): Остановка фильтрации учетной записи пользователя.

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

Для использования любой функции фильтрации необходимо включить плагин audit_log, в противном случае произойдет ошибка. Кроме того, таблицы аудита должны существовать, в противном случае произойдет ошибка. Инструкции по установке плагина audit_log и его соответствующих функций и таблиц см. в разделе 8.4.5.2 «Установка или удаление MySQL Enterprise Audit».

Для использования любой функции фильтрации пользователю необходимо иметь привилегию AUDIT_ADMIN SUPER или произойдет ошибка. Для предоставления одной из этих привилегий учетной записи пользователя используйте данную инструкцию:

GRANT privilege ON *.* TO user;

В качестве альтернативы, если вы предпочитаете не предоставлять привилегию AUDIT_ADMIN или SUPER, но при этом разрешать пользователям доступ к определенным функциям фильтрации, можно определить хранимые программы “оберток”. Этот метод описан в контексте функций ключей в разделе "Использование функций общего назначения для работы с ключами"; его можно адаптировать для использования с функциями фильтрации.

Плагин audit_log работает в режиме устаревшей версии, если он установлен, но соответствующие таблицы и функции аудита не созданы. Плагин записывает эти сообщения в журнал ошибок при запуске сервера:

[Warning] Plugin audit_log reported: 'Failed to open the audit log filter tables.'
[Warning] Plugin audit_log reported: 'Audit Log plugin supports a filtering,
which has not been installed yet. Audit Log plugin will run in the legacy
mode, which will be disabled in the next release.'

В режиме устаревшей версии (устаревшем) фильтрация может выполняться только по учетной записи события или статусу. Подробнее см. в разделе 8.4.5.10 «Фильтрация аудиторного журнала в режиме устаревшей версии».

Теоретически возможно, что пользователь с достаточными правами может случайно создать элемент “отмена” в фильтре аудиторного журнала, который препятствует доступу к системе самим администраторам и другим администраторам. Привилегия AUDIT_ABORT_EXEMPT доступна, чтобы разрешить пользователю всегда выполнять запросы, даже если элемент “отмена” их заблокирует. Учетные записи с этой привилегией, следовательно, могут использоваться для восстановления доступа к системе после неправильной настройки аудита. Запрос все равно регистрируется в аудиторском журнале, но вместо отклонения он разрешается благодаря привилегии.

Учетные записи, созданные с привилегией SYSTEM_USER, имеют привилегию AUDIT_ABORT_EXEMPT, автоматически назначенную при их создании. Привилегия AUDIT_ABORT_EXEMPT также назначается существующим учетным записям с привилегией SYSTEM_USER при выполнении процедуры обновления, если таким учетным записям не назначена эта привилегия.

Если пользователю назначен фильтр, журнал аудита использует этот фильтр.

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

В противном случае журнал аудита не выбирает никаких событий аудита из сессии для обработки.

Чтобы отменить назначение фильтра учетной записи пользователя:

SELECT audit_log_filter_remove_user('user1@localhost');

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

Чтобы назначить другой фильтр учетной записи пользователя:

SELECT audit_log_filter_set_filter('log_nothing', '{ "filter": { "log": false } }');
SELECT audit_log_filter_set_user('user1@localhost', 'log_nothing');

Фильтрация текущих сессий для учетной записи не изменяется. Последующие подключения от учетной записи фильтруются с использованием нового фильтра. Для показанного здесь фильтра это означает отсутствие регистрации новых подключений от user1@localhost.