Przewodnik zakupowy: dostawca tożsamości (IdP) i SSO

czym naprawdę są IdP i SSO

Dostawca tożsamości to autorytatywne źródło twoich tożsamości i pośrednik, który je uwierzytelnia. Kiedy ktoś się loguje, IdP sprawdza, czy jest tym, za kogo się podaje, a potem poręcza za niego wobec aplikacji, do których próbuje dotrzeć. Single sign-on to mechanizm, który pozwala, żeby jedno uwierzytelnienie otwierało wiele aplikacji.

To ma znaczenie wykraczające poza wygodę, bo IdP to naturalne miejsce do wymuszania wszystkiego innego. Wymagaj MFA raz, na poziomie IdP, a obejmie to każdą aplikację za nim. Wyłącz kogoś na poziomie IdP i, jeśli twoje aplikacje są prawidłowo podłączone, jego dostęp wszędzie zapada się naraz. Ustaw regułę warunkową, na przykład blokadę logowania z niezarządzanego urządzenia, i obowiązuje ona wszędzie. IdP to miejsce, w którym dostęp staje się rządzalny, i właśnie dlatego aplikacja stojąca poza nim to aplikacja poza twoją kontrolą.

gdzie kupujący popełniają błędy

Pierwszy i najczęstszy błąd to niedowykorzystywanie IdP, który już masz. Dostawca tożsamości dołączony do twojego pakietu produktywności niemal na pewno zawiera MFA, dostęp warunkowy, funkcje lifecycle i więcej, a spora część tego jest wyłączona. Wiele firm idzie na zakupy po możliwości, za które już płacą i których nigdy nie włączyły.

Drugi to pozostawianie aplikacji poza single sign-on. Każda aplikacja, którą zespół przyjął z własnym mailem i hasłem, to osobne logowanie, którego IdP nie może chronić, nie może objąć MFA i nie może wyłączyć, kiedy ktoś odchodzi. Firma może mieć pięknie skonfigurowany IdP i wciąż być szeroko otwarta, bo połowa jej realnych aplikacji nigdy nie została podłączona. Większą luką zwykle jest pokrycie, nie konfiguracja.

Trzeci to prowadzenie kilku katalogów bez konsolidacji. Firmy, które rosły przez przejęcia, albo które doczepiły chmurowy katalog do starego, lokalnego, często prowadzą dwa albo trzy systemy tożsamości naraz. Każdy z nich to miejsce do provisioningu, deprovisioningu i audytu, a to właśnie na styku między nimi konta stają się osierocone.

Czwarty to wybór na podstawie ceny albo przyzwyczajenia zamiast dopasowania, zwłaszcza dopasowania do faktycznego zestawu aplikacji, jakie masz. IdP jest tak dobry, jak jego zdolność połączenia się z konkretnymi aplikacjami, których używasz. Piąty, cichszy błąd to zapominanie, że IdP jest dziś pojedynczym punktem awarii: jeśli padnie albo zostanie przejęty, dotyczy to wszystkiego, co za nim stoi, co czyni odporność i bezpieczeństwo samego IdP sprawą pierwszorzędną.

zanim zaczniesz kupować: zmapuj, co masz

Zacznij od znalezienia swoich katalogów. Możesz mieć ich więcej, niż myślisz: tenant Entra, który przyszedł z Microsoft 365, katalog Google Workspace, lokalne Active Directory sprzed ery chmury, tenant Okta, który pojawił się razem z przejęciem. Pierwsza rzecz do ustalenia to ile systemów tożsamości faktycznie prowadzisz i który z nich jest autorytatywny dla kogo.

Potem spójrz na swoje pokrycie single sign-on. Które aplikacje stoją za IdP, a które nie. Te, które nie, to twoja prawdziwa ekspozycja, i zwykle jest ich więcej, niż się spodziewasz. Tu też natkniesz się na SSO tax: część dostawców SaaS chowa single sign-on w najdroższym planie, co kusi firmy, żeby zostawić aplikacje poza SSO dla oszczędności, kosztem bezpieczeństwa wprost.

Potem scharakteryzuj swoich ludzi i swoje aplikacje. Czy wszyscy to pracownicy przy biurku, czy masz kontraktorów, personel liniowy bez firmowych urządzeń i partnerów, którzy potrzebują dostępu? Czy twoje aplikacje to nowoczesny SaaS mówiący standardowymi protokołami, czy mieszanka obejmująca systemy lokalne i własne? I osobno, czy musisz uwierzytelniać zewnętrznych klientów w produkcie, który prowadzisz, bo to inny problem, zwany customer identity. Na koniec zrób rachunek swojej skali, bo dziesięcioosobowa firma na jednym pakiecie chmurowym i międzynarodowy koncern z kilkoma odziedziczonymi katalogami nie podejmują tej samej decyzji.

kategoria w prostych słowach

Pod warstwą marketingu świat IdP sprowadza się do kilku wzorców i kilku protokołów.

protokoły w skrócie

Spotkasz te skróty i mają znaczenie, bo określają, co się z czym łączy. SAML i OIDC (zbudowany na OAuth) to dwa standardy, których aplikacje używają do przyjmowania single sign-on od twojego IdP; większość nowoczesnego SaaS wspiera jeden albo oba. SCIM to standard provisioningu, dzięki któremu IdP automatycznie tworzy i usuwa konta użytkowników w podłączonych aplikacjach, i to on zamienia offboarding z ręcznej checklisty w automatyczne działanie. LDAP i Active Directory to starsze, lokalne technologie katalogowe, których wiele firm wciąż używa. To, jak IdP wspiera te technologie, oraz jakość jego konkretnych integracji z aplikacjami, decyduje o tym, czy faktycznie potrafi zarządzać twoim zestawem.

trzy wzorce

IdP z pakietu produktywności. Jeśli działasz na Microsoft 365, masz Entrę; jeśli działasz na Google Workspace, masz jego platformę tożsamości. Dla dużej części firm, zwłaszcza mniejszych i cloud-first, to jest właściwa odpowiedź, bo jest wystarczająco możliwościowy, już jest na miejscu i już jest opłacony. Zadanie polega na tym, żeby wykorzystać go w pełni i podłączyć za nim każdą aplikację, nie na tym, żeby go zastąpić.

Dedykowany, niezależny IdP. Samodzielna platforma tożsamości, która stoi ponad wszystkim, niezależnie od tego, jakich chmur i pakietów używasz. Zasługuje na swoje miejsce, kiedy masz naprawdę mieszany zestaw, dużo SaaS, wiele chmur, partnerów i dostęp B2B, albo kilka katalogów, które chcesz zunifikować pod jedną neutralną warstwą. Jego siłą jest to, że nie jest przywiązany do jednego dostawcy produktywności, co ma największe znaczenie, kiedy ty też nie jesteś.

Lokalnie i hybrydowo. Wiele ugruntowanych firm wciąż prowadzi Active Directory lokalnie i federuje je do chmury. To realny i uzasadniony wzorzec, zwłaszcza przy legacy i aplikacjach lokalnych, ale kierunek zmierza w stronę tożsamości chmurowej, a układ hybrydowy to zwykle etap, nie cel docelowy.

co IdP obejmuje coraz częściej

Granica między „IdP" a „resztą tożsamości" wciąż się zaciera, bo nowoczesne IdP dołączają możliwości, które kiedyś były osobnymi zakupami: uwierzytelnianie wieloskładnikowe, dostęp warunkowy, część funkcji lifecycle i governance, i coraz częściej wykrywanie zagrożeń tożsamości. To dobra wiadomość, bo często oznacza, że to, czego potrzebujesz, jest funkcją tego, co już masz, a nie nowym produktem.

uwaga o customer identity

Jeśli część twojego pytania dotyczy tego, jak wpuścić zewnętrznych klientów do logowania w produkcie, który prowadzisz, to jest customer identity and access management, powiązana, ale osobna kategoria z innymi priorytetami (skala, doświadczenie rejestracji, zgody). Nie próbuj rozwiązać tego tą samą decyzją o IdP dla pracowników; oznacz to jako osobny problem.

co pasuje do twojej wielkości i sytuacji

• Szczupła / mała (poniżej ~50) · Jak wygląda dobrze: Używaj IdP wbudowanego w pakiet produktywności. Ustandaryzuj się na jednym katalogu, podłącz każdą aplikację SaaS za jej SSO i włącz MFA oraz dostęp warunkowy, które już masz w środku. · Czego pominąć: Kupowanie osobnego, dedykowanego IdP. Niemal na pewno jeszcze go nie potrzebujesz.
• Rosnący mid-market (50 do 500) · Jak wygląda dobrze: To samo, chyba że masz mieszany zestaw wielochmurowy, duży ślad SaaS albo dostęp B2B, wtedy dedykowany IdP zaczyna zasługiwać na swoje miejsce. Skonsoliduj wszelkie dodatkowe katalogi. Włącz provisioning SCIM, żeby dołączanie i odejścia były automatyczne. · Czego pominąć: Prowadzenie wielu katalogów bezterminowo, bo nikt nie odpowiada za konsolidację.
• Większa / wielopodmiotowa (500 do 2000) · Jak wygląda dobrze: Dedykowany IdP jest często uzasadniony, zwłaszcza przy wielu chmurach albo po przejęciach. Hybrydowe AD tam, gdzie legacy tego wymaga, z planem jego ograniczania. Funkcje lifecycle i governance w aktywnym użyciu. · Czego pominąć: Pozostawianie odziedziczonych katalogów sfederowanych na zawsze zamiast konsolidacji.
• Enterprise / regulowana (2000+, finanse) · Jak wygląda dobrze: Odporny rdzeń tożsamości z governance, wykrywaniem zagrożeń, failoverem i dowodami dostępu, jakich oczekują regulatorzy, traktowany jak infrastruktura krytyczna. · Czego pominąć: Architektura IdP bez odpowiedzi na pytanie, co się dzieje, kiedy sam IdP jest niedostępny.

Kilka sytuacji zmienia kształt decyzji niezależnie od wielkości. Wielochmurowość i potrzeba neutralności wobec dostawcy wskazują na dedykowany, niezależny IdP, i ta neutralność jest głównym powodem zakupu. Wzrost przez przejęcia zmienia decyzję o IdP w projekt konsolidacyjny, gdzie niezależna warstwa nad kilkoma odziedziczonymi systemami może być sposobem na jego przeprowadzenie. Firmy B2B SaaS prawdopodobnie potrzebują zarówno IdP dla pracowników, jak i customer identity dla użytkowników, trzymanych osobno. Duże środowiska lokalne albo legacy powinny mocno ważyć zdolność IdP do obsłużenia ich przez federację, bo narzędzie tylko chmurowe może zostawić najtrudniejsze aplikacje na lodzie. Personel liniowy i bez biurka wnosi współdzielone urządzenia, brak firmowego telefonu i przerywaną łączność, więc upewnij się, że IdP potrafi uwierzytelnić ludzi, których faktycznie zatrudniasz.

sourcing: cztery drogi dojścia

Użyj IdP z pakietu produktywności. Dla większości małych i mid-marketowych firm to właściwy pierwszy ruch, i często też właściwy ruch ostateczny. Ustandaryzuj się na nim, pokryj swoje aplikacje, włącz funkcje, za które już płacisz. Wyczerp tę opcję, zanim cokolwiek kupisz.

Wdroż dedykowany, niezależny IdP. Uzasadniony przy mieszanym zestawie, wielochmurowości, dużym SaaS, dostępie B2B albo potrzebie konsolidacji kilku katalogów. Sens tkwi w niezależności, więc kupuj go wtedy, kiedy niezależność jest tym, czego wymaga twoja sytuacja.

Prowadź hybrydę. Trzymaj lokalną tożsamość sfederowaną z chmurą tam, gdzie legacy naprawdę tego wymaga, najlepiej jako zarządzane przejście, a nie stan permanentny.

Sięgnij po pomoc z zewnątrz. Konsolidacja tożsamości i migracja IdP należą do projektów IT o wyższym ryzyku, bo wszystko uwierzytelnia się względem tej jednej rzeczy, a spartaczona migracja zamyka ludziom dostęp do wszystkiego naraz. Podejście co-managed albo migracja prowadzona przez doradcę, przez MSSP albo VAR, ma sens, kiedy konsolidujesz katalogi, migrujesz między IdP albo nie masz w firmie ekspertyzy tożsamościowej, żeby zrobić to bezpiecznie.

kryteria decyzyjne, które naprawdę się liczą

• Pokrycie aplikacji · Na co zwrócić uwagę: Solidne, przetestowane integracje i SSO dla konkretnych aplikacji, jakich faktycznie używasz, w tym tych niewygodnych i legacy. To jest sprawa decydująca o wszystkim, i jest specyficzna dla twojego zestawu.
• Wsparcie protokołów · Na co zwrócić uwagę: SAML, OIDC, a zwłaszcza SCIM dla zautomatyzowanego provisioningu i deprovisioningu, plus wszystko, czego potrzebują twoje aplikacje legacy.
• Lifecycle i provisioning · Na co zwrócić uwagę: Czy tworzy i usuwa dostęp automatycznie, kiedy ludzie dołączają, zmieniają rolę i odchodzą, czy zostaje to ręczne?
• MFA i dostęp warunkowy · Na co zwrócić uwagę: Czy zawiera silne, najlepiej odporne na phishing uwierzytelnianie i politykę, którą kontrolujesz, tak żebyś nie potrzebował osobnego produktu?
• Neutralność wielochmurowa · Na co zwrócić uwagę: Jeśli tego potrzebujesz, czy stoi czysto ponad chmurami i pakietami, zamiast faworyzować świat jednego dostawcy?
• Migracja i lock-in · Na co zwrócić uwagę: Jak trudno jest wejść, i jak trudno byłoby później wyjść? Tożsamość jest lepka, więc zrozum wyjście, zanim zrozumiesz wejście.
• Odporność · Na co zwrócić uwagę: Co się dzieje, kiedy IdP pada albo jest atakowany? Uptime, failover i bezpieczeństwo samego IdP to sprawy pierwszorzędne.
• Governance i dowody · Na co zwrócić uwagę: Czy potrafi wygenerować raportowanie dostępu i kontrole lifecycle, jakich oczekuje regulator albo audytor?
• Rezydencja danych i UE · Na co zwrócić uwagę: Gdzie fizycznie żyją twoje tożsamości i dane uwierzytelniające?
• Koszt, w tym SSO tax · Na co zwrócić uwagę: Cennik samego IdP, plus to, ile kosztuje cię SSO w twoich aplikacjach SaaS, bo to kształtuje, czy realnie możesz podłączyć za nim wszystko.

Jeśli masz zapamiętać jeden wiersz, zapamiętaj pokrycie aplikacji. IdP, który nie potrafi czysto zarządzać konkretnymi aplikacjami twojej firmy, to IdP, który zostawi luki, których nie zamknie żadna konfiguracja.

jak to jest wyceniane i jaki jest prawdziwy koszt

IdP i SSO są zwykle wyceniane za użytkownika miesięcznie, przy czym bardziej użyteczne możliwości, zaawansowany dostęp warunkowy, automatyzacja lifecycle, governance, siedzą w wyższych planach. Kiedy IdP przychodzi z twoim pakietem produktywności, spora część tego jest wliczona w licencję, którą już masz, co jest pierwszym powodem, żeby zrobić inwentarz tego, co posiadasz.

Licencja rzadko jest prawdziwym kosztem. Zaplanuj budżet na migrację, która dominuje pierwszy rok i jest drogą, ryzykowną częścią przenosin między IdP albo konsolidacji katalogów. Zaplanuj budżet na integrację aplikacji, zwłaszcza legacy i tych własnych. Zaplanuj budżet na SSO tax, czyli to, co pobierają twoi dostawcy SaaS za włączenie single sign-on, bo to decyduje, jak dużą część twojego zestawu faktycznie możesz objąć IdP. I zaplanuj budżet na plan, którego naprawdę potrzebujesz, bo funkcje, które czynią z IdP kontrolę bezpieczeństwa, często siedzą w wyższych planach. Myśl w kategoriach całkowitego kosztu na przestrzeni kilku lat, łącznie z migracją i SSO tax.

jak przeprowadzić ewaluację

Zbuduj shortlistę świadomie i uwzględnij opcję ustandaryzowania się na IdP, który już masz, i pełnego jego skonfigurowania, bo dla wielu firm to jest prawdziwy konkurent każdego zakupu. Wyślij pytania badające dopasowanie, nie funkcje: przetestowane integracje dla konkretnych aplikacji, jak działa provisioning SCIM przy offboardingu, co faktycznie obejmuje migracja, historia uptime'u i failoveru, gdzie żyją tożsamości i jak obsługiwane są aplikacje legacy.

Potem przeprowadź proof of concept na swoim prawdziwym zestawie. Podłącz kilka najważniejszych aplikacji, łącznie z jedną trudną, przez SSO i SCIM. Przepuść przez to prawdziwe dołączenie i prawdziwe odejście i potwierdź, że dostęp faktycznie pojawia się i znika w tych aplikacjach. Przetestuj regułę dostępu warunkowego. Ustal kryteria sukcesu z góry, i uczyń zautomatyzowany deprovisioning jednym z nich, bo tam koncentruje się wartość bezpieczeństwa. Potem zbierz referencje, skupione na migracji: ile trwała, co się popsuło i co zrobiliby inaczej.

pułapki, których nie pokaże demo

Typową porażką jest częściowo podłączony IdP: skonfigurowany starannie, ale z długim ogonem aplikacji wciąż poza nim, z których każda to logowanie, którego IdP nie może chronić ani cofnąć. Tuż za tym cicho wygrywa SSO tax, z zespołami zostawiającymi aplikacje poza single sign-on, żeby uniknąć cennika dostawcy, co fragmentuje dokładnie tę kontrolę, którą budowałeś.

Potem jest problem wielu katalogów, który nigdy nie zostaje rozwiązany, więc konta wciąż wymykają się na styku systemów. Jest IdP, który niedowykorzystujesz, płacąc za możliwości, których nigdy nie włączasz, jednocześnie kupując je gdzie indziej. Jest ból migracji i lock-in, odkrywane za późno, bo tożsamość jest najbardziej lepką rzeczą w twoim stacku. I jest martwe pole odporności: brak planu na dzień, w którym sam IdP pada albo zostaje przejęty. Duże naruszenia dostawców tożsamości ostatnich lat pokazały, że IdP sam w sobie jest celem najwyższej klasy, a jego własne bezpieczeństwo i dostępność są częścią tego, co wybierasz.

jak to się spotyka z przepisami

IdP to sposób, w jaki faktycznie dostarczasz kilka rzeczy wymaganych przez przepisy. Artykuł 21 NIS2 oczekuje kontroli dostępu i uwierzytelniania wieloskładnikowego, a IdP to miejsce, gdzie oba są wymuszane. DORA oczekuje od podmiotów finansowych kontroli tożsamości i dostępu, w tym least privilege i terminowego usuwania dostępu, co w praktyce oznacza lifecycle i provisioning na poziomie IdP. Audytorzy i ubezpieczyciele coraz częściej chcą dowodów kontroli dostępu i offboardingu, a dobrze prowadzony IdP z właściwym provisioningiem to najczystsze miejsce, żeby je wygenerować. Kwestia deprovisioningu jest ostra: zdecydowana większość ludzi zachowuje dostęp do co najmniej jednego systemu byłego pracodawcy po odejściu (Beyond Identity, 2022, self-reported), a zautomatyzowany deprovisioning na poziomie IdP to kontrola, która zamyka tę lukę.

droga krok po kroku

Tożsamość nagradza najpierw konsolidację, a dopiero potem rozbudowę.

Crawl: wybierz jeden główny IdP i ustandaryzuj się na nim, konsolidując zbłąkane katalogi tam, gdzie się da. Podłącz za jego single sign-on każdą aplikację SaaS, jaką możesz. Włącz MFA i dostęp warunkowy, które już zawiera. Samo to sprawia, że twój dostęp staje się rządzalny w sposób, w jaki rozproszony zestaw nigdy nie jest.

Walk: włącz provisioning SCIM, tak żeby dołączenia, zmiany ról i odejścia automatycznie wpływały do podłączonych aplikacji i z nich wypływały, i to tam rozwiązuje się ryzyko deprovisioningu. Wytrop i podłącz aplikacje wciąż poza SSO, świadomie radząc sobie z SSO tax, zamiast pozwolić mu wypychać aplikacje na zewnątrz. Wprowadź do użytku podstawowy governance i przeglądy dostępów.

Run: przesuwaj się w stronę passwordless na poziomie IdP, dodaj wykrywanie zagrożeń tożsamości, zautomatyzuj pełny lifecycle, rozszerz się na uprawnienia wielochmurowe i wbuduj odporność oraz failover, tak żeby pojedynczy punkt awarii miał zabezpieczenie. Na tym etapie IdP jest działającą warstwą kontrolną dla całego twojego dostępu, czyli tym, czym zawsze miał być.

Najczęstsza sytuacja to firma, która nigdy świadomie nie wybrała IdP i wykorzystuje ułamek tego, co ma. Więc uczciwym pierwszym ruchem jest zwykle jasno zobaczyć swój obecny zestaw tożsamości, ustandaryzować się na jednym IdP, podłączyć za nim swoje aplikacje i włączyć to, co już masz, zanim zdecydujesz, czy potrzebujesz czegoś więcej.