Konfiguracja szyfrowania połączeń

Konfiguracja szyfrowania połączeń to wymuszenie stosowania protokołu TLS przy komunikacji klientów z bazą danych.

Na czym polega wymuszenie szyfrowania połączenia

Konfiguracja szyfrowania połączeń polega na takim ustawieniu klienta i serwera bazy danych, aby komunikacja między nimi odbywała się z użyciem protokołu TLS (Transport Layer Security). W praktyce oznacza to ochronę danych przesyłanych przez sieć przed odczytem przez osoby, które mogłyby przechwycić ruch. Szyfrowanie obejmuje między innymi zapytania SQL, odpowiedzi serwera, dane uwierzytelniające oraz komunikaty sterujące wymieniane podczas pracy sesji. Sam fakt, że aplikacja łączy się z bazą przez sieć lokalną, nie gwarantuje poufności transmisji.

Wymuszenie TLS różni się od opcjonalnego szyfrowania. Przy trybie opcjonalnym klient może nawiązać połączenie nieszyfrowane, jeżeli serwer je akceptuje albo jeżeli konfiguracja sterownika nie wymaga ochrony. Przy trybie wymaganym negocjacja szyfrowanego kanału staje się warunkiem rozpoczęcia sesji. Jeżeli klient nie obsługuje TLS, nie ufa certyfikatowi serwera albo nie może uzgodnić wspólnej wersji protokołu i zestawu szyfrów, połączenie powinno zostać odrzucone zamiast przejść na komunikację jawnym tekstem.

Elementy negocjacji TLS między klientem a bazą

Podczas zestawiania połączenia TLS klient i serwer uzgadniają parametry bezpiecznego kanału. Istotna jest wersja protokołu, przy czym współczesne konfiguracje powinny preferować TLS 1.2 lub TLS 1.3, o ile obsługują je używany silnik bazy danych, sterownik klienta oraz system operacyjny. TLS 1.0 i TLS 1.1 zostały wycofane z bieżących zastosowań przez główne standardy i biblioteki kryptograficzne, dlatego ich dopuszczanie może powodować problemy bezpieczeństwa oraz ostrzeżenia zgodności. Ostateczny zakres obsługiwanych wersji zależy od konkretnej implementacji.

Serwer przedstawia certyfikat cyfrowy, który zawiera między innymi nazwę podmiotu lub alternatywne nazwy DNS oraz klucz publiczny. Klient może zweryfikować, czy certyfikat został podpisany przez zaufany urząd certyfikacji, czy nie wygasł, czy nie został unieważniony oraz czy nazwa użyta w połączeniu odpowiada nazwie zapisanej w certyfikacie. Weryfikacja nazwy ma znaczenie, ponieważ samo szyfrowanie kanału nie potwierdza jeszcze, że klient połączył się z właściwym serwerem. Pominięcie sprawdzania certyfikatu może chronić przed przypadkowym podsłuchem, ale osłabia ochronę przed podstawieniem fałszywego serwera.

Ustawienia klienta, sterownika i certyfikatu

Wymuszenie szyfrowania musi być zgodne z konfiguracją wszystkich elementów uczestniczących w połączeniu. Dotyczy to aplikacji, biblioteki dostępu do danych, sterownika, magazynu zaufanych certyfikatów oraz samego serwera bazy. W zależności od używanego rozwiązania opcja może występować w parametrach połączenia, konfiguracji sterownika, menedżerze źródeł danych albo ustawieniach aplikacji. Nazwy parametrów nie są uniwersalne, dlatego nie należy przenosić składni z jednego silnika bazy danych do innego.

Certyfikat serwera powinien być wystawiony dla nazwy, której klient rzeczywiście używa. Jeżeli aplikacja łączy się przez nazwę DNS, ta nazwa powinna znajdować się w polu Subject Alternative Name certyfikatu. Połączenie przez adres IP może wymagać osobnego wpisu typu IP Address, ponieważ certyfikat zawierający wyłącznie nazwę hosta nie musi przejść walidacji dla adresu numerycznego. Należy także kontrolować datę ważności certyfikatu, kompletny łańcuch certyfikatów pośrednich oraz dostępność właściwego certyfikatu głównego w magazynie zaufania klienta. Błąd walidacji nie zawsze oznacza awarię szyfrowania; często wskazuje na brak zaufania, niezgodną nazwę albo wygaśnięcie certyfikatu.

Konfiguracja powinna rozdzielać szyfrowanie od uwierzytelniania użytkownika bazy. TLS zabezpiecza kanał transportowy i pozwala zweryfikować serwer, ale nie zastępuje kontroli loginu, hasła, certyfikatu klienta ani uprawnień nadanych w bazie. Po zmianie ustawień trzeba sprawdzić, czy aplikacja faktycznie korzysta z szyfrowanej sesji, a nie tylko poprawnie przechodzi etap logowania. Weryfikacja powinna obejmować również połączenia tworzone przez zadania cykliczne, narzędzia administracyjne, biblioteki ORM i procesy działające w tle.

Rozpoznawanie problemów po zmianie konfiguracji

Najczęstszym skutkiem włączenia wymaganego TLS jest odmowa połączenia przez starszy sterownik albo bibliotekę kryptograficzną. W logach mogą pojawić się informacje o braku wspólnej wersji protokołu, nieobsługiwanym zestawie szyfrów, błędzie uwierzytelniania certyfikatu lub niezgodności nazwy hosta. Osobną klasę problemów stanowi brak zaufanego certyfikatu głównego na komputerze klienta. W takim przypadku serwer może poprawnie przedstawiać certyfikat, lecz klient nie potrafi zbudować zaufanego łańcucha.

Diagnostyka powinna zaczynać się od ustalenia dokładnej ścieżki połączenia: nazwy serwera, portu, używanego sterownika, wersji biblioteki oraz parametrów konfiguracji. Następnie należy sprawdzić datę i nazwę certyfikatu, dostępność certyfikatów pośrednich, obsługiwane wersje TLS oraz logi po obu stronach sesji. Sam test dostępności portu nie potwierdza poprawnej negocjacji TLS, ponieważ pokazuje jedynie możliwość nawiązania połączenia sieciowego. Przydatny jest również test z identycznymi parametrami, których używa aplikacja, ponieważ ręczne narzędzie może korzystać z innego magazynu certyfikatów lub innej biblioteki kryptograficznej.

Po wdrożeniu zmian warto potwierdzić, że nowe połączenia nie działają bez szyfrowania, a istniejące sesje zostały odtworzone zgodnie z nową polityką. Należy obserwować błędy aplikacji, czas zestawiania sesji i zachowanie mechanizmów puli połączeń. Jeżeli część klientów działa, a część odrzuca połączenie, przyczyną może być różnica w wersjach sterowników, systemach zaufania certyfikatów albo nazwach używanych do adresowania serwera. Poprawna konfiguracja jest więc wynikiem zgodności całego łańcucha, a nie pojedynczego przełącznika w aplikacji.