Microsoft AZ-700: Bezpieczeństwo sieciowe — Przewodnik do nauki

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

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

Kontrola dostępu do sieci: projektowanie NSG i ASG, routing i peering

Sieciowe grupy zabezpieczeń (NSG) pozostają podstawowym, tanim mechanizmem filtrowania ruchu przychodzącego i wychodzącego z podsieci i kart sieciowych (NIC). NSG są stanowe, mogą odwoływać się do tagów usług (np. Internet, Storage) i obsługują aplikacyjne grupy zabezpieczeń (ASG) do grupowania kart sieciowych maszyn wirtualnych i skalowania zarządzania regułami dla dużych flot. Stosuj NSG na poziomie podsieci dla szerokiej segmentacji oraz na poziomie karty sieciowej dla wyjątków specyficznych dla hosta; pamiętaj, że obie są ewaluowane i obowiązuje najbardziej restrykcyjny zestaw reguł. Częste pułapki to zapominanie o domyślnych regułach (systemowe reguły deny/allow o wysokich priorytetach), błędne ustawienie priorytetów (priorytety reguł NSG mieszczą się w zakresie od 100 do 4096; domyślne systemowe mają wartości 65 000+) oraz zakładanie, że NSG zapewniają funkcje IDS/antywirusowe — nie inspekcjonują one zawartości pakietów. Podczas komunikacji równorzędnej (peeringu) sieci wirtualnych, NSG nadal zarządzają ruchem między nimi, ale trasy zdefiniowane przez użytkownika (UDR) mogą nadpisywać trasy systemowe i nieumyślnie powodować czarną dziurę dla ruchu, jeśli następny skok (np. do Azure Firewall) jest w danym kontekście nieosiągalny. Kompromisy projektowe polegają na zważeniu kosztu i prostoty NSG/ASG w stosunku do widoczności i zaawansowanych kontroli centralnego firewalla: NSG są tanie i wydajne do zgrubnego filtrowania; użyj zarządzanego firewalla do centralnego logowania, kontroli DNAT/NAT i polityk warstwy aplikacji.

Kontrole na brzegu sieci i ruch wschód-zachód: Azure Firewall, DNAT, reguły aplikacyjne i IDPS

Azure Firewall zapewnia zarządzany, stanowy firewall na brzegu sieci, zdolny do obsługi DNAT, SNAT i reguł warstwy aplikacji. Zaprojektuj go w dedykowanej podsieci AzureFirewallSubnet i użyj tabel routingu, aby kierować ruch wschód-zachód w architekturze hub-spoke przez firewall w celu inspekcji. Użyj kolekcji reguł DNAT do publikowania usług wewnętrznych: określ zakresy źródłowe, docelowy adres IP, porty docelowe oraz przetłumaczony adres IP i port. Kolekcje reguł aplikacyjnych pozwalają na zezwalanie na ruch na podstawie FQDN dla HTTP/S (np. *.microsoft.com), co pozwala uniknąć kruchych list dozwolonych adresów IP. Do głębokiej inspekcji pakietów i inspekcji ruchu szyfrowanego, Azure Firewall Premium dodaje silnik IDPS i inspekcję TLS, co wiąże się z wyższym kosztem, złożonością operacyjną w zarządzaniu certyfikatami i potencjalnymi opóźnieniami. Urządzenia wirtualne (NVA) firm trzecich pozostają dobrym wyborem, gdy potrzebujesz specjalistycznych sygnatur lub określonej charakterystyki wydajności. Decyzje dotyczące skali i odporności obejmują użycie automatycznego skalowania Firewall (v2) lub wdrożeń nadmiarowych strefowo w porównaniu do stałych instancji: automatyczne skalowanie łagodzi ograniczenia przepustowości, ale jest droższe. Monitoruj metryki i logi firewalla w Log Analytics, aby wykrywać wyczerpanie puli DNAT/SNAT i w razie potrzeby dostosowywać kolejność reguł oraz liczbę publicznych adresów IP.

Azure Firewall Standard: stanowe filtrowanie L3–L7, NAT/DNAT, reguły aplikacyjne i sieciowe, usługa zarządzana z opcjami autoskalowania i zintegrowanym logowaniem.
Azure Firewall Premium: zawiera funkcje wersji Standard oraz IDPS, inspekcję TLS, zaawansowaną analitykę zagrożeń i filtrowanie URL; wyższy koszt i wymaga zarządzania certyfikatami/kluczami do inspekcji TLS.

Ochrona warstwy aplikacji, Private Link i DDoS

Chroń aplikacje internetowe na brzegu sieci za pomocą WAF i rozproszonych usług brzegowych. Application Gateway WAF_v2 zapewnia regionalny WAF z integracją z siecią VNet i jest idealny, gdy backendy są prywatne (App Service z ASE lub maszyny wirtualne). Azure Front Door (brzeg sieci) zapewnia globalne równoważenie obciążenia i WAF na brzegu sieci CDN oraz zmniejsza opóźnienia dla klientów globalnych; wybierz Front Door do globalnego przełączania awaryjnego (failover) i App Gateway do regionalnej ochrony prywatnych backendów. Ochronę DDoS (wersja Basic wliczona w cenę) należy zaktualizować do DDoS Protection Standard, gdy publiczne adresy IP hostują ważne usługi; automatycznie profiluje ona ruch i łagodzi ataki wolumetryczne na zasoby w chronionej sieci wirtualnej. Dla dostępu prywatnego, Private Link/Prywatne punkty końcowe (Private Endpoints) zapewniają prywatny adres IP w Twojej sieci VNet dla usług platformy, eliminując ich publiczną ekspozycję. Częste pułapki to zapominanie o wyłączeniu publicznego dostępu sieciowego do zasobu PaaS, nieprawidłowa obsługa integracji z prywatnym DNS (musisz posiadać i mapować strefy privatelink lub skonfigurować warunkowe usługi przesyłania dalej) oraz oczekiwanie, że brzegowe WAF dotrą do prywatnych punktów końcowych bez regionalnego proxy; często mały, wzmocniony odwrotny serwer proxy (Application Gateway lub Firewall) w podsieci brzegowej kieruje ruch z Front Door do prywatnego punktu końcowego.

Kontrole operacyjne: logowanie, zasady, monitorowanie i typowe pułapki inżynierskie

Higiena operacyjna jest często czynnikiem odróżniającym bezpieczne środowiska sieciowe od tych kruchych i podatnych na awarie. Włącz NSG Flow Logs (v2) i diagnostykę Azure Firewall do centralnie zarządzanego obszaru roboczego Log Analytics i połącz je z Azure Monitor oraz Sentinel w celu analizy, wyszukiwania zagrożeń (threat hunting) i generowania alertów. Użyj Traffic Analytics do analizy zagregowanej topologii, identyfikacji głównych źródeł ruchu (top talkers) i anomalii w przepływach; pamiętaj, że Traffic Analytics wymaga usług Network Watcher i Log Analytics w tym samym regionie. Dla połączeń hybrydowych, Network Performance Monitor (NPM) i Connection Monitor zapewniają okresowe pomiary opóźnień (latency), wahań opóźnień (jitter) i kondycji ścieżki, co pomaga weryfikować umowy SLA dla ExpressRoute i SD‑WAN. Wymuszaj bariery ochronne (guardrails) za pomocą Azure Policy: wymagaj obecności Azure Firewall w hubach, blokuj tworzenie publicznych adresów IP dla zasobów wyłącznie prywatnych oraz przeprowadzaj inspekcję zakresów priorytetów reguł NSG lub reguł bez tagów. Typowe pułapki obejmują pierwszeństwo tras (UDR nadpisuje trasy systemowe), wyczerpanie portów SNAT, gdy wiele połączeń wychodzących przechodzi przez jeden publiczny adres IP (można to złagodzić, dodając publiczne adresy IP lub używając autoskalowania zapory), oraz wymagania dotyczące nazewnictwa podsieci (dla zapory musi istnieć podsieć o nazwie AzureFirewallSubnet). Decyzje dotyczące odporności w stosunku do kosztów mają charakter iteracyjny: centralizuj inspekcję w celu zapewnienia widoczności, ale lokalizuj ją dla ścieżek wrażliwych na opóźnienia i używaj autoskalowania/redundancji strefowej tam, gdzie obciążenia robocze są krytyczne.

Problem praktyczny: Scenariusz użycia

Scenariusz: Firma Contoso Ltd. zarządza siecią Azure w topologii hub-and-spoke, obejmującą dwa regiony z centralną siecią VNet (hub) zawierającą strefową zaporę Azure Firewall i usługi współdzielone. Oddziały firmy łączą się za pomocą SD‑WAN BGP z regionalnymi hubami. Kilka aplikacji internetowych PaaS korzysta z prywatnych punktów końcowych (private endpoints) w sieciach VNet typu spoke.

Wyzwanie: Klienci z internetu muszą mieć dostęp do publicznego punktu wejścia (front door) w celu globalnego routingu, ale ruch backendowy aplikacji internetowych musi kończyć się na prywatnych punktach końcowych, a cały ruch wychodzący (egress) z sieci spoke musi być inspekcjonowany i logowany bez publicznego udostępniania zasobów PaaS.

Zalecane podejście:

Wdróż Azure Front Door Standard/Premium jako globalny publiczny punkt wejścia i dołącz regionalną bramę Application Gateway w każdym hubie jako prywatne źródło (private origin) lub użyj Front Door Premium z bezpieczną konfiguracją prywatnego źródła, jeśli jest to wspierane.
Umieść Application Gateway v2 w podsieci VNet huba (dedykowanej dla każdej bramy AGW) i skonfiguruj ją tak, aby przekierowywała ruch do App Service Private Endpoint poprzez VNet peering; włącz WAF_v2 na Application Gateway i powiąż z nią zarządzaną politykę WAF.
Przekieruj cały ruch wychodzący z sieci spoke przez zaporę Azure Firewall Premium w hubie (w podsieci AzureFirewallSubnet) za pomocą tras UDR w sieciach spoke; włącz reguły DNAT dla wymaganych translacji przychodzących oraz reguły aplikacji dla ruchu wychodzącego opartego na FQDN; włącz inspekcję IDPS i TLS w wersji Premium SKU, aby uzyskać wgląd w zaszyfrowany ruch.
Scentralizuj logi w obszarze roboczym Log Analytics, włącz NSG Flow Logs i Traffic Analytics, aktywuj DDoS Protection Standard na publicznych adresach IP huba i wymuś architekturę za pomocą Azure Policy (wymagaj zapory Firewall, blokuj publiczny dostęp sieciowy do usług PaaS).

Uzasadnienie: Front Door zapewnia globalną dostępność i niskie opóźnienia, Application Gateway z WAF_v2 zabezpiecza prywatne backendy, a Azure Firewall Premium oferuje scentralizowaną inspekcję, DNAT i IDPS zarówno dla ruchu wychodzącego (egress), jak i przychodzącego (ingress). Scentralizowane logowanie i egzekwowanie zasad zapewniają widoczność i zgodność, jednocześnie utrzymując prywatność punktów końcowych PaaS.

← Azure DNS i rozwiązywanie nazw · Wszystkie domeny · Równoważenie obciążenia i zarządzanie ruchem →

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