Проверки безопасности MySQL

Эта страница является оригинальной документацией PmaControl. Она сохраняет практичную структуру индекса для работ по оптимизации MySQL, не копируя сторонний контент и не завися от внешнего продукта.

Цель

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

Приоритетные проверки

1. Анонимные учетные записи или учетные записи без пароля.
2. Пользователи с необоснованными SUPER, FILE, PROCESS, GRANT OPTION или глобальными правами.
3. Доступ %, когда достаточно конкретного host.
4. TLS не обязателен для чувствительных потоков.
5. local_infile включен без необходимости.
6. Binary logs и backups доступны слишком широким системным учетным записям.

Базовый SQL

SELECT user, host, account_locked, password_expired
FROM mysql.user
ORDER BY user, host;

SHOW GRANTS FOR 'app_user'@'%';

Главное

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

Определите границы и соберите данные учётных записей

Составьте перечень серверов, прокси, прикладных и административных аккаунтов, реплик и средств резервирования. Для каждого аккаунта определите владельца и ожидаемый исходный узел. Приведённые столбцы относятся к MySQL: MariaDB хранит данные иначе в зависимости от версии. Используйте авторизованный аккаунт аудита и не включайте хеши паролей или секреты в отчёты.

SELECT VERSION() AS server_version,
       CURRENT_USER() AS matched_account, USER() AS connection_identity;

SELECT user, host, plugin, account_locked, password_expired, ssl_type
FROM mysql.user
ORDER BY user, host;

SELECT grantee, privilege_type, is_grantable
FROM information_schema.user_privileges
ORDER BY grantee, privilege_type;

CURRENT_USER() показывает аккаунт для проверки прав, а USER() — идентичность соединения. Глобального перечня недостаточно: изучите SHOW GRANTS, права баз и таблиц, динамические права и назначенные роли, включая активные и роли по умолчанию. Пустая строка аутентификации не доказывает отсутствие защиты: плагины различаются. Проверьте плагин, ограничения узла, блокировку и фактическую политику.

Проверьте транспорт реального соединения

SHOW GLOBAL VARIABLES WHERE Variable_name IN (
  'require_secure_transport', 'tls_version', 'local_infile',
  'secure_file_priv', 'bind_address', 'port'
);
SHOW SESSION STATUS WHERE Variable_name IN ('Ssl_cipher', 'Ssl_version');

Поля TLS сеанса описывают только текущее соединение. Unix-сокет может быть безопасным локальным транспортом без TLS-шифра. Для TCP проверьте шифрование и проверку сертификата и имени узла в драйвере приложения. Если TLS завершается на прокси, отдельно проверяйте клиент–прокси и прокси–сервер. Поддержка TLS сервером не означает, что все клиенты требуют его.

mysql --host=db.example --user=app_reader --password \
  --ssl-mode=VERIFY_IDENTITY --ssl-ca=/path/to/ca.pem

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

Оцените доступ за пределами SQL-прав

Разделяйте минимальные права по задачам: приложение, миграции, мониторинг и резервирование. Испытайте отзыв прав и ограничения узлов на новых соединениях, сохраните исходные grants для отката и отслеживайте отказы. Обновляйте сервер и коннекторы по документированному пути: поддержка плагинов зависит от версии. Для каждой находки задайте ответственного, срок исправления и проверенный результат.

Продолжение диагностики

• Включите находки в оценку и проверьте готовность через контроль состояния.

Официальные источники

• MySQL encrypted connections
• MySQL SHOW GRANTS