Web Application Firewall für Azure Netzwerke

Azure Web Application Firewall (WAF) schützt Ihre Webanwendungen vor gängigen HTTP-Layer-Angriffen wie SQL-Einfügung, websiteübergreifendes Skripting (XSS) und Pfad-Traversal. Im Gegensatz zu Azure Firewall, die den Datenverkehr auf Layer 3 bis 7 auf Bedrohungen auf Netzwerkebene prüft, funktioniert WAF nur bei Layer 7 und versteht HTTP-Semantik, einschließlich Anforderungsheader, Abfragezeichenfolgen, Anforderungstexte und Cookies. Stellen Sie WAF als eine Richtlinie bereit, die entweder an Azure Application Gateway (regional) oder an Azure Front Door (global) angehängt ist, um den Schutzumfang an Ihre Anwendungsarchitektur anzupassen. Die Web Application Firewall ist eine von drei zentralen Azure-Netzwerksicherheitsdiensten, neben Azure Firewall und Azure DDoS Protection.

Inhalt dieses Artikels

In diesem Artikel wird der HTTP-Layerschutz mithilfe von Azure Web Application Firewall behandelt. Sie erfahren mehr über:

  • Plattformvergleich zwischen WAF on Application Gateway v2 und WAF auf Azure Front Door.
  • OWASP-basierte Regelsätze einschließlich Standardregelsatz (Default Rule Set, DRS) und Kernregelsatz (Core Rule Set, CRS).
  • Erkennungsmodus im Vergleich zum Präventionsmodus und wann welcher verwendet werden sollte.
  • WAF-Richtlinienbereichsoptionen: globale, standortspezifische und listenerspezifische Zuordnungen.
  • Benutzerdefinierte Regeln zur Ratenbegrenzung, Geofilterung und anwendungsspezifischen Logik.
  • Der Unterschied zwischen WAF (Layer 7 HTTP) und Azure Firewall (Layer 3-7-Netzwerk).

Wer diesen Artikel benötigt

Stellen Sie WAF bereit, wenn Ihre Workloads einem oder mehreren der folgenden Kriterien entsprechen:

  • Öffentlich zugängliche Webanwendungen: Ihre Anwendungen akzeptieren eingehenden HTTP/HTTPS-Datenverkehr aus dem Internet, wodurch sie OWASP Top 10-Sicherheitsrisiken ausgesetzt werden, einschließlich Einfügungsangriffe, fehlerhafter Authentifizierungsmissbrauch und Gefährdungsversuche vertraulicher Daten.
  • Complianceanforderungen: Regulatorische Frameworks wie PCI DSS (Payment Card Industry Data Security Standard) mandatiert eine Webanwendungsfirewall vor jeder Anwendung, die Zahlungskartendaten verarbeitet.
  • API-Schutz: Ihre APIs sind öffentlich zugänglich und erfordern Schutz vor Anforderungsschmuggel, überdimensionalen Nutzlasten und Angriffen auf Protokollebene, die von Netzwerkfirewalls nicht überprüft werden.
  • Bot-Entschärfung: Sie müssen automatisierten Datenverkehr kategorisieren und steuern, schädliche Bots blockieren und gleichzeitig legitime Crawler und Überwachungsdienste zulassen.

Organisationen, die nur die Datenverkehrsfilterung auf Netzwerkebene (IP, Port und Protokoll) ohne HTTP-Anforderungsüberprüfung benötigen, sollten stattdessen Azure Firewall oder NSGs verwenden.

Heben und Verschieben des Fokus: Viele neu gehostete interne Apps haben keinen Internetausgang und benötigen keine WAF. Fügen Sie WAF nur hinzu, wenn Sie eine Web-App während oder nach der Migration im Internet verfügbar machen.

Modernisierungsfokus: Kundenorientierte Web-Apps sollten mit einer WAF über Azure Front Door für globale Apps oder über Application Gateway für Single-Region-Apps bereitgestellt werden, abgestimmt auf Ihre Bereitstellungsentscheidung zwischen Front Door und Traffic Manager.

Cloud-übergreifender Fokus: Platzieren Sie für migrierte öffentliche Web-Apps im Spoke eine Layer-7-WAF auf Application Gateway und bilden Sie die Webschutzmechanismen anderer Clouds (z. B. Google Cloud Armor) auf Azure WAF ab.

Azure WAF-Plattformvergleich

Azure WAF ist auf zwei Plattformen verfügbar. Jede Plattform integriert WAF-Inspektion in einen anderen Punkt im Verkehrsfluss.

Diagramm mit Azure Web Application Firewall Architektur mit Bereitstellungsoptionen für Anwendungsgateway und Front Door

Fähigkeit WAF auf Application Gateway v2 WAF auf Azure Front Door
Bereitstellungsumfang Regional (einzelne Azure-Region) Global (192+ Edge-PoPs weltweit)
Inspektionspunkt Sobald der Datenverkehr Ihre Region erreicht hat Am Edge-PoP, bevor der Datenverkehr den Origin-Server erreicht
Unterstützte Regelsätze DRS 2.2, DRS 2.1, CRS 3.2 DRS 2.2, DRS 2.1, DRS 2.0
Benutzerdefinierte Regeln ✔ ✔
Bot-Schutz ✔ ✔ (Nur Premium-Stufe)
Ratenbegrenzung ✔ ✔
Geo-filtering ✔ ✔
Richtlinie pro Standort ✔ (pro Listener, pro Pfad) ✔ (pro Endpunkt)
Verwaltete Regelsätze ✔ ✔ (Nur Premium-Stufe; Standard unterstützt nur benutzerdefinierte Regeln)
Untersuchung des Anforderungstexts Bis zu 128 KB (konfigurierbar) Bis zu 128 KB (konfigurierbar)
Private Link Origin-Unterstützung N/A (integriert in App Gateway) ✔ (private Ursprungskonnektivität)
Am besten geeignet für: Apps mit einer Region, L7 Lastenausgleich + WAF Multiregion-Apps, globale Beschleunigung + WAF

Note

Azure Front Door hat zwei Stufen: Standard und Premium. Verwaltete Regelsätze (einschließlich DRS und Bot-Schutz) sind nur für Front Door Premium verfügbar. Front Door Standard unterstützt nur benutzerdefinierte Regeln. Front Door (klassisch) unterstützt nur DRS 1.1 oder früher.

So wählen Sie Ihre WAF-Plattform aus

Verwenden Sie die folgenden Entscheidungskriterien:

  • Wählen Sie WAF auf dem Anwendungsgateway aus, wenn Ihre Anwendung in einer einzelnen Region bereitgestellt wird und Sie bereits Anwendungsgateway für Den Layer 7-Lastenausgleich, TLS-Beendigung oder pfadbasiertes Routing verwenden. WAF fügt die HTTP-Inspektion inline hinzu, ohne einen zusätzlichen Service-Hop einzuführen.
  • Wählen Sie WAF auf Azure Front Door aus, wenn Ihre Anwendung mehrere Regionen umfasst, einen globalen Lastenausgleich erfordert oder vorteile von der CDN-Beschleunigung (Content Delivery Network) hat. Front Door WAF überprüft den Datenverkehr am nächstgelegenen Edge-Point-of-Presence (PoP). Der Dienst blockiert böswillige Anforderungen, bevor sie das Azure Backbone durchlaufen, um Ihren Ursprung zu erreichen. Dieser Ansatz reduziert die Angriffsfläche und wehrt volumetrische Layer-7-Angriffe am Netzwerkrand ab.
  • Wählen Sie beides (überschichtet) aus, wenn eine von Front Door bediente Multiregion-Anwendung auch regionale WAF-Richtlinien erfordert, die sich für jedes Back-End unterscheiden. Front Door bietet einen globalen Schutz auf erster Ebene, während die Application Gateway WAF regionsspezifische benutzerdefinierte Regeln näher an der Arbeitslast anwendet.

Überlegungen zum Entwurf

WAF-Designfokus per Lift & Shift migrieren

  • Überspringen Sie WAF für ausschließlich intern erneut gehostete Workloads, die keinen eingehenden Pfad aus dem Internet haben; prüfen Sie dies erneut, wenn Sie eine App im Internet veröffentlichen.
  • Wenn Sie eine Webanwendung öffentlich zugänglich machen, betreiben Sie die WAF zunächst im Erkennungsmodus, um ein Basisprofil des Datenverkehrs zu erstellen, und wechseln Sie dann in den Präventionsmodus, nachdem Sie False Positives durch Feinabstimmung reduziert haben.
  • Verwenden Sie Application Gateway WAF für eine per Rehosting migrierte Web-App in einer einzelnen Region, für die Sie bereits Application Gateway für Layer-7-Routing vorgeschaltet haben.
  • Verwenden Sie die Absicht Ihrer lokalen Webschutzregeln (z. B. OWASP-Abdeckung) als Startrichtlinie wieder.

Modernisieren des WAF-Designfokus

  • Führen Sie WAF im Verhinderungsmodus von Anfang an für kundenorientierte Apps aus, und übernehmen Sie den neuesten verwalteten Regelsatz, sodass die Abdeckung neue OWASP-Bedrohungen automatisch verfolgt.
  • Aktivieren Sie die Botverwaltung, um legitime Crawler von böswilliger Automatisierung gegen Ihre öffentlichen Apps zu trennen.
  • Verwalten Sie WAF-Richtlinie als Code, damit aktive-aktive regionale Back-Ends über Ihre Bereitstellungspipeline synchronisiert bleiben.
  • Kombinieren Sie die Edge-WAF mit der Hub-Firewall für mehrschichtige Verteidigung, und aktivieren Sie den Abrechnungsrabatt für die Application Gateway-WAF, indem Sie den DDoS-Netzwerkschutz im VNet aktivieren.

Cloudübergreifender WAF-Designfokus

  • Stellen Sie eine Layer-7-Web Application Firewall (WAF) auf dem Application Gateway im Spoke-VNet bereit, damit öffentlicher Webdatenverkehr geprüft wird, ohne öffentliche IP-Adressen direkt virtuellen Maschinen zuzuweisen.
  • Ordnen Sie vorhandene Webschutzmechanismen von anderen Clouds (z. B. AWS WAF oder Google Cloud Armor) Azure verwalteten WAF-Regelsätzen zu, sodass die Abdeckung übernommen wird.
  • Überprüfen Sie die öffentlich zugängliche Kommunikation über die WAF und halten Sie ost-west- und cloudübergreifende Transit-Inspektionen auf der Virtual WAN Hubfirewall.
  • Betreiben Sie die WAF während der Umstellung zunächst im Erkennungsmodus (Lernmodus) und setzen Sie sie erst dann auf den Erzwingungsmodus, wenn Sie die Muster des legitimen Datenverkehrs bestätigt haben.

Voraussetzungen

Bevor Sie Azure Web Application Firewall bereitstellen, stellen Sie sicher, dass Sie folgendes haben:

  • Application Gateway v2 oder Azure Front Door Ressource: WAF wird als richtlinie bereitgestellt, die einer dieser Plattformen zugeordnet ist. Sie müssen bereits über eine bereitgestellte Application Gateway v2-Instanz oder ein Azure Front Door-Profil verfügen, bevor Sie eine WAF-Richtlinie erstellen und zuordnen.
  • Öffentlich zugängliche HTTP/HTTPS-Workload: Ihre Anwendung muss eingehenden HTTP/HTTPS-Datenverkehr empfangen. WAF prüft die Semantik auf Anforderungsebene und bietet keinen Vorteil für Nicht-HTTP-Workloads oder rein interne Dienste.
  • Grundlegendes zu HTTP-Datenverkehrsmustern: Vertrautheit mit den normalen Anforderungsmustern Ihrer Anwendung (Header, Abfrageparameter und Textkörperinhalt) hilft Ihnen beim Konfigurieren von Ausschlüssen und Optimieren von Regeln, um falsch positive Ergebnisse während des Übergangs zum Erkennungs-zu-Präventionsmodus zu minimieren.

Regelsätze und Regelverarbeitung

WAF verwendet Regelsätze, um böswillige Muster in HTTP-Anforderungen zu erkennen. Wenn Sie die Regelhierarchie und die Verarbeitungsreihenfolge verstehen, können Sie WAF für Ihre spezifischen Anwendungen optimieren.

Verwaltete Regelsätze

Microsoft verwaltet verwaltete Regelsätze, die auf Mustern des OWASP Core Rule Set (CRS) basieren. Der empfohlene Regelsatz für neue Bereitstellungen ist DRS 2.2 (Standardregelsatz). DRS 2.2 baut auf OWASP CRS 3.3.4 auf und fügt Microsoft Threat Intelligence-Signaturen hinzu.

Regelsatz Basierend auf Plattformunterstützung Recommendation
DRS 2.2 OWASP CRS 3.3.4 + Microsoft Threat Intel App-Gateway v2, Front Door Premium Empfohlen für neue Bereitstellungen
DRS 2.1 OWASP CRS 3.3 App-Gateway v2, Front Door Premium Vorherige Generation; unterstützt auf beiden Plattformen
DRS 2.0 OWASP CRS 3.2 Front Door Premium nur Unterstützt; Front Door N-2-Version
CRS 3.2 OWASP CRS 3.2 Nur App-Gateway v2 Unterstützt; Verwenden von DRS 2.2 für neue Bereitstellungen

DRS- und CRS-Regelsätze verwenden Anomaliebewertungen. Jede Abgleichsregel trägt eine Bewertung bei, anstatt die Anforderung sofort zu blockieren. Wenn der kumulierte Anomalie-Score einen konfigurierbaren Schwellenwert überschreitet, ergreift die WAF eine Maßnahme (Blockieren oder Protokollieren). Dieser Ansatz reduziert False Positives im Vergleich zur Blockierung einzelner Regeln, da eine einzelne Übereinstimmung mit niedriger Konfidenz keine Erzwingung auslöst.

Benutzerdefinierte Regeln

Benutzerdefinierte Regeln werden vor verwalteten Regeln ausgeführt und verwenden Prioritätsnummern zum Steuern der Auswertungsreihenfolge (niedrigere Zahl = höhere Priorität). Verwenden Sie benutzerdefinierte Regeln für:

  • Ratenbegrenzung: Beschränken Sie Anfragen für jede Client-IP innerhalb eines Zeitfensters, um Credential-Stuffing- und Brute-Force-Angriffe abzuwehren.
  • Geofilterung: Zulassen oder Verweigern des Datenverkehrs basierend auf dem Land oder der Herkunftsregion des Kunden.
  • IP-Zulassungslisten und Ablehnungslisten: Lassen Sie bekannte Partner-IPs zu, oder blockieren Sie bekannte schlechte Akteure, bevor verwaltete Regeln ausgewertet werden.
  • Überprüfung von Request-Headern: Stellen Sie anwendungsspezifische Anforderungen sicher, etwa erforderliche API-Schlüssel oder erwartete Inhaltstypen.

Bot-Schutzregelsatz

Beide Plattformen bieten einen Bot-Schutzregelsatz, der automatisierten Datenverkehr in gute Bots (überprüfte Suchmaschinen), schlechte Bots (bekannte böswillige Scanner) und unbekannte Bots kategorisiert. Konfigurieren Sie Aktionen für jede Kategorie: zulassen Sie gute Bots, blockieren Sie schlechte Bots, und fordern Sie unbekannte Bots mit Ratelimit oder CAPTCHA heraus.

Erkennungsmodus vs. Präventionsmodus

WAF-Richtlinien werden in einem von zwei Modi ausgeführt, die bestimmen, wie das System übereinstimmene Anforderungen verarbeitet:

Modus Behavior Anwendungsfall
Erkennung Protokolliert übereinstimmende Anfragen, blockiert sie jedoch nicht. Anfragen werden weiterhin an das Backend gesendet. Anfängliche Bereitstellung und Regeloptimierung. Überwachen Sie, welche Regeln ausgelöst werden, ohne den Produktionsdatenverkehr zu beeinträchtigen.
Verhütung Blockiert übereinstimmende Anfragen und gibt eine HTTP-403-Antwort zurück. Protokolliert die blockierte Anforderung. Produktions-Workloads nach abgeschlossener Regeloptimierung. Aktiver Schutz vor Angriffen.
  1. Im Erkennungsmodus bereitstellen: Aktivieren Sie WAF mit Ihrem ausgewählten Regelsatz im Erkennungsmodus. Leiten Sie den Produktionsverkehr durch die WAF.
  2. Analysieren von Protokollen: Überprüfen Sie WAF-Protokolle, um falsch positive Ergebnisse zu identifizieren. Bestimmen Sie die Regeln, die durch legitimen Anwendungsverkehr ausgelöst werden.
  3. Erstellen von Ausschlüssen: Definieren Sie bei Regeln, die falsch positive Ergebnisse generieren, Ausschlüsse, die die Anforderungsfelder (Header, Cookies und Abfrageparameter) angeben, die für bestimmte Regeln übersprungen werden sollen.
  4. Wechseln zum Verhinderungsmodus: Wechseln Sie nach 1 bis 2 Wochen sauberer Erkennungsprotokolle mit akzeptablen falsch positiven Raten zum Verhinderungsmodus für die aktive Blockierung.
  5. Laufende Überwachung: Fahren Sie mit den Überwachungsprotokollen fort, nachdem Sie zum Verhinderungsmodus gewechselt haben. Neue Anwendungsfeatures oder API-Änderungen können neue falsch positive Muster einführen.

Important

Führen Sie Produktions-Workloads immer im Präventionsmodus aus. Der Erkennungsmodus bietet keinen Schutz. Es protokolliert nur potenzielle Angriffe. Verwenden Sie den Erkennungsmodus nur während der ersten Optimierungsphase oder wenn Sie ein bestimmtes False-Positive-Problem behandeln.

WAF-Richtlinienbereich und -Zuordnung

Eine WAF-Richtlinie ist eine eigenständige Azure Ressource, die Ihre Modusauswahl, Regelsatzkonfiguration, benutzerdefinierte Regeln und Ausschlüsse enthält. Ordnen Sie die Richtlinie einem oder mehreren Zielen zu, um den Schutzbereich zu steuern.

Application Gateway – Bereich der WAF-Richtlinie

Ordnen Sie im Application Gateway eine WAF-Richtlinie auf drei Granularitätsebenen zu:

  • Global (gatewayweit): Die Richtlinie gilt für alle Listener und Pfadregeln im Anwendungsgateway. Verwenden Sie den globalen Bereich, wenn alle Anwendungen hinter dem Gateway dieselben Schutzanforderungen aufweisen.
  • Listenerebene: Eine andere WAF-Richtlinie gilt für einen bestimmten Listener (Hostname und Portkombination). Verwenden Sie den Geltungsbereich auf Listener-Ebene, wenn mehrere Anwendungen ein Gateway gemeinsam nutzen, aber unterschiedliche Regelanpassungen oder Ausschlüsse benötigen.
  • Ebene der Pfadregel: Eine WAF-Richtlinie wird auf eine bestimmte URL-Pfadregel in einem Listener angewendet. Verwenden Sie den Geltungsbereich von Pfadregeln für eine feingranulare Steuerung von Anwendungen mit unterschiedlicher Backend-Sensibilität.

Wenn mehrere Geltungsbereiche auf eine einzelne Anfrage zutreffen, hat die spezifischste Richtlinie Vorrang: Die Pfadregel hat Vorrang vor der Listener-Ebene und diese wiederum vor der globalen Richtlinie.

Umfang der Front Door-WAF-Richtlinie

In Front Door werden WAF-Richtlinien auf Endpunkt- bzw. Routenebene zugeordnet. Jeder Front Door-Endpunkt kann über eine eigene WAF-Richtlinie verfügen. Dieser Ansatz ermöglicht anwendungsspezifische Schutzprofile in einer einzigen Front Door-Instanz.

Freigeben von Richtlinien für ressourcenübergreifende Ressourcen

Teilen Sie eine einzelne WAF-Richtlinie für mehrere Anwendungsgatewayinstanzen oder Front Door-Endpunkte. Azure Firewall Manager bietet unabhängig von der Plattform zentrale Sichtbarkeit und Verwaltung aller WaF-Richtlinien. Verwenden Sie gemeinsam genutzte Richtlinien, wenn mehrere Ressourcen denselben Schutz erfordern, um die Verwaltung zu vereinfachen und ein einheitliches Sicherheitsniveau zu gewährleisten.

Unterscheidung von Azure Firewall

WAF und Azure Firewall schützen verschiedene Ebenen des Netzwerkstapels und dienen ergänzenden Rollen. Setzen Sie beide für eine mehrschichtige Verteidigung ein.

Attribute Firewall für Webanwendungen Azure Firewall
OSI-Ebene Layer 7 (nur HTTP/HTTPS) Layer 3–7 (Netzwerk und Anwendung)
Datenverkehrstyp Eingehende HTTP/HTTPS-Anforderungen an Webanwendungen Alle Verkehrsrichtungen (Nord-Süd, Ost-West)
Inspektionsfokus HTTP-Semantik: Header, Body, Cookies, URIs IP-Adressen, Ports, Protokolle, FQDNs, URLs
Regelmodul OWASP-basierter Mustervergleich + Anomaliebewertung Netzwerkregeln, Anwendungsregeln, NAT-Regeln
Bereitstellungsmodell Integriert mit Application Gateway oder Front Door Eigenständig im Hub-Subnetz mit UDR-Routing
Typische Angriffe blockiert SQL-Injektion, XSS, CSRF, Pfadmanipulation Portüberprüfung, C2-Rückrufe, DNS-Exfiltration

Verwenden Sie WAF für HTTP-Anwendungsschutz und Azure Firewall für die zentralisierte Netzwerkdatenverkehrsüberprüfung. In einer Hub-Spoke-Architektur fließt der Datenverkehr vom Internet zu einer Webanwendung in der Regel über Azure Firewall (für DNAT- und Netzwerküberprüfung) und dann über das Anwendungsgateway mit WAF (für HTTP-Layer-Inspektion). Siehe Azure Firewall und Datenverkehrsüberprüfung für die Komponente auf Netzwerkebene.

Sicherheitsüberlegungen

Die folgenden Sicherheitspraktiken helfen Ihnen, den größten Schutz vor WAF zu erhalten:

  • Präventionsmodus für Produktion: Belassen Sie Produktionsworkloads niemals im Erkennungsmodus. Der Erkennungsmodus bietet Sichtbarkeit, aber keine Erzwingung, sodass Anwendungen Angriffen ausgesetzt sind.
  • Die Regeloptimierung wird fortgesetzt: Anwendungen werden weiterentwickelt. Neue API-Endpunkte, Parameter und Inhaltstypen können falsch positive Ergebnisse in vorhandenen Regelsätzen auslösen. Überprüfen Sie WAF-Protokolle regelmäßig nach Bereitstellungen.
  • Log Analytics Integration: Senden von WAF-Diagnoseprotokollen an einen Log Analytics Arbeitsbereich. Verwenden Sie die WAF-Arbeitsmappe für die Visualisierung blockierter Anforderungen, ausgelöster Regeln und Anomaliebewertungsverteilungen.
  • DDoS und WAF zusammen: WAF schützt vor Angriffen auf Layer 7-Anwendungen, verringert jedoch keine Volumetric Network-Layer-DDoS-Angriffe. Kombinieren Sie WAF mit Azure DDoS Protection für umfassenden Schutz auf allen Ebenen.
  • Ursprungssperre: Wenn Sie Front Door WAF verwenden, konfigurieren Sie Ihren Ursprung so, dass Datenverkehr nur vom Front Door-Diensttag akzeptiert wird. Ohne Ursprungssperrung können Angreifer Front Door umgehen und Anforderungen direkt an Ihre Ursprungs-IP-Adresse senden.
  • Schutz vertraulicher Daten: WAF-Protokolle können Anforderungsdaten enthalten. Konfigurieren Sie Protokollbereinigungsregeln, um vertrauliche Felder (Autorisierungsheader, Cookies oder Textkörperinhalte) in WAF-Diagnoseprotokollen zu maskieren.

Die folgenden Artikel beziehen sich auf verwandte Themen zur Netzwerksicherheit:

Weitere Informationen

Nächste Schritte

Tip

Auf eigene Faust erkunden? Kehren Sie zum Übersichtsnavigator zurück, um Ihren nächsten Artikel nach Funktion zu finden.

Als Nächstes in Ihrer Lift-and-Shift-Reise:

Richten Sie die Überwachung für Ihr migriertes Netzwerk ein: Überprüfen Sie die Konnektivität und Leistung, nachdem Sie die Webanwendungsfirewall konfiguriert haben.

Als Nächstes in Ihrer Modernisierungsreise:

Aktivieren Sie den DDoS-Schutz für öffentliche Endpunkte: Schützen Sie Ihre öffentlichen IP-Ressourcen vor verteilten Denial-of-Service-Angriffen.

Als Nächstes in Ihrer cloudübergreifenden Reise:

Stellen Sie Ihre migrierten Anwendungen bereit: Ordnen Sie Load Balancer aus AWS und Google Cloud den entsprechenden Azure-Diensten für Ihre cloudübergreifenden Workloads zu.

  • Last updated on