Microsoft AZ-500: Netzwerksicherheitsarchitektur — Lernleitfaden

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

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

Überblick

Die Azure-Netzwerksicherheitsarchitektur erzwingt Konnektivität nach dem Least-Privilege-Prinzip, geht von einer Kompromittierung aus (Assume Breach) und instrumentiert eine kontinuierliche Überwachung. Sie kombiniert Mikrosegmentierung innerhalb virtueller Netzwerke, zustandsbehaftete Steuerungsebenen für Ost-West- und Egress-Traffic, Edge-Schutz für Endpunkte mit Internetzugang und privaten Zugriff auf PaaS. Solide Architekturen priorisieren den identitätsbasierten Zugriff auf der Anwendungsebene, während sie starke Netzwerkgrenzen, explizites Routing und verifizierbare Telemetrie beibehalten.

Steuerelemente und Segmentierung für virtuelle Netzwerke

Subnetze sind die erste Segmentierungsgrenze. Platzieren Sie Workloads mit ähnlicher Vertrauensstellung, ähnlichem Lebenszyklus und ähnlichen Richtlinien im selben Subnetz; trennen Sie die Tiers (Web, App, Daten), damit Sie unabhängige Richtlinien und Routen anwenden können. Vermeiden Sie flache, „gemeinsam genutzte“ Subnetze, die Admin-Tools, Jump-Hosts und geschäftliche Workloads vermischen; sie verkomplizieren die Richtlinien und vergrößern den „Blast Radius“ (Schadensradius).

Network Security Groups (NSGs) wenden eine zustandsbehaftete L3–L4-Filterung pro Subnetz oder pro NIC an. Eingehende und ausgehende Regeln werden nach Priorität ausgewertet (niedrigere Zahl zuerst), mit einem impliziten DenyAll am Ende. NSGs sind zustandsbehaftet (stateful): Antworten auf erlaubte Datenflüsse werden automatisch zugelassen, sodass Sie selten Regeln für ephemere Ports benötigen. Binden Sie NSGs im Betrieb an Subnetze für allgemeine Kontrollen und verfeinern Sie diese dann auf kritischen NICs. Dokumentieren Sie immer den Besitzer, den Zweck und das Ablaufdatum für alle „temporären“ Freigaben.

Application Security Groups (ASGs) ermöglichen es Ihnen, VM-Gruppen über den Namen statt über die IP-Adresse zu referenzieren, sodass Regeln Skalierungen und IP-Wechsel überdauern. Verschlagworten (taggen) Sie VMs in rollenbasierte ASGs (z. B. asg-web, asg-app) und formulieren Sie Richtlinien wie „asg-web → asg-app TCP 443“. Dies reduziert die Ausuferung von Regeln und die betriebliche Abweichung (Operational Drift).

Effektive Sicherheitsregeln ergeben sich aus der Zusammenführung von NSGs, die sowohl auf eine NIC als auch auf deren Subnetz angewendet werden. Die spezifischste passende Allow/Deny-Regel (nach Priorität) gewinnt. Validieren Sie mit „Effektive Sicherheitsregeln“ im Portal oder über den Network Watcher IP Flow Verify, um widersprüchliche Einträge vor den Deployment-Fenstern zu erkennen.

Service-Tags (z. B. AzureLoadBalancer, Storage, Sql, Internet, VirtualNetwork) werden von Microsoft gepflegt und fassen große, dynamische IP-Bereiche zu stabilen Regelzielen zusammen. Bevorzugen Sie Service-Tags gegenüber manuellen IP-Listen, um Ausfälle bei der Rotation von Dienst-IPs zu vermeiden. Beschränken Sie beispielsweise den Egress-Traffic auf Storage und Sql, während Sie den allgemeinen Internetzugang verweigern.

Mikrosegmentierung und Zero Trust werden realisiert durch:

• Anwendung von Deny-by-Default-NSGs und Öffnung nur expliziter, minimaler Pfade.
• Verwendung von ASGs, um die Absicht des Workloads zu kodieren.
• Einschränkung des Egress-Traffics mit Service-Tags oder FQDN-basierter Filterung über die Azure Firewall.
• Erzwingung von „keine öffentliche IP auf Servern“ und Weiterleitung des gesamten Egress-Traffics durch einen kontrollierten Inspektionspunkt.

Beispiel: Erstellen Sie eine NSG-Regel, die Web-zu-App-Kommunikation über TLS mit ASGs erlaubt und alles andere explizit mit einer höheren Priorität als die implizite Deny-Regel verweigert, um die Absicht zu dokumentieren.

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

Netzwerksicherheitsdienste und Edge-Schutz

Azure Firewall ist eine vollständig zustandsbehaftete, hochverfügbare Firewall mit zentraler Richtlinienverwaltung. Verwenden Sie sie für:

• Ost-West- und Egress-Kontrolle, wenn NSGs nicht ausreichen (Domain-Namen, TLS-Inspektion).
• DNAT für begrenzte eingehende Erreichbarkeit, wenn Application Gateway ungeeignet ist.
• Zentrales Logging und Threat Intelligence.

Regelsammlungsgruppen (Rule Collection Groups) enthalten Regelsammlungen (Network, Application, NAT) mit Prioritäten, die die Auswertungsreihenfolge definieren. Innerhalb einer Gruppe werden Sammlungen mit niedrigerer Priorität zuerst ausgewertet; Regeln werden nach den spezifischsten Kriterien abgeglichen. Bewahren Sie DNAT-Regeln in ihrer eigenen Gruppe mit der höchsten Auswertungspriorität auf, um eingehenden Verkehr deterministisch zu erfassen.

• Netzwerkregeln filtern nach 5-Tupel (IP/Port/Protokoll).
• Anwendungsregeln filtern nach FQDN, URL-Kategorien (Premium) und können FQDN-Tags verwenden.
• NAT-Regeln übersetzen öffentliche in private Adressen/Ports für eingehende Szenarien.

Threat-Intelligence-basierte Filterung blockiert bekannte bösartige IPs/Domains. Führen Sie sie während des anfänglichen Baselining im Modus „Alert“ (Warnung) aus und wechseln Sie dann zu „Deny“ (Verweigern), sobald False Positives behoben sind.

Premium-Funktionen fügen hinzu:

• TLS-Inspektion mit Entschlüsselung für ausgehenden und eingehenden Verkehr, was L7-Sichtbarkeit und IDPS ermöglicht.
• Intrusion Detection and Prevention (IDPS) mit Signaturen und Priorisierung von Schwachstellen.
• URL-Filterung und Web-Kategorien für eine granulare Egress-Kontrolle.
• Erweiterte Zertifikats- und TLS-Richtlinienkontrollen.

Isolieren Sie die Firewall im Betrieb in einem dedizierten Subnetz (AzureFirewallSubnet), leiten Sie den gesamten internetgebundenen Verkehr mit UDRs dorthin und aktivieren Sie Availability Zones. Verwenden Sie Firewall Policy (nicht die klassischen Regeln) für eine skalierbare Verwaltung, Vererbung und Abweichungen für Dev/Test mit einer gemeinsamen Basisrichtlinie.

Die Web Application Firewall (WAF) wehrt L7-Angriffe (SQLi, XSS) ab.

• Auf dem Application Gateway schützt die WAF regionale Apps mit End-to-End-TLS und standortspezifischen Richtlinien; sie terminiert das Client-TLS und verschlüsselt optional erneut zum Backend.
• Auf Azure Front Door schützt die WAF global verteilte Anwendungen am Edge mit integriertem CDN, Bot-Schutz und Geo-Kontrollen.

Erstellen Sie WAF-Richtlinien und weisen Sie sie Gateways, Listenern oder Routen zu. Wählen Sie anfangs den Modus „Detection“ (Erkennung) zur Feinabstimmung und dann „Prevention“ (Verhinderung) zum Blockieren. Verwenden Sie verwaltete Regelsätze (OWASP 3.x) und fügen Sie benutzerdefinierte Regeln für Ratenbegrenzungen oder IP-Bereiche hinzu. Konfigurieren Sie Ausschlüsse (z. B. für bestimmte JSON-Felder oder Header), um False Positives zu reduzieren, ohne den Gesamtschutz zu schwächen.

Distributed Denial of Service (DDoS):

• Basic ist ein ständig aktiver Plattformschutz, bietet aber keine ressourcenspezifische Telemetrie oder Anpassung der Abwehrmaßnahmen.
• DDoS Protection: Network Protection fügt adaptive Anpassung pro öffentlicher IP, automatische Abwehr, Angriffsanalysen, Benachrichtigungen, eine Gutschrift zum Kostenschutz und Zugriff auf den DDoS Rapid Response hinzu.

Aktivieren Sie Network Protection auf VNets, die öffentliche IPs (Standard-SKU) hosten. Nutzen Sie Telemetriedaten (Metriken, Diagnoseprotokolle), um Angriffsvektoren, den Lebenszyklus der Abwehrmaßnahmen und deren Wirksamkeit zu beobachten. Architektieren Sie geschützte Ressourcen hinter Load Balancern oder einem Application Gateway, um volumetrische Lasten abzufangen, und minimieren Sie die direkte öffentliche Erreichbarkeit. Kombinieren Sie WAF und DDoS für eine mehrschichtige Verteidigung (Layered Defense).

Privater Zugriff, hybride Konnektivität und Routing

Private Link und private Endpunkte ermöglichen den privaten IP-Zugriff von Ihrem VNet auf PaaS-Dienste. Ein privater Endpunkt ist eine NIC in Ihrem Subnetz, die der PaaS-Ressource zugeordnet ist; der Datenverkehr verbleibt im Microsoft-Backbone. Operative Schritte:

• Deaktivieren Sie den öffentlichen Netzwerkzugriff auf der PaaS-Ressource, um eine Umgehung zu verhindern.
• Stellen Sie private DNS-Zonen (z. B.

undefined

) bereit und verknüpfen Sie diese mit VNets für eine nahtlose Namensauflösung.

• Verwalten Sie Genehmigungen zentral; ziehen Sie eine Abonnement-/Mandanten-Isolation mit einem manuellen Genehmigungsworkflow in Betracht.

Dienstendpunkte erweitern die Identität Ihres Subnetzes auf PaaS-Ressourcen über deren öffentliche IPs, sodass die PaaS-Firewall den Zugriff auf bestimmte Subnetze beschränken kann. Sie erstellen keine privaten IPs, sodass der ausgehende Datenverkehr den öffentlichen Rand passiert, aber innerhalb des Microsoft-Netzwerks verbleibt. Verwenden Sie Dienstendpunktrichtlinien, um nur genehmigte Speicherkonten zuzulassen. Stellen Sie bei containerisierten Workloads auf IaaS-VMs sicher, dass Azure CNI verwendet wird, damit die Pod-/Container-IPs aus dem Subnetz stammen; andernfalls erkennt der Dienstendpunkt die Quelle nicht und der Zugriff kann fehlschlagen.

Strategie für die DNS-Auflösung:

• Stellen Sie bei Private Link sicher, dass Ihr DNS-Pfad den PaaS-FQDN zum privaten Endpunkt auflöst. Verwenden Sie Azure Private DNS-Zonen, bedingte Weiterleitungen auf dem lokalen DNS oder Azure DNS Private Resolver für die hybride Weiterleitung.
• Halten Sie autoritative Split-Horizon-Mappings eindeutig, um eine zeitweilige öffentliche Auflösung zu vermeiden.

Hybride Konnektivität:

• VPN Gateway: Verwenden Sie für Site-to-Site ein routenbasiertes VPN mit IKEv2 und starken Verschlüsselungen. Nutzen Sie BGP, um Routen dynamisch auszutauschen, was das Wachstum und Failover vereinfacht. Wenden Sie VPN NAT an, wenn sich Adressräume überschneiden. Für Forced Tunneling kündigen Sie 0.0.0.0/0 von On-Premises über BGP an oder wenden Sie UDRs an, die 0/0 an eine virtuelle Appliance senden; stellen Sie bei Bedarf eine Ausnahmeroute für private PaaS-Bereiche sicher.
• ExpressRoute: Bietet private Konnektivität; Verschlüsselung ist nicht inhärent. Verwenden Sie MACsec (für ExpressRoute Direct) oder führen Sie IPsec über ER aus, um die Vertraulichkeit zu gewährleisten. Nutzen Sie BGP-Communities und Routenfilter für das Microsoft-Peering. Unterstützen Sie Aktiv/Aktiv mit ECMP über Leitungen hinweg für Resilienz. Akzeptieren Sie für Forced Tunneling Standardrouten von On-Premises und stellen Sie sicher, dass keine widersprüchlichen UDRs Internetpfade in ein Blackhole leiten.

Benutzerdefinierte Routen (UDRs), NVAs und Vorrang:

• Die Routenauswahl verwendet die längste Präfixübereinstimmung (Longest Prefix Match), dann die Quelle: UDR > BGP > System. Falsch angewendete 0/0-UDRs können Rückgabepfade in ein Blackhole leiten; validieren Sie dies mit der Next-Hop-Funktion von Network Watcher.
• Aktivieren Sie bei NVAs die IP-Weiterleitung auf den NICs und platzieren Sie sie hinter einem Load Balancer oder Gateway Load Balancer für eine transparente, skalierbare Einfügung. Bevorzugen Sie Azure Firewall für verwaltete Szenarien; wenn herstellerspezifische Funktionen erforderlich sind, entwerfen Sie Hochverfügbarkeit mit mehreren Verfügbarkeitszonen und einem durch Health Probes überwachten Load Balancing.

Sichere Administration, Überwachung und Telemetrie

Sichere administrative Konnektivität:

• Azure Bastion bietet RDP/SSH über TLS aus dem Portal oder einem nativen Client, ohne öffentliche IPs von VMs preiszugeben. Verwenden Sie die Standard-SKU für Skalierung, IP-basierte Verbindungen und gemeinsam nutzbare Links. Beschränken Sie den Bastion-Zugriff durch RBAC und Just-in-Time.
• Der Just-in-Time-VM-Zugriff (Defender for Cloud) schließt Verwaltungsports in NSGs und öffnet sie auf zeitlich begrenzte Anfrage mit Genehmigung und Quell-IP-Beschränkungen. Kombinieren Sie dies mit Bastion für eine Haltung ohne öffentliche IPs und einen präzisen Audit-Trail.

Network Watcher bietet operative Überprüfung und Forensik:

• NSG-Flow-Protokolle (v2) schreiben in den Speicher und können an Traffic Analytics in Log Analytics gesendet werden, um Einblicke in Top-Talker, erlaubte/verweigerte Flows und geografische Standorte zu erhalten.
• Die Verbindungsfehlerbehebung (Connection Troubleshoot) testet aktiv die End-to-End-Konnektivität und meldet, wo ein Pfad blockiert ist (NSG, UDR, DNS, Firewall).
• Die Paketerfassung (Packet Capture) kann bei Bedarf oder durch Warnungen ausgelöst werden; verwenden Sie Ringpuffer, um den Speicherbedarf zu reduzieren und nur relevante Ports zu erfassen.
• „Effektive Routen“ und „IP-Fluss überprüfen“ bilden Laufzeitentscheidungen über UDRs, BGP und NSGs hinweg ab; automatisieren Sie diese Prüfungen in CI/CD-Preflight-Checks.

NSG-Flow-Protokolle und -Analysen schnell aktivieren:

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

Praktisches Problemszenario

Starbucks modernisiert eine Bestellverwaltungsplattform auf Azure. Sicherheitsziele: keine öffentlichen IPs auf den Anwendungs-/Datenebenen, strikter Egress-Verkehr, globaler Webschutz und operative Transparenz.

1. Erstellen Sie drei Subnetze pro Region: Web, App, Daten, jedes mit seiner eigenen NSG und rollenbasierten ASGs.

Begründung: Subnetz-basierte Mikrosegmentierung mit ASGs kodiert die geringsten Rechte für Datenflüsse (Web→App 443, App→Daten 1433) und reduziert den Explosionsradius (Blast Radius). Separate NSGs pro Ebene vermeiden eine versehentliche Kopplung von Richtlinien.

2. Stellen Sie Azure Front Door Standard/Premium mit einer WAF-Richtlinie im Präventionsmodus (Prevention Mode) bereit, die OWASP 3.x und benutzerdefinierte Regeln für Ratenbegrenzung und geografische Einschränkungen verwendet.

Begründung: Der globale Edge-Schutz absorbiert volumetrischen Datenverkehr, blockiert gängige L7-Angriffe, bevor sie die Region erreichen, und reduziert die Latenz durch Anycast. WAF-Richtlinien am Edge sorgen für eine konsistente Durchsetzung über Regionen hinweg.

3. Platzieren Sie in jeder Region ein Application Gateway mit WAF v2 vor der Web-Ebene; beenden Sie TLS am App Gateway und verschlüsseln Sie die Verbindung zum Backend erneut.

Begründung: Regionales L7-Routing und WAF ergänzen Front Door und ermöglichen anwendungsspezifisches mTLS zu Backends, Cookie-basierte Affinität und Blue/Green-Deployments, während die Inspektionsfähigkeit erhalten bleibt.

4. Aktivieren Sie den DDoS-Schutz: Network Protection für die VNets, die die öffentlichen IPs des Application Gateway enthalten.

Begründung: Adaptive Mitigation pro IP, Telemetrie und Kostenschutz reduzieren das Risiko volumetrischer Angriffe auf regionale Eingangspunkte. Der VNet-Geltungsbereich stellt sicher, dass alle aktuellen und zukünftigen öffentlichen IPs ohne Konfiguration pro Ressource geschützt sind.

5. Stellen Sie Azure Firewall Premium in einem gesicherten Hub bereit; leiten Sie den gesamten Egress-Verkehr von den App- und Daten-Subnetzen mit UDRs dorthin. Aktivieren Sie die TLS-Inspektion und IDPS für ausgehenden Verkehr und konfigurieren Sie Anwendungsregeln, um nur erforderliche FQDNs zuzulassen.

Begründung: Die zentralisierte Egress-Kontrolle mit Entschlüsselung und signaturbasierter Erkennung verhindert Command-and-Control-Kommunikation und Datenexfiltration. Anwendungsregeln reduzieren den Wartungsaufwand im Vergleich zu IP-basierten Regeln und entsprechen dem Zero-Trust-Egress-Modell.

6. Verwenden Sie Private Link für Azure SQL und Storage; deaktivieren Sie den öffentlichen Netzwerkzugriff und konfigurieren Sie private DNS-Zonen, die mit allen VNets verknüpft sind. Verwenden Sie für containerisierte Workloads Azure CNI.

Begründung: Private Endpunkte halten die Datenpfade auf dem Backbone und eliminieren die öffentliche Exposition. Private DNS gewährleistet eine nahtlose Namensauflösung. Azure CNI garantiert, dass Pod-IPs aus dem Subnetz stammen, sodass Private Link und Dienstendpunkte korrekt funktionieren.

7. Richten Sie ExpressRoute mit dualen Leitungen im Aktiv-Aktiv-Modus ein und kündigen Sie On-Prem-Routen mit BGP an; aktivieren Sie IPsec über ER für sensiblen Datenverkehr. Kündigen Sie anfangs nicht 0/0 an; testen Sie Forced Tunneling zuerst in einem Staging-Subnetz.

Begründung: ER bietet vorhersagbare, private Konnektivität; eine mehrschichtige Verschlüsselung schützt hochsensible Datenflüsse. Ein kontrollierter Rollout von Forced Tunneling verhindert versehentliches Internet-Blackholing und validiert Ausnahmerouten.

8. Stellen Sie administrativen Zugriff über Azure Bastion bereit und erzwingen Sie Just-in-Time für alle VMs; entfernen Sie alle öffentlichen IPs von den Servern.

Begründung: Eliminiert exponierte Verwaltungsoberflächen und bewahrt gleichzeitig einen auditierbaren, zeitlich begrenzten Zugriff gemäß dem Prinzip der geringsten Rechte (Least Privilege).

9. Aktivieren Sie NSG-Flow-Protokolle und Traffic Analytics, konfigurieren Sie die Diagnose von Firewall und WAF für Log Analytics und richten Sie Warnungen für DDoS-Mitigationen und Spitzen bei WAF-Blockierungen ein.

Begründung: Einheitliche Telemetrie ermöglicht proaktive Erkennung, Kapazitätsplanung und schnelle Reaktion auf Vorfälle (Incident Response). Die Alarmierung bei Anomalien deckt Angriffe und Fehlkonfigurationen frühzeitig auf.

10. Implementieren Sie Azure Policy, um öffentliche IPs auf NICs zu verweigern, NSGs für alle Subnetze vorzuschreiben und VNets ohne aktivierten DDoS-Schutz zu auditieren; integrieren Sie Richtlinienprüfungen in CI/CD.

Begründung: Verhindert Konfigurationsdrift, erzwingt Leitplanken (Guardrails) in großem Maßstab und macht sichere Standardeinstellungen für zukünftige Workloads wiederholbar.

← Identitäts- und Zugriffsverwaltung · Alle Domänen · Sicherheit für Compute →

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

Microsoft durchsuchen →