Miért nem fedhet le egyetlen OTP Wi-Fi-t, VPN-t és egy registryt

Az egyszeri bejelentkezés egy identitást és kevesebb kérést ígér, és az ígéret a harmadik protokollnál eltörik. A csapda azt feltételezni, hogy egyetlen sikeres hitelesítés olyan tokent állít elő, amelyet minden más protokoll be tud mutatni. A Wi-Fi-belépés, a VPN-belépés és egy konténer-registry mind más cserét futtat, különböző közönségekkel és élettartamokkal. A fiók megosztása címtár-döntés; a hitelesítő adat megosztása protokoll-döntés, és a protokollok ritkán értenek egyet.

Három csere, három tulajdonos

A vállalati Wi-Fi EAP-metódust futtat a 802.1X-en belül, amelyet általában egy RADIUS-szolgáltatás zár le, saját nézettel a felhasználóról vagy az eszközről. A VPN-átjáró a saját támogatott folyamán keresztül hitelesít, majd saját újrahitelesítési időzítővel tartja a munkamenetet. A registry egy nem hitelesített kérést olyan kihívással válaszol meg, amely token-szolgáltatást, közönséget és hatókört nevez meg, és az ügyfél a hitelesítő adatát rövid élettartamú tokenre cseréli.

Ezek nem egy munkamenet három nézete. Mindegyiknek saját ellenőrzője, saját élettartama és saját visszavonási útvonala van, ezért a címtárban végzett jelszócsere az egyiket működőképesen, a másikat törötten hagyhatja. Kezelje őket három integrációként, amelyek véletlenül közös felhasználói címtárat használnak.

Mit hordoz a böngésző SSO-ja és mit nem

A böngésző-munkamenet egy identitásszolgáltatónál valóban hasznos: a hozzá átirányító alkalmazások öröklik a bejelentkezést, amelyet a felhasználó már befejezett. Ez azért működik, mert azok az alkalmazások ugyanazokat az átirányítási és tokenprotokollokat beszélik, és ugyanazt a közönséget fogadják el. Az EAP-t beszélő kérelmezőnek nincs követhető átirányítása, és a registry-kihívást kapó Docker-ügyfél nem OIDC identitástokent kér. Az identitásszolgáltató csak azokért a protokollokért kezeskedhet, amelyekre épült.

A hiba könnyen látható a naplókban, ha tudja, hol keresse. Az identitásszolgáltató sikeres bejelentkezést jelent, miközben a Wi-Fi-társítás továbbra is meghiúsul, vagy a registry 401-et ad vissza egy olyan tokencsere után, amelyet a böngésző soha nem látott. Két siker és egy hiba nem ellentmondás; az három külön hitelesítés.

Ahol a tanúsítvány felváltja az ismételt kódot

Kezelt eszközöknél a tanúsítványalapú EAP eltávolítja az emberi lépést anélkül, hogy eltávolítaná az identitást: az eszköz tanúsítványt mutat be, a RADIUS-szolgáltatás ellenőrzi a kibocsátó hatóságnál, és a visszavonás annál a hatóságnál történik, nem egy megosztott titokban. Az ár az életciklus-munka, mert a tanúsítványok lejárnak, és előbb meg kell újítani őket.

A registryknél hasonló a felosztás. Az interaktív felhasználó egyszer bejelentkezhet, és hagyhatja, hogy egy hitelesítőadat-segéd tárolja a kapott tokent, míg az automatizálásnak szűken korlátozott szolgáltatáshitelesítő adatot vagy számítási terhelés-identitást kell használnia. Egyik sem lehet egy ember egyszeri kódja, amelyet csővezetékbe másoltak. A segéd egy adott registry-közönség tokenjét tárolja, így nem irányítható át a VPN-átjáróra egy konfigurációs fájl szerkesztésével.

docker login registry.example.com

Hasonlítsa össze a karbantartási költséget, ne a kérések számát

A megosztott hitelesítő adat olcsónak tűnik, mert a munka láthatatlan, amíg meg nem hibásodik. Számolja inkább össze, mit költenek a lehetőségek egy év alatt: regisztráció, megújítás, visszavonás, egy szivárgás hatássugara és az érintett rendszerek száma, amikor valaki távozik. A tanúsítványflotta többet kerül felépíteni és kevesebbet üzemeltetni nagy léptékben; a másolt kód semmibe nem kerül elkezdeni, és mindenbe kigombolyítani.

Aztán szakaszonként válasszon, nem globálisan. A Wi-Fi áttérhet tanúsítványokra, a VPN megtarthatja a támogatott SSO-t MFA-val, és a registry használhat kifejezett hatókörű tokeneket. Jegyezze fel a tulajdonost, a közönséget, a hatókört, a lejáratot és a visszavonási útvonalat mindegyiknél, és a kérések ott fognak esni, ahol kell, nem egyszerre mindenhol. Ez a nyilvántartás a válasz akkor is, amikor egy auditor azt kérdezi, mely rendszerek bíznak még jelszóban.