Rozrost zakresów OAuth

czym jest

Kiedy aplikacja prosi o autoryzację OAuth, określa zakresy, o które pyta: konkretne uprawnienia, których żąda w twoim środowisku. Zakres może oznaczać „odczyt poczty", „odczyt i zapis plików", „odczyt kalendarza", „odczyt kontaktów", a w najszerszym przypadku pełny dostęp do konta Google Workspace lub Microsoft 365.

Rozrost zakresów OAuth to sytuacja, w której aplikacje mają zakresy szersze niż wymaga tego ich funkcja, zwykle dlatego, że zostały nadane bez dokładnego przeglądu podczas konfiguracji i nigdy później nie zostały zawężone.

Narzędzie do powiadomień, które prosi o pełny dostęp do skrzynki pocztowej, żąda znacznie więcej, niż potrzebuje. Narzędzie do analizy dokumentów proszące o zapis do wszystkich plików mogłoby działać na dostępie tylko do odczytu (read-only). Użytkownik klika „Zezwól" podczas konfiguracji, często bez sprawdzenia, o jakie konkretnie zakresy wnioskuje aplikacja, a ona zachowuje ten szeroki dostęp bezterminowo.

dlaczego narasta

Rozrost zakresów ma strukturalne przyczyny zarówno po stronie dostawcy, jak i użytkownika.

Dostawcy celowo proszą o szerokie zakresy. Twórca aplikacji, który wnioskuje o minimalne zakresy, musi obsługiwać przypadki brzegowe i dodatkowe prośby o uprawnienia, gdy użytkownicy testują kolejne funkcje. Proszenie o szerokie zakresy od razu upraszcza rozwój produktu i zmniejsza tarcie w doświadczeniu użytkownika. Dostawcy zależy więc na tym, żeby przy konfiguracji poprosić o jak najwięcej.

Użytkownicy nie sprawdzają zakresów przy autoryzacji. Ekran autoryzacji OAuth wymienia żądane uprawnienia, ale w praktyce większość użytkowników przechodzi dalej, nie czytając go. Krok przeglądu uprawnień, który technicznie istnieje w procesie, w rzeczywistym zachowaniu użytkowników praktycznie nie funkcjonuje.

Zakresy nie są sprawdzane po autoryzacji. Nawet tam, gdzie organizacje robią okresowe przeglądy uprawnień OAuth, przegląd zwykle skupia się na tym, które aplikacje mają uprawnienia, a nie na tym, jaki konkretnie zakres niesie każde z nich. Aplikacja znana i zaufana może w takim przeglądzie w ogóle nie mieć sprawdzanego zakresu.

Minimalny zakres często po prostu nie jest dostępny. Niektórzy dostawcy budują model uprawnień tak, że zestaw funkcji, na którym zależy użytkownikowi, jest dostępny wyłącznie przy szerokim zakresie. Poproszenie o węższy zakres oznacza utratę funkcjonalności, którą użytkownik uważa za niezbędną. Użytkownik akceptuje więc szeroki zakres, żeby dostać tę funkcję.

co to kosztuje

Większy blast radius naruszenia. Gdy dochodzi do przejęcia aplikacji z szerokim uprawnieniem OAuth, atakujący dostaje taki sam dostęp, jaki miała aplikacja. Jeśli miała pełny dostęp do odczytu skrzynki, atakujący może czytać pocztę twojej organizacji. Jeśli miała pełny dostęp do plików, może się do nich dostać i je wykraść. Blast radius przejętej aplikacji wyznacza jej zakres.

Przepływ danych poza twoją świadomością. Aplikacje z szerokim zakresem mogą przesyłać dane, do których mają dostęp, a nie tylko te, których potrzebują do działania. Narzędzie produktywnościowe z pełnym dostępem do skrzynki może czytać każdy e-mail na koncie, włącznie z wrażliwą korespondencją, której nigdy nie miało dotykać. To, czy tak robi, zależy od praktyk dostawcy, których być może nigdy nie sprawdziłeś.

Naruszenie zasady least privilege. Least privilege to podstawowa kontrola bezpieczeństwa: każdy system i użytkownik powinien mieć minimalny dostęp konieczny do wykonania swojej funkcji. Aplikacje z nadmiarowym zakresem OAuth naruszają tę zasadę. W ramach takich jak ISO 27001, SOC 2 czy DORA oczekuje się stosowania least privilege do całego dostępu, w tym dostępu aplikacji zewnętrznych.

Narastające ryzyko przez kumulację uprawnień. Rozrost zakresów i kumulacja uprawnień wzmacniają się nawzajem. Środowisko z wieloma długo żyjącymi uprawnieniami OAuth, z których część niesie niepotrzebnie szerokie zakresy, ma jednocześnie problem z liczbą i z głębokością uprawnień. Razem dają szeroką powierzchnię dostępu, którą trudno ogarnąć bez narzędzi.

co działa

Dane o zakresach już siedzą w dostawcy tożsamości (IdP): eksport z konsoli administracyjnej pokazuje nadane zakresy każdej aplikacji, a filtrowanie po najwyższym poziomie zakresu, pełny dostęp do skrzynki, pełny odczyt lub zapis plików, pełny dostęp do konta, odczyt i modyfikacja wszystkich danych, daje roboczą listę. Kolejny krok to ocena funkcjonalna: co ta aplikacja naprawdę robi i czy zakres do tego pasuje. Narzędzie, które wysyła powiadomienia mailowe, nie ma żadnego funkcjonalnego powodu, żeby czytać skrzynkę; narzędzie do tworzenia dokumentów nie ma powodu, żeby czytać wszystkie istniejące pliki. Luka między nadanym a potrzebnym zakresem to jest właśnie to, co trzeba znaleźć.

Tam, gdzie dostawca obsługuje węższe zakresy, rozwiązaniem jest cofnięcie i ponowna autoryzacja przy minimalnym zakresie, jakiego wymaga funkcja, a dokumentacja dostawcy zwykle wskazuje minimalną konfigurację. Tam, gdzie szeroki zakres jest wpisany w architekturę dostawcy i nie ma węższej opcji, realne kroki to bezpośrednia rozmowa z dostawcą o tym, dlaczego zakres jest konieczny i czy planowana jest węższa opcja, plus notatka w kartotece dostawcy, która zaważy przy kolejnej ocenie lub odnowieniu umowy. Architektura, która do wąskiej funkcji wymaga pełnego dostępu do konta, mówi coś o dostawcy i warto to uwzględnić w ocenie.

Trwałą kontrolą jest włączenie zakresu do cyklu przeglądów. Przegląd OAuth, który potwierdza tylko, które aplikacje mają uprawnienia, ale nigdy nie sprawdza, na co pozwala każde z nich, będzie co kwartał przepuszczał zaufane narzędzie, mimo że trzyma ono klucze do skrzynki. To przegląd zakresu przy każdym uprawnieniu, w tym samym kwartalnym lub półrocznym rytmie, faktycznie wyłapuje rozrost, bo z definicji jest on niewidoczny na poziomie samej listy aplikacji.