Топ-7 лучших практик безопасности MySQL для защиты вашей базы данных

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

1. Управление безопасным доступом пользователей

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

Создавайте надежные учетные записи

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

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

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

Пример:

CREATE USER 'webapp_user'@'10.0.10.%' IDENTIFIED BY 'используйте-настоящий-секрет-здесь';

GRANT SELECT, INSERT, UPDATE ON mydatabase.* TO 'webapp_user'@'10.0.10.%';

Вам не нужен FLUSH PRIVILEGES после обычных операторов CREATE USER или GRANT. MySQL автоматически обновляет таблицы привилегий для этих операторов.

Регулярно проверяйте учетные записи:

SELECT user, host, account_locked FROM mysql.user ORDER BY user, host;
SHOW GRANTS FOR 'webapp_user'@'10.0.10.%';

2. Ограничьте сетевой доступ

Ограничьте сетевые пути к MySQL. Эффективное значение по умолчанию зависит от вашей версии MySQL и пакета, поэтому проверьте ваш работающий сервер, а не предполагайте, что он прослушивает только локально.

Проверьте слушатели:

ss -ltnp | grep 3306

Привяжите MySQL к localhost, когда доступ нужен только локальным клиентам:

[mysqld]
bind-address = 127.0.0.1

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

3. Используйте TLS для соединений

Шифрование данных при передаче предотвращает перехват и атаки «человек посередине». MySQL поддерживает шифрование SSL/TLS для соединений клиент-сервер.

Конфигурация сервера обычно выглядит так:

[mysqld]
ssl-ca=/path/to/ca.pem
ssl-cert=/path/to/server-cert.pem
ssl-key=/path/to/server-key.pem

Пример клиента:

mysql -h ваш_хост -u ваш_пользователь -p --ssl-mode=REQUIRED

Для более строгой проверки используйте --ssl-mode=VERIFY_IDENTITY с именем хоста, соответствующим сертификату. REQUIRED шифрует соединение, но не проверяет личность сервера так строго.

4. Поддерживайте MySQL в актуальном состоянии

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

Отслеживайте поток релизов, который вы используете, применяйте обновления безопасности и тестируйте обновления в staging перед production. Если вы используете управляемый сервис баз данных, ознакомьтесь с политикой обслуживания провайдера и установите окно обслуживания, за которым ваша команда действительно следит.

5. Укрепите конфигурацию сервера MySQL

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

Отключите local_infile, если вашим приложениям не нужен LOAD DATA LOCAL INFILE:

[mysqld]
local_infile = 0

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

6. Аудит и мониторинг логов

Логирование имеет решающее значение для обнаружения подозрительной активности и для криминалистического анализа после инцидента безопасности.

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

Как минимум, отслеживайте:

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

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

7. Защитите данные в состоянии покоя

В то время как SSL/TLS защищает данные при передаче, шифрование данных в состоянии покоя защищает их в случае компрометации базового хранилища.

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

MySQL также имеет функции шифрования, такие как AES_ENCRYPT() и AES_DECRYPT(), но не жестко кодируйте ключи в SQL и не храните их рядом с данными.

Упрощенный пример:

UPDATE users
SET sensitive_data = AES_ENCRYPT('user_private_info', @encryption_key)
WHERE user_id = 1;

SELECT AES_DECRYPT(sensitive_data, @encryption_key)
FROM users
WHERE user_id = 1;

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

Вывод

Начните с мер контроля, которые устраняют наибольший риск: пользователи с минимальными привилегиями, частный сетевой доступ, TLS, обновления и проверенные резервные копии. Затем добавьте аудит логирования и меры шифрования, соответствующие вашей модели соответствия и угроз. Пересматривайте настройку после каждого крупного изменения схемы, инфраструктуры или доступа.