Cel czytelnika: praktyczne wdrożenie Zero Trust bez złudzeń
Zero Trust interesuje przede wszystkim osoby, które mają dość marketingowych slajdów i chcą wiedzieć, jak realnie zmienić bezpieczeństwo firmowej sieci. Chodzi o to, aby przełożyć hasło „never trust, always verify” na konkretne działania, procesy i konfiguracje – krok po kroku, na istniejącej infrastrukturze, a nie w idealnym „greenfieldzie”.
Celem jest redukcja ryzyka, a nie zgodność z modnym trendem. Dlatego bardziej liczy się trzeźwa diagnoza i konsekwentna realizacja małych etapów niż zakup kolejnego „magicznego” rozwiązania Zero Trust obiecywanego w broszurach producentów.
Czym Zero Trust jest naprawdę, a czym już nie
Skąd się wziął model Zero Trust
Zero Trust nie jest nowym firewallem ani kolejną generacją VPN. To odpowiedź na fakt, że tradycyjny model „zaufanej sieci wewnętrznej” i „niezaufanego internetu” przestał odzwierciedlać rzeczywistość. Pracownicy łączą się z domu, z hoteli, z własnych komputerów, aplikacje siedzą w chmurze, a dane podróżują między dostawcami SaaS, partnerami i podwykonawcami.
Forrester jako pierwszy mocno spopularyzował pojęcie Zero Trust, kładąc nacisk na zasadę „never trust, always verify”. Z kolei NIST w publikacji 800‑207 opisał model Zero Trust Architecture (ZTA) jako zbiór zasad architektonicznych i wzorców, a nie konkretny produkt. W obu podejściach kluczem jest rezygnacja z założenia, że sam fakt „bycia w sieci firmowej” oznacza zaufanie.
W praktyce Zero Trust powstawał ewolucyjnie: od segmentacji sieci, przez silniejsze zarządzanie tożsamościami, po coraz szersze wykorzystanie analityki i telemetrii. To dlatego różne organizacje wdrażają go od różnych stron: jedni od IAM i MFA, inni od mikrosementacji, jeszcze inni – od ochrony danych i klasyfikacji informacji.
Najczęstsze mity i marketingowe nadużycia
Hasło „Zero Trust” stało się już tak modne, że część dostawców używa go jako etykietki na dowolnym produkcie bezpieczeństwa. To utrudnia zrozumienie, o co naprawdę chodzi. Kilka typowych mitów:
- „Zero Trust to brak zaufania do pracowników” – w rzeczywistości chodzi o brak ślepego zaufania do sesji, urządzeń i kontekstu. Użytkownik może być jak najbardziej zaufany, ale jego laptop już niekoniecznie, szczególnie po powrocie z podróży czy po instalacji nowego oprogramowania.
- „Zero Trust = jedno narzędzie” – nie istnieje „platforma Zero Trust”, która po wdrożeniu załatwi wszystko. To zawsze kombinacja polityk, procesów, integracji i technologii, szytych pod konkretne środowisko.
- „Jak mamy VPN i MFA, to mamy Zero Trust” – to dopiero drobne elementy układanki. Zero Trust wymaga konsekwentnej kontroli dostępu na wielu poziomach (aplikacje, dane, urządzenia, ruch sieciowy) oraz ciągłego monitoringu.
- „Zero Trust to projekt na 3 miesiące” – bardziej przypomina program kilkuletni, który zmienia sposób myślenia o dostępie i zaufaniu. Krótkie projekty pilotażowe to element, nie cel sam w sobie.
Marketingowa narracja upraszcza Zero Trust do listy funkcji. W realnym świecie ważniejsze jest, jak te funkcje są użyte, jaki proces je otacza i czy faktycznie ograniczają możliwości napastnika poruszania się po środowisku.
Jak poznać, że sprzedawca używa „Zero Trust” jako etykietki
Istnieje kilka czerwonych flag sygnalizujących, że mamy do czynienia z marketingiem, nie z rzeczywistym podejściem Zero Trust:
- brak rozmowy o istniejącej architekturze, przepływach i danych – od razu oferta „gotowego rozwiązania Zero Trust”;
- obietnica „wyeliminowania wszystkich VPN” w tydzień, bez szczegółowego planu migracji aplikacji i uwierzytelnień;
- brak odniesienia do zasad NIST/Forrester lub chociaż logicznej mapy: użytkownik – urządzenie – aplikacja – dane – sieć;
- brak dyskusji o integracji z dotychczasowym IAM, SIEM, EDR, systemami kopii zapasowych i procesami biznesowymi.
Jeśli dostawca nie zadaje trudnych pytań o procesy, role, wyjątki i „brudne” elementy infrastruktury, raczej sprzedaje produkt z modną etykietą niż realną koncepcję Zero Trust. W takiej sytuacji lepiej zatrzymać się na etapie analizy potrzeb i samodzielnie zmapować wymagania, zanim powiąże się je z konkretnymi narzędziami.
Fundamenty Zero Trust: kluczowe zasady i komponenty
Zasady projektowe według NIST, Forrestera i praktyków
Zero Trust w praktyce opiera się na kilku powtarzalnych zasadach, które przewijają się w dokumentach NIST, publikacjach Forrestera oraz doświadczeniach zespołów SOC i architektów bezpieczeństwa. W uproszczeniu można je streścić w czterech hasłach:
- Jawne weryfikowanie – nic nie jest zakładane „z góry”. Każdy dostęp wymaga sprawdzenia tożsamości, kontekstu urządzenia, poziomu ryzyka i polityk.
- Minimalne uprawnienia (least privilege) – użytkownik, aplikacja czy usługa otrzymują tylko tyle dostępu, ile jest konieczne do wykonania zadania. Nie więcej, „na wszelki wypadek”.
- Założenie naruszenia (assume breach) – projekt zakłada, że włamanie prędzej czy później nastąpi. Celem jest ograniczenie jego zasięgu i czasu wykrycia, a nie ślepa wiara, że „u nas się nie uda”.
- Ciągła ocena ryzyka – decyzja o dostępie nie jest jednorazowa przy logowaniu. Warunki mogą się zmieniać w czasie sesji, a system musi na to reagować.
Te zasady mają konsekwencje organizacyjne. Oznaczają m.in. konieczność regularnego przeglądu uprawnień, rewizji kont uprzywilejowanych, okresowej recertyfikacji dostępów oraz ścisłej współpracy IT z działami biznesowymi. Sam dział bezpieczeństwa, bez wsparcia właścicieli procesów, nie jest w stanie wdrożyć ich sensownie.
Kluczowe obszary: tożsamość, urządzenia, aplikacje, dane, sieć, widoczność
Zero Trust w praktyce dotyka kilku warstw jednocześnie. Ignorowanie którejkolwiek z nich prowadzi do „dziur” w modelu:
- Tożsamość użytkownika – kto próbuje uzyskać dostęp, jakie ma role, jak silnie jest uwierzytelniony, czy jego konto nie jest zainfekowane/zhakowane.
- Urządzenie – z jakiego komputera, telefonu lub serwera następuje dostęp, w jakim jest stanie (aktualizacje, antywirus/EDR, szyfrowanie dysku, konfiguracja).
- Aplikacja / usługa – do czego następuje dostęp: webowa aplikacja biznesowa, panel administracyjny, interfejs API, system ERP, poczta.
- Dane – do jakich danych użytkownik sięga, jaka jest ich wrażliwość, czy może je eksportować, kopiować, drukować.
- Sieć – jak wygląda ścieżka ruchu, jakie segmenty są połączone, czy występuje mikrosementacja, czy ruch jest szyfrowany i monitorowany.
- Widoczność i logowanie – co jest logowane, gdzie trafiają logi, czy są korelowane, jakie są progi alarmowania.
Praktyczny model Zero Trust wymaga minimalnego poziomu dojrzałości w każdym z tych obszarów. Bardziej opłaca się mieć prostsze rozwiązania, ale spójnie wdrożone w całym środowisku, niż zaawansowane funkcje w jednym narzędziu, które nie mają danych z innych warstw.
Rola IAM, MFA i inwentaryzacji zasobów
Tożsamość jest nowym „perymetrem”, ale bez porządnego IAM (Identity and Access Management) i wieloskładnikowego uwierzytelniania Zero Trust pozostaje teorią. Centralne zarządzanie tożsamością pozwala wprowadzić zasadę „jeden użytkownik – jedna tożsamość”, przypisać role i uprawnienia oraz zautomatyzować cykl życia kont (nadanie, modyfikacja, odebranie dostępu).
Pomóc może też porównanie marketingowych obietnic ze źródłami bardziej niezależnymi, np. publikacjami NIST czy praktycznymi analizami dostępnych na serwisach branżowych, takich jak Ochrona Twierdza, gdzie bardziej widać wzorce architektury niż pojedyncze produkty.
W praktyce często dopiero porządki w IAM ujawniają skalę chaosu: nieużywane konta, duplikaty, konta „sieroty” po pracownikach, którzy odeszli lata temu, a wciąż mają dostęp do krytycznych systemów. To z kolei blokuje sensowne ograniczanie uprawnień i recertyfikację dostępów.
Drugim fundamentem jest MFA, czyli Multi‑Factor Authentication. Bez drugiego składnika (aplikacja, token sprzętowy, klucz FIDO, SMS jako absolutne minimum) konta stają się łatwym celem ataków brute force i phishingu. Szczególnie przy pracy zdalnej i dostępie do aplikacji chmurowych bez MFA nie ma mowy o Zero Trust w praktyce.
Do tego dochodzi systematyczna inwentaryzacja zasobów. Bez wiedzy, jakie mamy serwery, aplikacje, integracje, konta serwisowe i połączenia z partnerami, nie da się zbudować sensownych polityk. W tym miejscu przydają się proste, ale rzetelnie prowadzone rejestry: tabela aplikacji, właściciele biznesowi, rodzaj danych, interfejsy, poziom krytyczności, zależności sieciowe.
Granica między automatyzacją a decyzją człowieka
Zero Trust silnie korzysta z automatyzacji: polityki dostępu warunkowego, automatyczne blokowanie sesji przy wykryciu anomalii, reagowanie SOAR na incydenty. Kuszące jest, aby „oddać decyzje maszynie”. Tu pojawia się pierwsza pułapka: modele ryzyka, na których działa automatyka, są z definicji uproszczeniem rzeczywistości.
Decyzje typu „czy zablokować użytkownika?” czy „czy wymusić dodatkowy składnik MFA?” często można oprzeć na algorytmach. Natomiast pytania „czy ten dostęp jest potrzebny biznesowo?” czy „czy można całkowicie wyłączyć starą integrację z dostawcą?” wymagają rozmowy z właścicielami procesów. Automatyzacja powinna więc obsługiwać powtarzalne decyzje, ale definicja reguł musi pozostać po stronie człowieka.
Dojrzały model Zero Trust rozwija się warstwowo: najpierw twarde wymogi (MFA dla krytycznych usług, minimalne uprawnienia dla adminów), potem automatyczny monitoring i reakcja na anomaliach, a dopiero w kolejnych etapach – bardziej złożone scenariusze adaptacyjne (np. dynamiczne podnoszenie wymogów przy nietypowym zachowaniu użytkownika).
Diagnoza stanu obecnego: od czego zacząć bez złudzeń
Inwentaryzacja zasobów i przepływów
Pierwszy krok do wdrożenia Zero Trust w firmowej sieci to uczciwe rozpoznanie, co faktycznie istnieje. W praktyce oznacza to inwentaryzację na kilku poziomach:
- Urządzenia – komputery, serwery, urządzenia mobilne, drukarki sieciowe, IoT w biurze (kamery, systemy kontroli dostępu), sprzęt sieciowy (switche, routery, firewalle).
- Konta – konta użytkowników, konta uprzywilejowane (admini, root), konta serwisowe (integracje, skrypty), konta techniczne używane przez aplikacje.
- Aplikacje i usługi – systemy on‑prem, aplikacje webowe, SaaS, narzędzia w chmurze publicznej, wewnętrzne API, systemy integracyjne (ESB, middleware).
- Połączenia z partnerami – tunele VPN z dostawcami i klientami, dostęp zewnętrznych serwisantów, integracje z API partnerów.
W wielu firmach sytuacja zastana bywa zaskakująca: „tym serwerem już nikt nie zarządza, ale jak go wyłączymy, to coś przestaje działać”. Dlatego oprócz samej listy zasobów kluczowa jest mapa przepływów: kto, z czego, do czego się łączy i w jakim celu. Pomagają tu:
- logi z firewalli i proxy (źródło – cel – port – czas);
- logi z VPN (kto, skąd, do jakich sieci);
- dane z EDR/NDR o połączeniach między hostami;
- rozmowy z administratorami i właścicielami aplikacji o typowych scenariuszach użycia.
Nawet prosta wizualizacja w postaci arkusza kalkulacyjnego lub schematu sieci z zaznaczonymi przepływami pomaga zobaczyć, gdzie potencjalnie napastnik może poruszać się zbyt swobodnie. Bez tej wiedzy segmentacja i mikrosementacja będą strzelaniem na oślep.
Ocena dojrzałości bezpieczeństwa i ryzyka
Po zebraniu danych pojawia się pytanie: „od czego zacząć?”. Odpowiedź zależy od dojrzałości bezpieczeństwa w poszczególnych obszarach. Pomocne jest zgrubne określenie poziomu na skali, np. od 1 do 5, dla takich domen jak:
- zarządzanie tożsamością i dostępem (IAM, MFA, recertyfikacja);
- segmentacja sieci i kontrola ruchu bocznego (lateral movement);
- ochrona punktów końcowych (EDR/antywirus, aktualizacje);
- monitoring i logowanie (SIEM, korelacja zdarzeń);
- zarządzanie podatnościami (skanowanie, patch management);
- kopie zapasowe i odtwarzanie po incydencie (backup, DR).
Priorytetyzacja działań: co naprawić najpierw, a co może poczekać
Po wstępnej ocenie dojrzałości zwykle okazuje się, że „do zrobienia jest wszystko”. Bez selekcji priorytetów Zero Trust zamienia się w niekończący się projekt koncepcyjny. Potrzebny jest filtr, który wskaże, gdzie jeden dzień pracy daje największe ograniczenie ryzyka.
Praktyczne kryteria priorytetyzacji:
- Wpływ na krytyczne procesy – które systemy są niezbędne do wystawiania faktur, obsługi klientów, produkcji? Wokół nich najpierw trzeba uszczelniać tożsamość i dostęp.
- Ekspozycja na Internet – aplikacje dostępne z zewnątrz, zdalne pulpity, panele administracyjne, VPN. Każde narzędzie „wystawione na świat” to naturalny kandydat do szybkiego utwardzenia.
- Łatwość ataku – brak MFA, słabe hasła, stare protokoły (np. SMBv1, niezaszyfrowane usługi), szerokie uprawnienia adminów. Tam ryzyko jest wysokie przy relatywnie małym nakładzie pracy.
- Skala potencjalnego „lateral movement” – gdzie jeden zainfekowany host daje dostęp do połowy sieci, bo VLAN jest płaski, a ACL-e symboliczne.
Na tej podstawie da się stworzyć prostą matrycę: istotność biznesowa × podatność × ekspozycja. Systemy z górnego prawego rogu lądują w pierwszej fali działań. Oznacza to w praktyce np. pilne włączenie MFA na portalach zdalnego dostępu, weryfikację kont adminów domeny, odcięcie przestarzałych zdalnych pulpitów z bezpośrednim dostępem z Internetu.
Typowym błędem jest zaczynanie od najbardziej zaawansowanych koncepcji (mikrosegmentacja w całym DC, SASE, ZTNA „dla wszystkich”) zamiast od prostych luk, które można zamknąć w tygodnie, nie lata. Nafaszerowana funkcjami platforma bez ogarniętych ról i kont uprzywilejowanych rozwiązuje marginalną część problemu.
Mapowanie luk na konkretny model Zero Trust
Kolejny krok to powiązanie zidentyfikowanych luk z elementami modelu Zero Trust. Zamiast abstrakcyjnych „filarów bezpieczeństwa” lepiej posługiwać się mapą: luka → zasada Zero Trust → potencjalne środki zaradcze.
Przykładowe powiązania:
- Brak MFA dla dostępu VPN → naruszenie zasady „nigdy nie ufaj, zawsze weryfikuj” → włączenie MFA, ograniczenie dostępnych sieci po VPN, docelowo zastąpienie klasycznego VPN bramą ZTNA.
- Jeden VLAN dla całego biura i serwerowni → brak ograniczenia ruchu bocznego → segmentacja sieci, stopniowe wprowadzanie mikrosegmentacji dla krytycznych aplikacji.
- Konta użytkowników z prawami lokalnego administratora → naruszenie zasady minimalnych uprawnień → wdrożenie modelu standard user + narzędzia do podnoszenia uprawnień na żądanie (PAM, LAPS, EPM).
- Integracje między systemami po „twardo zaszytych” hasłach → brak kontroli nad kontami serwisowymi → wprowadzenie sejfu haseł (PAM), rotacja poświadczeń, docelowo uwierzytelnianie oparte na kluczach/certyfikatach lub tożsamości aplikacji.
Takie mapowanie pozwala spiąć techniczne zadania z koncepcją Zero Trust w sposób zrozumiały dla zarządu i właścicieli procesów. Zamiast ogólnego hasła „wdrażamy nowoczesny model bezpieczeństwa” można pokazać, że chodzi o bardzo konkretne zmiany: kto, do czego, z jakiego miejsca i w jakich warunkach ma dostęp.
Planowanie wdrożenia: strategia, priorytety i zakres pilotażu
Określenie realnego poziomu ambicji
Przy planowaniu wdrożenia pojawia się presja, żeby „dogonić najlepszych” i z dnia na dzień przeprojektować całą infrastrukturę. Taki plan zwykle kończy się paraliżem decyzyjnym i oporem biznesu. Rozsądniej jest świadomie zdefiniować poziom ambicji na horyzoncie 1–2 lat, a nie 5–10.
Pomocne pytania na start:
- czy organizacja jest gotowa na powiązanie dostępów z formalnymi rolami i procesami HR (onboarding, zmiana stanowiska, offboarding)?
- jak duża jest tolerancja na zmiany w sposobie pracy użytkowników (częstsze wymuszanie MFA, zmiana sposobu łączenia się z zasobami)?
- czy istnieje wsparcie zarządu dla wprowadzania ograniczeń, które krótkoterminowo utrudnią „kombinowanie na skróty” (np. logowanie się adminów na pocztę tymi samymi kontami, którymi zarządzają serwery)?
Na tej podstawie da się określić, czy celem jest raczej „podstawowy Zero Trust” (MFA, minimalne uprawnienia, segmentacja krytycznych systemów, lepsza widoczność), czy od razu „pełny” scenariusz z ZTNA, silną mikrosegmentacją i szeroką automatyzacją reakcji.
Roadmapa: krótka lista kroków zamiast setek zadań
Strategia Zero Trust nie powinna przyjmować formy 200-stronicowego dokumentu z listą życzeń. Lepiej zadziała 12–18-miesięczna roadmapa z kilkunastoma punktami, które można mierzyć i konsekwentnie realizować.
Dobrym uzupełnieniem będzie też materiał: Cloud Security Posture Management – czy warto inwestować? — warto go przejrzeć w kontekście powyższych wskazówek.
Przykładowa, uproszczona struktura roadmapy:
- Faza 1 – uszczelnienie fundamentów
- MFA dla wszystkich zdalnych dostępów i usług krytycznych.
- Centralizacja kont użytkowników (AD/AAD + podstawowa hybryda chmurowa, jeśli potrzebna).
- Redukcja lokalnych adminów, wdrożenie LAPS lub innego mechanizmu zarządzania hasłami lokalnymi.
- Podstawowa segmentacja sieci: rozdzielenie użytkowników od serwerów, wydzielenie stref DMZ.
- Faza 2 – kontrola dostępu warunkowego i widoczność
- Wdrożenie zasad dostępu warunkowego opartego o kontekst (lokalizacja, urządzenie, poziom ryzyka logowania).
- Zebranie logów do centralnego systemu (SIEM lub tańsza alternatywa), definicja podstawowych korelacji i alarmów.
- Wprowadzenie procesu regularnej recertyfikacji uprawnień w systemach krytycznych.
- Faza 3 – segmentacja aplikacyjna i ZTNA
- Wybór i wdrożenie rozwiązania ZTNA lub proxy aplikacyjnego dla kluczowych usług.
- Mikrosegmentacja per aplikacja (firewalle hostowe, grupy zabezpieczeń, polityki sieciowe w chmurze).
- Automatyzacja reakcji na wybrane scenariusze (SOAR lub skrypty reagujące na alerty z SIEM/EDR).
Ta lista musi być dopasowana do skali i branży. Mała firma produkcyjna z kilkoma krytycznymi systemami MES będzie miała inny rozkład akcentów niż korporacja z setkami aplikacji SaaS. Model jest ten sam, różni się głębokość i tempo.
Dobór obszaru pilotażowego
Pilot Zero Trust powinien być wystarczająco istotny, żeby pokazać realną wartość, ale na tyle ograniczony, by porażka nie sparaliżowała całej organizacji. Zazwyczaj najlepszym kandydatem jest pojedyncza, dobrze zdefiniowana linia biznesowa albo wybrany zestaw aplikacji.
Przykładowe kryteria wyboru pilota:
- Jasno określony właściciel biznesowy, który jest gotów brać udział w decyzjach o dostępach.
- Dobra znajomość zależności technicznych (kto korzysta, jakie integracje, jakie dane).
- Znaczące ryzyko przy obecnym stanie (np. szerokie dostępy, brak segmentacji, brak MFA), ale możliwe do ograniczenia bez rewolucji.
Częstym błędem jest próba objęcia pilotem „całego IT” lub „wszystkich pracowników biurowych”. Kończy się to nadmiarem wyjątków, wyjątkami od wyjątków i ostatecznym rozmyciem zasad. Znacznie lepiej przećwiczyć pełny cykl Zero Trust na jednym, dobrze wybranym obszarze, a dopiero potem skalować.
Zaangażowanie biznesu i „właścicieli ról”
Bez udziału osób spoza IT Zero Trust prędzej czy później przekształci się w techniczny projekt infrastrukturalny. Formalne role, uprawnienia i wyjątki musi ktoś zatwierdzać. Nie ma sposobu, by sensownie zdefiniować, kto powinien mieć dostęp do jakich danych sprzedażowych czy finansowych, bez szefa sprzedaży czy CFO przy stole.
Na koniec warto zerknąć również na: Poradnik: jak chronić się przed atakami na hasła (brute force) — to dobre domknięcie tematu.
Przykładowa praktyka, która się sprawdza:
- Na etapie pilota dla każdej kluczowej aplikacji powoływany jest właściciel biznesowy (nie z IT) i właściciel techniczny.
- Wspólnie definiują zestaw ról w aplikacji (np. sprzedawca, kierownik regionu, administrator działu, superadmin).
- Do każdej roli przypisuje się uprawnienia w kategoriach: odczyt, zapis, administracja, eksport danych, dostęp zdalny.
- Na tej podstawie IAM implementuje odpowiednie grupy, a systemy dostępu warunkowego – polityki.
Wymaga to czasu i cierpliwości, ale po pierwszych iteracjach zaczyna działać jak szablon do kolejnych aplikacji. Zamiast tradycyjnego „dajcie temu użytkownikowi takie same prawa jak Kowalski” pojawia się język ról i procesów.
Tożsamość i dostęp: budowa nowego „perymetru”
Standaryzacja źródeł tożsamości
Żeby tożsamość mogła być sensownym perymetrem, musi być jednoznaczna. Typowy bałagan to kilka równoległych baz użytkowników: osobno w AD, osobno w Google Workspace lub M365, osobno w aplikacjach SaaS, jeszcze inaczej w systemie HR.
Docelowy model to jeden system źródłowy (najczęściej HR) oraz jeden lub dwa główne katalogi tożsamości (np. AD + AAD). Z tego wynika reszta:
- konto w katalogu powstaje automatycznie, gdy w HR pojawia się nowy pracownik;
- zmiana stanowiska aktualizuje przypisanie do ról i grup;
- odejście pracownika powoduje dezaktywację konta w katalogu i – przez integracje – w aplikacjach.
Bez takiej standaryzacji każda polityka Zero Trust będzie zderzać się z przypadkami „konto jest w innym systemie, nieobjęte politykami”. W małych firmach wystarczy prosty workflow i integracja przez API. W większych organizacjach zwykle potrzebny jest dedykowany system IAM z konektorami.
Modele uwierzytelniania a Zero Trust
Uwierzytelnianie to nie tylko login i hasło + MFA. Model Zero Trust wymusza spójne podejście do tego, jak użytkownik „przynosi” swoją tożsamość do różnych aplikacji.
Najbardziej praktyczne wzorce:
- SSO oparte o standardy (SAML, OpenID Connect, OAuth2) – aplikacje nie przechowują własnych haseł, odwołują się do centralnego dostawcy tożsamości.
- Federacja z zewnętrznymi dostawcami – partnerzy, kontraktorzy, czasem także klienci logują się przez swoje systemy (Azure AD, Google, inne IdP), a nasz system tylko przyznaje im odpowiednie role.
- Step-up authentication – podniesienie poziomu uwierzytelnienia przy wrażliwych operacjach (np. wejście w tryb administracyjny aplikacji wymaga ponownego podania hasła lub potwierdzenia w aplikacji MFA).
W praktyce nie wszystkie aplikacje wspierają nowoczesne protokoły. Dla starszych systemów stosuje się różnego rodzaju „bramy” SSO, reverse proxy, a w skrajnych przypadkach pozostaje klasyczny VPN z mocnymi kontrolami. Warto mieć świadomość, że pełne „odcięcie haseł lokalnych” od razu jest wyjątkiem, nie normą.
Polityki MFA bez paraliżu użytkowników
Wiele organizacji boi się agresywnego MFA, bo „ludzie się zbuntują”. Rzeczywiście, projekt wymuszający potwierdzanie każdego logowania do poczty potrafi wygenerować sporo frustracji. Da się to jednak ucywilizować, wykorzystując mechanizmy kontekstowe.
Przykładowe, rozsądne zasady:
- Wymóg MFA przy pierwszym logowaniu z nowego urządzenia lub nowej przeglądarki.
- Wymóg MFA przy dostępie do aplikacji o wysokiej wrażliwości (np. finanse, dane zdrowotne), nawet jeśli urządzenie jest „znane”.
- Dodatkowy MFA przy wykryciu podwyższonego ryzyka przez system (nietypowa lokalizacja, wiele nieudanych prób logowania, zgłoszenie incydentu z kontem).
Taki model minimalizuje liczbę „przeszkadzajek” na co dzień, a jednocześnie znacznie utrudnia przejęcie konta napastnikowi. Warto też od razu zaplanować procesy awaryjne: co jeśli użytkownik zgubi telefon, jak szybko może odzyskać dostęp, jakie mechanizmy weryfikacji tożsamości stosuje helpdesk.
Zarządzanie uprawnieniami: role, grupy, wyjątki
Bez uporządkowanych uprawnień Zero Trust sprowadza się do „mamy MFA, więc jest dobrze”. Tu potrzebna jest dyscyplina na kilku poziomach:
- RBAC (role-based access control) jako punkt wyjścia – uprawnienia nadaje się przez role i grupy, nie indywidualnie.
- ABAC (attribute-based) w bardziej zaawansowanych scenariuszach – dostęp zależy np. od przynależności do działu, kraju, poziomu seniority, stanu urządzenia.
