Uprawnienia delegowane a uprawnienia aplikacji: jak wybrać model odpowiedni dla Twojej aplikacji

By Mirko Peters · 2026-08-11

Automatically translated with AI from the original post. Read the English original

Titelbild: Delegated vs. Application Permissions: Choosing the Right Model for Your App

Witamy ponownie w podcaście i w naszej cyklicznej serii, która pomaga opanować Microsoft 365, Azure oraz narzędzia dla deweloperów napędzające nowoczesny ekosystem chmury. Jeśli kiedykolwiek tworzyłeś integrację, pisałeś skrypt lub wdrażałeś automatyzację dla przedsiębiorstwa z użyciem interfejsu Microsoft Graph API, z pewnością napotkałeś ścianę uprawnień. Zabezpieczenie dzierżawy przy jednoczesnym tworzeniu funkcjonalnych aplikacji to jedno z najtrudniejszych zadań równoważenia, przed jakimi stoi administrator lub deweloper. Wybór modelu uprawnień bezpośrednio wpływa na poziom bezpieczeństwa, tempo wdrożeń i ogólną architekturę systemu.

Aby lepiej zgłębić ten złożony temat, niedawno nagraliśmy odcinek z pogłębioną analizą. Koniecznie posłuchaj pełnej dyskusji audio pod adresem Microsoft Graph Permissions and Consent Models Explained. W tym towarzyszącym wpisie na blogu rozwiniemy te koncepcje, przyjrzymy się podstawowym różnicom między uprawnieniami delegowanymi a uprawnieniami aplikacji, omówimy modele zgody, przedstawimy sprawdzone praktyki oraz kompleksowe ramy, które pomogą utrzymać Twoje aplikacje w bezpieczeństwie i zgodności z wymogami.

Przegląd uprawnień interfejsu Microsoft Graph API

Zanim przejdziemy do niuansów konkretnych przepływów autoryzacji, warto zrozumieć, czym właściwie są uprawnienia interfejsu Microsoft Graph API. W swojej istocie Microsoft Graph działa jako ujednolicona brama do danych znajdujących się w usługach Microsoft 365, w tym w usłudze Exchange Online, SharePoint, Microsoft Teams, OneDrive oraz Azure Active Directory (Microsoft Entra ID). Zamiast zmuszać deweloperów do uwierzytelniania w wielu odizolowanych punktach końcowych, Microsoft Graph udostępnia jeden punkt końcowy REST API. Ponieważ jednak to API otwiera dostęp niemal do każdego zakątka cyfrowego zasobu organizacji, jego zabezpieczenie wymaga solidnej, szczegółowej struktury uprawnień.

Uprawnienia delegowane a uprawnienia aplikacji

Gdy rejestrujesz aplikację w platformie tożsamości Microsoft, musisz jawnie zadeklarować, w jaki sposób aplikacja ma współdziałać z zasobami. Sprowadza się to zasadniczo do wyboru między dwoma podstawowymi typami uprawnień: uprawnieniami delegowanymi a uprawnieniami aplikacji. Ten wybór determinuje sposób uwierzytelniania aplikacji, to, kogo lub co reprezentuje, oraz granice danych, które może pobierać.

Uprawnienia delegowane są przeznaczone dla aplikacji po stronie klienta lub skierowanych do użytkownika, takich jak aplikacje webowe z pojedynczą stroną, aplikacje mobilne czy narzędzia desktopowe, w których zalogowany użytkownik jest aktywnie obecny. W tym modelu aplikacja działa *w imieniu* użytkownika. Może uzyskiwać dostęp wyłącznie do danych i wykonywać wyłącznie te działania, do których dany użytkownik ma uprawnienia. Gdy użytkownik uruchamia aplikację, zostaje poproszony o zalogowanie się i wyraźne udzielenie zgody, w wyniku czego wystawiany jest token dostępu OAuth 2.0 zawierający zarówno tożsamość użytkownika, jak i zatwierdzone zakresy.

Uprawnienia aplikacji natomiast są wykorzystywane przez usługi działające w tle, demony, zadania webowe oraz zautomatyzowane runbooki, które działają niezależnie od kontekstu użytkownika. Tutaj aplikacja działa jako własna tożsamość. Do uzyskania tokena dostępu tylko dla aplikacji z usługi Azure AD wykorzystuje poświadczenia klienta, takie jak sekret klienta, para kluczy certyfikatu publicznego/prywatnego lub tożsamość zarządzana. Ponieważ żaden człowiek nie siedzi przy klawiaturze, aby się uwierzytelnić, uprawnienia te obejmują zasoby w całej dzierżawie. W związku z tym wiążą się z istotnie wyższym ryzykiem bezpieczeństwa i zawsze wymagają wyraźnej zgody administratora dzierżawy.

Kluczowe różnice i przypadki użycia

Zrozumienie, kiedy zastosować każdy z modeli uprawnień, pozwala uniknąć wąskich gardeł architektonicznych i luk w zabezpieczeniach. Przyjrzyjmy się szybkiemu zestawieniu porównawczemu:

Uprawnienia delegowane: Aplikacja działa w imieniu użytkownika. Użytkownik musi się zalogować i udzielić zgody. Aplikacja widzi tylko to, co widzi użytkownik. Ten model sprawdza się w aplikacjach klienckich odczytujących lub zapisujących dane osobiste, takie jak indywidualne kalendarze czy wiadomości e-mail.
Uprawnienia aplikacji: Aplikacja działa jako sama siebie. Żaden użytkownik nie musi się logować. Zgodę musi wyrazić administrator. Aplikacja może przeglądać i modyfikować dane w całej dzierżawie. Ten model sprawdza się w synchronizacji w tle, raportowaniu administracyjnym oraz zautomatyzowanych zadaniach zarządzania.

Wybór właściwego modelu zależy w całości od architektury aplikacji. Jeśli na przykład tworzysz interaktywny pulpit, który wyświetla profil użytkownika i jego osobistą skrzynkę odbiorczą, musisz użyć uprawnień delegowanych. Z kolei jeśli opracowujesz zautomatyzowany skrypt, który o północy skanuje skrzynki pocztowe wszystkich użytkowników w organizacji na potrzeby audytu zgodności, wymagane są uprawnienia aplikacji.

Uprawnienia delegowane w Microsoft Graph

Jak działają uprawnienia delegowane

Dostęp delegowany jest ściśle powiązany z tożsamością użytkownika. Gdy aplikacja żąda uprawnienia delegowanego, zasadniczo prosi serwer autoryzacji o zgodę na podszywanie się pod zalogowanego użytkownika w określonych granicach. Token dostępu zwracany w przepływie kodu autoryzacji OAuth zawiera konkretne oświadczenia zakresów (scope claims), które odzwierciedlają zarówno wbudowane uprawnienia użytkownika, jak i uprawnienia zażądane przez aplikację.

Dostęp delegowany oznacza, że aplikacja działa bezpośrednio jako użytkownik.
Zarówno rejestracja aplikacji, jak i poszczególny użytkownik muszą posiadać odpowiednie uprawnienia bazowe.
Zakresy określają dokładny maksymalny poziom tego, co aplikacja może robić w imieniu użytkownika.
Powstały token dostępu łączy tożsamość aplikacji z kontekstem użytkownika.

Typowe scenariusze dla uprawnień delegowanych

Uprawnienia delegowane napędzają większość codziennych integracji produktywności. Na przykład jeśli korporacyjna aplikacja do notatek musi synchronizować pliki z kontem użytkownika w usłudze OneDrive, żąda zakresu Files.ReadWrite. Jeśli użytkownik nie ma uprawnień do określonego dokumentu, interfejs API Graph odrzuci żądanie, nawet gdy zakres aplikacji technicznie na to pozwala. Podobnie aplikacje korzystające z zestawu Microsoft Graph SDK do wysyłania zautomatyzowanych powiadomień e-mail w imieniu użytkownika wykorzystują zakresy delegowane, takie jak Mail.Send.

Zagadnienia bezpieczeństwa i zgody

Chociaż uprawnienia delegowane są z natury bezpieczniejsze niż uprawnienia aplikacji obejmujące całą dzierżawę, ponieważ ograniczają je uprawnienia użytkownika, nadal stwarzają specyficzne wyzwania bezpieczeństwa. Jeśli aplikacja żąda zbyt szerokich zakresów, takich jak pełny dostęp do całej skrzynki pocztowej użytkownika i profilu w katalogu, udany atak phishingowy lub przejęcie aplikacji może ujawnić wrażliwe dane osobowe. Deweloperzy muszą ściśle przestrzegać zasady najmniejszych uprawnień, żądając wyłącznie tych zakresów, które są niezbędne do bieżącego działania.

Uprawnienia aplikacji w Microsoft Graph

Jak działają uprawnienia aplikacji

Uprawnienia aplikacji eliminują element ludzki z procesu uwierzytelniania. Zamiast korzystać z monitu logowania, aplikacja uwierzytelnia się bezpośrednio w usłudze Microsoft Entra ID przy użyciu poświadczeń klienta. Powstały token zawiera role aplikacji zamiast zakresów delegowanych, co daje jednostce usługi szeroki, nieograniczony dostęp do zasobów w całej dzierżawie.

Uprawnienia aplikacji działają całkowicie bez zalogowanego użytkownika.
Aplikacja pozyskuje token wyłącznie dla aplikacji, aby wysyłać zapytania do zasobów.
Dostęp jest regulowany przez role aplikacji przypisane jednostce usługi, a nie przez indywidualne uprawnienia użytkownika.

Kiedy stosować uprawnienia aplikacji

Uprawnienia aplikacji należy ściśle ograniczyć do obciążeń po stronie serwera, nienadzorowanych demonów i integracji system-system. Przykładami są zautomatyzowane silniki udostępniania użytkowników, scentralizowane systemy kopii zapasowych, narzędzia do reagowania na incydenty bezpieczeństwa oraz skrypty migracji dzierżawy.

Zgoda administratora i implikacje bezpieczeństwa

Ponieważ uprawnienia aplikacji omijają ograniczenia poszczególnych użytkowników i przyznają dostęp obejmujący całą dzierżawę, zwykli użytkownicy nie mogą wyrażać na nie zgody. Zgodę na uprawnienia aplikacji może udzielić wyłącznie administrator z uprawnieniami uprzywilejowanymi. Błędnie skonfigurowane uprawnienia aplikacji, takie jak przyznanie Directory.ReadWrite.All lub Mail.ReadWrite.All niezaufanej lub słabo napisanej aplikacji działającej w tle, mogą pozostawić całą dzierżawę Microsoft 365 podatną na pełne przejęcie. Zawsze regularnie audytuj jednostki usługi aplikacji korporacyjnych.

Zalety i wady uprawnień interfejsu API Microsoft Graph

Zalety

Zunifikowany model uprawnień: Jednolita, spójna struktura autoryzacji dla wszystkich usług Microsoft 365 upraszcza administrowanie.
Szczegółowe zakresy: Precyzyjne zakresy delegowane i aplikacji umożliwiają tworzenie architektur zgodnych z zasadą najmniejszych uprawnień.
Standardowy protokół OAuth2/OpenID Connect: Wykorzystuje powszechnie przyjęte standardy bezpieczeństwa, zapewniając prostą integrację tożsamości.
Integracja RBAC: Płynnie łączy się z rolami w Azure AD i zasadami dostępu warunkowego, zapewniając scentralizowaną zgodność z wymogami.
Przyrostowa zgoda: Pozwala aplikacjom z czasem żądać dodatkowych uprawnień, zamiast wymagać wszystkich od razu.

Wady

Złożoność: Poruszanie się po przecięciu delegowanych zakresów, ról aplikacji i modeli zgody administratora może przytłoczyć osoby początkujące.
Ryzyko uprawnień o wysokim poziomie dostępu: Błędna konfiguracja szerokich uprawnień (takich jak Sites.FullControl.All) może udostępnić ogromne ilości danych firmowych.
Wąskie gardła związane ze zgodą administratora: Wymaganie zatwierdzenia przez administratora dla uprawnień o dużym wpływie może spowolnić zwinne cykle tworzenia oprogramowania.
Rozproszona dokumentacja: Deweloperzy często muszą sprawdzać wiele repozytoriów dokumentacji Microsoft, aby odwzorować dokładne zachowania interfejsów API.

Modele zgody i najlepsze praktyki

Zgoda użytkownika a zgoda administratora w Microsoft Graph

Zarządzanie sposobem uzyskiwania zgody ma kluczowe znaczenie dla ładu organizacyjnego. Zgoda użytkownika pozwala poszczególnym osobom autoryzować aplikacje do dostępu do ich danych osobowych. Zgoda administratora przenosi bramkę zatwierdzania do administratorów IT, którzy oceniają żądania aplikacji w imieniu całej organizacji. Nowoczesne podstawowe konfiguracje zabezpieczeń przedsiębiorstw często całkowicie wyłączają zgodę użytkownika, wymuszając wdrażanie wszystkich aplikacji w sformalizowanym procesie wstępnego zatwierdzania przez administratora.

Wpływ zasad dzierżawy na uprawnienia

Zasady dzierżawy przedsiębiorstwa mogą zasadniczo zmienić sposób działania aplikacji w czasie wykonywania. Jeśli administrator wymusił rygorystyczne zasady dostępu warunkowego, na przykład wymóg uwierzytelniania wieloskładnikowego (MFA) lub zgodnych urządzeń hybrydowo dołączonych do Azure AD, aplikacja próbująca pobrać token Graph bez spełnienia tych kryteriów zostanie zablokowana. Deweloperzy muszą projektować aplikacje tak, aby płynnie obsługiwały błędy pobierania tokenów i udostępniały jasne kroki naprawcze.

Strategie zapewniania sprawnego przepływu zgody

Aby zapobiec utrudnieniom dla użytkowników i blokadom administracyjnym, zaplanuj strategię uprawnień przed napisaniem kodu. Wdrażaj wzorce przyrostowej zgody, w których aplikacja żąda podstawowych zakresów tożsamości z góry i prosi o specjalistyczne uprawnienia do zasobów dopiero wtedy, gdy użytkownik przejdzie do konkretnych funkcji. Wykorzystaj zautomatyzowane procesy wstępnego zatwierdzania w Microsoft Entra ID, aby usprawnić tworzenie oprogramowania, zachowując jednocześnie ścisły nadzór nad bezpieczeństwem.

Typowe błędy związane z uprawnieniami interfejsu API Microsoft Graph

Mylenie uprawnień delegowanych z uprawnieniami aplikacji oraz błędne rozumienie wymagań dotyczących kontekstu użytkownika.
Żądanie nadmiernych uprawnień z góry zamiast przyjęcia podejścia najmniejszych uprawnień.
Brak uwzględnienia wymogów zgody administratora przy wdrażaniu usług działających w tle.
Zakładanie, że zmiany uprawnień w portalu Azure natychmiast wchodzą w życie bez odświeżenia tokenów.
Przedstawianie tokenu dostępu delegowanego tam, gdzie wymagany jest token poświadczeń klienta.
Ignorowanie zasad dostępu warunkowego, które blokują żądania interfejsu API Graph w czasie wykonywania.
Zaniedbanie walidacji oświadczeń dotyczących zakresów w kodzie aplikacji w czasie wykonywania.
Brak okresowego audytu przyznanych uprawnień aplikacji i jednostek usługi.

Lista kontrolna uprawnień interfejsu API Microsoft Graph

Skorzystaj z tej praktycznej listy kontrolnej, aby poprowadzić zespół przez bezpieczne projektowanie, wdrażanie i audytowanie uprawnień interfejsu API Microsoft Graph:

Podsumowanie

Poruszanie się po uprawnieniach interfejsu API Microsoft Graph nie musi być źródłem frustracji. Dzięki jasnemu zrozumieniu różnic operacyjnych między uprawnieniami delegowanymi (które wymagają zalogowanego użytkownika i działają w ramach ograniczeń użytkownika) a uprawnieniami aplikacji (które działają bez ograniczeń w tle i wymagają zgody administratora), możesz projektować bezpieczne i skalowalne rozwiązania. Stosowanie zasady najmniejszych uprawnień, rygorystyczny audyt oraz wykorzystanie narzędzi do zarządzania ładem w przedsiębiorstwie pozwolą chronić środowisko Microsoft 365 bez spowalniania innowacji.

Aby uzyskać więcej wskazówek eksperckich, praktycznych strategii i szczegółowych analiz zabezpieczania chmury, koniecznie posłuchaj naszego pełnego omówienia w powiązanym odcinku: Microsoft Graph Permissions and Consent Models Explained. Dbaj o to, by uprawnienia były ściśle kontrolowane, poświadczenia bezpieczne, a kodowanie przyjemne!