Главная особенность Microsoft SQL Server заключается в том, что его основной клиент, SQL Server Management Studio, всегда запрашивает шифрование, даже при снятом флажке Encrypt Connection:

fed_1

Для любого анализатора сетевых пакетов это означает, что либо зашифрованный трафик невозможно будет прослушать, либо для его расшифровки потребуется приватный ключ сервера. Сниффер DataArmor Database Firewall умеет расшифровывать трафик SSL при наличии приватного ключа, поэтому остановимся на процедуре настройки сервера для работы DataArmor в этом режиме.

По умолчанию, сервер «из коробки» настроен на работу с эфемерными ключами. Для него не заданы какие-либо статические ключи и сертификаты — сертификат и ключ генерируется всякий раз при подключении. Эта стратегия гарантирует высокий уровень безопасности всех сетевых соединений с сервером. Неудивительно, что встроенный криптопровайдер Microsoft во всех последних версиях Windows повысил приоритет всех своих эфемерных шифров. И теперь, без дополнительной настройки сервера, переключаться на более лояльные к сниффингу шифры стало сложнее.

Для отключения эфемерных ключей и получения статического приватного ключа нам потребуется, во первых, установить сертификат. Сделать это можно из SQL Server Configuration Manager, в свойствах протоколов экземпляра сервера (Protocols for MSSQLSERVER), сетевой конфигурации (SQL Server Network Configuration), на вкладке Certificate:

fed_2

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

Подготовка самого сертификата требует соблюдения некоторых требований Microsoft:

  1. Сертификат должен находиться в хранилище сертификатов локального компьютера или текущего пользователя.
  2. Текущее системное время должно быть больше значения свойства сертификата Valid from и быть меньше значения свойства сертификата Valid to.
  3. Сертификат должен быть предназначен для проверки подлинности сервера. Для этого свойство Enhanced Key Usage сертификата должно быть установлено в значение Server Authentication (1.3.6.1.5.5.7.3.1).
  4. Сертификат должен быть создан со значением KeySpec параметра AT_KEYEXCHANGE. Обычно в свойстве использования ключа сертификата (KEY_USAGE) также предусмотрено шифрование ключа (CERT_KEY_ENCIPHERMENT_KEY_USAGE).
  5. Свойство Subject сертификата должно указывать, что общее имя (CN) совпадает с именем узла или полным доменным именем (FQDN) сервера. Если SQL Server выполняется в кластере отработки отказа, общее имя должно совпадать с именем узла или полным доменным именем виртуального сервера, а сертификаты должны быть предоставлены всем узлам отказоустойчивого кластера.

Для генерации сертификата, удовлетворяющего таким условиям, можно воспользоваться утилитой MakeCert , которая доступна в составе Windows SDK:

makecert -r -pe -n "CN= SUDA24322118" -b 01/09/2016 -e 01/09/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

В данном примере сертификат SUDA24322118 будет создан и размещен в локальном хранилище сертификатов. На этом этапе этот сертификат уже можно выбрать из списка сертификатов SQL Server Configuration Manager. И после перезагрузки сервера, он будет использоваться для защиты сетевых соединений.

Следующий шаг — получить ключ сервера. Для этого необходимо его экспортировать из хранилища сертификатов, а из полученного certname.pfx извлечь key.pem:

openssl pkcs12 -in certname.pfx -nocerts -out key.pem -nodes

key.pem — это тот самый приватный ключ, который требует сниффер.

Сервер сконфигурирован, его приватный ключ получен, но он по прежнему использует эфемерные алгоритмы, т.к. это зона ответственности криптопровайдера. Для отключения эфемерных алгоритмов обмена ключами необходимо воспользоваться соответствующим руководством Microsoft, либо его GUI-интерпретацией — IISCrypto:

fed_3

Здесь необходимо отключить 2 алгоритма обмена ключами: Diffie-Hellman и ECDH. Изменения вступят в силу сразу после перезагрузки хоста сервера.

Последний этап — установить ключ в DataArmor Database Security. Для этого открываем вкладку Configurations, выбираем необходимую базу, открываем окно Certificates, вкладку PrivateKey и вставляем сюда содержимое файла с приватным ключом (он текстовый):

fed_4

На этом, настройка сервера и файрвола для сниффинга Microsoft SQL Server закончена. А мы еще немного подумаем, как сделать защиту вашей инфраструктуры проще и безопаснее.

Комментарии