Microsoft AZ-500: Zarządzanie tożsamością i dostępem — Przewodnik do nauki

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

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

Przegląd

Zarządzanie tożsamością i dostępem (IAM) w Microsoft Azure koncentruje się na usłudze Microsoft Entra ID (wcześniej Azure AD). Określa ona, kto może uzyskać dostęp do jakich zasobów, na jakich warunkach i z jakimi uprawnieniami. Efektywna architektura IAM minimalizuje stałe uprawnienia, wymusza dostęp warunkowy i oparty na ryzyku oraz wdraża nowoczesne uwierzytelnianie zarówno dla ludzi, jak i dla obciążeń, jednocześnie wspierając scenariusze współpracy hybrydowej i zewnętrznej.

Konstrukcje tożsamości i zakresy w Microsoft Entra

Dzierżawy, użytkownicy i grupy
- Dzierżawa reprezentuje granicę tożsamości i strukturę zaufania Twojej organizacji. Użytkownicy mogą mieć konta członkowskie lub gościnne (B2B). Używaj grup zabezpieczeń do autoryzacji, a grup Microsoft 365 do funkcji współpracy; preferuj grupy dynamiczne, aby ograniczyć ręczne zarządzanie członkostwem.
Jednostki administracyjne (AU)
- AU pozwalają delegować role katalogowe na podzbiór użytkowników/urządzeń (np. regionalny helpdesk może zarządzać tylko użytkownikami z Europy). Wspiera to zasadę najniższych uprawnień w zadaniach katalogowych.
Role katalogowe i zakresy przypisania ról
- Role katalogowe (np. Global Administrator, User Administrator) mają zastosowanie do zasobów Microsoft Entra. Jeśli to możliwe, ograniczaj zakres ról katalogowych do poziomu AU, aby zmniejszyć promień rażenia. Rola Global Administrator jest wymagana do początkowej konfiguracji Privileged Identity Management (PIM).
Zakresy kontroli dostępu opartej na rolach na platformie Azure (Azure RBAC)
- Azure RBAC zarządza dostępem do zasobów Azure. Przypisuj role na poziomie grupy zarządzania, subskrypcji, grupy zasobów lub pojedynczego zasobu. Dziedziczenie odbywa się w dół; zawsze wybieraj najwęższy praktyczny zakres, aby ograniczyć nadmierne uprawnienia.
Uzasadnienie operacyjne
- Oddzielaj role katalogowe (Entra) od Azure RBAC (autoryzacja zasobów). Używaj AU i wąskich zakresów RBAC, aby ograniczyć zasięg administracyjny, zmniejszyć możliwości ruchu bocznego i uprościć przeglądy dostępu.

Kontrola dostępu z Azure RBAC i zasadą najniższych uprawnień

Role wbudowane i zasada najniższych uprawnień
- Preferuj najbardziej specyficzną rolę wbudowaną, która pasuje do zadania. Przykład: nadaj dostęp tylko do pobierania (pull) obrazów kontenerów za pomocą roli AcrPull, a dostęp do przesyłania (push) za pomocą AcrPush, zamiast szerokiej roli Contributor. W przypadku Key Vault, nadawaj kontrolę administracyjną przez RBAC tylko administratorom magazynu, używając szczegółowych zasad dostępu do określonych operacji na obiektach, takich jak zarządzanie certyfikatami.
Dziedziczenie przypisań ról
- Przypisuj role na najniższym możliwym poziomie zakresu. Przypisania na poziomie grupy zarządzania lub subskrypcji są kaskadowane; unikaj szerokich, dziedziczonych uprawnień, chyba że jest to celowe. Gdy potrzebujesz spójnego RBAC w wielu subskrypcjach, wdrażaj spójne przypisania ról za pomocą Azure Blueprints (lub nowoczesnych alternatyw IaC), zamiast ręcznego przypisywania w PIM.
Przypisania odmowy (Deny)
- Przypisania odmowy jawnie blokują działania niezależnie od przypisań zezwalających i są zazwyczaj tworzone przez usługi Azure, takie jak Azure Policy lub Blueprints. Używaj ich do egzekwowania niepodważalnych barier ochronnych (np. uniemożliwiania tworzenia reguł sieci publicznej dla wrażliwych zasobów).
Role niestandardowe
- Gdy role wbudowane są zbyt szerokie, zdefiniuj role niestandardowe zawierające tylko wymagane akcje. Weryfikuj je poprzez testowanie najniższych uprawnień i przeglądy dostępu.

{
  "Name": "Storage Blob Reader (TagsBlocked)",
  "IsCustom": true,
  "Description": "Read blobs; no tag write",
  "Actions": [
    "Microsoft.Storage/storageAccounts/blobServices/containers/read",
    "Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
  ],
  "NotActions": [
    "Microsoft.Resources/tags/write"
  ],
  "AssignableScopes": ["/subscriptions/00000000-0000-0000-0000-000000000000"]
}

Uzasadnienie operacyjne
- Ograniczanie zakresu RBAC i role niestandardowe redukują nadmierne uprawnienia i powierzchnię audytu. Przypisania odmowy kodują „twarde” ograniczenia zgodności, których nie można obejść przez omyłkowo szerokie przypisania „zezwalające”, co poprawia odporność postawy bezpieczeństwa.

Dostęp uprzywilejowany, dostęp warunkowy i ochrona tożsamości

Privileged Identity Management (PIM)
- Uprawnione a aktywne: przypisania uprawnione (eligible) nie dają stałych uprawnień; użytkownicy muszą aktywować je w trybie JIT, aby stały się aktywne. Wymuszaj zatwierdzenie, uzasadnienie i MFA podczas aktywacji; ustawiaj ograniczony czas trwania i wymagaj odwołań do zgłoszeń w celu zapewnienia identyfikowalności. Zacznij od wykrycia ról uprzywilejowanych, aby zrozumieć bieżące ryzyko. Używaj okresowych przeglądów dostępu, idealnie z właścicielami zasobów lub grup jako recenzentami, aby zweryfikować ciągłą potrzebę dostępu.
Dostęp warunkowy (Conditional Access - CA)
- Przypisania dotyczą użytkowników/grup, tożsamości obciążeń, aplikacji w chmurze i akcji. Warunki obejmują ryzyko związane z logowaniem, platformę/stan urządzenia, lokalizacje, aplikacje klienckie oraz filtry dla urządzeń i aplikacji. Kontrole udzielania dostępu mogą wymagać MFA, urządzeń zgodnych lub przyłączonych hybrydowo do Azure AD, zasad ochrony aplikacji lub akceptacji warunków użytkowania. Kontrole sesji ograniczają częstotliwość logowania, sesje trwałe i ograniczenia wymuszane przez aplikację (np. dostęp tylko przez przeglądarkę do SharePoint). Używaj trybu tylko do raportowania, aby bezpiecznie zweryfikować wpływ zasad przed ich wdrożeniem. Utrzymuj wykluczenia dla kont awaryjnych (break-glass) i stosuj wdrożenia etapowe, aby zapobiec zablokowaniu dostępu.
Identity Protection
- Ryzyko użytkownika (User risk) odzwierciedla prawdopodobieństwo, że konto zostało naruszone; ryzyko logowania (sign-in risk) odzwierciedla prawdopodobieństwo, że dana sesja jest ryzykowna. Skonfiguruj zasady, aby wymagać bezpiecznej remediacji:
  - Użytkownicy z poświadczeniami, które wyciekły: traktuj jako wysokie ryzyko użytkownika (High user risk); wymuś reset hasła i zablokuj dostęp do czasu naprawy.
  - Logowania z adresów IP o podejrzanej aktywności: traktuj co najmniej jako średnie ryzyko logowania (Medium sign-in risk); zażądaj weryfikacji MFA lub zablokuj dostęp do wrażliwych aplikacji.
- Zintegruj z CA, aby dostosowywać zaufanie w czasie rzeczywistym. Śledź historię ryzyka i działania naprawcze, aby mierzyć skuteczność.
Uzasadnienie operacyjne
- PIM eliminuje stałe uprawnienia i wymusza silną, audytowalną aktywację. CA i Identity Protection stosują model zero trust — weryfikując każdą próbę dostępu na podstawie użytkownika, urządzenia, sesji i ryzyka — co ogranicza skuteczną kradzież poświadczeń i ponowne odtwarzanie tokenów.

Tożsamości hybrydowe i tożsamości obciążeń

Opcje tożsamości hybrydowej
- Synchronizacja skrótów haseł (PHS): synchronizuje skróty haseł z Entra ID. Prosta i odporna; nie wymusza lokalnych zasad logowania w momencie uwierzytelniania.
- Uwierzytelnianie przekazywane (PTA): weryfikuje hasła względem lokalnych kontrolerów domeny (DC) za pomocą lekkich konektorów; wymusza lokalne zasady haseł i ograniczenia konta w czasie rzeczywistym, bez AD FS.
- Federacja (np. AD FS): przenosi uwierzytelnianie do lokalnego STS. Używaj tylko wtedy, gdy jest to wymagane dla złożonych oświadczeń (claims) lub scenariuszy starszego typu; wprowadza więcej serwerów i narzut operacyjny.
- Bezproblemowe logowanie jednokrotne (Seamless SSO): loguje użytkowników na urządzeniach przyłączonych do domeny wewnątrz sieci korporacyjnej z minimalną liczbą monitów.
- Wybór operacyjny: aby wymusić lokalne zasady haseł i ograniczenia konta przy jednoczesnej minimalizacji liczby serwerów, wdróż PTA i Seamless SSO, a także włącz PHS w celu zapewnienia odporności/przełączania awaryjnego dla scenariuszy niezależnych od PTA. Sama federacja zwiększa złożoność i nie spełnia celu „minimalizacji liczby serwerów”.
Uwierzytelnianie aplikacji w Azure SQL z urządzeń Windows przyłączonych hybrydowo
- Użyj zintegrowanego uwierzytelniania Active Directory, aby zminimalizować liczbę monitów i wykorzystać Kerberos/SSO tam, gdzie to możliwe.
Tożsamości zarządzane i jednostki usługi (service principals)
- Tożsamości zarządzane (przypisane przez system lub przez użytkownika) są pierwszym wyborem dla obciążeń hostowanych w Azure, ponieważ eliminują wpisy tajne (secrets) i automatycznie rotują poświadczenia. Przypisz uprawnienia RBAC o najniższych uprawnieniach (least-privilege) do tożsamości w zakresie zasobu.
- Jednostki usługi (service principals) stoją za rejestracjami aplikacji; używaj poświadczeń certyfikatowych zamiast kluczy tajnych klienta (client secrets) i ustaw najkrótszy możliwy czas życia.
Federacja tożsamości obciążeń
- Użyj federacji OIDC, aby umożliwić zewnętrznym tożsamościom obciążeń (np. GitHub Actions, Kubernetes) uzyskiwanie tokenów dla aplikacji Entra bez przechowywania wpisów tajnych. Zdefiniuj precyzyjnie oświadczenia (claims) dotyczące wystawcy (issuer), podmiotu (subject) i odbiorcy (audience), aby ograniczyć, kto może wymieniać tokeny.

az ad app federated-credential create \
  --id <app-object-id> \
  --parameters '{
    "name":"gh-actions-main",
    "issuer":"https://token.actions.githubusercontent.com",
    "subject":"repo:contoso/api:environment:prod",
    "audiences":["api://AzureADTokenExchange"]
  }'

Dostęp z AKS do ACR
- Nadaj tożsamości zarządzanej klastra AKS uprawnienie AcrPull w docelowym rejestrze, używając przepływu attach-acr, który automatyzuje prawidłowe określanie zakresu i pozwala uniknąć błędnych przypisań.

az aks update -n aks-prod -g rg-aks --attach-acr myRegistry

Uzasadnienie operacyjne
- PTA+PHS+Seamless SSO wymusza lokalne kontrole w czasie rzeczywistym, zachowując jednocześnie odporność chmury. Tożsamości zarządzane i federacja usuwają statyczne wpisy tajne z potoków (pipelines) i środowiska uruchomieniowego, zamykając częste ścieżki kradzieży poświadczeń.

Współpraca zewnętrzna, metody uwierzytelniania i dostęp do aplikacji

Tożsamości zewnętrzne i współpraca B2B
- Używaj kont gości B2B z ustawieniami dostępu między dzierżawami, warunkami użytkowania i zasadami CA skierowanymi do gości. Ogranicz, kto może zapraszać, i preferuj dostęp just-in-time poprzez zarządzanie uprawnieniami.
Zarządzanie uprawnieniami i pakiety dostępu
- Grupuj grupy, aplikacje i witryny SharePoint w pakiety dostępu z zasadami definiującymi, kto może o nie wnioskować (w tym użytkownicy zewnętrzni), przepływy zatwierdzania, czas trwania przypisania i przeglądy dostępu. Do wyboru recenzentów używaj właścicieli grup (Group Owners), aby utrzymać odpowiedzialność biznesową po stronie opiekunów zasobów.
Metody uwierzytelniania i logowanie bezhasłowe
- Standaryzuj na silnych metodach: klucze bezpieczeństwa FIDO2, Windows Hello for Business i logowanie telefoniczne Microsoft Authenticator. Używaj połączonej rejestracji informacji bezpieczeństwa (SSPR + MFA) i wymuszaj zasady rejestracji MFA dla wszystkich użytkowników. Włącz SSPR z zapisem zwrotnym do środowiska lokalnego, jeśli jest to konieczne; wymagaj bezpiecznych metod i ograniczaj je do czynników zarządzanych przez firmę, tam gdzie to możliwe. Wyłącz starsze/podstawowe protokoły uwierzytelniania i blokuj słabe MFA oparte tylko na SMS, gdy ryzyko to uzasadnia.
Microsoft Entra application proxy
- Publikuj lokalne aplikacje internetowe bez otwierania przychodzących portów zapory. Używaj grup konektorów dla wysokiej dostępności (HA), uwierzytelniania wstępnego z Entra ID i nakładaj warstwy CA, zgodności urządzeń i Identity Protection, aby uzyskać zero trust dla starszych aplikacji.
Bezpieczeństwo rejestracji aplikacji
- Wymagaj przepływów zgody administratora; ogranicz, kto może tworzyć aplikacje; klasyfikuj uprawnienia; preferuj uprawnienia aplikacji tylko wtedy, gdy nie jest wymagany kontekst użytkownika, i ograniczaj zakres API do minimum. Wyłącz niejawne nadanie uprawnień (implicit grant), tam gdzie to możliwe, wymagaj przypisania dla aplikacji dla przedsiębiorstw i preferuj certyfikaty zamiast kluczy tajnych z automatyczną rotacją.

az ad app update --id <app-id> --required-resource-access @permissions.json
az ad sp update --id <sp-id> --set appRoleAssignmentRequired=true

Uzasadnienie operacyjne
- Pakiety dostępu i app proxy zapewniają zarządzany i audytowalny dostęp zewnętrzny. Silne, bezhasłowe metody zwiększają odporność na phishing. Ścisła kontrola rejestracji aplikacji zapobiega zbyt szerokim zgodom i zmniejsza ryzyko podszywania się pod aplikację.

Praktyczny scenariusz problemu

Firma Adobe Inc. musi przyznać zewnętrznemu dostawcy tymczasowy dostęp administracyjny do podzbioru zasobów Azure i opublikować dla niego wewnętrzną, starszą aplikację internetową, wymuszając silne uwierzytelnianie i zasadę zero stałych uprawnień.

Określ zakres i model dostępu

Utwórz grupę zasobów rg-vendor-ops i przenieś do niej tylko wymagane zasoby. Przypisz minimalne role Azure RBAC (np. Contributor w rg-vendor-ops; Reader w grupie zasobów diagnostycznych).
Uzasadnienie: Wąskie określenie zakresu zapobiega ruchowi bocznemu. Dziedziczenie ról jest ograniczone do rg-vendor-ops, co ogranicza promień rażenia.

Zarządzaj tożsamością i aktywacją za pomocą PIM

Uczyń administratorów dostawcy uprawnionymi (eligible), a nie stałymi, do wymaganych ról; wymagaj zatwierdzenia, identyfikatora zgłoszenia, MFA przy aktywacji i ogranicz aktywację do 4 godzin. Zacznij od uruchomienia w PIM funkcji „Odnajdź role uprzywilejowane” (Discover privileged roles), aby ustalić bazowy stan istniejących przypisań.
Uzasadnienie: Przypisania uprawniające eliminują stałe uprawnienia. Zatwierdzenie i MFA wymuszają dostęp JIT zgodny z oknami wsparcia i zapewniają audytowalną kontrolę.

Wymuszaj zasady dostępu warunkowego (Conditional Access) i ryzyka

Utwórz zasadę CA skierowaną do grupy dostawcy oraz do portalu Azure i interfejsów API ARM, wymagając MFA, zgodnego/hybrydowo dołączonego urządzenia i blokując dostęp z ryzykownych lokalizacji. Najpierw włącz tryb „tylko do raportowania” (report-only), a następnie wymuś zasadę. Skonfiguruj Identity Protection: blokuj wysokie ryzyko użytkownika (wyciekłe poświadczenia) do czasu zresetowania hasła; wymagaj MFA dla średniego ryzyka logowania (podejrzany adres IP).
Uzasadnienie: CA wiąże dostęp z zaufaniem do urządzenia i ryzykiem w czasie rzeczywistym. Tryb „tylko do raportowania” zapobiega awariom podczas wdrażania. Zasady ryzyka automatycznie naprawiają naruszone sesje i konta.

Opublikuj starszą aplikację za pomocą Microsoft Entra application proxy

Wdróż dwa konektory w oddzielnych podsieciach dostępnych dla dostawcy w celu zapewnienia wysokiej dostępności (HA). Skonfiguruj uwierzytelnianie wstępne z Entra ID, wymagaj przypisania do aplikacji dla przedsiębiorstw i zastosuj tę samą zasadę CA. Użyj pakietów dostępu, aby przyznać użytkownikom dostawcy ograniczony czasowo dostęp zarówno do aplikacji dla przedsiębiorstw, jak i do ról w grupie zasobów; ustaw właścicieli grup (Group Owners) jako recenzentów.
Uzasadnienie: App proxy eliminuje ekspozycję na ruch przychodzący i centralizuje uwierzytelnianie. Zarządzanie uprawnieniami standaryzuje onboarding/offboarding i zapewnia okresowe przeglądy przez właścicieli zasobów.

Zabezpiecz poświadczenia obciążeń i aplikacji

Zastąp wszelkie klucze tajne klienta poświadczeniami certyfikatowymi dla jednostek usługi; w przypadku CI/CD użyj federacji tożsamości obciążeń zamiast przechowywania kluczy tajnych. Dla obciążeń AKS, które potrzebują obrazów, dołącz ACR do klastra, aby przyznać uprawnienie AcrPull tożsamości zarządzanej.
Uzasadnienie: Usunięcie statycznych kluczy tajnych zamyka powszechny wektor naruszenia; federacja i tożsamości zarządzane zapewniają dostęp o najniższych uprawnieniach z automatyczną rotacją.

Chroń konta awaryjne i monitoruj

Wyklucz dwa konta awaryjne (break-glass) z zasad CA, ale zabezpiecz je długimi, losowymi hasłami przechowywanymi offline. Włącz kwartalne przeglądy dostępu i eksportuj logi PIM i CA do obszaru roboczego Log Analytics z alertami dotyczącymi anomalnych aktywacji.
Uzasadnienie: Konta awaryjne zapobiegają blokadzie dzierżawy, będąc jednocześnie bezpiecznymi operacyjnie. Ciągłe monitorowanie szybko wykrywa nadużycia, utrzymując zgodność i gotowość do reagowania na incydenty.

Wszystkie domeny · Architektura bezpieczeństwa sieci →

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