Dlaczego jeden OTP nie obejmuje Wi-Fi, VPN i rejestru

Pojedyncze logowanie obiecuje jedną tożsamość i mniej monitów, a obietnica łamie się na trzecim protokole. Pułapką jest założenie, że jedno udane uwierzytelnienie tworzy token, który może przedstawić każdy inny protokół. Dostęp do Wi-Fi, wejście VPN i rejestr kontenerów prowadzą każdy inną wymianę, z różnymi publicznościami i czasami życia. Współdzielenie konta to decyzja katalogu; współdzielenie poświadczeń to decyzja protokołu, a protokoły rzadko się zgadzają.

Trzy wymiany, trzech właścicieli

Firmowe Wi-Fi uruchamia metodę EAP wewnątrz 802.1X, zwykle kończoną przez usługę RADIUS, która ma własny pogląd na użytkownika lub urządzenie. Brama VPN uwierzytelnia się własnym obsługiwanym przepływem, a następnie utrzymuje sesję z własnym licznikiem ponownego uwierzytelnienia. Rejestr odpowiada na nieuwierzytelnione żądanie wyzwaniem, które nazywa usługę tokenów, publiczność i zakres, a klient wymienia swoje poświadczenia na krótkotrwały token.

To nie są trzy widoki jednej sesji. Każdy ma własny weryfikator, własny czas życia i własną ścieżkę unieważnienia, dlatego zmiana hasła w katalogu może zostawić jeden działający, a drugi zepsuty. Traktuj je jako trzy integracje, które przypadkiem dzielą katalog użytkowników.

Co przenosi SSO w przeglądarce, a czego nie

Sesja przeglądarki u dostawcy tożsamości jest naprawdę przydatna: aplikacje, które do niego przekierowują, dziedziczą logowanie, które użytkownik już ukończył. Działa to dlatego, że te aplikacje mówią tymi samymi protokołami przekierowania i tokenów oraz akceptują tę samą publiczność. Podmiot mówiący EAP nie ma żadnego przekierowania do wykonania, a klient Docker, który otrzymuje wyzwanie rejestru, nie prosi o token tożsamości OIDC. Dostawca tożsamości może poręczyć tylko za protokoły, dla których został zbudowany.

Awarię łatwo zobaczyć w logach, gdy wiadomo, gdzie patrzeć. Dostawca tożsamości zgłasza udane logowanie, podczas gdy skojarzenie Wi-Fi nadal się nie udaje, albo rejestr zwraca 401 po wymianie tokenu, której przeglądarka nigdy nie widziała. Dwa sukcesy i jedna porażka nie są sprzecznością; to trzy osobne uwierzytelnienia.

Gdzie certyfikat zastępuje powtarzany kod

W przypadku urządzeń zarządzanych EAP oparty na certyfikatach usuwa krok ludzki bez usuwania tożsamości: urządzenie przedstawia certyfikat, usługa RADIUS sprawdza go u wystawcy, a unieważnienie następuje u tego wystawcy, a nie we wspólnym sekrecie. Ceną jest praca cyklu życia, ponieważ certyfikaty wygasają i trzeba je odnowić wcześniej.

Rejestry mają równoważny podział. Użytkownik interaktywny może zalogować się raz i pozwolić pomocnikowi poświadczeń zapisać wynikowy token, podczas gdy automatyzacja powinna używać wąsko ograniczonych poświadczeń usługi lub tożsamości obciążenia. Żadne z nich nie powinno być jednorazowym kodem człowieka skopiowanym do potoku. Pomocnik przechowuje token dla konkretnej publiczności rejestru, więc nie można go przekierować na bramę VPN, edytując plik konfiguracji.

docker login registry.example.com

Porównaj koszt utrzymania, a nie liczbę monitów

Współdzielone poświadczenie wygląda tanio, bo praca jest niewidoczna, dopóki coś nie zawiedzie. Policz raczej, ile każda opcja kosztuje przez rok: rejestracja, odnowienie, unieważnienie, promień rażenia wycieku i liczba systemów dotkniętych, gdy ktoś odchodzi. Flota certyfikatów kosztuje więcej przy budowie i mniej przy eksploatacji w skali; skopiowany kod nie kosztuje nic na start i wszystko przy rozplątywaniu.

Potem wybieraj dla każdego odcinka, a nie globalnie. Wi-Fi może przejść na certyfikaty, VPN może zachować obsługiwane SSO z MFA, a rejestr może używać tokenów z jawnymi zakresami. Zapisz właściciela, publiczność, zakres, wygaśnięcie i ścieżkę unieważnienia dla każdego, a monity padną tam, gdzie powinny, zamiast wszędzie naraz. Ten zapis jest też odpowiedzią, gdy audytor pyta, które systemy nadal ufają hasłu.