Skąd pochodzi Zero Trust
Termin “Zero Trust” został spopularyzowany przez analityka Johna Kindervaga w 2010 roku, ale idea sięga wcześniej. Klasyczny model bezpieczeństwa zakładał podział na “wewnątrz sieci” (zaufane) i “na zewnątrz” (niezaufane). Firewall na granicy chronił wszystko co było w środku.
Ten model przestał działać z chwilą gdy infrastruktura przestała być fizyczna i zlokalizowana. Chmura, praca zdalna, SaaS, mikroserwisy — wszystko to oznacza że nie ma już wyraźnej granicy między “wewnątrz” a “na zewnątrz”. Atakujący który uzyska dostęp do jednego zasobu wewnętrznego ma dostęp do wszystkiego co ten zasób może osiągnąć — bo sieć wewnętrzna mu ufa.
Trzy zasady Zero Trust
Architektura Zero Trust opiera się na trzech zasadach które brzmią prosto, ale wymagają przemyślanego wdrożenia:
Nigdy nie ufaj, zawsze weryfikuj. Każde żądanie dostępu — niezależnie od źródła — musi być uwierzytelnione i autoryzowane. Fakt że żądanie pochodzi z wewnętrznej sieci nie jest wystarczającym dowodem tożsamości. Każda interakcja między serwisami, każdy dostęp do danych, każde uruchomienie pipeline’u wymaga weryfikacji tożsamości.
Zasada minimalnych uprawnień. Każdy podmiot — użytkownik, serwis, pipeline — powinien mieć dostęp tylko do tego co jest mu niezbędne do wykonania konkretnego zadania. Nie “dostęp do wszystkich sekretów organizacji” ale “dostęp do sekretów potrzebnych do tego konkretnego deploymentu”. Nie “admin całego projektu” ale “prawo do odczytu konkretnego repozytorium”.
Zakładaj naruszenie. Projektuj systemy zakładając że dojdzie do kompromitacji — i minimalizuj wpływ gdy to nastąpi. Segmentacja, audyt, możliwość szybkiego odwołania dostępów.
Zero Trust a pipeline CI/CD
Pipeline CI/CD jest jednym z najtrudniejszych środowisk do zastosowania Zero Trust — bo tradycyjnie jest projektowany dla wygody, nie dla bezpieczeństwa. Jeden token z pełnym dostępem do chmury. Wspólne środowisko wykonania dla wszystkich jobów. Sekrety dostępne w zmiennych środowiskowych dla całego pipeline’u.
Każdy z tych elementów jest sprzeczny z zasadami Zero Trust. Token powinien być krótkotrwały i minimalnie uprawiony. Środowisko wykonania powinno być izolowane między jobami. Dostęp do sekretów powinien być ograniczony do konkretnych etapów pipeline’u które ich potrzebują.
Dojrzałość Zero Trust w organizacji
CISA (US Cybersecurity and Infrastructure Security Agency) opublikowała model dojrzałości Zero Trust z pięcioma filarami: tożsamość, urządzenia, sieci, aplikacje i dane. Każdy filar ma trzy poziomy dojrzałości: tradycyjny, zaawansowany i optymalny.
Większość organizacji które nie miały formalnego programu bezpieczeństwa jest na poziomie “tradycyjnym” we wszystkich filarach. Przejście do “zaawansowanego” w ciągu roku jest ambitne ale realistyczne — jeśli jest to priorytet z odpowiednimi zasobami. Poziom “optymalny” to cel długoterminowy który większość dojrzałych organizacji osiąga przez lata iteracji.
Kluczowe jest że Zero Trust nie jest binarny — to spektrum dojrzałości. Każdy krok w kierunku mniejszego zaufania implicitnego i większej weryfikacji explicite zmniejsza ryzyko. Nie trzeba osiągnąć perfekcji żeby osiągnąć znaczącą poprawę.
Czytaj również: