MariaDB Audit Plugin - Настройки логов

События, которые регистрирует плагин MariaDB Audit Plugin, обычно группируются в разные типы: события подключения, запросов и таблиц. Для регистрации событий этих типов установите переменную server_audit_events в CONNECT, QUERY, или TABLE. Для регистрации нескольких типов событий перечислите их в списке через запятую:

SET GLOBAL server_audit_events = 'CONNECT,QUERY,TABLE';

Вы можете задать аналогичное значение в файле конфигурации так:

[mysqld]
...
server_audit_events=connect,query

По умолчанию, регистрация отключена. Чтобы включить её, установите переменную server_audit_logging в ON. Обратите внимание, что если кеш запросов query cache включен, и запрос возвращается из кеша, то записи TABLE в логе не появятся, так как сервер не открывал и не обращается к таблицам, а использовал кэшированные результаты. Поэтому вы можете отключить кеширование запросов.

На самом деле, существует несколько типов событий, которые можно регистрировать, а не только три упомянутых выше. Полный список соответствующих системных переменных подробно описан на странице Системные переменные Server_Audit, а переменные состояния — на странице Переменные состояния Server_Audit в этой документации. Некоторые из основных типов представлены ниже:

Поскольку существуют другие типы запросов помимо DDL и DML, использование QUERY_DDL и QUERY_DML вместе не эквивалентно использованию QUERY. Начиная с версии 1.3.0 плагина Audit Plugin, появилась опция QUERY_DCL для регистрации запросов типа DCL (например, GRANT и REVOKE операторы). В той же версии была добавлена переменная server_audit_query_log_limit, чтобы установить длину записи в логе. Ранее запись лога обрезалась из-за длинных строк запросов.

Регистрация событий подключения

Если плагин Audit Plugin настроен на регистрацию событий подключения, он будет регистрировать подключения, разключения и неудачные подключения. В случае неудачного подключения в логе будет указан код ошибки.

Можно определить список пользователей, для которых события могут быть исключены или включены для отслеживания их активности в базе данных. Однако этот список будет игнорироваться при регистрации событий подключения. Это связано с тем, что стандарты аудита различают технических и реальных пользователей. Подключения должны регистрироваться для всех типов пользователей; доступ к объектам должен регистрироваться только для реальных пользователей.

Регистрация событий запросов

Если включены типы событий QUERY, QUERY_DDL, QUERY_DML, QUERY_DML_NO_SELECT, и/или QUERY_DCL, то соответствующие типы запросов, которые выполняются, будут регистрироваться для определенных пользователей. Запросы будут регистрироваться точно так, как они выполняются, в виде простого текста. Это потенциальная уязвимость безопасности: любой, у кого есть доступ к файлам логов, сможет прочитать запросы. Поэтому убедитесь, что доступ к файлам логов имеют только доверенные пользователи, и файлы хранятся в защищенном месте. Альтернативой является использование типа событий TABLE вместо типов событий, связанных с запросами.

Запросы также регистрируются, если они не могут быть выполнены или завершены неудачно. Например, запрос будет зарегистрирован из-за синтаксической ошибки или из-за отсутствия у пользователя необходимых привилегий для доступа к объекту. Эти запросы могут быть обработаны по коду ошибки, указанному в логе.

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

Ниже приведен пример, в котором пользователь пытается выполнить оператор UPDATE для таблицы, к которой у него нет прав:

UPDATE employees 
SET salary = salary * 1.2 
WHERE emp_id = 18236;

ERROR 1142 (42000): 
UPDATE command denied to user 'bob'@'localhost' for table 'employees'

Просматривая журнал плагина Audit Plugin (server_audit.log) для этой записи, вы можете увидеть следующую запись:

20170817 11:07:18,ip-172-30-0-38,bob,localhost,15,46,QUERY,company,
'UPDATE employees SET salary = salary * 1.2 WHERE emp_id = 18236',1142

Эта запись лога будет на одной строке, но здесь она отформатирована для лучшего отображения. В этой записи журнала вы можете увидеть дату и время запроса, за которым следует хост сервера, пользователь и хост для учетной записи. Далее следуют идентификаторы соединения и запроса (т.е., 15 и 46). После типа события журнала (т.е., QUERY) записываются имя базы данных (т.е., company), запрос и номер ошибки.

Обратите внимание, что последнее значение в записи лога — 1142. Это номер ошибки запроса. Чтобы найти неудачные запросы, вам нужно искать два элемента: обозначение, указывающее, что это запись QUERY, и последнее значение для записи. Если запрос выполнен успешно, значение будет 0.

Запросы, не включённые в подчинённые типы событий запросов

Обратите внимание, что тип события QUERY будет регистрировать запросы, которые не включены ни в один из подчинённых типов событий QUERY_*, таких как:

• CREATE FUNCTION
• DROP FUNCTION
• CREATE PROCEDURE
• DROP PROCEDURE
• SET
• CHANGE MASTER TO
• FLUSH
• KILL
• CHECK
• OPTIMIZE
• LOCK
• UNLOCK
• ANALYZE
• INSTALL PLUGIN
• UNINSTALL PLUGIN
• INSTALL SONAME
• UNINSTALL SONAME
• EXPLAIN

Регистрация событий таблиц

MariaDB имеет возможность записывать события таблиц в журналы—это не функция MySQL. Эта функция является единственным способом записи логов о том, какие таблицы были обработаны через представление, хранимую процедуру, хранимую функцию или триггер. Без этой функции запись лога о запросе показывает только используемое представление, хранимую процедуру или функцию, а не основанные таблицы. Конечно, вы можете создать пользовательское приложение для разбора каждого выполняемого запроса, чтобы найти используемые SQL-операторы и доступные таблицы, но это нагрузит ресурсы системы. Регистрация событий таблиц значительно проще: она добавляет строку в журнал для каждой обработанной таблицы без анализа. Она включает информацию о чтении или записи.

Если вы хотите отслеживать доступ пользователей к определённым базам данных или таблицам (например, mysql.user), вы можете искать их в журнале. Затем, если вы хотите увидеть запрос, который обратился к определённой таблице, запись в журнале аудита будет содержать идентификатор запроса. Вы можете использовать его для поиска той же записи запроса в том же журнале. Это может быть полезно при поиске в журнале, содержащем десятки тысяч записей.

Благодаря опции TABLE, вы можете отключить регистрацию запросов и по-прежнему знать, кто обращался к каким таблицам. Вы можете отключить регистрацию событий QUERY для предотвращения регистрации конфиденциальных данных. Поскольку регистрация событий таблиц будет регистрировать, кто обращался к какой таблице, вы по-прежнему можете отслеживать подозрительную активность по логу. Этого часто достаточно для выполнения требований аудита.

Ниже приведён пример с включёнными событиями TABLE и QUERY. Для этой ситуации предположим, что в базе данных company существует представление, в котором выбираются столбцы из нескольких таблиц, связанных с конфиденциальной информацией о сотрудниках, в частности, со ставками зарплаты. Несмотря на принятые меры предосторожности, гарантирующие, что доступ к этим таблицам имеют только определённые учетные записи пользователей, мы будем отслеживать журналы плагина Audit Plugin для всех, кто обращается к ним — напрямую или косвенно через представление.

20170817 16:04:33,ip-172-30-0-38,root,localhost,29,913,READ,company,employees,
20170817 16:04:33,ip-172-30-0-38,root,localhost,29,913,READ,company,employees_salaries,
20170817 16:04:33,ip-172-30-0-38,root,localhost,29,913,READ,company,ref_job_titles,
20170817 16:04:33,ip-172-30-0-38,root,localhost,29,913,READ,company,org_departments,
20170817 16:04:33,ip-172-30-0-38,root,localhost,29,913,QUERY,company,
'SELECT * FROM employee_pay WHERE title LIKE \'%Executive%\'  OR title LIKE \'%Manager%\'',0

Хотя пользователь выполнил только один оператор SELECT, в журнал записывается несколько записей: по одной для каждой обработанной таблицы и одна запись для запроса к представлению (т.е., employee_pay). Мы можем предположить, что всё это относится к одному запросу, поскольку у них все одинаковые идентификаторы соединения и запроса (т.е., 29 и 913).

Регистрация активности пользователей

Плагин Audit Plugin будет регистрировать действия всех пользователей в базе данных или только тех пользователей, которых вы указали. Активность в базе данных определяется как событие запроса или событие таблицы. События подключения регистрируются для всех пользователей.

Пользователей, подлежащих включению в журнал, можно указать с помощью переменной server_audit_incl_users, а исключить — с помощью переменной server_audit_excl_users. Это может быть полезно, если вы хотите регистрировать записи, но не заинтересованы в записях от доверенных приложений и хотите исключить их из журналов.

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

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

Следующий пример показывает, как добавить новое имя пользователя в переменную server_audit_incl_users без удаления предыдущих имён пользователей:

SET GLOBAL server_audit_incl_users = CONCAT(@@global.server_audit_incl_users, ',Maria');

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

Исключение или включение пользователей

По умолчанию события от всех пользователей регистрируются, но определённых пользователей можно исключить из регистрации, используя переменную server_audit_excl_users. Например, чтобы исключить пользователей valerianus и rocky из регистрации своих событий:

server_audit_excl_users=valerianus,rocky

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

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

Обратите внимание, что события CONNECT всегда регистрируются для всех пользователей независимо от этих двух настроек. Регистрация также основана только на имени пользователя, а не на сочетании имени пользователя и имени хоста, которое MariaDB использует для определения привилегий.