Zero Trust - Jak wdrożyć model zerowego zaufania w firmie?

Bezpieczny dostęp do systemów nie kończy się dziś na haśle i nazwie sieci. W praktyce chodzi o to, by każdy użytkownik i każde urządzenie były sprawdzane zanim dostaną dostęp do zasobu, a nie po tym, jak już „wejdą do środka”. To właśnie założenie, które stoi za podejściem zero trust, i dlatego tak dobrze pasuje do środowisk z pracą hybrydową, chmurą oraz wieloma aplikacjami poza klasycznym obwodem firmowym.

Na czym polega model zerowego zaufania

Najprościej mówiąc, ten model zakłada, że żaden element środowiska nie zasługuje na automatyczne zaufanie tylko dlatego, że znajduje się w sieci firmowej, należy do organizacji albo wcześniej został już sprawdzony. NIST opisuje to jako przesunięcie ochrony z sztywnego perymetru sieci na użytkowników, zasoby i procesy, czyli na to, co naprawdę trzeba chronić.

To ważna zmiana myślenia. Tradycyjny model mówił w skrócie: „jesteś wewnątrz, więc jesteś w miarę bezpieczny”. Podejście zerowego zaufania mówi coś innego: każde żądanie ma własny kontekst i własny poziom ryzyka, więc powinno być oceniane osobno. Nie ma znaczenia, czy ktoś loguje się z biura, domu czy z kraju po drugiej stronie świata, jeśli jego urządzenie jest zainfekowane albo konto przejęte.

W praktyce ten model jest odpowiedzią na trzy zjawiska, które zdominowały cyberbezpieczeństwo w ostatnich latach: pracę zdalną i hybrydową, chmurę oraz rozproszone łańcuchy dostępu z udziałem partnerów i dostawców. W takim środowisku klasyczna granica sieci przestaje być wiarygodnym punktem odniesienia. Dlatego ja patrzę na ten model nie jak na modny termin, ale jak na sposób uporządkowania dostępu tam, gdzie granic już właściwie nie da się narysować jedną linią.

To prowadzi do pytania ważniejszego od samej definicji: jak system podejmuje decyzję o dostępie w konkretnym momencie.

Jak działa decyzja o dostępie w praktyce

W dobrym wdrożeniu nie ma jednego „tak” albo „nie” dla całej sieci. Jest za to proces, który sprawdza kilka sygnałów naraz i dopiero na tej podstawie wydaje zgodę. W uproszczeniu wygląda to tak:

1. Użytkownik lub usługa prosi o dostęp do konkretnego zasobu.
2. System weryfikuje tożsamość, zwykle przez SSO i MFA.
3. Sprawdzany jest stan urządzenia, czyli na przykład aktualność systemu, obecność ochrony endpointów i zgodność z polityką firmy.
4. Oceniany jest kontekst: lokalizacja, pora dnia, rodzaj aplikacji, poziom ryzyka i nietypowe zachowania.
5. Silnik polityk podejmuje decyzję, a punkt egzekwowania polityki wymusza ją na poziomie sesji lub aplikacji.
6. Sesja nie jest „raz na zawsze zaufana” - może być ponownie oceniana, ograniczana albo zamykana, jeśli ryzyko wzrośnie.

To jest istota tego podejścia: dostęp nie jest nagrodą za sam fakt zalogowania się, tylko wynikiem bieżącej oceny. W środowiskach cloud-native dochodzi jeszcze kolejny poziom, czyli tożsamość usług i workloadów, a nie tylko ludzi. To szczególnie ważne, bo dziś wiele incydentów nie zaczyna się od spektakularnego włamania, tylko od przejętego konta lub źle ustawionego uprawnienia w aplikacji.

W praktyce oznacza to też, że MFA nie załatwia wszystkiego. To jeden z filarów, ale sam w sobie nie odpowiada na pytania o stan urządzenia, zakres uprawnień ani o to, czy dana sesja nadal wygląda wiarygodnie. Z tego powodu ważne jest porównanie z klasycznym modelem, który nadal bywa mylony z nowym podejściem.

Czym różni się od klasycznego podejścia do bezpieczeństwa

Największa różnica nie leży w samych narzędziach, tylko w logice ochrony. W klasycznym modelu najpierw buduje się obwód, a potem zakłada, że wszystko wewnątrz jest w dużej mierze zaufane. W modelu zerowego zaufania obwód traci znaczenie, a centrum ciężkości przesuwa się na tożsamość, urządzenie, dane i aplikację.

Tu pojawia się częste nieporozumienie: wiele osób myśli, że wdrożenie VPN, MFA i nowego firewalla już „robi” cały model. Nie robi. To tylko fragment układanki. Jeśli użytkownik po zalogowaniu widzi za dużo, jeśli konto administratora ma stałe szerokie uprawnienia albo jeśli aplikacje nie potrafią sprawdzić kontekstu żądania, to nadal tkwimy w starym myśleniu, tylko w nowocześniejszym opakowaniu.

Właśnie dlatego przejście od teorii do działania wymaga kolejnego kroku: rozsądnego wdrożenia, a nie wielkiej rewolucji od pierwszego dnia.

Jak wdrożyć go bez przepalania budżetu

Ja zwykle zaczynam od tego, co daje największy efekt przy najmniejszej liczbie zmian. W praktyce są to konta uprzywilejowane, najważniejsze aplikacje i podstawowa higiena tożsamości. W polskich firmach najczęściej problemem nie jest brak technologii, tylko rozproszone uprawnienia, stare wyjątki i brak spójnej listy zasobów, które naprawdę trzeba chronić.

1. Spisz tożsamości, urządzenia, aplikacje i dane, które mają najwyższy priorytet biznesowy.
2. Zacznij od najmniejszych grup, czyli administratorów, działu finansów, danych klientów i krytycznych systemów.
3. Włącz MFA i polityki warunkowego dostępu, a tam gdzie się da, przejdź na logowanie bezhasłowe.
4. Dodaj zarządzanie stanem urządzeń przez MDM lub UEM oraz ochronę endpointów, żeby móc oceniać zgodność sprzętu.
5. Ogranicz szeroki dostęp sieciowy na rzecz dostępu do konkretnej aplikacji lub usługi.
6. Wprowadź zasadę najmniejszych uprawnień i usuń stałe konta administracyjne tam, gdzie nie są potrzebne.
7. Dołóż logowanie, analizę i automatyzację, żeby wykrywać anomalie i szybko reagować na zmiany ryzyka.

CISA rozwija ten temat w pięciu obszarach dojrzałości: tożsamości, urządzeniach, sieci, danych oraz aplikacjach i workloadach. To dobry punkt odniesienia, bo pokazuje, że wdrożenie nie sprowadza się do jednego narzędzia zakupionego przez zespół IT. To raczej proces porządkowania całego środowiska, warstwa po warstwie.

Największy błąd, jaki widzę, to próba wdrożenia wszystkiego naraz. Taki projekt szybko gubi się w integracjach i wyjątkach. Lepiej zacząć od jednego procesu biznesowego, na przykład dostępu do systemu finansowego lub panelu administracyjnego SaaS, i dopiero potem rozszerzać zasady na kolejne obszary. Dzięki temu szybciej widać efekt, a zespół łatwiej rozumie, po co w ogóle zmieniamy reguły dostępu.

To jednak nie znaczy, że każdy przypadek nadaje się do wdrożenia w identyczny sposób. Właśnie tutaj pojawiają się największe przewagi i ograniczenia tego modelu.

Gdzie daje największą przewagę, a gdzie rozczarowuje

Model zerowego zaufania szczególnie dobrze działa tam, gdzie środowisko jest rozproszone, dynamiczne i mocno zależne od tożsamości. Najwięcej zyskują organizacje z pracą hybrydową, dużą liczbą aplikacji SaaS, zespołami zewnętrznymi, partnerami technologicznymi oraz danymi o wyższej wrażliwości. Im więcej ruchu odbywa się poza jedną lokalizacją, tym mniej sensu ma myślenie o jednej „bezpiecznej” sieci.

• Środowiska hybrydowe - bo użytkownicy łączą się z wielu miejsc i urządzeń.
• Chmura i SaaS - bo dostęp trzeba kontrolować na poziomie aplikacji, a nie biurowego adresu IP.
• Praca z partnerami i kontrahentami - bo zakres uprawnień da się zawęzić dużo dokładniej.
• Dane wrażliwe - bo ograniczenie blast radius naprawdę ma znaczenie po incydencie.

Rozczarowanie pojawia się wtedy, gdy ktoś oczekuje cudownego efektu bez porządkowania fundamentów. Jeśli firma nie wie, kto ma jakie uprawnienia, nie ma spójnego zarządzania urządzeniami albo pozwala na dziesiątki wyjątków „bo to ważny dział”, to model nie zadziała tak, jak powinien. Zero zaufania nie naprawia bałaganu samo z siebie; ono tylko ujawnia go szybciej.

Wniosek jest prosty: ten model najlepiej działa wtedy, gdy łączysz go z realistycznym planem wdrożenia, a nie z listą życzeń. I właśnie dlatego sensownie jest zakończyć go krótką listą priorytetów na start.

Od czego zacząć, żeby zobaczyć efekt najszybciej

Jeśli chciałbym zobaczyć szybki, mierzalny efekt, zacząłbym od jednego procesu krytycznego i czterech twardych reguł. To wystarcza, by od razu obniżyć ryzyko, a jednocześnie nie rozbić organizacji o zbyt duży zakres zmian.

• Wybierz jeden zasób o wysokiej wartości, na przykład system finansowy, CRM, repozytorium kodu lub panel administracyjny.
• Włącz MFA i warunkowy dostęp dla wszystkich kont w tym obszarze, bez wyjątków „na próbę”.
• Usuń stałe nadmiarowe uprawnienia i zastąp je dostępem czasowym, gdy to możliwe.
• Sprawdzaj stan urządzenia, zanim sesja dostanie dostęp do wrażliwych danych.
• Ustal metryki: liczba zablokowanych logowań ryzykownych, liczba wyjątków, czas reakcji na incydent i zakres dostępu po kompromitacji konta.

Najlepsze wdrożenia nie próbują być idealne od pierwszego dnia. Są konsekwentne, etapowe i oparte na realnym ryzyku. Jeśli miałbym zostawić jedną praktyczną zasadę, byłaby prosta: zamień domyślne zaufanie na weryfikację tożsamości, stanu urządzenia i kontekstu, a dopiero potem porządkuj resztę warstw. To właśnie wtedy ten model zaczyna działać jak porządna strategia bezpieczeństwa, a nie jak modne hasło.