Microsoft AZ-900: Ład i zgodność — Przewodnik do nauki

By Laurynas Brazys · 23 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

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

Zarządzanie (governance) w Azure dostosowuje wykorzystanie chmury do wymagań biznesowych, bezpieczeństwa i regulacyjnych poprzez warstwowy zestaw mechanizmów kontrolnych: strukturę organizacyjną, zasady (policy), standaryzowane wdrożenia, ochronę przed przypadkowymi zmianami i ciągły audyt. Te funkcje działają natywnie w płaszczyźnie sterowania Azure Resource Manager i skalują się od pojedynczej subskrypcji do dużych środowisk wielodostępnych (multi-tenant). Dobre zarządzanie redukuje dryf konfiguracji, wymusza spójność i dostarcza dowodów zgodności bez spowalniania pracy deweloperów. Zgodność zależy od solidnej inwentaryzacji i historii zmian. Azure zapewnia widoczność zasobów w czasie zbliżonym do rzeczywistego w różnych subskrypcjach, predefiniowane mapowania regulacyjne oraz mechanizmy odnajdywania danych w celu lokalizowania i klasyfikowania informacji wrażliwych. Rezultatem jest możliwa do obrony postawa bezpieczeństwa w chmurze (cloud posture), w której standardy są definiowane jednorazowo, automatycznie egzekwowane, stale potwierdzane dowodami i korygowane na dużą skalę.

Azure Policy: definicje, inicjatywy, kontrola lokalizacji i naprawa

Azure Policy definiuje bariery ochronne (guardrails), które oceniają konfiguracje zasobów podczas ich tworzenia/aktualizacji (a także regularnie później) i wymuszają pożądane stany. Definicja zasady (policy definition) używa warunków i efektów do oceny właściwości zasobów udostępnianych przez dostawców zasobów (resource providers). Główne efekty to Deny, Audit, Append, Modify, DeployIfNotExists, AuditIfNotExists i Disabled. Zasady można przypisywać na poziomie grupy zarządzania (management group), subskrypcji, grupy zasobów lub pojedynczego zasobu, a dziedziczenie zapewnia, że szersze przypisania są stosowane na niższych poziomach, chyba że zostaną wykluczone za pomocą notScopes. Inicjatywy (Initiatives) grupują powiązane definicje zasad w jeden pakiet z parametrami, co pozwala na spójne i powtarzalne przypisywanie. Na przykład inicjatywa bazowa dotycząca bezpieczeństwa może zawierać zasady wymagające ustawień diagnostycznych, ograniczające publiczne punkty końcowe, wymuszające tagowanie i audytujące brak kopii zapasowych. Przypisanie inicjatywy stosuje wszystkie zawarte w niej zasady w ramach jednej akcji i daje pojedynczy widok zgodności. Wbudowane zasady Allowed locations ograniczają, gdzie mogą być tworzone grupy zasobów i zasoby, zapobiegając wdrożeniom w niezatwierdzonych regionach i pomagając w zachowaniu rezydencji i suwerenności danych. Gdy żądanie utworzenia zasobu jest skierowane do zabronionego regionu, efekt Deny blokuje operację, zanim dotrze ona do dostawcy zasobów, zapewniając ścisłą zgodność. Gdy zostanie wykryty dryf konfiguracji, zadania naprawcze (remediation tasks) przywracają zgodność zasobów na dużą skalę. W przypadku zasad z efektami DeployIfNotExists i Modify, tożsamość zarządzana (managed identity) przypisania zasady jest używana do rekonfiguracji niezgodnych zasobów (na przykład włączając ustawienia diagnostyczne na kontach magazynu lub dołączając wymagane tagi). Zadania naprawcze mogą mieć wąski zakres lub być uruchamiane w całych subskrypcjach, a wyniki zgodności są prezentowane dla każdej zasady i każdego zasobu w celu śledzenia audytowego.

• Cel
  • Definicja zasady (Policy Definition): Pojedyncza reguła oceniająca właściwości zasobu
  • Inicjatywa (Policy Set): Zestaw definicji zasad ze wspólnymi parametrami
  • Zakres przypisania: Grupa zarządzania, subskrypcja, grupa zasobów lub zasób
  • Typowe efekty: Deny, Audit, Append, Modify, DeployIfNotExists, AuditIfNotExists
  • Wymagania dotyczące naprawy: Tożsamość zarządzana w przypisaniu; dotyczy efektów Modify/DeployIfNotExists
• Przypadek użycia
  • Definicja zasady (Policy Definition): Wymuszanie SKU, TLS, tagów, prywatnych punktów końcowych
  • Inicjatywa (Policy Set): Zastosowanie bazowego standardu bezpieczeństwa lub zarządzania
  • Zakres przypisania: Szerokie egzekwowanie z dziedziczeniem i wykluczeniami
  • Typowe efekty: Twarde egzekwowanie lub audytowanie tylko w celu zebrania dowodów
  • Wymagania dotyczące naprawy: Uprawnienia wystarczające do zmiany docelowych zasobów

Azure Blueprints: pakowanie standardów z zasadami, RBAC, grupami zasobów i szablonami

Azure Blueprints pakuje artefakty zarządzania, aby organizacje mogły spójnie tworzyć („stemplować”) zgodne środowiska. Definicja schematu (blueprint definition) może zawierać przypisania zasad, przypisania kontroli dostępu opartej na rolach (Azure RBAC), definicje grup zasobów oraz artefakty wdrożeniowe, takie jak szablony ARM (w tym Bicep) do provisioningu standardowej infrastruktury. Parametry pozwalają na dostosowanie każdego przypisania, zachowując jednocześnie jedno, wersjonowane źródło prawdy. Schematy (Blueprints) pomagają oddzielić to, „co musi istnieć i kto co może zrobić” od kodu aplikacji (workload). Na przykład, bazowy schemat może tworzyć grupy zasobów typu „spoke”, przypisywać rolę Reader zespołom audytowym i Contributor zespołom platformowym, wdrażać szablon sieci hub-and-spoke oraz przypisywać inicjatywy dotyczące diagnostyki i bezpieczeństwa. Przypisanie schematu do jednej lub więcej subskrypcji stosuje wszystkie artefakty w odpowiedniej kolejności i rejestruje stan zgodności. Wersjonowanie wspiera kontrolowane aktualizacje, a blokowanie artefaktów (artifact locking) może chronić krytyczne komponenty po wdrożeniu.

• Główny cel
  • Azure Policy: Bariery ochronne dla konfiguracji i zgodności
  • Szablony ARM/Bicep: Deklaratywne wdrażanie zasobów
  • Azure Blueprints: Pakowanie i zarządzanie standardami w różnych subskrypcjach
• Zawiera RBAC
  • Azure Policy: Nie (osobne przypisanie)
  • Szablony ARM/Bicep: Nie (osobne przypisanie)
  • Azure Blueprints: Tak (przypisania ról jako artefakty)
• Zawiera Policy
  • Azure Policy: Nie dotyczy
  • Szablony ARM/Bicep: Nie (może wdrażać zasoby zasad, ale nie przypisywać)
  • Azure Blueprints: Tak (przypisania zasad jako artefakty)
• Tworzy grupy zasobów
  • Azure Policy: Może wymagać/wymuszać nazewnictwo/tagi
  • Szablony ARM/Bicep: Może wdrażać wewnątrz lub tworzyć poprzez zagnieżdżone wdrożenia
  • Azure Blueprints: Tak (definiuje artefakty RG jako część schematu)
• Typowe zastosowanie
  • Azure Policy: Ograniczanie jednostek SKU, wymuszanie diagnostyki, tagów
  • Szablony ARM/Bicep: Provisioning sieci VNet, Key Vaults, App Services
  • Azure Blueprints: Tworzenie zgodnych stref docelowych (landing zones) z zasadami + RBAC + infrastrukturą

Organizacja i standardy: grupy zarządzania, subskrypcje, grupy zasobów, nazewnictwo i tagi

Hierarchia zarządzania w Azure umożliwia skalowanie ładu korporacyjnego. Grupy zarządzania (Management groups) znajdują się powyżej subskrypcji i stanowią miejsce do stosowania zasad (policy) i RBAC, które są dziedziczone przez wszystkie podrzędne subskrypcje. Subskrypcje definiują rozliczenia, limity usług i granicę bezpieczeństwa dla większości mechanizmów kontrolnych. Grupy zasobów (Resource groups) przechowują zasoby o wspólnym cyklu życia, uprawnieniach i logice wdrożenia; każdy zasób należy do dokładnie jednej grupy zasobów i jednej subskrypcji. Standardy nazewnictwa i tagowania przekładają założenia ładu korporacyjnego na przejrzystość operacyjną. Nazwy powinny kodować skróty typów zasobów, obciążenie robocze, środowisko i region (na przykład kv-payroll-prod-eus2) w ramach limitów usługi. Tagi dodają kontekst biznesowy do zasobów w celu alokacji kosztów, określenia właściciela, klasyfikacji danych i kluczy automatyzacji (na przykład costCenter=FIN, owner=ops-team@contoso.com, dataSensitivity=Confidential). Azure Policy z efektami Modify i Append wymusza obecność tagów i wzorce ich wartości, a także może dziedziczyć tagi z grup zasobów na zasoby. Spójność w tym obszarze zapewnia niezawodne raportowanie kosztów, przeglądy dostępu i automatyzację cyklu życia.

• Management Group
  • Cel: Zarządzanie na dużą skalę w wielu subskrypcjach
  • Typowe zastosowania: Stosowanie zasad, RBAC i inicjatyw do jednostek biznesowych lub środowisk
  • Może zawierać: Podrzędne grupy zarządzania i subskrypcje
  • Kluczowe uwagi: Do 6 poziomów głębokości (z wyłączeniem głównej); dziedziczenie odbywa się w dół
• Subscription
  • Cel: Granica rozliczeniowa i usługowa
  • Typowe zastosowania: Izolacja obciążeń roboczych, segregacja kosztów, zarządzanie limitami
  • Może zawierać: Grupy zasobów i zasoby
  • Kluczowe uwagi: Przypisania zasad/RBAC na tym poziomie wpływają na wszystkie zawarte w niej grupy zasobów
• Resource Group
  • Cel: Granica cyklu życia i uprawnień dla zasobów
  • Typowe zastosowania: Wspólne wdrażanie, aktualizowanie i usuwanie powiązanych zasobów
  • Może zawierać: Zasoby
  • Kluczowe uwagi: Zasób może istnieć tylko w jednej grupie zasobów; przenoszenie między grupami/subskrypcjami ma ograniczenia specyficzne dla usługi

Blokady zasobów i zapobieganie przypadkowemu usunięciu

Blokady zasobów stanowią ostatnią linię obrony przed niezamierzonymi zmianami. Blokady są stosowane na poziomie subskrypcji, grupy zasobów lub zasobu i są dziedziczone w dół. Istnieją dwa typy blokad: CanNotDelete zapobiega usunięciu, ale zezwala na operacje odczytu i zapisu, a ReadOnly ogranicza wszystkie operacje zapisu i usuwania (w praktyce zezwalając tylko na operacje odczytu). Blokady chronią przed działaniami z portalu, CLI, PowerShell, ARM/Bicep i narzędzi IaC firm trzecich. Używaj CanNotDelete na współdzielonej lub krytycznej infrastrukturze — sieciach wirtualnych, tabelach routingu, strefach DNS, produkcyjnych Key Vaults — aby prace konserwacyjne mogły być kontynuowane, podczas gdy usuwanie jest zablokowane. Używaj ReadOnly oszczędnie dla artefaktów, które muszą pozostać całkowicie statyczne, takich jak zarchiwizowane konta magazynu lub kontenery z danymi dowodowymi dla celów regulacyjnych; wiele usług wymaga operacji zapisu do normalnego działania i ulegnie awarii z blokadą ReadOnly. Tylko podmioty z odpowiednimi uprawnieniami (na przykład Owner z Microsoft.Authorization/locks/*) mogą usunąć blokadę, a samo jej usunięcie jest operacją podlegającą audytowi w Activity Log.

• CanNotDelete
  • Odczyty: Dozwolone
  • Zapisy/Aktualizacje: Dozwolone
  • Usunięcia: Zablokowane
  • Typowe przypadki użycia: Ochrona VNet, tabel routingu, produkcyjnych Key Vaults, krytycznych grup zasobów
  • Uwagi: Zezwala na zmiany konfiguracji; operacje usunięcia kończą się niepowodzeniem do czasu usunięcia blokady
• ReadOnly
  • Odczyty: Dozwolone
  • Zapisy/Aktualizacje: Zablokowane
  • Usunięcia: Zablokowane
  • Typowe przypadki użycia: Zachowanie magazynów dowodowych, archiwalnych pamięci masowych, niezmiennych konfiguracji
  • Uwagi: Wiele usług przestaje działać z blokadą ReadOnly; aktualizacje i skalowanie są zablokowane

Inspekcja, inwentaryzacja i zgodność z przepisami: Resource Graph, Activity Log, Defender for Cloud i Microsoft Purview

Azure Resource Graph umożliwia szybkie i skalowalne zapytania dotyczące inwentaryzacji i stanu zabezpieczeń w ramach subskrypcji i grup zarządzania przy użyciu Kusto Query Language (KQL). Pozwala odpowiadać na pytania, takie jak które konta magazynu nie mają włączonego szyfrowania, które sieci VNet udostępniają publiczne adresy IP oraz które zasoby są niezgodne z zasadami. Wyniki zasilają pulpity nawigacyjne, synchronizację z CMDB i potoki naprawcze. Resource Graph może również ujawniać stany zgodności z zasadami, rozkład tagów i wymiary atrybucji kosztów w połączeniu z danymi z Cost Management. Azure Activity Log rejestruje operacje na płaszczyźnie sterowania (control-plane) na zasobach, w tym kto, co i kiedy zrobił, z domyślnym okresem przechowywania wynoszącym 90 dni. Przekieruj Activity Log do Log Analytics, Azure Storage lub Event Hubs w celu długoterminowego przechowywania, korelacji i pozyskiwania danych przez systemy SIEM. Analiza historii zmian precyzyjnie wskazuje dryf konfiguracji, wspiera reagowanie na incydenty i dostarcza dowodów na potrzeby audytów. Microsoft Defender for Cloud przekłada techniczny stan zabezpieczeń na widoki zgodności z przepisami, mapując oceny na standardy takie jak Azure Security Benchmark, ISO/IEC 27001, NIST SP 800-53, PCI DSS i CIS. Pulpit nawigacyjny zgodności z przepisami (Regulatory compliance) pokazuje kontrole, które przeszły lub nie przeszły weryfikacji, zasoby, których dotyczy problem, oraz wskazówki dotyczące naprawy. Włączenie automatycznego aprowizowania integruje agentów i zasady tam, gdzie jest to potrzebne, a wskaźnik bezpieczeństwa (secure score) oferuje perspektywę do priorytetyzacji. Microsoft Purview odnajduje, klasyfikuje i kataloguje dane w źródłach Azure, wielochmurowych i lokalnych (on-premises). Skanowanie identyfikuje dane wrażliwe (np. finansowe, PII, zdrowotne) w Azure Storage, SQL, Synapse, Power BI i wielu innych, stosując wbudowane lub niestandardowe klasyfikatory. Purview Data Map i Catalog zapewniają śledzenie pochodzenia danych (lineage), informacje o właścicielach i etykietowanie wrażliwości, które integrują się z Microsoft Information Protection, umożliwiając zapobieganie utracie danych (DLP) i podejmowanie decyzji dotyczących zasad dostępu zgodnie z obowiązkami regulacyjnymi.

• Główna funkcja
  • Azure Resource Graph: Inwentaryzacja i zapytania o stan zabezpieczeń na dużą skalę
  • Activity Log: Ścieżka audytowa operacji na płaszczyźnie sterowania
  • Defender for Cloud (Regulatory): Mapowanie stanu zabezpieczeń na standardy i priorytetyzacja poprawek
  • Microsoft Purview: Odnajdywanie, klasyfikacja, katalogowanie i śledzenie pochodzenia danych
• Zakres
  • Azure Resource Graph: W ramach grup zarządzania/subskrypcji
  • Activity Log: Na poziomie tenanta z przekierowaniem do LA/Storage/Event Hub
  • Defender for Cloud (Regulatory): Na poziomie subskrypcji/tenanta z przypisaniami inicjatyw
  • Microsoft Purview: W ramach różnych źródeł danych (Azure, M365, on-prem, multicloud)
• Typowe wyniki
  • Azure Resource Graph: Wyniki zapytań KQL, pulpity nawigacyjne, eksporty
  • Activity Log: Kto/co/kiedy, status, kody błędów
  • Defender for Cloud (Regulatory): Status zgodności kontroli, wskaźnik bezpieczeństwa, rekomendacje
  • Microsoft Purview: Zasoby danych, etykiety wrażliwości, schematy, grafy pochodzenia danych

Praktyczny problem: Standaryzacja zgodnych z przepisami stref docelowych w Fabrikam Retail Group

Scenariusz: Fabrikam Retail Group działa w Ameryce Północnej i UE, podlegając ścisłym obowiązkom w zakresie rezydencji danych i standardu PCI DSS. Wiele zespołów aplikacyjnych co miesiąc wdraża obciążenia, a wcześniejsze wdrożenia ad-hoc prowadziły do niespójnego tagowania, umieszczania zasobów w niezatwierdzonych regionach i sporadycznego usuwania współdzielonych zasobów sieciowych. Kierownictwo wymaga ustandaryzowanych, zgodnych z przepisami stref docelowych, ciągłego dostarczania dowodów na skuteczność mechanizmów kontrolnych oraz odkrywania danych wrażliwych na platformach przechowywania i analitycznych.

Wyzwanie: Zaprojektuj i wdróż podejście do ładu korporacyjnego w Azure, które wymusza ograniczenia regionalne, standaryzuje wdrożenia za pomocą zasad i RBAC, zapobiega przypadkowemu usuwaniu kluczowej infrastruktury, utrzymuje inwentarz i historię zmian, generuje raporty zgodności z ISO 27001 i PCI DSS oraz odkrywa i klasyfikuje dane wrażliwe.

Zalecane podejście:

1. Utwórz hierarchię grup zarządzania: główna grupa /Fabrikam; podrzędne /Corp (usługi współdzielone), /NA i /EU; pod każdą z nich dodaj /Prod i /NonProd. Przenieś subskrypcje do odpowiednich grup zarządzania.
2. Stwórz inicjatywy zasad na poziomie grup zarządzania: (a) Dozwolone lokalizacje dla danej geografii, (b) Wymagane tagi (costCenter, owner, dataSensitivity) z działaniem Modify/Append, (c) Wymuszaj wysyłanie ustawień diagnostycznych do Log Analytics dla kluczowych usług, (d) Ograniczenia dotyczące jednostek SKU i dostępu z sieci publicznej dla usług PaaS. Przypisz inicjatywy do grup /NA i /EU z parametrami odpowiednimi dla danego regionu i wyklucz subskrypcje awaryjne (break-glass) za pomocą notScopes.
3. Przygotuj schemat (blueprint) dla standardowej strefy docelowej: artefakty obejmują utworzenie grup zasobów typu hub i dla aplikacji, przypisania RBAC (rola Network Contributor dla zespołu platformy, rola Reader dla audytu), przypisania zasad dotyczących diagnostyki i tagów oraz szablony ARM do wdrożenia sieci vNET, peeringu, Key Vault i Log Analytics. Utwórz wersję schematu i przypisz go do wszystkich subskrypcji Prod i NonProd.
4. Zastosuj blokady zasobów: CanNotDelete na sieciach vNET typu hub, tabelach routingu, współdzielonych strefach DNS i obszarach roboczych Log Analytics; ReadOnly na koncie magazynu do archiwizacji na potrzeby eksportów regulacyjnych. Sprawdź, czy właściciele (Owners) subskrypcji z usługami współdzielonymi mogą usuwać blokady po uzyskaniu odpowiednich zgód, gdy planowane są zmiany.
5. Włącz eksport Dziennika aktywności (Activity Log) ze wszystkich subskrypcji do centralnego obszaru roboczego Log Analytics i archiwizuj go na koncie magazynu z niezmiennym (opartym na czasie) przechowywaniem przez siedem lat. Zbuduj pulpity nawigacyjne w Resource Graph, które wyświetlają listę zasobów niezgodnych z zasadami, zasobów z brakującymi tagami oraz aktywów według regionu i tagu dataSensitivity.
6. Włącz usługę Microsoft Defender for Cloud w całej dzierżawie (tenant). Wybierz ISO/IEC 27001 i PCI DSS jako standardy regulacyjne, włącz automatyczne aprowizowanie i przejrzyj rekomendacje. Twórz elementy robocze na podstawie ustaleń o wysokim priorytecie i śledź poprawę wskaźnika bezpieczeństwa (secure score) dla każdej subskrypcji.
7. Wdróż usługę Microsoft Purview w subskrypcji usług współdzielonych /Corp. Zarejestruj Azure SQL, Storage, Synapse i Power BI jako źródła danych. Skonfiguruj zaplanowane skanowania z użyciem wbudowanych typów informacji poufnych i sklasyfikuj zbiory danych. Opublikuj wykaz danych i przypisz właścicieli danych. Wyeksportuj odkryte etykiety poufności, aby wykorzystać je w zasadach dostępu warunkowego i DLP.

Uzasadnienie dla Azure: To podejście rozpoczyna się od określenia zakresu na poziomie grup zarządzania, dzięki czemu zasady i RBAC dziedziczą się w przewidywalny sposób. Następnie wymusza kluczowe mechanizmy kontrolne za pomocą Azure Policy i inicjatyw, aby zapobiegać niezgodności w momencie wdrożenia. Schemat (blueprint) łączy zasady, RBAC, grupy zasobów i szablony infrastruktury, aby tworzyć spójne strefy docelowe, jednocześnie umożliwiając parametryzację według regionu i środowiska. Blokady zasobów chronią krytyczne usługi współdzielone przed przypadkowym usunięciem, nie utrudniając przy tym codziennej konfiguracji tam, gdzie jest to właściwe. Scentralizowane przechowywanie Dziennika aktywności i usługa Resource Graph zapewniają wiarygodny inwentarz i dowody zmian. Defender for Cloud dostarcza bieżącą mapę kontroli regulacyjnych i priorytetyzowaną naprawę, podczas gdy Microsoft Purview odkrywa i klasyfikuje dane wrażliwe, wspierając mechanizmy kontrolne związane z PCI DSS i rezydencją danych w całym środowisku analitycznym Fabrikam.

← Zarządzanie kosztami i ekonomika usług · Wszystkie domeny · Monitorowanie →

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

Przeglądaj Microsoft →