Niedawno firma Microsoft wydała dwa nowe sterowniki dla SQL Server, poważną aktualizację:
Sterownik ODBC 18 dla SQL Server
Sterownik OLEDB 19 dla SQL Server
To świetna wiadomość! Jednak istnieją poważne przełomowe zmiany, które wymagają Twojej uwagi. W szczególności zmienili sposób działania domyślnych ustawień szyfrowania. We wszystkich wcześniejszych wersjach sterowników domyślnie nie wymagało szyfrowania. Mieliśmy możliwość wymuszenia szyfrowania po stronie serwera lub żądania go w ciągu połączenia po stronie klienta. Oczywiście dla administratora serwera zwykle bardziej pożądane było wymuszenie szyfrowania z serwera, aby nie miało znaczenia, że jakaś stara aplikacja nie zażąda tego, ale będzie gwarantowane szyfrowanie komunikacji z serwerem.
Istnieją 2 słowa kluczowe parametrów połączenia i ustawienie serwera, które wpływa na zachowanie sterownika:
W ciągu połączenia od strony klienta:
Encrypt:Wskazuje, czy komunikacja powinna być szyfrowana.TrustServerCertificate:wskazuje, czy klient powinien po prostu zaufać certyfikatowi serwera bez sprawdzania autentyczności certyfikatu.
W ustawieniach po stronie serwera:
Force Encryption:Nakazuje każdemu klientowi łączącemu się z serwerem szyfrować komunikację niezależnie od ciągu połączenia klienta.
Kombinacja 3 właściwości wpływa na sposób wykonania połączenia. Jest poręczny wykres ich wyliczania, który można znaleźć tutaj..
Jednak najczęstszym scenariuszem jest to, że wymuszamy szyfrowanie z serwera i nie określamy niczego innego w ciągu połączenia. Oto wyodrębniona wersja obu poprzednich wersji i zachowanie nowej wersji:
Wersja | Zaszyfruj | Certyfikat Trust Server | Serwer wymusza Szyfrowanie | Wynik |
|---|---|---|---|---|
| ODBC 17 i wcześniejsze OLEDB 18 i wcześniejsze | Nie | Nie | Tak | Certyfikat serwera nie jest sprawdzany. Dane przesyłane między klientem a serwerem są szyfrowane. |
| ODBC 18 OLEDB 19 | Nie | Nie | Tak | Certyfikat serwera jest sprawdzany. Dane przesyłane między klientem a serwerem są szyfrowane. |
Myślę, że generalnie jest to dobra rzecz, zwłaszcza w sytuacji, gdy bazy danych Azure SQL stają się coraz bardziej powszechne, ale zmiana sprawdzania certyfikatu SQL Server wprowadza zmianę, szczególnie w przypadku serwerów, które mogą nie mieć skonfigurowanych certyfikatów. Domyślnie użyje certyfikatu z podpisem własnym, który nie jest tak bezpieczny jak ten, który jest zaufany. W przypadku serwerów, na których połączenia są nawiązywane przez Internet, dodatkowe środki ostrożności są warte wysiłku.
Oto porównanie parametrów połączenia ODBC dla programu Microsoft Access ze zmianami SQL Server między poprzednią wersją a wersją obecną:
ODBC 17 kontra ODBC 18
17:DRIVER=ODBC Driver 17 for SQL Server;SERVER= ;DATABASE= ;
18:DRIVER=ODBC Driver 18 for SQL Server;SERVER= ;DATABASE= ;
Parametry połączenia OLEDB 18 i OLEDB 19 dla Microsoft Access z SQL Server
18:Provider= ;Data Source= ;Initial Catalog= ;
19:Provider= ;Data Source= ;Initial Catalog=
Zauważ, że w poprzednich wersjach trzeba było określić Encrypt=yes ale jest to teraz dorozumiane w obecnych wersjach.
OK, ale mam lokalny serwer, ale nie działa on z nowymi sterownikami?
Ze względu na zmianę ustawienia możesz teraz zobaczyć ten błąd:
W zależności od scenariusza i wymagań, oto możliwe rozwiązania:
- Zainstaluj i skonfiguruj zaufany certyfikat na serwerze.
- Zmodyfikuj ciąg połączenia aplikacji, aby zawierał
TrustServerCertificate=Yes. UŻYWAJ Z OSTROŻNOŚCIĄ - Zmodyfikuj ciąg połączenia aplikacji, aby zawierał
Encrypt=Noi wyłączForce Encryptionna serwerze. NIE ZALECANE - Nie aktualizuj sterowników.
Kroki mające na celu rozwiązanie problemu są szczegółowo opisane w odpowiednich sekcjach.
Rezolucje
Zainstaluj i skonfiguruj zaufany certyfikat na serwerze
Bardzo ważne jest, aby pamiętać, że tylko dlatego, że masz serwer, który ma skonfigurowany ważny certyfikat SSL i jest aktywnie używany, nie oznacza to, że SQL Server używa tego samego certyfikatu. Ponadto okazuje się, że SQL Server Configuration Manager jest okropny w obsłudze certyfikatów. Może się okazać, że nie będzie zawierał żadnych certyfikatów, których możesz użyć:
Krótka wersja jest taka, że SQL Server Configuration Manager jest nadmiernie restrykcyjny w odniesieniu do tego, jakie certyfikaty będzie wyświetlać, co może być dość frustrujące, zwłaszcza że jest to problem z interfejsem użytkownika, a nie prawdziwe wymaganie samego SQL Server. Na szczęście możemy obejść to głupie ograniczenie interfejsu użytkownika, bezpośrednio edytując rejestr. Odpowiada to kluczowi rejestru:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<name of your instance>\MSSQLServer\SuperSocketNetLib
W tym kluczu znajduje się wartość Certificate który oczekuje odcisku palca certyfikatu.
Możesz ręcznie wkleić odcisk palca certyfikatu SSL, który ma być używany, ale polecam użyć do tego skryptu, ponieważ musimy również upewnić się, że konto serwera ma uprawnienia dostępu do certyfikatu. Użyłem tego artykułu na blogu jako przewodnika po skonfigurowaniu skryptu PowerShell, aby wybrać certyfikat i załadować go do klucza rejestru SQL Server i ponownie uruchomić usługę. W zależności od tego, kto dostarcza Twój certyfikat SSL i przepływ pracy, możesz zintegrować to z innymi zaplanowanymi zadaniami, aby po odnowieniu certyfikatu SSL klucz rejestru i uprawnienia zostały odpowiednio zaktualizowane.
Jeśli wszystko jest poprawnie skonfigurowane, serwer powinien być w stanie korzystać z nowych sterowników bez żadnych modyfikacji parametrów połączenia aplikacji. Jako dodatkową weryfikację możesz sprawdzić dziennik błędów serwera SQL Server i poszukać takiej linii:
<timestamp> spid11s The certificate [Cert Hash(sha1) "<certificate thumbprint>"] was successfully loaded for encryption.
Jeśli odcisk palca pasuje do tego, którego chcesz użyć, oznacza to, że wiesz, że został załadowany poprawnie, a zatem łańcuch zaufania został ustanowiony.
Zmodyfikuj ciąg połączenia aplikacji, aby zawierał TrustServerCertificate=Yes
Jeśli jednak Twój serwer nie jest połączony z Internetem i skonfigurowanie certyfikatu SSL jest zbyt bolesne, włączenie TrustServerCertificate może być dopuszczalne . Wymaga to zmiany parametrów połączenia aplikacji. Pozwala to aplikacji na łączenie się z serwerem bez weryfikacji certyfikatu serwera. Jeśli jesteś w stanie pewnie kontrolować swoją aplikację, aby nie wychodziła poza twoją sieć, powinno to być w porządku. Pamiętaj, że jeśli ktoś jest w stanie sfałszować nazwę serwera lub adres IP w sieci, aplikacje klienckie będą ślepo łączyć się z tym komputerem. Z tego powodu nie możemy tego polecić, jeśli połączenie jest połączone z Internetem. Naprawdę wolelibyśmy nie ryzykować.
Zmodyfikuj ciąg połączenia aplikacji, aby zawierał Encrypt=No i wyłącz Force Encryption na serwerze.
To jest dla tych, którzy lubią przemykać w Internecie gigantycznym neonem „Ukradnij moje dane! POWINIEN MNIE TERAZ!” do wszystkich złych aktorów. To jest „opcja”. Jedyne, co mogę powiedzieć o tej opcji, to to, że jest wyjątkowo zła. Tak źle, że zapomniałem, jak to zrobić. Jesteś sam, kolego.
Nie aktualizuj sterowników.
Nieco lepszą alternatywą w porównaniu do poprzedniej jest po prostu nieaktualizowanie i trzymanie się sterowników ODBC 17 i OLEDB 18. Jest to jednak w najlepszym razie rozwiązanie tymczasowe. To rozwiązanie nie wymaga zmian aplikacji, ale w najlepszym razie tylko opóźnia nieuniknione zmiany. Możesz wykorzystać czas na zbadanie ścieżek, które doprowadzą Cię do najnowszej wersji i odpowiednio zabezpieczą Twoje dane.
Mam nadzieję, że to pomoże!
