Zero Trust, VPN i inspekcja TLS pełnią różne funkcje

Dokumenty zakupowe traktują zero trust, VPN i inspekcję TLS jak ten sam zakup, a każdy z nich odpowiada na pytanie, na które pozostałe nie potrafią. Tunel buduje chronioną ścieżkę, brama inspekcyjna czyta ruch, który potrafi zakończyć, a polityka decyduje, czy nazwana tożsamość może wykonać nazwaną operację na nazwanym zasobie. Tylko ta ostatnia jest decyzją autoryzacyjną. Produkt może doskonale realizować dwie pierwsze i nadal pozostawiać prawdziwe pytanie otwarte.

Trzy mechanizmy, trzy pytania

Tunel odpowiada, jak ruch dociera do sieci. Brama inspekcyjna odpowiada, co może zobaczyć i zrobić urządzenie pośredniczące tam, gdzie ma uprawnienia do zakończenia TLS. Silnik polityki odpowiada, kto może co zrobić z którym zasobem, a potem potrzebuje punktu egzekwowania, który potrafi zastosować tę odpowiedź. Architektura zero trust według NIST stawia zasób w centrum i odmawia wywnioskowania zaufania z tego, skąd przyszedł pakiet.

Takie ujęcie jest trudniejsze do spełnienia niż etykieta i znacznie trudniejsze do podrobienia w przeglądzie. Przenosi też pytanie z tego, jakie produkty wdrożono, na to, jakie decyzje są egzekwowane i przez co.

Gdzie decyzja jest faktycznie stosowana

Weź jedno żądanie: inżynier wsparcia otwiera konsolę usługi, a maszyna prywatna podłączona do tego samego przełącznika nie może odziedziczyć tego uprawnienia tylko dlatego, że jest w pobliżu. Zapisz dozwoloną operację, warunki urządzenia i komponent, który je egzekwuje. Umiejscowienie decyduje o wszystkim: brama aplikacyjna, proxy usługi, kontrola hosta albo inna granica, którą organizacja naprawdę wspiera. Czymkolwiek jest ten komponent, musi leżeć na ścieżce zarówno prób zdalnych, jak i lokalnych.

Ruch, który nigdy nie przekracza wejścia VPN, nie jest regulowany przez kontrolę wykonywaną tam, choćby była najstaranniejsza. Właśnie ta jedna luka wyjaśnia większość dystansu między diagramem zero trust a działającym wdrożeniem. Narysuj ścieżkę żądania, zanim narysujesz architekturę.

Odszyfrowanie nie jest autoryzacją

Przechwytywanie służy wąskim celom inspekcyjnym i niesie własny ciężar certyfikatów, zaufanych korzeni, przeglądu prywatności i aplikacji, które się pod nim psują. Nic z tego nie jest znaczeniem zero trust i nic z tego nie zastępuje decyzji polityki. Uwierzytelnienie osoby i autoryzacja usługi są całkowicie możliwe bez odszyfrowania choćby jednego pakietu. Odszyfrowany strumień nie mówi nic o tym, czy użytkownik miał prawo do operacji, którą transportuje.

Polityka potrzebuje jednego rodzaju dowodu, a odszyfrowanie nim nie jest. Stan urządzenia to jeden z danych wejściowych obok tożsamości, wrażliwości zasobu i kontekstu, a jednorazowe przejście nie daje tej maszynie reszty sieci. Mieszanie obu zamienia pytanie autoryzacyjne w projekt certyfikatów.

Gdy bramy nie ma nigdzie na ścieżce

Zinwentaryzuj, co podróżuje bez dotykania zdalnej bramy: połączenia między maszynami w segmencie lokalnym, wywołania z jednego obciążenia roboczego do drugiego i punkty końcowe osiągane bezpośrednio wewnątrz konta chmurowego. Dla każdej ścieżki wskaż metodę egzekwowania, którą naprawdę można dziś wdrożyć. Sprzęt, który nie może hostować agenta, nadal potrzebuje innej wyraźnie wspieranej kontroli, a założenie, że agent pojawi się później, nic teraz nie zamyka. Dostęp między usługami zwykle lepiej pasuje do tożsamości obciążenia roboczego i kontroli napisanej wobec zasobu niż do kolejnej sieci nakładkowej.

Przyjmij projekt po zachowaniu, a nie po diagramach: które operacje są dozwolone, które odrzucane i gdzie każda odpowiedź jest egzekwowana. Zatwierdź konkretne dozwolone i odrzucone operacje oraz uwzględnij jedną trasę lokalną, która nigdy nie dociera do bramy. Zapisz, kto jest właścicielem polityki, jak się zmienia i jak działa odwołanie.

Przemianowany tunel nadal jest tunelem. Polityka decyduje, a coś musi ją egzekwować.