Microsoft AZ-500: Architektura bezpieczeństwa sieci — 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.

Omówienie

Architektura bezpieczeństwa sieciowego Azure wymusza łączność opartą na zasadzie najniższych uprawnień, zakłada możliwość naruszenia bezpieczeństwa i wdraża ciągły monitoring. Łączy ona mikrosegmentację wewnątrz sieci wirtualnych, stanowe płaszczyzny kontroli dla ruchu wschód-zachód i ruchu wychodzącego, ochronę brzegową dla punktów końcowych wystawionych do internetu oraz prywatny dostęp do usług PaaS. Dobre projekty priorytetyzują dostęp oparty na tożsamości w warstwie aplikacji, jednocześnie utrzymując silne granice sieciowe, jawny routing i weryfikowalną telemetrię.

Kontrola i Segmentacja Sieci Wirtualnej

Podsieci są pierwszą granicą segmentacji. Umieszczaj obciążenia robocze o podobnym poziomie zaufania, cyklu życia i polityce w tej samej podsieci; oddzielaj warstwy (webową, aplikacyjną, danych), aby móc stosować niezależne polityki i trasy. Unikaj płaskich, „współdzielonych” podsieci, które mieszają narzędzia administracyjne, serwery pośredniczące (jump hosty) i obciążenia biznesowe; komplikują one polityki i zwiększają promień rażenia.

Sieciowe Grupy Zabezpieczeń (NSG) stosują stanowe filtrowanie w warstwach L3–L4 na poziomie podsieci lub karty sieciowej (NIC). Reguły przychodzące i wychodzące są oceniane według priorytetu (niższy numer ma pierwszeństwo), z niejawną regułą DenyAll na końcu. NSG są stanowe: odpowiedzi na dozwolone przepływy są automatycznie akceptowane, więc rzadko potrzebujesz reguł dla portów efemerycznych. Operacyjnie, przypisuj NSG do podsieci w celu uzyskania szerokiej kontroli, a następnie doprecyzowuj je na krytycznych kartach sieciowych. Zawsze dokumentuj właściciela, cel i datę wygaśnięcia dla wszelkich „tymczasowych” zezwoleń.

Aplikacyjne Grupy Zabezpieczeń (ASG) pozwalają odwoływać się do grup maszyn wirtualnych po nazwie, a nie po adresie IP, dzięki czemu reguły pozostają aktualne mimo skalowania i zmian adresów IP. Oznaczaj maszyny wirtualne za pomocą ASG opartych na rolach (np. asg-web, asg-app) i wyrażaj polityki takie jak „asg-web → asg-app TCP 443”. Redukuje to rozrost liczby reguł i dryf operacyjny.

Efektywne reguły zabezpieczeń wynikają z połączenia NSG zastosowanych zarówno do karty sieciowej, jak i jej podsieci. Wygrywa najbardziej szczegółowa pasująca reguła zezwalająca/blokująca (według priorytetu). Weryfikuj konfigurację za pomocą opcji „Efektywne reguły zabezpieczeń” w portalu lub poprzez weryfikację przepływu IP w Network Watcher, aby wychwycić sprzeczne wpisy przed oknami wdrożeniowymi.

Tagi usług (np. AzureLoadBalancer, Storage, Sql, Internet, VirtualNetwork) są utrzymywane przez Microsoft i upraszczają duże, dynamiczne przestrzenie adresów IP do stabilnych celów dla reguł. Preferuj tagi usług zamiast ręcznych list IP, aby uniknąć przerw w działaniu spowodowanych rotacją adresów IP usług. Na przykład, ogranicz ruch wychodzący do usług Storage i Sql, jednocześnie blokując szeroki dostęp do Internetu.

Mikrosegmentacja i Zero Trust są realizowane przez:

Stosowanie NSG z domyślnym blokowaniem (deny-by-default) i otwieranie tylko jawnych, minimalnych ścieżek.
Używanie ASG do kodowania intencji obciążenia roboczego.
Ograniczanie ruchu wychodzącego za pomocą tagów usług lub filtrowania opartego na FQDN przez Azure Firewall.
Wymuszanie zasady „braku publicznych adresów IP na serwerach” i kierowanie całego ruchu wychodzącego przez kontrolowany punkt inspekcji.

Przykład: utwórz regułę NSG zezwalającą na komunikację z warstwy webowej do aplikacyjnej przez TLS z użyciem ASG i jawnie zablokuj wszystko inne z wyższym priorytetem niż niejawna reguła blokująca, aby udokumentować intencję.

az network nsg rule create \
  --resource-group rg-sec \
  --nsg-name nsg-app \
  --name allow-web-to-app-443 \
  --priority 200 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-asgs asg-web \
  --destination-asgs asg-app \
  --destination-port-ranges 443

Usługi Bezpieczeństwa Sieciowego i Ochrona Brzegowa

Azure Firewall to w pełni stanowy firewall o wysokiej dostępności z centralnym zarządzaniem politykami. Używaj go do:

Kontroli ruchu wschód-zachód i wychodzącego, gdy NSG są niewystarczające (nazwy domen, inspekcja TLS).
DNAT dla ograniczonej ekspozycji ruchu przychodzącego, gdy Application Gateway nie jest odpowiedni.
Centralnego logowania i analizy zagrożeń (threat intelligence).

Grupy kolekcji reguł zawierają kolekcje reguł (sieciowe, aplikacyjne, NAT) z priorytetami, które definiują kolejność ewaluacji. W obrębie grupy, kolekcje o niższym priorytecie są oceniane jako pierwsze; reguły są dopasowywane według najbardziej szczegółowych kryteriów. Trzymaj reguły DNAT w osobnej grupie z najwyższym priorytetem ewaluacji, aby deterministycznie przechwytywać ruch przychodzący.

Reguły sieciowe filtrują na podstawie 5-krotki (IP/port/protokół).
Reguły aplikacyjne filtrują na podstawie FQDN, kategorii URL (w wersji Premium) i mogą używać tagów FQDN.
Reguły NAT tłumaczą publiczne adresy/porty na prywatne dla scenariuszy przychodzących.

Filtrowanie oparte na analizie zagrożeń blokuje znane złośliwe adresy IP/domeny. Uruchom je w trybie Alert podczas wstępnego profilowania, a następnie przełącz na Deny po rozwiązaniu problemu fałszywych alarmów.

Funkcje Premium dodają:

Inspekcję TLS z deszyfracją ruchu wychodzącego i przychodzącego, umożliwiając widoczność w warstwie 7 i działanie IDPS.
System wykrywania i zapobiegania włamaniom (IDPS) z sygnaturami i priorytetyzacją podatności.
Filtrowanie URL i kategorie internetowe dla granularnej kontroli ruchu wychodzącego.
Zaawansowane kontrole certyfikatów i polityk TLS.

Operacyjnie, izoluj firewall w dedykowanej podsieci (AzureFirewallSubnet), kieruj do niego cały ruch internetowy za pomocą UDR (tras zdefiniowanych przez użytkownika) i włącz Strefy Dostępności. Używaj Firewall Policy (zamiast klasycznych reguł) do skalowalnej administracji, dziedziczenia i rozbieżności między środowiskami Dev/Test przy współdzielonej polityce bazowej.

Web Application Firewall (WAF) łagodzi ataki na warstwę 7 (SQLi, XSS).

Na Application Gateway, WAF chroni aplikacje regionalne z szyfrowaniem TLS end-to-end i politykami per witryna; kończy sesję TLS klienta i opcjonalnie ponownie szyfruje ruch do backendu.
Na Azure Front Door, WAF chroni globalnie rozproszone aplikacje na brzegu sieci, oferując zintegrowany CDN, ochronę przed botami i kontrole geograficzne.

Twórz polityki WAF i przypisuj je do bram, nasłuchów (listeners) lub tras. Początkowo wybierz tryb wykrywania (Detection), aby dostroić reguły, a następnie przełącz na tryb zapobiegania (Prevention), aby blokować ataki. Używaj zarządzanych zestawów reguł (OWASP 3.x) i dodawaj reguły niestandardowe dla limitów zapytań (rate limits) lub zakresów IP. Konfiguruj wykluczenia (np. dla określonych pól JSON lub nagłówków), aby zredukować fałszywe alarmy bez osłabiania ogólnej ochrony.

Rozproszona odmowa usługi (DDoS):

Basic to zawsze włączona ochrona platformy, ale nie oferuje telemetrii per zasób ani dostrajania mitygacji.
DDoS Protection: Network Protection dodaje adaptacyjne dostrajanie per publiczny adres IP, automatyczną mitygację, analitykę ataków, alerty, kredyt na pokrycie kosztów oraz dostęp do zespołu DDoS Rapid Response.

Włącz Network Protection na sieciach wirtualnych (VNet) hostujących publiczne adresy IP (w wersji Standard SKU). Używaj telemetrii (metryki, logi diagnostyczne) do obserwacji wektorów ataku, cyklu życia mitygacji i jej skuteczności. Projektuj chronione zasoby za load balancerami lub Application Gateway, aby absorbować obciążenie wolumetryczne i minimalizować bezpośrednią ekspozycję publiczną. Połącz WAF i DDoS dla obrony warstwowej.

Dostęp prywatny, łączność hybrydowa i routing

Usługi Private Link i prywatne punkty końcowe (private endpoints) zapewniają prywatny dostęp IP z Twojej sieci VNet do usług PaaS. Prywatny punkt końcowy to karta sieciowa (NIC) w Twojej podsieci, zmapowana na zasób PaaS; ruch pozostaje w sieci szkieletowej Microsoftu. Kroki operacyjne:

Wyłącz publiczny dostęp sieciowy na zasobie PaaS, aby zapobiec jego ominięciu.
Wdróż prywatne strefy DNS (np. privatelink.blob.core.windows.net) i połącz je z sieciami VNet, aby zapewnić płynne rozwiązywanie nazw.
Zarządzaj zatwierdzeniami centralnie; rozważ izolację subskrypcji/dzierżawy z ręcznym procesem zatwierdzania.

Punkty końcowe usługi (service endpoints) rozszerzają tożsamość Twojej podsieci na zasoby PaaS poprzez ich publiczne adresy IP, pozwalając zaporze PaaS na ograniczenie dostępu do określonych podsieci. Nie tworzą one prywatnych adresów IP, więc ruch wychodzący przechodzi przez publiczną krawędź sieci, ale pozostaje wewnątrz sieci Microsoft. Użyj zasad punktów końcowych usługi (service endpoint policies), aby zezwolić na dostęp tylko do zatwierdzonych kont magazynu. W przypadku obciążeń skonteneryzowanych na maszynach wirtualnych IaaS, upewnij się, że używany jest Azure CNI, aby adresy IP podów/kontenerów pochodziły z podsieci; w przeciwnym razie punkt końcowy usługi nie rozpozna źródła i dostęp może się nie powiodąć.

Strategia rozwiązywania nazw DNS:

Dla Private Link upewnij się, że Twoja ścieżka DNS rozwiązuje nazwę FQDN usługi PaaS na prywatny punkt końcowy. Użyj stref Azure Private DNS, warunkowych serwerów przesyłających dalej (conditional forwarders) w lokalnym DNS lub Azure DNS Private Resolver do przekazywania zapytań w środowisku hybrydowym.
Utrzymuj przejrzyste autorytatywne mapowania split-horizon, aby unikać sporadycznego rozwiązywania nazw na adresy publiczne.

Łączność hybrydowa:

VPN Gateway: Dla połączeń site-to-site używaj VPN opartego na trasach (route-based) z IKEv2 i silnymi szyframi. Używaj BGP do dynamicznej wymiany tras, co upraszcza rozbudowę i przełączanie awaryjne (failover). Zastosuj VPN NAT, gdy istnieją nakładające się przestrzenie adresowe. W przypadku tunelowania wymuszonego (forced tunneling) rozgłaszaj trasę 0.0.0.0/0 z lokalizacji on-premise przez BGP lub zastosuj trasy UDR wysyłające ruch 0/0 do wirtualnego urządzenia; w razie potrzeby zapewnij trasę wyjątku dla prywatnych zakresów PaaS.
ExpressRoute: Zapewnia prywatną łączność; szyfrowanie nie jest wbudowane. Użyj MACsec (dla ExpressRoute Direct) lub uruchom IPsec przez ER w celu zapewnienia poufności. Używaj społeczności BGP (BGP communities) i filtrów tras dla komunikacji równorzędnej Microsoft (Microsoft peering). Wspieraj konfigurację active-active z ECMP na obu obwodach dla zapewnienia odporności. W przypadku tunelowania wymuszonego akceptuj trasy domyślne z lokalizacji on-premise i upewnij się, że żadne konfliktowe trasy UDR nie tworzą czarnej dziury (blackhole) dla ścieżek internetowych.

Trasy zdefiniowane przez użytkownika (UDR), urządzenia NVA i pierwszeństwo:

Wybór trasy opiera się na najdłuższym dopasowaniu prefiksu (longest prefix match), a następnie na źródle: UDR > BGP > system. Błędnie zastosowane trasy UDR 0/0 mogą tworzyć czarną dziurę dla ścieżek powrotnych; zweryfikuj to za pomocą funkcji następnego skoku (next-hop) w Network Watcher.
Dla urządzeń NVA włącz przekazywanie IP (IP forwarding) na kartach sieciowych i umieść je za modułem równoważenia obciążenia (load balancer) lub Gateway Load Balancer w celu transparentnego i skalowalnego wstawiania. W scenariuszach zarządzanych preferuj Azure Firewall; gdy wymagane są funkcje specyficzne dla dostawcy, zaprojektuj wysoką dostępność (HA) z wieloma strefami dostępności i równoważeniem obciążenia opartym na sondach kondycji (health probes).

Bezpieczna administracja, monitorowanie i telemetria

Bezpieczna łączność administracyjna:

Azure Bastion zapewnia RDP/SSH przez TLS z portalu lub natywnego klienta bez wystawiania publicznych adresów IP maszyn wirtualnych. Użyj jednostki SKU Standard dla skalowalności, połączeń opartych na IP i linków do udostępniania. Ogranicz dostęp do Bastion za pomocą RBAC i Just-in-Time.
Dostęp Just-in-Time do maszyn wirtualnych (Defender for Cloud) zamyka porty zarządzania w grupach NSG i otwiera je na żądanie ograniczone czasowo, z zatwierdzeniem i limitami źródłowych adresów IP. Połącz z usługą Bastion, aby uzyskać architekturę bez publicznych adresów IP i precyzyjny ślad audytowy.

Network Watcher zapewnia weryfikację operacyjną i analizę powłamaniową (forensics):

Dzienniki przepływu NSG (v2) zapisują dane na koncie magazynu i mogą być wysyłane do Traffic Analytics w Log Analytics w celu uzyskania wglądu w najaktywniejszych komunikujących się (top talkers), dozwolone/odrzucone przepływy i dane geograficzne.
Narzędzie do rozwiązywania problemów z połączeniem (Connection troubleshoot) aktywnie testuje łączność end-to-end i raportuje, gdzie ścieżka jest zablokowana (NSG, UDR, DNS, firewall).
Przechwytywanie pakietów (Packet capture) może być uruchamiane na żądanie lub przez alerty; użyj buforów pierścieniowych, aby zmniejszyć zużycie magazynu i przechwytywać ruch tylko na istotnych portach.
Narzędzia Effective routes i IP flow verify mapują decyzje podejmowane w czasie rzeczywistym przez UDR, BGP i NSG; zautomatyzuj te kontrole w ramach testów wstępnych (preflight) w CI/CD.

Szybkie włączanie dzienników przepływu NSG i analityki:

az network watcher flow-log configure \
  --resource-group rg-sec \
  --nsg nsg-app \
  --enabled true \
  --traffic-analytics true \
  --storage-account saflowlogs \
  --workspace /subscriptions/<sub>/resourceGroups/rg-la/providers/Microsoft.OperationalInsights/workspaces/la-workspace

Praktyczny scenariusz problemowy

Firma Starbucks modernizuje platformę do zarządzania zamówieniami, przenosząc ją na platformę Azure. Cele bezpieczeństwa: brak publicznych adresów IP w warstwach aplikacji i danych, ścisła kontrola ruchu wychodzącego (egress), globalna ochrona aplikacji webowych i widoczność operacyjna.

Utwórz trzy podsieci w każdym regionie: web, app, data, każda z własną grupą NSG i grupami ASG dopasowanymi do roli.

Uzasadnienie: Mikrosegmentacja oparta na podsieciach z grupami ASG koduje przepływy o najniższych uprawnieniach (web→app 443, app→data 1433) i zmniejsza promień rażenia (blast radius). Oddzielne grupy NSG dla każdej warstwy pozwalają uniknąć przypadkowego powiązania polityk.

Wdróż usługę Azure Front Door Standard/Premium z polityką WAF w trybie Prevention, używając reguł OWASP 3.x i niestandardowych reguł do ograniczania liczby żądań (rate limiting) i restrykcji geograficznych.

Uzasadnienie: Globalna ochrona na brzegu sieci (edge) absorbuje ataki wolumetryczne, blokuje popularne ataki na warstwę 7, zanim dotrą do regionu, i zmniejsza opóźnienia dzięki anycast. Polityki WAF na brzegu sieci zapewniają spójne egzekwowanie zasad we wszystkich regionach.

Umieść Application Gateway z WAF v2 w każdym regionie przed warstwą web; zakończ szyfrowanie TLS na App Gateway i ponownie zaszyfruj ruch do backendu.

Uzasadnienie: Regionalny routing L7 i WAF uzupełniają Front Door, umożliwiając mTLS dla poszczególnych aplikacji do backendów, koligację opartą na plikach cookie (cookie-based affinity) i wdrożenia blue/green, zachowując jednocześnie możliwość inspekcji.

Włącz ochronę DDoS Protection: Network Protection na sieciach VNet zawierających publiczne adresy IP usługi Application Gateway.

Uzasadnienie: Adaptacyjna mitygacja na poziomie pojedynczego adresu IP, telemetria i ochrona kosztów zmniejszają ryzyko ataków wolumetrycznych wymierzonych w regionalne punkty wejścia. Zakres na poziomie VNet zapewnia, że wszystkie obecne i przyszłe publiczne adresy IP są chronione bez konieczności konfiguracji dla każdego zasobu.

Wdróż Azure Firewall Premium w zabezpieczonym hubie; przekieruj cały ruch wychodzący (egress) z podsieci aplikacji i danych do firewalla za pomocą UDR. Włącz inspekcję TLS i IDPS dla ruchu wychodzącego oraz skonfiguruj reguły aplikacji, aby zezwalać tylko na wymagane nazwy FQDN.

Uzasadnienie: Scentralizowana kontrola ruchu wychodzącego z deszyfrowaniem i wykrywaniem opartym na sygnaturach zapobiega komunikacji z serwerami command-and-control i eksfiltracji danych. Reguły aplikacji zmniejszają nakład pracy związany z utrzymaniem w porównaniu z regułami opartymi na IP i są zgodne z podejściem Zero Trust dla ruchu wychodzącego.

Użyj Private Link dla usług Azure SQL i Storage; wyłącz publiczny dostęp sieciowy i skonfiguruj prywatne strefy DNS połączone ze wszystkimi sieciami VNet. Dla obciążeń skonteneryzowanych użyj Azure CNI.

Uzasadnienie: Prywatne punkty końcowe (private endpoints) utrzymują ścieżki danych w sieci szkieletowej Azure i eliminują publiczną ekspozycję. Prywatny DNS zapewnia bezproblemowe rozwiązywanie nazw. Azure CNI gwarantuje, że adresy IP podów pochodzą z podsieci, dzięki czemu Private Link i punkty końcowe usług (service endpoints) działają poprawnie.

Ustanów połączenie ExpressRoute z podwójnymi obwodami w trybie active-active i rozgłaszaj trasy on-premise za pomocą BGP; włącz IPsec over ER dla wrażliwego ruchu. Początkowo nie rozgłaszaj trasy 0.0.0.0/0; najpierw przeprowadź pilotaż wymuszonego tunelowania (forced tunneling) w podsieci przejściowej (staging).

Uzasadnienie: ER zapewnia przewidywalną, prywatną łączność; warstwowe szyfrowanie chroni przepływy o wysokiej wrażliwości. Kontrolowane wdrażanie wymuszonego tunelowania zapobiega przypadkowemu odcięciu od internetu (internet blackholing) i pozwala zweryfikować trasy wyjątków.

Zapewnij dostęp administracyjny przez Azure Bastion i wymuś stosowanie Just-in-Time na wszystkich maszynach wirtualnych; usuń wszystkie publiczne adresy IP z serwerów.

Uzasadnienie: Eliminuje to wystawione na zewnątrz powierzchnie zarządzania, zachowując jednocześnie audytowalny, ograniczony czasowo dostęp zgodny z zasadą najniższych uprawnień.

Włącz dzienniki przepływu NSG i Traffic Analytics, skonfiguruj diagnostykę dla Firewall i WAF do wysyłania danych do Log Analytics oraz ustaw alerty dotyczące mitygacji DDoS i nagłych wzrostów blokad WAF.

Uzasadnienie: Ujednolicona telemetria umożliwia proaktywne wykrywanie, planowanie pojemności i szybką reakcję na incydenty. Alerty dotyczące anomalii pozwalają wcześnie wykrywać ataki i błędne konfiguracje.

Wdróż Azure Policy, aby blokować publiczne adresy IP na kartach sieciowych (NIC), wymagać grup NSG na wszystkich podsieciach i audytować sieci VNet bez włączonej ochrony DDoS; zintegruj sprawdzanie polityk z procesem CI/CD.

Uzasadnienie: Zapobiega to dryfowi konfiguracji (drift), wymusza stosowanie zabezpieczeń (guardrails) na dużą skalę i sprawia, że bezpieczne ustawienia domyślne są powtarzalne dla przyszłych obciążeń.

← Zarządzanie tożsamością i dostępem · Wszystkie domeny · Bezpieczeństwo Compute →

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