Liczba 1069 aplikacji z ponad 8000 wygląda jak prosty wskaźnik przejrzystości Microsoft 365. Nie jest nim. To finalny zbiór, dla którego badaczom udało się jednocześnie uzyskać wystarczająco użyteczny opis funkcji oraz zestaw uprawnień, poprawnie powiązać aplikację z jej Service Principal i przejść etap czyszczenia danych.

To rozróżnienie ma znaczenie. Z badania nie wynika, że pozostałe ponad 7000 aplikacji było złośliwych, nie miało żadnych opisów albo celowo ukrywało swoje permissions. Wynika z niego coś bardziej praktycznego dla administratora: ekosystem Microsoft 365 jest rozdrobniony, a informacja potrzebna do oceny ryzyka nie jest prezentowana w jednolity sposób.

Problem dotyczy przy tym dostępu do danych, które w firmowym tenantcie trudno uznać za drugorzędne: wiadomości Exchange Online, plików OneDrive i SharePoint, kalendarzy, kontaktów, czatów Teams, katalogu użytkowników czy metod uwierzytelniania.

Najważniejszy wniosek nie brzmi więc „blokować dodatki”. Brzmi: nie zatwierdzać aplikacji, dopóki nie wiadomo, jak jej funkcja przekłada się na konkretny typ i zakres permission.

Skąd naprawdę wzięło się 1069 aplikacji i czego ta liczba nie dowodzi

Badanie „Lost in Permissions: Exploring the Microsoft 365 App Ecosystem” opublikowano jako preprint 3 sierpnia 2026 r.. Część danych jest jednak starsza. Marketplace crawlowano we wrześniu 2025 r., a dane z rzeczywistego środowiska uniwersyteckiego były snapshotem z maja 2025 r.

Ma to praktyczną konsekwencję: zestawu permissions przypisanego w badaniu do konkretnego produktu nie należy traktować jak gwarancji jego konfiguracji w sierpniu 2026 r. Producent mógł zmienić integrację, manifest albo zakres żądanych zgód.

Badacze korzystali z kilku dróg pozyskiwania danych. W samym Microsoft Marketplace znaleźli 8232 unikalne aplikacje:

• Excel — 1338,
• Office — 412,
• Outlook — 2069,
• PowerPoint — 480,
• SharePoint — 1222,
• Teams — 2595,
• Word — 1306.

Suma kategorii jest większa niż 8232, ponieważ jedna aplikacja może występować przy kilku produktach.

Marketplace udostępniał opisy, ale nie dawał badaczom kompletnej listy uprawnień potrzebnej do analizy. Powstał więc testowy tenant i automat instalujący aplikacje oraz odczytujący permissions przypisane ich Service Principals.

Tutaj skala mocno się kurczy.

Spośród 8232 pozycji automat skutecznie wdrożył 432 aplikacje. Autorzy publikacji nazywają ten wynik „około 4%”, ale 432 podzielone przez 8232 daje matematycznie około 5,2%. Bezpieczniej więc posługiwać się w tym miejscu surowymi liczbami: 432 udane wdrożenia z 8232 unikalnych aplikacji Marketplace.

Powodów niepowodzeń było kilka. Część instalacji kończyła się błędem podczas procesu OAuth, niektóre aplikacje nie żądały permissions przy samym wdrożeniu, inne wymagały dodatkowej rejestracji lub przejścia przez portal producenta. Automat nie był zatem w stanie po prostu „zainstalować całego sklepu i odczytać wszystkiego”.

Do tego doszły inne źródła:

• dane z Teams,
• dane ze SharePoint Store,
• aplikacje z testowego crawla,
• 285 aplikacji obecnych w rzeczywistym tenantcie uczelni liczącym ponad 35 tys. użytkowników.

Przed deduplikacją połączony materiał obejmował 1286 pozycji. Następnie usunięto:

• 96 duplikatów,
• 61 przypadków z niejednoznacznym dopasowaniem aplikacji do Service Principal,
• 40 aplikacji z opisami innymi niż angielskie,
• 20 aplikacji z opisem krótszym niż 10 słów.

Zostało 1069 aplikacji.

To właśnie na nich wykonano właściwą analizę.

W tym zbiorze jedna aplikacja posiadała od 1 do 32 permissions, a łącznie pojawiło się ponad 300 różnych uprawnień OAuth. Najczęstsze należały do podstawowych:

• User.Read — około 48% aplikacji,
• openid — około 37%,
• profile — około 36%.

Sama liczba permissions nadal niewiele mówi o ryzyku. Integracja obejmująca Teams, kalendarz, pocztę i dokumenty może potrzebować więcej uprawnień niż prosty dodatek do pojedynczego dokumentu. Dziesięć dobrze uzasadnionych, wąskich permissions może być lepszym profilem niż jedno bardzo szerokie application permission.

Badacze poszli więc dalej. Na podstawie opisów pogrupowali aplikacje w 24 klastry funkcjonalne, m.in. zarządzanie plikami, bezpieczeństwo, powiadomienia, e-learning, HR czy narzędzia AI. Następnie w obrębie każdego klastra porównali profile uprawnień za pomocą trzech algorytmów wykrywania anomalii: One-Class SVM, Local Outlier Factor oraz Isolation Forest.

Do końcowej grupy trafiały tylko aplikacje wskazane jako anomalne przez wszystkie trzy metody.

Wynik: 139 aplikacji, czyli 13% finalnego zbioru 1069 pozycji.

I tu trzeba postawić wyraźną granicę. „Anomalna” nie oznacza „złośliwa”.

Aplikacja mogła odstawać, ponieważ:

• żądała zbyt szerokich uprawnień,
• żądała nietypowego, lecz uzasadnionego dostępu,
• korzystała z rzadkiego RSC,
• miała mniej permissions niż podobne programy,
• realizowała funkcję inaczej niż większość konkurentów.

Badacze dodatkowo wykorzystali GPT-5.2 do oceny zgodności opisów z permissions, ale sami podkreślili, że wynik LLM nie jest ground truth. Wykonali też ręczną, ślepą analizę ośmiu wybranych anomalii. W 6 z 8 przypadków wskazane uprawnienia uznano za nadmierne lub trudne do uzasadnienia na podstawie deklarowanej funkcji.

Osiem przypadków to za mało, aby wyliczać na tej podstawie skuteczność całej metody. Pokazuje natomiast, że anomaly detection ma sens jako filtr ustalający kolejność kontroli, a nie automat wydający wyrok „bezpieczne/niebezpieczne”.

Jest jeszcze jedno istotne ograniczenie: badanie było statyczne. Analizowano permissions, nie rzeczywiste zachowanie aplikacji podczas pracy. Permission określa, do czego aplikacja może zostać uprawniona. Nie dowodzi, że rzeczywiście czyta, kopiuje albo modyfikuje cały dostępny zakres danych.

Delegated, Application i RSC — bez tego sama końcówka .All mówi za mało

W audycie Microsoft 365 największy błąd zaczyna się od traktowania nazwy permission jako pełnego opisu ryzyka.

Files.ReadWrite.All wygląda groźnie — i często słusznie zwraca uwagę — ale trzeba jeszcze sprawdzić typ dostępu.

Microsoft Graph używa przede wszystkim dwóch modeli.

Delegated permissions działają w kontekście zalogowanego użytkownika. Aplikacja wykonuje operacje w jego imieniu, a możliwości zależą również od tego, do czego ten użytkownik sam ma dostęp.

Application permissions działają bez zalogowanego użytkownika. Aplikacja korzysta z własnej tożsamości i może mieć dostęp organizacyjny. Taki model wymaga szczególnej uwagi, ponieważ nie jest uzależniony od aktywnej sesji pracownika.

Do tego w Teams dochodzi Resource-Specific Consent, czyli RSC. Tutaj uprawnienie może być ograniczone do konkretnego zespołu, czatu, spotkania albo innego wspieranego zasobu, zamiast obejmować organizację.

Różnicę dobrze pokazuje Files.ReadWrite.All.

W wariancie Delegated pozwala aplikacji odczytywać, tworzyć, modyfikować i usuwać wszystkie pliki, do których dostęp ma zalogowany użytkownik.

W wariancie Application pozwala wykonywać takie operacje na plikach we wszystkich site collections bez zalogowanego użytkownika.

Nazwa jest ta sama. Powierzchnia dostępu — nie.

Dlatego reguła „każde .All jest złe” jest zbyt prymitywna. Z kolei reguła „to tylko jeden permission” jest jeszcze gorsza.

Przy każdej zgodzie administrator powinien ustalić co najmniej pięć rzeczy:

1. Co permission pozwala zrobić — read, write, create, delete, administracja.
2. Jaki ma typ — Delegated, Application lub RSC.
3. Jaki jest zakres danych — jeden użytkownik, dane dostępne użytkownikowi, konkretny zasób czy organizacja.
4. Czy aplikacja może działać bez aktywnego użytkownika.
5. Która konkretna funkcja produktu wymaga tego dostępu.

Dopiero razem tworzy to sensowny profil ryzyka.

W badaniu dobrze widać, dlaczego.

Mindomo 9.0 zostało wskazane m.in. z Files.ReadWrite.All. Dostęp do plików pasuje do aplikacji pracującej na mapach myśli i dokumentach. Trzeba jednak sprawdzić, czy wymagany zakres nie jest większy od funkcji, którą użytkownik rzeczywiście chce uruchomić. Kluczowe jest przy tym ustalenie typu permission — sama końcówka .All nie pozwala poprawnie opisać zasięgu.

Mocniejszym przypadkiem było monday.com. W badanym snapshotcie aplikacja projektowa posiadała łącznie 14 permissions, a wśród nich UserAuthenticationMethod.ReadWrite.All.

To uprawnienie pozwala odczytywać i modyfikować metody uwierzytelniania użytkowników, obejmujące m.in. numery telefonów i ustawienia Microsoft Authenticator. Microsoft zaznacza jednocześnie ważne ograniczenie: permission nie daje aplikacji wglądu w hasła i samo w sobie nie pozwala używać metod uwierzytelniania do logowania się jako użytkownik.

Nie zmienia to oceny operacyjnej. Dla platformy do zarządzania projektami możliwość modyfikacji metod uwierzytelniania użytkowników jest funkcjonalnie bardzo odległa od zarządzania zadaniami, tablicami i workflow. Bez technicznego uzasadnienia taki zakres powinien trafić do ręcznej eskalacji przed udzieleniem zgody, a nie przejść dlatego, że producent jest znany.

Officely, aplikacja do rezerwacji biurek zintegrowana z Teams, miała w badanym zestawie 14 permissions. Część można łatwo powiązać z funkcją, ale wśród anomalii znalazły się m.in.:

• ChatMember.ReadWrite.All,
• Chat.ManageDeletion.All.

Pierwsze z nich dotyczy zarządzania członkostwem w czatach.

Drugiego nie należy opisywać jako permission do „usuwania wiadomości”. Aktualna definicja Chat.ManageDeletion.All mówi o usuwaniu i odzyskiwaniu usuniętych czatów. To inna operacja niż zarządzanie pojedynczymi wiadomościami.

W aplikacji rezerwującej stanowiska pracy oba zakresy wymagają bardzo konkretnego wyjaśnienia: która funkcja biznesowa przestanie działać, jeżeli dane uprawnienie nie zostanie przyznane?

To jedno z najlepszych pytań kontrolnych podczas audytu. Jeżeli właściciel integracji ani producent nie umie wskazać funkcji, permission nie powinien być akceptowany „na zapas”.

Nie każda anomalia działa jednak w stronę nadmiernego dostępu.

Badacze pokazali też Brochesia i Vizerto, które korzystały z RSC. Ich permissions były rzadkie w zbiorze, więc modele uznały aplikacje za odstające. RSC mogło jednak ograniczać dostęp do konkretnego zespołu lub czatu zamiast całego tenanta. Z punktu widzenia least privilege jest to często właśnie pożądany kierunek.

To dobry przykład ograniczenia automatycznych scoringów. Rzadkie nie znaczy ryzykowne. Popularne również nie znaczy bezpieczne.

W grupie najmniej anomalnych badacze znaleźli m.in. aplikacje, których dostęp do rozmów Teams był podobny do innych produktów w tej samej kategorii. Algorytm nie podnosił alarmu, bo permission był tam popularny. Popularność wewnątrz klastra może więc ukryć ryzyko, tak samo jak rzadkość RSC może stworzyć fałszywy alarm.

Podio pokazuje jeszcze inną sytuację. W badanym profilu pojawiały się m.in.:

• Files.ReadWrite,
• Files.Read,
• Mail.Read,
• Contacts.Read,
• Contacts.ReadWrite.

Dla platformy automatyzującej procesy i budującej własne workflow taki zestaw może być funkcjonalnie spójny. Nie powinien być odrzucony tylko dlatego, że dotyka kilku kategorii danych. Trzeba za to ustalić, które moduły organizacja faktycznie wykorzystuje. Jeżeli firma korzysta tylko z jednej funkcji, szeroki pakiet dostępu potrzebny całej platformie może być większy niż realna potrzeba konkretnego wdrożenia.

To właśnie odróżnia analizę permission od zwykłego czytania ekranu consent.

Audyt Microsoft 365: najpierw dostęp bez użytkownika i szeroki zapis, dopiero potem reszta

Pierwszego przeglądu nie zaczynałbym od liczenia wszystkich aplikacji ani od usuwania każdego scope’u z .All. Najpierw trzeba znaleźć integracje, w których potencjalny skutek nadużycia jest największy.

Punktem startowym jest Microsoft Entra admin center → Enterprise apps → All applications.

Dla każdej istotnej zewnętrznej aplikacji przygotuj prosty rekord:

Najwyższy priorytet nadaj aplikacjom łączącym kilka z poniższych cech:

• Application permissions,
• ReadWrite lub uprawnienia administracyjne,
• dostęp tenant-wide,
• poczta wszystkich użytkowników,
• pliki i SharePoint całej organizacji,
• katalog Entra ID,
• zarządzanie grupami,
• czaty i wiadomości Teams,
• metody uwierzytelniania,
• zarządzanie aplikacjami, Service Principals lub zgodami,
• brak właściciela biznesowego,
• integracja, której nikt nie potrafi już uzasadnić.

W tej grupie szczególnie niebezpieczne operacyjnie są permissions pozwalające aplikacji działać bez zalogowanego użytkownika. Użytkownik nie musi wtedy aktywnie korzystać z integracji, aby aplikacja mogła wykonywać dozwolone operacje.

Drugi poziom kontroli obejmuje szerokie Delegated permissions. Nie należy ich bagatelizować. Jeżeli dyrektor, administrator albo użytkownik z dostępem do dużej części SharePointa nada aplikacji permission działające w jego kontekście, realny zasięg również może być bardzo duży.

Dopiero później przechodź do permissions ograniczonych do pojedynczych użytkowników i RSC działających na konkretnych zasobach.

Przy każdym podejrzanym zakresie zastosuj prosty test:

„Jaka funkcja przestanie działać, jeśli odbiorę właśnie ten permission?”

Dobra odpowiedź brzmi konkretnie:

„Bez Calendars.Read aplikacja nie odczyta terminów potrzebnych do wskazywania wolnych godzin.”

Słaba odpowiedź:

„Integracja tego potrzebuje do Microsoft Graph.”

Microsoft Graph jest interfejsem. Nie jest uzasadnieniem biznesowym.

Jeżeli nie ma konkretnej odpowiedzi, masz trzy rozsądne opcje:

• znaleźć węższy permission,
• wyłączyć funkcję wymagającą nadmiernego dostępu,
• wstrzymać wdrożenie do czasu uzyskania wyjaśnienia.

Po inwentaryzacji Enterprise apps sprawdź też Microsoft 365 admin center → Settings → Integrated apps. To miejsce służy do centralnego zarządzania wdrożonymi dodatkami Office i ich dostępnością dla użytkowników lub grup.

Nie są to dwa identyczne widoki rozwiązujące ten sam problem. Microsoft 365 Integrated apps pomaga zarządzać wdrożeniami dodatków, a Entra pokazuje tożsamości aplikacji, Service Principals i udzielone zgody. Audyt obejmujący tylko jeden z tych obszarów może być niepełny.

Następny punkt to polityka consent.

Microsoft Entra pozwala ograniczyć samodzielne udzielanie zgód przez użytkowników. Organizacja może dopuścić user consent tylko dla określonych, niskiego ryzyka delegated permissions i zweryfikowanych producentów albo całkowicie wymagać ścieżki administracyjnej dla nowych integracji.

Application permissions nie mogą być traktowane jak uprawnienia niskiego ryzyka przeznaczone do samodzielnego consentu użytkownika.

Jeżeli firma ogranicza user consent, warto skonfigurować admin consent workflow. Użytkownik potrzebujący aplikacji może wtedy przesłać formalny wniosek, zamiast szukać administratora na czacie albo próbować obejść procedurę.

Sam workflow nie rozwiązuje jednak problemu. Reviewer powinien dostać przynajmniej:

• nazwę i przeznaczenie aplikacji,
• pełną listę wymaganych permissions,
• rozróżnienie Delegated/Application/RSC,
• uzasadnienie szerokich zakresów,
• właściciela biznesowego,
• informację, czy istnieje węższa konfiguracja.

Znana marka nie zastępuje tej analizy. Consent zostaje udzielony konkretnemu Service Principal i konkretnym uprawnieniom, nie logo producenta.

W polskiej organizacji trzeba do tego dołożyć drugą warstwę: rzeczywiste przetwarzanie danych osobowych.

Permission i przetwarzanie to nie to samo.

Jeżeli aplikacja ma Mail.Read, technicznie może otrzymać dostęp do wiadomości w określonym zakresie. Nie wynika z tego automatycznie, że dostawca kopiuje całą skrzynkę do własnej infrastruktury. To trzeba ustalić osobno.

Przed zatwierdzeniem aplikacji dotykającej poczty, dokumentów, kontaktów, kalendarzy czy rozmów pracowników sprawdź więc również:

• jakie dane rzeczywiście są wysyłane do dostawcy,
• w jakim celu,
• gdzie są przetwarzane,
• jak długo są przechowywane,
• jakie podmioty uczestniczą w dalszym przetwarzaniu,
• czy dochodzi do transferu poza EOG,
• czy wymagana jest umowa powierzenia,
• jak wygląda usuwanie danych po zakończeniu korzystania z usługi.

To ostatnie jest często pomijane. Odebranie OAuth consent zatrzymuje przyszły dostęp wynikający ze zgody, ale nie usuwa automatycznie danych, które aplikacja zdążyła wcześniej skopiować do własnego systemu.

Offboarding integracji powinien więc obejmować dwa oddzielne zadania:

1. odebranie technicznego dostępu do Microsoft 365,
2. zweryfikowanie usunięcia lub dalszego legalnego przechowywania danych po stronie dostawcy.

Jeżeli masz dziś zrobić tylko jedną rzecz, zacznij od Enterprise apps i application permissions umożliwiających szeroki zapis lub operacje administracyjne bez zalogowanego użytkownika. Następnie przejrzyj szerokie Delegated permissions. .All traktuj jako sygnał do kontroli, nie automatyczny wyrok.

Najpierw usuń sytuację, w której nikt w firmie nie potrafi odpowiedzieć, po co dana aplikacja nadal ma dostęp do danych całej organizacji. Dopiero po tym warto optymalizować drobniejsze zgody i budować bardziej rozbudowany governance.

FAQ

Czy 1069 oznacza, że pozostałe ponad 7000 aplikacji nie ujawniało żadnych uprawnień?
Nie. 1069 to finalny, oczyszczony zbiór aplikacji, dla których badacze dysponowali jednocześnie odpowiednim opisem i przypisanym zestawem permissions. Liczba powstała po połączeniu kilku źródeł, deduplikacji, odrzuceniu niejednoznacznych dopasowań i filtrowaniu opisów.

Czy permission z .All zawsze oznacza dostęp do całego tenanta?
Nie w identyczny sposób. Znaczenie zależy od konkretnego permission i jego typu. Przykładowo Delegated Files.ReadWrite.All obejmuje wszystkie pliki dostępne zalogowanemu użytkownikowi, natomiast wariant Application działa bez użytkownika i obejmuje pliki we wszystkich site collections. Trzeba czytać pełną definicję permission, nie samą nazwę.

Czym różni się Delegated od Application permission?
Delegated działa w imieniu zalogowanego użytkownika i jest ograniczone również jego prawami. Application działa jako sama aplikacja, bez aktywnego użytkownika. Z punktu widzenia audytu Application permissions zwykle wymagają wcześniejszej kontroli, szczególnie gdy umożliwiają zapis lub dostęp organizacyjny.

Czy RSC jest bezpieczniejsze od zwykłych permissions Microsoft Graph?
Może znacząco ograniczać powierzchnię dostępu, ponieważ dotyczy konkretnego zasobu, np. jednego zespołu lub czatu. Nie oznacza to automatycznej gwarancji bezpieczeństwa. Nadal trzeba sprawdzić, jakie operacje aplikacja może wykonać w obrębie tego zasobu.

Czy 139 aplikacji oznaczonych jako anomalne było niebezpiecznych?
Nie. 139 aplikacji, czyli 13% finalnego zbioru, odbiegało profilem permissions od podobnych funkcjonalnie aplikacji według trzech algorytmów. Anomalia mogła oznaczać nadmierny dostęp, zbyt mały zestaw permissions albo uzasadnione wykorzystanie rzadkiego RSC. To lista do dalszej analizy, nie lista złośliwego oprogramowania.

Jak wiarygodna była ręczna weryfikacja badania?
Ręcznie sprawdzono osiem anomalnych aplikacji. W sześciu przypadkach uprawnienia wyglądały na nadmierne lub trudne do uzasadnienia. Próbka jest zbyt mała, by na jej podstawie wyliczać skuteczność dla całego rynku, ale potwierdza użyteczność metody jako narzędzia do priorytetyzacji kontroli.

Czy UserAuthenticationMethod.ReadWrite.All daje aplikacji hasła użytkowników?
Nie. Permission pozwala odczytywać i modyfikować metody uwierzytelniania, m.in. związane z numerami telefonów i Microsoft Authenticator, ale Microsoft wyraźnie zaznacza, że nie ujawnia ono haseł i samo nie pozwala aplikacji logować się za pomocą metod użytkownika. Nadal jest to bardzo szeroki zakres administracyjny wymagający mocnego uzasadnienia.

Czy Chat.ManageDeletion.All pozwala kasować wszystkie wiadomości w Teams?
Nie należy go tak opisywać. Aktualna definicja dotyczy usuwania i odzyskiwania usuniętych czatów. Operacje na poszczególnych wiadomościach są związane z innymi permissions i API.

Gdzie najpierw sprawdzić aplikacje mające dostęp do firmowego Microsoft 365?
W Microsoft Entra admin center przejdź do Enterprise apps → All applications, wybierz aplikację i przejrzyj jej permissions oraz udzielone zgody. Dodatki centralnie wdrożone w Microsoft 365 sprawdź również w Settings → Integrated apps.

Co sprawdzić w pierwszych 15 minutach audytu?
Najpierw znajdź application permissions pozwalające na ReadWrite, operacje administracyjne albo szeroki dostęp do poczty, plików, Teams, katalogu i metod uwierzytelniania. Dla każdej aplikacji ustal właściciela biznesowego i zapytaj, która funkcja wymaga danego permission. Brak właściciela lub brak konkretnego uzasadnienia oznacza wyższy priorytet kontroli.

Jak często przeglądać aplikacje i zgody?
Nie ma jednego uniwersalnego interwału pasującego każdej organizacji. Kwartalny przegląd jest rozsądnym procesem operacyjnym przy niewielkiej liczbie integracji, a przy częstych wdrożeniach SaaS nowe zgody warto kontrolować na bieżąco lub co miesiąc. Niezależnie od harmonogramu dodatkowy przegląd powinien nastąpić po zmianie permissions, zmianie funkcji produktu, odejściu właściciela biznesowego, zakończeniu projektu lub utracie uzasadnienia dla integracji.

Czy odebranie consent usuwa dane, które aplikacja wcześniej pobrała?
Nie. Odebranie zgody blokuje dalszy dostęp wynikający z danego consentu, ale kopie danych już zapisane w systemie dostawcy mogą nadal istnieć. Dlatego wyłączenie aplikacji i usunięcie danych u zewnętrznego dostawcy to dwa oddzielne etapy offboardingu.