M365Con 2027 – bezpłatna konferencja online · 11–22 Jan 2027 · 120 sessions→ m365con.net

Blog · Mirko Peters

Uprawnienia delegowane a uprawnienia aplikacji w Microsoft Entra ID: co administratorzy powinni wiedzieć

By ·

Poznaj kluczowe różnice między uprawnieniami delegowanymi a uprawnieniami aplikacji w Microsoft Entra ID, w tym najlepsze praktyki bezpieczeństwa i zasady najmniejszych uprawnień.

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

Cover: OAuth 2.0 - Simply Explained

Integrując narzędzia zewnętrzne lub niestandardowe aplikacje ze środowiskiem Microsoft 365, zrozumienie różnicy między uprawnieniami delegowanymi a uprawnieniami aplikacji jest kluczowe dla zachowania bezpieczeństwa w chmurze, zapobiegania wyciekom danych i egzekwowania zasady najmniejszych uprawnień w Microsoft Entra ID.

Najważniejsze wnioski

Zrozumienie uprawnień OAuth w chmurze Microsoft

Gdy podłączasz zewnętrzne narzędzie produktywności lub wewnętrzny skrypt automatyzacji do swojego środowiska Microsoft 365, uruchamiasz proces OAuth 2.0. Samo uzyskanie tokenu dostępu to jednak dopiero połowa sukcesu. Rzeczywistą granicę bezpieczeństwa wyznacza to, co dany token faktycznie może robić. W ekosystemie tożsamości Microsoft, na którego czele stoi Microsoft Entra ID (dawniej Azure Active Directory), uprawnienia dzielą się na dwa zasadniczo różne rodzaje: uprawnienia delegowane i uprawnienia aplikacji.

Pomylenie tych dwóch modeli to jedna z najczęstszych pułapek dla administratorów IT, deweloperów i zaawansowanych użytkowników. Wybór niewłaściwego typu uprawnień może przypadkowo ujawnić dane całej firmy lub całkowicie zepsuć działanie aplikacji. Przyjrzyjmy się więc, jak działa każdy z typów, gdzie są przechowywane i jak nimi zarządzać w prawidłowy sposób.

Uprawnienia delegowane: działanie w imieniu użytkownika

Uprawnienia delegowane są przeznaczone dla aplikacji, przed którymi siedzi człowiek. Gdy logujesz się do aplikacji mobilnej lub usługi internetowej przy użyciu konta Microsoft, aplikacja przejmuje Twoją tożsamość do wykonania określonego zestawu zadań. Nazywa się to uprawnieniem delegowanym.

W tym scenariuszu aplikacja działa jako Ty. Może sięgać wyłącznie po dane, do których Ty już masz dostęp, i nic ponadto. Jeśli Twoje konto użytkownika nie ma prawa odczytu do konkretnego folderu w SharePoint ani do kalendarza współpracownika, aplikacja również do niego nie będzie mieć dostępu. Ponieważ zasięg potencjalnych szkód jest naturalnie ograniczony uprawnieniami poszczególnego użytkownika, Microsoft zaleca stosowanie uprawnień delegowanych zawsze wtedy, gdy w przepływie pracy uczestniczy człowiek.

Jak uprawnienia delegowane wyglądają w praktyce

Z uprawnieniami delegowanymi stykasz się za każdym razem, gdy klikasz okno zgody. Asystent do planowania spotkań może wyświetlić ekran informujący, że chce odczytywać Twój kalendarz. Takie żądanie odpowiada konkretnemu zakresowi OAuth. Ponieważ jesteś obecny, aby zatwierdzić lub odrzucić żądanie, działasz jako właściciel zasobu i kontrolujesz dokładnie to, co aplikacja kliencka może pozyskać z Twojego profilu.

Uprawnienia aplikacji: usługi w tle i dostęp w skali całej dzierżawy

Uprawnienia aplikacji działają w zupełnie innym modelu. Są przeznaczone dla procesów działających w tle, zautomatyzowanych skryptów synchronizacji i usług backendowych, które działają o trzeciej w nocy, gdy żaden użytkownik nie jest zalogowany. Pomyśl o zautomatyzowanym narzędziu raportującym, które agreguje dane ze wszystkich skrzynek pocztowych w organizacji.

Ponieważ nie ma użytkownika, który dostarczyłby kontekst tożsamości, aplikacja uwierzytelnia się przy użyciu własnych poświadczeń (np. identyfikatora klienta i wpisu tajnego klienta w przepływie poświadczeń klienta). W konsekwencji uprawnienia aplikacji dają narzędziu możliwość działania w imieniu własnym w całej organizacji. Jeśli aplikacja ma uprawnienia aplikacji do odczytu poczty, może odczytać pocztę każdego użytkownika w dzierżawie.

Dlaczego zgoda administratora jest obowiązkowa

Ze względu na ogromne możliwości, jakie dają uprawnienia aplikacji, zwykli użytkownicy nie mogą ich zatwierdzać. Standardowy pracownik może zatwierdzić uprawnienie delegowane do własnego kalendarza, natomiast uprawnienia aplikacji wymagają wyraźnej zgody administratora globalnego lub administratora roli uprzywilejowanej. Ta ścisła kontrola zapobiega cichemu pozyskiwaniu danych z całej organizacji przez złośliwe lub źle napisane aplikacje.

Microsoft Graph a rola zakresów OAuth

Niezależnie od tego, czy aplikacja używa uprawnień delegowanych, czy uprawnień aplikacji, ostatecznie kieruje swoje żądania przez jedną, potężną bramę: Microsoft Graph. Każdy czat zespołu, dokument w usłudze SharePoint, plik w usłudze OneDrive i wiadomość e-mail w programie Outlook są dostępne za usługą Microsoft Graph, pod warunkiem że aplikacja wywołująca przedstawi prawidłowy token dostępu OAuth.

Mechanizmami, które pilnują, aby te tokeny działały zgodnie z przeznaczeniem, są zakresy. Zakres to precyzyjna etykieta osadzona w tokenie, która określa dokładne granice, na przykład odczyt kalendarza kontra wysyłanie wiadomości e-mail. Gdy deweloperzy żądają zbyt szerokich zakresów (np. dostępu do odczytu i zapisu, mimo że wystarczyłby prosty dostęp do odczytu), naruszają podstawowe zasady bezpieczeństwa. Administratorzy muszą dokładnie audytować te zakresy podczas przeglądów rejestracji aplikacji.

Egzekwowanie zasady najmniejszych uprawnień w dzierżawie

Najlepsze praktyki bezpieczeństwa w usłudze Microsoft Entra ID zawsze sprowadzają się do jednej złotej zasady: zasady najmniejszych uprawnień. Każda aplikacja, każdy podmiot usługi i każdy skrypt automatyzacji powinien otrzymać absolutnie minimalny poziom dostępu niezbędny do wykonania swojego zadania.

Podsumowanie

Poruszanie się po mechanizmach nowoczesnej tożsamości w chmurze wymaga spojrzenia poza proste przyciski logowania i zbadania leżących u podstaw struktur uprawnień. Niezależnie od tego, czy zarządzasz mobilnymi aplikacjami dla użytkowników z zakresami delegowanymi, czy rozbudowanymi automatyzacjami przedsiębiorstwa opartymi na uprawnieniach aplikacji, zrozumienie tych granic jest niezbędne dla bezpiecznego środowiska Microsoft 365.

Aby zgłębić podstawy działania tych wymian, posłuchaj pełnego odcinka podcastu, w którym w przystępny sposób omówiono OAuth 2.0, cykl życia tokenów i cztery podmioty biorące udział w każdej wymianie.

Często zadawane pytania

Czy zwykli użytkownicy mogą zatwierdzać uprawnienia aplikacji w usłudze Microsoft Entra ID?

Nie. Uprawnienia aplikacji działają bez zalogowanego użytkownika i mają zasięg obejmujący całą dzierżawę. Dlatego uprawnienia aplikacji może przyznać wyłącznie administrator posiadający odpowiednie uprawnienia w dzierżawie.

Co się stanie, jeśli użytkownik spróbuje uzyskać dostęp do pliku za pośrednictwem aplikacji z uprawnieniami delegowanymi, do których nie ma uprawnień?

Aplikacja również zostanie zablokowana i nie uzyska dostępu do tego pliku. Uprawnienia delegowane korzystają z tożsamości użytkownika, co oznacza, że aplikacja nigdy nie może przekroczyć osobistych granic dostępu użytkownika.

Jakie jest główne zagrożenie bezpieczeństwa związane z uprawnieniami aplikacji?

Ponieważ uprawnienia aplikacji uruchamiają usługi działające w tle bez nadzoru człowieka, skompromitowane poświadczenia aplikacji mogą dać atakującemu nieograniczony dostęp do skrzynek pocztowych, plików i zasobów całej firmy.

W jaki sposób Microsoft Graph współdziała z tokenami OAuth i uprawnieniami?

Microsoft Graph pełni rolę bramy API dla Microsoft 365. Każde żądanie do Graph musi zawierać token dostępu OAuth, który osadza określone zakresy definiujące uprawnienia delegowane lub uprawnienia aplikacji.

Microsoft Entra ID Microsoft Microsoft 365 Fabric workspace Microsoft Graph Microsoft To Do SharePoint

Related articles

RSS