Наскоро Microsoft пусна два нови драйвера за SQL Server, голяма надстройка:
ODBC 18 драйвер за SQL сървър
OLEDB 19 драйвер за SQL сървър
Това е страхотна новина! Въпреки това има сериозни промени, които изискват вашето внимание. По-конкретно, те промениха начина, по който настройките по подразбиране работят за криптирането. Във всички предишни версии на драйвери по подразбиране не се изисква криптиране. Имахме опциите да наложим криптиране от страна на сървъра или да го поискаме в низа за връзка от страна на клиента. Очевидно за администратора на сървъра обикновено е било по-желателно да се наложи криптиране от сървъра, така че да няма значение, ако някое старо приложение не го е поискало, но ще бъде гарантирано да криптира комуникацията си със сървъра.
Има 2 ключови думи за низове за връзка и настройка на сървъра, която влияе върху това как трябва да се държи драйверът:
В низа за връзка от страна на клиента:
Encrypt:Показва дали комуникацията трябва да бъде криптирана.TrustServerCertificate:Показва дали клиентът трябва просто да се довери на сертификата на сървъра, без да проверява автентичността на сертификата.
В настройките от страна на сървъра:
Force Encryption:Задължава всеки клиент, който се свързва със сървъра, да криптира комуникацията, независимо от низа за връзка на клиента.
Комбинацията от 3-те свойства влияе върху начина, по който ще се осъществи връзката. Има удобна диаграма, която ги изброява, която можете да намерите тук...
Най-често срещаният сценарий обаче е, че принуждаваме криптиране от сървъра и не указваме нищо друго в низа за връзка. Ето извлечената версия на двете предишни версии и поведението на новата версия:
Версия | Шифроване | Доверен сървър Сертификат | Принудително шифроване на сървъра Шифроване | Резултат |
|---|---|---|---|---|
| ODBC 17 и по-стари OLEDB 18 и по-стари | Не | Не | Да | Сертификатът на сървъра не е отметнат. Данните, изпратени между клиент и сървър, са криптирани. |
| ODBC 18 OLEDB 19 | Не | Не | Да | Сертификатът на сървъра е проверен. Данните, изпратени между клиент и сървър, са криптирани. |
Мисля, че това като цяло е добро нещо, особено когато базите данни на Azure SQL стават все по-често срещани, но промяната на проверката на сертификата на SQL Server въвежда промяна, особено за сървъри, които може да нямат настроени сертификати. По подразбиране той ще използва самоподписан сертификат, който не е толкова безопасен, колкото този, на който има доверие. За тези сървъри, където връзките се осъществяват през интернет, допълнителната предпазна мярка си заслужава усилията.
Ето сравнение на ODBC низовете за връзка за Microsoft Access с промените на SQL Server между предишната версия и текущата версия:
ODBC 17 срещу ODBC 18
17:DRIVER=ODBC Driver 17 for SQL Server;SERVER= ;DATABASE= ;
18:DRIVER=ODBC Driver 18 for SQL Server;SERVER= ;DATABASE= ;
OLEDB 18 срещу OLEDB 19 низове за връзка за Microsoft Access със SQL Server
18:Provider= ;Data Source= ;Initial Catalog= ;
19:Provider= ;Data Source= ;Initial Catalog=
Имайте предвид, че в предишни версии трябваше да посочите Encrypt=yes но това вече е имплицитно в текущите версии.
Добре, но имам локален сървър, но той не работи с новите драйвери?
Поради промяната в настройката, сега може да видите тази грешка:
В зависимост от сценария и изискванията, ето възможни решения:
- Инсталирайте и конфигурирайте доверен сертификат на сървъра.
- Променете низа за връзка на приложението, за да включи
TrustServerCertificate=Yes. ИЗПОЛЗВАЙТЕ С ВНИМАНИЕ - Променете низа за връзка на приложението, за да включите
Encrypt=Noи деактивирайтеForce Encryptionна сървъра. НЕ СЕ ПРЕПОРЪЧВА - Не актуализирайте драйвери.
Стъпките за разрешаване на проблема са описани подробно в съответните раздели.
Резолюции
Инсталирайте и конфигурирайте доверен сертификат на сървъра
Много е важно да се отбележи, че само защото имате сървър, който има настроен валиден SSL сертификат и е в активна употреба, всъщност не означава, че SQL Server използва същия сертификат. Освен това се оказва, че SQL Server Configuration Manager е ужасен при обработката на сертификатите. Може да откриете, че няма да изброи никакви сертификати, които да използвате:
Кратката версия е, че SQL Server Configuration Manager е прекомерно ограничаващ какви сертификати ще изброява, което може да бъде доста разочароващо, особено защото това е проблем с потребителския интерфейс, а не истинско изискване от самия SQL Server. За щастие можем да заобиколим това глупаво ограничение на потребителския интерфейс, като редактираме директно регистъра. Това съответства на ключа на системния регистър:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<name of your instance>\MSSQLServer\SuperSocketNetLib
В рамките на този ключ има стойност Certificate който очаква отпечатък на сертификата.
Можете ръчно да поставите отпечатъка на SSL сертификата, който ще се използва, но бих препоръчал да използвате скрипт, за да направите това, тъй като също така трябва да се уверим, че акаунтът на сървъра има разрешение за достъп до сертификата. Използвах тази статия в блога като ръководство за настройка на скрипта PowerShell, за да изберете сертификата и да го заредите в ключа на системния регистър на SQL Server и да рестартирате услугата. В зависимост от това кой предоставя вашия SSL сертификат и работния процес, може да искате да го интегрирате в някои други планирани задачи, така че когато SSL сертификатът бъде подновен, ключът на системния регистър и разрешенията ще бъдат съответно актуализирани.
Ако всичко е настроено правилно, тогава вашият сървър трябва да може да използва новите драйвери без никакви модификации на низа за връзка на приложението. Като допълнителна проверка можете да проверите дневника за грешки на вашия SQL Server и да потърсите ред като този:
<timestamp> spid11s The certificate [Cert Hash(sha1) "<certificate thumbprint>"] was successfully loaded for encryption.
Ако отпечатъкът съвпада с този, който искате да използвате, тогава знаете, че сте го заредили правилно и така веригата на доверие вече е установена.
Променете низа за връзка на приложението, за да включи TrustServerCertificate=Yes
Въпреки това, ако вашият сървър не е обърнат към интернет и е твърде болезнено да настроите SSL сертификат, може да е приемливо да включите TrustServerCertificate . Това изисква промяна в низа за връзка на вашето приложение. Това позволява на приложението да позволява свързване със сървър без проверка на сертификата на сървъра. Ако можете уверено да контролирате приложението си, така че да не излиза извън мрежата ви, това трябва да е наред. Имайте предвид, че ако някой успее да излъже името или IP адреса на сървъра в мрежата, клиентските приложения ще се свързват сляпо с този компютър. Поради тази причина не можем да препоръчаме това, ако има интернет, включен във връзката. Наистина бихме предпочели да не поемаме риска.
Променете низа за връзка на приложението, за да включите Encrypt=No и деактивирайте Force Encryption на сървъра.
Това е за тези, които обичат да се нарисуват в интернет с огромен неонов надпис „ОТКРАЙ МОИТЕ ДАННИ! ОХВАЙТЕ МЕ СЕГА!” на всички лоши актьори там. Това е "опция". Единственото, което мога да кажа за тази опция е, че е изключително лоша. Толкова лошо, че забравих как да направя това. Сам си, приятелю.
Не актуализирайте драйвери.
Малко по-добра алтернатива в сравнение с предишната е просто да не актуализирате и да се придържате към ODBC 17 и OLEDB 18 драйвери. Това обаче в най-добрия случай е междинна мярка. Тази резолюция не изисква промени в приложението, но това само забавя неизбежните промени в най-добрия случай. Можете да използвате времето, за да проучите пътища, които ще ви отведат до най-новата версия и ще защитят правилно вашите данни.
Надявам се това да помогне!
