Microsoft AZ-700: Netzwerksicherheit — Lernleitfaden

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

Teil des Microsoft Azure Network Engineer AZ-700 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Netzwerkzugriffskontrolle: NSG- und ASG-Design, Routing und Peering

Network Security Groups (NSGs) bleiben der primäre, kostengünstige Mechanismus zum Filtern von Datenverkehr in und aus Subnetzen und NICs. NSGs sind zustandsbehaftet, können auf Dienst-Tags (z. B. Internet, Storage) verweisen und unterstützen Application Security Groups (ASGs), um VM-NICs zu gruppieren und die Regelwartung für große Flotten zu skalieren. Wenden Sie NSGs auf Subnetzebene für eine grobe Segmentierung und auf NIC-Ebene für hostspezifische Ausnahmen an; denken Sie daran, dass beide ausgewertet werden und der restriktivste effektive Regelsatz zur Anwendung kommt. Häufige Fallstricke sind das Vergessen der Standardregeln (Verweigern/Zulassen-Systemregeln mit hohen Prioritäten), eine falsche Reihenfolge der Prioritäten (NSG-Regelprioritäten reichen von 100 bis 4096; Systemstandards liegen bei 65.000+) und die Annahme, dass NSGs IDS/Antivirus-Funktionen bieten – sie inspizieren keine Payloads. Beim Peering von virtuellen Netzwerken steuern NSGs weiterhin den Datenverkehr zwischen den Peers, aber UDRs (benutzerdefinierte Routen) können Systemrouten überschreiben und unbeabsichtigt Datenverkehr in ein „Blackhole“ leiten, wenn ein „Next Hop“ (zum Beispiel zu einer Azure Firewall) in diesem Kontext nicht erreichbar ist. Design-Abwägungen stellen die Kosten und Einfachheit von NSGs/ASGs der Sichtbarkeit und den erweiterten Kontrollen einer zentralen Firewall gegenüber: NSGs sind günstig und performant für eine grobe Filterung; verwenden Sie eine verwaltete Firewall für zentralisierte Protokollierung, DNAT/NAT-Steuerung und Richtlinien auf Anwendungsebene.

Perimeter- und Ost-West-Kontrollen: Azure Firewall, DNAT, Anwendungsregeln und IDPS

Azure Firewall bietet einen verwalteten, zustandsbehafteten Perimeter, der DNAT, SNAT und Regeln auf Anwendungsebene beherrscht. Architektieren Sie sie in einem dedizierten AzureFirewallSubnet und verwenden Sie Routingtabellen, um den Ost-West-Datenverkehr in einer Hub-Spoke-Topologie zur Überprüfung durch die Firewall zu leiten. Verwenden Sie DNAT-Sammlungen, um interne Dienste zu veröffentlichen: Geben Sie Quellbereiche, Ziel-IP, Zielports und die übersetzte IP:Port an. Anwendungsregelsammlungen ermöglichen es Ihnen, Datenverkehr für HTTP/S nach FQDN zu erlauben (z. B. *.microsoft.com), was fehleranfällige IP-Allow-Listen vermeidet. Für Deep Packet Inspection und die Überprüfung von verschlüsseltem Datenverkehr fügt Azure Firewall Premium eine IDPS-Engine und TLS-Inspektion hinzu, was mit höheren Kosten und betrieblicher Komplexität für die Zertifikatsverwaltung und potenzieller Latenz verbunden ist. NVAs von Drittanbietern bleiben eine valide Wahl, wenn Sie spezielle Signaturen oder Leistungsmerkmale benötigen. Entscheidungen zur Skalierung und Ausfallsicherheit umfassen die Verwendung von Firewall-Autoscaling (v2) oder zonenredundanten Bereitstellungen im Vergleich zu festen Instanzen: Autoscaling entschärft Engpässe beim Durchsatz, ist aber teurer. Überwachen Sie Firewall-Metriken und -Protokolle in Log Analytics, um eine Erschöpfung von DNAT/SNAT zu erkennen und bei Bedarf die Regelreihenfolge und die Anzahl der öffentlichen IPs anzupassen.

Azure Firewall Standard: Zustandsbehaftete L3–L7-Filterung, NAT/DNAT, Anwendungs- und Netzwerkregeln, verwalteter Dienst mit Autoscaling-Optionen und integrierter Protokollierung.
Azure Firewall Premium: Beinhaltet die Standard-Funktionen sowie IDPS, TLS-Inspektion, erweiterte Threat Intelligence und URL-Filterung; höhere Kosten und erfordert Zertifikats-/Schlüsselverwaltung für die TLS-Inspektion.

Schutz auf Anwendungsebene, Private Link und DDoS

Schützen Sie Webanwendungen am Edge mit WAFs und verteilten Edge-Diensten. Application Gateway WAF_v2 bietet eine regionale WAF mit Integration in ein VNet und ist ideal, wenn die Backends privat sind (App Service mit ASE oder VMs). Azure Front Door (Edge) bietet globales Load Balancing und eine WAF am CDN-Edge und reduziert die Latenz für globale Clients; wählen Sie Front Door für globales Failover und Application Gateway für den Schutz regionaler privater Backends. Der DDoS-Schutz (Basic ist inbegriffen) sollte auf DDoS Protection Standard hochgestuft werden, wenn öffentliche IPs wichtige Dienste hosten; dieser erstellt automatisch Profile des Datenverkehrs und entschärft volumetrische Angriffe für Ressourcen in einem geschützten virtuellen Netzwerk. Für den privaten Zugriff stellen Private Link/Private Endpoints eine private IP in Ihrem VNet für Plattformdienste bereit, wodurch die öffentliche Erreichbarkeit eliminiert wird. Häufige Fallstricke sind das Vergessen, den öffentlichen Netzwerkzugriff auf der PaaS-Ressource zu deaktivieren, die falsche Handhabung der privaten DNS-Integration (Sie müssen privatelink-Zonen besitzen und zuordnen oder bedingte Weiterleitungen konfigurieren) und die Erwartung, dass Edge-WAFs private Endpunkte ohne einen regionalen Proxy erreichen; oft leitet ein kleiner, gehärteter Reverse-Proxy (Application Gateway oder Firewall) in einem Perimeter-Subnetz den Datenverkehr von der Front Door zum privaten Endpunkt.

Betriebskontrollen: Protokollierung, Richtlinien, Überwachung und häufige Fallstricke für Engineers

Betriebshygiene ist oft das Unterscheidungsmerkmal zwischen sicheren und anfälligen Netzwerkumgebungen. Aktivieren Sie NSG Flow Logs (v2) und die Diagnosedaten der Azure Firewall in einem zentral verwalteten Log Analytics-Arbeitsbereich und verbinden Sie diese mit Azure Monitor und Sentinel für Analysen, Bedrohungssuche und Warnmeldungen. Verwenden Sie Traffic Analytics für aggregierte Topologie, Top-Talker und Flow-Anomalien; denken Sie daran, dass Traffic Analytics Network Watcher und einen Log Analytics-Arbeitsbereich in derselben Region erfordert. Für hybride Verbindungen bieten Network Performance Monitor (NPM) und Connection Monitor periodische Latenz-, Jitter- und Pfad-Zustandsdaten, die helfen, SLAs für ExpressRoute und SD-WAN nachzuweisen. Setzen Sie Leitplanken mit Azure Policy durch: schreiben Sie eine Azure Firewall in Hubs vor, verbieten Sie die Erstellung öffentlicher IPs für rein private Ressourcen und auditieren Sie die Prioritätsbereiche von NSG-Regeln oder nicht getaggte Regeln. Häufige Fallstricke sind die Routenpräzedenz (UDR überschreibt Systemrouten), die SNAT-Port-Erschöpfung, wenn viele Verbindungen über eine einzige öffentliche IP-Adresse ausgehen (zu entschärfen durch Hinzufügen öffentlicher IPs oder die Nutzung von Firewall-Autoscaling), und Anforderungen an die Benennung von Subnetzen (AzureFirewallSubnet muss für die Firewall existieren). Entscheidungen über Resilienz im Vergleich zu Kosten sind iterativ: Zentralisieren Sie die Inspektion für die Sichtbarkeit, aber lokalisieren Sie sie für latenzempfindliche Pfade und nutzen Sie Autoscaling/zonale Redundanz, wo Workloads kritisch sind.

Praktisches Problem: Anwendungsfallszenario

Szenario: Contoso Ltd. betreibt ein Hub-and-Spoke-Azure-Netzwerk, das sich über zwei Regionen erstreckt, mit einem zentralen Hub-VNet, das eine zonale Azure Firewall und gemeinsam genutzte Dienste enthält. Zweigstellen verbinden sich über SD-WAN BGP mit regionalen Hubs. Mehrere PaaS-Web-Apps verwenden private Endpunkte in Spoke-VNets.

Herausforderung: Internetkunden müssen für globales Routing auf eine öffentliche Front Door zugreifen können, aber der Backend-Traffic der Web-App muss an privaten Endpunkten enden, und aller ausgehende Datenverkehr von den Spokes muss inspiziert und protokolliert werden, ohne PaaS-Ressourcen öffentlich preiszugeben.

Empfohlener Ansatz:

Stellen Sie Azure Front Door Standard/Premium als globalen öffentlichen Einstiegspunkt bereit und binden Sie ein regionales Application Gateway in jedem Hub als privaten Ursprung an, oder verwenden Sie Front Door Premium mit einer sicheren Konfiguration für private Ursprünge, wo dies unterstützt wird.
Platzieren Sie ein Application Gateway v2 im Subnetz des Hub-VNets (dediziert pro AGW) und konfigurieren Sie es so, dass der Datenverkehr über VNet-Peering an den App Service Private Endpoint weitergeleitet wird; aktivieren Sie WAF_v2 auf dem Application Gateway und weisen Sie eine verwaltete WAF-Richtlinie zu.
Leiten Sie den gesamten ausgehenden Datenverkehr der Spokes über die Azure Firewall Premium im Hub (in AzureFirewallSubnet) mithilfe von UDRs auf den Spokes; aktivieren Sie DNAT-Regeln für erforderliche eingehende Übersetzungen und Anwendungsregeln für ausgehenden FQDN-Verkehr; aktivieren Sie IDPS und TLS-Inspektion auf der Premium-SKU für die Sichtbarkeit von verschlüsseltem Datenverkehr.
Zentralisieren Sie Protokolle in einem Log Analytics-Arbeitsbereich, aktivieren Sie NSG Flow Logs und Traffic Analytics, aktivieren Sie DDoS Protection Standard auf den öffentlichen IPs des Hubs und setzen Sie die Architektur mit Azure Policy durch (Firewall vorschreiben, öffentlichen Netzwerkzugriff auf PaaS verbieten).

Begründung: Front Door bietet globale Verfügbarkeit und geringe Latenz, Application Gateway mit WAF_v2 sichert private Backends, und Azure Firewall Premium bietet zentralisierte Inspektion, DNAT und IDPS für sowohl ausgehenden als auch eingehenden Datenverkehr. Zentralisierte Protokollierung und Richtliniendurchsetzung gewährleisten Sichtbarkeit und Compliance, während die PaaS-Endpunkte privat bleiben.

← Azure DNS · Alle Domänen · Lastenausgleich →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →