Szyfrowanie połączeń SSL/TLS

Szyfrowanie połączeń SSL/TLS wymaga skonfigurowania certyfikatu na poziomie instancji SQL Server.

Szyfrowanie SSL/TLS – czym jest i czemu służy

Szyfrowanie połączeń SSL/TLS to mechanizm ochrony komunikacji pomiędzy aplikacją a serwerem, na przykład pomiędzy programem korzystającym z bazy danych a instancją SQL Server. Jego zadaniem jest ograniczenie ryzyka podsłuchania, zmodyfikowania albo podszycia się pod jedną ze stron połączenia. Dane przesyłane przez sieć mogą obejmować zapytania, wyniki zapytań, dane uwierzytelniające, informacje biznesowe oraz komunikaty sterujące. Bez odpowiedniej ochrony część z nich może być możliwa do odczytania przez osobę, która uzyska dostęp do ruchu sieciowego.

Określenie SSL jest nadal powszechnie używane, jednak współczesne wdrożenia powinny opierać się na protokole TLS. SSL oznacza starszą rodzinę mechanizmów, która została zastąpiona przez nowsze wersje TLS ze względu na ograniczenia projektowe i znane problemy bezpieczeństwa. W praktyce istotne jest nie samo zaznaczenie opcji szyfrowania, lecz cała konfiguracja: wybór wersji protokołu, przygotowanie certyfikatu, przypisanie go do właściwej usługi, ustawienie nazwy serwera oraz wymuszenie odpowiednich zasad po stronie klientów.

Po prawidłowym ustanowieniu sesji TLS dane są szyfrowane podczas przesyłania. Oznacza to, że przechwycony strumień nie powinien być użyteczny bez kluczy sesyjnych. Mechanizm zapewnia również kontrolę integralności, dzięki której odbiorca może wykryć zmianę danych w drodze. Certyfikat dodatkowo pomaga potwierdzić tożsamość serwera, o ile klient sprawdza jego wystawcę, nazwę i okres ważności. Samo pojawienie się symbolu kłódki lub komunikatu o aktywnym szyfrowaniu nie stanowi jeszcze dowodu, że konfiguracja jest poprawna.

Szyfrowanie SSL/TLS w SQL Server i znaczenie certyfikatu

W środowisku SQL Server certyfikat jest konfigurowany na poziomie instancji, ponieważ to instancja przyjmuje połączenia i negocjuje parametry zabezpieczenia z klientem. Certyfikat powinien znajdować się w magazynie certyfikatów komputera, mieć klucz prywatny oraz być dostępny dla konta, pod którym działa usługa SQL Server. Należy także zadbać o zgodność nazwy wpisanej przez klienta z nazwą umieszczoną w certyfikacie. Jeżeli aplikacja łączy się przez alias, nazwę skróconą albo adres nieujęty w certyfikacie, może pojawić się błąd weryfikacji tożsamości, nawet gdy sama warstwa szyfrowania działa.

Ważne jest rozróżnienie dwóch scenariuszy. W pierwszym szyfrowanie jest negocjowane wtedy, gdy klient je obsługuje i akceptuje certyfikat serwera. W drugim szyfrowanie jest wymuszane na poziomie instancji, a połączenia niespełniające wymagań są odrzucane. Pierwsze ustawienie może ułatwić etap przejściowy, lecz pozostawia możliwość zestawiania komunikacji bez ochrony, jeśli klient nie zażąda TLS. Drugie zapewnia bardziej spójną politykę, ale wymaga wcześniejszego sprawdzenia wszystkich aplikacji, sterowników i narzędzi administracyjnych korzystających z bazy.

Podczas negocjacji ustalane są między innymi wersja protokołu, zestaw algorytmów oraz klucze sesyjne. Współczesna konfiguracja powinna ograniczać się do aktualnie wspieranych wersji TLS i bezpiecznych zestawów kryptograficznych. Stare protokoły oraz przestarzałe algorytmy mogą być blokowane przez system operacyjny, biblioteki kryptograficzne albo aktualizacje sterowników. Z tego powodu problem połączenia może pojawić się po aktualizacji, mimo że nie zmieniano ustawień samej bazy danych.

Ochrona transportu nie zastępuje kontroli dostępu do danych. TLS zabezpiecza drogę pomiędzy klientem a serwerem, ale nie decyduje, jaki użytkownik może odczytać tabelę, uruchomić procedurę albo zmienić rekord. Niezbędne pozostają silne zasady uwierzytelniania, ograniczenie uprawnień, właściwa segmentacja sieci, aktualizacje oraz rejestrowanie prób połączeń. Szyfrowanie nie chroni też danych już zapisanych na dysku, dlatego należy odróżnić ochronę transmisji od szyfrowania plików baz danych i kopii zapasowych.

Typowe problemy z szyfrowaniem SSL/TLS

Jednym z częstszych problemów jest brak certyfikatu spełniającego wymagania SQL Server. Certyfikat może być nieważny, wygasły, wystawiony dla innej nazwy albo pozbawiony klucza prywatnego. Zdarza się również, że został zapisany w magazynie użytkownika zamiast w magazynie komputera lub że konto usługi nie ma prawa korzystania z klucza prywatnego. W takiej sytuacji usługa może nie uruchomić się poprawnie albo połączenia będą kończyły się błędem podczas negocjacji zabezpieczeń.

Inna grupa błędów wynika z rozbieżności pomiędzy klientem a serwerem. Starszy sterownik może nie obsługiwać wymaganej wersji TLS, a nowszy serwer może odrzucać przestarzałe parametry. Objawem bywa komunikat o nieudanym ustanowieniu bezpiecznego kanału, niezgodności protokołu lub braku wspólnego zestawu algorytmów. Warto ustalić, czy problem dotyczy wszystkich klientów, czy tylko jednego programu. Porównanie wersji sterownika, bibliotek oraz systemu często pozwala zawęzić przyczynę.

Do pomyłek dochodzi także przy rozróżnieniu szyfrowania po stronie klienta i wymuszania szyfrowania na serwerze. Zaznaczenie opcji szyfrowania w pojedynczej aplikacji nie oznacza, że każda inna aplikacja korzystająca z tej samej instancji będzie działała według identycznych zasad. Z kolei wymuszenie szyfrowania może ujawnić nieprzygotowane połączenia, które wcześniej korzystały z komunikacji nieszyfrowanej. Przed zmianą ustawień należy sporządzić listę klientów, nazw połączeń, sterowników i zależności aplikacyjnych.

Przyczyną trudności może być również zapora sieciowa, błędny port, nieprawidłowa rozdzielczość nazwy albo użycie aliasu. Te elementy nie są samym TLS, lecz mogą maskować właściwy problem. Dobra diagnostyka rozdziela etap nawiązania połączenia z portem, etap negocjacji certyfikatu oraz etap uwierzytelniania użytkownika. Pomocne bywają dzienniki SQL Server, dzienniki systemowe, informacje z narzędzia do konfiguracji SQL Server oraz ślady połączeń wykonane po stronie klienta.

Konfiguracja i praktyczne wskazówki dla SSL/TLS

Prace warto rozpocząć od zinwentaryzowania nazw, pod którymi instancja jest osiągana. Należy sprawdzić pełną nazwę hosta, nazwy alternatywne, aliasy i sposób używany przez aplikacje. Certyfikat powinien odpowiadać rzeczywistym nazwom klientów, a jego łańcuch zaufania musi być rozpoznawany przez urządzenia, z których wykonywane są połączenia. W przypadku certyfikatu podpisanego przez wewnętrzny urząd certyfikacji trzeba upewnić się, że odpowiedni certyfikat urzędu znajduje się w zaufanym magazynie po stronie klienta.

Następnie należy zweryfikować klucz prywatny i uprawnienia konta usługi. Sam plik certyfikatu lub widoczny wpis w magazynie nie zawsze wystarcza. Certyfikat przeznaczony do uwierzytelniania serwera powinien mieć właściwe przeznaczenie klucza, poprawny okres ważności oraz odpowiedni algorytm. Przed wdrożeniem zaleca się wykonanie kopii konfiguracji, zapisanie obecnych parametrów i przygotowanie procedury powrotu do poprzedniego ustawienia. Zmiana powinna być testowana na kopii środowiska albo w kontrolowanym oknie serwisowym.

Po przypisaniu certyfikatu do instancji należy zrestartować usługę, jeżeli wymaga tego sposób zastosowanej konfiguracji, a następnie sprawdzić połączenia z kilku rodzajów klientów. Test powinien obejmować aplikację użytkową, narzędzie administracyjne oraz sterownik wykorzystywany przez skrypty lub integracje. Sam fakt, że jeden klient łączy się bez błędu, nie potwierdza zgodności całego środowiska. Warto sprawdzić także zachowanie po wygaśnięciu certyfikatu testowego, po zmianie nazwy hosta oraz po aktualizacji sterownika.

Certyfikaty trzeba monitorować przed upływem ich ważności. Przydatny jest kalendarz odnowień, przypisanie odpowiedzialności i kontrola, czy nowy certyfikat ma te same nazwy oraz przeznaczenia co poprzedni. Należy unikać obchodzenia weryfikacji certyfikatu poprzez wyłączanie sprawdzania nazwy albo akceptowanie dowolnego certyfikatu. Takie ustawienie może chwilowo usunąć komunikat, ale osłabia ochronę przed podszyciem się pod serwer. Jeżeli szyfrowanie jest wymagane, powinno być potwierdzane testem oraz dokumentowane razem z wersją sterownika i ustawieniami połączenia.

Kiedy zgłosić się do serwisu z problemem SSL/TLS

Do serwisu warto zgłosić się wtedy, gdy po zmianie certyfikatu SQL Server przestaje przyjmować połączenia, aplikacja zgłasza błąd bezpiecznego kanału albo część komputerów łączy się poprawnie, a część nie. Wskazaniem jest również sytuacja, w której nie wiadomo, czy certyfikat znajduje się w odpowiednim magazynie, czy konto usługi ma dostęp do klucza prywatnego albo czy klienci korzystają z właściwych sterowników. Pomocna będzie informacja o nazwie instancji, rodzaju klienta, treści komunikatu oraz momencie, w którym problem się pojawił.

W Warszawskim Pogotowiu Komputerowym 24/7 można zlecić uporządkowanie diagnostyki komputera, sprawdzenie podstawowych zależności systemowych oraz przygotowanie bezpiecznego planu dalszych działań. Przed ingerencją należy ustalić, czy problem dotyczy samego komputera, sieci, certyfikatu, usługi SQL Server czy programu klienckiego. Takie rozdzielenie pozwala ograniczyć ryzyko przypadkowego wyłączenia ochrony i ułatwia przekazanie administratorowi konkretnych ustaleń.

Nie powinno się samodzielnie usuwać certyfikatów, zmieniać ustawień kryptograficznych ani wyłączać wymuszania szyfrowania bez zapisania stanu początkowego. W środowisku, w którym działają aplikacje zależne od bazy danych, jedna nieprzemyślana zmiana może przerwać obsługę użytkowników albo spowodować odrzucanie połączeń przez starsze komponenty. Bezpieczniejsze podejście polega na zebraniu informacji, wykonaniu testu na wybranym kliencie, obserwacji dzienników i dopiero potem przeprowadzeniu zmiany dla całej instancji.