Microsoft AZ-140: Tożsamość, dostęp i zarządzanie — Przewodnik do nauki

By Laurynas Brazys · 12 August 2026 · #microsoft #az-140 #certification #exam-prep #study-guide

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

Przegląd

Tożsamość, dostęp i ład organizacyjny definiują, w jaki sposób użytkownicy, urządzenia i automatyzacja wchodzą w interakcję z zasobami Azure Virtual Desktop. Solidny projekt wykorzystuje Microsoft Entra ID jako płaszczyznę sterowania tożsamością, stosuje zasadę najniższych uprawnień za pomocą Azure RBAC w zakresie zasobów AVD, wymusza dostęp warunkowy i uwierzytelnianie wieloskładnikowe oraz operacjonalizuje automatyzację przy użyciu tożsamości zarządzanych. Decyzje, takie jak to, czy hosty sesji są przyłączone do Microsoft Entra, czy hybrydowo przyłączone do Microsoft Entra, wpływają na dalsze wymagania dotyczące DNS, uwierzytelniania, przechowywania profili i zachowania dostępu warunkowego.

Projekt tożsamości i katalogu

• Dzierżawy, użytkownicy i grupy Microsoft Entra ID

  • Płaszczyzna sterowania AVD jest natywnie zintegrowana z Microsoft Entra ID. Użytkownicy muszą istnieć w dzierżawie będącej właścicielem zasobów AVD lub być użytkownikami-gośćmi B2B z odpowiednimi przypisaniami.
  • Używaj grup zabezpieczeń Microsoft Entra — statycznych lub dynamicznych — do przypisań grup aplikacji i administracji opartej na rolach. Unikaj zagnieżdżonych grup dla przypisań ról AVD; Azure RBAC nie ewaluuje członkostwa w zagnieżdżonych grupach przy przypisywaniu ról.

• Przypisywanie oparte na grupach do grup aplikacji AVD

  • Użytkownicy uzyskują uprawnienia do zdalnych aplikacji lub pulpitów poprzez przypisanie użytkowników lub grup do grupy aplikacji. W momencie autoryzacji Azure stosuje przypisanie roli Desktop Virtualization User w zakresie grupy aplikacji do tych podmiotów zabezpieczeń.
  • Preferuj przypisania grupowe nad indywidualnymi użytkownikami, aby uprościć zarządzanie cyklem życia i przeglądy dostępu. Używaj grup dynamicznych opartych na atrybutach użytkownika lub dziale, aby mapować użytkowników do odpowiednich grup aplikacji RemoteApp lub Desktop.

• Hosty sesji przyłączone do Microsoft Entra a przyłączone hybrydowo do Microsoft Entra

  • Przyłączone do Microsoft Entra: Brak bezpośredniej widoczności tradycyjnych kontrolerów domeny. Idealne dla wdrożeń typu cloud-first. Obsługuje nowoczesne uwierzytelnianie i SSO do sesji za pomocą Microsoft Entra ID. W przypadku FSLogix użyj Azure Files z Microsoft Entra Kerberos, aby hosty mogły uwierzytelniać się do profili bez AD DS.
  • Przyłączone hybrydowo do Microsoft Entra (przyłączone do domeny AD DS i zarejestrowane w Entra ID): Wymagane, jeśli musisz używać istniejących zasad grupy (Group Policy), lokalnego uwierzytelniania Kerberos/NTLM lub zasobów SMB wymagających AD DS. Upewnij się, że DNS w sieci VNET wskazuje na kontrolery domeny, które mogą rozpoznawać i obsługiwać domenę. Jeśli używasz Azure AD DS (domena zarządzana), ustaw serwery DNS sieci VNET na adresy IP domeny zarządzanej przed przyłączeniem hostów sesji do domeny.

• Tożsamość hybrydowa, Microsoft Entra Connect, synchronizacja skrótów haseł i bezproblemowe logowanie jednokrotne (SSO)

  • Użyj Microsoft Entra Connect do synchronizacji tożsamości użytkowników z AD DS. Synchronizacja skrótów haseł jest najprostszą i najbardziej odporną metodą logowania, która obsługuje dostęp warunkowy po stronie chmury.
  • Włącz bezproblemowe logowanie jednokrotne (Seamless SSO), aby urządzenia firmowe w sieci wewnętrznej mogły uzyskać logowanie jednokrotne oparte na protokole Kerberos do Entra ID bez monitowania o poświadczenia. Poprawia to doświadczenie użytkownika podczas uruchamiania AVD z zarządzanych sieci, jednocześnie umożliwiając egzekwowanie dostępu warunkowego.

Kontrola dostępu i zasada najniższych uprawnień

• Wbudowane role Azure RBAC dla AVD

  • Desktop Virtualization Administrator: Pełna kontrola administracyjna nad zasobami AVD.
  • Desktop Virtualization Contributor: Zarządzanie zasobami AVD bez przyznawania dostępu użytkownikom końcowym.
  • Desktop Virtualization Reader: Wyświetlanie zasobów AVD.
  • Desktop Virtualization Host Pool Contributor: Zarządzanie ustawieniami puli hostów i kluczami rejestracji; brak pełnej kontroli nad innymi zasobami AVD.
  • Desktop Virtualization Workspace Contributor: Publikowanie lub usuwanie grup aplikacji z obszaru roboczego.
  • Desktop Virtualization Application Group Contributor: Zarządzanie właściwościami grupy aplikacji i opublikowanymi aplikacjami; nie przyznaje dostępu użytkownikom.
  • Desktop Virtualization Session Host Operator: Rola zorientowana na pomoc techniczną (help-desk); wyświetlanie hostów sesji, sesji użytkowników, wysyłanie wiadomości, rozłączanie lub wylogowywanie sesji.
  • Desktop Virtualization User: Przypisywana do użytkowników/grup w zakresie grupy aplikacji w celu autoryzacji uruchomień.

• Zakresy i wzorce przypisywania ról

  • Ograniczaj zakres uprawnień tak wąsko, jak to możliwe:
    • Przypisuj rolę Desktop Virtualization User do użytkowników/grup wyłącznie w zakresie grupy aplikacji.
    • Przypisuj rolę Application Group Contributor do grupy aplikacji; Workspace Contributor do obszaru roboczego; Host Pool Contributor do puli hostów.
    • Przypisuj rolę Virtual Machine Contributor i powiązane role dotyczące zasobów obliczeniowych/magazynu/sieci w zakresie grupy zasobów zawierającej maszyny wirtualne hostów sesji, jeśli personel operacyjny musi zarządzać zasilaniem, rozmiarami lub interfejsami sieciowymi gości.
  • Oddzielne grupy zasobów dla obiektów płaszczyzny sterowania (obszary robocze, pule hostów, grupy aplikacji) i maszyn wirtualnych hostów sesji poprawiają ograniczanie zakresu i możliwość przeprowadzania inspekcji.

• Tożsamości zarządzane, jednostki usługi i delegowana automatyzacja

  • Preferuj tożsamości zarządzane przypisane przez system lub użytkownika dla funkcji automatycznego skalowania AVD i operacyjnych elementów runbook. Przyznawaj tylko niezbędne role, w minimalnym zakresie, do manipulowania docelowymi zasobami (na przykład Virtual Machine Contributor w grupie zasobów hosta sesji i Desktop Virtualization Contributor w puli hostów).
  • Używaj jednostek usługi z poświadczeniami certyfikatów dla potoków DevOps, które publikują grupy aplikacji lub aktualizują właściwości RDP. Ogranicz ich uprawnienia do konkretnych zasobów AVD, którymi zarządzają.

• Privileged Identity Management i dostęp awaryjny

  • Używaj Microsoft Entra Privileged Identity Management zarówno dla ról Azure RBAC, jak i Microsoft Entra. Ustawiaj role wysokiego ryzyka, takie jak Desktop Virtualization Administrator i Subscription Owner, jako uprawnione (eligible) i wymagaj uwierzytelniania wieloskładnikowego, zatwierdzeń oraz uzasadnienia.
  • Utrzymuj co najmniej dwa konta dostępu awaryjnego (typu break-glass) z rolą Global Administrator, wykluczone z dostępu warunkowego i PIM, przechowywane w trybie offline, okresowo testowane i używane wyłącznie do celów odzyskiwania.

Krótkie przykłady zakresu ról:

# End-user entitlement to one application group
az role assignment create \
  --assignee <groupObjectId> \
  --role "Desktop Virtualization User" \
  --scope /subscriptions/<subId>/resourceGroups/rg-avd-control/providers/Microsoft.DesktopVirtualization/applicationGroups/ag-fin-remoteapps

# Help-desk session operations on a host pool
az role assignment create \
  --assignee <helpdeskGroupId> \
  --role "Desktop Virtualization Session Host Operator" \
  --scope /subscriptions/<subId>/resourceGroups/rg-avd-control/providers/Microsoft.DesktopVirtualization/hostPools/hp-fin

Dostęp warunkowy, MFA i kontrola sesji

• Docelowe aplikacje w chmurze

  • Zastosuj dostęp warunkowy (Conditional Access) zarówno do Azure Virtual Desktop, jak i do Azure Virtual Desktop Azure Resource Manager, aby chronić połączenia użytkowników końcowych i działania administracyjne. Wyklucz konta awaryjne (break-glass accounts) i tożsamości obciążeń nieinteraktywnych.

• Uwierzytelnianie wieloskładnikowe i siła uwierzytelniania

  • Wymagaj MFA dla wszystkich logowań zewnętrznych lub o wysokim ryzyku. Użyj siły uwierzytelniania (authentication strengths), aby wymusić metody odporne na phishing (np. klucze bezpieczeństwa FIDO2, klucze dostępu powiązane z urządzeniem w Microsoft Authenticator lub uwierzytelnianie oparte na certyfikatach).
  • Aby zapewnić najlepsze doświadczenie użytkownika z klientem Windows, połącz odporne na phishing MFA z logowaniem jednokrotnym (SSO) AVD, aby użytkownicy uwierzytelniali się raz w Entra ID i byli płynnie logowani do sesji Windows.

• Zgodność urządzeń i sygnały z Intune

  • Aby ograniczyć dostęp do zarządzanych punktów końcowych, użyj dostępu warunkowego (Conditional Access) z opcją wymagania, aby urządzenie było oznaczone jako zgodne (Require device to be marked as compliant). Ocenia to stan zgodności z Microsoft Intune dla urządzeń z systemami Windows, macOS, iOS i Android korzystających z klienta Remote Desktop.
  • Dla urządzeń BYOD lub niezarządzanych użyj alternatywnych mechanizmów kontroli, takich jak MFA, zasady oparte na ryzyku logowania, warunki użytkowania (Terms of Use) i ograniczenia sesji. Rozważ utworzenie oddzielnych grup aplikacji dla BYOD z ograniczonym dostępem do aplikacji.

• Kontrola sesji i częstotliwość logowania

  • Skonfiguruj częstotliwość logowania odpowiednią dla produktywności i ryzyka (np. 12 godzin), aby uniknąć powtarzających się monitów podczas ponownych połączeń. Trwała sesja przeglądarki (Persistent browser session) nie ma zastosowania do natywnych klientów Remote Desktop. Wykorzystaj Continuous Access Evaluation tam, gdzie jest to wspierane, aby umożliwić szybkie zmiany zasad i unieważnianie dostępu w razie ryzyka.

• Uwarunkowania sieciowe i lokalizacyjne

  • Użyj nazwanych lokalizacji (named locations), aby zmniejszyć utrudnienia dla zaufanych sieci biurowych. W przypadku pracowników zdalnych połącz MFA i zgodność urządzeń, aby utrzymać wysoki poziom bezpieczeństwa.

Kwestie operacyjne dotyczące tożsamości hostów

• DNS i dołączanie do domeny

  • W przypadku hostów dołączonych do AD DS lub Azure AD DS, przed udostępnieniem zasobów należy ustawić serwery DNS w VNET na adresy IP kontrolerów domeny lub zarządzanej domeny. Bez poprawnej konfiguracji DNS dołączenie do domeny nie powiedzie się, a FSLogix, GPO i Kerberos nie będą działać.
  • W przypadku hostów dołączonych do Microsoft Entra nie jest wymagany DNS z AD DS; jednak docelowe zasoby SMB dla profili nadal wymagają możliwości nowoczesnego uwierzytelniania (Microsoft Entra Kerberos z Azure Files).

• Klucze rejestracyjne i skalowanie w poziomie

  • Dodawanie istniejących lub nowych hostów sesji do puli hostów wymaga ważnego klucza rejestracyjnego. Ogranicz czas życia klucza i zawęź wdrożenie rozszerzenia VM tylko do zasobu puli hostów.

• Uruchamianie maszyny wirtualnej przy połączeniu i autoskalowanie

  • W przypadku funkcji autoskalowania, które dealokują/alokują maszyny wirtualne, przypisz tożsamości zarządzanej planu skalowania rolę Virtual Machine Contributor w grupie zasobów maszyn wirtualnych hostów oraz rolę Desktop Virtualization Contributor w puli hostów. Unikaj nadawania uprawnień na poziomie subskrypcji.

• Przeglądy dostępu i cykl życia uprawnień

  • Wdróż okresowe przeglądy dostępu dla grup Entra przypisanych do grup aplikacji. Zintegruj z Entitlement Management, jeśli dostęp do aplikacji obejmuje wiele grup aplikacji lub zasobów.

• Inspekcja

  • Monitoruj dzienniki logowania i inspekcji Microsoft Entra pod kątem dostępu do aplikacji AVD oraz Azure Activity Logs pod kątem zmian w zasobach AVD. Przesyłaj dane strumieniowo do Log Analytics lub systemu SIEM z alertami dotyczącymi anomalnej aktywności (na przykład masowe wylogowania z sesji lub nieoczekiwane przypisania ról).

Praktyczny scenariusz problemowy

Firma Tailwind Traders wdraża bezpieczny zdalny dostęp do swoich aplikacji biznesowych (LOB) za pośrednictwem Azure Virtual Desktop dla 3000 użytkowników. Posiadają lokalny las AD zsynchronizowany z Microsoft Entra ID za pomocą synchronizacji skrótów haseł i Seamless SSO. Planują modernizację, wykorzystując hosty sesji dołączone do Microsoft Entra dla nowych pul, jednocześnie zachowując jedną starszą pulę hybrydową, która wymaga GPO. Muszą wdrożyć MFA odporne na phishing, zezwolić na dostęp tylko z urządzeń zgodnych z zasadami (compliant), gdy użytkownicy pracują poza siedzibą firmy, delegować operacje na sesjach dla działu pomocy technicznej oraz uruchomić autoskalowanie z najniższymi wymaganymi uprawnieniami.

1. Wybór modeli dołączania hostów i DNS

   • Działanie: Wdróż nową, współdzieloną pulę hostów z maszynami Windows 11 Enterprise multi-session dołączonymi do Microsoft Entra dla większości użytkowników; zachowaj mniejszą pulę dołączoną hybrydowo dla aplikacji wymagającej GPO.
   • Uzasadnienie: Dołączenie do Entra zmniejsza zależność od kontrolerów domeny i upraszcza Conditional Access. Starsza pula zachowuje wymagane GPO. Dla puli hybrydowej DNS w VNET jest ustawiony na adresy IP lokalnych kontrolerów domeny osiągalnych przez VPN, aby zapewnić dołączenie do domeny i działanie protokołu Kerberos.

2. Przechowywanie profili z nowoczesnym uwierzytelnianiem

   • Działanie: Użyj Azure Files z Microsoft Entra Kerberos dla FSLogix w puli dołączonej do Entra. Skonfiguruj uprawnienia na poziomie udziału i plików dla użytkowników oraz tożsamości zarządzanych hostów sesji.
   • Uzasadnienie: Umożliwia dostęp do SMB bez użycia domeny, wykorzystując Entra ID, co eliminuje zależność od AD DS dla profili w puli opartej na chmurze (cloud-first).

3. Uprawnienia oparte na grupach

   • Działanie: Utwórz grupy bezpieczeństwa Entra dla każdej persony (np. grp-tt-hr-remoteapps, grp-tt-sales-desktop). Przypisz te grupy do odpowiednich grup aplikacji; unikaj zagnieżdżonych grup.
   • Uzasadnienie: Centralizuje kontrolę dostępu i umożliwia przeprowadzanie przeglądów dostępu. Bezpośrednie przypisania grup są niezawodnie oceniane przez Azure RBAC dla AVD.

4. Conditional Access z siłami uwierzytelniania

   • Działanie: Utwórz zasady skierowane do aplikacji Azure Virtual Desktop i Azure Virtual Desktop Azure Resource Manager:
     • Wymagaj siły uwierzytelniania „MFA odporne na phishing”.
     • Dla lokalizacji poza zaufanymi biurami, wymagaj dodatkowo, aby urządzenie było oznaczone jako zgodne (compliant).
     • Ustaw częstotliwość logowania na 12 godzin dla użytkowników końcowych.
     • Wyklucz dwa konta awaryjne (break-glass) i tożsamość zarządzaną autoskalowania.
   • Uzasadnienie: Wymusza silne czynniki uwierzytelniania i dostęp z zarządzanych urządzeń bez nadmiernej liczby monitów oraz pozwala uniknąć blokowania tożsamości awaryjnych lub tożsamości obciążeń.

5. Delegowanie operacji z najniższymi wymaganymi uprawnieniami

   • Działanie: Przypisz role w minimalnych zakresach:
     • Desktop Virtualization User do grup uprawnień w zakresach ich grup aplikacji.
     • Desktop Virtualization Session Host Operator do grupy działu pomocy technicznej w każdej puli hostów.
     • Desktop Virtualization Workspace Contributor do zespołu publikującego aplikacje w obszarze roboczym.
     • Virtual Machine Contributor do zespołu operacyjnego tylko w grupie zasobów hostów sesji.
   • Uzasadnienie: Dopasowuje obowiązki do zakresów, którymi zarządzają, zapobiegając nadmiernym uprawnieniom na poziomie subskrypcji.

6. Konfiguracja autoskalowania z tożsamością zarządzaną

   • Działanie: Włącz autoskalowanie w puli hostów z tożsamością zarządzaną przypisaną przez użytkownika. Nadaj jej uprawnienia Virtual Machine Contributor w grupie zasobów hostów sesji oraz Desktop Virtualization Contributor w puli hostów. Przykład:

az role assignment create --assignee <miObjectId> --role "Virtual Machine Contributor" --scope /subscriptions/<sub>/resourceGroups/rg-tt-avd-hosts
az role assignment create --assignee <miObjectId> --role "Desktop Virtualization Contributor" --scope /subscriptions/<sub>/resourceGroups/rg-tt-avd-control/providers/Microsoft.DesktopVirtualization/hostPools/hp-tt-prod

• Uzasadnienie: Autoskalowanie może uruchamiać i zatrzymywać maszyny wirtualne oraz aktualizować metryki puli hostów bez szerokich uprawnień.

7. Ochrona administracji za pomocą PIM i kont awaryjnych

   • Działanie: Wdróż administracyjne role RBAC w Microsoft Entra PIM z przepływami pracy zatwierdzania i MFA. Utrzymuj dwa konta awaryjne Global Administrator, wykluczone z zasad Conditional Access i PIM.
   • Uzasadnienie: Redukuje stałe uprawnienia i zapewnia możliwość odzyskania dostępu w przypadku błędnej konfiguracji Conditional Access lub usług tożsamości.

8. Monitorowanie i okresowy przegląd dostępu

   • Działanie: Przesyłaj strumieniowo dzienniki logowania Entra i Azure Activity Logs do Log Analytics. Przeprowadzaj kwartalne przeglądy dostępu dla grup przypisanych do grup aplikacji oraz dla ról operatorów działu pomocy technicznej.
   • Uzasadnienie: Utrzymuje zasadę najniższych uprawnień w czasie i wykrywa anomalie, takie jak nieoczekiwany wzrost liczby odrzuconych logowań do AVD lub masowe zamykanie sesji.

Takie podejście łączy tożsamość opartą na chmurze (cloud-first) z precyzyjnym określaniem zakresu i silnymi zasadami dostępu, równoważy doświadczenie użytkownika z bezpieczeństwem oraz zapewnia, że operacje i automatyzacja mają delegowane tylko niezbędne uprawnienia.

← Architektura i projektowanie usługi Azure Virtual Desktop · Wszystkie domeny · Sieci →

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

Przeglądaj Microsoft →