При подключении к Microsoft SQL Server через публичные или недоверенные сети защита данных с помощью шифрования подключений становится обязательной. Начиная с SQL Server 2016, для этой цели используется протокол TLS, заменивший устаревший SSL. Эта статья предоставляет пошаговое руководство по настройке обязательного TLS-шифрования для клиентских подключений, включая установку сертификатов, конфигурацию сервера и клиентов, а также устранение типичных ошибок.
1. Установка TLS-сертификата на сервере
Для включения шифрования подключений на SQL Server требуется TLS-сертификат. Подойдут коммерческие сертификаты, сертификаты от внутреннего центра сертификации (CA) или самоподписанные сертификаты (рекомендуются только для тестов). Сертификат должен соответствовать следующим критериям:
– Назначение (Enhanced Key Usage): Server Authentication (OID 1.3.6.1.5.5.7.3.1).
– Срок действия: Сертификат должен быть действителен.
– Хранилище: Установлен в хранилище сертификатов компьютера (certlm.msc) или пользователя (certmgr.msc).
– Subject Name: Должно совпадать с именем хоста сервера SQL Server.
– Доверие: Клиенты должны доверять сертификату или его издателю.
Генерация самоподписанного сертификата
В тестовой среде можно создать самоподписанный сертификат через PowerShell. Пример для сервера srv-sql1.resource.com:
New-SelfSignedCertificate -DnsName srv-sql1.resource.com -CertStoreLocation cert:\LocalMachine\My
Если SQL Server доступен по нескольким именам (например, хост, полное доменное имя или листенер группы Always-On), укажите их в Subject Alternative Name (SAN). Пример создания сертификата с SAN и сроком действия 3 года:
$todaydate = Get-Date
$add3year = $todaydate.AddYears(3)
$newcert = New-SelfSignedCertificate -DnsName srv-sql1,srv-sql1.resource.loc,SQL-DB-liste.resource.loc -CertStoreLocation cert:\LocalMachine\My -NotAfter $add3year
Импорт в доверенные сертификаты
Для доверия клиентов к самоподписанному сертификату экспортируйте его и добавьте в хранилище доверенных корневых центров:
$certFile = Export-Certificate -Cert $newcert -FilePath C:\certname.cer
Import-Certificate -CertStoreLocation Cert:\LocalMachine\AuthRoot -FilePath $certFile.FullName
2. Конфигурация SQL Server для TLS
После установки сертификата настройте SQL Server для принудительного TLS-шифрования:
1. Откройте SQL Server Configuration Manager.
2. Перейдите в SQL Server Network Configuration → Protocols for MSSQLSERVER → Свойства.
3. На вкладке Flags включите параметр Force Encryption.
4. На вкладке Certificate выберите установленный сертификат из списка.
5. Перезапустите службу SQL Server, чтобы изменения вступили в силу.
Эти действия обеспечат, что сервер принимает только зашифрованные подключения.
3. Настройка клиентов для шифрования
Чтобы клиентские приложения или инструменты использовали шифрованные подключения, выполните следующие настройки.
Настройка через Configuration Manager
На клиентском устройстве:
1. Откройте SQL Server Configuration Manager.
2. Перейдите в SQL Native Client Configuration → Свойства.
3. Активируйте опцию Force Protocol Encryption.
Указание шифрования в строке подключения
Для приложений настройте строку подключения с параметром Encrypt=True. Пример:
Data Source=sqldb1.resource.ru;Integrated Security=False;User ID=test;Password=[Password];Encrypt=True
Шифрование в SQL Server Management Studio
Для SSMS:
1. В окне Connect to Server нажмите Options.
2. Включите параметр Encrypt Connection.
Эта настройка гарантирует использование TLS при подключении.
4. Диагностика и устранение ошибок
При настройке TLS-шифрования могут возникать ошибки. Рассмотрим основные.
Ошибка недоверенного сертификата
Если клиент не доверяет сертификату, появляется сообщение:
Cannot connect to SRV-SQL. A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 — The certificate chain was issued by an authority that is not trusted.) (Microsoft SQL Server, Error: -2146893019)
Решение:
– Добавьте сертификат или его издателя в хранилище доверенных корневых центров на клиенте.
– Для самоподписанного сертификата импортируйте его в Cert:\LocalMachine\AuthRoot.
Ошибка неверного имени сервера
Если имя в подключении не совпадает с Subject Name или SAN сертификата, возникает ошибка:
The target principal name is incorrect
Решение:
– Убедитесь, что имя сервера в строке подключения или SSMS совпадает с именем в сертификате.
– При необходимости обновите сертификат, добавив недостающие имена в SAN.
5. Проверка шифрования
Чтобы подтвердить, что подключения к SQL Server зашифрованы, используйте PowerShell с модулем SqlServer:
Invoke-Sqlcmd -ServerInstance "srv-sql1" -Query "SELECT DISTINCT encrypt_option FROM sys.dm_exec_connections WHERE session_id = @@SPID"
Для нестандартного порта укажите его, например: srv-sql1,21221. Результат encrypt_option=TRUE указывает на активное шифрование.
6. Шифрование в Azure SQL
Базы данных Azure SQL по умолчанию используют TLS-шифрование для всех подключений. Даже если в SSMS не активирована опция Encrypt Connection, подключение будет зашифровано автоматически, что упрощает обеспечение безопасности.
Настройка TLS-шифрования для MS SQL Server защищает данные от перехвата в недоверенных сетях. Процесс включает установку сертификата, активацию шифрования на сервере и клиенте, а также проверку корректности настроек. Для Azure SQL шифрование включено по умолчанию, что минимизирует усилия. Тщательная настройка и устранение ошибок обеспечивают надежную защиту баз данных.
