6.3.1 Configuring MySQL to Use Encrypted Connections — MySQL 5.7

6.3.1 Настройка MySQL для использования шифрованных соединений

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

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

Между серверами-источником и репликаторами. См. Раздел 16.3.8, «Настройка репликации для использования шифрованных соединений».
Между серверами Group Replication. См. Раздел 17.6.2, «Поддержка SSL (Secure Socket Layer) в Group Replication».
Программными клиентами, основанными на MySQL C API. См. .

Инструкции по созданию необходимых файлов сертификата и ключа доступны в Разделе 6.3.3, «Создание сертификатов и ключей SSL и RSA».

Настройка сервера при запуске для шифрованных соединений

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

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

Эти системные переменные на стороне сервера указывают файлы сертификата и ключа, которые использует сервер при разрешении клиентам устанавливать шифрованные соединения:

ssl_ca: Путь к файлу сертификата Удостоверяющего центра (CA). (ssl_capath аналогичен, но указывает путь к каталогу файлов сертификатов CA.)
ssl_cert: Путь к файлу сертификата открытого ключа сервера. Этот сертификат может быть отправлен клиенту и проверен по сертификату CA, которым он обладает.
ssl_key: Путь к файлу закрытого ключа сервера.

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

[mysqld]
ssl_ca=ca.pem
ssl_cert=server-cert.pem
ssl_key=server-key.pem

Чтобы дополнительно указать, что клиенты обязаны использовать шифрованные соединения, включите системную переменную require_secure_transport:

[mysqld]
ssl_ca=ca.pem
ssl_cert=server-cert.pem
ssl_key=server-key.pem
require_secure_transport=ON

Каждое имя системной переменной сертификата и ключа указывает на файл в формате PEM. Если вам необходимо создать необходимые файлы сертификата и ключа, см. Раздел 6.3.3, «Создание сертификатов и ключей SSL и RSA». Серверы MySQL, скомпилированные с использованием OpenSSL, могут автоматически генерировать недостающие файлы сертификата и ключа при запуске. См. Раздел 6.3.3.1, «Создание сертификатов и ключей SSL и RSA с помощью MySQL». В качестве альтернативы, если у вас есть дистрибутив исходного кода MySQL, вы можете протестировать свою настройку, используя демонстрационные файлы сертификата и ключа в каталоге mysql-test/std_data.

Сервер выполняет автоматическое обнаружение файлов сертификата и ключа. Если не заданы явные параметры шифрованных соединений, кроме --ssl (возможно, вместе с ssl_cipher) для настройки шифрованных соединений, сервер пытается автоматически включить поддержку шифрованных соединений при запуске:

Если сервер обнаружит корректные файлы сертификата и ключа с именами ca.pem, server-cert.pem и server-key.pem в каталоге данных, он включит поддержку шифрованных соединений для клиентов. (Файлы не обязательно были сгенерированы автоматически; важно, чтобы у них были эти имена и они были корректны.)
Если сервер не найдёт корректные файлы сертификата и ключа в каталоге данных, он продолжит выполнение, но без поддержки шифрованных соединений.

Если сервер автоматически включит поддержку шифрованных соединений, он запишет заметку в журнал ошибок. Если сервер обнаружит, что сертификат CA самоподписанный, он запишет предупреждение в журнал ошибок. (Сертификат самоподписанный, если он был создан автоматически сервером или вручную с помощью mysql_ssl_rsa_setup.)

MySQL также предоставляет эти системные переменные для управления шифрованными соединениями на стороне сервера:

ssl_cipher: Список разрешённых шифров для шифрования соединения.
ssl_crl: Путь к файлу, содержащему списки отзыва сертификатов. (ssl_crlpath аналогичен, но указывает путь к каталогу файлов списков отзыва сертификатов.)
tls_version: Какие протоколы шифрования разрешены сервером для шифрованных соединений; см. Раздел 6.3.2, «Протоколы и шифры TLS шифрованных соединений». Например, вы можете настроить tls_version, чтобы предотвратить использование клиентами менее безопасных протоколов.

Настройка шифрованных подключений на стороне клиента

Полный список параметров клиента, связанных с установлением шифрованных подключений, см. в разделе Параметры командной строки для шифрованных подключений.

По умолчанию программы-клиенты MySQL пытаются установить шифрованное соединение, если сервер поддерживает шифрование, с дальнейшим управлением, доступным через параметр --ssl-mode:

При отсутствии параметра --ssl-mode, клиенты пытаются подключиться с использованием шифрования, переходя к нешифрованному подключению, если шифрованное подключение не может быть установлено. Это также поведение с явным параметром --ssl-mode=PREFERRED.
С параметром --ssl-mode=REQUIRED, клиенты требуют шифрованного соединения и завершаются ошибкой, если оно не может быть установлено.
С параметром --ssl-mode=DISABLED, клиенты используют нешифрованное соединение.
С параметрами --ssl-mode=VERIFY_CA или --ssl-mode=VERIFY_IDENTITY, клиенты требуют шифрованного соединения и также выполняют проверку по отношению к сертификату серверной CA и (с VERIFY_IDENTITY) по отношению к имени сервера хоста в его сертификате.

Важно

Значение по умолчанию, --ssl-mode=PREFERRED, создаёт шифрованное подключение, если другие параметры по умолчанию не изменены. Однако, для предотвращения сложных атак «человек посередине», важно, чтобы клиент проверял личность сервера. Параметры --ssl-mode=VERIFY_CA и --ssl-mode=VERIFY_IDENTITY являются лучшим выбором, чем значение по умолчанию, для предотвращения этого типа атаки. VERIFY_CA заставляет клиента проверять, является ли сертификат сервера действительным. VERIFY_IDENTITY заставляет клиента проверять, является ли сертификат сервера действительным, а также проверяет, соответствует ли имя хоста, используемое клиентом, идентификатору в сертификате сервера. Для реализации одного из этих параметров необходимо сначала убедиться, что сертификат CA для сервера надёжно доступен всем клиентам, которые его используют в вашей среде, в противном случае возникнут проблемы с доступностью. По этой причине они не являются значениями по умолчанию.

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

Следующие параметры на стороне клиента идентифицируют сертификаты и ключи, используемые клиентами при установлении шифрованных подключений к серверу. Они аналогичны системным переменным ssl_ca, ssl_cert и ssl_key, используемым на стороне сервера, но --ssl-cert и --ssl-key идентифицируют открытый и закрытый ключи клиента:

--ssl-ca: Путь к файлу сертификата Удостоверяющего центра (CA). Если используется, этот параметр должен указывать тот же сертификат, который используется сервером. (--ssl-capath аналогичен, но указывает путь к каталогу файлов сертификатов CA.)
--ssl-cert: Путь к файлу сертификата открытого ключа клиента.
--ssl-key: Путь к файлу закрытого ключа клиента.

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

Чтобы указать сертификат CA, используйте --ssl-ca (или --ssl-capath) и укажите --ssl-mode=VERIFY_CA.
Чтобы включить проверку имени хоста, используйте --ssl-mode=VERIFY_IDENTITY вместо --ssl-mode=VERIFY_CA.

Примечание

Проверка имени хоста с помощью VERIFY_IDENTITY не работает с самозаверяющими сертификатами, которые создаются автоматически сервером или вручную с помощью mysql_ssl_rsa_setup (см. Раздел 6.3.3.1, «Создание SSL и RSA сертификатов и ключей с помощью MySQL»). Такие самозаверяющие сертификаты не содержат имя сервера как значение Common Name.

До MySQL 5.7.23 проверка имени хоста также не работает с сертификатами, в которых имя Common Name указано с использованием подстановочных символов, поскольку это имя сравнивается дословно с именем сервера.

MySQL также предоставляет эти параметры для управления шифрованными подключениями на стороне клиента:

--ssl-cipher: Список допустимых шифров для шифрования соединения.
--ssl-crl: Путь к файлу, содержащему списки отозванных сертификатов. (--ssl-crlpath аналогичен, но указывает путь к каталогу файлов списков отозванных сертификатов.)
--tls-version: Допустимые протоколы шифрования; см. Раздел 6.3.2, «Протоколы и шифры TLS шифрованного соединения».

В зависимости от требований к шифрованию учётной записи MySQL, используемой клиентом, может потребоваться указать определённые параметры для подключения к серверу MySQL с использованием шифрования.

Предположим, что вы хотите подключиться с помощью учётной записи, у которой нет особых требований к шифрованию или которая была создана с помощью оператора CREATE USER, который включал в себя предложение REQUIRE SSL. При условии, что сервер поддерживает шифрованные подключения, клиент может подключиться с использованием шифрования без параметра --ssl-mode или с явным параметром --ssl-mode=PREFERRED:

mysql

Или:

mysql --ssl-mode=PREFERRED

Для учётной записи, созданной с помощью предложения REQUIRE SSL, попытка подключения завершится ошибкой, если шифрованное подключение не может быть установлено. Для учётной записи без особых требований к шифрованию попытка возвращается к нешифрованному подключению, если шифрованное подключение не может быть установлено. Чтобы предотвратить возврат и завершить ошибкой, если шифрованное подключение не может быть получено, подключитесь следующим образом:

mysql --ssl-mode=REQUIRED

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

Для учётных записей, созданных с предложением REQUIRE X509, клиенты должны указать как минимум --ssl-cert и --ssl-key. Кроме того, рекомендуется использовать --ssl-ca (или --ssl-capath), чтобы можно было проверить открытый сертификат, предоставленный сервером. Например (введите команду в одну строку):
```
mysql --ssl-ca=ca.pem
      --ssl-cert=client-cert.pem
      --ssl-key=client-key.pem
```
Для учётных записей, созданных с предложением REQUIRE ISSUER или REQUIRE SUBJECT, требования к шифрованию такие же, как для REQUIRE X509, но сертификат должен соответствовать выданному или субъекту, соответственно, указанным в определении учётной записи.

Дополнительную информацию о предложении REQUIRE см. в Разделе 13.7.1.2, «CREATE USER Statement».

Сервера MySQL могут генерировать файлы сертификатов и ключей клиентов, которые клиенты могут использовать для подключения к экземплярам сервера MySQL. См. Раздел 6.3.3, «Создание SSL и RSA сертификатов и ключей».

Важно

Если клиент, подключающийся к экземпляру сервера MySQL, использует сертификат SSL с расширением extendedKeyUsage (расширение X.509 v3), расширенное использование ключа должно включать аутентификацию клиента (clientAuth). Если сертификат SSL указан только для аутентификации сервера (serverAuth) и других целей, не связанных с сертификатами клиентов, проверка сертификата завершается неудачей, и подключение клиента к экземпляру сервера MySQL прерывается. Расширения extendedKeyUsage в сертификатах SSL, генерируемых сервером MySQL (как описано в разделе 6.3.3.1, «Создание SSL и RSA сертификатов и ключей с помощью MySQL»), нет, а также в сертификатах SSL, созданных с помощью команды openssl по инструкциям в разделе 6.3.3.2, «Создание SSL сертификатов и ключей с помощью openssl». Если вы используете собственный сертификат клиента, созданный другим способом, убедитесь, что любое расширение extendedKeyUsage включает аутентификацию клиента.

Для предотвращения использования шифрования и переопределения других --ssl-xxx параметров вызовите программу-клиент с --ssl-mode=DISABLED:

mysql --ssl-mode=DISABLED

Чтобы определить, использует ли текущее подключение к серверу шифрование, проверьте значение сеанса переменной состояния Ssl_cipher. Если значение пусто, подключение не зашифровано. В противном случае подключение зашифровано, и значение указывает шифр шифрования. Например:

mysql> SHOW SESSION STATUS LIKE 'Ssl_cipher';
+---------------+---------------------------+
| Variable_name | Value                     |
+---------------+---------------------------+
| Ssl_cipher    | DHE-RSA-AES128-GCM-SHA256 |
+---------------+---------------------------+

Для клиента mysql альтернативой является использование команды STATUS или \s и проверка строки SSL:

mysql> \s
...
SSL: Not in use
...

Или:

mysql> \s
...
SSL: Cipher in use is DHE-RSA-AES128-GCM-SHA256
...

Настройка обязательного шифрования подключений

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

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

Чтобы потребовать от клиентов подключение с использованием зашифрованных подключений, включите переменную системы require_secure_transport. Например, поместите эти строки в файл сервера my.cnf:

[mysqld]
require_secure_transport=ON

При включенной require_secure_transport подключения клиентов к серверу обязаны использовать какой-либо вид защищенного транспорта, а сервер разрешает только подключения TCP/IP, использующие SSL, или подключения, использующие файл сокета (в Unix) или общую память (в Windows). Сервер отклоняет попытки подключения без шифрования, которые завершаются ошибкой.

Чтобы вызвать программу-клиент таким образом, чтобы она требовала зашифрованного подключения независимо от того, требует ли сервер шифрования, используйте значение параметра --ssl-mode равное REQUIRED, VERIFY_CA или VERIFY_IDENTITY. Например:

mysql --ssl-mode=REQUIRED
mysqldump --ssl-mode=VERIFY_CA
mysqladmin --ssl-mode=VERIFY_IDENTITY

Чтобы настроить учетную запись MySQL для использования только через зашифрованные подключения, включите в оператор CREATE USER, создающий учетную запись, предложение с указанием требуемых вами характеристик шифрования. Например, для требования зашифрованного подключения и использования действительного сертификата X.509 используйте REQUIRE X509:

CREATE USER 'jeffrey'@'localhost' REQUIRE X509;

Дополнительную информацию о предложении REQUIRE см. в разделе 13.7.1.2, «Оператор CREATE USER».

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