Co dostawca tożsamości pokazuje o dostępach, a czego nie widzi

dlaczego obraz jest z założenia niepełny

Zanim przejdziemy do przeglądu poszczególnych dostawców, warto nazwać, skąd bierze się ta luka. Dzieją się jednocześnie trzy rzeczy.

Po pierwsze, dostęp się kumuluje i rzadko jest usuwany. Każde nowe narzędzie, integracja i kontraktor dodają uprawnienia. Offboarding usuwa część z nich. Kierunek netto jest jednak zawsze w górę. Konsola dokładna dzisiaj domyślnie z czasem traci aktualność.

Po drugie, dostęp pojawia się w więcej niż jednym miejscu w obrębie jednej konsoli. Rejestr logowań, przypisane aplikacje, uprawnienia OAuth i role administracyjne to cztery osobne widoki czterech różnych rzeczy. Przeczytanie jednego i założenie, że przeczytało się cały dostęp, to częsty błąd.

Po trzecie, katalog wie tylko o tym, co się przez niego uwierzytelniło. Logowanie federacyjne, provisioning i zgody OAuth zostawiają ślad, bo angażują dostawcę tożsamości. Konto samodzielne, założone bezpośrednio u dostawcy usługi, śladu nie zostawia. To strukturalne ograniczenie, takie samo we wszystkich trzech platformach.

Raport Verizon 2026 Data Breach Investigations Report wykazał, że strona trzecia była zaangażowana w 40 procent naruszeń. Ta liczba opisuje szerszy wzorzec, a nie konkretnie twoje środowisko. To powód, żeby wiedzieć, do czego faktycznie mogą dotrzeć strony trzecie podłączone do twojego środowiska, czyli dokładnie to, do czego służy inwentarz uprawnień OAuth w twojej konsoli, i dokładnie to, co ukrywa luka kont samodzielnych.

google workspace

Google Workspace jest w tej kwestii najbardziej hojna z trzech platform. Prowadzi użyteczny inwentarz aplikacji zewnętrznych z uprawnieniami OAuth wobec danych Workspace i umieszcza ten inwentarz w konsoli administracyjnej, gdzie administrator może go przeczytać.

gdzie szukać

Wszystko poniżej znajdziesz w konsoli Google Admin pod adresem admin.google.com.

• Security, potem API controls, potem App access control. Centrum obrazu aplikacji zewnętrznych. Wylicza aplikacje, którym przyznano dostęp do usług Google przez OAuth, pokazuje scope'y, jakie ma każda aplikacja, i pozwala oznaczać aplikacje jako zaufane, ograniczone albo zablokowane.
• Security, potem API controls, potem Manage Google Services. Kontroluje, które usługi Google są włączone dla których jednostek organizacyjnych.
• Directory, potem Users. Inwentarz kont. Kto istnieje, kto jest zawieszony, kto został utworzony niedawno i które konta nie są powiązane z aktualnym pracownikiem.
• Account, potem Admin roles. Kto ma rolę super admina i role delegowanego administratora.
• Reporting, potem Audit and investigation. Rejestr aktywności. Można tu przeszukiwać przyznania tokenów, działania administratorów i zdarzenia logowania.

co pokazuje dobrze

Widok App access control to mocna strona. Odpowiada na pytanie, na które większość konsol odpowiada słabo: które aplikacje zewnętrzne mają obecnie dostęp do naszej poczty, plików, kalendarza i innych danych Google, i co każda z nich może odczytać albo zapisać. Ponieważ to Google pośredniczy w zgodach OAuth na dane Workspace, te uprawnienia lądują w jednym miejscu. Widać scope, widać, którzy użytkownicy autoryzowali aplikację, i można ograniczyć lub odwołać dostęp z tego samego ekranu.

czego nie pokazuje

Widok jest ograniczony do własnych usług Google. Narzędzie SaaS, z którego intensywnie korzysta twój zespół, z własnym logowaniem i bez połączenia z Google, tu się nie pojawi, bo nigdy niczego od Google nie zażądało. Konsola pokazuje aplikacje podłączone do Google. Nie pokazuje całego twojego zestawu aplikacji. Nie zawęża też za ciebie scope'ów ani nie mówi, czy przyznany scope jest faktycznie używany. Ocena, czy dane uprawnienie jest nadmierne, należy do ciebie.

microsoft entra

Entra, warstwa tożsamości Microsoft 365, to druga platforma, która prowadzi prawdziwy inwentarz uprawnień zewnętrznych. Słownictwo jest tu specyficzne dla Microsoftu, a dostęp jest rozłożony na kilka powiązanych widoków, ale sedno tam jest.

gdzie szukać

Wszystko poniżej znajdziesz w Microsoft Entra admin centre pod adresem entra.microsoft.com albo w odpowiadających panelach w portalu Azure.

• Identity, potem Applications, potem Enterprise applications. Inwentarz aplikacji dodanych do twojego tenanta, w tym aplikacji SaaS firm trzecich, na które zgodę wyrazili użytkownicy lub administratorzy. To odpowiednik widoku połączonych aplikacji w Google.
• W obrębie aplikacji enterprise, widok Permissions. Pokazuje uprawnienia delegowane i uprawnienia aplikacji, jakie ma dana aplikacja, oraz to, czy zostały przyznane zgodą administratora, czy zgodą użytkownika.
• Identity, potem Applications, potem App registrations. Aplikacje zarejestrowane w twoim tenancie, zwykle własne albo zbudowane przez partnerów.
• Enterprise applications, potem Consent and permissions. Ustawienia określające, kto może wyrazić zgodę na co.
• Identity, potem Monitoring, potem Sign-in logs i Audit logs. Rejestr aktywności.

co pokazuje dobrze

Entra ujawnia uprawnienia OAuth i aplikacje z wyrażoną zgodą w obrębie tenanta, wyraźnie rozróżniając zgodę administratora od zgody użytkownika. To rozróżnienie jest tu przydatne. Pozwala oddzielić aplikacje, które administrator świadomie zatwierdził, od aplikacji, którym dostęp przyznali samodzielnie pojedynczy użytkownicy, co często jest źródłem nieprzejrzanego dostępu. Widok Permissions pokazuje scope każdej aplikacji i to, skąd się wziął.

czego nie pokazuje

Podobnie jak w Google, inwentarz uprawnień obejmuje tylko aplikacje zintegrowane z Microsoft 365. Aplikacja SaaS, do której twój zespół loguje się bezpośrednio, bez połączenia z Entra, nie jest aplikacją enterprise i się nie pojawia. Widoki są też bardziej rozproszone niż w Google. Administrator, który czyta tylko listę aplikacji enterprise, bez otwierania widoku uprawnień, widzi, że aplikacje istnieją, ale nie widzi, co potrafią. Kompletność tam jest. Trzeba tylko więcej kliknięć, żeby ją złożyć w całość.

okta

Okta to dedykowany dostawca tożsamości i jest bardzo dobra w zadaniu, do którego ją zbudowano: uwierzytelnianiu ludzi i przypisywaniu ich do aplikacji. Uczciwy punkt o Okcie w kontekście tego przewodnika dotyczy czegoś, czego ona nie robi, więc warto to sprecyzować.

gdzie szukać

Wszystko poniżej znajdziesz w konsoli administracyjnej Okty.

• Applications, potem Applications. Katalog aplikacji zintegrowanych z Oktą do logowania, z modelem przypisań dla każdej z nich.
• Directory, potem People i Directory, potem Groups. Inwentarz kont i grup.
• Security, potem Administrators. Kto ma role administracyjne w samej Okcie.
• Reports, potem System Log. Rejestr aktywności. Można tu przeszukiwać uwierzytelnienia, przypisania, działania administratorów i zmiany polityk, a System Log jest naprawdę szczegółowy.

co pokazuje dobrze

Okta daje przejrzysty widok warstwy logowania i przypisań. Które aplikacje są spięte z SSO, którzy użytkownicy i grupy są do nich przypisani, jak przypisanie wynika z członkostwa w grupach, oraz dokładny log aktywności zdarzeń uwierzytelniania i administracyjnych. Do odpowiedzi na pytanie, kto może się gdzie zalogować przez naszego dostawcę tożsamości, Okta jest precyzyjna.

czego nie pokazuje

Okta jest dostawcą tożsamości do logowania i przypisań. Nie utrzymuje inwentarza uprawnień aplikacji OAuth firm trzecich tak, jak robią to Google Workspace i Entra dla własnych danych. Google i Entra pośredniczą w zgodach na dostęp do danych swojej platformy, więc uprawnienia, jakie aplikacje zewnętrzne mają wobec tych danych, zbierają się w jednym miejscu. Okta stoi przed aplikacjami jako pośrednik logowania. Nie jest platformą danych, do której sięgają te aplikacje zewnętrzne, więc nie ma odpowiednika jednego ekranu wyliczającego, jaki stały dostęp do danych ma każda podłączona aplikacja. Wynika to z tego, gdzie Okta siedzi w architekturze, a nie z żadnej luki w twojej konfiguracji. Jeśli uruchamiasz Oktę przed Google Workspace albo Microsoft 365, te platformy bazowe wciąż mają własne inwentarze uprawnień.

porównanie obok siebie

• Google Workspace · Co pokazuje dobrze: Uprawnienia OAuth firm trzecich wobec danych Workspace w jednym miejscu, ze scope'ami, autoryzującymi użytkownikami i kontrolami zaufania. Użytkowników, role administracyjne i log audytowy. · Czego nie pokazuje: Aplikacji bez połączenia z Google. Tego, czy przyznany scope jest faktycznie używany. Szerszego zestawu aplikacji w firmie.
• Microsoft Entra · Co pokazuje dobrze: Uprawnienia OAuth i aplikacje enterprise z wyrażoną zgodą, z wyraźnym rozróżnieniem zgody administratora od zgody użytkownika. Uprawnienia dla poszczególnych aplikacji, ustawienia zgód, logi logowań i audytu. · Czego nie pokazuje: Aplikacji bez połączenia z Microsoft 365. Jednego zbiorczego widoku (dane są rozłożone na kilka paneli).
• Okta · Co pokazuje dobrze: Logowanie i przypisania: które aplikacje są spięte z SSO, kto jest przypisany, przypisania sterowane grupami i szczegółowy log systemowy. · Czego nie pokazuje: Inwentarza uprawnień aplikacji OAuth firm trzecich porównywalnego z Google i Entra. Tego, co podłączone aplikacje mogą odczytać lub zapisać wewnątrz swoich własnych platform.

Jedna rzecz jest wspólna dla każdego wiersza: żadna z tych konsol nie widzi aplikacji, której nikt w ogóle nie połączył z katalogiem.

czego nie pokazuje żadna z nich

Najmocniejsza część obrazu każdego dostawcy, czyli inwentarz uprawnień OAuth w Google i Entra, zależy od tego, czy aplikacja się połączyła. Aplikacja poprosiła o dostęp do twoich danych, użytkownik albo administrator wyraził zgodę i uprawnienie zostało zapisane. To właśnie to połączenie sprawia, że dostęp jest widoczny. Dwa częste rodzaje dostępu nigdy tego połączenia nie nawiązują, więc są niewidoczne dla wszystkich trzech dostawców.

Konto samodzielne. Ktoś zapisuje się do narzędzia służbowym mailem i hasłem, które sam wybrał. Nie ma SSO, nie ma zgody OAuth, nie ma provisioningu. Narzędzie może trzymać dane firmowe, może być opłacane z czyjejś karty i może być używane od lat. Z punktu widzenia katalogu nie istnieje. To najczęstsza forma dostępu, którą nawet dokładna lektura dostawcy tożsamości całkowicie przeoczy.

Rozszerzenie przeglądarki. Rozszerzenie zainstalowane w przeglądarce pracownika działa na endpoincie z uprawnieniami, o jakie poprosiło przy instalacji. Może odczytywać zawartość stron, w tym zawartość twoich aplikacji SaaS, i odpowiada przed wydawcą rozszerzenia, nie przed twoim katalogiem. Dostawca tożsamości nie ma tu żadnej widoczności, bo rozszerzenie nigdy nie uwierzytelniło się przez katalog. Żyje na urządzeniu.

Wspólna logika jest prosta. Katalog widzi to, co się z nim połączyło. Nie widzi tego, co go ominęło. Zarówno samodzielna rejestracja, jak i rozszerzenie przeglądarki z założenia go omijają. Dlatego nawet staranna, kompletna lektura twojego dostawcy tożsamości daje tylko częściową mapę. To dokładna mapa wszystkiego, co się połączyło. Milczy o wszystkim, co się nie połączyło.

praktyczny wniosek: przeczytaj dostawcę porządnie, potem zamknij lukę

Wniosek to sekwencja działań, nie wybór narzędzia.

Najpierw przeczytaj porządnie swojego dostawcę. Większość środowisk tego nie zrobiła. Widok uprawnień OAuth w Google albo widoki aplikacji enterprise i uprawnień w Entra zwykle zawierają uprawnienia, których zatwierdzenia nikt nie pamięta, często wyrażone zgodą użytkowników, a nie administratorów, czasem trzymane przez narzędzia, z których firma już nie korzysta. W Okcie tak samo dokładnego przejścia wymagają widoki przypisań i logu systemowego, żeby ustalić, kto może się gdzie zalogować. Dokładna lektura konsoli, za którą już płacisz, to najbardziej wartościowy dostępny krok i nie kosztuje nic poza uwagą.

Potem zamknij lukę, której konsola nie widzi. Gdy przeczytasz już wszystko, co wie katalog, zostają ci konta samodzielne i rozszerzenia na endpointach, o których katalog wiedzieć nie może. Dwa źródła zamykają większość tej luki bez nowej platformy:

• Dane o wydatkach. Wyciągi z kart i zapisy zobowiązań pokazują powtarzające się opłaty SaaS. Subskrypcja na firmowej karcie, która nie odpowiada niczemu w twoim SSO ani w inwentarzu uprawnień OAuth, jest z definicji kontem samodzielnym.
• Krótka ankieta wśród pracowników. Zapytaj ludzi, z czego faktycznie korzystają do pracy. Odpowiedzi regularnie zawierają narzędzia, które nigdy nie pojawiają się w żadnej konsoli administracyjnej, bo poszczególne osoby wdrożyły je samodzielnie. To najtańsza dostępna metoda wykrywania dostępu, który nie zostawił śladu w katalogu.

Połącz lekturę dostawcy tożsamości z uzgodnieniem wydatków i ankietą, a dostaniesz znacznie uczciwszy inwentarz aplikacji niż ten, który daje sam katalog. Nawet wtedy mapa ma swoje granice. Rozszerzenia na endpointach wymagają widoczności na poziomie endpointu, żeby je w pełni wyliczyć, a konta trzymane przez kontraktorów mogą leżeć poza twoim katalogiem i poza systemem wydatków. Celem jest przestać traktować czystą lekturę katalogu jako pełny obraz, bo strukturalnie jest tylko jego częścią.