Zero trust jako standard przyszłości jak przygotować infrastrukturę już dziś

Dlaczego zero trust staje się standardem przyszłości

Koniec ery „bezpiecznej sieci wewnętrznej”

Model, w którym wszystko, co jest „w środku sieci firmowej”, uznawane jest za bezpieczne, przestał działać. Praca zdalna, usługi SaaS, aplikacje w chmurze i stała współpraca z partnerami sprawiają, że granica między „wewnątrz” a „na zewnątrz” praktycznie zniknęła. Użytkownicy logują się do systemów z domu, z telefonu, z sieci hotelowej albo z prywatnego laptopa. Z punktu widzenia starej architektury to ciągła dziura w murze, którą próbuje się łatać kolejnymi tunelami VPN i wyjątkami w firewallach.

Kiedyś wystarczyło zbudować solidny perymetr: firewalle, filtry, IPS, a w środku założyć, że każdy host i użytkownik są mniej więcej godni zaufania. Dziś taki model powoduje, że jeden skuteczny atak na konto lub stację roboczą otwiera drogę do całej sieci. Atakujący, który „przeskoczy” do wnętrza, może swobodnie poruszać się między serwerami, bo wiele organizacji ma jedną, dużą, płaską sieć, w której reguły są bardzo ogólne, a monitoring – szczątkowy.

Zero trust zakłada zupełnie inne podejście: sieć nie jest domyślnie bezpieczna. Każde żądanie dostępu jest traktowane jak potencjalnie wrogie, niezależnie od tego, czy pochodzi z biura, czy z internetu. Zaufanie nie wynika z lokalizacji IP, ale z kombinacji tożsamości, stanu urządzenia, kontekstu, ryzyka i historii zachowań.

Incydenty coraz częściej zaczynają się od przejęcia konta

Coraz mniej ataków polega na „przeskoczeniu” firewalla przy użyciu jakiegoś wymyślnego exploita. Atakujący szukają prostszej ścieżki: wyłudzają hasła, przejmują tokeny sesyjne, wykorzystują słabe procesy resetowania haseł, podszywają się pod serwisy, które mają słabe zabezpieczenia. Gdy tylko zdobędą działające konto, często mają w zasadzie „wejście główne” do środka.

Jeżeli infrastruktura opiera się na założeniu, że każdy, kto jest w środku sieci, ma szerokie uprawnienia, przejęcie pojedynczego konta może oznaczać katastrofę. Admin domeny, użytkownik z dostępem do serwera plików, sprzedawca z szerokim dostępem do CRM – to wszystko potencjalne punkty krytyczne, gdy brakuje segmentacji i zasady najmniejszych uprawnień.

Zero trust traktuje każde konto jako potencjalnie zagrożone. Zamiast dawać szeroki, stabilny dostęp, wprowadza mechanizmy ciągłej weryfikacji: MFA, kontrolę anomalii, ograniczone sesje, dynamiczne polityki. Zmniejsza się powierzchnia ataku – przejęcie jednego konta nie powinno dać możliwości „zwiedzania” całej infrastruktury.

Rozmycie granicy „wewnątrz” vs „na zewnątrz”

Przez lata bezpieczeństwo było projektowane wokół fizycznej sieci firmowej. Dziś aplikacje SaaS, środowiska IaaS/PaaS, mikroserwisy i integracje API tworzą krajobraz, którego nie da się „zamknąć w jednym budynku”. Użytkownicy korzystają z kilkunastu lub kilkudziesięciu usług spoza LAN, często z prywatnych urządzeń, a część krytycznych danych żyje w chmurze publicznej lub prywatnej.

W takim świecie pojęcie „naszej sieci” jest mocno umowne. Nawet jeśli istnieje centralne data center, znaczna część ruchu i tak omija klasyczne firewalle, trafiając bezpośrednio do chmurowych aplikacji. Próbą utrzymania starego modelu jest „wpuszczanie” ruchu do środka przez VPN, ale to w praktyce przywraca koncept dużej, płaskiej sieci – tylko że jeszcze trudniejszej do zapanowania.

Zero trust zakłada, że bezpieczeństwo nie opiera się na lokalizacji usług czy użytkowników. Granicą bezpieczeństwa staje się przede wszystkim tożsamość (użytkownika, urządzenia, usługi) oraz kontekst (skąd, kiedy, w jaki sposób i do czego jest żądany dostęp). Dzięki temu można projektować spójne zasady dla środowisk hybrydowych: on‑prem, chmura, SaaS, biuro, dom.

Presja regulatorów i dużych dostawców technologii

Regulatorzy (np. w sektorze finansowym, energetycznym, telekomunikacyjnym) coraz częściej oczekują, że organizacje pokażą nie tylko „mamy firewalla”, ale konkretnie: jak zarządzają tożsamością, jak ograniczają uprawnienia, jak monitorują dostęp do krytycznych systemów. W wielu wytycznych pojawiają się już wprost odwołania do zasad bliskich zero trust: kontrola tożsamości, segmentacja, ciągły monitoring.

Najwięksi dostawcy chmury i platform bezpieczeństwa również przesuwają ciężar z klasycznej ochrony sieci na ochronę tożsamości, aplikacji i danych. Usługi typu ZTNA, CASB, nowoczesne IdP, platformy do obserwowalności i analizy zachowań użytkowników to nie moda, tylko odpowiedź na realne zmiany w sposobie, w jaki pracują organizacje. To z kolei wpływa na oczekiwania klientów i partnerów – w wielu przetargach pojawiają się już wymagania powiązane z architekturą zero trust.

Zero trust jako kierunek, nie jednorazowa rewolucja

Największy lęk związany z zero trust dotyczy tego, że to „kolejna wielka rewolucja”, która wymusi wywrócenie całej infrastruktury do góry nogami. W praktyce dojście do dojrzałego modelu zero trust jest raczej podróżą w kilku falach niż jednorazowym projektem. Można zacząć od obszarów, które są najbardziej krytyczne lub najłatwiejsze do ogarnięcia, stopniowo poprawiając kolejne elementy.

Dobrze zaprojektowany plan migracji do zero trust minimalizuje przerwy w pracy biznesu. Sporo zmian można wdrażać warstwowo: najpierw lepsze IAM i MFA, potem restrykcyjniejsze role i segmentacja sieci, następnie nowe podejście do dostępu zdalnego i integracji. Kluczem jest zaakceptowanie faktu, że zero trust to model myślenia o bezpieczeństwie na lata, a nie pojedynczy projekt inwestycyjny.

Czym tak naprawdę jest zero trust – bez marketingu

Prosta definicja zero trust w języku biznesu

Zero trust to model bezpieczeństwa, który zakłada, że nikomu i niczemu nie ufa się domyślnie. Każdy dostęp jest przyznawany tylko w takim zakresie, jaki jest niezbędny, i tylko na tyle długo, na ile rzeczywiście potrzebny. Zaufanie nie jest stanem stałym, ale dynamiczną oceną ryzyka opartą na tożsamości, urządzeniu, lokalizacji, rodzaju żądania i historii zachowań.

W praktyce oznacza to, że pracownik, który chce dostać się do aplikacji HR, nie dostaje automatycznie dostępu do całej sieci biurowej tylko dlatego, że siedzi przy biurku w siedzibie firmy. Jego tożsamość musi zostać sprawdzona, urządzenie zweryfikowane, a dostęp uruchomiony w sposób możliwie izolowany – najlepiej bez możliwości „przeskakiwania” do innych systemów.

Trzy fundamenty: brak domyślnego zaufania, ciągła weryfikacja, minimalne uprawnienia

Można wyróżnić trzy podstawowe założenia, które od strony praktycznej definiują zero trust:

• Brak domyślnego zaufania – samo bycie „w sieci”, „na VPN‑ie” albo „w biurze” nie daje specjalnych praw. Lokalizacja nie jest wystarczającym kryterium do nadania dostępu.
• Ciągła weryfikacja – nie ma założenia, że raz uwierzytelniony użytkownik jest „bezpieczny” przez wiele godzin. Systemy mogą wymagać dodatkowych potwierdzeń (np. MFA) przy wrażliwych operacjach, zmianach kontekstu lub wykryciu anomalii.
• Zasada najmniejszych uprawnień – każdy użytkownik, urządzenie i aplikacja mają tylko te uprawnienia, które są absolutnie niezbędne do realizacji zadań. Dostępy są przydzielane w sposób granularny i, coraz częściej, na określony czas (just-in-time).

Te trzy zasady wydają się oczywiste, ale ich konsekwentne wdrożenie wymaga przebudowy wielu dotychczasowych przyzwyczajeń, procesów i decyzji technicznych. To właśnie dlatego zero trust bywa określany bardziej jako zmiana sposobu myślenia niż konkretna technologia.

Zero trust jako stan docelowy vs sposób projektowania

Można spotkać się z dwoma podejściami do zero trust. Pierwsze traktuje je jako stan docelowy: „kiedyś będziemy organizacją zero trust”. Drugie, bardziej praktyczne, definiuje zero trust jako metodę projektowania nowych systemów i stopniowej modernizacji starych.

W wersji praktycznej każdy nowy projekt IT jest oceniany pod kątem kilku kluczowych pytań:

• Jak identyfikujemy użytkownika, usługę i urządzenie?
• Jakie minimalne uprawnienia są potrzebne i jak je wymusimy?
• Jak monitorujemy i weryfikujemy zachowania w czasie trwania sesji?
• Jak łatwo możemy cofnąć dostęp i przeanalizować incydent?

Taki sposób myślenia pozwala uniknąć pułapki „zrobimy zero trust po migracji do chmury” czy „po wdrożeniu nowego ERP‑a”. Zamiast odkładać temat, integruje się zasady zero trust w bieżących planach rozwoju infrastruktury.

Najpopularniejsze mity: produkt, firewall nowej generacji, samo MFA

Rzeczywistość rozmija się często z marketingiem. Kilka mitów szczególnie utrudnia sensowną dyskusję o zero trust:

• „Zero trust to produkt” – żaden pojedynczy produkt nie uczyni organizacji „zero trust”. Potrzebna jest kombinacja zmian: w IAM, sieci, aplikacjach, procesach, monitoringu.
• „Zero trust to firewall nowej generacji” – nowoczesne firewalle i rozwiązania ZTNA są ważnym elementem, ale tylko jednym z wielu. Bez solidnej warstwy tożsamości, zarządzania urządzeniami i segmentacji, sam firewall niewiele zmieni.
• „Zero trust to po prostu MFA” – MFA jest kluczowym narzędziem, jednak nie rozwiązuje problemu zbyt szerokich uprawnień, braku segmentacji sieci czy braku monitoringu zachowań.

W praktyce zero trust jest zbiorem zasad, które mogą być wdrażane przy użyciu różnych technologii. To właśnie wybór konkretnych narzędzi, zgodnych z istniejącą infrastrukturą, decyduje, na ile przejście do zero trust będzie bolesne, a na ile płynne.

Jak zmienia się dostęp do prostej aplikacji HR

Przykład z życia: aplikacja HR dostępna wyłącznie z sieci firmowej. W starym modelu pracownik musi:

• być fizycznie w biurze albo połączony przez VPN,
• mieć konto w domenie lub aplikacji,
• znać adres URL aplikacji.

Po podłączeniu na VPN ma często dostęp do wielu innych zasobów: serwerów plików, drukarek, innych aplikacji, których nie potrzebuje do prostego sprawdzenia urlopu. Przejęcie jego laptopa lub danych logowania daje atakującemu szerokie możliwości poruszania się po sieci.

W modelu zero trust dostęp do HR może wyglądać inaczej:

• pracownik loguje się przez portal SSO,
• jest uwierzytelniony w IdP z MFA,
• dostęp do aplikacji HR jest przyznawany niezależnie od lokalizacji, na poziomie konkretnej aplikacji (ZTNA),
• połączenie jest tunelowane wyłącznie do HR, bez dostępu do reszty sieci,
• przy wrażliwych danych (np. dane wynagrodzeń) system może wymagać ponownego MFA lub działać tylko z urządzeń spełniających wymogi bezpieczeństwa.

Dla użytkownika różnica nie musi być duża – często jest wręcz wygodniej, bo odpada konieczność łączenia się z VPN. Dla bezpieczeństwa organizacji zmienia się jednak wszystko: nawet kompromitacja konta daje znacznie mniej możliwości atakującemu, a każdy dostęp jest lepiej śledzony.

Punkt startowy: diagnoza obecnej infrastruktury i ryzyk

Uczciwa analiza: z czego dziś „żyje” infrastruktura

Zanim pojawią się plany, roadmapy i projekty, trzeba zrozumieć, jak faktycznie działa obecna infrastruktura. Chodzi nie o idealny diagram, ale o praktyczną odpowiedź na kilka pytań:

• Jakie systemy są krytyczne dla bieżącego działania biznesu (ERP, CRM, produkcja, systemy księgowe, systemy sprzedaży, usługi klientowskie)?
• Które aplikacje są w praktyce nie do zastąpienia w najbliższym czasie (np. legacy, bez wsparcia producenta, ale kluczowe dla procesów)?
• Jakie integracje istnieją między systemami (API, wymiana plików, połączenia bazodanowe)?
• Gdzie leżą „wąskie gardła”, które w razie awarii zatrzymają biznes?

Nie chodzi o stworzenie perfekcyjnej dokumentacji w pół roku, lecz o złapanie realnego obrazu. Dobrym podejściem są krótkie sprinty inwentaryzacyjne – np. po 1–2 tygodnie na obszar (finanse, sprzedaż, produkcja, HR), które przynoszą listę kluczowych systemów i integracji, a nie 100‑stronicowy wykaz każdego skryptu.

Mapa danych, systemów i usług krytycznych

Zero trust wymaga priorytetyzacji – nie da się od razu „opanować wszystkiego”. Konieczna jest mapa krytycznych zasobów z perspektywy bezpieczeństwa i biznesu. W praktyce warto wyróżnić trzy grupy:

• Systemy i dane o najwyższej wrażliwości – dane osobowe (szczególnie wrażliwe), dane finansowe, systemy produkcyjne, systemy płatnicze, kluczowe bazy klientów.
• Systemy „nerwowe” organizacji – katalogi tożsamości, systemy pocztowe, platformy współpracy, systemy integracyjne (ESB, API gateway).

„Cisi bohaterowie”: systemy, o których wszyscy zapomnieli

Obok systemów opisanych w regulaminach i politykach funkcjonuje cała kategoria rozwiązań „historycznych”: serwery, aplikacje czy bazy danych, które „miały być wyłączone”, ale wciąż działają, bo ktoś coś z nich jeszcze wyciąga raz na kwartał. To właśnie one często stają się furtką dla atakującego.

Warto wprost założyć, że takie systemy istnieją i spróbować je „wyłapać” kilkoma prostymi metodami:

• analiza ruchu sieciowego – które serwery generują ruch, mimo że nikt nie potrafi jasno powiedzieć po co,
• przegląd harmonogramów zadań (Windows Task Scheduler, cron) na serwerach integracyjnych i bazodanowych,
• rozmowy z „ukrytymi administratorami” – osobami, które „od 10 lat ogarniają ten serwer, bo tak wyszło”.

Takie „ciche” systemy zwykle nie spełniają żadnych współczesnych standardów bezpieczeństwa, ale bywają kluczowe np. dla raportowania czy rozliczeń. Zero trust nie polega na ich natychmiastowym wyłączeniu, tylko na urealnieniu obrazu ryzyka i zaplanowaniu bezpiecznego „opakowania” lub migracji.

Ocena dojrzałości bezpieczeństwa: gdzie zero trust ma największy sens na start

Nie ma potrzeby odkrywać koła na nowo. Dobrą praktyką jest wykonanie uproszczonej oceny dojrzałości bezpieczeństwa z perspektywy obszarów krytycznych dla zero trust:

• Tożsamość i dostęp – jak wygląda obecnie uwierzytelnianie, reset haseł, nadawanie ról? Ile jest równoległych źródeł tożsamości (AD, LDAP, aplikacje SaaS z własnymi kontami)?
• Sieć – czy istnieje segmentacja (VLAN-y, strefy bezpieczeństwa), czy raczej jedna duża płaska sieć? Jak wygląda dostęp zdalny: klasyczny VPN, kilka różnych klientów VPN, czy częściowo ZTNA?
• Urządzenia końcowe – jak są zarządzane komputery, telefony, tablety? Czy jest MDM/EMM, czy „każdy ma swój laptop i antywirus”? Jak wygląda patch management?
• Monitoring i reagowanie – czy jest centralny system zbierania logów (SIEM), czy logi leżą na serwerach i nikt do nich nie zagląda? Jak szybko organizacja jest w stanie zareagować na incydent?

Celem nie jest uzyskanie wymarzonej oceny „poziom 4 na 5”, tylko wskazanie 2–3 pól, gdzie wdrożenie zasad zero trust da największy, odczuwalny efekt przy rozsądnym wysiłku. Dla jednych będzie to uporządkowanie tożsamości, dla innych – segmentacja sieci wokół systemów produkcyjnych.

Mapa przepływów: kto, skąd i do czego się łączy

Zero trust uderza w samą istotę dostępu. Żeby cokolwiek sensownie zaplanować, trzeba zrozumieć, jak naprawdę wyglądają przepływy w organizacji – nie tylko „teoretyczne”, ale też te faktycznie wykorzystywane na co dzień.

Pomagają tu proste ćwiczenia warsztatowe z wybranymi zespołami:

• przejście typowego dnia pracy użytkownika z konkretnej roli (np. handlowiec, księgowa, technolog produkcji) i zapisanie, do jakich systemów musi się logować i z jakich urządzeń,
• oznaczenie systemów, do których dostęp jest „awaryjnie” potrzebny kilku osobom (np. dostęp do serwera baz danych tylko dla analityka raz w miesiącu),
• zebranie informacji o nietypowych ścieżkach – np. łączenie się z domu na serwer terminali, a z niego dopiero do aplikacji, bo „kiedyś tak zrobiono i zostało”.

Tak powstaje realny obraz tego, na czym opiera się praca. Dzięki temu można później projektować polityki zero trust w sposób, który nie sparaliżuje biznesu pierwszego dnia.

Kluczowe filary zero trust i ich przełożenie na praktykę

Tożsamość: kto prosi o dostęp

Tożsamość jest pierwszym filarem, bo bez wiarygodnego potwierdzenia „kim jest proszący” reszta układanki nie ma sensu. Dotyczy to zarówno ludzi, jak i usług, kont technicznych czy integracji API.

W praktyce oznacza to kilka decyzji:

• wybór głównego źródła tożsamości (IdP / katalogu) i konsekwentne podpinanie pod nie kolejnych systemów,
• ograniczenie liczby lokalnych kont w aplikacjach i na serwerach – im ich mniej, tym łatwiej egzekwować zasady i reagować na incydenty,
• uporządkowanie procesów tworzenia, modyfikacji i usuwania kont – najlepiej powiązanych z HR i procesami kadrowymi.

Tożsamość w zero trust to nie tylko login i hasło. To również zestaw atrybutów: rola biznesowa, dział, lokalizacja, stan zatrudnienia, typ urządzenia, z którego korzysta użytkownik. To na nich opierają się później reguły dostępu warunkowego.

Urządzenie: z czego przychodzi żądanie

Drugi filar to urządzenie – laptop, telefon, terminal produkcyjny, maszyna IoT. Nawet najlepiej uwierzytelniony użytkownik nie jest bezpieczny, jeśli korzysta z niezaktualizowanego, zainfekowanego komputera.

Organizacja, która chce zbliżyć się do zero trust, musi umieć odpowiedzieć na kilka pytań:

• czy urządzenie jest znane i zarejestrowane (managed), czy traktowane jako gość (BYOD, urządzenie kontraktora),
• czy spełnia minimalne wymogi bezpieczeństwa – szyfrowanie dysku, aktualne łatki, działający agent bezpieczeństwa,
• czy urządzenie jest przypisane do konkretnej osoby, czy używane współdzielone (np. stanowiska call center, komputery na produkcji).

Na tej podstawie buduje się polityki: np. dostęp do systemu finansowo‑księgowego tylko z urządzeń spełniających określone kryteria, natomiast dostęp do intranetu – również z prywatnych telefonów, ale z ograniczeniami (brak możliwości pobrania plików, tylko dostęp przez przeglądarkę).

Aplikacja i usługa: co ma być dostępne

Trzecim filarem są aplikacje i usługi – systemy, do których zero trust ma ograniczyć zasięg dostępu. Chodzi zarówno o aplikacje webowe, systemy desktopowe, jak i API, bazy danych czy serwisy mikrousług.

W praktyce oznacza to przede wszystkim:

• przejście z myślenia „dostęp do sieci” na „dostęp do konkretnych aplikacji”,
• rozróżnianie poziomu wrażliwości aplikacji: inaczej traktuje się system kadrowo‑płacowy, a inaczej tablicę ogłoszeń w intranecie,
• w miarę możliwości „frontowanie” aplikacji przez centralne mechanizmy: reverse proxy, ZTNA, WAF, bramki API.

Dzięki temu coraz większą część decyzji o dostępie podejmuje centralna warstwa polityk, a nie lokalna konfiguracja w każdej aplikacji z osobna.

Dane: co jest naprawdę krytyczne

Zero trust nie kończy się na aplikacjach. W tle zawsze stoją konkretne dane – pliki, rekordy w bazach, dokumenty, logi. To one są celem atakującego, a ich wyciek lub zaszyfrowanie realnie boli biznes.

Przygotowując infrastrukturę, dobrze jest wykonać chociaż uproszczoną klasyfikację danych:

• dane publiczne – materiały marketingowe, treści na stronę WWW, instrukcje ogólne,
• dane wewnętrzne – dokumenty wewnętrzne, nieprzeznaczone do szerokiej dystrybucji, ale też nie krytyczne,
• dane wrażliwe / krytyczne – dane osobowe, finansowe, tajemnice handlowe, plany rozwoju produktów, dane produkcyjne.

Nie musi to być od razu ogromny projekt. Wystarczy, że dla kilku głównych repozytoriów (systemy plików, DMS, główne bazy) jest jasne, w której „szufladce” się znajdują. Później można do tego podłączyć odpowiednie polityki: mocniejsze MFA, brak dostępu z urządzeń prywatnych, dodatkowy monitoring dostępu.

Sieć i transport: jak żądanie dociera do zasobu

Sieć w zero trust przestaje być pasywnym „rurą”, a staje się aktywną warstwą kontroli. Chodzi o to, aby ruch między użytkownikiem, urządzeniem i aplikacją był możliwie precyzyjnie kontrolowany, zamiast wpuszczania kogoś szeroko do wnętrza sieci.

Podstawowe elementy to:

• segmentacja – dzielenie sieci na mniejsze strefy (VLAN, mikrosegmentacja), które ograniczają możliwość swobodnego poruszania się atakującego,
• szyfrowanie transportu – TLS wszędzie, gdzie to możliwe, a w sieciach wewnętrznych stopniowe odchodzenie od nieszyfrowanych protokołów,
• dostęp oparty na aplikacjach, nie adresach IP – ZTNA lub reverse proxy, które kontrolują ruch na poziomie aplikacyjnym, a nie tylko IP/port.

Dla wielu organizacji kluczowym krokiem jest odejście od założenia, że samo „bycie w sieci biurowej” oznacza wysoki poziom zaufania. Zero trust zakłada, że każda sieć – także wewnętrzna – jest potencjalnie wroga.

Widoczność i analiza: bez logów zero trust nie działa

Nawet najlepiej zaprojektowane polityki nie pomogą, jeśli nie da się sprawdzić, co faktycznie się dzieje. Ostatnim filarem jest więc widoczność – logi, telemetria, korelacja zdarzeń.

W kontekście zero trust kluczowe są:

• logi uwierzytelniania i autoryzacji z IdP, systemów SSO, bramek ZTNA,
• informacje o stanie urządzeń z systemów MDM/EDR,
• dzienniki dostępu do aplikacji i danych (kto, kiedy, do czego sięgał),
• mechanizmy korelacji i wykrywania anomalii (SIEM, UEBA).

Na początek wystarczy, że najważniejsze źródła logów trafiają w jedno miejsce i ktoś realnie na nie patrzy – choćby w formie prostych, predefiniowanych raportów i alertów. Z czasem można dołożyć automatyczne reakcje (np. blokadę konta przy wykryciu nietypowej aktywności).

Tożsamość w centrum: jak przygotować IAM, SSO, MFA i role

Porządkowanie źródeł tożsamości: jeden „punkt prawdy”

Zero trust rozpoczyna się w momencie uwierzytelnienia, więc pierwszym krokiem jest porządek w katalogach i systemach tożsamości. W wielu organizacjach funkcjonuje kilka równoległych „światów”: domena Windows, osobne konta w aplikacjach SaaS, lokalne bazy użytkowników w systemach legacy, osobne loginy do VPN.

Dobrym kierunkiem jest zdefiniowanie jednego systemu nadrzędnego (IdP) i wybranie kolejności integracji:

• najpierw systemy używane przez większość pracowników (poczta, portal intranetowy, kluczowe aplikacje biurowe),
• potem aplikacje krytyczne (finanse, produkcja),
• na końcu niszowe rozwiązania, o ile wciąż są niezbędne.

Każda kolejna integracja zmniejsza liczbę haseł i scenariuszy „zapomniałem loginu”. Równocześnie zwiększa się kontrola nad tym, kto faktycznie ma dostęp do jakich systemów.

IAM jako proces, nie tylko narzędzie

System IAM (Identity and Access Management) często bywa postrzegany jako duże, skomplikowane wdrożenie. W praktyce można zacząć od prostszej wersji, ale z dobrze przemyślanymi procesami.

Kluczowe są trzy obszary:

• prowizjonowanie – kto i na jakiej podstawie tworzy konto oraz nadaje dostęp? Idealnie, jeśli dane pochodzą bezpośrednio z systemu HR, a proces wymaga akceptacji przełożonego,
• deprowizjonowanie – jak szybko po odejściu pracownika lub zakończeniu umowy z kontraktorem odcinane są wszystkie dostępy, także do systemów SaaS i narzędzi zewnętrznych,
• przeglądy dostępów – cykliczne (np. kwartalne) zatwierdzanie list uprawnień przez właścicieli biznesowych systemów.

Te trzy elementy, nawet zrealizowane częściowo ręcznie na starcie, znacząco obniżają ryzyko „sierocych kont” i nadmiarowych uprawnień.

SSO: mniej haseł, więcej kontroli

Single Sign‑On często jest odbierane jako funkcja poprawiająca wygodę użytkowników. W kontekście zero trust jest jednak równie istotne dla bezpieczeństwa. Mniej miejsc do logowania oznacza mniejsze pole do nadużyć i prostszą analizę incydentów.

Praktyczne podejście:

• na początek objęcie SSO systemów najczęściej używanych – tak, aby użytkownik odczuł realną poprawę,
• stopniowe wyłączanie możliwości logowania lokalnego w aplikacjach, które zostały podłączone do SSO,
• wykorzystanie SSO jako miejsca egzekwowania polityk – np. warunkowego dostępu w zależności od lokalizacji czy typu urządzenia.

Dzięki temu część decyzji dotyczących dostępu przenosi się z pojedynczych aplikacji do centralnego IdP, co znacznie upraszcza całość.

MFA: jak wdrażać, żeby nie zrazić użytkowników

Wieloskładnikowe uwierzytelnianie (MFA) jest jedną z najskuteczniejszych barier przed przejęciem konta. Jednocześnie bywa odbierane jako uciążliwe, jeśli wdroży się je bez przygotowania.

Sprawdza się podejście etapowe:

• najpierw MFA dla kont uprzywilejowanych (administratorzy systemów, osoby z dostępem do danych krytycznych),

MFA kontekstowe i adaptacyjne

Po pierwszej fali wdrożenia MFA pojawia się naturalne pytanie: jak ograniczyć „klikanie w telefon” przy każdym logowaniu, a jednocześnie nie osłabić zabezpieczeń. Tu wchodzi MFA adaptacyjne – decyzja o wymaganiu drugiego czynnika zależy od kontekstu.

Najczęściej brane pod uwagę są:

• lokalizacja – inne zasady z sieci biurowej, inne z internetu publicznego,
• urządzenie – zaufane, zarządzane przez firmę vs. prywatne, nieznane,
• ryzyko logowania – nietypowa godzina, nowe państwo, nowe urządzenie,
• wrażliwość aplikacji – portal HR vs. system finansowy.

Przykładowy kompromis: pracownik logujący się z firmowego laptopa, z biura, do mało wrażliwej aplikacji – tylko hasło lub SSO. Ten sam pracownik, ale z prywatnego telefonu, do systemu kadrowo‑płacowego – zawsze dodatkowe potwierdzenie w aplikacji uwierzytelniającej.

Takie podejście znacząco podnosi bezpieczeństwo przy akceptowalnym poziomie „tarcia” po stronie użytkowników.

Role i uprawnienia: z „kto prosi, ten dostaje” do modelu RBAC

Zero trust nie zadziała, jeśli większość pracowników ma dostęp „na wszelki wypadek”. Uprawnienia trzeba uprościć i powiązać z rolami biznesowymi, a nie z indywidualnymi prośbami.

Dobrym punktem startu jest identyfikacja kilku podstawowych profili:

• „pracownik biurowy” – pakiet standardowych uprawnień (poczta, intranet, podstawowe aplikacje),
• „manager” – jak wyżej plus dostęp do raportów zespołu,
• „specjalista X” – np. księgowy, handlowiec, inżynier produkcji,
• „konto uprzywilejowane” – administratorzy systemów, sieci, baz danych.

Dla każdej z tych ról definiuje się standardowy zestaw dostępów i powiązuje go z procesem HR (zatrudnienie, awans, zmiana działu). Dzięki temu większość uprawnień nadaje się automatycznie, a wnioski indywidualne dotyczą tylko wyjątków.

W kolejnych krokach można „dociążać” model RBAC bardziej precyzyjnymi regułami, a dla krytycznych systemów rozważyć ABAC (atrybuty, np. lokalizacja, godziny pracy, typ umowy).

Dostęp uprzywilejowany: osobny tor bezpieczeństwa

Konta administracyjne są najcenniejszym celem atakującego. W modelu zero trust powinny być traktowane zupełnie inaczej niż zwykłe konta użytkowników. Dobrą praktyką jest rozdzielenie ról: osobne konto do codziennej pracy biurowej, osobne – do zadań administracyjnych.

W praktyce oznacza to kilka zasad:

• logowanie na konto admina tylko wtedy, gdy jest to faktycznie potrzebne,
• obowiązkowe, silne MFA dla każdego konta uprzywilejowanego,
• preferowanie rozwiązań typu PAM (Privileged Access Management) – sesje administrowania przez kontrolowaną bramkę, z nagrywaniem i czasowym nadawaniem uprawnień.

Nawet jeśli pełny PAM jest poza aktualnym budżetem, już samo rozdzielenie kont oraz dodatkowe polityki dla nich (np. brak możliwości bezpośredniego logowania spoza sieci firmowej) znacząco zmniejszają ryzyko.

Sieć pod zero trust: segmentacja, dostęp zdalny, VPN vs ZTNA

Od „jednej dużej sieci” do stref i mikrosegmentacji

Wiele firm wciąż działa w modelu: jeden duży VLAN biurowy, kilka serwerowych i ewentualnie odseparowana produkcja. Taki układ daje dużą wygodę, ale też ułatwia atakującemu poruszanie się po infrastrukturze.

Przejście w stronę zero trust można zacząć od prostych kroków:

• wydzielenie sieci dla gości (Wi‑Fi guest) zupełnie odseparowanej od zasobów wewnętrznych,
• osobne VLAN‑y dla urządzeń biurowych, serwerów, drukarek, IoT,
• ograniczenie ruchu „wszystko do wszystkiego” – tylko niezbędne porty i kierunki, na podstawie faktycznych potrzeb aplikacji.

Kolejny etap to mikrosegmentacja, czyli kontrola ruchu nie tylko między VLAN‑ami, ale też wewnątrz nich – np. na poziomie pojedynczych serwerów lub grup aplikacyjnych. Można to realizować klasycznymi zaporami lub rozwiązaniami opartymi o agenty na hostach.

Dostęp zdalny: nowa rola VPN

Klasyczny VPN traktuje użytkownika po połączeniu jak część sieci wewnętrznej – często z bardzo szerokim dostępem. W modelu zero trust to podejście staje się problematyczne, szczególnie przy pracy hybrydowej.

Możliwe są dwa kierunki:

• utwardzenie istniejącego VPN – silne MFA, podział na profile dostępowe (np. księgowość widzi tylko określone serwery), integracja z IdP i politykami warunkowego dostępu,
• stopniowa migracja do ZTNA – zamiast wpuszczania użytkownika „do sieci”, udostępnia się mu konkretne aplikacje lub usługi przez bramkę ZTNA.

W przejściowym okresie oba podejścia mogą współistnieć: krytyczne systemy przechodzą na ZTNA, a systemy legacy pozostają za VPN, ale z podniesionym poziomem kontroli.

ZTNA w praktyce: jak wygląda dostęp „aplikacja po aplikacji”

Zero Trust Network Access zmienia punkt widzenia: użytkownik po uwierzytelnieniu i spełnieniu polityk nie „wchodzi do sieci”, tylko dostaje ściśle określony katalog aplikacji, do których może się połączyć.

Typowy scenariusz wdrożenia:

1. wybór kilku aplikacji o dużym znaczeniu biznesowym (np. CRM, system zgłoszeniowy, panel partnerów),
2. postawienie bramki ZTNA „przed” aplikacją – ruch przechodzi przez nią niezależnie od tego, skąd łączy się użytkownik,
3. integracja bramki z IdP i MDM/EDR, aby polityki mogły brać pod uwagę zarówno tożsamość, jak i stan urządzenia,
4. wyłączenie bezpośredniego dostępu do aplikacji z internetu (lub z VPN) po ustabilizowaniu ruchu przez ZTNA.

Korzyść jest podwójna: zewnętrzna ekspozycja aplikacji jest mniejsza, a logi dostępu trafiają do jednego miejsca. Dodatkowo dużo łatwiej wprowadzić reguły typu „z prywatnych urządzeń tylko dostęp przeze przeglądarkę, bez możliwości pobierania plików”.

Urządzenia niezarządzane i partnerzy: dostęp „bez wpuszczania do środka”

Wyzwaniem są sytuacje, gdy do aplikacji potrzebują dostępu osoby spoza organizacji – partnerzy, dostawcy, konsultanci – często z własnym sprzętem. W klasycznym podejściu kończy się to wydzielonym VPN‑em lub kontami „specjalnymi” w systemach.

Przy podejściu zero trust można to rozwiązać inaczej:

• dostęp wyłącznie przez przeglądarkę, z silnym MFA i krótkim czasem ważności sesji,
• brak konieczności instalowania klienta VPN – łączność realizuje bramka ZTNA lub reverse proxy,
• dodatkowe ograniczenia w aplikacji: brak eksportu danych, maskowanie pól wrażliwych, dostęp tylko do wybranych funkcji.

Dzięki temu sprzęt partnera nigdy nie staje się elementem „sieci wewnętrznej”, a ryzyko rozlania się incydentu jest dużo mniejsze.

Aplikacje i dane: jak „opakować” to, czego nie da się przepisać

Inwentaryzacja aplikacji: które da się zmienić, które trzeba otoczyć ochroną

W niemal każdej firmie istnieje zestaw systemów, których „nie da się” szybko wymienić: kluczowy ERP, aplikacje pisane lata temu, oprogramowanie dostawcy, który nie wspiera nowoczesnych mechanizmów uwierzytelniania. Z perspektywy zero trust nie są one przeszkodą nie do przejścia – wymagają po prostu dodatkowej warstwy ochrony.

Pomaga podział aplikacji na kategorie:

• gotowe do integracji – obsługują SAML/OIDC, reverse proxy, mają sensowne logowanie zdarzeń,
• wymagające „opakowania” – brak nowoczesnego SSO, stare protokoły, działają tylko z określonego adresu IP,
• krytyczne i wrażliwe – niezależnie od technologii wymagają najwyższego poziomu ochrony.

Do pierwszej grupy stosuje się standardowe mechanizmy IdP/SSO/ZTNA. Druga grupa staje się kandydatem do frontowania dodatkowymi warstwami pośrednimi.

Reverse proxy, WAF i bramki aplikacyjne jako „egzekutorzy” polityk

Jeśli aplikacji nie da się nauczyć nowoczesnego uwierzytelniania, można postawić przed nią komponent pośredniczący, który to zrobi. Może to być klasyczne reverse proxy, WAF z funkcją uwierzytelniania lub wyspecjalizowana bramka aplikacyjna.

Taki komponent:

• przyjmuje ruch od użytkownika i wymusza logowanie przez IdP (SAML/OIDC),
• sprawdza polityki dostępu (stan urządzenia, lokalizacja, grupa użytkownika),
• dopiero po pozytywnej weryfikacji przekazuje żądanie do aplikacji, mapując tożsamość np. na nagłówek HTTP lub konto techniczne.

Od strony użytkownika wygląda to jak normalny dostęp przez przeglądarkę. Aplikacja „w środku” może nadal myśleć, że widzi ruch tylko z lokalnej sieci lub z określonej maszyny pośredniczącej.

Ograniczanie ekspozycji systemów legacy

Systemów legacy zwykle nie da się całkowicie odłączyć od sieci, ale można znacząco zmniejszyć ich powierzchnię ataku. Kilka praktycznych zabiegów:

• dostęp tylko z wydzielonego segmentu sieci (np. poprzez jump host lub ZTNA),
• zamknięcie bezpośrednich połączeń z internetu – wszelki ruch zewnętrzny przechodzi przez bramkę,
• silne ograniczenie kont uprzywilejowanych, rotacja haseł technicznych,
• dodatkowy monitoring – logi z tych systemów trafiają w pierwszej kolejności do analizy.

W wielu przypadkach już samo odcięcie „historycznych” portów z zewnątrz i centralne logowanie zdarzeń daje wyraźny skok bezpieczeństwa, bez konieczności przebudowy aplikacji.

Dane w ruchu i w spoczynku: szyfrowanie jako standard

Jeśli zero trust zakłada brak domyślnego zaufania do sieci i urządzeń, to dane – zarówno w ruchu, jak i w spoczynku – powinny być traktowane jako coś, co może zostać przechwycone. Szyfrowanie przestaje być dodatkiem, a staje się normą.

Praktyczne minimum to:

• TLS dla wszystkich interfejsów webowych, API i usług – także wewnątrz sieci,
• szyfrowanie dysków na laptopach i urządzeniach mobilnych,
• szyfrowanie baz danych lub kluczowych tabel z danymi wrażliwymi, tam gdzie jest to technicznie możliwe,
• dedykowane mechanizmy dla backupów i archiwów – szyfrowanie z kontrolą dostępu do kluczy.

Kluczową rolę odgrywa tu zarządzanie kluczami (KMS, HSM) – kto może ich użyć, w jakim kontekście, czy rotacja jest zautomatyzowana. Nawet bardzo dobre szyfrowanie traci sens, jeśli klucze są przechowywane w arkuszu kalkulacyjnym na udziale sieciowym.

Dostęp do danych: od prostych etykiet do DLP

Sama klasyfikacja danych to dopiero początek. Kolejny krok to powiązanie tej klasyfikacji z zachowaniem systemów. Można iść dwiema ścieżkami – od lekkich rozwiązań do zaawansowanych.

Na start wystarczą proste etykiety i reguły:

• oznaczanie plików i folderów poziomem wrażliwości (np. etykiety w systemie DMS lub Office),
• inne reguły udostępniania: dokumenty „wewnętrzne” można współdzielić w organizacji, „wrażliwe” tylko wewnątrz działu,
• dodatkowe MFA przy próbie dostępu do repozytoriów z etykietą „krytyczne”.

W kolejnym etapie można włączyć systemy DLP (Data Loss Prevention), które automatycznie analizują treść (np. poszukiwanie numerów PESEL, danych kart), blokują wysyłkę lub wymagają dodatkowego uzasadnienia przy próbach wypływu danych poza organizację.

Dobrze jest zaczynać od trybu „monitoruj i raportuj”, aby poznać realne przepływy informacji, a dopiero później zaostrzać reguły blokujące. Dzięki temu unika się paraliżu pracy w pierwszych dniach po wdrożeniu.

„Opakowywanie” danych w SaaS i chmurze

Coraz więcej informacji żyje w chmurze: poczta, dyski współdzielone, CRM, systemy HR. Zero trust nie kończy się na granicy własnego data center – polityki dostępu muszą obejmować również zasoby SaaS.

Podstawowe kroki to:

• centralne logowanie do usług chmurowych przez IdP i SSO,
• wyłączenie lokalnych kont w tych systemach tam, gdzie to możliwe,
• ograniczenie dostępu administracyjnego: preferowanie kont „break‑glass” z silnym zabezpieczeniem, zamiast stałych loginów adminów,
• wykorzystanie natywnych mechanizmów dostawcy (etykiety, szyfrowanie, reguły udostępniania) zgodnie z przyjętą w organizacji klasyfikacją danych.

Jeżeli pojawia się obawa, że „wszystko będzie w rękach jednej chmury”, można rozważyć warstwę pośrednią – CASB lub podobne rozwiązania – które wprowadzają dodatkowe reguły kontroli dostępu i przepływu danych między usługami.

Źródła informacji

• Zero Trust Architecture (SP 800-207). National Institute of Standards and Technology (2020) – Podstawowa definicja i model architektury zero trust
• Zero Trust Security Playbook. Microsoft (2021) – Praktyczne wytyczne wdrażania zero trust w środowiskach hybrydowych
• BeyondCorp: A New Approach to Enterprise Security. Google (2014) – Koncepcja dostępu bez zaufanej sieci wewnętrznej, fundament idei zero trust
• Zero Trust Extended Ecosystem Framework. Forrester Research (2018) – Model Forrester opisujący filary i komponenty ekosystemu zero trust
• Zero Trust Security Buyer’s Guide. Gartner (2021) – Analiza trendów rynkowych i rekomendacje dla architektury zero trust
• CISA Zero Trust Maturity Model. Cybersecurity and Infrastructure Security Agency (2021) – Model dojrzałości zero trust dla organizacji publicznych i prywatnych
• Executive Order on Improving the Nation’s Cybersecurity. The White House (2021) – Wymóg przejścia agencji federalnych USA na model zero trust