Шифрование трафика между SQL Server и клиентом. Часть 3.

 

В предыдущей серии мы остановились на том, что самоудостоверяющий сертификат, который SQL Server сам себе выдает при старте для шифрования чувствительной информации , предоставляемой пользователями в момент открытия соединения (логин, пароль), при отстутствии у него иных сертификатов, использовать для шифрования всего соединения, в принципе, можно (TrustServerCertificate=True), но чревато атакой «человек посередине». Необходимо задействовать инфраструктуру открытых ключей (PKI), которая позволит аутентифицировать пользователя с открытым ключом на основе удостоверяющего центра (СА). Если взаимодействие клиента и сервера происходит внутри организации, где развернут собственный удостоверяющий центр, например, на основе Windows Server 2008 c ролью Active Directory Certificate Services, можно просто запустить certmgr.msc, встать на папку Personal\Certificates и выбрать из контекстного меню пункт All Tasks -> Request New Certificate. Если SQL Server засвечен в Интернет (хотя на практике такое встречается нечасто), и клиенты могут приходить откуда угодно, то рамок организации недостаточно. Следует приобретать внешний сертификат у коммерческого удостоверяющего или аккредитованного центра.

Для целей демонстрации я создам внешний по отношению к SQL Server самозаверяющий сертификат при помощи утилиты makecert.exe из состава .NET Framework SDK, которая ставится, в частности, вместе с Visual Studio. В Windows 7 она находится в папке C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin (C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\x64). Я не буду выпускать несколько сертификатов и увязывать их в иерархию, как это делал Ян в своем блоге, а для простоты обойдусь одним. Необходимо иметь в виду, что makecert как «Инструмент для создания сертификатов генерирует сертификаты X.509, предназначенные исключительно для тестирования», как сказано в документации. Помимо нее, онлайновую справку по использованию утилиты можно получить по ключу -?, а расширенную справку - по ключу -!:

Рис.1

Обогащенные этим знанием, мы можем легко и непринужденно сгенерить тестовый сертификат для SQL Server:

"C:\Program Files (x86)\Microsoft SDKs\Windows\v6.0A\bin\makecert.exe" -n CN="< имя компьютера>.europe.corp.microsoft.com" -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localmachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 -e 12/31/2011 -a sha1 -r "c:\temp\sql2008r2.cer"

Рис.2

На самом деле я позаимствовал эту команду из SQL Serverной документации - см. «Настройка сертификата для использования протоколом SSL» и «Шифрование соединений с SQL Server». Ключ -n задает subject name сертификата в стандарте X.500. Оно должно выглядеть как CN=”FQDN компьютера, на который ставится сертификат” с точностью до верхнего/нижнего регистра символов, иначе SQL Server автоматически его не подхватит. Полностью квалифицированное доменное имя компьютера можно посмотреть, например, в Control Panel -> System, нажать справа Change Settings и скопировать, как есть, Full Computer Name:

Рис.3

Страшная вещь после ключа -eku скопирована 1:1 из BOL, где просто и незатейливо сказано: хочешь, чтобы SQL Server этот сертификат увидел - делай по сему. Список разделенных запятыми объектных идентификаторов (OID) расширенного использования ключей (EKU) указывает, что данный сертификат может использоваться для проверки подлинности сервера. Ключ -ss - это subject's certificate store, где данный сертификат будет храниться, например, My (персональное хранилище) или Root (корневое хранилище доверенных сертификатов). Ключ -sr задает ветку реестра для хранилища сертификатов, например, localmachine (для всех пользователей) или currentuser (сертификат будет доступен только текущему пользователю). Ключ -sky указывает тип ключа сертификата, может быть signature, exchange или целое число. В BOL написано, что для алгоритма передачи открытых ключей RSA требуется тип exchange. В ключе -sp задается имя криптопровайдера, а в -sy - его тип. В BOL сказано, что для провайдера Microsoft RSA SChannel Cryptographic Provider тип должен быть 12. В ключе -е задается дата окончания действия сертификата в формате mm/dd/yyyy. Поскольку ключ -b опущен, предполагается, что дата начала действия сертификата - это момент его генерации. Ключ -а задает хэш-алгоритм цифровой подписи сертификата. Раньше по умолчанию использовался md5, сейчас - sha1. Ключ -r указывает на то, что это самозаверяющий сертификат. Последним параметром является выходной файл сертификата.

Чтобы убедиться, что сертфикат создан успешно, запускаем mmc.exe, открываем меню File -> Add/Remove Snap-in, из списка оснасток выбираем Certificates и жмем кнопку Add:

Рис.4

На следующем экране отмечаем Computer account, потому что на Рис.2 было задано -sr localmachine. Был бы currentuser, выбрали бы My user account.

Рис.5

Далее указываем, что это будет данный, а не удаленный компьютер, жмем Finish и ОК. Раскрываем папку Personal (потому что на Рис.2 было -ss my), в ней - Certificates, ждем, пока она прочухается и отобразит полный список, где и наблюдаем свежесозданный сертификат:

Рис.6

Аналогично, посмотреть список установленных сертификатов можно при помощи утилиты certutil.exe, находящейся в папке Windows\System32:

certutil.exe -store My

Рис.7

Здесь ключ -store - то же, что ключ -ss в команде makecert. Сообщение Private key is NOT exportable появилось, потому что в команде makecert мы не использовали ключ -pe. Key Container = JoeSoft, потому что в makecert не было ключа -sk или ключа -sv. Когда в явном виде не задан контейнер, куда следует поместить закрытый ключ сертификата, или pvk-файл для него, по умолчанию создается key container по имени JoeSoft.

Удалить сертификат можно из интерфейса Рис.6, а также при помощи только что использованой утилиты certutil (Рис.7). Синтаксис традиционно доступен по справке certutil.exe -delstore -?. Он несложный: CertUtil [Options] -delstore CertificateStoreName CertId, где в качестве CertificateStoreName выступает то же, что и в ключе -store при просмотре сертификатов (certutil.exe -store -?): "My", "CA" (по умолчанию), "Root", "ldap:///CN=Certification Authorities,CN=Public Key Services,CN=Services,CN=Configuration,DC=...?cACertificate?one?objectClass=certificationAuthority" и т.д. В качестве CertId может выступать серийный или порядковый номер сертификата, хэш его открытого ключа, которые мы видели в выдаче Рис.10, и др. Например, удалить созданный сертификат можно одной из команд

certutil .exe -delstore My 13bc5e8ea77e2bb14549a39d20434c45

certutil .exe -delstore My 2

Сейчас мы его удалять не будем, потому что не для того мы его создавали. Перестартуем сервис SQL Server, заходим в текущий Error Log (SSMS-> Object Explorer -> Management -> SQL Server Logs или C:\Program Files\Microsoft SQL Server\MSSQL10_50.<Имя инстанса>\MSSQL\Log\ERRORLOG) и видим:

Рис.8

Что мы здесь видим? Что я забыл вернуть назад affinity mask после поста про Resource Governor. Но это к слову. Главное, мы видим, что SQL Server подхватил созданный нами на Рис.2 сертификат (можно сравнить хэш A5D81C78E91888993033FD3EBBA76E65733A6696 на Рис.8 с хэшем a5 d8 1c 78 e9 18 88 99 30 33 fd 3e bb a7 6e 65 73 3a 66 96 на Рис.7, дабы убедиться, что это тот самый сертификат) и теперь будет использовать его, а не самопальный сертификат, как это было на Рис.1 в прошлом посте..

 

Алексей Шуленин, Microsoft

Окончание следует.