Aplikacje poza SSO

czym to jest

Single Sign-On (SSO) to mechanizm, który kieruje uwierzytelnianie wszystkich aplikacji przez jednego centralnego dostawcę tożsamości, jak Microsoft Entra ID, Google Workspace czy Okta. Gdy użytkownik loguje się do aplikacji podłączonej przez SSO, jego dane uwierzytelniające są weryfikowane wobec dostawcy tożsamości. Aplikacja ufa potwierdzeniu dostawcy.

Ta centralizacja oznacza, że działania zarządzania dostępem podjęte u dostawcy tożsamości, w tym zamknięcie konta, egzekwowanie MFA czy zmiana uprawnień, natychmiast rozprzestrzeniają się na wszystkie aplikacje podłączone przez SSO.

Aplikacje poza SSO uwierzytelniają się niezależnie. Utrzymują własne bazy danych użytkowników. Logowanie odbywa się na własnych danych uwierzytelniających aplikacji, nie przez dostawcę tożsamości. Zmiany u dostawcy tożsamości nie docierają do tych aplikacji. Zamknięte konto w katalogu nie zamyka konta w aplikacji.

„Aplikacje poza SSO" to część środowiska SaaS, która działa poza tym centralnym punktem kontroli i dlatego wymaga osobnego, ręcznego zarządzania dostępem.

dlaczego się gromadzi

Kilka sił utrzymuje znaczącą część większości środowisk SaaS poza SSO.

Wsparcie SSO nie jest powszechne. Wiele narzędzi, zwłaszcza tych w niższych planach cenowych, albo w ogóle nie wspiera SSO, albo obejmuje je tylko w planach enterprise lub premium. Organizacje na licencjach uważnych na koszty często mają narzędzia, w których SSO to płatny upgrade, którego nie kupiły.

Adopcja na poziomie działu omija IT. Gdy zespół przyjmuje narzędzie bez przechodzenia przez IT, narzędzie niemal nigdy nie jest zintegrowane z SSO. Zespół tworzy konta za pomocą maila i hasła. Narzędzie nigdy nie jest rejestrowane u dostawcy tożsamości.

Starsze i długo działające narzędzia dryfują. Aplikacje dodane do środowiska lata temu, zanim SSO zostało wyegzekwowane jako standard, często pozostają na niezależnych danych uwierzytelniających bezterminowo. Ich migracja wymaga czasu i wysiłku, który przegrywa z bieżącymi priorytetami.

co to kosztuje

Ślepa plama offboardingu. Zamknięcie konta użytkownika w katalogu zamyka dostęp do aplikacji podłączonych przez SSO. Aplikacje poza SSO pozostają nietknięte. Bez osobnego, ręcznego kroku zamykającego konto w każdej z nich, byli pracownicy zachowują dostęp. Ten ręczny krok zależy od tego, czy IT wie, że aplikacja istnieje.

Luka w egzekwowaniu MFA. MFA egzekwowane na poziomie dostawcy tożsamości dotyczy aplikacji podłączonych przez SSO. Aplikacje poza SSO mają własne ustawienia MFA, które mogą nie być skonfigurowane albo egzekwowane konsekwentnie. Konto użytkownika w narzędziu poza SSO może być chronione tylko hasłem, nawet jeśli organizacja egzekwuje MFA wszędzie indziej.

Brak widoczności w przeglądach dostępów. Przeglądy dostępów sprawdzają, kto ma dostęp do czego. Dla aplikacji poza SSO przegląd wymaga osobnego logowania się do konsoli administracyjnej każdej z nich. W praktyce aplikacje poza SSO są często pomijane w cyklach przeglądu, co oznacza, że ich uprawnienia nigdy nie są formalnie zwalidowane.

Opóźnienie reagowania na incydent. Jeśli dojdzie do zdarzenia bezpieczeństwa i trzeba odciąć dostęp konta we wszystkich narzędziach, aplikacje podłączone przez SSO można obsłużyć jedną akcją. Aplikacje poza SSO wymagają osobnej akcji w każdej z nich. W incydencie wrażliwym na czas to opóźnienie ma znaczenie.

co działa

Konsola administracyjna dostawcy tożsamości pokazuje, które aplikacje są zarejestrowane w SSO, a ta lista definiuje zarządzany obszar. Porównanie jej z szerszym rejestrem aplikacji ujawnia narzędzia leżące poza centralnym punktem kontroli. To porównanie ma znaną ślepą plamę, którą warto rozumieć: katalog może ujawnić tylko to, co go dotyka, więc aplikacja uwierzytelniająca się całkowicie na własnych danych uwierzytelniających i bez żadnego grantu OAuth nie zostawia w IdP żadnego śladu. Rekordy wydatków i bezpośrednie pytania do szefów działów ujawniają tę resztę.

Dla każdej aplikacji poza SSO decydujące pytania brzmią: czy dostawca wspiera SSO i czy jest ono dostępne w bieżącym planie. Narzędzia, które je wspierają i przetwarzają wrażliwe dane, to naturalni pierwsi kandydaci do integracji, bo oferują największy zysk governance za zadanie konfiguracyjne. Uczynienie wsparcia SSO standardowym wymogiem w ocenie narzędzia, z udokumentowaną dostępnością na poziomie planu przed zakupem, powstrzymuje lukę przed poszerzaniem się z każdą nową adopcją.

Niektóre aplikacje nigdy nie znajdą się w środku: dostawca nie oferuje SSO albo oferuje je tylko w poziomie licencji, którego nie da się uzasadnić. Dla nich działa wyraźne śledzenie plus kontrole kompensujące. Dane uwierzytelniające administratora trzymane przez więcej niż jedną osobę, MFA egzekwowane wewnątrz samej aplikacji i stałe miejsce na każdej checkliście offboardingu razem przybliżają ochronę, jaką inaczej zapewniłby IdP. Kontrolą, która zawodzi po cichu, jest nieudokumentowany wyjątek: aplikacja, o której wszyscy zakładają, że zarządza nią katalog, mimo że nigdy tak nie było.