Microsoft 365 ma problem z przejrzystością dodatków – tylko 1069 z ponad 8000 przebadanych aplikacji publicznie pokazuje jednocześnie opis i wymagane uprawnienia, a część żąda dostępu do danych całej organizacji

Problem nie polega na tym, że dodatki do Microsoft 365 potrzebują uprawnień. Problem zaczyna się wtedy, gdy administrator nie może łatwo zestawić dwóch podstawowych informacji: co aplikacja deklaruje, że robi, oraz do jakich danych naprawdę chce dostać dostęp. Badanie opublikowane 3 sierpnia 2026 r. pokazuje skalę tej luki. Z ponad 8000 przeanalizowanych aplikacji Microsoft 365 tylko dla 1069 udało się jednocześnie uzyskać użyteczny opis funkcji i zestaw żądanych uprawnień OAuth.

To szczególnie istotne w firmowym środowisku Microsoft 365. Dodatek nie musi ograniczać się do dokumentu otwartego przez jednego pracownika. W zależności od sposobu autoryzacji może otrzymać dostęp do poczty, plików, kalendarzy, czatów Teams, katalogu użytkowników, a w przypadku najbardziej rozległych uprawnień — do zasobów obejmujących całą organizację. I właśnie tutaj zwykłe „Zezwól” staje się decyzją z obszaru bezpieczeństwa, a nie konfiguracji wygodnej wtyczki.

Ponad 8000 aplikacji i tylko 1069 przypadków z kompletem informacji

Badacze z Politecnico di Torino połączyli dane z publicznych interfejsów marketplace’ów Microsoftu, automatycznych instalacji aplikacji w testowym tenantcie oraz rzeczywistego środowiska Microsoft 365 obejmującego ponad 35 tys. użytkowników. Celem nie było sprawdzenie jednej kategorii dodatków, lecz odtworzenie rzeczywistego ekosystemu aplikacji współpracujących z Microsoft 365.

Najbardziej problematyczny wynik pojawia się jeszcze przed oceną bezpieczeństwa samych uprawnień. Microsoft 365 korzysta z kilku kanałów dystrybucji: Microsoft Marketplace, sklepu Teams, dodatków Office oraz aplikacji integrujących się bezpośrednio przez Microsoft Graph. Sposób prezentowania uprawnień nie jest w tych kanałach jednolity. W jednym miejscu użytkownik zobaczy listę wymaganych dostępów, w innym część informacji jest ukryta głębiej albo nie da się jej łatwo powiązać z opisem konkretnej aplikacji.

Po połączeniu dostępnych źródeł badacze mieli początkowo 1286 rekordów zawierających opis oraz informacje o uprawnieniach. Następnie:

• usunięto 96 duplikatów,

• odrzucono 61 przypadków, w których nie można było pewnie dopasować aplikacji do właściwego Service Principal,

• usunięto 40 opisów nieanglojęzycznych,

• odrzucono 20 opisów krótszych niż 10 słów.

Do właściwej analizy zostało 1069 aplikacji. W kontekście ponad 8000 przebadanych pozycji oznacza to, że dla zdecydowanej większości ekosystemu nie powstał jednocześnie kompletny, jednoznaczny zestaw „deklarowana funkcja + faktyczne uprawnienia”, który nadawałby się do porównania.

To nie jest detal dotyczący jakości katalogu. Administrator zatwierdzający integrację potrzebuje dokładnie tych dwóch informacji. Sam opis typu „usprawnia pracę zespołu” czy „integruje kalendarz z Teams” nie mówi jeszcze, czy aplikacja chce odczytać kalendarz zalogowanego pracownika, czy modyfikować kalendarze wszystkich osób w tenantcie.

Dodatkowym problemem są nazwy aplikacji i obiektów w Entra ID. Ta sama usługa może występować w sklepie pod jedną nazwą, a jako Service Principal z dopiskiem „for M365”, „for Teams” albo inną nazwą produktu. W praktyce oznacza to, że proste porównanie listy dodatków ze sklepem nie zawsze wystarczy do audytu.

„Read” nie zawsze znaczy dostęp jednego użytkownika. Końcówka „All” zmienia skalę ryzyka

Microsoft 365 opiera integracje między innymi na OAuth 2.0 i Microsoft Graph. Administrator powinien rozróżniać co najmniej trzy mechanizmy dostępu.

Delegated permissions pozwalają aplikacji działać w imieniu zalogowanego użytkownika i co do zasady mieszczą się w zakresie jego własnych uprawnień. Application permissions działają bez obecności użytkownika i mogą obejmować cały tenant. Trzeci wariant, Resource-Specific Consent (RSC), ogranicza dostęp do konkretnego zasobu Teams, na przykład jednego zespołu lub czatu.

Właśnie dlatego nie wystarczy policzyć uprawnień. W analizowanej grupie aplikacje żądały od 1 do 32 różnych uprawnień, ale jedno szerokie uprawnienie aplikacyjne może mieć większe znaczenie niż kilka zwykłych zakresów logowania. Dla porównania User.Read występowało w 48% aplikacji, openid w 37%, a profile w 36%. Są to zakresy częste. Zupełnie inaczej należy traktować uprawnienia kończące się na .Read.All lub .ReadWrite.All, szczególnie gdy są przyznawane jako Application permissions.

Badanie pokazuje konkretne przypadki:

• Mindomo 9.0, aplikacja do map myśli i współpracy, występowała z Files.ReadWrite.All. Funkcja zapisywania map w plikach tłumaczy potrzebę pracy na dokumentach, ale zakres .All pozwala objąć dostępem pliki w całej organizacji.

• Vacation Tracker żądał łącznie 13 uprawnień. W analizowanej konfiguracji Calendars.ReadWrite występowało jako Application permission, dzięki czemu aplikacja mogła wykonywać operacje na wydarzeniach kalendarzowych wszystkich użytkowników tenant’a. Badacze zwrócili również uwagę na MailboxSettings.ReadWrite, czyli możliwość modyfikacji ustawień skrzynek.

• Seismic for Outlook miał 10 uprawnień, wśród nich Directory.Read.All, umożliwiające odczyt katalogu organizacji.

• Officely, narzędzie do rezerwowania biurek, żądało 14 uprawnień. W zestawie znalazły się między innymi ChatMember.ReadWrite.All i Chat.ManageDeletion.All, czyli zakresy pozwalające ingerować odpowiednio w członkostwo czatów oraz usuwanie wiadomości na poziomie organizacji.

Najmocniejszy przykład dotyczył monday.com. W badanym zestawie 14 uprawnień znajdowało się UserAuthenticationMethod.ReadWrite.All. Taki zakres pozwala odczytywać i zmieniać metody uwierzytelniania użytkowników w organizacji, w tym informacje związane z numerami telefonów i konfiguracją Microsoft Authenticator. Dla platformy do zarządzania projektami jest to uprawnienie wymagające bardzo mocnego uzasadnienia przed zatwierdzeniem.

Nie należy jednak wyciągać z tych przykładów wniosku, że wymienione produkty są złośliwe. Badanie analizowało statyczny zestaw zadeklarowanych lub przyznanych uprawnień, a nie rzeczywiste zachowanie aplikacji podczas pracy. Nie dowodzi więc nadużywania danych. Nie gwarantuje również, że dokładnie taki sam zestaw uprawnień jest wymagany w każdej konfiguracji produktu w sierpniu 2026 r. Przed decyzją liczy się lista wyświetlana dla konkretnej aplikacji w konkretnym tenantcie.

To ważne również z drugiej strony. Aplikacja może zostać uznana za nietypową właśnie dlatego, że korzysta z bezpieczniejszego, rzadziej spotykanego modelu. W badaniu Brochesia korzystała z ośmiu uprawnień RSC ograniczonych do konkretnych zasobów Teams. Algorytm oznaczył ją jako anomalną, ponieważ RSC było rzadkie, mimo że z punktu widzenia minimalizacji dostępu takie rozwiązanie jest korzystniejsze od szerokich uprawnień tenant-wide.

Administrator powinien porównywać funkcję aplikacji z każdym szerokim zakresem dostępu

Spośród 1069 aplikacji 139, czyli 13%, zostało wskazanych jako anomalne jednocześnie przez trzy metody wykrywania odstępstw: One-Class SVM, Local Outlier Factor i Isolation Forest. Aplikacji nie porównywano przy tym bezmyślnie ze wszystkimi pozostałymi. Najpierw podzielono je według deklarowanych funkcji na 24 grupy tematyczne, a dopiero potem sprawdzano, czy ich zestaw uprawnień odbiega od podobnych produktów.

To rozsądniejsze kryterium niż zasada „im mniej uprawnień, tym lepiej”. Asystent spotkań potrzebuje innych danych niż system bezpieczeństwa, dodatek do SharePointa czy narzędzie do rezerwacji biurek. Alarm powinien uruchomić się wtedy, gdy aplikacja chce dostępu, którego nie da się logicznie połączyć z jej podstawowym zadaniem.

W ręcznej kontroli ośmiu aplikacji wskazanych jako anomalne w sześciu przypadkach badacze ocenili nietypowe uprawnienia jako nadmierne albo trudne do uzasadnienia zadeklarowaną funkcją. To nadal nie jest dowód złych zamiarów dostawcy. Jest za to wystarczający powód, aby nie traktować zgody administratora jako formalności.

W polskiej organizacji trzeba do tego dołożyć wymagania RODO. Art. 5 ust. 1 lit. c RODO wprowadza zasadę minimalizacji danych: przetwarzane dane mają być adekwatne, stosowne i ograniczone do tego, co niezbędne. Jeśli zewnętrzna aplikacja przetwarza dane osobowe w imieniu firmy, znaczenie ma również relacja z dostawcą określona m.in. w art. 28 RODO. Sam fakt, że integracja znajduje się w ekosystemie Microsoft 365, nie przenosi odpowiedzialności za ocenę dostępu na Microsoft.

Praktyczny proces zatwierdzania aplikacji powinien wyglądać następująco:

1. Najpierw sprawdź rodzaj zgody. Application permission ma wyższy priorytet kontroli niż zwykłe delegowane uprawnienie użytkownika.

2. Wyszukaj .All, ReadWrite, Directory, Mail, Files, Chat i uprawnienia administracyjne. Nie są automatycznie niedopuszczalne, ale każde wymaga uzasadnienia funkcją produktu.

3. Porównaj zakres z zadaniem aplikacji. Dodatek rezerwujący biurka może potrzebować użytkowników i kalendarza; możliwość kasowania wiadomości ze wszystkich czatów wymaga już osobnego wyjaśnienia.

4. Sprawdź wydawcę. Status Verified Publisher ogranicza ryzyko podszywania się pod dostawcę, ale nie oznacza, że każde żądane uprawnienie jest potrzebne.

5. Sprawdź Microsoft 365 Certification lub Publisher Attestation, jeżeli są dostępne. Certyfikacja podnosi poziom weryfikacji, ale także nie zastępuje analizy zakresów OAuth.

6. Nie przyznawaj zgody, jeśli administrator nie rozumie któregoś uprawnienia. To przypadek do wyjaśnienia z producentem, a nie do „zaakceptowania na próbę”.

7. Po wdrożeniu regularnie przeglądaj Enterprise Applications w Microsoft Entra ID. Jeśli organizacja korzysta z funkcji App Governance w Microsoft Defender for Cloud Apps, można dodatkowo sprawdzać między innymi uprawnienia Microsoft Graph, które nie były używane przez ostatnie 90 dni.

W Entra ID sensownym ustawieniem dla firmy jest ograniczenie możliwości samodzielnego wyrażania zgody przez użytkowników i skierowanie bardziej wymagających integracji do Admin Consent Workflow. Microsoft umożliwia ustawienie polityki, w której użytkownicy mogą samodzielnie zatwierdzać tylko aplikacje spełniające określone kryteria, na przykład pochodzące od zweryfikowanych wydawców i proszące o wybrane, niskiego ryzyka zakresy. Pozostałe żądania mogą trafić do administratora.

Nie warto jednak blokować wszystkiego bez wyjątku. Efektem bywa obchodzenie procedur przez pracowników i powstawanie shadow IT. Lepsza granica decyzyjna jest prostsza: zwykły użytkownik może zatwierdzać wyłącznie wcześniej zdefiniowane, niskiego ryzyka zakresy, a dostęp obejmujący całą organizację trafia do administratora i właściciela danych.

Dodatkowe informacje na: ANCHOR

FAQ

Czy aplikacja z Microsoft Marketplace jest automatycznie bezpieczna?
Nie. Obecność w oficjalnym kanale dystrybucji nie oznacza, że wszystkie żądane przez aplikację uprawnienia są niezbędne dla konkretnej organizacji. Trzeba osobno sprawdzić wydawcę, certyfikację i zakres OAuth.

Co jest groźniejsze: Delegated permission czy Application permission?
W typowej sytuacji większą ostrożność należy zachować przy Application permissions, ponieważ aplikacja może działać bez zalogowanego użytkownika i otrzymać dostęp na poziomie tenant’a. Delegated permissions działają w kontekście użytkownika, choć również mogą być szerokie.

Czy końcówka .All oznacza dostęp do całej organizacji?
Często sygnalizuje szeroki zakres obejmujący wszystkie zasoby danego typu, ale znaczenie trzeba sprawdzić dla konkretnego uprawnienia i rodzaju zgody. Files.Read.All jako Application permission jest zupełnie inną kategorią ryzyka niż podstawowe User.Read.

Czy 139 aplikacji oznaczonych jako anomalne było niebezpiecznych?
Nie. 139 z 1069 aplikacji, czyli 13%, odbiegało profilem uprawnień od narzędzi o podobnej funkcji według wszystkich trzech zastosowanych algorytmów. Anomalia jest sygnałem do kontroli, a nie dowodem złośliwego działania.

Czy certyfikat Microsoft 365 wystarcza do zatwierdzenia aplikacji?
Nie. Microsoft 365 Certification daje dodatkową informację o kontroli bezpieczeństwa i zgodności dostawcy, ale administrator nadal powinien ocenić, czy konkretne uprawnienia są proporcjonalne do potrzeb swojej firmy.

Gdzie w firmie sprawdzić aplikacje, które już mają dostęp do Microsoft 365?
Podstawowym miejscem jest Microsoft Entra admin center i sekcja Enterprise applications. Priorytetem są aplikacje z uprawnieniami typu Application, szerokimi zakresami .All oraz prawami do zapisu lub modyfikacji danych.

Pierwszy ruch nie powinien więc polegać na przeglądaniu wszystkich kilku czy kilkudziesięciu integracji po kolei. Najpierw wyfiltruj aplikacje mające Application permissions i zakresy .ReadWrite.All, .Read.All oraz inne prawa obejmujące cały tenant. To tam pojedyncza błędna zgoda ma największy możliwy zasięg. Dopiero po usunięciu lub uzasadnieniu tych przypadków ma sens porządkowanie mniej uprzywilejowanych dodatków.