Zarządzanie grantami OAuth: jak przeglądać aplikacje podpięte do katalogu

czym jest grant OAuth

Kiedy pracownik loguje się do aplikacji firmy trzeciej za pomocą firmowego konta Google lub Microsoft, robi więcej niż tylko logowanie. Aplikacja prosi o zgodę na konkretne działania na danych firmowych: czytanie poczty, wgląd w pliki, dostęp do kalendarza, odczyt profilu. Pracownik klika Zezwól, a aplikacja otrzymuje token.

Ten token to grant OAuth. To stały dostęp do danych firmowych, który ma aplikacja, powiązany z tożsamością pracownika, bez hasła zarządzanego czy rotowanego przez firmę. Aplikacja nie potrzebuje ponownego logowania pracownika, żeby dalej z niego korzystać. Grant trwa, dopóki ktoś go nie cofnie.

Dostęp aplikacji definiują jej scopes. Scope to pojedyncze, nazwane uprawnienie. User.Read pozwala aplikacji odczytać podstawowy profil zalogowanego użytkownika. Mail.Read pozwala jej czytać skrzynkę pocztową tego użytkownika. Files.ReadWrite.All pozwala czytać i zapisywać pliki w całym zakresie, do którego użytkownik ma dostęp. Aplikacja pokazuje listę żądanych scopes na ekranie zgody. Niewiele osób czyta ją uważnie, a po kliknięciu Zezwól grant jest już aktywny.

To cicha część twojej powierzchni dostępu. Leży obok polityki haseł, MFA i procesu offboardingu, ale nie przechodzi przez żaden z nich. Aplikacja autoryzowana dwa lata temu przez kogoś, kto od dawna już nie pracuje w firmie, może dziś nadal mieć ważny grant.

dlaczego granty się kumulują i dlaczego to ma znaczenie

Trzy rzeczy sprawiają, że granty OAuth się piętrzą.

Łatwo je utworzyć. W domyślnej konfiguracji Google Workspace lub Microsoft 365 zwykły pracownik może samodzielnie nadać wiele uprawnień delegowanych. Bez zgłoszenia, bez zatwierdzenia, bez przeglądu. Jedno kliknięcie i połączenie jest gotowe.

Nikt nie zatwierdza większości z nich. Grant powstaje w procesie aplikacji firmy trzeciej, nie w procesie IT. Dział IT często dowiaduje się o istnieniu aplikacji dopiero wtedy, gdy coś się psuje albo gdy ktoś robi inwentaryzację.

Przeżywają swoje zastosowanie. Pracownik testuje narzędzie do projektu, projekt się kończy, narzędzie zostaje zapomniane. Grant zostaje. Osoba odchodzi z firmy, jej konto zostaje wyłączone, a grant na poziomie aplikacji może nadal być ważny, bo powstał przy aplikacji, nie przy logowaniu.

Efekt to rosnąca lista aplikacji ze stałym dostępem, których prawie nikt nie pilnuje. Ma to znaczenie, bo wiele z tych aplikacji prosi o więcej, niż potrzebuje. Narzędzie do planowania spotkań prosi o pełny zapis w kalendarzu. Aplikacja do notatek prosi o odczyt całej skrzynki pocztowej. Szerokie scopes w zapomnianej aplikacji, należącej do firmy trzeciej, której już nie śledzisz, to dostęp, za który nie potrafisz odpowiedzieć. Udział firm trzecich pojawił się w 48% naruszeń, wobec 30% rok wcześniej, według Verizon Data Breach Investigations Report 2026. Podpięte aplikacje to jedna z najbardziej bezpośrednich form dostępu firm trzecich do twoich danych, a w większości firm to forma najrzadziej przeglądana.

jak czytać scopes: prosty przewodnik

Nie musisz zapamiętywać nazwy każdego scope. Musisz umieć odróżnić scope logowania od scope danych.

Scope logowania pozwala aplikacji potwierdzić, kim jest użytkownik, i odczytać podstawowe informacje o profilu. To niskie ryzyko. Nie dają aplikacji dostępu do poczty, plików ani katalogu.

Scope danych pozwala aplikacji czytać lub zmieniać rzeczywiste dane firmowe. Zawartość skrzynki pocztowej. Pliki na Drive czy SharePoint. Wpisy w kalendarzu. Sam katalog. To scopes, które warto przeglądać, a te szerokie warto kwestionować za każdym razem.

Jeszcze jeden scope warto znać z nazwy. offline_access pozwala aplikacji działać bez obecności użytkownika, dzięki przechowywaniu refresh tokena. Aplikacja ze scope danych plus offline_access może sięgać po twoje dane, nawet gdy użytkownik zamknął przeglądarkę i poszedł do domu, dopóki grant nie zostanie cofnięty.

• openid, profile, email · Platforma: Oba · Co pozwala robić aplikacji: Potwierdza tożsamość, odczytuje imię i e-mail · Ryzyko: Niskie. Tylko logowanie
• User.Read · Platforma: Microsoft · Co pozwala robić aplikacji: Odczytuje podstawowy profil zalogowanego użytkownika · Ryzyko: Niskie. Tylko logowanie
• Calendars.Read / calendar.readonly · Platforma: Oba · Co pozwala robić aplikacji: Odczytuje wpisy w kalendarzu · Ryzyko: Średnie. Ujawnia spotkania i uczestników
• Mail.Read / gmail.readonly · Platforma: Oba · Co pozwala robić aplikacji: Odczytuje całą skrzynkę pocztową użytkownika · Ryzyko: Wysokie. Cała poczta, przeszła i przyszła
• Mail.ReadWrite / Mail.Send · Platforma: Oba · Co pozwala robić aplikacji: Odczytuje, zmienia lub wysyła pocztę w imieniu użytkownika · Ryzyko: Wysokie. Może działać jako użytkownik w poczcie
• Files.ReadWrite.All / drive · Platforma: Oba · Co pozwala robić aplikacji: Odczytuje i zapisuje pliki w całym zakresie dostępnym użytkownikowi · Ryzyko: Wysokie. Szeroki dostęp do dokumentów
• Sites.ReadWrite.All · Platforma: Microsoft · Co pozwala robić aplikacji: Odczytuje i zapisuje witryny SharePoint · Ryzyko: Wysokie. Szeroki dostęp do dokumentów
• Directory.Read.All · Platforma: Microsoft · Co pozwala robić aplikacji: Odczytuje wszystkich użytkowników, grupy i role w katalogu · Ryzyko: Wysokie. Pełne wyliczenie katalogu
• offline_access · Platforma: Oba · Co pozwala robić aplikacji: Utrzymuje dostęp po zakończeniu sesji · Ryzyko: Podnosi ryzyko każdego scope danych, któremu towarzyszy

Przydatny test przy czytaniu grantu: czy scope pasuje do tego, do czego służy aplikacja. Narzędzie do planowania spotkań musi odczytywać dostępność w kalendarzu. Nie musi czytać każdego e-maila. Kiedy scope jest dużo szerszy niż zadanie, to sygnał ostrzegawczy, nie funkcja.

gdzie szukać grantów

Granty widać w konsoli administracyjnej każdej platformy. Ścieżka jest inna, ale idea ta sama: lista aplikacji, scopes, jakie ma każda z nich, i liczba użytkowników, którzy je autoryzowali.

Google Workspace. Zaloguj się do konsoli Admin. Przejdź do Security, potem API controls. Otwórz App access control, żeby zobaczyć aplikacje firm trzecich podpięte do katalogu. Dla każdej aplikacji widzisz scopes, jakie posiada, i liczbę użytkowników, którzy nadali dostęp. Stąd możesz oznaczyć aplikację jako zaufaną, ograniczoną albo zablokowaną, a także usunąć dostęp. Nowo autoryzowane aplikacje mogą pojawić się w tym widoku z dnia lub dwóch opóźnieniem.

Microsoft Entra. Zaloguj się do Entra admin center. Przejdź do Identity, potem Enterprise applications. Tam znajdziesz listę aplikacji, na które wyrażono zgodę w twoim tenancie. Otwórz aplikację i sprawdź jej Permissions, żeby zobaczyć posiadane scopes oraz to, czy dane uprawnienie jest delegowane (działa jako użytkownik) czy aplikacyjne (działa samodzielnie w całym tenancie). Uprawnienia aplikacyjne z przyrostkiem .All zasługują na najbaczniejszą uwagę, bo obejmują każdą skrzynkę pocztową czy plik, a nie tylko te jednego użytkownika.

Jeśli korzystasz z obu platform, sprawdź listy w obu konsolach. Aplikacja podpięta w Google nie pojawi się w Entra, i odwrotnie.

przebieg przeglądu

Przegląd to cztery kroki. Inwentaryzacja, sortowanie, ocena, dokumentacja. Potem powtarzasz go w ustalonym rytmie.

Krok pierwszy: inwentaryzacja. Wyeksportuj lub wypisz wszystkie podpięte aplikacje z każdej konsoli. Zapisz nazwę aplikacji, jej scopes, liczbę użytkowników i wydawcę, jeśli jest widoczny. Wystarczy prosty arkusz. Celem jest jeden wiersz na aplikację, z jej scopes wprost widocznymi.

Krok drugi: sortowanie. Uporządkuj listę najpierw według ryzyka scope, potem według liczby użytkowników. Aplikacje z scopes danych wysokiego ryzyka, które sięgają do wielu osób, trafiają na górę. Niskiego ryzyka aplikacja logowania używana przez jedną osobę może poczekać.

Krok trzeci: ocena. Dla każdej aplikacji wybierz jeden z trzech wyników.

• Zostaw. Aplikacja jest znana, używana, a jej scopes pasują do zadania. Żadnego działania poza zapisaniem decyzji.
• Ogranicz. Aplikacja jest potrzebna, ale jej dostęp jest szerszy, niż trzeba, albo powinna zostać ograniczona do mniejszej liczby użytkowników bądź do stanu zatwierdzanego przez administratora. Zapisz zmianę do wprowadzenia.
• Cofnij. Aplikacja jest nieznana, nieużywana, powiązana z osobą, która już nie pracuje w firmie, albo ma szerokie scopes bez uzasadnienia. Usuń jej dostęp.

Przy górze listy zadaj trzy pytania o każdą aplikację. Czy wiemy, czym to jest i kto tego używa. Czy scope pasuje do zadania. Czy wydawca jest nam znany. Aplikacja, która nie przechodzi któregoś z tych testów, kieruje się w stronę ograniczenia albo cofnięcia.

Krok czwarty: dokumentacja. Dla każdej aplikacji zapisz decyzję, powód i właściciela. Właściciel to osoba odpowiedzialna za to, że aplikacja nadal ma dostęp. Decyzja bez właściciela to decyzja, którą odwróci kolejna osoba klikająca Zezwól. Zachowaj zapis. To też jest to, o co poprosi audytor.

Potem ustal harmonogram. Granty kumulują się nieustannie, więc jednorazowy przegląd szybko się dezaktualizuje. Kwartalny przegląd aplikacji wysokiego ryzyka i o szerokim zasięgu, z półrocznym przeglądem reszty, to sensowny punkt startowy. Dopnij sprawdzenie grantów do procesu offboardingu, żeby podpięte aplikacje odchodzącego pracownika były przeglądane w momencie wyłączenia jego konta, a nie miesiące później.

jak zapobiegać dalszemu rozrostowi

Przegląd listy to połowa pracy. Druga połowa to spowolnienie tempa, w jakim lista odrasta. Cztery mechanizmy kontroli załatwiają większość tej roboty i wszystkie żyją w tych samych konsolach administracyjnych.

Ustaw zgodę administratora dla scopes wysokiego ryzyka. Skonfiguruj tenant tak, żeby aplikacje żądające scopes danych, na przykład dostępu do skrzynki pocztowej czy pełnego dostępu do plików, wymagały zatwierdzenia przez administratora. Pracownicy nadal mogą korzystać z aplikacji. Nie mogą po cichu oddać szerokiego dostępu samodzielnie.

Ogranicz zgodę użytkownika do scopes niskiego ryzyka. Pozwól pracownikom samodzielnie wyrażać zgodę tylko na scopes poziomu logowania od rozpoznawalnych wydawców. Wszystko poza tym trafia do przeglądu.

Utrzymuj allowlistę aplikacji. Prowadź listę zatwierdzonych aplikacji z góry dopuszczonych do użycia. W Google Workspace możesz ustawić dostęp API w tryb ograniczony i zaufać konkretnym aplikacjom. W Entra możesz zarządzać tym, które aplikacje są dozwolone, a które zablokowane. Allowlista to lista, którą przejrzałeś i zdecydowałeś zostawić.

Daj pracownikom ścieżkę zgłaszania. Kontrola, która tylko blokuje, tworzy presję, żeby ją obejść. Połącz ograniczenie zgody z prostym sposobem, w jaki pracownik może zgłosić aplikację i szybko dostać decyzję. Chodzi o to, żeby ktoś zobaczył zgłoszenie, zanim dostęp stanie się aktywny, a ludzie nadal dostawali swoje narzędzia.

Razem te mechanizmy zmieniają dostęp aplikacji z czegoś, co dzieje się domyślnie, w coś, co przechodzi przez lekki, widoczny krok.

uczciwa uwaga o zakresie

Przegląd oparty na katalogu daje jasny obraz, ale nie cały obraz. Widzi aplikacje podpięte przez OAuth i przez SSO. To realna i istotna część twojej powierzchni dostępu, a dla większości firm to część, na którą nikt wcześniej nie spojrzał.

Nie widzi wszystkiego. Pracownik korzystający z prywatnego konta poza katalogiem tu się nie pojawi, bo nic nie zostało podpięte do twojego tenanta. Rozszerzenie przeglądarki działające na czyimś laptopie też się nie pojawi, bo żyje na endpoincie, nie w katalogu. Te obszary potrzebują innych sygnałów. Zarządzanie endpointami lub urządzeniami mobilnymi daje widoczność tego, co działa na firmowych urządzeniach. Narzędzie do bezpieczeństwa przeglądarki daje widoczność rozszerzeń i tego, do czego pracownicy się logują w przeglądarce.

Świadomość tego utrzymuje przegląd w uczciwych ramach. Mówi ci, co już objąłeś, a czego nie, żebyś nie pomylił czystej listy OAuth z pełnym obrazem wszystkich używanych narzędzi.