Uprawnienia delegowane a uprawnienia aplikacji

By Mirko Peters · 2026-04-26 · Updated 2026-07-18

Porównaj uprawnienia delegowane i uprawnienia aplikacji w Microsoft Entra ID i wybierz właściwy model dostępu do bezpiecznych interfejsów API, automatyzacji i tworzenia aplikacji.

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

Gdy pracujesz z Microsoft Entra ID, ustalenie, kto może co zrobić i w jakich okolicznościach, to więcej niż szczegół techniczny. To fundament bezpiecznego tworzenia aplikacji, automatyzacji i ogólnego zarządzania tożsamością w chmurze Microsoft. Ogromna różnica polega na tym, czy pozwolisz użytkownikom przyznać aplikacji dokładnie tyle dostępu, ile potrzebuje, aby działała w ich imieniu (uprawnienia delegowane), czy dasz aplikacji klucze do samodzielnego działania (uprawnienia aplikacji).

Jeśli popełnisz błąd, możesz otworzyć drzwi do niepożądanego ujawnienia danych, problemów ze zgodnością z przepisami, a nawet incydentów bezpieczeństwa. Jeśli wybierzesz dobrze, zyskasz sprawniejszą automatyzację, czytelniejsze zarządzanie i zadowolonych audytorów. Ten przewodnik przedstawia pełny obraz: podstawy tych typów uprawnień, sposób ich działania w praktyce oraz wszystkie aspekty bezpieczeństwa, zarządzania i eksploatacji, które pomogą Ci podjąć najlepszą decyzję dla Twojego środowiska. Ustawmy uprawnienia na właściwym miejscu, bo wielki dostęp wiąże się z poważną odpowiedzialnością.

Wprowadzenie i tło modeli uprawnień w tożsamości Microsoft

Uprawnienia w Microsoft Entra ID to nie tylko pola do zaznaczenia; to fundamentalna struktura wpleciona w sposób, w jaki aplikacje i użytkownicy współpracują w usługach Microsoft 365, Azure i nie tylko. Gdy Microsoft przeniósł tożsamość do chmury, potrzebował sposobu, aby usługi i narzędzia zewnętrznych dostawców mogły bezpiecznie współdziałać, bez przyznawania wszystkim i wszystkiego pełnego dostępu. Tu właśnie pojawiają się uprawnienia delegowane i uprawnienia aplikacji.

Te modele umożliwiają precyzyjne zarządzanie tym, kto ma dostęp do czego, i wyznaczają jasne granice między tym, co może zatwierdzić pojedynczy użytkownik, a tym, na co może pozwolić wyłącznie administrator. Są efektem lat nauki (czasem na własnych błędach) na podstawie klasycznych kont usługowych w AD i topornego, wszystko-albo-nic modelu dostępu. Zrozumienie tych modeli to nie tylko dobra higiena, ale warunek spełnienia wymogów zgodności, egzekwowania modelu Zero Trust i uniknięcia sytuacji, w której codzienne działanie zatrzymuje się z powodu błędnej konfiguracji zabezpieczeń.

Uprawnienia aplikacji a uprawnienia delegowane: podstawowe pojęcia i scenariusze z życia wzięte

Wyjaśnijmy różnicę między uprawnieniami delegowanymi a uprawnieniami aplikacji prostym językiem. Uprawnienia delegowane można traktować jak pomocnika aplikacji: aplikacja uzyskuje dostęp tylko wtedy, gdy zalogowany jest określony użytkownik, i jest ograniczona do tego, co ten użytkownik sam może zrobić. Uprawnienia aplikacji natomiast pozwalają aplikacji działać samodzielnie, jak menedżer bez nadzoru, który ma własny zestaw kluczy. Nie potrzebuje do tego żadnego użytkownika.

Przy uprawnieniach delegowanych uwierzytelnianie zawsze obejmuje użytkownika. Oznacza to, że gdy ktoś się loguje, na przykład do aplikacji, która potrzebuje dostępu do jego poczty lub kalendarza, przyznaje aplikacji tymczasowe okno do działania z jego uprawnieniami. Gdy użytkownik się wyloguje, to okno się zamyka. To idealne rozwiązanie dla aplikacji, które wykonują pracę na żądanie użytkownika, takich jak interfejsy webowe, boty w usłudze Microsoft Teams czy mobilne aplikacje produktywności.

Przy uprawnieniach aplikacji sama aplikacja uwierzytelnia się jako własna tożsamość (jednostka usługi) i otrzymuje własny token. Na tym opierają się automatyzacja i zadania w tle, na przykład integracja systemowa, która nocą synchronizuje dane między usługą SharePoint a Twoim systemem CRM. Nie jest wymagana interakcja użytkownika; aplikacja wykonuje zadania zgodnie z własnym harmonogramem i na własnym poziomie dostępu, z zastrzeżeniem tego, co zatwierdzi administrator.

Wyobraź sobie, że musisz zautomatyzować aprowizację użytkowników: usługa działająca w tle po cichu aktualizuje konta użytkowników każdej nocy. Uprawnienia delegowane nie mają tu zastosowania, bo nikt nie siedzi i nie zatwierdza dostępu. Jednak gdy Twoje rozwiązanie ma oferować spersonalizowane funkcje, gdy użytkownik jest aktywny, na przykład aplikację do podpisywania dokumentów połączoną z usługą OneDrive, wtedy sprawdzają się uprawnienia delegowane.

W rzeczywistych scenariuszach często potrzebne jest połączenie obu modeli, dlatego znajomość tego, który model pasuje do Twojego przypadku, ma kluczowe znaczenie dla doświadczenia użytkownika, zarządzania i bezpieczeństwa. Nie chcesz rozdawać więcej kluczy, niż trzeba, ale nie chcesz też, aby Twoja usługa została zablokowana o 3:00 w nocy, bo nikogo nie ma, kto mógłby się zalogować.

Wewnątrz uprawnień delegowanych Microsoft Entra: przepływ uwierzytelniania i ograniczenia

Uprawnienia delegowane w Microsoft Entra ID prowadzą przez klasyczny, sterowany przez użytkownika przepływ uwierzytelniania. Zaczyna się, gdy użytkownik loguje się do Twojej aplikacji, używając swoich poświadczeń Microsoft. W tym momencie aplikacja żąda określonych uprawnień – czyli zakresów – pokazując użytkownikowi (a czasem także administratorowi), do jakich danych lub działań chce uzyskać dostęp.

Jeśli żądane uprawnienia wymagają wyłącznie zgody użytkownika, zatwierdza je on od razu na ekranie zgody. Przy bardziej wrażliwych uprawnieniach (na przykład odczyt skrzynek pocztowych wszystkich użytkowników w organizacji) wymagana jest zgoda administratora. Po udzieleniu zgody aplikacja otrzymuje token dostępu powiązany bezpośrednio z tożsamością użytkownika i jego przypisanymi rolami.

Ten token dostępu pozwala aplikacji wywoływać interfejsy API Microsoft Graph lub Microsoft 365, ale zawsze działa ona z uprawnieniami użytkownika. Jeśli więc użytkownik jest zwykłym pracownikiem, aplikacja nie może nagle uzyskać możliwości administracyjnych. Gdy tylko użytkownik się wyloguje, dostęp aplikacji wygasa – co ogranicza zasięg ewentualnych szkód.

Istnieje jednak ograniczenie: uprawnienia delegowane nie sprawdzają się w scenariuszach bez nadzoru. Jeśli uruchamiasz proces w tle, zadanie cron lub integrację usługową, która nie powinna zależeć od tego, czy ktoś aktywnie się loguje, uprawnienia delegowane po prostu nie wystarczą. Wiążą wszystko z obecnością użytkownika, więc zadania wsparcia, automatyzacje i procesy nocne napotykają ścianę.

Warto też spojrzeć na aspekt bezpieczeństwa. Jeśli użytkownik z szerokim dostępem zostanie oszukany i wyrazi zgodę, aplikacja może nadużyć tych uprawnień – to kluczowy wektor ataków typu consent phishing. Dlatego potrzebna jest ścisła kontrola nad tym, kto może przyznawać jakie uprawnienia, oraz solidne szkolenia uświadamiające, co naprawdę oznaczają ekrany zgody.

Nadmierne uprawnienia aplikacji i bezpieczeństwo tokenów w Microsoft Entra ID

Jeśli chodzi o uprawnienia, więcej nie zawsze znaczy lepiej. Nadmierne przydzielanie uprawnień – czyli nadawanie zbędnych lub zbyt szerokich przywilejów, szczególnie w przypadku uprawnień aplikacyjnych – może otworzyć drzwi do wycieków wrażliwych danych i poważnych incydentów bezpieczeństwa. Załóżmy, że dajesz aplikacji dostęp do odczytu i zapisu wszystkich skrzynek pocztowych w firmie, a ona potrzebuje tylko odczytu wydarzeń z kalendarza. Właśnie znacznie powiększyłeś powierzchnię ataku.

To zagrożenie nie jest wyłącznie teoretyczne. Atakujący wykorzystują nadużycia zgody OAuth, aby obejść nawet uwierzytelnianie wieloskładnikowe. Biorą na cel użytkowników lub administratorów sprytnie spreparowanymi żądaniami zgody, nakłaniając ich do zatwierdzenia ryzykownych uprawnień. Po uzyskaniu dostępu złośliwe aplikacje często zachowują go nawet po zmianie haseł lub wymuszeniu MFA. Chwyt atakującego się utrzymuje, przez co tradycyjne mechanizmy obrony są nieskuteczne. Jeśli chcesz zobaczyć praktyczne omówienie, sprawdź ten materiał o tym, jak atakujący nadużywają zgody OAuth w Entra ID, oraz najlepsze sposoby na jej zabezpieczenie.

Rozmowa nie kończy się na nadmiernych uprawnieniach. Tokeny i poświadczenia – nawet sekrety klienta i certyfikaty – mogą stać się łakomym kąskiem dla atakujących, jeśli nie są odpowiednio zabezpieczone. Wyciek sekretu klienta z rejestracji aplikacji działającej bez użytkownika wystarcza atakującemu, by podszyć się pod Twoją usługę. Dlatego higiena poświadczeń jest niezbędna: w miarę możliwości używaj tożsamości zarządzanych, regularnie rotuj sekrety i nigdy nie przechowuj poświadczeń klienta w kodzie ani w niezabezpieczonych plikach. W środowiskach opierających się na dostępie nieludzkim rozważ Microsoft Entra Workload Identities, które umożliwiają dostęp bez sekretów, podlegający audytowi, i eliminują problemy związane z przestarzałymi kontami usługowymi. Bardziej szczegółowe omówienie znajdziesz tutaj: dlaczego tożsamości obciążeń są koniecznością w modelu Zero Trust.

Na koniec monitorowanie jest absolutnie konieczne. Regularnie przeglądaj dzienniki logowania i przyznane uprawnienia OAuth, ustaw alerty dotyczące podejrzanych zgód lub użycia tokenów i stale miej się na baczności wobec ataków consent phishing oraz kradzieży tokenów. Wnioski z rzeczywistych naruszeń (jak ten łańcuch ataku w Microsoft 365) pokazują, że atakujący wykorzystują słabe zarządzanie – im większa widoczność, tym lepiej. Chroń klucze, zaostrzaj uprawnienia i dbaj o to, by Twoje aplikacje były uczciwe.

Kontrole i najlepsze praktyki zarządzania uprawnieniami delegowanymi i aplikacyjnymi

• Wdróż wbudowane kontrolki Entra do zarządzania uprawnieniamiWykorzystaj wbudowane w Microsoft Entra przepływy zgody, procesy zatwierdzania przez administratora oraz szczegółowe zasady, aby ograniczyć, którzy użytkownicy lub grupy mogą przyznawać uprawnienia. Użyj zasad zgody administratora, aby wysokiego ryzyka zakresy uzyskiwały wyłącznie sprawdzone aplikacje.
• Egzekwuj zasadę najmniejszych uprawnieńPrzyznawaj aplikacjom wyłącznie minimalny zestaw uprawnień niezbędnych do ich działania. Sprawdź każde uprawnienie żądane podczas rejestracji aplikacji i usuń wszystko, co zbędne. Zasada najmniejszych uprawnień to najskuteczniejsza ochrona przed nadużyciami i nadmiernym dostępem.
• Planuj regularne przeglądy uprawnień i audytySkonfiguruj cykliczne przeglądy dostępu, korzystając z pulpitów uprawnień i zgód w Entra, aby wykrywać nieużywane lub ryzykowne uprawnienia i je cofać. Jeśli to możliwe, zautomatyzuj te kontrole, aby zapewnić skalowalne zarządzanie – zgodnie z zaleceniami zawartymi w zaawansowanych przewodnikach dotyczących governance, takich jak ta strategia dla Microsoft Purview.
• Monitoruj zmiany uprawnień i generuj alertyUstanów monitoring i alerty, które wychwycą nowe przyznania OAuth, nagłe wzrosty wykorzystania uprawnień aplikacji lub nieoczekiwane integracje administracyjne. Proaktywne raportowanie daje czas na reakcję, zanim problemy z bezpieczeństwem się nasilą.
• Zabezpieczaj przechowywanie tokenów i poświadczeńPrzechowuj sekrety klienta i tokeny w bezpiecznych magazynach, takich jak Azure Key Vault. Regularnie rotuj poświadczenia, stosuj certyfikaty zamiast współdzielonych sekretów i preferuj tożsamości obciążeń (workload identities) przy integracjach wymagających dostępu nieludzkiego, ponieważ zapewniają lepsze zarządzanie cyklem życia i możliwość audytu.
• Stosuj zaawansowane zarządzanie i automatyzację zasadWykorzystaj narzędzia takie jak Microsoft Purview i Azure Policy, aby egzekwować kontrole obejmujące całą dzierżawę, ograniczać ryzyko dzięki Data Loss Prevention i projektować rozwiązania z myślą o ciągłej zgodności. Praktyczne spojrzenie na wykorzystanie zasad do zarządzania już na etapie projektowania znajdziesz w artykule o strategii zarządzania przedsiębiorstwem w Azure.

Stosując te kroki i korzystając z ekosystemu narzędzi Microsoft do zarządzania, pomożesz organizacji wychwytywać ryzyko związane z uprawnieniami, zanim przerodzi się ono w problemy. Regularnie edukuj użytkowników w zakresie bezpiecznych praktyk udzielania zgód, automatyzuj wszędzie, gdzie to możliwe, i pamiętaj – zarządzanie uprawnieniami nigdy nie jest jednorazowym zadaniem. Zachowuj czujność, stale doskonal zasady, a środowisko Entra ID pozostanie w dobrej kondycji.

Warto także posłuchać

Jeśli zgłębiasz temat uprawnień delegowanych i aplikacyjnych w Entra ID, te odcinki dostarczą praktycznego kontekstu dotyczącego bezpiecznego wdrażania Microsoft 365, ochrony danych, zarządzania i zarządzania ryzykiem AI.

• Microsoft Purview – Simply Explained — Zobacz, jak klasyfikacja, przechowywanie, zgodność i ochrona łączą się w jednym modelu zarządzania danymi Microsoft.
• Microsoft Defender XDR – Simply Explained — Połącz kontrolki ochrony danych z wykrywaniem, badaniem i reagowaniem.
• Conditional Access – Simply Explained — Dowiedz się, jak sygnały tożsamości i ryzyka dodają kontekst do decyzji o dostępie.
• Microsoft AI Agent Harness – Simply Explained — Poznaj kontrolki, które sprawiają, że automatyzacja AI jest bardziej niezawodna, obserwowalna i bezpieczna.

Te odcinki pomogą przełożyć koncepcje z artykułu na decyzje projektowe i wdrożeniowe.