SASE w pigułce: połączenie sieci i bezpieczeństwa dla rozproszonej firmy w jednym rozwiązaniu

Po co w ogóle łączyć sieć i bezpieczeństwo? Kontekst dla SASE

Od „wszystko do data center” do „wszędzie do wszystkiego”

Przez lata wzorzec był prosty: biura, fabryki i oddziały łączyły się siecią MPLS do centralnego data center. Tam stały serwery, tam była zapora, proxy, IDS/IPS, DLP – całe bezpieczeństwo. Internet często był tylko w jednym punkcie wyjścia. Użytkownik w oddziale, chcąc wejść do dowolnej aplikacji SaaS, szedł najpierw do centrali, przechodził przez stos pudełek, a dopiero potem wychodził do sieci publicznej.

Ten model przestał się bronić, gdy pojawiła się masowa praca zdalna, SaaS i chmura publiczna. Ruch sieciowy zmienił kierunek. Użytkownicy łączą się:

• z domu, co-worku, hotelu, pociągu, telefonu;
• bezpośrednio do usług SaaS (Teams, Salesforce, Google Workspace, Workday i wiele innych);
• do aplikacji hostowanych w chmurach publicznych (AWS, Azure, GCP);
• do kilku data center równocześnie (on-prem i colocation).

Zamiast prostego schematu „oddział → centrala → internet”, pojawia się topologia „wszędzie do wszystkiego”. Z punktu widzenia klasycznego MPLS i centralnego firewalla to koszmar.

Ruch nie musi już przechodzić przez Twoje data center, a więc:

• część komunikacji omija tradycyjne zabezpieczenia;
• rośnie liczba punktów, w których trzeba egzekwować polityki bezpieczeństwa;
• dla użytkownika każde dodatkowe „hop” to opóźnienie, a dla organizacji – dodatkowy koszt.

Pchanie wszystkiego do centrali tylko po to, by „zaliczyć” firewalla, stoi w sprzeczności z oczekiwaniem użytkownika: dostęp ma być szybki, stabilny i niezależny od miejsca, z którego pracuje.

Dlaczego MPLS + VPN + stos osobnych urządzeń nie nadąża

Tradycyjny model rozwiązuje problem fragmentacją. Dla każdego wycinka powstaje osobne rozwiązanie:

• MPLS dla połączeń między oddziałami;
• klient VPN dla pracowników zdalnych;
• oddzielne urządzenia (fizyczne lub wirtualne) pełniące rolę zapory, proxy, DLP, IDS/IPS;
• osobne bramki dostępu do chmury, czasem kilka dla różnych regionów.

Teoretycznie wszystko działa. W praktyce widoczne są skutki uboczne:

• opóźnienia i niepotrzebne trasy – ruch do SaaS wraca do centrali z odległych lokalizacji, tylko po to, by wrócić w tę samą stronę do najbliższego regionu chmurowego;
• kaskada pudełek – każdy nowy wymóg bezpieczeństwa to kolejna wirtualka, nowa subskrypcja, nowy zespół do zarządzania;
• niespójne polityki – inne zasady w VPN, inne w proxy, inne na zaporze, a po drodze jeszcze ręcznie dodawane wyjątki;
• napięcie między siecią a bezpieczeństwem – sieć chce uprościć trasy, bezpieczeństwo dokłada kolejne punkty kontroli, użytkownicy narzekają na wydajność.

Ten model pęka szczególnie mocno, gdy:

• pojawi się większa fala pracy zdalnej i nie da się „skalować” VPN bez gigantycznych kosztów;
• aplikacje z on-prem przenoszone są etapami do chmury, a architektura sieci i bezpieczeństwa nie nadąża;
• dochodzi do incydentu i nagle trzeba zapanować nad tym, przez co właściwie przechodzi ruch i kto ma dostęp.

Koszty złożoności i historia firmy, która „utonęła” w patchworku

Przykład z życia: średnia firma usługowa z kilkunastoma oddziałami w Polsce, kilkoma w Europie, jednym data center on-prem i rosnącym użyciem SaaS. Z czasem dorobiła się:

• MPLS z kilkoma operatorami;
• osobnego VPN dla użytkowników mobilnych;
• urządzeń firewall/UTM w centrali i kilku większych oddziałach;
• oddzielnego proxy w data center dla ruchu web;
• dedykowanego rozwiązania CASB do monitorowania kilku kluczowych aplikacji SaaS;
• bramki do chmury publicznej od innego dostawcy.

Każdy element powstał z dobrego powodu, zwykle w reakcji na konkretną potrzebę lub incydent. Po kilku latach infrastruktura przypominała jednak łaty na łatach:

• zmiana adresu IP usługi w chmurze oznaczała poprawki w kilku systemach – część zmian ginęła po drodze;
• zespół bezpieczeństwa nie był w stanie odtworzyć spójnej ścieżki dostępu użytkownika z domu do konkretnej aplikacji SaaS;
• czas wdrożenia nowej lokalizacji liczony był w tygodniach, bo trzeba było dograć łącze, sprzęt, konfiguracje w kilku systemach;
• koszty licencji i utrzymania rosły, bo każdy „moduł” miał swój osobny model licencyjny i cykl odnowień.

SASE nie jest magicznym produktem, który z dnia na dzień rozwiąże wszystko. Jest raczej modelem pracy z siecią i bezpieczeństwem, który zakłada, że świat jest rozproszony i że to, co lokalne i scentralizowane, ma ustąpić miejsca chmurowej usłudze, możliwie blisko użytkownika.

SASE jako odpowiedź na rozproszenie, nie jako gadżet

Źródłowy sens SASE polega na tym, by:

• przestać myśleć o sieci jako o fizycznych trasach między lokalizacjami, a zacząć jak o logicznym, kontrolowanym dostępie między użytkownikiem a aplikacją, niezależnie od miejsca;
• zastąpić kaskadę rozwiązań bezpieczeństwa jedną spójną warstwą polityk, egzekwowaną możliwie blisko punktu połączenia;
• wykorzystać chmurę jako miejsce świadczenia zarówno usług sieciowych, jak i bezpieczeństwa.

SASE nie ma sensu w organizacji, która:

• ma jedną, zamkniętą lokalizację, praktycznie bez pracy zdalnej i bez SaaS;
• działa w reżimie, w którym internet jest minimalny, a wszystkie systemy są lokalne i wymagają izolacji.

W każdej innej sytuacji rozproszenie jest faktem, a SASE staje się sposobem, by je okiełznać bez budowania kolejnej warstwy patchworku.

Czym właściwie jest SASE – esencja bez marketingowego szumu

Przekład definicji SASE na język praktyka

Gartner zdefiniował Secure Access Service Edge (SASE) jako połączenie funkcji sieciowych (takich jak SD-WAN) i funkcji bezpieczeństwa (takich jak SWG, CASB, FWaaS, ZTNA) dostarczanych jako usługa z chmury, możliwie blisko użytkownika. Tyle teoria. W praktyce SASE oznacza:

• jeden logiczny „brzeg” (edge), w którym zbiegają się: użytkownik, urządzenie, aplikacja;
• zestaw usług sieciowych (routing, optymalizacja, QoS) i bezpieczeństwa (kontrola dostępu, inspekcja, ochrona danych), działających z tej samej platformy;
• model as-a-service, w którym większość inteligencji leży po stronie chmury dostawcy, a po stronie klienta są lekkie agenty lub proste urządzenia brzegowe.

Zamiast inwestować w kolejne fizyczne urządzenia i tunele, organizacja kupuje punkt obecności bezpieczeństwa i sieci, do którego podpinają się użytkownicy, lokalizacje, aplikacje i chmury.

Dwa filary: sieć i bezpieczeństwo bez muru między zespołami

Żeby SASE miało sens, potrzebne są dwa filary.

Filar sieciowy – SD-WAN i optymalizacja tras

Część sieciowa SASE najczęściej opiera się o SD-WAN. Kluczowe cechy:

• możliwość wykorzystania różnych typów łączy (MPLS, Internet, LTE/5G) w sposób świadomy i dynamiczny;
• sterowanie ruchem na poziomie aplikacji, a nie tylko adresów IP i portów;
• monitorowanie jakości ścieżek i przełączanie ruchu w locie, gdy parametry spadają poniżej ustalonego progu.

Różnica względem „zwykłego VPN” polega na tym, że tunel nie jest po prostu zakładany między dwoma punktami, ale jest jednym z elementów sterowanej, mierzonej i optymalizowanej sieci, w której decyzje podejmuje centralne sterowanie (orchestrator).

Filar bezpieczeństwa – ZTNA, SWG, CASB, FWaaS

Drugi filar to funkcje bezpieczeństwa, które przestają być oddzielnymi wyspami, a stają się usługami w chmurowym edge. Typowo obejmują:

• ZTNA (Zero Trust Network Access) – dostęp do aplikacji oparty na tożsamości i kontekście, a nie przynależności do sieci;
• SWG (Secure Web Gateway) – kontrola i filtrowanie ruchu HTTP/HTTPS, ochrona przed malware, phishingiem, kontrola kategorii stron;
• CASB (Cloud Access Security Broker) – widoczność i kontrola użycia aplikacji SaaS, polityki dla konkretnych usług;
• FWaaS (Firewall as a Service) – funkcje klasycznego firewalla i często IPS, realizowane w chmurze;
• często także DLP, DNS security, kontrola aplikacji jako dodatkowe moduły.

Sedno: wszystkie te funkcje współdzielą jedną bazę polityk, jedno pojęcie użytkownika/tożsamości i jedno miejsce raportowania. To różni SASE od patchworku kilku niezależnych produktów SaaS.

Model usług z chmury blisko użytkownika

SASE zakłada, że nie musisz mieć własnych „brzegów” w każdym regionie świata. Zamiast tego korzystasz z globalnej sieci punktów dostępowych dostawcy. Użytkownik łączy się do najbliższego POP-u (Point of Presence), a tam:

• ruch jest uwierzytelniany, klasyfikowany, inspekowany;
• aplikacja docelowa (w chmurze lub on-prem) jest osiągana najkrótszą sensowną ścieżką;
• egzekwowane są polityki firmy (dostęp, ochrona przed zagrożeniami, DLP).

W praktyce oznacza to:

• mniej zależności od tego, gdzie jest fizycznie użytkownik – ważne, żeby najbliższy POP był rozsądnie blisko geograficznie;
• mniej zasobów sprzętowych do utrzymania w lokalnych serwerowniach i oddziałach;
• spójne zasady bezpieczeństwa dla użytkownika niezależnie od lokalizacji czy sposobu połączenia (biuro, dom, LTE).

Jak odróżnić pełnoprawne SASE od „naklejki marketingowej”

Rynek szybko podłapał modę na SASE, więc wiele rozwiązań zostało po prostu przechrzczonych. Kilka pytań, które pozwalają odsiać marketing:

• Czy dostawca oferuje zarówno SD-WAN, jak i funkcje bezpieczeństwa w jednym spójnym modelu (jeden portal, jedna logika polityk)?
• Czy funkcje SWG, CASB, ZTNA, FWaaS korzystają z tej samej definicji użytkownika i grup (integracja z IdP)?
• Czy dla użytkownika mobilnego i dla użytkownika w oddziale polityka bezpieczeństwa jest definiowana raz, czy w dwóch różnych systemach?
• Czy rozwiązanie jest dostarczane z globalnej, rozproszonej infrastruktury chmurowej dostawcy, czy raczej z kilku punktów w jednym regionie?
• Czy dostawca umożliwia płynną skalę (setki, tysiące użytkowników bez kupowania i instalowania kolejnych urządzeń)?

Jeśli odpowiedzi są wymijające („integrujemy się z partnerem X”, „możemy dostarczyć jako osobne moduły”), najpewniej patrzysz na hybrydę produktów sprzed epoki SASE.

Kiedy „prawie SASE” jest wystarczające i rozsądne

Pełny pakiet SASE nie zawsze ma sens ekonomiczny ani operacyjny. Przykładowo:

• organizacja ma już stabilny, nowoczesny SD-WAN, ale bezpieczeństwo ruchu web i SaaS jest rozproszone – wtedy rozsądne może być połączenie istniejącego SD-WAN z chmurowym SWG+CASB od jednego dostawcy;
• firma ma silny zespół odpowiedzialny za firewalle i on-prem data center, ale potrzebuje tylko nowoczesnego dostępu Zero Trust dla użytkowników zdalnych – wystarczy ZTNA jako pierwszy krok;
• część funkcji, jak zaawansowane DLP czy IPS, może być świadomie pozostawiona poza SASE, jeśli ich integracja nie przynosi widocznych korzyści.

„Prawie SASE” ma sens, gdy:

• potrzebujesz szybkiej poprawy doświadczenia użytkownika (np. praca zdalna, SaaS) bez wywracania sieci do góry nogami;
• budżet jest ograniczony, a największy ból leży w jednym obszarze (np. VPN i brak widoczności w SaaS);
• chcesz Stopniowo migrować – zacząć od ZTNA i SWG, potem dołożyć SD-WAN/FWaaS.

Nie ma sensu upierać się przy pełnym SASE tylko dlatego, że tak brzmi „kanoniczna” definicja, jeśli organizacja i tak nie wykorzysta wszystkich modułów.

Kluczowe komponenty SASE – co naprawdę musi się tam znaleźć

SD-WAN: fundament sieciowy, który wykracza poza VPN

SD-WAN często jest pierwszym elementem, który pojawia się w architekturze SASE. Jest to warstwa, która:

• abstrahuje fizyczne łącza (MPLS, Internet, LTE/5G) i przedstawia je jako jeden logiczny WAN;
• pozwala zdefiniować polityki routingu w kategoriach aplikacji, użytkowników, priorytetów biznesowych;
• monitoruje parametry łączy (opóźnienie, jitter, utrata pakietów) i dynamicznie wybiera najlepszą ścieżkę.

Jak SD-WAN współgra z chmurowym „edge” SASE

SD-WAN w kontekście SASE nie kończy się na tunelach między oddziałami. Jego rolą staje się doprowadzenie ruchu w sposób inteligentny do najbliższego punktu obecności SASE oraz – tam, gdzie ma to sens – bezpośrednio do chmur publicznych.

Praktyka pokazuje kilka głównych wzorców:

• „SD-WAN do chmury SASE” – ruch z oddziału jest kierowany najkrótszą ścieżką do POP-u dostawcy, gdzie odbywa się inspekcja i dalszy routing (Internet, SaaS, inne lokalizacje);
• „lokalny breakout + SASE” – część ruchu (np. krytyczne połączenia z data center) idzie tunelami bezpośrednimi, a reszta internetowego ruchu wychodzi lokalnie i wpada do chmurowego SWG/ZTNA;
• „hub w chmurze” – SD-WAN traktuje chmurowy POP jako centralny węzeł, zastępując tradycyjny data center w roli koncentratora.

Najczęstszy błąd to próba 1:1 przeniesienia starej topologii MPLS do SD-WAN/SASE. Zwykle kończy się to tym, że płaci się za nowe narzędzie, ale używa go jak starego VPN-a. Projekt warto zacząć od zmapowania aplikacji i ich wymagań, a dopiero potem rysować topologię.

ZTNA: dostęp do aplikacji bez „wpuszczania do sieci”

W modelu SASE ZTNA staje się podstawowym mechanizmem przyznawania dostępu. Zamiast budować tunel VPN do sieci, użytkownik otrzymuje połączenie do konkretnej aplikacji lub grupy aplikacji, pod warunkiem spełnienia wymogów polityki (tożsamość, stan urządzenia, lokalizacja, ryzyko).

Kluczowe elementy praktycznej implementacji ZTNA:

• pełna integracja z IdP i MFA – baza tożsamości musi być jedna (Azure AD/Entra, Okta, AD FS itd.), inaczej wpadamy w rejestry użytkowników rozsiane po systemach;
• powiązanie z urządzeniem – sama tożsamość użytkownika to za mało; sensowny ZTNA weryfikuje stan endpointa (system, łatki, EDR), przynajmniej na podstawowym poziomie;
• mikrosegmentacja na poziomie aplikacji – polityki typu „dostęp do finansów tylko z urządzeń firmowych, z wymuszonym szyfrowaniem dysku i EDR”, a nie „pełny VPN z laptopa prywatnego”.

Popularna rada „zacznij od zastąpienia VPN ZTNA” działa, gdy większość aplikacji jest webowa lub da się je za taką podać (reverse proxy, publikacja). Przestaje działać w środowiskach pełnych starych protokołów, thick clientów i niestandardowych portów. Tam realistyczniejsze jest podejście mieszane: ZTNA dla wszystkiego, co się da, a dla reszty stopniowa modernizacja lub izolowana brama VPN z bardzo wąskim zakresem dostępu.

SWG i CASB: kontrola ruchu web i SaaS z jednego miejsca

SWG i CASB w SASE to nie dwa osobne światy, lecz dwie perspektywy na ten sam ruch. SWG widzi strumień HTTP/HTTPS, CASB „rozumie” logikę konkretnych usług (Office 365, Google Workspace, Salesforce itd.).

W dojrzałym wdrożeniu SASE te dwa moduły współpracują w kilku obszarach:

• widoczność użycia SaaS – SWG wykrywa, do jakich usług łączy się użytkownik, a CASB rozpoznaje, które z nich są akceptowane, a które „shadow IT”;
• polityki per aplikacja, nie tylko kategoria strony – zamiast blokować całe „chmury plików”, można różnicować: pełen dostęp do OneDrive służbowego, tylko odczyt z prywatnych kont, całkowity zakaz wysyłki danych do losowych dysków w chmurze;
• ochrona danych w SaaS – DLP zintegrowane z CASB pozwala reagować na próby udostępniania dokumentów na zewnątrz czy wycieki danych do prywatnych przestrzeni.

Popularna obietnica „zobaczysz całe shadow IT w tydzień” spełnia się tylko w organizacjach, które wymuszą pełne kierowanie ruchu web przez SWG (agent, PAC, tunel). Bez tego raport o shadow IT pokazuje raczej to, co przejdzie przez kilka wybranych węzłów, a nie pełen obraz.

FWaaS i dodatkowe moduły: kiedy przenosić „ciężkie” funkcje do chmury

Firewall as a Service w SASE brzmi kusząco jako „jeden globalny firewall dla całej organizacji”. Rzeczywistość jest bardziej zniuansowana. FWaaS sprawdza się szczególnie w trzech scenariuszach:

• oddziały bez lokalnego IT – proste urządzenie brzegowe albo nawet bez niego, cały ruch przez POP SASE, gdzie działa firewall, IPS, filtrowanie DNS;
• praca zdalna – ten sam zestaw polityk bezpieczeństwa (aplikacje, porty, geolokacje) dla użytkowników „z domu” i „z biura”;
• kontrola ruchu wychodzącego z chmur publicznych – podpięcie VPC/VNetów do FWaaS zamiast stawiania osobnych appliance’y w każdym regionie.

Nie każda funkcja powinna jednak lądować w chmurowym firewallu od razu. Zaawansowane IPS, sandboxing czy granularne DLP potrafią generować tyle logów i taką złożoność, że sensowniej jest zostawić je w krytycznych segmentach (np. data center OT) i zintegrować z SASE tylko na poziomie polityk wysokiego poziomu.

Zdrowe podejście: zacząć od prostego, spójnego FWaaS (reguły aplikacyjne, geoblokady, podstawowy IPS), a dopiero z czasem przenosić bardziej wyrafinowane funkcje, jeśli widać realną korzyść operacyjną.

Tożsamość, urządzenie, kontekst – „klej” łączący komponenty

W SASE komponenty techniczne są mniej ważne niż wspólny model kontekstu. Bez niego kończy się na czterech różnych politykach dla tego samego użytkownika, w zależności od tego, czy ruch idzie przez ZTNA, SWG, czy FWaaS.

Spójny model obejmuje trzy wymiary:

• tożsamość użytkownika – jedna integracja z IdP, jeden mechanizm grup i atrybutów (rola, dział, poziom uprawnień);
• tożsamość i stan urządzenia – integracja z EDR/MDM, minimum: rozróżnienie urządzeń zarządzanych i niezarządzanych oraz platformy (Windows, macOS, mobilne);
• kontekst sesji – lokalizacja, godzina, ryzyko (nietypowe zachowanie, próba pobrania dużej ilości danych, logowanie z rzadkiej lokalizacji).

Wiele wdrożeń zatrzymuje się na samym SSO, ignorując kontekst urządzenia. Efekt: „Zero Trust” w nazwie, ale w praktyce dostęp z dowolnego, niezałatanego laptopa prywatnego, byle użytkownik znał hasło i miał dostęp do aplikacji mobilnej MFA. Bardziej pragmatyczne jest wprowadzenie choćby prostego podziału polityk na „urządzenia firmowe” i „inne”, z różnym zakresem uprawnień.

Jak SASE zmienia codzienność rozproszonej firmy – scenariusze użycia

Praca zdalna i hybrydowa: jeden model dla „z domu” i „z biura”

Najbardziej widoczna zmiana pojawia się tam, gdzie dziś królują klasyczne VPN-y i reguły firewalli szyte pod adresy IP biur. SASE umożliwia opisanie polityki w języku, który rozumie biznes: „pracownik działu X z urządzenia firmowego może korzystać z aplikacji Y z dowolnego miejsca, z dodatkowymi kontrolami przy dostępie spoza kraju”.

Codzienność użytkownika wygląda inaczej:

• nie „włącza VPN-a”, tylko loguje się do klienta SASE (lub agent działa w tle), a dostęp do aplikacji pojawia się na podstawie tożsamości;
• nie doświadcza skoków opóźnień przy przełączaniu między siecią domową a LTE – ruch zawsze trafia do najbliższego POP-u;
• ma te same zasady korzystania z Internetu (blokady kategorii, DLP) w biurze i poza nim.

Po stronie IT znika codzienna gra w „przydziel nowe adresy VPN, dodaj do ACL na firewallu, sprawdź, czemu tunel się nie zestawił”. Zamiast tego pojawia się jeden zestaw polityk opisujących relacje: użytkownik – urządzenie – aplikacja.

Oddziały „bez IT na miejscu”: proste pudełko zamiast małej serwerowni

W tradycyjnym podejściu każdy oddział ma swój router, często lokalny firewall, czasem serwer AD, DNS, proxy. Im więcej lokalizacji, tym większa „kolekcja mini-data-center”, które trzeba aktualizować, monitorować i naprawiać.

Model SASE pozwala zredukować to do minimum:

• proste urządzenie brzegowe (lub nawet router operatora z poprawnie ustawionym tunelem) kieruje cały ruch do POP-u SASE;
• lokalne serwery znikają lub są zastępowane usługami z chmury (DNS, katalog, drukowanie);
• cała logika bezpieczeństwa i routingu przesuwa się do chmury, z centralnym zarządzaniem.

Popularna obietnica „zlikwidujesz wszystkie firewalle w oddziałach w trzy miesiące” jest realna tylko dla organizacji, które nie mają w tych lokalizacjach złożonych aplikacji lokalnych, systemów OT czy wymagań prawnych dotyczących lokalnego przetwarzania danych. W fabryce z maszynami sterowanymi przez SCADA sensowniejsze bywa pozostawienie segmentu OT lokalnie, z prostym połączeniem SASE tylko do ruchu „biurowego”.

Bezpieczny dostęp do aplikacji w wielu chmurach

Gdy aplikacje lądują w AWS, Azure, GCP i prywatnej chmurze, tradycyjna siatka VPN-ów robi się nie do utrzymania. SASE może pełnić rolę wspólnego „szkieletu” dostępu, niezależnie od chmury.

Typowa ewolucja wygląda tak:

1. lokalne firewalle i VPN-y w każdej chmurze łączą się site-to-site z data center;
2. po migracji do SASE, VPC/VNet-y są podpinane do sieci dostawcy jako kolejne „lokalizacje”;
3. dostęp użytkowników (ZTNA) i połączenia między chmurami przechodzą przez wspólną warstwę polityk.

Dobrą praktyką jest nie przenosić do SASE wszystkiego naraz. Krytyczne usługi (np. systemy finansowe) można zostawić początkowo na dotychczasowych tunelach, a do warstwy SASE wprowadzać mniej wrażliwe aplikacje i ruch między nimi. Pozwala to przetestować wydajność POP-ów, stabilność integracji i model operacyjny bez narażania rdzenia biznesu.

Kontrola nad danymi w ruchu i w chmurach SaaS

Rozproszenie pracy i przejście na SaaS uwidaczniają problem: dane firmowe zaczynają żyć w dziesiątkach usług, do których dostęp jest z różnych lokalizacji i urządzeń. SASE zintegrowane z DLP i CASB może pomóc uporządkować ten chaos.

Przykładowy, realistyczny scenariusz:

• pracownik eksportuje raport z systemu finansowego do pliku i próbuje wrzucić go na prywatny dysk w chmurze z laptopa domowego;
• SWG/CASB widzi, że chodzi o wrażliwe dane (reguła DLP) i że celem jest niesankcjonowany serwis;
• polityka na poziomie SASE blokuje wysyłkę lub wymusza zaszyfrowanie pliku i zapis w służbowej przestrzeni.

Tego typu kontrola bywa przeceniana w materiałach marketingowych – sama technologia nie rozwiąże bałaganu w klasyfikacji informacji. Bez sensownego podziału dokumentów (np. „publiczne”, „wewnętrzne”, „poufne”) i zaangażowania biznesu DLP zamienia się w źródło fałszywych alarmów. SASE ułatwia egzekwowanie zasad, ale nie zastąpi ich zdefiniowania.

Ujednolicenie widoczności i reagowania na incydenty

Rozproszona firma, która korzysta z kilku produktów bezpieczeństwa SaaS, prędzej czy później tonie w logach z różnych portali. Jedną z praktycznych korzyści SASE jest spójny obraz aktywności użytkownika i urządzenia, niezależnie od sposobu połączenia.

W dojrzałych wdrożeniach SOC dostaje nie tylko strumień logów z SASE do SIEM, lecz także:

• korelację zdarzeń: „użytkownik loguje się z nowej lokalizacji, pobiera nietypową ilość danych z SaaS, a następnie próbuje przesłać je na zewnętrzny serwis”;
• możliwość reakcji z jednego miejsca: blokada konta, odcięcie sesji, wymuszenie reautentykacji lub podniesienie wymogów MFA;
• informację o stanie urządzenia w momencie incydentu.

Popularny błąd to traktowanie SASE jako „kolejnego źródła logów”, bez przeprojektowania procesu reagowania. Zespół bezpieczeństwa nadal pracuje w starym modelu, a potencjał centralnej warstwy kontroli pozostaje niewykorzystany. Rozsądniej jest od razu zaplanować, które akcje i scenariusze będą obsługiwane bezpośrednio z konsoli SASE, a które pozostaną w narzędziach typu EDR czy klasyczne SIEM/SOAR.

Popularne obietnice dostawców SASE – kiedy działają, a kiedy NIE

„Szybciej i taniej niż MPLS”

Porównanie SASE/SD-WAN z MPLS to klasyk sprzedażowy. Rzeczywiście, w wielu przypadkach zestawienie kilku łącz internetowych z inteligentnym routingiem daje niższy koszt za Mbps i lepszą elastyczność niż klasyczne MPLS.

Ta obietnica działa, gdy:

• obecne łącza MPLS są drogie, mało elastyczne i mają ograniczoną przepustowość;

„Jedna chmura bezpieczeństwa dla całego świata”

Hasło o „globalnej chmurze bezpieczeństwa” brzmi kusząco, szczególnie dla firm z wieloma krajami i strefami czasowymi. Rzeczywistość jest jednak bardziej prozaiczna: sieć POP-ów dostawcy bywa gęsta w USA czy Europie, a dużo rzadsza w Afryce, Azji Południowej czy Ameryce Łacińskiej.

Model globalnej chmury dobrze działa, gdy:

• kluczowe lokalizacje znajdują się w regionach dobrze pokrytych przez POP-y (krótkie „ogonki” sieciowe do najbliższego węzła);
• główne aplikacje mają swoje instancje w podobnych regionach (np. Office 365, Salesforce, ERP w chmurze publicznej w tym samym obszarze);
• nie ma ostrych wymogów lokalizacyjnych typu „dane nie mogą opuszczać kraju X lub regionu Y”.

Problemy zaczynają się tam, gdzie użytkownik w jednym kraju, POP w drugim, a aplikacja w trzecim. Nagle ruch, który lokalnie mógłby przejść „po prostej”, krąży między regionami. Zamiast marketingowej „optimum path” pojawiają się skargi na opóźnienia i wolno ładujące się aplikacje.

Zanim padnie decyzja o globalnym przełączeniu ruchu na SASE, warto przeprowadzić twardą analizę tras:

• zmierzyć faktyczny RTT użytkownik → POP → główne aplikacje SaaS/IaaS w kluczowych krajach;
• sprawdzić, gdzie ruch wychodzi do Internetu (lokalny breakout w kraju czy hairpinning przez inny region);
• zweryfikować, czy dostawca oferuje „data residency” i logikę przetwarzania danych w konkretnym regionie.

Jeśli regulacje wymuszają przetwarzanie w konkretnym państwie, jedyną rozsądną drogą czasem bywa model mieszany: SASE jako globalny szkielet plus lokalne komponenty zgodne z wymogami (np. prywatny POP w kraju, dodatkowe logowanie do krajowego SIEM). To komplikuje architekturę, ale bywa jedynym sposobem na pogodzenie bezpieczeństwa, wydajności i prawa.

„Zastąpi wszystkie Twoje VPN-y i firewalle”

Obietnica szczególnie atrakcyjna dla organizacji zmęczonych setkami tuneli i list ACL, na których nikt już się nie zna. Zastąpienie całego zoo VPN-ów i firewalli jednym SASE teoretycznie wygląda sensownie: jedno miejsce do zarządzania, jednolity model polityk, brak „prywatnych rozwiązań” w każdym oddziale.

To podejście bywa skuteczne, jeśli:

• większość ruchu to HTTP(S) do aplikacji webowych i SaaS, a usługi „legacy” stanowią mniejszą część;
• nie ma rozbudowanych konfiguracji typu dynamiczny routing wewnętrzny, multicast, specyficzne protokoły OT/IoT;
• dział sieci gotów jest przejść z „myślenia IP” na „myślenie o aplikacjach i tożsamości”.

Całkowita rezygnacja z klasycznych VPN-ów i firewalli nie sprawdzi się natomiast tam, gdzie funkcjonują:

• sieci przemysłowe z protokołami, których SASE nie rozumie i nie wspiera (lub wspiera bardzo powierzchownie);
• aplikacje oparte na niestandardowych protokołach, wymagające precyzyjnego kształtowania ruchu;
• segmenty o ekstremalnych wymaganiach dostępności, gdzie zależność od chmury dostawcy jest nie do przyjęcia.

Praktyczniejsza ścieżka niż „wycinamy wszystko” to podejście warstwowe:

1. Na SASE przenoszony jest ruch użytkownik ↔ aplikacje webowe i SaaS oraz proste połączenia site-to-site.
2. Na lokalnych firewallach zostają segmenty krytyczne i systemy specyficzne (OT, laboratoria, sprzęt medyczny itd.).
3. W miarę dojrzewania zespołu i technologii część tych segmentów może być przenoszona, jeśli pojawi się realna korzyść.

Zryw „od jutra zero VPN i firewalli” zwykle kończy się rollbackiem po pierwszym większym incydencie lub przestoju. Lepiej już na starcie przyjąć, że kilka starych rozwiązań zostanie „w rezerwie strategicznej” i będzie wygaszane dopiero wtedy, gdy organizacja nauczy się żyć i diagnozować problemy w nowym modelu.

„Zero Trust z pudełka”

Z marketingowego punktu widzenia Zero Trust i SASE idą dziś w parze. Sprzedawca pokazuje, jak jednym kliknięciem ograniczyć dostęp do aplikacji tylko dla określonej grupy użytkowników z zarządzanych urządzeń – wygląda to imponująco.

Taka obietnica ma sens, gdy spełnione są trzy warunki:

• tożsamość użytkowników jest już względnie uporządkowana (grupy w IdP, podstawowa higiena haseł i MFA);
• stan urządzenia jest widoczny (MDM/EDR, choćby w prostej formie: „zarządzony / niezarządzony”);
• aplikacje da się jednoznacznie zidentyfikować (FQDN, ścieżki URL, porty) i nie są przesadnie „spaghetti-architekturą”.

Jeśli tożsamość jest chaotyczna („wszyscy w grupie Domain Users mają prawie wszystko”), a urządzenia funkcjonują w stylu BYOD bez kontroli, to „Zero Trust” staje się tylko ładną nakładką na stary model. Dostawca SASE nie naprawi braku porządku w IdP ani rozlanego BYOD-a.

Zamiast kupować „pełne Zero Trust” w pierwszym etapie, rozsądniejszy jest prostszy cel: „mniej zaufania niż dotychczas”. Przykładowo:

• najpierw odcina się dostęp „z całego Internetu” do wybranych aplikacji, zostawiając wejście tylko przez ZTNA;
• następnie wprowadza się różnicowanie polityk dla urządzeń zarządzonych i niezależnych;
• dopiero później buduje się drobnoziarniste reguły per aplikacja, dział, typ danych.

Zero Trust w praktyce to nie „stan docelowy”, lecz kierunek, który wymaga kilku iteracji zmian organizacyjnych, nie tylko nowej konsoli.

„Jedna konsola uprości zarządzanie i zmniejszy koszty”

Konsolidacja narzędzi to jeden z głównych argumentów dostawców SASE. Z punktu widzenia zarządu brzmi logicznie: mniej licencji, mniej integracji, mniej ludzi do obsługi. Problem w tym, że realna krzywa uczenia się i zmiany procesów rzadko mieści się w slajdzie z ROI.

Jedna platforma upraszcza zarządzanie, gdy:

• zespół odpowiedzialny za sieć i bezpieczeństwo jest gotów współdzielić narzędzia i odpowiedzialności;
• integracje z obecnym ekosystemem (IdP, EDR, SIEM, ticketing) są zaplanowane i przetestowane, a nie „na później”;
• organizacja zaakceptuje, że część „ulubionych” funkcji z wyspecjalizowanych narzędzi zniknie lub będzie inaczej działać.

W przeciwnym scenariuszu powstaje hydra: oprócz SASE nadal działają stare systemy, bo ktoś „potrzebuje jednego konkretnego raportu tylko tam”. Zamiast konsolidacji jest dublowanie narzędzi i dodatkowe licencje.

Rozsądne podejście do uproszczenia obejmuje:

• listę funkcji krytycznych dla sieci i bezpieczeństwa, bez których zespół nie może pracować efektywnie;
• jasne decyzje, które narzędzia zostaną wygaszone w konkretnej dacie, po pełnym przejęciu ich roli przez SASE;
• okres przejściowy, w którym podwójny monitoring jest świadomym wyborem, a nie niekontrolowanym efektem migracji.

Z perspektywy kosztów kapitałowych (sprzęt, utrzymanie lokalnych urządzeń) SASE często się broni. Koszty ludzkie i procesowe maleją jednak wolniej i wymagają świadomego „oduczenia się” starych sposobów pracy.

Architektura SASE krok po kroku – jak to ułożyć bez rewolucji

Diagnoza stanu wyjściowego: co naprawdę ma znaczenie

Zanim pojawi się pierwsza linijka konfiguracji SASE, przydaje się trzeźwe spojrzenie na obecny stan. Zamiast próbować opisać całą sieć i wszystkie wyjątki, lepiej skupić się na kilku krytycznych obszarach:

• mapa aplikacji biznesowych – kto z czego korzysta, skąd i w jaki sposób (VPN, bezpośredni dostęp, terminale, aplikacje webowe);
• główne przepływy ruchu – użytkownicy ↔ DC, użytkownicy ↔ SaaS, oddziały ↔ oddziały, integracje B2B;
• lokalizacje i profile użytkowników – duże biura, małe oddziały, pracownicy terenowi, kontraktorzy;
• kluczowe ograniczenia – regulacje, wymogi klientów, integracje z systemami legacy.

Na tej podstawie można zdefiniować prostą klasyfikację:

• co musi być obsłużone w pierwszej kolejności (np. dostęp pracowników do CRM i ERP);
• co może wejść w kolejnym etapie (np. ruch między chmurami, mniej krytyczne aplikacje);
• co zostanie celowo poza SASE lub tylko częściowo (np. sieci OT, środowiska testowe o specyficznych wymaganiach).

Takie cięcie redukuje presję „migrujemy wszystko” i ułatwia późniejsze podejmowanie decyzji o kompromisach.

Model tożsamości i urządzeń jako fundament

Architektura SASE oparta na IP i sieciach lokalnych to powrót do starego świata w nowych szatach. Trwałe rozwiązanie musi bazować na tożsamości i stanie urządzenia. Tu wygodniej myśleć w odwrotnej kolejności niż klasycznie.

Najpierw warto uporządkować:

1. IdP i grupy – ograniczyć liczbę „historycznych” grup, zbudować kilka sensownych wymiarów: dział, rola, poziom uprzywilejowania, typ użytkownika (pracownik, kontraktor, partner);
2. politykę urządzeń – zdefiniować, co oznacza „urządzenie zarządzane”, jakie minimalne kryteria musi spełniać (szyfrowanie dysku, EDR, aktualizacje);
3. model atrybutów – ustalić, które informacje o użytkowniku i urządzeniu będą realnie używane w politykach SASE.

Dopiero na tym szkielecie ma sens projektowanie konkretnych zasad dostępu, np.: „pracownicy działu sprzedaży z urządzeń zarządzanych mają pełny dostęp do CRM, z niezarządzanych – tylko w trybie przeglądania”.

Warstwowe projektowanie polityk: od „grubego ziarna” do detali

Pokusą przy wdrożeniu nowej platformy jest tworzenie bardzo szczegółowych reguł od samego początku. Zwykle kończy się to labiryntem wyjątków, którego nikt nie rozumie po pół roku. Lepszą strategią jest podejście warstwowe:

• Warstwa 1 – polityki globalne (dla całej organizacji): zasady typu „blokujemy kategorie wysokiego ryzyka” w SWG, „wymagamy MFA spoza zaufanych lokalizacji”, „ruch do krytycznych aplikacji tylko przez ZTNA”.
• Warstwa 2 – polityki per segment biznesowy: różne wymagania dla finansów, HR, IT, produkcji; inaczej traktowani kontraktorzy niż pracownicy.
• Warstwa 3 – polityki per aplikacja / grupa aplikacji: zasady szczególne tylko tam, gdzie jest realna potrzeba (np. system płac, dokumenty M&A, kluczowe systemy produkcyjne).

W pierwszym wydaniu sensowne jest utrzymanie polityk w stylu „grubego pędzla” i doprecyzowywanie ich na podstawie realnych incydentów i zgłoszeń biznesu, zamiast wyobrażonych scenariuszy.

Podłączanie lokalizacji i chmur – kolejność ma znaczenie

Decyzja, co podłączyć do SASE najpierw, mocno wpływa na percepcję całego projektu. Jeśli na start trafią najbardziej wrażliwe systemy, każdy drobny problem zostanie zapamiętany na lata.

Sensowna kolejność często wygląda następująco:

1. Pilotaż na wybranej grupie użytkowników z różnych lokalizacji – np. dział IT lub zespół sprzedaży, który intensywnie korzysta z SaaS. Tu skupienie na ZTNA i SWG.
2. Podłączenie wybranych VPC/VNet z mniej krytycznymi aplikacjami – np. systemy wsparcia, narzędzia marketingowe, aplikacje wewnętrzne o niskiej wrażliwości.
3. Stopniowe włączanie większych oddziałów, zaczynając od tych z prostszą infrastrukturą lokalną (bez OT, bez lokalnych serwerowni).
4. Migracja krytycznych usług dopiero po zebraniu doświadczeń, z równoległym utrzymaniem dotychczasowych dróg dostępu przez pewien czas.

Przy każdej fali migracji warto zadbać o bardzo proste, ale jasne kryteria sukcesu: opóźnienia, dostępność, liczba zgłoszeń, poziom zadowolenia użytkowników. Bez tego kolejne kroki stają się subiektywną dyskusją „działa / nie działa”.

Integracje z SOC, SIEM i EDR – nie traktować SASE w izolacji

SASE często wchodzi do organizacji jako „projekt sieciowy”, a potem nagle okazuje się, że zmienia on także sposób pracy zespołów bezpieczeństwa. W architekturze rozsądnie jest na początku uwzględnić trzy typy integracji:

• logiczna integracja z IdP i HR – aby zmiany w zatrudnieniu i rolach automatycznie wpływały na zasady dostępu;
• techniczna integracja z EDR/MDM – stan urządzenia jako element polityki, a nie tylko informacja w raporcie;
• operacyjna integracja z SOC/SIEM – jasne zasady, kto i kiedy reaguje w konsoli SASE, a kiedy w EDR czy SOAR.

Kluczowe Wnioski

• Klasyczny model „oddział → MPLS → data center → internet” załamał się przy pracy zdalnej, SaaS i chmurze publicznej – ruch idzie dziś „wszędzie do wszystkiego”, więc wymuszanie przejścia przez centralne data center generuje opóźnienia, koszty i luki w zabezpieczeniach.
• Łatanie architektury kolejnymi modułami (MPLS, osobny VPN, osobne firewalle, proxy, CASB, bramki do chmury) działa tylko na początku; po kilku latach powstaje patchwork, w którym trudno utrzymać spójne polityki, prześledzić ścieżkę użytkownika i szybko wdrożyć nowe lokalizacje.
• Model „więcej pudełek = więcej bezpieczeństwa” przestaje działać, gdy organizacja rośnie i się rozprasza – każde nowe pudełko zwiększa złożoność, mnoży punkty konfiguracji i utrzymania, a finalnie obniża realną kontrolę nad ruchem.
• SASE zakłada odejście od myślenia w kategoriach fizycznych tras między lokalizacjami na rzecz logicznego, kontrolowanego dostępu „użytkownik → aplikacja”, niezależnie od tego, skąd ktoś się łączy i gdzie działa dana usługa (SaaS, chmura, data center).
• SASE spina funkcje sieciowe (np. SD-WAN) i bezpieczeństwa (SWG, CASB, FWaaS, ZTNA) w jedną warstwę polityk, świadczoną z chmury możliwie blisko użytkownika – zamiast kaskady rozproszonych narzędzi pojawia się jedno, spójne miejsce egzekwowania zasad.

Opracowano na podstawie

• The Future of Network Security Is in the Cloud. Gartner (2019) – Raport wprowadzający i definiujący koncepcję SASE
• Market Guide for Zero Trust Network Access. Gartner (2023) – Charakterystyka ZTNA jako jednego z komponentów SASE
• SD-WAN 101: A Primer on Software-Defined Wide Area Networking. Cisco Systems (2020) – Podstawy SD-WAN i jego rola w modernizacji sieci WAN
• Secure Web Gateway (SWG) Explained. Zscaler (2021) – Opis funkcji SWG i jej miejsca w architekturze SASE