Zero Trust dla firm digital-first

czym naprawdę jest Zero Trust

Termin wprowadził analityk John Kindervag z Forrester Research w 2010 roku. Podstawowa obserwacja była prosta: modele bezpieczeństwa oparte na obwodzie zakładają, że wszystko wewnątrz granicy sieci jest zaufane, a to założenie jest błędne. Konta wewnętrzne bywają kompromitowane. Kontraktorzy przynoszą niezarządzane urządzenia. Usługi chmurowe całkowicie rozpuszczają obwód. Zero Trust zastępuje to założenie innym: żaden użytkownik, urządzenie ani połączenie nie jest domyślnie zaufane, niezależnie od tego, skąd pochodzi. Każde żądanie dostępu jest oceniane na podstawie tego, kto pyta, o co pyta, z jakiego urządzenia i kontekstu, oraz czy powinien to mieć.

National Institute of Standards and Technology (NIST) sformalizował to w SP 800-207, opublikowanym w 2020 roku. Ten dokument definiuje architekturę Zero Trust jako zestaw wytycznych dla przepływu pracy, projektowania systemów i operacji, a nie pojedynczy produkt czy technologię. To rozróżnienie ma znaczenie, gdy dostawcy mówią, że ich platforma „dostarcza Zero Trust". Żadna pojedyncza platforma tego nie robi. Model wymaga stosowania zasad w wielu obszarach kontroli.

trzy zasady

Każdy wiarygodny framework Zero Trust sprowadza się do trzech zasad. Weryfikuj jawnie: każde żądanie dostępu jest uwierzytelniane i autoryzowane na podstawie wszystkich dostępnych punktów danych, przy czym tożsamość użytkownika, stan urządzenia, lokalizacja i wrażliwość zasobu zasilają decyzję o dostępie, bo sama ważna nazwa użytkownika i hasło to za mało jako weryfikacja. Stosuj least privilege: użytkownicy i systemy otrzymują minimalny dostęp potrzebny do wykonania bieżącej funkcji, zakresowany przez rolę, czas i kontekst, przy czym szerokie, trwałe uprawnienia zastępuje się węższymi nadaniami, które można przeglądać, dostosowywać i odbierać. Zakładaj naruszenie: projektuj i działaj tak, jakby atakujący już był obecny, segmentuj dostęp tak, żeby skompromitowane konto docierało tylko tam, gdzie miało prawo dotrzeć, i loguj oraz monitoruj wszystko, żeby nietypowy dostęp był wykrywalny. Te zasady są ze sobą powiązane: least privilege jest skuteczne tylko wtedy, gdy dostęp jest weryfikowany w sposób ciągły, a zakładanie naruszenia zmniejsza szkody tylko wtedy, gdy środowisko jest faktycznie posegmentowane. To system, nie checklista.

czemu tożsamość jest fundamentem

W środowisku cloud-first, rozproszonym, lokalizacja sieciowa stała się słabym zastępnikiem zaufania. Użytkownik w sieci firmowej może być zagrożeniem. Użytkownik na domowym łączu szerokopasmowym może być legalny. Tym, co pozostaje stałe i na czym opiera się Zero Trust, jest tożsamość. Tożsamość to płaszczyzna kontroli: decyzja o dostępie zaczyna się od tego, kim jest ta osoba, czy jej tożsamość została zweryfikowana, czy jej bieżące urządzenie i kontekst pasują do oczekiwanych, i czy jej rola uzasadnia to żądanie dostępu.

Dlatego luki w tożsamości podkopują każdą inną kontrolę Zero Trust. Do konta bez MFA można dotrzeć samymi danymi uwierzytelniającymi, a użycie skradzionych danych uwierzytelniających było zaangażowane w 36% naruszeń (Verizon DBIR). Konto, które już nie należy do aktywnego pracownika, ale nigdy nie zostało odebrane, daje atakującemu ważną tożsamość, z której może działać, a 83% pracowników przyznaje, że wciąż ma dostęp do co najmniej jednego konta u poprzedniego pracodawcy (Beyond Identity, 2022, dane self-reported). Użytkownik z dostępem znacznie szerszym, niż wymaga tego jego rola, daje skutecznemu atakującemu dużo większy blast radius. Zanim sprawdzanie stanu urządzenia, segmentacja sieci czy ciągłe monitorowanie zaczną przynosić realną wartość, warstwa tożsamości musi być solidna. Pytanie o widoczność jest pierwsze: kto ma dostęp do czego i czy to wciąż jest poprawne?

praktyczne elementy składowe

Zero Trust dla firmy z segmentu mid-market buduje się ze składników, które już są znane. Praca polega na świadomym i konsekwentnym ich stosowaniu.

Silna tożsamość i MFA wszędzie. Jeden centralny dostawca tożsamości, przez którego uwierzytelniają się wszyscy użytkownicy, single sign-on, tak żeby zamknięcie centralnego konta zamykało dostęp wszędzie tam, gdzie rządzi ten IdP, i MFA egzekwowane na każdym koncie, bez wyjątków dla kont administratorów czy przestarzałych konfiguracji. MFA blokuje ponad 99,2% ataków polegających na przejęciu konta (Microsoft), a ta liczba dotyczy kont z wymuszonym MFA, więc każde konto bez niego pozostaje poza tą ochroną. Konta administratorów bez MFA to dane uwierzytelniające o najwyższym uprzywilejowaniu w środowisku, chronione samym hasłem. Dla aplikacji SaaS, które uwierzytelniają się bezpośrednio, a nie przez IdP, MFA dostawcy tożsamości nie daje żadnej ochrony, więc te aplikacje potrzebują własnego MFA albo trzeba je objąć SSO.

Least privilege i przeglądy dostępów. Uprawnienia użytkowników zakresowane do bieżącej roli i bieżącej potrzeby, z cyklem przeglądu działającym kwartalnie dla kont uprzywilejowanych i co pół roku dla dostępu standardowego, gdzie właściciele zasobów potwierdzają, kto wciąż powinien co mieć. Dostęp domyślnie narasta: awanse dodają uprawnienia, zmiany roli dodają uprawnienia nowej roli bez usuwania starych, a kontraktorzy, których projekty się zakończyły, wciąż widnieją w narzędziach. Bez uporządkowanego cyklu przeglądu uprawnienia tylko rosną.

Stan urządzenia. Decyzja o dostępie jest silniejsza, gdy uwzględnia kondycję urządzenia wysyłającego żądanie: czy jest zarządzane, czy system operacyjny jest aktualny, czy jest zarejestrowane w katalogu. Sprawdzanie stanu urządzenia jest dostępne w większości nowoczesnych IdP i platform do zarządzania punktami końcowymi; w minimalnej wersji oznacza to rozróżnianie urządzeń zarządzanych od niezarządzanych i stosowanie surowszych polityk dostępu do tych niezarządzanych.

Segmentacja sieci. Płaskie sieci wewnętrzne, w których każdy uwierzytelniony użytkownik może dotrzeć do każdego systemu, powiększają blast radius skompromitowanego konta. Segmentacja oznacza, że skompromitowane konto dociera tylko do systemów, do których miało dotrzeć. W środowiskach chmurowych przekłada się to na dobrze zakresowane polityki IAM, grupy zabezpieczeń i uprawnienia na poziomie zasobów; zasada jest ta sama: ogranicz ruch boczny, ograniczając to, do czego może dotrzeć pojedyncze konto.

Ciągła weryfikacja i logowanie zdarzeń. Nie należy zakładać, że dostęp przyznany przy logowaniu pozostaje ważny bezterminowo. Długość sesji, wymogi ponownego uwierzytelnienia i wykrywanie anomalii wspólnie tworzą ciągłą weryfikację, a sesja, która zachowuje się nieoczekiwanie, może wywołać dodatkowe uwierzytelnienie albo alert. Logowanie zdarzeń jest warunkiem koniecznym dla tego wszystkiego: działania administratorów, zdarzenia uwierzytelniania, dostęp do wrażliwych zasobów i zmiany konfiguracji powinny generować logi audytowe, bo bez logów wykrywanie anomalii nie ma na czym pracować, a reagowanie na incydenty nie ma czego analizować.

Zarządzanie dostępem uprzywilejowanym (PAM). Uprawnienia administratora to dane uwierzytelniające o najwyższej wartości w każdym środowisku. Podstawową praktyką jest rozdzielenie: konto standardowe do codziennej pracy i osobne konto administratora używane tylko wtedy, gdy potrzebny jest podwyższony dostęp, co trzyma dane uwierzytelniające administratora z dala od codziennej ekspozycji na phishing, przeglądarkę i schowek, na jaką narażone są konta codziennego użytku. Dla środowisk z wieloma kontami uprzywilejowanymi dedykowane narzędzia PAM dodają nagrywanie sesji, przechowywanie danych uwierzytelniających w skarbcu i dostęp just-in-time.

etapowa ścieżka startowa

Zero Trust nie wymaga wymiany infrastruktury. Firmy, które utykają w miejscu, zwykle czekają na cykl budżetowy, żeby sfinansować pełną wymianę; firmy, które robią postępy, zaczynają od tego, co mają. Faza 1 to widoczność: sporządź kompletną inwentaryzację kont w całym środowisku tożsamości, w tym kont ludzkich, serwisowych, administratorskich i kontraktorskich oraz grantów OAuth, zmapuj, które aplikacje są objęte zarządzaniem IdP albo SSO, a które uwierzytelniają się niezależnie, i sprawdź pokrycie MFA dla każdego konta, zaczynając od kont na poziomie administratora, traktując inwentaryzację jako punkt odniesienia, a nie jednorazowe ćwiczenie. Faza 2 to fundament tożsamości: wyegzekwuj MFA na każdym koncie administratora, a potem na każdym koncie użytkownika, obejmij niezarządzane aplikacje SaaS SSO tam, gdzie to możliwe, odbierz dostęp kontom byłych pracowników i kontraktorów oraz ustanów podstawowy proces joiner-mover-leaver powiązany ze zdarzeniami HR; to inwestycja o najwyższym zwrocie z wysiłku w całej progresji i zamyka najczęściej wykorzystywane luki bez nowej infrastruktury. Faza 3 to least privilege i przeglądy: zakresuj uprawnienia do bieżącej roli, przeprowadź pierwszy cykl przeglądu dostępów, oddziel konta administratorów od kont codziennego użytku i ustanów trwały rytm przeglądów. Faza 4 to stan urządzenia i segmentacja: wprowadź polityki zgodności urządzeń, rozróżniaj urządzenia zarządzane od niezarządzanych w polityce dostępu i segmentuj sieć wewnętrzną oraz polityki IAM w chmurze. Faza 5 to ciągła weryfikacja i dojrzałość: dodaj wykrywanie anomalii i adaptacyjne ponowne uwierzytelnianie, rozszerz logowanie zdarzeń, wprowadź dostęp just-in-time do operacji uprzywilejowanych i prowadź przeglądy dostępów jako osadzony proces. Większość organizacji z segmentu mid-market może dotrzeć do końca fazy 3 bez wdrażania jakichkolwiek nowych narzędzi bezpieczeństwa, bo praca dotyczy procesu i konfiguracji, nie zakupów.

jak to mapuje się na standardy

NIST SP 800-207 to autorytatywny punkt odniesienia dla architektury Zero Trust, definiujący zasady, komponenty logiczne i modele wdrożenia. Kontrole ISO 27001 Annex A obejmujące zarządzanie dostępem (5.15, 5.18), uwierzytelnianie (8.2, 8.5), dostęp uprzywilejowany (5.16) i segmentację sieci (8.22) mapują się bezpośrednio na elementy składowe Zero Trust, więc organizacje budujące model od podstaw po drodze spełniają wiele kontroli ISO 27001. Artykuł 21 NIS2 wymaga kontroli dostępu, uwierzytelniania wieloskładnikowego i segmentacji sieci, czyli fundamentów Zero Trust. Wymogi bezpieczeństwa ICT DORA (artykuł 9) obejmują kontrolę dostępu, zarządzanie dostępem uprzywilejowanym i ciągłe monitorowanie, co pokrywa program Zero Trust adresujący tożsamość, least privilege i logowanie zdarzeń. Wymogi minimalizacji danych i ograniczenia dostępu z RODO dobrze obsługuje least privilege. Zgodność regulacyjna nie jest powodem, żeby budować program Zero Trust; powodem jest to, że większość naruszeń podąża za wzorcami, które model ma za zadanie przerywać, a zgodność z regulacjami jest produktem ubocznym poprawnie wykonanej pracy.

częste błędy i pułapki dostawców

Kilku dużych dostawców sprzedaje platformy opisywane jako dostarczające Zero Trust, a kupno jednej jako pierwszy krok to błąd kategorii: niektóre są naprawdę użytecznymi komponentami, ale żadna sama w sobie nie dostarcza modelu, który wymaga współpracy warstw tożsamości, urządzeń, sieci i monitorowania, więc twierdzenia dostawców trzeba oceniać względem NIST SP 800-207 i kupować pod luki w istniejącej architekturze. Zaczynanie od segmentacji sieci, zanim tożsamość jest solidna, daje ograniczoną wartość, bo atakujący z ważnymi, nadmiernie uprzywilejowanymi danymi uwierzytelniającymi może działać wewnątrz dobrze posegmentowanej sieci; tożsamość jest warunkiem wstępnym. Traktowanie Zero Trust jako projektu z datą zakończenia to błędne odczytanie, bo to model operacyjny, a środowisko, którym rządzi, zmienia się nieustannie, więc kontrole, które zostały ustawione, ale nie są utrzymywane, degradują się. Pominięcie fazy widoczności daje polityki, które pomijają faktyczne luki, a częstym przykładem jest organizacja, która egzekwuje MFA przez swój IdP i zainwestowała w zarządzanie punktami końcowymi, a mimo to wciąż ma tuzin byłych pracowników z aktywnymi kontami w aplikacjach SaaS, które nigdy nie połączyły się z IdP. A luki w MFA na przestarzałych konfiguracjach utrzymują się latami po tym, jak MFA zostało „wdrożone", w kontach sprzed polityki, konfiguracjach administratorskich wyłączonych dla wygody i VPN, który nigdy nie został zaktualizowany.