Kiedy słyszę, że ktoś mówi, że „modernizował” aplikację, zazwyczaj oznacza to, że włączył SAML lub OIDC.
SSOczyniUprościć dostęp i zmniejszyć tarcie.Ale oto, co mnie martwi: zbyt wiele zespołów zatrzymuje się tam.Wdrażają SSO i zakładają, że trudna część jest skończona.Ale w praktyce to właśnie wtedy zaczyna się pojawiać prawdziwa złożoność.
Dlaczego „my modernizowaliśmy” nie zawsze oznacza to, co myślisz
Kiedy ludzie mówią mi, że ich aplikacja została zmodernizowana, pytam, co to naprawdę oznacza. W wielu przypadkach oznacza to tylko, że aplikacja obsługuje teraz SSO. Wciąż używa tej samej wewnętrznej logiki sesji. Autoryzacja jest nadal kodowana głęboko w aplikacji.
To, co się tutaj dzieje, jest bardziej powszechne niż większość przyznaje: modernizujemy drzwi przednie i pozostawiamy resztę domu niezmienioną.
I to jest problem, ponieważ tożsamość nie polega tylko na logowaniu się.
Co oferuje nowoczesna autoryzacja
Nowoczesne protokoły auth, takie jak SAML i OIDC, zostały zaprojektowane tak, aby rozwiązywać prawdziwe wyzwania – głównie logowanie i federacja.
I tak, SSO za pośrednictwem tych protokołów poprawia postawę bezpieczeństwa, ale nie mylmy wygody z kompletnością.
Protokoły są postępem - ale nie są linią końcową
Nie zrozumcie mnie źle, dodanie wsparcia dla OIDC lub SAML to postęp. Otrzymasz mniej haseł, mniej tarcia i bardziej spójne doświadczenie użytkownika. Co nie zapewniają, to inne krytyczne kontrolki, na które opieraliśmy się z systemami zarządzania dostępem do sieci Web (WAM): scentralizowana kontrola sesji, egzekwowanie uprawnień, integracja katalogów i spójne zarządzanie zasadami.
Systemy WAM nie były doskonałe, ale dały nam spójną warstwę sterowania w aplikacjach.Kiedy je usunęliśmy, nie zastępując tej warstwy, straciliśmy coś istotnego - i widziałem konsekwencje z pierwszej ręki.
Aplikacja nie jest nowoczesna, jeśli tożsamość jest nadal zakodowana
Widziałem aplikacje, które wyglądają szczupło na powierzchni, ale nadal opierają się na kruchych, specyficznych dla dewelopera tożsamościach.W tych przypadkach dodanie SSO nie rozwiązuje rzeczywistego ryzyka – niespójnego zachowania w aplikacjach i środowiskach.
Niektóre zespoły wciąż korzystają z przestarzałych bibliotek sesji. Inne kodują zasady dostępu w sposób, który sprawia, że audyt jest koszmarem.
Gdzie rzeczy się rozpadają: zarządzanie sesją
Jednym z największych ślepych punktów tożsamości w nowoczesnych środowiskach jest zarządzanie sesjami.
Dzięki WAM zachowanie sesji – przerwy czasowe, odnawiania, odwołania – było obsługiwane w jednym miejscu. Możesz zastosować zmianę polityki i wiedzieć, że będzie ona obowiązywać w całym przedsiębiorstwie.
Pracowałem z zespołami korzystającymi z Spring, Node.js, Rails – a nawet w ramach jednej ramki nie ma gwarancji spójności.
Niezdolność do egzekwowania spójnych terminów sesji jest ogromnym ryzykiem, jeśli nie mogą odwołać sesji, gdy dzieje się coś podejrzanego.
Koszty decentralizowanej logiki sesji
Gdy poprawienie bibliotek sesji zajmuje tygodnie lub miesiące, lub nikt nie wie, gdzie są zdefiniowane opóźnienia, zabezpieczenie staje się reaktywne w najlepszym przypadku.
To nie jest teoretyczne. Widziałem, że firmy starają się śledzić, jak ich obsługa sesji działa. stała się wiedzą plemienną, ukrytą głęboko w kodzie aplikacji.
Nie jest to zrównoważone – zwłaszcza dla przedsiębiorstw zajmujących się zgodnością lub celami Zero Trust.
Rozprzestrzenianie tożsamości i autoryzacja
To samo, co dzieje się z logiką sesji, dzieje się z autoryzacją.Kiedy jest ona przesuwana w dół do kodu aplikacji, niemal niemożliwe jest centralne zarządzanie.
Zasady są zakopane w logice biznesowej. Polityki drżą. I ostatecznie nikt nie wie dokładnie, kto ma dostęp do czego – lub dlaczego. Nawet aplikacje, które obsługują nowoczesną uwierzytelnianie, mogą się tu nie udać, ponieważ AuthZ nie jest częścią protokołu.
Orkiestra musi przyjść
W tym momencie myślę, że jest jasne: nowoczesna uwierzytelnianie to tylko jeden kawałek zagadki.
Zalety korzystania z orkiestracji obejmują:
- Możliwość natychmiastowego odwołania sesji
- Stosowanie zasad sesji i authZ konsekwentnie
- Zarządzanie kluczami federacji i certami z jednego miejsca
- Integracja z sygnałami ryzyka (takimi jak CAEP) w celu wspierania Zero Trust
- I robi to wszystko bez ponownego pisania aplikacji lub przełączania dostawców tożsamości
Orkiestracja łączy przepaść między „nowoczesnym wsparciem protokołu” a prawdziwą modernizacją tożsamości.
Centralizacja nie oznacza cofnięcia się
Czasami ludzie zakładają, że przywrócenie kontroli tożsamości w jednym miejscu jest krokiem wstecz.
Chodzi o umożliwianie zwinności. o zapewnianie zespołom zabezpieczeń widoczności, której potrzebują, nie spowalniając deweloperów. o zarządzanie tożsamością jako usługą – nie jako serią hacków specyficznych dla aplikacji.
Gdy nie masz orkiestracji, każde wyzwanie tożsamości staje się jednorazowym rozwiązaniem.
Jeśli rozmawiam z zespołem zabezpieczeń, zwykle zadaję pytanie takie jak: „Jak szybko można odwołać sesje użytkownika?Każda aplikacja w Twojej firmieWłaśnie teraz?”
Jeśli odpowiedź jest czymś mniejszą niż „wkrótce”, istnieje problem, który warto rozwiązać.
Tagi: nie zatrzymuj się w SSO
Powiem to jasno: nowoczesna uwierzytelnianie jest niezbędne, ale jest niekompletne. Jeśli zatrzymasz się na SSO, brakuje ci warstwy sterowania, która sprawia, że wszystko inne działa – bezpiecznie, konsekwentnie i na skalę.
Więc tak, przyjmij SAML. Wyjmij OIDC. Ale nie pozwól, aby pole logowania było linią końcową.
Jeśli chcesz prawdziwego bezpieczeństwa, orkiestracja musi być częścią podróży.
O autorze
Darren Platt kierował zespołami inżynieryjnymi w Securant Technologies, Ping Identity, Simplified, RSA i Oracle. Obecnie jest wiceprezesem ds. zarządzania produktami i inżynierii w Strata Identity, gdzie buduje pierwszą platformę dystrybucyjną Identity Orchestration dla środowisk rozproszonych i przyczynia się do nowego standardu orkiestracji polityki, IDQL i jego oprogramowania referencyjnego Hexa.
