Microsoft AZ-204: Uwierzytelnianie, autoryzacja i bezpieczeństwo w Azure — Przewodnik do nauki

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Część Microsoft Azure Developer Associate AZ-204 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Uwierzytelnianie i autoryzacja w Azure opierają się na Microsoft Identity Platform, która wystawia tokeny tożsamościom (użytkownikom, aplikacjom, obciążeniom roboczym) i wymusza dostęp do API oraz zasobów. Aplikacje integrują się za pomocą protokołów OAuth 2.0 i OpenID Connect, pozyskują tokeny przy użyciu MSAL i żądają uprawnień zadeklarowanych w rejestracjach aplikacji w Azure AD. Obciążenia robocze działające na platformie Azure mogą całkowicie wyeliminować poświadczenia, korzystając z tożsamości zarządzanych, i polegać na Azure RBAC, aby uzyskać dostęp do usług takich jak Key Vault, Storage i Microsoft Graph. Zarządzanie wpisami tajnymi koncentruje się na usłudze Azure Key Vault, z wyraźnym rozdzieleniem dostępu do płaszczyzny danych magazynu od kontroli na płaszczyźnie zarządzania oraz z silnymi gwarancjami odzyskiwania dzięki usuwaniu nietrwałemu i ochronie przed przeczyszczeniem. W przypadku przechowywania danych, sygnatury dostępu współdzielonego (SAS) zapewniają ograniczony w zakresie i czasie dostęp dla klientów bez ujawniania kluczy konta.

Microsoft Identity Platform, OAuth 2.0, MSAL i rejestracje aplikacji

Platforma Microsoft Identity Platform obsługuje wiele przepływów OAuth 2.0 zoptymalizowanych dla różnych typów aplikacji:

• Przepływ kodu autoryzacji: Standard dla aplikacji internetowych, SPA i aplikacji natywnych. Klienci publiczni muszą używać PKCE do ochrony kodu autoryzacji. Aplikacje przekierowują użytkowników do punktu końcowego autoryzacji, otrzymują kod autoryzacji na URI przekierowania, a następnie wymieniają go w punkcie końcowym tokenu na token dostępu (i opcjonalnie token odświeżania). W przypadku aplikacji SPA, przepływ kodu autoryzacji + PKCE zastępuje przestarzały przepływ niejawny i ogranicza ryzyko wycieku tokenów.
• Przepływ poświadczeń klienta: Używany przez demony i usługi typu serwer-serwer bez udziału użytkownika. Aplikacja żąda tokenów przy użyciu asercji klienta (certyfikatu) lub klucza tajnego klienta. Dostępne są tutaj tylko uprawnienia aplikacji (role aplikacji), a większość z nich wymaga zgody administratora. Ten przepływ używa zakresu /.default do żądania zestawu statycznie skonfigurowanych uprawnień aplikacji.
• Przepływ kodu urządzenia: Zaprojektowany dla urządzeń lub środowisk bez wbudowanej przeglądarki. Aplikacja uzyskuje kod użytkownika i adres URL weryfikacji z platformy tożsamości, użytkownik uwierzytelnia się na osobnym urządzeniu, a aplikacja cyklicznie odpytuje punkt końcowy tokenu. Stosowane są uprawnienia delegowane, ponieważ użytkownik się loguje.
• Przepływ niejawnego udzielenia uprawnień: Historycznie używany przez aplikacje SPA do otrzymywania tokenów bezpośrednio z punktu końcowego autoryzacji. Obecnie jest odradzany na rzecz przepływu kodu autoryzacji z PKCE. Jeśli jest używany, URI przekierowania jest nadal wymagany podczas rejestracji aplikacji.

MSAL (Microsoft Authentication Library) zapewnia spójne pozyskiwanie tokenów na różnych językach i platformach. Publiczne aplikacje klienckie (desktopowe, mobilne, SPA) używają

undefined

i

undefined

do uzyskiwania i buforowania tokenów; aplikacje natywne będą również używać

undefined

dla przepływu kodu urządzenia oraz

undefined

do wymiany kodu autoryzacji w kontekstach klienta poufnego. Klienci poufni (aplikacje internetowe/API/demony) pozyskują tokeny za pomocą

undefined

, gdy używają poświadczeń klienta, oraz

undefined

dla scenariuszy OBO, w których API wywołuje podrzędne API z delegowanym kontekstem użytkownika.

Buforowanie tokenów jest integralną częścią MSAL: przechowuje ono tokeny dostępu i odświeżania, kluczowane według konta, klienta i zakresu, umożliwiając

undefined

unikanie niepotrzebnych interaktywnych monitów. Aplikacje internetowe i API działające w wielu instancjach muszą utrwalać i chronić pamięć podręczną tokenów przy użyciu współdzielonego, zaszyfrowanego magazynu (np. rozproszonej pamięci podręcznej z odpowiednim szyfrowaniem w spoczynku i w tranzycie). Haki serializacji pamięci podręcznej w MSAL umożliwiają bezpieczne utrwalanie. Zakresy identyfikują uprawnienia, o które prosi aplikacja. W przypadku uprawnień delegowanych, żądaj minimalnych, specyficznych dla zasobu zakresów (np.

undefined

). W przypadku poświadczeń klienta, żądaj opartego na zasobie zakresu /.default, który mapuje się na uprawnienia aplikacji statycznie przyznane aplikacji (np.

undefined

). Używaj zgody przyrostowej, aby żądać zakresów progresywnie i zmniejszyć niedogodności dla użytkownika.

Rejestracje aplikacji w Azure AD definiują tożsamość aplikacji, poświadczenia, URI przekierowania i uprawnienia. Uprawnienia delegowane wymagają zalogowanego użytkownika i często użytkownicy mogą sami wyrazić na nie zgodę dla swoich danych; uprawnienia aplikacji są przyznawane samej aplikacji i prawie zawsze wymagają zgody administratora, ponieważ mają zastosowanie w całej dzierżawie lub w szerokim zakresie. Aplikacje, które udostępniają API, deklarują zakresy (dla uprawnień delegowanych) i role aplikacji (dla uprawnień aplikacji) w sekcji „Udostępnij interfejs API”. Skonfiguruj dostęp jednodostępny lub wielodostępny w zależności od granic zaufania i używaj certyfikatów zamiast kluczy tajnych klienta dla silniejszych poświadczeń i łatwiejszej rotacji.

Microsoft Graph używa tego samego mechanizmu wystawiania tokenów. Uwierzytelniaj się za pomocą MSAL, celując w zasób Graph i żądając zakresów o najniższych uprawnieniach. Typowe punkty końcowe obejmują:

undefined

dla profilu użytkownika z tokenami delegowanymi (np.

undefined

)

undefined

i

undefined

dla obiektów katalogu (wymaga odpowiednich uprawnień delegowanych lub aplikacji, takich jak

undefined

lub

undefined

)

undefined

lub

undefined

dla operacji na SharePoint/OneDrive Podczas korzystania z poświadczeń klienta, żądaj zakresu /.default i upewnij się, że istnieje zgoda administratora na wymagane uprawnienia aplikacji. Wybierz odpowiedni urząd (ang. authority) (specyficzny dla dzierżawy w porównaniu z common/organizations), aby kontrolować, gdzie użytkownicy mogą się logować i gdzie mogą być tworzone tokeny.

Tożsamości zarządzane i bezpieczny dostęp do zasobów Azure oraz odwołania do Key Vault

Tożsamości zarządzane dla zasobów Azure eliminują potrzebę używania wpisów tajnych, pozwalając Azure na zarządzanie poświadczeniami jednostek usługi (service principal). Tożsamości zarządzane przypisane przez system są powiązane 1:1 z zasobem (App Service, Function App, VM, VMSS, Logic App itp.) i dzielą jego cykl życia; gdy zasób jest usuwany, tożsamość również jest usuwana. Tożsamości zarządzane przypisane przez użytkownika są tworzone jako samodzielne zasoby Azure, które mogą być dołączone do wielu zasobów obliczeniowych i istnieją niezależnie od cyklu życia dowolnego obciążenia. Ten model wspiera ponowne wykorzystanie tożsamości i separację obowiązków.

Aby uzyskać dostęp do zasobów Azure za pomocą tożsamości zarządzanej, należy przyznać jej odpowiednią rolę Azure RBAC w prawidłowym zakresie:

• Dla płaszczyzny danych Azure Storage z Azure AD, przypisz role takie jak Storage Blob Data Reader/Contributor w zakresie konta magazynu, kontenera lub grupy zasobów/subskrypcji.
• Dla Key Vault (model płaszczyzny danych z RBAC), przypisz role takie jak Key Vault Secrets User lub Key Vault Crypto Officer.
• Dla Microsoft Graph poprzez uprawnienia aplikacji, tożsamości zarządzane mogą wywoływać podrzędne API dopiero po skojarzeniu z rejestracją aplikacji. Użyj federacji tożsamości obciążeń (workload identity federation) lub skonfiguruj uprawnienia aplikacji korporacyjnej i zgodę administratora w zależności od potrzeb.

W czasie wykonywania, użyj Instance Metadata Service (IMDS) na maszynach wirtualnych lub zarządzanego przez App Service punktu końcowego, aby uzyskać tokeny; pakiety SDK, takie jak DefaultAzureCredential z biblioteki Azure Identity, automatycznie użyją punktu końcowego tożsamości zarządzanej, gdy jest on dostępny. Eliminuje to potrzebę przechowywania wpisów tajnych i wspiera rotację zarządzaną przez platformę.

Odwołania do Key Vault w App Service i Azure Functions pozwalają na bezpieczne pobieranie wpisów tajnych do ustawień aplikacji bez zmian w kodzie. W wartości ustawienia aplikacji użyj składni odwołania

undefined

. Platforma rozwiązuje to odwołanie przy użyciu tożsamości zarządzanej aplikacji podczas uruchamiania i okresowo je odświeża. Upewnij się, że tożsamość zarządzana ma uprawnienie Get do wpisów tajnych poprzez zasady dostępu Key Vault lub rolę Key Vault Secrets User, gdy używany jest model płaszczyzny danych z RBAC. Odwołania do Key Vault są idealne dla wartości konfiguracyjnych, które nigdy nie powinny być przechowywane w postaci zwykłego tekstu w magazynie konfiguracji aplikacji i usuwają logikę obsługi wpisów tajnych z kodu aplikacji.

Azure Key Vault: Wpisy tajne, klucze, certyfikaty i kontrola dostępu

Azure Key Vault przechowuje trzy typy obiektów:

• Wpisy tajne (Secrets): Nieprzezroczyste ciągi znaków, takie jak hasła, parametry połączenia czy klucze API. Są wersjonowane; klienci zazwyczaj wykonują operacje Get i Set.
• Klucze (Keys): Klucze kryptograficzne (RSA, EC) używane do operacji podpisywania/weryfikacji, szyfrowania/deszyfrowania oraz zawijania/odwijania (wrap/unwrap). Materiał klucza jest chroniony przez usługę opartą na HSM; klienci wywołują operacje kryptograficzne przez usługę, zamiast eksportować materiał klucza prywatnego.
• Certyfikaty (Certificates): Obiekty X.509 z zarządzaniem cyklem życia, opcjonalnie zintegrowane z partnerskimi urzędami certyfikacji (CA). Certyfikaty są materializowane jako certyfikat plus odpowiadający mu wpis tajny (PFX) i, opcjonalnie, zarządzany klucz.

Usuwanie nietrwałe (soft delete) jest domyślnie włączone, zachowując usunięte obiekty przez określony okres przechowywania. Włącz ochronę przed przeczyszczeniem (purge protection), aby zapobiec nieodwracalnemu usunięciu w okresie przechowywania i wymusić gwarancje odzyskiwania (często jest to wymóg 90-dniowego przechowywania). Połącz usuwanie nietrwałe i ochronę przed przeczyszczeniem, aby spełnić rygorystyczne zasady odzyskiwania. Dodatkowo, zabezpiecz dostęp sieciowy do magazynu za pomocą prywatnych punktów końcowych (private endpoints) i wyłącz dostęp z sieci publicznej, jeśli to możliwe.

Kontrola dostępu może używać starszych zasad dostępu do magazynu (vault access policies) lub Azure RBAC dla płaszczyzny danych. Zasady dostępu są konfigurowane dla każdego magazynu i jawnie przyznają uprawnienia (Get, List, Set, Sign, Wrap) jednostkom (principals); nie są dziedziczone i na dużą skalę mogą stać się uciążliwe operacyjnie. Model płaszczyzny danych z RBAC wykorzystuje role Azure (np. Key Vault Administrator, Key Vault Secrets Officer, Key Vault Secrets User, Key Vault Crypto Officer) i wspiera definiowanie zakresu na poziomie subskrypcji, grupy zasobów lub magazynu, z audytem zintegrowanym z Azure RBAC. Wybierz jeden model; jeśli RBAC jest włączony dla płaszczyzny danych, zasady dostępu są ignorowane. Operacje na płaszczyźnie zarządzania (tworzenie/aktualizowanie magazynu) zawsze używają Azure RBAC.

Integruj Key Vault z aplikacjami używając pakietów Azure SDK (np. SecretClient, KeyClient, CertificateClient) i DefaultAzureCredential. Preferuj tożsamości zarządzane do uwierzytelniania, unikaj osadzania poświadczeń w kodzie i implementuj zasady ponawiania prób i ograniczania przepustowości (retry and throttling) podczas wywoływania API magazynu.

Sygnatury dostępu współdzielonego (SAS) i przechowywane zasady dostępu w Azure Storage

Sygnatury dostępu współdzielonego (SAS) delegują szczegółowy, ograniczony czasowo dostęp do Azure Storage bez ujawniania kluczy konta:

• SAS delegowania użytkownika (tylko Blob): Oparty na Azure AD. Aplikacja uzyskuje klucz delegowania użytkownika z usługi Blob przy użyciu poświadczeń Azure AD, a następnie tworzy tokeny SAS dla klientów. Jest to najbezpieczniejsze podejście w scenariuszach zorientowanych na użytkownika, ponieważ unika używania kluczy konta i jest zgodne z autoryzacją opartą na rolach.
• SAS usługi: Ograniczony do określonego zasobu (blob, kontener, komunikat w kolejce, encja w tabeli, plik). Podpisywany kluczem konta. Obsługuje uprawnienia takie jak odczyt, zapis, dodawanie, tworzenie, usuwanie, listowanie, ustawianie niezmienności i tagi, w zależności od usługi.
• SAS konta: Najszerszy zakres obejmujący wiele usług (Blob, Queue, Table, File) i typów zasobów. Należy używać oszczędnie ze względu na duży promień rażenia.

Tokeny SAS zawierają ograniczenia, takie jak czas wygaśnięcia (se), czas rozpoczęcia (st), uprawnienia (sp), zakresy adresów IP (sip), dozwolone protokoły (spr), podpisany zasób (sr) oraz, gdy są powiązane z przechowywaną zasadą dostępu, podpisany identyfikator (si). Stosuj zasadę najniższych uprawnień, nadając tylko niezbędne uprawnienia, utrzymując krótkie czasy wygaśnięcia i wymuszając HTTPS (spr=https). Preferuj SAS delegowania użytkownika, jeśli to możliwe; w przeciwnym razie używaj SAS usługi z przechowywaną zasadą dostępu w celu umożliwienia odwołania.

Przechowywane zasady dostępu istnieją na poziomie kontenerów, udziałów plików, kolejek lub tabel i definiują zestaw ograniczeń wielokrotnego użytku (uprawnienia, czas rozpoczęcia, czas wygaśnięcia). Tworząc SAS, odwołuj się do zasady za pomocą jej identyfikatora. Umożliwia to centralne odwołanie lub zacieśnienie zakresu bez konieczności ponownego wydawania wszystkich tokenów SAS; aktualizacja lub usunięcie zasady natychmiast wpływa na wszystkie powiązane z nią tokeny SAS. Regularnie rotuj klucze konta, jeśli używane są SAS usługi lub konta, i monitoruj użycie za pomocą ustawień diagnostycznych i logów Azure Monitor.

Praktyczny scenariusz problemowy

Firma Adobe wdraża wielodostępny (multi-tenant) portal do przetwarzania multimediów na platformie Azure. Klienci logują się za pomocą własnych dzierżaw Microsoft Entra ID, przesyłają duże pliki multimedialne bezpośrednio do Blob storage i śledzą status przetwarzania. Rozwiązanie musi unikać przechowywania wpisów tajnych, centralizować uprawnienia i zapewniać możliwość odzyskania wpisów tajnych przez co najmniej 90 dni.

1. Zarejestruj aplikacje w Microsoft Entra ID:

   • Utwórz aplikację SPA dla interfejsu użytkownika portalu i klienta poufnego dla backendowego API. Upublicznij zakresy API dla dostępu delegowanego i zdefiniuj role aplikacji dla zadań w tle. Skonfiguruj SPA do używania przepływu z kodem autoryzacji + PKCE z dokładnymi identyfikatorami URI przekierowania. To dopasowuje każdego klienta do odpowiedniego przepływu OAuth i wymusza granice zgody zgodnie z zasadą najniższych uprawnień.

2. Zaimplementuj MSAL w SPA i backendzie:

   • SPA pozyskuje tokeny dla backendowego API za pomocą AcquireTokenInteractive/AcquireTokenSilent z przyrostową zgodą (incremental consent). Backend używa AcquireTokenOnBehalfOf do wywoływania Microsoft Graph w celu odczytania podstawowego profilu zalogowanego użytkownika. Zachowuje to kontekst użytkownika w całym rozwiązaniu (end-to-end) i minimalizuje liczbę monitów dzięki buforowaniu tokenów.

3. Włącz tożsamości zarządzane przypisane przez system w App Service (API) i Azure Functions (procesory multimediów):

   • Przypisz role Storage Blob Data Contributor do kontenera multimediów i Key Vault Secrets User do magazynu kluczy. Tożsamości zarządzane eliminują rozprzestrzenianie się wpisów tajnych i pozwalają platformie na automatyczną rotację poświadczeń, jednocześnie umożliwiając bezpieczny dostęp do Storage i Key Vault za pośrednictwem Azure RBAC.

4. Skonfiguruj Azure Key Vault z RBAC na płaszczyźnie danych, usuwaniem nietrwałym (soft delete) i ochroną przed przeczyszczeniem (purge protection):

   • Przechowuj certyfikaty podpisywania dla asercji backendu, klucze API firm trzecich i wszelkie wpisy tajne połączeń, których nie można zastąpić AAD. Wymuś ochronę przed przeczyszczeniem oraz usuwanie nietrwałe, aby zagwarantować możliwość odzyskania przez 90 dni. RBAC upraszcza audyt i skaluje się w różnych środowiskach w porównaniu do zasad dostępu per magazyn.

5. Użyj odwołań do Key Vault w konfiguracji:

   • Odwołuj się do wpisów tajnych w ustawieniach aplikacji App Service i Functions za pomocą @Microsoft.KeyVault(SecretUri=...). Platforma rozwiązuje i odświeża wartości przy użyciu tożsamości zarządzanej, eliminując zmiany w kodzie i zapobiegając przechowywaniu wpisów tajnych w konfiguracji w postaci zwykłego tekstu.

6. Deleguj bezpośrednie przesyłanie z przeglądarki za pomocą SAS:

   • Backend wydaje tokeny SAS delegowania użytkownika w celu zapewnienia krótkotrwałego dostępu tylko do zapisu do określonej ścieżki bloba, ograniczonego przez adres IP i protokół HTTPS. Dla operacyjnych narzędzi wsadowych utwórz SAS usługi powiązany z przechowywaną zasadą dostępu na kontenerze, aby tokeny mogły być centralnie odwoływane przez aktualizację lub usunięcie zasady. Umożliwia to wysokoprzepustowe przesyłanie plików przez klienta bez ujawniania kluczy konta i wspiera awaryjne odwoływanie dostępu.

7. Zintegruj Microsoft Graph w minimalnym zakresie:

   • Zażądaj uprawnienia https://graph.microsoft.com/User.Read w SPA do wyświetlania profilu i użyj https://graph.microsoft.com/.default w backendzie, jeśli wymagane są jakiekolwiek uprawnienia aplikacji (za uprzednią zgodą administratora). Użycie /.default zapewnia, że backend honoruje centralnie przyznane uprawnienia aplikacji i unika żądania nadmiarowych zakresów w czasie działania.

Ten projekt wykorzystuje przepływ z kodem autoryzacji + PKCE do zabezpieczenia SPA, przepływ OBO do zachowania kontekstu użytkownika, tożsamości zarządzane i RBAC do eliminacji wpisów tajnych, Key Vault z silnymi gwarancjami odzyskiwania, odwołania do Key Vault dla higieny konfiguracyjnej, Graph z zakresami o najniższych uprawnieniach oraz SAS z przechowywanymi zasadami dostępu dla bezpiecznego, odwoływalnego przesyłania plików przez klienta.

← Rozwiązania kontenerowe Azure · Wszystkie domeny · Azure API Management →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →

Przeglądaj Microsoft →