Secure Access Service Edge (SASE)

Model architektury łączący sieć (SD-WAN) i bezpieczeństwo (SWG, CASB, ZTNA, FWaaS) w jedną usługę z chmury, z dostępem opartym na tożsamości i Zero Trust.

SASE (Secure Access Service Edge) to model architektury IT, w którym funkcje sieciowe i funkcje bezpieczeństwa łączy się w jedną usługę dostarczaną z chmury. Usługa działa na brzegu sieci (edge), blisko użytkownika lub urządzenia. Zamiast prowadzić cały ruch przez centralę firmy, SASE sprawdza go i stosuje reguły w wielu rozproszonych punktach dostawcy. O dostępie decyduje tożsamość użytkownika i kontekst, a nie to, gdzie znajduje się on w sieci.

Czym jest SASE?

Nazwę SASE wprowadziła firma analityczna Gartner w 2019 roku, w raporcie „The Future of Network Security Is in the Cloud”. Opisuje ona połączenie dwóch obszarów, które wcześniej rozwijały się osobno: rozległych sieci sterowanych programowo (SD-WAN) oraz usług bezpieczeństwa sieci dostarczanych z chmury.

SASE jest odpowiedzią na prosty fakt. Dawniej zasoby, użytkownicy i zabezpieczenia mieściły się wewnątrz firmowego „perymetru” — czyli granicy sieci, którą firma w całości kontrolowała. Dziś aplikacje są w chmurze, a ludzie pracują zdalnie. Stary model przestał do tego pasować.

Najważniejsza zmiana to odejście od backhaulingu. Backhauling to zawracanie ruchu zdalnych pracowników i oddziałów z powrotem do centralnego data center tylko po to, by przepuścić go przez tamtejsze zabezpieczenia. W modelu SASE sprawdzanie ruchu i egzekwowanie reguł dzieje się w najbliższym węźle dostawcy. O dostępie decyduje tożsamość użytkownika lub urządzenia — zgodnie z zasadą Zero Trust („nigdy nie ufaj, zawsze weryfikuj”).

Z jakich komponentów składa się SASE?

SASE to nie jeden produkt, lecz kilka technologii zarządzanych z jednego miejsca. Dzieli się je zwykle na warstwę sieciową i warstwę bezpieczeństwa.

SD-WAN — warstwa sieciowa

SD-WAN (Software-Defined Wide Area Network, czyli rozległa sieć sterowana programowo) odpowiada za rozsądne kierowanie ruchem między oddziałami, użytkownikami a aplikacjami. Wybiera najlepszą trasę na bieżąco, potrafi łączyć różne łącza (MPLS, łącza internetowe, LTE/5G) i prowadzić ruch wprost do aplikacji w chmurze, zamiast zawracać go przez centralę. To sieciowy fundament, na którym opierają się usługi bezpieczeństwa SASE.

SWG — Secure Web Gateway

SWG (Secure Web Gateway, brama bezpiecznego dostępu do sieci) sprawdza ruch internetowy użytkowników. Filtruje adresy stron i kategorie treści, blokuje znane złośliwe domeny i pilnuje zasad korzystania z internetu. Ważnym elementem jest sprawdzanie ruchu szyfrowanego (TLS/SSL). Dziś większość ruchu jest zaszyfrowana — w tym kanały, którymi rozsyła się złośliwe oprogramowanie. Bez odszyfrowania ten ruch pozostaje dla zabezpieczeń nieczytelny.

CASB — Cloud Access Security Broker

CASB (Cloud Access Security Broker, pośrednik bezpieczeństwa dostępu do chmury) stoi między użytkownikami a aplikacjami chmurowymi (SaaS). Pokazuje, z jakich usług naprawdę korzysta firma — w tym z tzw. shadow IT, czyli aplikacji używanych bez wiedzy działu IT. CASB egzekwuje reguły dostępu do chmury, wykrywa ryzykowne ustawienia i realizuje funkcje DLP (Data Loss Prevention, ochrona przed wyciekiem danych), ograniczając wyciek danych wrażliwych przez chmurę.

ZTNA — Zero Trust Network Access

ZTNA (Zero Trust Network Access, dostęp do sieci w modelu zerowego zaufania) daje dostęp do konkretnych aplikacji według zasady „nigdy nie ufaj, zawsze weryfikuj”. Klasyczny VPN wpuszcza użytkownika do całej sieci. ZTNA działa inaczej: przyznaje dostęp do pojedynczej aplikacji i tylko na czas sesji, po sprawdzeniu tożsamości oraz kontekstu (kto, z jakiego urządzenia, skąd). Aplikacje pozostają niewidoczne dla osób nieuprawnionych — nie są wystawione pod publicznym adresem. Dzięki temu napastnik ma mniej celów do zaatakowania i trudniej mu poruszać się po sieci.

FWaaS — Firewall as a Service

FWaaS (Firewall as a Service, zapora sieciowa jako usługa) to firewall dostarczany z chmury. Filtruje i kontroluje ruch na warstwach od L3 do L7. Przejmuje zadania tradycyjnych firewalli sprzętowych — kontrolę portów i protokołów, sprawdzanie aplikacji, ochronę IPS (systemy zapobiegania włamaniom) — ale jako usługa, którą łatwo skalować i którą zarządza się jednolicie. Nie trzeba utrzymywać urządzeń w każdej lokalizacji.

Centralne zarządzanie

Tym, co spaja SASE, jest jedno miejsce zarządzania. Z niego ustala się reguły, które obowiązują tak samo wszystkich użytkowników i wszystkie lokalizacje — niezależnie od tego, skąd ktoś się łączy. Daje to jeden, spójny widok na ruch i usuwa problem rozjeżdżających się ustawień między osobno konfigurowanymi urządzeniami.

Dlaczego powstało SASE?

Bezpośrednim powodem był rozpad modelu „perymetru”. Złożyło się na to kilka trendów naraz:

  • Praca hybrydowa i zdalna — ludzie łączą się z dowolnego miejsca i nie siedzą już za firmową zaporą.
  • Przejście do chmury — aplikacje i dane przeniosły się do SaaS i chmur publicznych, więc ruch nie krąży już wokół firmowego data center.
  • Rozproszeni użytkownicy i urządzenia — oddziały, urządzenia mobilne i IoT generują ruch, którego zawracanie do centrali jest nieopłacalne.
  • Nieefektywność backhaulingu — prowadzenie ruchu chmurowego przez centralę zwiększa opóźnienia i koszty łączy, a nie daje już realnej korzyści dla bezpieczeństwa.

Jakie korzyści daje SASE?

  • Konsolidacja — kilka funkcji (sieć, SWG, CASB, ZTNA, FWaaS) zastępuje zbiór osobnych produktów od różnych dostawców.
  • Mniejsza złożoność i koszty — mniej urządzeń do utrzymania, mniej konsol, a często niższe koszty łączy dzięki odejściu od MPLS i backhaulingu.
  • Zero Trust w praktyce — dostęp oparty na tożsamości i kontekście, sprawdzany na każdą sesję, zamiast domyślnego zaufania wewnątrz sieci.
  • Jeden widok i jedne reguły — spójne zasady i wgląd w ruch wszystkich użytkowników z jednego miejsca.
  • Wydajność — sprawdzanie ruchu blisko użytkownika i krótsze trasy do aplikacji zmniejszają opóźnienia w porównaniu z backhaulingiem.

Czym różni się SASE od SSE?

To jedno z najczęstszych źródeł nieporozumień. SSE (Security Service Edge) to wyodrębniony przez Gartnera w 2021 roku podzbiór SASE. Obejmuje tylko warstwę bezpieczeństwa dostarczaną z chmury — bez części sieciowej.

  • SSE = SWG + CASB + ZTNA (oraz zwykle FWaaS). To „połowa bezpieczeństwa” SASE.
  • SASE = SSE + SD-WAN. Czyli warstwa bezpieczeństwa plus warstwa sieciowa, połączone i zarządzane razem.

W praktyce wiele firm zaczyna od wdrożenia SSE, bo bezpieczny dostęp do chmury i aplikacji jest najpilniejszy. Komponent SD-WAN dokłada później, dochodząc do pełnego SASE. Gartner wprowadził SSE właśnie dlatego, że sieć i bezpieczeństwo często obsługują różni dostawcy i różne zespoły. Rozdzielenie tych warstw odzwierciedla realne ścieżki zakupowe.

Czym różni się SASE od MPLS i tradycyjnych sieci?

MPLS to technologia łączy operatorskich, która gwarantuje pasmo i jakość. Zwykle używano jej, by połączyć oddziały z centralą i data center. W modelu sprzed SASE ruch oddziałów płynął przez MPLS do centrali, gdzie stały zabezpieczenia.

  • MPLS: stałe, drogie łącza punkt-punkt; ruch chmurowy zawracany przez centralę (backhauling); skalowanie kosztowne i wolne.
  • SASE/SD-WAN: elastyczne korzystanie z dowolnych łączy (internet, LTE/5G, także MPLS); bezpośrednie trasy do aplikacji w chmurze; sprawdzanie ruchu w chmurze, blisko użytkownika.

SASE nie zawsze całkowicie usuwa MPLS. Częściej zmniejsza zależność od niego i traktuje je jako jedno z łączy w SD-WAN — zwłaszcza tam, gdzie potrzebne są gwarancje jakości.

Czym różni się SASE od VPN?

Klasyczny VPN tworzy szyfrowany tunel i — po zalogowaniu — wpuszcza użytkownika do fragmentu sieci firmowej, często z szerokim dostępem. ZTNA w ramach SASE działa inaczej. Udostępnia pojedyncze aplikacje, a nie całą sieć, sprawdza kontekst sesji i nie wystawia zasobów pod publicznym adresem. Z punktu widzenia bezpieczeństwa różnica jest duża. Przejęte konto VPN daje napastnikowi przyczółek w rozległej sieci i możliwość poruszania się po niej. ZTNA ogranicza zasięg do pojedynczych, dozwolonych aplikacji.

Jakie są zastosowania SASE?

  • Bezpieczna praca hybrydowa i zdalna — te same reguły i to samo sprawdzanie ruchu niezależnie od tego, skąd łączy się pracownik.
  • Łączność oddziałów — bezpieczny, bezpośredni dostęp oddziałów do aplikacji chmurowych, bez zawracania ruchu do centrali.
  • Migracja z MPLS — stopniowe zastępowanie drogich łączy operatorskich elastycznym SD-WAN.
  • Zasięg globalny — rozproszone punkty obecności dostawcy dają niskie opóźnienia użytkownikom w różnych regionach.
  • Zastąpienie VPN — ZTNA jako bezpieczniejsza alternatywa dla zdalnego dostępu opartego na tunelach.

Jakie są wyzwania wdrożeniowe SASE?

Wdrożenie SASE to projekt architektoniczny i organizacyjny, a nie sam zakup usługi:

  • Połączenie zespołów sieci i bezpieczeństwa — SASE łączy domeny, które w wielu firmach należą do osobnych zespołów o różnych priorytetach.
  • Migracja krok po kroku — rzadko da się przejść „na raz”; zwykle zaczyna się od ZTNA lub SSE, a SD-WAN dochodzi później.
  • Sprawdzanie ruchu TLS — odszyfrowanie ruchu jest potrzebne, by zabezpieczenia działały, ale rodzi pytania o wydajność, prywatność i wyjątki (np. ruch bankowy czy zdrowotny).
  • Uzależnienie od dostawcy — oddanie warstwy sieci i bezpieczeństwa jednemu dostawcy jest wygodne, ale zwiększa zależność.
  • Zasięg punktów obecności (PoP) — jakość zależy od tego, jak gęsto i gdzie dostawca ma swoje węzły względem użytkowników.

Jak wybrać dostawcę SASE: jeden czy wielu?

Jednym z głównych dylematów jest model dostawcy:

  • Single-vendor SASE — wszystkie komponenty (SD-WAN i cała warstwa bezpieczeństwa) pochodzą od jednego dostawcy i są zintegrowane natywnie. Zalety: spójne reguły, jedna konsola, prostsza obsługa. Wady: silniejsze uzależnienie i ryzyko, że nie każdy komponent jest najlepszy w swojej klasie.
  • Dual/multi-vendor SASE — np. SD-WAN od jednego dostawcy, SSE od innego. Zalety: dobór najlepszych komponentów, mniejsze uzależnienie. Wady: trudniejsza integracja, ryzyko niespójnych reguł i podzielonego widoku na ruch.

Przy wyborze warto ocenić: gęstość punktów obecności (PoP) w regionach, w których działa firma; głębię każdego komponentu, a nie tylko jego obecność „na liście”; jakość sprawdzania ruchu TLS i funkcji DLP; możliwość przekazywania telemetrii do własnych systemów; oraz model rozliczeń.

SASE z perspektywy cyberbezpieczeństwa — czego dostawcy nie mówią

Dla zespołu bezpieczeństwa SASE niesie realne korzyści: konsekwentnie wymusza Zero Trust, utrudnia poruszanie się po sieci (ZTNA nie wystawia całej sieci), zmniejsza liczbę celów ataku w porównaniu z publicznie dostępnymi bramami VPN i daje spójne reguły dla rozproszonych użytkowników.

Jest jednak skutek, który materiały dostawców zwykle pomijają: w architekturze SASE punkt obserwacji ruchu i zbierania telemetrii przesuwa się do chmury dostawcy. Sprawdzanie ruchu i zapisywanie zdarzeń dzieje się w infrastrukturze usługodawcy, a nie w sieci, którą firma w pełni kontroluje. Ma to praktyczne następstwa:

  • Przechowywanie i dostępność logów — zakres, format i czas przechowywania logów ruchu zależą od dostawcy i planu; własny SOC (centrum operacji bezpieczeństwa) może mieć ograniczony lub opóźniony dostęp do surowej telemetrii.
  • Wykrywanie we własnym SOC/NDR — systemy NDR (wykrywanie i reagowanie na poziomie sieci) oraz reguły wykrywania oparte na ruchu z firmowej sieci tracą część widoczności, gdy ruch jest sprawdzany i kończony u dostawcy. Trzeba wtedy zaplanować eksport logów i telemetrii do własnego systemu SIEM oraz sprawdzić, czy dostawca udostępnia dane w użytecznej rozdzielczości.
  • Zależność wykrywania od dostawcy — część skuteczności wykrywania przechodzi na stronę usługodawcy. Warto ująć to w modelu ryzyka i w wymaganiach umowy.

To nie argument przeciw SASE, lecz przypomnienie, że ta decyzja ma też wymiar operacji bezpieczeństwa. Trzeba świadomie zaplanować, gdzie powstają logi, kto je przechowuje i jak trafiają do własnych narzędzi wykrywania i reagowania.

Dowiedz się więcej