Scena otwarcia: kiedy klasyczny firewall przestaje wystarczać
Administrator bezpieczeństwa kończy zmianę z przekonaniem, że „mamy to ogarnięte”. W centrali stoi potężny firewall, ruch jest filtrowany, logi spływają. Tymczasem kilka godzin później pracownik łączący się z domowego laptopa przez publiczne Wi-Fi wprowadza swoje dane do fałszywej strony SaaS, a napastnik zyskuje dostęp do firmowych danych – bez dotknięcia tego „mocnego” firewalla w serwerowni.
Tak wygląda zderzenie poczucia bezpieczeństwa z rzeczywistością. Fizyczne urządzenie na brzegu sieci lokalnej dalej jest potrzebne, ale chroni głównie to, co jest w jego zasięgu. Coraz więcej kluczowych aplikacji, użytkowników i danych działa jednak poza klasycznym perymetrem: w chmurze publicznej, w aplikacjach SaaS, na prywatnych urządzeniach i w modelu pracy zdalnej.
Jeśli w organizacji wciąż dominuje myślenie „mamy firewall, więc jesteśmy bezpieczni”, pojawiają się charakterystyczne sygnały ostrzegawcze:
- rosnąca liczba incydentów związanych z kontami w chmurze (np. przejęte skrzynki pocztowe w Microsoft 365, wycieki z dysków współdzielonych),
- niekontrolowane korzystanie z narzędzi typu shadow IT (Dropbox, Google Drive, komunikatory),
- narastająca liczba wyjątków w politykach VPN i firewalli („tymczasowo odblokujmy to połączenie, bo biznes stoi”),
- brak spójnego wglądu w to, co robią użytkownicy spoza biura i poza VPN.
Źródło problemu nie leży w tym, że firewall jest „zły” albo „za słaby”. Chodzi o samą architekturę: model, w którym wszystko istotne znajduje się za jednym murem obronnym, rozpadł się wraz z wejściem chmury, SaaS i pracy hybrydowej. Nowoczesny model bezpieczeństwa sieciowego musi bazować na innych założeniach niż tylko ochrona jednej, fizycznej sieci lokalnej.
Jak doszliśmy do ściany: ewolucja klasycznego bezpieczeństwa sieciowego
Od pojedynczego firewalla do rozbudowanych stref bezpieczeństwa
Klasyczne bezpieczeństwo sieciowe opierało się na koncepcji „twarda skorupa, miękkie wnętrze”. Zakładano, że istnieje wyraźna granica między „bezpieczną” siecią wewnętrzną a „niezaufanym” Internetem. Na tej granicy stawiano firewall – jedno centralne urządzenie kontrolujące ruch przychodzący i wychodzący. Wszystko, co znajdowało się wewnątrz, traktowano jako mniej lub bardziej zaufane.
Z czasem firmy zaczęły rozszerzać ten model. Pojawiły się strefy DMZ na serwery publiczne, segmentacja VLAN, systemy IDS/IPS monitorujące ruch, dodatkowe firewalle między segmentami. Każdy z tych elementów coś poprawiał: utrudniał poruszanie się atakującego wewnątrz sieci, pozwalał oddzielić krytyczne systemy, zwiększał widoczność.
Jednak fundament pozostał ten sam: sieć wewnętrzna jest z natury bardziej zaufana niż Internet, a celem jest ochrona granicy. To prowadziło do wielu kompromisów. Jeśli ktoś dostał się do sieci wewnętrznej (np. przez VPN, fizyczny dostęp, przejęte konto), w wielu organizacjach miał zaskakująco szerokie możliwości poruszania się. Mikrosegmentacja na poziomie sieci była kosztowna, trudna w utrzymaniu i często ograniczała się do kilku kluczowych stref.
Druga kwestia to skala. Stos reguł firewalla w typowej średniej lub dużej organizacji wyrastał do tysięcy wpisów. Próba zrozumienia, które zasady są jeszcze potrzebne, a które powstały „na wszelki wypadek”, była często nierealna. Każda nowa aplikacja, każdy nowy partner, każde nowe łącze wymagały kolejnych wyjątków. Architektura pozostawała ta sama, ale była coraz bardziej łataną mozaiką.
Nowe realia: chmura, SaaS, mobilność, praca zdalna
Wraz z upowszechnieniem się chmury publicznej i SaaS, model „wszystko za jednym firewallem” zaczął się kruszyć. Kluczowe systemy – CRM, poczta, narzędzia współpracy – przeniosły się do usług typu Microsoft 365, Google Workspace, Salesforce czy Jira Cloud. Dane biznesowe przestały leżeć wyłącznie w serwerowni, a użytkownicy zaczęli pracować z dowolnego miejsca: z domu, u klienta, w podróży.
Coraz częściej dochodziło do sytuacji, w której:
- pracownik łączy się z aplikacją SaaS bezpośrednio z domowego łącza, pomijając firmowe VPN i firewalle,
- zespół wdraża nową usługę chmurową (np. do analityki danych) wcześniej niż dział IT jest w stanie ją formalnie zatwierdzić,
- działy biznesowe korzystają z kilkunastu różnych usług SaaS, o których bezpieczeństwie dział IT ma ograniczone informacje.
Do tego dochodzi wielochmurowość. Organizacje hostują aplikacje w różnych regionach i u różnych dostawców (AWS, Azure, GCP, lokalne chmury). Tradycyjny, centralny firewall w siedzibie przestaje być miejscem, przez które „przechodzi wszystko”. Punktów styku z Internetem i partnerami biznesowymi przybywa: oddziały, direct connecty do chmur, łącza MPLS, VPN między organizacjami, access pointy dla pracowników zewnętrznych.
Efekt uboczny jest taki, że spójne zarządzanie bezpieczeństwem staje się coraz trudniejsze. Tam, gdzie kiedyś istniała jedna brama i jeden główny firewall, pojawiają się dziesiątki lokalnych reguł, wyjątków i tuneli. Część ruchu jest widoczna i kontrolowana, część nie – i łatwo przegapić który kawałek układanki właśnie pękł.
Łatanie architektury kolejnymi pudełkami
Naturalną reakcją wielu organizacji było dokładanie kolejnych warstw bezpieczeństwa: nowoczesne NGFW, WAF-y do aplikacji webowych, oddzielne urządzenia VPN, dedykowane bramy pocztowe, systemy DLP, osobne rozwiązania do ochrony chmury, proxy webowe w centralnym punkcie. Każde z tych narzędzi rozwiązuje jakiś fragment problemu, ale rzadko składa się w prosty, spójny obraz.
Z każdym nowym komponentem rośnie liczba konsol, polityk, integracji i punktów awarii. Administratorzy dzielą uwagę między kilka lub kilkanaście narzędzi, z których każde widzi tylko część ruchu. Korelacja zdarzeń staje się skomplikowana i opóźniona. Z punktu widzenia bezpieczeństwa zaczyna brakować najcenniejszej rzeczy: pełnego kontekstu – kto, skąd, do czego sięga i jak to się ma do reszty działań w organizacji.
Mini-wniosek: tradycyjny perymetr się rozmył, a wraz z nim sens opierania całego modelu bezpieczeństwa na jednym, centralnym firewallu. Nawet jeśli stoi on wciąż w serwerowni i działa poprawnie, chroni już tylko fragment rzeczywistej powierzchni ataku.
Dlaczego klasyczne firewalle przegrywają z rzeczywistością
Perymetr, który już nie istnieje
Wyobraźmy sobie typową scenę: przedstawiciel handlowy siada w kawiarni, łączy się z Wi-Fi i loguje do firmowego CRM w chmurze. Adres URL wygląda znajomo, ruch jest szyfrowany, wszystko działa. Z punktu widzenia centralnego firewalla organizacji nie wydarzyło się absolutnie nic: żaden pakiet nie przeszedł przez jego interfejsy, żaden log się nie pojawił.
W klasycznym modelu bezpieczeństwa taka sytuacja nie była w ogóle projektowana. Zakładano, że użytkownicy pracują głównie z sieci firmowej, a jeśli zdalnie – to przez VPN, który kończy się na firmowym firewallu. Dziś VPN jest często traktowany jako przeszkoda: spowalnia połączenie, komplikuje życie użytkownikowi, nie jest wymagany przez większość aplikacji SaaS, które działają z dowolnego miejsca.
Model „zaufane sieci vs. niezaufany Internet” przestał odzwierciedlać rzeczywistość. Te same dane są dostępne z domu, z kawiarni, z telefonu, z laptopa służbowego i prywatnego. Tylko część tego ruchu można „wciągnąć” do firmowego perymetru. Reszta to bezpośrednie połączenia użytkownik–chmura, w których centralny firewall jest całkowicie pominięty.
Ograniczenia techniczne i organizacyjne klasycznych firewalli
Klasyczne firewalle były projektowane z myślą o ruchu opartym na adresach IP, portach i protokołach. Tymczasem dzisiejszy ruch jest w ogromnej większości szyfrowany (HTTPS, TLS), aplikacje korzystają z dynamicznych adresów i portów, a granica między „aplikacją webową” a „stroną internetową” jest płynna. Reguły typu „zezwól z tej sieci na port 443 do tamtego IP” dają coraz mniej realnej kontroli.
Administrator, który chce kontrolować dostęp do konkretnej aplikacji SaaS, musi poruszać się w gąszczu adresów IP dostawcy chmury (często zmiennych) albo polegać na identyfikacji ruchu aplikacyjnego, która wymaga inspekcji SSL i zaawansowanych mechanizmów w firewallu. Nawet jeśli technicznie jest to możliwe, utrzymanie takich polityk przy kilkudziesięciu aplikacjach SaaS staje się niepraktyczne.
Dodatkowym problemem jest shadow IT. Pracownicy, chcąc przyspieszyć swoją pracę, zaczynają używać narzędzi, których dział IT nie zna i nie kontroluje: prywatne dyski w chmurze, aplikacje do zarządzania zadaniami, komunikatory. Dla firewalla jest to po prostu ruch HTTPS do legalnego serwisu. Bez dodatkowego kontekstu (kto, z jakiego urządzenia, do jakiej aplikacji, jakie dane przesyła) nie da się sensownie egzekwować polityk bezpieczeństwa.
Na to nakłada się rozjazd między formalną polityką bezpieczeństwa a tym, co faktycznie jest egzekwowane. Dokumenty mówią o klasyfikacji danych, zasadach korzystania z chmury, wymogach silnego uwierzytelniania, ale firewall i VPN znają tylko adresy IP i porty. Ten rozdźwięk jest jednym z głównych powodów, dla których incydenty bezpieczeństwa w środowiskach hybrydowych bywają tak bolesne.
Rosnące koszty, skomplikowanie i brak widoczności
Każda próba „rozciągnięcia” klasycznego firewalla na nowe realia wiąże się z kosztami i złożonością. Rozbudowane urządzenia NGFW z inspekcją SSL, modułami aplikacyjnymi, IPS/IDS, DLP i sandboxingiem są drogie i wymagają wydajnej infrastruktury. Do tego dochodzi aspekt operacyjny: aktualizacje, utrzymanie, tworzenie i przeglądanie polityk, monitorowanie wydajności.
W architekturze multi-cloud problem się pogłębia. Organizacja często ma:
- firewalle on-premises w siedzibach i oddziałach,
- firewalle w chmurze (wirtualne urządzenia) chroniące VPC/VNet,
- osobne rozwiązania bezpieczeństwa oferowane przez dostawców chmury i SaaS,
- różne systemy VPN i zdalnego dostępu.
Kazdy element ma własne reguły, logi i sposób zarządzania. Złapanie całościowego obrazu staje się wyzwaniem, a bez tego reagowanie na incydenty jest spóźnione i niepełne. Informacje są rozproszone po wielu narzędziach, integracje SIEM są trudne, a korelacja wymaga czasu i specjalistycznej wiedzy.
Mini-wniosek: firewall nie jest „złym” narzędziem; jest po prostu narzędziem zaprojektowanym do innego świata. W nowoczesnym modelu bezpieczeństwa sieciowego rola klasycznego firewalla staje się rolą jednego z wielu elementów – i to coraz rzadziej najważniejszego.
Nowy paradygmat: zero trust, bezpieczeństwo oparte na tożsamości i kontekście
Zasada „never trust, always verify” w praktyce
Zero Trust nie jest pojedynczym produktem, lecz sposobem myślenia o bezpieczeństwie. Kluczowa zasada brzmi: nigdy nie ufaj domyślnie, zawsze weryfikuj. To oznacza odejście od założenia, że sieć wewnętrzna jest z natury bardziej zaufana niż Internet. Każde żądanie dostępu – niezależnie od tego, czy pochodzi z biura, z domu czy z kawiarni – podlega takiej samej ocenie.
W centrum tego modelu stoi tożsamość: użytkownika, urządzenia oraz – w coraz większym stopniu – aplikacji i usług. Dostęp nie jest przyznawany na podstawie adresu IP czy lokalizacji sieciowej, lecz w oparciu o to, kim jest użytkownik, jakim urządzeniem się posługuje, gdzie się znajduje i jaki jest kontekst jego działania (czas, ryzyko, rola, wrażliwość zasobu).
Przykładowa decyzja w modelu Zero Trust może brzmieć: „zezwól użytkownikowi z działu finansowego, uwierzytelnionemu MFA, z zarządzanego i szyfrowanego laptopa, z kraju X, na dostęp do aplikacji księgowej, ale zablokuj dostęp z niezarządzanego urządzenia mobilnego lub z innego kraju”. Taka logika jest praktycznie niemożliwa do wyrażenia jedynie w klasycznych regułach firewalla.
W praktyce model Zero Trust wymaga spójnej platformy tożsamości (IdP, SSO, MFA), mechanizmów oceny stanu urządzenia (endpoint posture), ciągłej analizy zachowania użytkowników i automatycznego egzekwowania polityk blisko aplikacji i danych.
Od dostępu do sieci do dostępu do aplikacji: ZTNA zamiast klasycznego VPN
Kluczową zmianą jest odejście od udzielania dostępu do całej sieci (jak w klasycznym VPN), na rzecz dostępu do konkretnych aplikacji. Użytkownik nie „wchodzi” już do sieci firmowej, lecz „łączy się” bezpośrednio z konkretną usługą – przy zachowaniu zasad Zero Trust. Tę koncepcję realizuje ZTNA (Zero Trust Network Access).
Jak działa ZTNA od środka
Administrator otrzymuje zgłoszenie: nowa aplikacja HR ma być dostępna zdalnie dla całej firmy, ale bez otwierania portów do środka. Jeszcze kilka lat temu oznaczałoby to kombinacje z VPN, regułami na firewallu i listą wyjątków. W modelu ZTNA to samo zadanie da się zrealizować inaczej – bliżej aplikacji i użytkownika niż sieci.
Architektura ZTNA opiera się zazwyczaj na kilku elementach:
- konektor/agent blisko aplikacji – mały komponent instalowany w sieci firmowej lub w VPC/VNet, który nawiązuje wychodzące, szyfrowane połączenie do chmurowej platformy ZTNA,
- broker/dostawca ZTNA w chmurze – punkt kontrolny, przez który przechodzi ruch użytkownika; to tutaj egzekwowane są polityki Zero Trust,
- klient na urządzeniu użytkownika lub agent w przeglądarce – zapewnia uwierzytelnienie, przekazanie kontekstu (tożsamość, stan urządzenia) i kieruje ruch do brokera,
- integracja z IdP – SSO, MFA, grupy i role z katalogu (np. Azure AD/Entra ID, Okta, AD FS) stają się podstawą polityk dostępu.
Po stronie administratora konfiguracja przypomina raczej publikację aplikacji niż tworzenie tuneli sieciowych. Definiuje się zasób (adres URL, FQDN, port, ewentualnie ścieżki), przypisuje do niego konektor, określa grupy użytkowników oraz warunki dostępu (MFA, typ urządzenia, kraj, poziom ryzyka logowania). Użytkownik widzi aplikację na portalu dostępowym lub w kliencie ZTNA i łączy się do niej bez świadomości, czy stoi ona w centrum danych, czy w prywatnym VPC.
Mini-wniosek: ZTNA przenosi punkt kontroli z sieci na warstwę aplikacji i tożsamości, eliminując konieczność wpuszczania użytkownika do całej sieci tylko po to, aby skorzystał z jednej usługi.
Tożsamość, urządzenie, kontekst – nowy „trójkąt zaufania”
Przy incydencie polegającym na przejęciu konta użytkownika tradycyjny firewall często nie widzi nic podejrzanego – ruch wygląda tak jak zawsze. W modelu opartym na tożsamości różnica widoczna jest w kontekście: inny kraj, inne urządzenie, inna pora, nietypowy wolumen danych.
Nowoczesne systemy bezpieczeństwa korzystają z trzech głównych wymiarów:
- Tożsamość – kto się loguje (człowiek, serwis, konto techniczne), do jakich grup należy, jak silnie został uwierzytelniony, czy konto wykazuje anomalie.
- Urządzenie – czy jest zarządzane przez MDM/EDR, czy ma aktualne poprawki, włączone szyfrowanie dysku, aktywne zabezpieczenia anty-malware.
- Kontekst – lokalizacja, sieć, czas, typ zasobu, poziom ryzyka wskazany przez systemy UEBA lub dostawcę tożsamości.
Na tej podstawie buduje się polityki typu Conditional Access. Dostęp do wrażliwych systemów finansowych może wymagać urządzenia zgodnego z polityką bezpieczeństwa i silnego MFA, natomiast do intranetu wystarczy uwierzytelnienie SSO z wewnętrznej sieci. Ten sam użytkownik, ten sam login – ale inne decyzje w zależności od warunków.
Mini-wniosek: zaufanie przestaje być binarne („dopuszczony” vs. „zablokowany”); staje się dynamiczne i stopniowane, co utrudnia atakującym wykorzystanie pojedynczego „przeskoku” (np. wykradzione hasło).
Rozszerzanie Zero Trust poza użytkowników końcowych
W pewnym momencie każda organizacja odkrywa, że „użytkownicy” to nie tylko ludzie. Integracje system–system, kontenery, mikroserwisy, funkcje serverless – wszystko to wymaga dostępu do danych i zasobów. Jeśli zostanie oparte na stałych kluczach API, otwartych sieciach wewnętrznych i zaufaniu do IP, szybko stanie się najsłabszym ogniwem.
Zero Trust dla usług oznacza kilka praktyk:
- silne tożsamości maszyn – certyfikaty, workload identities, managed identities w chmurze zamiast haseł zapisanych w konfiguracji,
- segmentacja logiczna – mikroserwisy nie widzą wszystkiego dookoła; komunikują się tylko z konkretnymi usługami przez zdefiniowane API,
- service mesh z politykami opartymi na tożsamości – mTLS między usługami, autoryzacja oparta na tym, która usługa się komunikuje, a nie z jakiego IP.
Mini-wniosek: przeniesienie zasad Zero Trust na poziom usług i aplikacji ogranicza skutki włamań – atakujący nie „rozlewa się” po całej infrastrukturze po zdobyciu jednego dostępu.
SASE – co to naprawdę jest, a co jest jedynie marketingiem
Krótka scena z życia: „kupmy SASE, bo tak mówi Gartner”
Dyrektor IT wraca z konferencji z hasłem: „Musimy mieć SASE, wszyscy o tym mówią”. Dostawcy prześcigają się w ofertach, prezentacje pełne są kolorowych chmurek i strzałek. Tymczasem zespół operacyjny zastanawia się, czy to oznacza wymianę firewalli, migrację VPN, czy może kolejny produkt do obsługi.
SASE (Secure Access Service Edge) to koncepcja łącząca funkcje sieciowe i bezpieczeństwa w jedną, globalnie dostępną usługę w chmurze. Zamiast budować centralny perymetr i „wciągać” do niego ruch z całego świata, organizacja korzysta z rozproszonych punktów obecności dostawcy, który zapewnia:
- funkcje sieciowe (SD-WAN, optymalizacja tras, dynamiczne łącza),
- funkcje bezpieczeństwa (ZTNA, SWG, CASB, FWaaS, DLP) jako zintegrowaną usługę.
W praktyce SASE ma kilka kluczowych cech, które odróżniają go od zwykłej „paczki produktów w chmurze”:
- globalna, chmurowa platforma – jeden „fabric”, a nie zestaw odrębnych usług spinanych tunelami IPsec,
- wspólny silnik polityk – to samo miejsce, w którym zarządza się dostępem użytkownika do aplikacji w chmurze, ruchu internetowego i połączeń między lokalizacjami,
- spójna widoczność – jeden panel do monitorowania i analiz, zamiast kilku usług o ograniczonym wglądzie.
Marketingowa pułapka polega na tym, że niemal każdy produkt SaaS z etykietą „security” może zostać opisany jako element SASE. Pojawiają się więc „mini-SASE” lub „SASE-ready firewalle”, które w rzeczywistości są po prostu klasycznymi rozwiązaniami przeniesionymi do chmury IaaS.
Mini-wniosek: prawdziwe SASE to nie pojedyncze urządzenie ani sama funkcja ZTNA, lecz spójna usługa łącząca sieć i bezpieczeństwo w jednym, chmurowym szkieletu.
Kluczowe komponenty SASE bez żargonu
Żeby odróżnić pełnowartościową platformę od „naklejki SASE”, przydaje się prosty filtr. Większość dojrzałych wdrożeń opiera się o następujące elementy:
- SD-WAN – łączy oddziały, centra danych i chmury, inteligentnie wybierając ścieżkę (MPLS, Internet, LTE/5G) i dbając o jakość połączeń,
- SWG (Secure Web Gateway) – filtruje ruch WWW/HTTPS, blokuje złośliwe domeny, egzekwuje polityki „acceptable use” i może inspekcjonować treść,
- CASB (Cloud Access Security Broker) – daje wgląd w użycie SaaS, wykrywa shadow IT, kontroluje działania użytkownika (upload, share, download) w chmurze,
- ZTNA – bezpieczny, kontekstowy dostęp do aplikacji prywatnych bez otwierania sieci do Internetu,
- FWaaS (Firewall as a Service) – funkcje klasycznego firewalla dostępne jako usługa w chmurze, z możliwością segmentacji i kontroli ruchu nie-webowego.
Te funkcje mogą występować w różnym zestawieniu i dojrzałości, ale im silniej są zintegrowane na poziomie polityk i logów, tym bliżej organizacja jest do faktycznego SASE. Jeśli każda z nich ma osobny portal, osobne polityki, a integracja polega na ręcznym tworzeniu reguł, to w praktyce jest to tylko zestaw punktowych produktów.
Mini-wniosek: przy wyborze SASE mniej liczy się liczba „checkboxów” w tabelce funkcjonalnej, a bardziej to, na ile jednolite są polityki i zarządzanie.
Co SASE realnie zmienia dla użytkownika i zespołu IT
Pracownik terenowy uruchamia laptop na lotnisku, łączy się z Wi-Fi, otwiera klienta lub przeglądarkę – i tyle. Niezależnie od miejsca ruch kierowany jest do najbliższego punktu POP dostawcy SASE, gdzie stosowane są te same polityki co w biurze: filtrowanie WWW, dostęp do aplikacji prywatnych, ochrona danych.
Od strony zespołu IT następują trzy główne zmiany:
- centralizacja polityk – reguły dostępu, kategorie stron, ograniczenia dla SaaS czy segmentacja ruchu między lokalizacjami konfigurowane są w jednym miejscu,
- uproszczenie topologii – zamiast tuneli „każdy z każdym” lub kaskad hub-and-spoke, większość lokalizacji i użytkowników ma pojedynczy tunel/agent do chmurowej platformy,
- większa przewidywalność – użytkownik w domu, w oddziale i w podróży podlega tej samej logice bezpieczeństwa; nie trzeba utrzymywać różnych „trybów pracy” (on-prem vs. remote).
Mini-wniosek: z perspektywy użytkownika SASE upraszcza dostęp (jedno miejsce, jeden sposób łączenia), a z perspektywy IT redukuje liczbę architektonicznych „wyjątków” i lokalnych rozwiązań.
SD-WAN, SSE, SASE – jak to się ze sobą łączy i czym się różni
Scena: trzy skróty na jednym slajdzie
Na spotkaniu z dostawcą padają skróty: SD-WAN, SASE, SSE. Zarząd słyszy „nowoczesna sieć” i „bezpieczeństwo w chmurze”, inżynierowie próbują zrozumieć, co jest im faktycznie potrzebne, a co jest tylko zmianą nazwy tego, co już mają. Rozplątanie tego gąszczu pomaga podejmować decyzje, które nie skończą się dublowaniem funkcji.
SD-WAN – fundament sieciowy pod nowy model bezpieczeństwa
SD-WAN (Software-Defined WAN) rozwiązuje problem: jak spiąć oddziały, centra danych i chmury w sposób elastyczny, tani i odporny na awarie. Zamiast polegać wyłącznie na MPLS, wykorzystuje różne łącza Internetowe, LTE/5G, a o tym, jak ruch ma płynąć, decydują reguły oparte na aplikacjach, SLA, priorytetach biznesowych.
Kluczowe cechy SD-WAN to m.in.:
- świadomość aplikacji – ruch do krytycznych systemów (ERP, VoIP) traktowany jest inaczej niż do mediów społecznościowych,
- dynamiczny wybór ścieżki – jeśli jedno łącze traci jakość, ruch może zostać automatycznie przełączony,
- upraszczanie konfiguracji – polityki definiuje się centralnie, a urządzenia na brzegu stosują je lokalnie.
SD-WAN nie jest z definicji rozwiązaniem bezpieczeństwa, choć wielu producentów dodaje funkcje NGFW czy IPS. W kontekście SASE pełni rolę „rury” między lokalizacjami a chmurowym „fabric” bezpieczeństwa. Placówki, które wcześniej łączyły się do centralnego data center, zaczynają łączyć się bezpośrednio do najbliższych POP-ów SASE, co redukuje opóźnienia i uzależnienie od pojedynczego punktu.
Mini-wniosek: SD-WAN to warstwa transportowa i optymalizacyjna; sam w sobie nie rozwiązuje problemu kontroli dostępu użytkownika do aplikacji, ale tworzy pod to solidny fundament.
SSE – „połówka” SASE skupiona na bezpieczeństwie
Kiedy organizacja nie potrzebuje (lub nie chce na razie zmieniać) warstwy WAN, a równocześnie szuka nowoczesnego modelu bezpieczeństwa w chmurze, pojawia się pojęcie SSE (Security Service Edge). Można je traktować jako „bezpieczną połówkę” SASE – bez funkcji sieciowych SD-WAN.
Do SSE zalicza się zwykle:
- ZTNA – dostęp do aplikacji prywatnych,
- SWG – ochrona ruchu do Internetu,
- CASB – kontrola i widoczność użycia SaaS,
- czasem również FWaaS – firewall jako usługa w chmurze.
Scenariusz praktyczny: firma ma już działający SD-WAN lub nie ma rozbudowanej sieci oddziałów, ale posiada wielu pracowników zdalnych i dużo aplikacji w chmurze. Zamiast wymieniać całą sieć, wdraża SSE jako „parasol” bezpieczeństwa nad użytkownikami i ruchem do chmury. Dopiero później – jeśli będzie to miało sens – może dołożyć elementy SD-WAN i przejść w pełne SASE.
Mini-wniosek: SSE to naturalny krok dla organizacji, które najpierw chcą uporządkować bezpieczeństwo dostępu, a dopiero później angażować się w przebudowę całej warstwy WAN.
SASE – związek SD-WAN i SSE w jednym modelu operacyjnym
Jak złożyć SD-WAN i SSE w spójne SASE, a nie puzzle z różnych pudełek
Na warsztacie architektonicznym sieć jest po lewej stronie tablicy, bezpieczeństwo po prawej, a po godzinie dyskusji wszyscy dochodzą do tego samego miejsca: „chcemy SASE”. Problem zaczyna się, gdy okazuje się, że SD-WAN kupiono od jednego dostawcy, SSE od drugiego, a użytkownik końcowy i tak widzi dwa agenty i trzy portale logowania.
Przy przejściu do SASE kluczowe jest nie tyle „odhaczenie” funkcji, ile zbudowanie jednego modelu operacyjnego. W praktyce oznacza to kilka decyzji architektonicznych:
- kto jest „mózgiem” polityk – czy reguły dostępu opisujesz przede wszystkim w platformie bezpieczeństwa, a SD-WAN pełni rolę transportu, czy odwrotnie,
- jak wygląda ścieżka ruchu – czy oddziały łączą się najpierw do POP SASE, a dopiero potem do chmur/publicznego Internetu, czy istnieją wyjątki „direct to Internet” z lokalnym breakoutem,
- jak chronisz ruch między lokalizacjami – czy IPsec/segmentacja realizowane są na brzegu SD-WAN, czy outsourcowane do FWaaS w chmurze.
W dojrzałym modelu SASE polityki są spójne niezależnie od ścieżki. Pracownik w oddziale, który wychodzi do Internetu przez POP SASE, i pracownik zdalny z agentem SSE podlegają temu samemu zestawowi zasad. SD-WAN dba o to, aby ruch dotarł w odpowiednie miejsce w najlepszej jakości, natomiast warstwa SSE/SASE dba o to, kto do czego ma dostęp i na jakich warunkach.
Mini-wniosek: SASE zaczyna się tam, gdzie kończy się rysowanie dwóch oddzielnych diagramów „sieć” i „bezpieczeństwo”, a powstaje jeden wspólny schemat z tożsamością użytkownika w centrum.
Scenariusze dojścia do SASE: ewolucja zamiast wielkiego przeskoku
Na jednym z projektów prezes chciał „SASE w rok”, podczas gdy zespół IT wiedział, że ma w data center firewalle sprzed dekady i MPLS z umowami na kilka lat do przodu. Zderzenie ambicji z rzeczywistością zwykle kończy się odkładaniem zmian „na później”, chyba że rozbije się je na logiczne etapy.
Najczęściej spotykane ścieżki przejścia do SASE to:
- od SD-WAN do SASE – organizacja najpierw konsoliduje i upraszcza sieć WAN (rezygnacja z części MPLS, centralne sterowanie), a następnie dobudowuje elementy SSE, początkowo np. w formie ZTNA i SWG dla pracowników zdalnych,
- od SSE do SASE – firmy z mocnym komponentem pracy zdalnej zaczynają od chmurowego bezpieczeństwa dla użytkowników i aplikacji, a dopiero później migrują ruch oddziałów z klasycznego WAN na SD-WAN zintegrowany z tym samym dostawcą,
- „zielona łąka” – rzadki, ale wymarzony wariant przy budowie nowej organizacji lub dużej restrukturyzacji, gdzie od razu projektuje się sieć w duchu SASE, bez bagażu starych kontraktów i urządzeń.
Każda z tych dróg ma inny profil ryzyka i inny horyzont czasowy. Krytyczne jest, aby na starcie zdefiniować punkt docelowy: jak ma wyglądać dostęp użytkownika, jakie są główne kategorie aplikacji, skąd do nich ruch będzie płynął. Bez tego łatwo utknąć w półkroku – z osobnym SD-WAN i osobnym SSE, które „kiedyś” ktoś połączy.
Mini-wniosek: migrację do SASE lepiej planować jako serię kontrolowanych kroków z jasną wizją końcową, niż jako jednorazową „wymianę wszystkiego na nowe” bez mapy drogowej.
Rola tożsamości i kontekstu w praktycznym modelu SASE
Podczas audytu incydentu zespół bezpieczeństwa próbuje odpowiedzieć na pytanie: „kto miał dostęp do tej aplikacji wczoraj wieczorem?”. W klasycznym modelu kończy się to przeglądaniem logów firewalli, VPN-ów i systemów katalogowych. W podejściu SASE odpowiedź powinna być widoczna w jednym miejscu – bo to tożsamość i kontekst są osią polityk, a nie adres IP.
Typowa polityka w SASE nie mówi „pozwól ruch z sieci 10.10.0.0/16 do serwera X na porcie Y”, tylko raczej: „pracownicy działu finansów z zarządzanymi laptopami, korzystający z firmowego IdP, mają dostęp do aplikacji księgowej pod warunkiem, że łączą się z zaufanej lokalizacji lub przez agenta z aktualną ochroną endpointa”.
Taki model wymaga kilku elementów:
- centralnego źródła tożsamości (IdP) – np. Azure AD, Okta, Keycloak; najlepiej z silnym uwierzytelnianiem i grupami odzwierciedlającymi strukturę organizacji,
- sygnałów o stanie urządzenia – integracji z EDR/MDM, aby polityka mogła odróżnić firmowego laptopa od prywatnego komputera w przeglądarni,
- kontekstu sieciowego – wiedzy, skąd pochodzi połączenie (kraj, typ sieci, reputacja IP), czy nie jest to np. znany węzeł VPN wykorzystywany do nadużyć.
Na tej podstawie SASE podejmuje decyzje: przyznać dostęp, wymusić dodatkowe uwierzytelnienie, ograniczyć uprawnienia lub całkowicie zablokować ruch. Co ważne, te same zasady działają wobec aplikacji SaaS, prywatnych systemów w data center i ruchu do publicznego Internetu.
Mini-wniosek: przejście na SASE bez uporządkowanej tożsamości i integracji z narzędziami endpointowymi kończy się rozczarowaniem – platforma staje się tylko „ładniejszym firewallem w chmurze”.
Zmiana pracy zespołów: od zarządzania pudełkami do projektowania polityk
W tradycyjnym modelu inżynier sieciowy spędza dzień na logowaniu się do kolejnych firewalli, sprawdzaniu tuneli IPsec i walce z trasowaniem między oddziałami. Po wdrożeniu SASE coraz częściej okazuje się, że największą wartością jest ktoś, kto rozumie procesy biznesowe i potrafi przełożyć je na polityki dostępu i segmentacji.
Zmieniają się też kompetencje:
- administratorzy sieci przechodzą od konfiguracji CLI na pojedynczych urządzeniach do projektowania wzorców topologii i profili lokalizacji w centralnym panelu,
- specjaliści ds. bezpieczeństwa uczą się pracować na logach aplikacyjnych i danych o tożsamości, a nie tylko na sygnaturach IPS i regułach port/protokół,
- zespoły IT blisko współpracują z biznesem, aby zrozumieć, które aplikacje są krytyczne i jakich warunków dostępu wymagają.
Przykład z praktyki: po wprowadzeniu ZTNA w ramach SASE, dział IT zorientował się, że tak naprawdę nie ma spisu wszystkich aplikacji wewnętrznych i ich właścicieli. Pierwszy etap projektu polegał więc nie na konfiguracji systemu, lecz na inwentaryzacji i klasyfikacji aplikacji. Dopiero potem można było sensownie zbudować polityki.
Mini-wniosek: w modelu SASE narzędzia stają się bardziej „deklaratywne” – to, co kiedyś robiło się komendami na urządzeniu, dziś opisuje się jako politykę biznesową. Zespół, który nie ma czasu ani zasobów, by zająć się tym poziomem, nie wykorzysta potencjału architektury.
Typowe pułapki przy wdrażaniu SASE w realnej organizacji
Na papierze SASE wygląda kusząco: jedna platforma, jedna polityka, koniec z VPN-ami i klasycznymi firewallami. W pierwszych miesiącach projektu wychodzą jednak na wierzch drobiazgi, które potrafią zatrzymać całą transformację.
Kilka najczęstszych problemów:
- hybrydowa rzeczywistość – przez dłuższy czas część ruchu idzie „starą drogą” (np. do data center przez klasyczny VPN), a część przez SASE; bez jasnych zasad szybko powstają niespójności polityk i „wyspy” bezpieczeństwa,
- brak przygotowania aplikacji – stare systemy używające twardo zakodowanych adresów IP, brak TLS, nietypowe porty i protokoły utrudniają wystawienie ich przez ZTNA i segmentację w FWaaS,
- niedocenienie wydajności – przy założeniu „to chmura, więc będzie szybciej” pomijane są testy pod kątem opóźnień między konkretnymi lokalizacjami a POP-ami dostawcy,
- rozjazd między działami – bezpieczeństwo, sieć, infrastruktura i zespół aplikacyjny mają różne priorytety; bez jednego sponsora biznesowego SASE może zostać odebrane jako „projekt IT, który wprowadza utrudnienia”.
Dobrym sposobem na ograniczenie ryzyka jest pilotaż na ograniczonym zakresie: jeden region, jeden zestaw aplikacji, jedna grupa użytkowników. Jeśli na tym etapie pojawią się problemy z tożsamością, wydajnością lub widocznością, dużo łatwiej je skorygować, niż gdy platforma obejmie całą organizację.
Mini-wniosek: technologia SASE dojrzała szybciej niż organizacyjne procesy; nieudany projekt częściej wynika z braku przygotowania ludzi i aplikacji niż z ograniczeń samej platformy.
Jak mierzyć sukces przejścia od klasycznych firewalli do SASE
Po roku od startu projektu zarząd oczekuje odpowiedzi: „czy nowy model bezpieczeństwa faktycznie coś poprawił?”. Samo „działa, użytkownicy się logują” nie wystarcza; potrzebne są konkretne wskaźniki, które pokażą, że to nie była tylko kosmetyczna zmiana technologii.
Przydatne metryki łatwo podzielić na kilka grup:
- operacyjne – liczba utrzymywanych urządzeń brzegowych, liczba indywidualnie zarządzanych tuneli VPN, czas wdrożenia nowej lokalizacji (od zamówienia łącza do pełnego wdrożenia polityk),
- bezpieczeństwo – odsetek ruchu przechodzącego przez inspekcję TLS, liczba aplikacji objętych ZTNA vs. klasycznym VPN, czas wykrycia i zamknięcia incydentu dzięki jednolitym logom,
- doświadczenie użytkownika – czas logowania do zasobów (SSO vs. wiele haseł), średnie opóźnienie do kluczowych aplikacji po migracji, liczba zgłoszeń do Service Desk dotyczących VPN i dostępu zdalnego.
Dobrą praktyką jest zdefiniowanie tych wskaźników jeszcze przed startem projektu i zebranie wartości „przed” – inaczej trudno będzie obronić inwestycję w rozmowach z biznesem. SASE wpływa jednocześnie na koszty łączy, koszty operacyjne, poziom ryzyka i komfort pracy użytkowników, więc warto pokazać tę zmianę w liczbach, a nie tylko w diagramach.
Mini-wniosek: jeśli nie da się nazwać i zmierzyć oczekiwanych efektów SASE, dyskusja o architekturze szybko zamienia się w spór o marki i funkcje, zamiast o realny wpływ na organizację.
SASE w kontekście regulacji i audytów
Podczas przeglądu bezpieczeństwa audytor prosi o opis segmentacji sieci, kontroli dostępu i monitoringu. W tradycyjnej architekturze odpowiedzią są diagramy VLAN-ów, listy ACL i zrzuty z firewalli. W modelu SASE narracja przesuwa się z poziomu infrastruktury na poziom procesów i polityk.
Platformy SASE ułatwiają spełnienie wymagań regulacyjnych (np. RODO, wytyczne KNF, normy ISO) pod warunkiem, że polityki są właściwie udokumentowane. Pomagają w tym m.in.:
- centralne logi i raporty – wygodne przedstawienie, kto i kiedy miał dostęp do jakich zasobów, z jakich lokalizacji i na jakich warunkach,
- polityki oparte na rolach – możliwość pokazania, że dostęp do danych wrażliwych jest ograniczony do konkretnych ról biznesowych, a nie do „wszystkich w sieci 10.0.0.0/8”,
- segmentacja aplikacyjna – precyzyjne odseparowanie stref zawierających dane osobowe, finansowe lub systemy krytyczne bez konieczności rysowania skomplikowanych map VLAN-ów.
Istotnym elementem staje się także zarządzanie dostawcą. W modelu SASE dużo więcej odpowiedzialności za infrastrukturę i jej dostępność przechodzi na usługodawcę, co wymaga odpowiednich zapisów w umowach, audytów dostawcy i zrozumienia, gdzie kończy się odpowiedzialność klienta, a zaczyna chmury.
Mini-wniosek: zamiast bronić się przed SASE argumentem „audyt tego nie zaakceptuje”, lepiej wspólnie z audytorem przełożyć nowe możliwości platformy na język wymagań regulacyjnych i umiejętnie to udokumentować.
Najczęściej zadawane pytania (FAQ)
Czy klasyczny firewall jest jeszcze potrzebny w nowoczesnej organizacji?
Administrator siedzi w serwerowni, widzi zielone lampki na firewallu i czuje spokój, a tymczasem pracownik loguje się do SaaS z domowego Wi‑Fi, całkowicie omijając to urządzenie. Firewall działa poprawnie, ale nie widzi połowy tego, co robią użytkownicy poza biurem.
Klasyczny firewall nadal jest potrzebny – chroni lokalne zasoby, serwerownie, oddziały i ruch do aplikacji on‑premise. Przestaje być jednak „centralnym punktem prawdy” o bezpieczeństwie. Jego rolę trzeba wkomponować w szerszy model, który obejmuje użytkowników w terenie, chmurę publiczną i SaaS, a nie tylko sieć biurową.
Dlaczego sam firewall i VPN nie wystarczą przy pracy zdalnej i SaaS?
Typowy scenariusz: użytkownik łączy się do Teamsów czy CRM-u w chmurze bez VPN, bo „tak jest szybciej i wszystko działa”. Z perspektywy firmowego firewalla ten ruch po prostu nie istnieje – nie ma logów, nie ma polityk, nie ma kontroli.
Model oparty wyłącznie na firewallu i VPN zakłada, że większość ruchu przejdzie przez centralny punkt. Przy obecnej skali SaaS, pracy hybrydowej i prywatnych urządzeń jest to fikcja. Pojawiają się luki: brak widoczności działań użytkownika w chmurze, trudność w egzekwowaniu polityk, ogrom wyjątków w VPN „bo inaczej biznes nie działa”. Nowoczesne podejście musi przenieść kontrolę bliżej użytkownika i aplikacji, a nie trzymać się kurczowo jednego tunelu VPN.
Co to jest SASE i czym różni się od klasycznego bezpieczeństwa sieciowego?
Wyobraź sobie, że zamiast stawiać kolejny „mur” w serwerowni, przenosisz ochronę do chmury i „ciągniesz” ją za użytkownikiem, gdziekolwiek ten się znajduje. Nieważne, czy siedzi w biurze, w pociągu czy na lotnisku – wszędzie korzysta z tych samych zasad bezpieczeństwa.
SASE (Secure Access Service Edge) łączy funkcje sieciowe (np. SD-WAN) z bezpieczeństwem (m.in. firewall w chmurze, CASB, SWG, Zero Trust) i dostarcza je jako usługę z rozproszonych punktów brzegowych. Zamiast jednego centralnego firewalla mamy chmurową „warstwę ochronną”, która uwzględnia: tożsamość użytkownika, stan urządzenia, kontekst aplikacji i lokalizację. Kluczowa różnica: chronimy dostęp do danych niezależnie od sieci, a nie tylko granicę jednej sieci lokalnej.
Jak rozpoznać, że organizacja „dosiadła się do ściany” z klasycznym modelem firewalla?
Dobrym lustrem są codzienne problemy: helpdesk co tydzień „na szybko” otwiera nowe porty, a dział sprzedaży od miesięcy używa niezatwierdzonego Dropboxa, bo inaczej nie jest w stanie pracować z klientami. Security team ma poczucie, że gasi pożary, a nie projektuje bezpieczeństwo.
Typowe sygnały, że stary model się sypie, to między innymi:
- rosnąca liczba incydentów w usługach chmurowych (przejęte konta, wycieki z dysków współdzielonych),
- rozkwit shadow IT – użytkownicy sami dobierają SaaS do pracy, poza radarami IT,
- nadmiar wyjątków w politykach VPN i firewalli, tworzonych „tymczasowo” i zostających na stałe,
- brak spójnego wglądu w to, co robią użytkownicy pracujący poza siecią firmową i poza VPN.
Jeśli te zjawiska są codziennością, sam firewall nie rozwiąże problemu – potrzebna jest zmiana architektury, a nie kolejna poprawka w regułach.
Czy przejście na model SASE oznacza rezygnację z obecnych firewalli?
W wielu firmach pojawia się obawa: „Jak wdrożymy SASE, to wszystko trzeba będzie wyrzucić do kosza?”. W praktyce wygląda to bardziej jak przestawianie torów niż burzenie całej stacji.
Najczęściej klasyczne firewalle zostają tam, gdzie mają sens: przy ochronie lokalnych serwerów, segmentów LAN, połączeń z systemami o wysokich wymaganiach regulacyjnych. SASE stopniowo przejmuje ruch użytkownik–Internet i użytkownik–SaaS, a także dostęp zdalny, oferując spójne polityki i lepszą widoczność. Przez pewien czas oba światy działają równolegle, a zakres odpowiedzialności „pudełek w serwerowni” po prostu się zmniejsza.
Od czego zacząć transformację z klasycznego firewalla do podejścia SASE / Zero Trust?
Najgorszy start to zakup kolejnego „magicznego pudełka” lub subskrypcji bez zrozumienia, skąd naprawdę biorą się luki. Znacznie skuteczniej działa podejście krok po kroku, oparte na realnych przepływach pracy.
Dobrą kolejnością bywa:
- inwentaryzacja: jakie kluczowe aplikacje są w chmurze, z jakich SaaS korzystają działy biznesowe, skąd logują się użytkownicy,
- uporządkowanie tożsamości i MFA – bez tego Zero Trust będzie tylko hasłem marketingowym,
- wdrożenie chmurowej kontroli dostępu do Internetu i SaaS (proxy/SWG, CASB) dla użytkowników spoza biura,
- stopniowa migracja dostępu zdalnego z klasycznego VPN na podejście „user-to-app” (Zero Trust Network Access),
- dopiero potem – pełniejsze spięcie tego w spójny model SASE.
Każdy z tych kroków może sam w sobie poprawić bezpieczeństwo, a przy okazji przygotowuje grunt pod dalszą ewolucję.
Jak pogodzić bezpieczeństwo sieciowe z wygodą użytkowników w modelu SASE?
Użytkownicy szybko obchodzą zabezpieczenia, które ich spowalniają – stąd logowanie do SaaS z prywatnego laptopa na publicznym Wi‑Fi, bez VPN i jakiejkolwiek kontroli. Jeśli nowe rozwiązanie bezpieczeństwa będzie tylko kolejną przeszkodą, skończy jak stary VPN: omijane przy każdej okazji.
Kluczem jest model, w którym:
- dostęp „po prostu działa” – użytkownik nie musi ręcznie zestawiać tunelu ani kombinować z lokalizacją,
- polityki opierają się na tożsamości i kontekście, więc można precyzyjnie ograniczać ryzyko bez blokowania wszystkiego „na wszelki wypadek”,
- bezpieczeństwo jest jak pasy w samochodzie – obecne zawsze, ale nie przeszkadza w jeździe, dopóki ktoś nie robi nic ryzykownego.
Dobre wdrożenie SASE zwykle poprawia wygodę: znika konieczność ciągłego łączenia z VPN, dostęp do aplikacji jest bardziej przewidywalny, a użytkownik mniej odczuwa „tarcie” między bezpieczeństwem a pracą.
