Szyfrowanie łącza w Firebirdzie 3 i VPN to dwie różne granice

VPN się łączy, klient otwiera sesję, a wszyscy zakładają, że połączenie z bazą jest zabezpieczone. Właśnie pomieszano trzy różne rzeczy. Czy listener jest w ogóle osiągalny, czy serwer zaakceptował użytkownika i czy Firebird uzgodnił szyfrowanie łącza, to osobne mechanizmy z osobnymi dowodami. Tunel odpowiada tylko na pierwsze pytanie i tylko dla źródeł, które dopuściłeś.

Dwie granice, które się nie pokrywają

Granica VPN chroni pakiety między klientem a bramą. Szyfrowanie łącza w Firebirdzie chroni protokół bazy między biblioteką klienta a procesem serwera. Oba mogą istnieć, a żadne nie zastępuje drugiego.

Jeśli tunel kończy się przed hostem bazy, ruch za nim chroni tylko to, co uzgodniła sesja bazy. Właśnie w tej luce przegląd zwykle znajduje niespodziankę. Diagram tunelu kończy się na bramie, a połączenie niosące twoje zapytanie biegnie dalej. Każdy, kto później czyta ten diagram, dziedziczy to założenie.

Granica pierwsza: kto może otworzyć listener

Ustal rzeczywisty adres serwera i skonfigurowany port, który wynosi 3050, jeśli go nie zmieniono, a następnie zezwól tylko zatwierdzonym źródłom VPN w zaporze hosta i sieci. Uwzględnij ewentualne tłumaczenie adresów na bramie VPN i daj hostowi bazy trasę powrotną do puli klientów, jeśli brama jest osobna.

Potem udowodnij negatyw. Ścieżka zewnętrzna, która powinna zostać odrzucona, musi pozostać odrzucona, bo otwarcie tunelu samo w sobie nie ogranicza listenera Firebirda.

Granica druga: co Firebird uzgadnia

Firebird 3 wprowadził ramy szyfrowania łącza z polityką serwera, którą można wyłączyć, włączyć lub wymusić. Polityka wyznacza minimum. Rzeczywista sesja nadal zależy od biblioteki klienta ładowanej przez aplikację i wtyczek obsługiwanych przez obie strony.

W informacjach o wydaniu Firebirda 3 Arc4 jest wymieniony jako domyślna wtyczka szyfrowania łącza dla tego wydania. Arc4 to historyczna wartość domyślna, a nie zalecenie nowoczesnego szyfru, i nie jest tym samym co zewnętrzna ochrona VPN.

Uwierzytelnianie to trzecia zmienna w tych samych negocjacjach. Serwer akceptuje zestaw wtyczek uwierzytelniania, biblioteka klienta oferuje pewien podzbiór, a oba muszą się pokrywać.

Pułapka Legacy_Auth

Obsługa Legacy_Auth wymaga poluzowania domyślnej polityki wymaganego szyfrowania serwera. To udokumentowany koszt zgodności i dlatego obniżenie polityki, by uciszyć błąd połączenia, jest zmianą bezpieczeństwa, a nie poprawką.

Jeśli klient nagle zawodzi po aktualizacji serwera, porównaj listy wtyczek, zanim cokolwiek osłabisz. Awaria to zwykle niezgodność negocjacji, a odpowiedzią jest wtyczka obsługiwana po obu stronach.

Sprawdź połączenie, które ma znaczenie

Na kompilacji udostępniającej zmienną kontekstu to zapytanie raportuje stan szyfrowania bieżącego połączenia:

SELECT RDB$GET_CONTEXT('SYSTEM', 'WIRE_ENCRYPTED')
FROM RDB$DATABASE;

Uruchom je przez własne połączenie aplikacji, a nie przez sesję administratora na tym samym serwerze. Zaszyfrowane połączenie administratora nic nie mówi o sesji innej biblioteki klienta, a starsza kompilacja, która nie obsługuje tej zmiennej, nie jest dowodem, że szyfrowanie jest wyłączone.

Zapisz razem wersję biblioteki klienta, kompilację serwera i wynik, bo żadne z nich osobno nie jest czytelne.

Uprawnienia i ścieżka aktualizacji

Ograniczanie źródeł i szyfrowanie transportu nie zastępują uwierzytelniania ani uprawnień najmniejszych przywilejów. Sprawdź uprawnienia zwykłego użytkownika bazy do obiektów, których naprawdę dotyka.

Na koniec traktuj długotrwałe wdrożenie jako kwestię utrzymania. Tunel nie czyni przestarzałej biblioteki klienta bezpieczną na zawsze, a obsługiwana ścieżka aktualizacji jest tańsza niż odkrycie, że potrzebna wtyczka została usunięta.