Utrzymywanie tunelu przez całą dobę to decyzja projektowa, która ma wersję uzasadnioną i wersję nieostrożną. Oddział, który przez cały dzień potrzebuje aplikacji centralnej, a w nocy wykonuje kopię zapasową, ma powód. Laptop pozostawiony podłączony w pokoju hotelowym na trzy dni to wypadek.

Oba pokazują tę samą zieloną ikonę i oba odpowiedzą tak samo, gdy zapytać, jak długo tunel jest podniesiony. Ta liczba nie jest ciekawa. Liczy się to, co połączenie utrzymuje dostępnym, dla kogo i co faktycznie je kończy.

Trzy zegary, które chodzą osobno

Pierwszy stan to ścieżka. Tunel i jego polityki czynią zestaw usług osiągalnym, a łącze bez ruchu może pozostać gotowe na kolejne żądanie. To, jak długo pozostaje gotowe, jest decyzją implementacji, a nie uniwersalnym licznikiem.

Drugi stan to uprawnienie. Zaakceptowana tożsamość lub urządzenie może być upoważnione do korzystania z tej ścieżki. To upoważnienie powinno się zmienić, gdy zmienia się rola, urządzenie znika lub podejrzewa się naruszenie, i jest niezależne od tego, czy pakiety płyną.

Trzeci stan to własna sesja aplikacji. Klient bazy danych, pulpit zdalny albo aplikacja webowa uwierzytelnia się osobno i utrzymuje własny stan. Zamknięcie tunelu nie kończy koniecznie żadnego z nich.

Przegląd, który traktuje te sprawy jako jedno pytanie, kończy się sporem o liczniki bezczynności. Każdy z trzech może być zdrowy lub zepsuty osobno, a ustalenie w jednym niewiele mówi o pozostałych. Lista kontrolna z trzema liniami bije debatę o jednej wartości limitu czasu. Odpowiedź dla każdego stanu zapisz osobno.

Tunel to ścieżka, nie odznaka

Ustanowiony tunel jest dowodem, że między dwoma punktami końcowymi istnieje chroniona ścieżka. Nie jest dowodem, że każdy proces za którymkolwiek punktem końcowym powinien docierać do każdej usługi po drugiej stronie.

Wytyczne NIST dotyczące zero trust mówią to samo z drugiej strony: lokalizacji sieciowej nie należy traktować jako domniemanego zaufania. Łącze lokacji to fakt transportowy, a uprawnienie jednego hosta do korzystania z jednej aplikacji to odrębna decyzja z własnym właścicielem.

Naruszone urządzenie peer może nadal próbować szkodliwych działań przez usługi, do których ma dostęp. Filtrowanie i monitorowanie ograniczają konkretne ryzyka, nie zacierając skutków naruszenia punktu końcowego. Projektuj pod ścieżkę, a upoważniaj pod usługę.

Uzasadnianie stałego łącza lokacji

Obronna wersja zawsze włączonego rozwiązania nazywa swój cel precyzyjnie. Które źródła, które cele, który kierunek i kto jest właścicielem każdego wpisu. Zapora oddziałowa, która zezwala każdemu hostowi oddziału na każdą centralną podsieć, nie utrzymuje łącza dla nazwanego celu; utrzymuje je dla wszystkiego, co komuś przyjdzie do głowy później.

Gdy peer nie może spełnić wymaganego poziomu zaufania, zawęź granicę albo zmień rozwiązanie. Poleganie na sporadycznym ręcznym rozłączeniu jest kontrolą procesu, a kontrole procesu są najmniej niezawodne właśnie wtedy, gdy incydent czyni je niewygodnymi.

Trzymaj uzasadnienie razem z konfiguracją. Stały wyjątek z zapisanym celem można przejrzeć i wycofać. Wyjątek bez celu staje się stały domyślnie.

Zmiana kluczy to nie unieważnienie

Wymiana kluczy według harmonogramu utrzymuje cykl ochrony. Odświeża materiał i zachowuje poufność. Nie usuwa uprawnienia punktu końcowego.

Jeśli punkt końcowy nadal ma ważne poświadczenia i politykę dostępu, która go akceptuje, następne uzgadnianie przywróci tę samą dozwoloną ścieżkę. Dlatego zdanie o kluczach obracanych co godzinę nie jest odpowiedzią na zgubione urządzenie: zgubione urządzenie też się obraca, dopóki jego tożsamość jest zaufana. Sprawdź uprawnienie, zanim sprawdzisz harmonogram. Rotacja to higiena, a unieważnienie to decyzja o dostępie.

Unieważnienie to inny mechanizm z własnym opóźnieniem: unieważniony certyfikat, wyłączone konto, zmieniona grupa, usunięta reguła sieciowa. Każdy działa w innym momencie i każdy zachowuje się inaczej wobec sesji już ustanowionych.

Kończenie tego, co już działa

Zapytaj, co implementacja robi z ustanowionymi sesjami, gdy dostęp zostaje odebrany. Może je zakończyć, czekać na wygaśnięcie albo zastosować udokumentowane zachowanie pośrednie. Nie zakładaj, że jutrzejsza zmiana dopuszczenia zamknie dzisiejsze połączenie aplikacji.

Dla dostępu interaktywnego limity sesji i reguły bezczynności oddaj w ręce właścicieli tożsamości i VPN, a nie tylko zespołu sieciowego. Dla usługi lokacji ustal procedurę, której konserwacja, awaria lub incydent bezpieczeństwa używa do wyłączenia dostępu.

Potem przetestuj trzy wyniki: dozwolona praca nadal działa, niepowiązana usługa jest odrzucana, a procedura usunięcia daje udokumentowany rezultat. Projekt zawsze włączony jest do przyjęcia, gdy jego cel, upoważnienie i możliwość wyłączenia są zapisane i przećwiczone. Inaczej to udogodnienie, które przeżyło swój powód.

Powiązane artykuły