Typowe środowisko wygląda dziś podobnie w wielu firmach: centrala, kilka mniejszych lokalizacji, pracownicy pracujący częściowo z domu, zestaw aplikacji SaaS i kilka systemów wewnętrznych, których nikt nie przeniesie do chmury.
Wszystko to musi być połączone. Ale nie każdy powinien dostać dostęp do całej sieci, nie każde łącze jest tak samo dobre, a mały oddział rzadko potrzebuje tego samego sprzętu co centrala.
W tej części cyklu patrzę na Sophos XGS nie jak na filtr ruchu, lecz jak na punkt, w którym spotykają się wszystkie ścieżki dostępu — i w którym można o nich zdecydować spójnie.
1. Najpierw sieć: strefy, VLAN-y i trasy
Zanim pojawi się jakakolwiek polityka bezpieczeństwa, musi istnieć topologia. XGS jest tu również elementem warstwy sieciowej: obsługuje interfejsy fizyczne i VLAN-y, strefy, routing statyczny i dynamiczny, policy routing, agregację łączy oraz podstawowe usługi typu DHCP czy przekazywanie zapytań DNS.
Nie będę tego rozwijać — to materiał na dokumentację, nie na artykuł. Warto natomiast zapamiętać konsekwencję: skoro strefy i trasy definiujemy w tym samym urządzeniu, w którym powstają reguły, decyzja o dostępie może uwzględniać jedno i drugie naraz. To rzadziej oczywiste, niż się wydaje — w architekturach, gdzie routing i bezpieczeństwo są rozdzielone między różne systemy, taka spójność wymaga dodatkowej pracy.
2. Site-to-site VPN: bezpiecznie połączyć sieci
Najstarszy i wciąż najczęściej używany scenariusz. Tunel IPsec lub SSL łączy dwie sieci tak, by zachowywały się jak jedna — z zachowaniem poufności transmisji przez Internet.
W praktyce spotykam trzy warianty: centrala ↔ oddział, firma ↔ środowisko chmurowe oraz połączenie z partnerem lub dostawcą. Ten ostatni bywa najbardziej niedoceniany pod względem ryzyka: tunel do zewnętrznej organizacji to jednocześnie ścieżka, którą incydent u partnera może dotrzeć do nas. Segmentacja po stronie tunelu jest tu równie ważna jak samo szyfrowanie.
3. Remote access: gdy użytkownik potrzebuje dostępu do sieci
Dla pracownika zdalnego XGS może udostępniać remote access VPN w wariancie IPsec i SSL, z klientem Sophos Connect po stronie stacji. Uwierzytelnienie może korzystać z poświadczeń, które organizacja już posiada, w tym z logowania jednokrotnego przez Microsoft Entra ID.
Dwa elementy, które warto tu potraktować jako standard, a nie dodatek:
- MFA — samo hasło przestało być wystarczającą przesłanką, że po drugiej stronie jest właściwa osoba;
- polityki oparte na użytkowniku — dostęp zdalny nie musi oznaczać takiego samego zakresu dla wszystkich, którzy się połączą.
4. VPN kontra ZTNA: sieć czy konkretna aplikacja?
To najważniejsze rozróżnienie w całym artykule, więc warto je postawić precyzyjnie.
VPN tworzy bezpieczną ścieżkę do sieci lub jej fragmentu. Po zestawieniu połączenia użytkownik znajduje się „wewnątrz” i widzi to, co dana część sieci zawiera — zwykle więcej niż jedną usługę, której faktycznie potrzebował.
ZTNA odwraca tę logikę. Publikuje konkretny zasób i ocenia dostęp do niego przy każdej próbie: kim jest użytkownik, z jakiego urządzenia korzysta i w jakim stanie jest to urządzenie. Efektem nie jest obecność w sieci, tylko ścieżka do jednej aplikacji.
Sophos XGS może pełnić rolę platformy hostującej bramę ZTNA, zarządzaną z poziomu Sophos Central. Dzięki temu funkcja nie wymaga osobnego urządzenia w lokalizacji.
Nie napiszę, że ZTNA „zastępuje VPN” — bo w większości środowisk tak nie jest. Przenosi natomiast wybrane scenariusze z modelu dostępu sieciowego do modelu dostępu do aplikacji. I to zwykle właśnie te scenariusze, które dotyczą największej liczby osób: aplikacja kadrowa, system zgłoszeń, wewnętrzny portal, panel raportowy.
5. Tożsamość jako część polityki
Adres IP mówi, skąd pochodzi ruch. Nie mówi, kto go generuje — a to zwykle jest pytanie, które nas interesuje.
XGS potrafi wiązać politykę z użytkownikiem, korzystając ze źródeł tożsamości, które organizacja już utrzymuje: katalogu AD/LDAP, serwera RADIUS, logowania jednokrotnego przez Entra ID, agentów typu STAS/SATC czy Synchronized User ID tam, gdzie ten mechanizm jest adekwatny.
Różnica jest praktyczna, a nie kosmetyczna. Reguła oparta na tożsamości działa tak samo, gdy użytkownik pracuje z biura, z domu i z oddziału. Reguła oparta na adresacji wymaga utrzymywania osobnych wyjątków dla każdej z tych sytuacji — i to właśnie te wyjątki zwykle zostają w konfiguracji na lata.
6. SD-WAN: nie każde łącze jest takie samo
Organizacja, która ma dwa łącza, zwykle ma też pytanie: co dokładnie się stanie, gdy jedno z nich zacznie działać gorzej. Nie „padnie” — z tym radzi sobie prosty failover — tylko właśnie zacznie działać gorzej: wzrośnie opóźnienie, pojawią się straty pakietów, rozmowy zaczną się rwać, a sesje do systemu ERP zrywać.
SD-WAN w Sophos Firewall pozwala opisać to jako regułę. Profile tras, testy jakości łącza i progi SLA decydują o tym, którą drogą pójdzie dany typ ruchu — z możliwością przeniesienia wybranych aplikacji na łącze zapasowe, a mniej wrażliwych zostawienia tam, gdzie są.
Istotne, że jest to decyzja podejmowana w tym samym miejscu co polityka bezpieczeństwa. Transport i ochrona nie rozjeżdżają się na dwa różne systemy z dwiema różnymi listami wyjątków.
7. SD-RED: oddział bez lokalnego firewalla klasy enterprise
Sklep, magazyn, punkt sprzedaży, mała filia z kilkoma stanowiskami. Postawienie tam pełnego firewalla bywa nieproporcjonalne — kosztowo i operacyjnie, bo ktoś musiałby tym urządzeniem zarządzać.
SD-RED tworzy bezpieczne przedłużenie sieci centrali do takiej lokalizacji i może być zarządzany z poziomu Sophos Firewall. W praktyce oznacza to, że polityka pozostaje w jednym miejscu, a w oddziale znajduje się urządzenie, którego uruchomienie nie wymaga obecności administratora.
8. High Availability: firewall też bywa pojedynczym punktem awarii
Im więcej ról pełni firewall, tym poważniejsze konsekwencje ma jego niedostępność. Jeśli przez to samo urządzenie przechodzi dostęp do Internetu, ruch między segmentami, VPN oddziałów i publikacja aplikacji — jego awaria zatrzymuje wszystko naraz.
Sophos Firewall obsługuje HA w wariancie Active-Passive i Active-Active. Nie będę tu wchodzić w wymagania sprzętowe ani szczegóły konfiguracji; ważniejsze jest rozróżnienie pojęć, które bywają mylone:
- redundancja łączy odpowiada na awarię operatora,
- HA firewalla odpowiada na awarię urządzenia.
To dwa różne problemy. Rozwiązanie jednego nie rozwiązuje drugiego.
9. Jeden punkt łączności, wiele sposobów dostępu
Zamiast podsumowania — trzy sytuacje i trzy różne odpowiedzi:
- Pracownik zdalny potrzebuje aplikacji kadrowej. Nie potrzebuje sieci. Naturalnym wyborem jest ZTNA.
- Administrator potrzebuje dostępu do sieci technicznej. Tu zakres jest szerszy z natury rzeczy — VPN z MFA i wyraźnie ograniczonym zasięgiem.
- Mały oddział potrzebuje centrali i Internetu. SD-RED dla łączności, SD-WAN dla jakości trasy.
Dobre rozwiązanie dostępu nie zaczyna się od pytania „VPN czy ZTNA?”. Zaczyna się od pytania: kto potrzebuje dostępu, do czego, z jakiego urządzenia — i jak dużo sieci naprawdę musi zobaczyć.
Źródła
- Sophos Firewall 22.0 — Remote connectivity
- Sophos Firewall 22.0 — Sophos Connect
- Sophos Firewall 22.0 — Integrate firewall with ZTNA
- Sophos Firewall 22.0 — Licensing info
Informacje zależne od wersji SFOS, licencji lub konkretnego modelu sprzętowego wymagają ponownej weryfikacji przed publikacją.