2025-12-03

DLACZEGO Next Generation Firewall bez SSL Inspection to często strata pieniędzy?

Wprowadzenie – „bezpieczeństwo”, które widzi tylko to, co niezaszyfrowane

Dawniej większość ruchu internetowego była przesyłana w czystym tekście (HTTP) – firewall klasyczny wystarczał, by blokować niepożądane porty albo IP. Dziś sytuacja jest zupełnie inna, zdecydowana większość stron i usług używa szyfrowania (HTTPS/TLS).

Jak wynika z najnowszych danych: globalnie 95 % ruchu webowego jest zabezpieczone przez HTTPS.
W praktyce oznacza to, że jeśli NGFW nie jest skonfigurowany do inspekcji szyfrowanego ruchu, to nie widzi wcale tego, co naprawdę dzieje się w środku sesji – co de facto wyklucza skuteczne wykrywanie zagrożeń.


Co odróżnia NGFW od klasycznego firewalla

  • Blokowanie ataków w warstwie aplikacyjnej – dzięki silnikom typu IPS (Intrusion Prevention System) lub WAF (Web Application Firewall) potrafi reagować na znane podatności, próby exploitów lub nieprawidłowe zachowania aplikacji.
  • Ochrona przed złośliwym oprogramowaniem – silniki antywirusowe (AV) analizują treść pobieranych plików i blokują malware.
  • Kontrola dostępu do serwisów i aplikacji – filtr Web Filter / Application Control pozwala blokować witryny lub konkretne aplikacje (np. portale społecznościowe, usługi streamingowe etc.).
  • Polityki bezpieczeństwa zależne od tożsamości użytkownika / grupy – NGFW może działać na poziomie użytkownika, nie tylko IP/port.
  • Kontrola ruchu, QoS, DoS, zarządzanie wieloma łączami, VPN – to wszystko rozszerza funkcjonalność NGFW poza samą blokadę zagrożeń.

To czyni z NGFW coś znacznie bardziej zaawansowanego niż tradycyjny firewall.


Dlaczego większość funkcji NGFW nie działa bez SSL/TLS Inspection

1. Większość ruchu jest zaszyfrowana

Zgodnie z wcześniej przedstawiona informacją – 95 % ruchu webowego to dziś HTTPS. Dla przeglądarki i użytkownika to coś normalnego, ale dla firewalla oznacza to że jeśli ruch nie jest odszyfrowany, to firewall widzi tylko meta-dane (adres IP, port, nagłówek TLS, ewentualne SNI), a nie same dane (ładowane strony, treści, pliki, żądania POST itp.).

2. Dlatego NGFW bez inspekcji TLS staje się „ślepym”

Choć NGFW aspiruje do roli gatekeepera całego ruchu sieciowego, bez TLS decryption nie może zobaczyć i ocenić tego, co naprawdę płynie przez łącze. Widać co najwyżej skąd i dokąd – nie widać, co konkretnie. W rezultacie:

  • ataki ukryte w HTTPS (np. exploity, malware, phishing, złośliwe pliki) pozostają niewykryte,
  • filtry aplikacyjne, AV, IPS, WAF nie mają dostępu do treści – czyli większość ich funkcji jest praktycznie bezużyteczna.

3. To nie teoria – statystyki mówią jasno

W ostatnim okresie firma Zscaler wykazała, że ponad 87 % wszystkich zagrożeń było dostarczane przez szyfrowane kanały (HTTPS/TLS). To oznacza, że ogromna większość ataków wykorzystuje szyfrowanie właśnie po to, by ukryć się przed tradycyjną analizą.

W takich warunkach NGFW, który nie odszyfrowuje ruchu – po prostu nie widzi tych zagrożeń.


Jak działa SSL/TLS Inspection (i co to zmienia)

Aby NGFW mógł skutecznie działać, konieczne jest uruchomienie inspekcji szyfrowanego ruchu – czyli TLS/HTTPS Inspection / SSL Decryption / Proxy. W praktyce wygląda to tak:

  1. Komputer klienta łączy się nie z docelowym serwerem, ale z firewallem.
  2. Firewall przedstawia użytkownikowi własny certyfikat (zaufany wewnętrznie).
  3. Firewall odszyfrowuje ruch, analizuje go silnikami AV, IPS, WAF, filtrami aplikacji itd.
  4. Następnie ponownie szyfruje go i wysyła do rzeczywistego serwera.

Dzięki temu:

  • firewall widzi całą treść transmisji – a więc może reagować na ataki, wykrywać malware, blokować niepożądane aplikacje, analizować żądania webowe itd.,
  • funkcje NGFW – które bez tego byłyby “na papierze” – realnie działają.

Oczywiście należy przy tym:

  • rozprowadzić zaufany certyfikat (CA) na wszystkich urządzeniach klienckich,
  • ewentualnie zaplanować wyjątki (np. dla aplikacji bankowych, medycznych),
  • dobrać odpowiedni sprzęt/firewall, bo decryption to ponowne szyfrowanie czyli wysiłek dla CPU.

Dlaczego NGFW bez SSL Inspection to często strata pieniędzy i co trzeba zrobić

Problem / ograniczenieEfekt bez SSL Inspection
Ruch w sieci jest w większości szyfrowany (HTTPS)NGFW widzi tylko metadane – nie treść, nie pliki, nie żądania HTTP.
Atakujący coraz częściej korzystają z TLS do dostarczenia malware / exploitówWiększość zagrożeń przechodzi „pod radar” – nie są wykryte.
Funkcje IPS, AV, WAF, filtrowanie aplikacji i stron wymagają dostępu do treściTe funkcje są nieskuteczne albo działają tylko częściowo.
Wysoka cena NGFW, licencje, wsparcie, konfiguracjaInwestycja nie przekłada się na realne bezpieczeństwo, jeśli TLS Inspection nie zostanie wdrożone.

Wniosek: kupując NGFW i nie planując jednoczesnej implementacji SSL Inspection – z dużym prawdopodobieństwem nie wykorzystujesz jego możliwości.

Jeśli natomiast potrzebujesz realnej ochrony w nowoczesnej sieci – prawdziwy plan wdrożenia to:

  • NGFW + SSL Inspection + odpowiednie polityki bezpieczeństwa + przemyślana dystrybucja certyfikatu CA + wyjątki, gdzie trzeba.

Jak BOIT może pomóc w bezpiecznym wdrożeniu NGFW

Wiele organizacji posiada dziś Next Generation Firewall, który formalnie „działa”, ale w praktyce nie zapewnia realnej ochrony przed współczesnymi zagrożeniami. Najczęstszy problem? Brak lub nieprawidłowa konfiguracja SSL/TLS Inspection.

Co robimy w ramach wdrożeń NGFW?

Najczęściej zaczynamy od analizy rzeczywistego ruchu sieciowego czyli sprawdzamy, ile danych jest szyfrowanych, jakie aplikacje są używane i gdzie faktycznie występują ryzyka. Dopiero na tej podstawie:

  • projektujemy politykę SSL/TLS Inspection dopasowaną do środowiska (nie „wszystko albo nic”),
  • wskazujemy, które systemy powinny być wyłączone z inspekcji (bankowość, medycyna, systemy krytyczne),
  • dobieramy wydajność firewalla tak, aby decryption nie stał się wąskim gardłem,
  • integrujemy NGFW z Active Directory aby polityki były oparte o użytkowników i role,
  • wdrażamy certyfikację CA na stacjach roboczych i urządzeniach mobilnych,
  • konfigurujemy IPS, AV, Web Filter, Application Control i WAF tak, aby faktycznie analizowały treść ruchu HTTPS.

Dla kogo to rozwiązanie?

  • dla firm, które już posiadają NGFW, ale nie są pewne, czy wykorzystują jego możliwości,
  • dla organizacji planujących audyt bezpieczeństwa sieci,
  • dla firm przygotowujących się do certyfikacji ISO 27001, TISAX, NIS2

Oskar Dyjach
Oskar Dyjach