Пароли могут быть записаны как обычный текст в SQL-запросах, таких как CREATE USER, GRANT и SET PASSWORD. Если такие запросы регистрируются сервером MySQL как написаны, пароли в них становятся видимыми для любого пользователя с доступом к логам.

Регистрация запросов позволяет избежать записи паролей в открытом виде для следующих запросов:

CREATE USER ... IDENTIFIED BY ...
ALTER USER ... IDENTIFIED BY ...
SET PASSWORD ...
START REPLICA ... PASSWORD = ...
CREATE SERVER ... OPTIONS(... PASSWORD ...)
ALTER SERVER ... OPTIONS(... PASSWORD ...)

Пароли в этих запросах переписываются таким образом, чтобы они не отображались буквально в тексте запросов, записываемых в общий журнал запросов, журнал медленных запросов и бинарный журнал. Переписывание не применяется к другим запросам. В частности, запросы INSERT или UPDATE для системной таблицы mysql.user, которые ссылаются на буквальные пароли, регистрируются как есть, поэтому следует избегать таких запросов. (Прямое изменение таблиц предоставления прав не рекомендуется в любом случае.)

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

По умолчанию содержимое файлов журнала аудита, создаваемых плагином журнала аудита, не шифруется и может содержать конфиденциальную информацию, например текст SQL-запросов. По соображениям безопасности файлы журнала аудита должны записываться в каталог, доступ к которому имеют только сервер MySQL и пользователи с законными основаниями для просмотра логов. См. Раздел 8.4.5.3, «MySQL Enterprise Audit Security Considerations».

Запросы, полученные сервером, могут быть переписаны, если установлен плагин переписывания запросов (см. Плагины переписывания запросов). В этом случае опция --log-raw влияет на запись запросов следующим образом:

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

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

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

Реплики хранят пароль сервера-источника репликации в хранилище метаданных подключения, которое по умолчанию является таблицей в базе данных mysql под названием slave_master_info. Использование файла в каталоге данных для хранилища метаданных подключения теперь устарело, но все еще возможно (см. Раздел 19.2.4, «Журнал ретрансляции и хранилища метаданных репликации»). Убедитесь, что к хранилищу метаданных подключения может получить доступ только администратор базы данных. Альтернативой хранению пароля в хранилище метаданных подключения является использование запроса START REPLICA или START GROUP_REPLICATION для указания учетных данных для подключения к источнику.

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