Empfehlungen für Netzwerk und Konnektivität

Artikel
10/31/2024

Gilt für diese Empfehlung für die Sicherheit von Azure Well-Architected Framework:

SE:06	Isolieren, Filtern und Steuern Sie den Netzwerkdatenverkehr über Eingangs- und Ausgangsflows hinweg. Wenden Sie die Verteidigung in tiefen Prinzipien an, indem Sie lokalisierte Netzwerksteuerelemente an allen verfügbaren Netzwerkgrenzen sowohl ost-west- als auch nord-süd-Datenverkehr verwenden.

In diesem Leitfaden werden die Empfehlungen für das Netzwerkdesign beschrieben. Der Fokus liegt auf Sicherheitskontrollen, die Angreifer filtern, blockieren und erkennen können, die Netzwerkgrenzen in verschiedenen Tiefen Ihrer Architektur überschreiten.

Sie können Ihre Identitätskontrollen stärken, indem Sie netzwerkbasierte Zugriffssteuerungsmaßnahmen implementieren. Zusammen mit der identitätsbasierten Zugriffssteuerung ist die Netzwerksicherheit für den Schutz von Ressourcen eine hohe Priorität. Ordnungsgemäße Netzwerksicherheitskontrollen können ein detailliertes Verteidigungselement bereitstellen, das dazu beitragen kann, Bedrohungen zu erkennen und zu enthalten, und Angreifer daran hindern, in Ihre Workload einzusteigen.

Definitionen

Ausdruck	Definition
Ost-West-Datenverkehr	Netzwerkdatenverkehr, der innerhalb einer vertrauenswürdigen Grenze verschoben wird.
Ausgangsfluss	Ausgehender Workload-Datenverkehr.
feindliches Netzwerk	Ein Netzwerk, das nicht als Teil Ihrer Workload bereitgestellt wird. Ein feindliches Netzwerk gilt als Bedrohungsvektor.
Eingangsfluss	Eingehender Workload-Datenverkehr.
Netzwerkfilter	Ein Mechanismus, der Netzwerkdatenverkehr basierend auf angegebenen Regeln zulässt oder blockiert.
Netzwerksegmentierung oder -isolation	Eine Strategie, die ein Netzwerk in kleine, isolierte Segmente unterteilt, wobei Sicherheitskontrollen an den Grenzen angewendet werden. Diese Technik trägt dazu bei, Ressourcen vor feindlichen Netzwerken wie dem Internet zu schützen.
Netzwerktransformation	Ein Mechanismus, der Netzwerkpakete stummschaltet, um sie zu verdecken.
Nord-Süd-Datenverkehr	Netzwerkdatenverkehr, der von einer vertrauenswürdigen Grenze zu externen Netzwerken wechselt, die potenziell feindliche sind und umgekehrt.

Wichtige Entwurfsstrategien

Die Netzwerksicherheit verwendet Obscurity, um Arbeitsauslastungsressourcen vor feindlichen Netzwerken zu schützen. Ressourcen, die sich hinter einer Netzwerkgrenze befinden, werden ausgeblendet, bis die Begrenzungssteuerelemente den Datenverkehr als sicher markieren, um vorwärts zu gelangen. Das Netzwerksicherheitsdesign basiert auf drei Hauptstrategien:

Segment. Diese Technik isoliert den Datenverkehr in separaten Netzwerken, indem Grenzen hinzugefügt werden. Beispielsweise übergibt der Datenverkehr zu und von einer Anwendungsebene eine Grenze, um mit anderen Ebenen zu kommunizieren, die unterschiedliche Sicherheitsanforderungen aufweisen. Segmentierungsebenen ist der detaillierte Verteidigungsansatz.

Die wichtigste Sicherheitsgrenze ist der Netzwerkrand zwischen Ihrer Anwendung und öffentlichen Netzwerken. Es ist wichtig, diesen Umkreis klar zu definieren, damit Sie eine Grenze für die Isolierung feindlicher Netzwerke einrichten. Die Steuerelemente auf diesem Rand müssen sehr effektiv sein, da diese Grenze Ihre erste Verteidigungslinie ist.

Virtuelle Netzwerke bieten eine logische Grenze. Entwurfsmäßig kann ein virtuelles Netzwerk nicht mit einem anderen virtuellen Netzwerk kommunizieren, es sei denn, die Grenze wurde absichtlich durch Peering unterbrochen. Ihre Architektur sollte diese starke, plattformbezogene Sicherheitsmaßnahme nutzen.

Sie können auch andere logische Grenzen verwenden, z. B. geschnitzte Subnetze in einem virtuellen Netzwerk. Ein Vorteil von Subnetzen besteht darin, dass Sie sie verwenden können, um Ressourcen zu gruppieren, die sich innerhalb einer Isolationsgrenze befinden und ähnliche Sicherheitsüberprüfungen aufweisen. Anschließend können Sie Steuerelemente an der Grenze konfigurieren, um den Datenverkehr zu filtern.
Filter. Mit dieser Strategie wird sichergestellt, dass Datenverkehr, der eine Grenze eingibt, erwartet, zulässig und sicher ist. Aus Zero-Trust-Perspektive überprüft die Filterung explizit alle verfügbaren Datenpunkte auf Netzwerkebene. Sie können Regeln auf der Grenze platzieren, um nach bestimmten Bedingungen zu suchen.

Beispielsweise können die Regeln auf Kopfzeilenebene überprüfen, ob der Datenverkehr von einem erwarteten Speicherort stammt oder über ein erwartetes Volume verfügt. Diese Prüfungen reichen jedoch nicht aus. Auch wenn der Datenverkehr erwartete Merkmale aufweist, ist die Nutzlast möglicherweise nicht sicher. Überprüfungen können einen SQL-Einfügungsangriff aufdecken.
Transformieren. Mutieren Sie Pakete an der Grenze als Sicherheitsmaßnahme. Sie können beispielsweise HTTP-Header entfernen, um das Risiko einer Belichtung zu beseitigen. Oder Sie können Transport Layer Security (TLS) an einem Punkt deaktivieren und es an einem anderen Hop mit einem Zertifikat erneut wiederherstellen, das strenger verwaltet wird.

Klassifizieren der Datenverkehrsflüsse

Der erste Schritt bei der Klassifizierung von Flüssen besteht darin, eine schematische Darstellung Ihrer Workloadarchitektur zu untersuchen. Bestimmen Sie anhand des schematischen Vorgangs die Absichten und Merkmale des Flusses in Bezug auf die funktionalen Dienstprogramme und betrieblichen Aspekte Ihrer Workload. Verwenden Sie die folgenden Fragen, um die Klassifizierung des Flusses zu unterstützen:

Wenn die Workload mit externen Netzwerken kommunizieren muss, was sollte die erforderliche Nähe zu diesen Netzwerken sein?
Was sind die Netzwerkmerkmale des Flusses, z. B. das erwartete Protokoll und die Quelle und Form der Pakete? Gibt es Complianceanforderungen auf Netzwerkebene?

Es gibt viele Möglichkeiten zum Klassifizieren von Datenverkehrsflüssen. In den folgenden Abschnitten werden häufig verwendete Kriterien erläutert.

Sichtbarkeit aus externen Netzwerken

Public. Eine Workload ist öffentlich zugänglich, wenn ihre Anwendung und andere Komponenten aus dem öffentlichen Internet erreichbar sind. Die Anwendung wird über einen oder mehrere öffentliche IP-Adressen und dns-Server (Public Domain Name System) verfügbar gemacht.
Private. Eine Workload ist privat, wenn nur über ein privates Netzwerk wie ein virtuelles privates Netzwerk (VPN) zugegriffen werden kann. Sie wird nur über eine oder mehrere private IP-Adressen und potenziell über einen privaten DNS-Server verfügbar gemacht.

In einem privaten Netzwerk gibt es keine Sicht vom öffentlichen Internet bis zur Workload. Für das Gateway können Sie einen Lastenausgleich oder eine Firewall verwenden. Diese Optionen können Sicherheitsvorkehrungen bieten.

Auch bei öffentlichen Arbeitslasten versuchen Sie, so viel wie möglich privat zu halten. Dieser Ansatz erzwingt die Durchquerung von Paketen durch eine private Grenze, wenn sie aus einem öffentlichen Netzwerk eintreffen. Ein Gateway in diesem Pfad kann als Übergangspunkt funktionieren, indem er als Reverseproxy fungiert.

Richtung des Datenverkehrs

Eingang: Ingress ist eingehender Datenverkehr, der in Richtung einer Workload oder seiner Komponenten fließt. Um einen sicheren Eingangsschritt zu gewährleisten, wenden Sie den vorherigen Satz von Schlüsselstrategien an. Bestimmen Sie, was die Datenverkehrsquelle ist und ob sie erwartet, zulässig und sicher ist. Angreifer, die IP-Adressbereiche des öffentlichen Cloudanbieters scannen, können ihre Verteidigung erfolgreich durchdringen, wenn Sie keine Eingehenden überprüfen oder grundlegende Netzwerksicherheitsmaßnahmen implementieren.
Ausgang. Der Ausgang ist ausgehender Datenverkehr, der von einer Workload oder seinen Komponenten abfließt. Um den Ausgang zu überprüfen, bestimmen Sie, wo sich der Datenverkehr befindet und ob das Ziel erwartet, zulässig und sicher ist. Das Ziel kann böswillig sein oder mit Datenexfiltrationsrisiken verknüpft sein.

Sie können auch Ihr Expositionsniveau ermitteln, indem Sie die Nähe Ihrer Workload zum öffentlichen Internet in Betracht ziehen. Beispielsweise dient die Anwendungsplattform in der Regel öffentlichen IP-Adressen. Die Workloadkomponente ist das Gesicht der Lösung.

Einflussbereich

Nord-Süd. Datenverkehr, der zwischen einem Workloadnetzwerk und externen Netzwerken fließt, ist Nord-Süd-Datenverkehr. Dieser Datenverkehr überschreitet den Rand Ihres Netzwerks. Externe Netzwerke können das öffentliche Internet, ein Unternehmensnetzwerk oder ein anderes Netzwerk sein, das sich außerhalb Ihres Kontrollbereichs befindet.

Eingangs- und Ausgang können beide Nord-Süd-Verkehr sein.

Betrachten Sie beispielsweise den Ausgang einer Hub-Spoke-Netzwerktopologie. Sie können den Netzwerkrand Ihrer Workload definieren, sodass der Hub ein externes Netzwerk ist. In diesem Fall handelt es sich bei ausgehenden Datenverkehr aus dem virtuellen Netzwerk der Speichen um Nord-Süd-Datenverkehr. Wenn Sie jedoch das Hub-Netzwerk in Ihrem Kontrollbereich in Betracht ziehen, wird der Nord-Süd-Datenverkehr auf die Firewall im Hub ausgedehnt, da der nächste Hop das Internet ist, das potenziell feindliche ist.
Ost-West. Datenverkehr, der innerhalb eines Workloadnetzwerks fließt, ist Ost-West-Datenverkehr. Diese Art von Datenverkehr führt dazu, dass Komponenten in Ihrer Workload miteinander kommunizieren. Ein Beispiel hierfür ist der Datenverkehr zwischen den Ebenen einer n-stufigen Anwendung. In Microservices ist die Service-to-Service-Kommunikation Ost-West-Verkehr.

Um die Verteidigung im Detail zu gewährleisten, behalten Sie die End-to-End-Kontrolle von Sicherheitsangeboten bei, die in jedem Hop enthalten sind oder die Sie verwenden, wenn Pakete interne Segmente überschreiten. Für unterschiedliche Risikostufen sind unterschiedliche Risikobehebungsmethoden erforderlich.

Das vorangehende Diagramm veranschaulicht die Netzwerkabwehr in der privaten Cloud. In diesem Diagramm ist der Rahmen zwischen den öffentlichen und privaten IP-Adressräumen wesentlich weiter von der Arbeitsauslastung entfernt als im Öffentlichen Cloud-Diagramm. Mehrere Ebenen trennen die Azure-Bereitstellungen vom öffentlichen IP-Adressraum.

Hinweis

Die Identität ist immer der primäre Umkreis. Die Zugriffsverwaltung muss auf Netzwerkflüsse angewendet werden. Verwenden Sie verwaltete Identitäten, wenn Sie azure role-based access control (RBAC) zwischen Komponenten Ihres Netzwerks verwenden.

Führen Sie nach der Klassifizierung von Flüssen eine Segmentierungsübung aus, um Firewalleinfügungspunkte auf den Kommunikationspfaden Ihrer Netzwerksegmente zu identifizieren. Wenn Sie Ihre Netzwerkabwehr in allen Segmenten und allen Datenverkehrstypen eingehend entwerfen, gehen Sie von einer Verletzung an allen Punkten aus. Verwenden Sie eine Kombination verschiedener lokalisierter Netzwerksteuerelemente an allen verfügbaren Grenzen. Weitere Informationen finden Sie unter Segmentierungsstrategien.

Anwenden von Firewalls am Edge

Internet-Edgedatenverkehr ist Nord-Süd-Datenverkehr und umfasst ein- und ausgehenden Datenverkehr. Um Bedrohungen zu erkennen oder zu blockieren, muss eine Edgestrategie möglichst viele Angriffe aus dem und in das Internet abwehren.

Senden Sie für den Ausgang den gesamten internetgebundenen Datenverkehr über eine einzelne Firewall , die eine verbesserte Aufsicht, Governance und Kontrolle des Datenverkehrs bietet. Was den ausgehenden Datenverkehr betrifft, erzwingen Sie, dass der gesamte Datenverkehr aus dem Internet durch eine Network Virtual Appliance (NVA) oder eine Webanwendungsfirewall geleitet wird.

Firewalls sind in der Regel Singletons, die pro Region in einer Organisation bereitgestellt werden. Daher werden sie von Arbeitslasten gemeinsam genutzt und gehören einem zentralen Team. Stellen Sie sicher, dass alle von Ihnen verwendeten NVAs so konfiguriert sind, dass sie die Anforderungen Ihrer Workload unterstützen.
Es wird empfohlen, azure native Steuerelemente so weit wie möglich zu verwenden.

Zusätzlich zu systemeigenen Steuerelementen können Sie auch Partner-NVAs in Betracht ziehen, die erweiterte oder spezialisierte Features bereitstellen. Partnerfirewall- und Webanwendungsfirewallprodukte sind in Azure Marketplace verfügbar.

Die Entscheidung, systemeigene Features im Gegensatz zu Partnerlösungen zu verwenden, sollte auf den Erfahrungen und Anforderungen Ihrer Organisation basieren.

Kompromiss: Partnerfunktionen bieten häufig erweiterte Features, die vor komplexen, aber in der Regel ungewöhnlichen Angriffen schützen können. Die Konfiguration von Partnerlösungen kann komplex und zerbrechlich sein, da diese Lösungen nicht in die Fabric-Controller der Cloud integriert werden. Aus Kostenperspektive wird systemeigene Steuerung bevorzugt, da sie günstiger als Partnerlösungen ist.

Alle technologischen Optionen, die Sie berücksichtigen, sollten Sicherheitskontrollen und -überwachungen sowohl für Eingangs- als auch für Ausgangsflüsse bereitstellen. Informationen zu optionen, die für Azure verfügbar sind, finden Sie im Abschnitt "Edge-Sicherheit " in diesem Artikel.

Entwerfen von virtuellen Netzwerken und Subnetzsicherheit

Das Hauptziel einer privaten Cloud besteht darin, Ressourcen aus dem öffentlichen Internet zu verdecken. Es gibt mehrere Möglichkeiten, dieses Ziel zu erreichen:

Wechseln Sie zu privaten IP-Adressräumen, die Sie mithilfe virtueller Netzwerke erreichen können. Minimieren Sie die Netzwerkleitung auch in Ihren eigenen privaten Netzwerken.
Minimieren Sie die Anzahl der öffentlichen DNS-Einträge, die Sie verwenden , um weniger Arbeitsauslastung verfügbar zu machen.
Fügen Sie ein Eingangs- und Ausgangs-Netzwerkflusssteuerelement hinzu. Lassen Sie keinen Datenverkehr zu, der nicht vertrauenswürdig ist.

Segmentierungsstrategie

Um die Netzwerksichtbarkeit zu minimieren, segmentieren Sie Ihr Netzwerk, und beginnen Sie mit den Netzwerksteuerelementen mit den geringsten Rechten. Wenn ein Segment nicht routingfähig ist, kann nicht darauf zugegriffen werden. Erweitern Sie den Bereich, um nur Segmente einzuschließen, die über den Netzwerkzugriff miteinander kommunizieren müssen.

Sie können virtuelle Netzwerke segmentiert werden, indem Sie Subnetze erstellen. Die Kriterien für die Aufteilung sollten beabsichtigt sein. Wenn Sie Dienste in einem Subnetz zusammenschließen, stellen Sie sicher, dass sich diese Dienste gegenseitig sehen können.

Sie können ihre Segmentierung auf viele Faktoren stützen. Sie können beispielsweise unterschiedliche Anwendungsebenen in dedizierten Segmenten platzieren. Ein weiterer Ansatz besteht darin, Ihre Subnetze basierend auf allgemeinen Rollen und Funktionen zu planen, die bekannte Protokolle verwenden.

Weitere Informationen finden Sie unter Segmentierungsstrategien.

Subnetzfirewalls

Es ist wichtig, den eingehenden und ausgehenden Datenverkehr jedes Subnetzes zu prüfen. Verwenden Sie die drei hauptstrategien, die weiter oben in diesem Artikel erläutert werden, in schlüsseldesignstrategien. Überprüfen Sie, ob der Fluss erwartet, zulässig und sicher ist. Um diese Informationen zu überprüfen, definieren Sie Firewallregeln, die auf dem Protokoll, der Quelle und dem Ziel des Datenverkehrs basieren.

In Azure legen Sie Firewallregeln in Netzwerksicherheitsgruppen fest. Weitere Informationen finden Sie im Abschnitt "Netzwerksicherheitsgruppen " in diesem Artikel.

Ein Beispiel für ein Subnetzdesign finden Sie unter Azure Virtual Network-Subnetze.

Verwenden von Steuerelementen auf Komponentenebene

Nachdem Sie die Sichtbarkeit Ihres Netzwerks minimiert haben, ordnen Sie Ihre Azure-Ressourcen aus einer Netzwerkperspektive zu und bewerten sie. Folgende Arten von Flüssen sind möglich:

Geplanter Datenverkehr oder beabsichtigte Kommunikation zwischen Diensten gemäß Ihrem Architekturdesign. Sie haben beispielsweise Datenverkehr geplant, wenn Ihre Architektur empfiehlt, Dass Azure Functions Nachrichten aus Azure Service Bus abruft.
Verwaltungsdatenverkehr oder Kommunikation, die als Teil der Funktionalität des Diensts erfolgt. Dieser Datenverkehr ist nicht Teil Ihres Designs, und Sie haben keine Kontrolle darüber. Ein Beispiel für verwalteten Datenverkehr ist die Kommunikation zwischen den Azure-Diensten in Ihrer Architektur und der Azure-Verwaltungsebene.

Durch die Unterscheidung zwischen geplantem und Verwaltungsdatenverkehr können Sie lokalisierte Steuerelemente oder Steuerelemente auf Dienstebene erstellen. Sie haben ein gutes Verständnis der Quelle und des Ziels bei jedem Hop. Besonders verstehen Sie, wie Ihre Datenebene verfügbar gemacht wird.

Bestimmen Sie als Ausgangspunkt, ob jeder Dienst für das Internet verfügbar gemacht wird. Planen Sie in diesem Beispiel, wie Sie den Zugriff einschränken. Wenn dies nicht der Richtige ist, platzieren Sie sie in einem virtuellen Netzwerk.

Dienstfirewalls

Wenn Sie erwarten, dass ein Dienst für das Internet verfügbar ist, nutzen Sie die Firewall auf Dienstebene, die für die meisten Azure-Ressourcen verfügbar ist. Wenn Sie diese Firewall verwenden, können Sie Regeln basierend auf Zugriffsmustern festlegen. Weitere Informationen finden Sie im Abschnitt "Azure-Dienstfirewalls " in diesem Artikel.

Hinweis

Wenn Ihre Komponente kein Dienst ist, verwenden Sie zusätzlich zu Firewalls auf Netzwerkebene eine hostbasierte Firewall. Ein virtueller Computer (VM) ist ein Beispiel für eine Komponente, die kein Dienst ist.

Konnektivität mit Plattform as a Service (PaaS)-Diensten

Erwägen Sie die Verwendung privater Endpunkte, um den Zugriff auf PaaS-Dienste zu sichern. Einem privaten Endpunkt wird eine private IP-Adresse aus Ihrem virtuellen Netzwerk zugewiesen. Der Endpunkt ermöglicht anderen Ressourcen im Netzwerk die Kommunikation mit dem PaaS-Dienst über die private IP-Adresse.

Die Kommunikation mit einem PaaS-Dienst erfolgt mithilfe der öffentlichen IP-Adresse und des DNS-Eintrags des Diensts. Diese Kommunikation erfolgt über das Internet. Sie können diese Kommunikation privat machen.

Ein Tunnel vom PaaS-Dienst in einem Ihrer Subnetze erstellt einen privaten Kanal. Die gesamte Kommunikation erfolgt von der privaten IP-Adresse der Komponente an einen privaten Endpunkt in diesem Subnetz, der dann mit dem PaaS-Dienst kommuniziert.

In diesem Beispiel zeigt das Bild auf der linken Seite den Fluss für öffentlich zugängliche Endpunkte. Auf der rechten Seite wird dieser Fluss durch private Endpunkte gesichert.

Weitere Informationen finden Sie im Abschnitt "Private Endpunkte" in diesem Artikel.

Hinweis

Es wird empfohlen, private Endpunkte in Verbindung mit Dienstfirewalls zu verwenden. Eine Dienstfirewall blockiert eingehenden Internetdatenverkehr und macht den Dienst dann privat für interne Benutzer verfügbar, die den privaten Endpunkt verwenden.

Ein weiterer Vorteil der Verwendung privater Endpunkte besteht darin, dass Sie die Ports in der Firewall nicht für ausgehenden Datenverkehr öffnen müssen. Private Endpunkte sperren den gesamten ausgehenden Datenverkehr im Port für das öffentliche Internet. Die Konnektivität ist auf Ressourcen innerhalb des Netzwerks beschränkt.

Tradeoff: Azure Private Link ist ein kostenpflichtiger Dienst, der Meter für eingehende und ausgehende Daten enthält, die verarbeitet werden. Sie werden auch für private Endpunkte in Rechnung gestellt.

Schutz vor verteilten Denial-of-Service -Angriffen (DDoS)

Ein DDoS-Angriff versucht, die Ressourcen einer Anwendung auszuschöpfen, um die Anwendung für legitime Benutzer nicht verfügbar zu machen. DDoS-Angriffe können auf jeden Endpunkt abzielen, der öffentlich über das Internet erreichbar ist.

Ein DDoS-Angriff ist in der Regel ein massiver, weit verbreiteter, geografisch verteilter Missbrauch der Ressourcen Ihres Systems, der es schwierig macht, die Quelle anzuheften und zu blockieren.

Informationen zu Azure-Support zum Schutz vor diesen Angriffen finden Sie im Abschnitt "Azure DDoS Protection" in diesem Artikel.

Umsetzung in Azure

Sie können die folgenden Azure-Dienste verwenden, um Ihrem Netzwerk Verteidigungsfunktionen hinzuzufügen.

Azure Virtual Network

Virtual Network hilft Ihren Azure-Ressourcen bei der sicheren Kommunikation mit einander, dem Internet und lokalen Netzwerken.

Standardmäßig können alle Ressourcen in einem virtuellen Netzwerk ausgehende Kommunikation mit dem Internet durchführen. Die eingehende Kommunikation ist jedoch standardmäßig eingeschränkt.

Virtuelles Netzwerk bietet Features zum Filtern von Datenverkehr. Sie können den Zugriff auf virtuelle Netzwerkebene einschränken, indem Sie eine benutzerdefinierte Route (UDR) und eine Firewallkomponente verwenden. Auf Subnetzebene können Sie den Datenverkehr mithilfe von Netzwerksicherheitsgruppen filtern.

Edgesicherheit

Standardmäßig fließen sowohl Ein- als auch Ausgang über öffentliche IP-Adressen. Je nach Dienst oder Topologie legen Sie entweder diese Adressen fest, oder Azure weist sie zu. Andere Eingangs- und Ausgangsmöglichkeiten umfassen das Übergeben von Datenverkehr über ein Lastenausgleichsgateway oder nat-Gateway (Network Address Translation). Diese Dienste dienen jedoch der Verkehrsverteilung und nicht unbedingt der Sicherheit.

Die folgenden Technologieoptionen werden empfohlen:

Azure Firewall. Sie können Azure Firewall am Netzwerkrand und in beliebten Netzwerktopologien wie Hub-Spoke-Netzwerken und virtuellen WANs verwenden. In der Regel stellen Sie Azure Firewall als Ausgangsfirewall bereit, die als endgültiges Sicherheitsgate fungiert, bevor der Datenverkehr zum Internet wechselt. Azure Firewall kann Datenverkehr weiterleiten, der Nicht-HTTP- und Nicht-HTTPS-Protokolle verwendet, z. B. Remotedesktopprotokoll (RDP), Secure Shell Protocol (SSH) und File Transfer Protocol (FTP). Der Featuresatz der Azure Firewall umfasst:
- Zielnetzwerkadressenübersetzung (DNAT) oder Portweiterleitung.
- Erkennung von IdPS-Signaturen (Intrusion Detection and Prevention System).
- Starke Netzwerkregeln der Ebene 3, Ebene 4 und vollqualifizierter Domänenname (FQDN).
Hinweis

Die meisten Organisationen verfügen über eine Richtlinie für erzwungene Tunneling, die den Datenverkehr zwingt, durch eine NVA zu fließen.

Wenn Sie keine virtuelle WAN-Topologie verwenden, müssen Sie einen UDR mit einer NextHopType der Internet privaten IP-Adressen Ihrer NVA bereitstellen. UDRs werden auf Subnetzebene angewendet. Der Subnetz-zu-Subnetz-Datenverkehr fließt standardmäßig nicht über die NVA.

Sie können azure Firewall auch gleichzeitig für den Ein- und Ausstieg verwenden. Er kann HTTP- und HTTPS-Datenverkehr weiterleiten. In mehrstufigen SKUs bietet Azure Firewall TLS-Beendigung, sodass Sie Inspektionen auf Nutzlastebene implementieren können.

Die folgenden Methoden werden empfohlen:
- Aktivieren Sie Diagnoseeinstellungen in Azure Firewall, um Datenverkehrsflussprotokolle, IDPS-Protokolle und DNS-Anforderungsprotokolle zu sammeln.
- Seien Sie so spezifisch wie möglich in Regeln.
- Vermeiden Sie in der Praxis FQDN-Diensttags. Wenn Sie sie jedoch verwenden, verwenden Sie die regionale Variante, die die Kommunikation mit allen Endpunkten des Diensts ermöglicht.
- Verwenden Sie IP-Gruppen, um Quellen zu definieren, die die gleichen Regeln für die Lebensdauer der IP-Gruppe aufweisen müssen. IP-Gruppen sollten Ihre Segmentierungsstrategie widerspiegeln.
- Überschreiben Sie die Infrastruktur-FQDN-Zulassungsregel nur, wenn Ihre Workload eine absolute Ausgangskontrolle erfordert. Die Außerkraftsetzung dieser Regel kommt zu einem Zuverlässigkeitskonflikt, da sich die Anforderungen der Azure-Plattform für Dienste ändern.
Kompromiss: Azure Firewall kann sich auf Ihre Leistung auswirken. Regelreihenfolge, Menge, TLS-Inspektion und andere Faktoren können zu erheblicher Latenz führen.

Es kann sich auch auf die Zuverlässigkeit Ihrer Workload auswirken. Möglicherweise kann es zu SNAT-Portausschöpfungen (Source Network Address Translation) kommen. Um dieses Problem zu umgehen, fügen Sie bei Bedarf öffentliche IP-Adressen hinzu.

Risiko: Bei Ausgehendem Datenverkehr weist Azure eine öffentliche IP-Adresse zu. Diese Zuordnung kann sich auf Ihr externes Sicherheitsgate nach unten auswirken.
Azure-Webanwendungsfirewall. Dieser Dienst unterstützt eingehende Filterung und zielt nur auf HTTP- und HTTPS-Datenverkehr ab.

Es bietet grundlegende Sicherheit für häufige Angriffe, z. B. Bedrohungen, die das Open Worldwide Application Security Project (OWASP) im OWASP Top 10-Dokument identifiziert. Die Azure-Webanwendungsfirewall bietet auch andere Sicherheitsfeatures, die sich auf Ebene 7 konzentrieren, z. B. Ratelimitierung, SQL-Einfügungsregeln und websiteübergreifendes Skripting.

Bei der Azure Web Application Firewall ist TLS-Beendigung erforderlich, da die meisten Prüfungen auf Nutzlasten basieren.

Sie können die Azure-Webanwendungsfirewall in Router integrieren, z. B. Azure-App lizenzierungsgateway oder Azure Front Door. Implementierungen der Azure-Webanwendungsfirewall für diese Arten von Routern können variieren.

Azure Firewall und Azure Web Application Firewall schließen sich nicht gegenseitig aus. Für Ihre Edge-Sicherheitslösung stehen verschiedene Optionen zur Verfügung. Beispiele finden Sie unter Firewall und Anwendungsgateway für virtuelle Netzwerke.

Netzwerksicherheitsgruppen

Eine Netzwerksicherheitsgruppe ist eine Firewall der Ebene 3 und Der Ebene 4, die Sie auf der Ebene der Subnetz- oder Netzwerkschnittstellenkarte (Network Interface Card, NIC) anwenden. Netzwerksicherheitsgruppen werden nicht standardmäßig erstellt oder angewendet.

Netzwerksicherheitsgruppenregeln dienen als Firewall zum Beenden des Datenverkehrs, der sich im Umkreis eines Subnetzes ein- und ausgibt. Eine Netzwerksicherheitsgruppe verfügt über einen Standardregelsatz, der übermäßig zulässig ist. Die Standardregeln legen beispielsweise keine Firewall aus der Ausgangsperspektive fest. Für eingehenden Datenverkehr ist kein eingehender Internetdatenverkehr zulässig.

Um Regeln zu erstellen, beginnen Sie mit dem Standardregelsatz:

Für eingehenden Datenverkehr oder Ingress:
- Der virtuelle Netzwerkdatenverkehr von direkten, peered- und VPN-Gatewayquellen ist zulässig.
- Azure Load Balancer-Integritätssonden sind zulässig.
- Sämtlicher anderer Datenverkehr wird blockiert.
Für ausgehenden Datenverkehr oder Ausgehende:
- Der virtuelle Netzwerkdatenverkehr zu direkten, peered- und VPN-Gatewayzielen ist zulässig.
- Der Datenverkehr zum Internet ist zulässig.
- Sämtlicher anderer Datenverkehr wird blockiert.

Berücksichtigen Sie dann die folgenden fünf Faktoren:

Protokoll
Quell-IP-Adresse
Quellport
IP-Zieladresse
Zielport

Der Mangel an Unterstützung für FQDN beschränkt die Funktionen der Netzwerksicherheitsgruppe. Sie müssen bestimmte IP-Adressbereiche für Ihre Workload bereitstellen, und sie sind schwer zu verwalten.

Für Azure-Dienste können Sie jedoch Diensttags verwenden, um Quell- und Ziel-IP-Adressbereiche zusammenzufassen. Ein Sicherheitsvorteil von Diensttags besteht darin, dass sie für den Benutzer undurchsichtig sind und die Verantwortung in Azure entladen wird. Sie können auch eine Anwendungssicherheitsgruppe als Zieltyp zuweisen, um den Datenverkehr weiterzuleiten. Dieser Typ der benannten Gruppe enthält Ressourcen mit ähnlichen Anforderungen für eingehenden oder ausgehenden Zugriff.

Risiko: Servicetag-Bereiche sind sehr breit, sodass sie die größtmögliche Kundenpalette berücksichtigen. Aktualisierungen von Diensttags liegen hinter Änderungen am Dienst zurück.

In der vorherigen Abbildung werden Netzwerksicherheitsgruppen an der NIC angewendet. Internetdatenverkehr und Subnetz-zu-Subnetz-Datenverkehr werden verweigert. Die Netzwerksicherheitsgruppen werden mit dem VirtualNetwork Tag angewendet. In diesem Fall haben die Subnetze von peered-Netzwerken also eine direkte Sichtlinie. Die allgemeine Definition des VirtualNetwork Tags kann erhebliche Auswirkungen auf die Sicherheit haben.

Wenn Sie Diensttags verwenden, verwenden Sie nach Möglichkeit regionale Versionen, z Storage.WestUS . B. anstelle von Storage. Durch diesen Ansatz beschränken Sie den Bereich auf alle Endpunkte in einer bestimmten Region.

Einige Tags sind ausschließlich für eingehenden oder ausgehenden Datenverkehr vorgesehen. Andere sind für beide Typen vorgesehen. Eingehende Tags ermöglichen in der Regel Datenverkehr von allen Hostingworkloads, zAzureFrontDoor.Backend. B. von Azure, um Dienstlaufzeiten zu unterstützen, zLogicAppsManagement. B. . Ebenso ermöglichen ausgehende Tags Datenverkehr zu allen Hostingworkloads oder von Azure zur Unterstützung von Dienstlaufzeiten.

Beschränken Sie die Regeln so weit wie möglich. Im folgenden Beispiel wird die Regel auf bestimmte Werte festgelegt. Jeder andere Datenverkehrstyp wird verweigert.

Informationen	Beispiel
Protokoll	Transmission Control Protocol (TCP), UDP
Quell-IP-Adresse	Zulassen des Eingangs zum Subnetz aus <dem Quell-IP-Adressbereich>: 4575/UDP
Quellport	Ingress zum Subnetz vom <Diensttag> zulassen: 443/TCP
IP-Zieladresse	Ausgehend vom Subnetz zum <Ziel-IP-Adressbereich> zulassen: 443/TCP
Zielport	Ausgehend vom Subnetz zum <Diensttag> zulassen: 443/TCP

Zusammenfassung:

Seien Sie genau, wenn Sie Regeln erstellen. Lassen Sie nur Datenverkehr zu, der für die Funktion Ihrer Anwendung erforderlich ist. Alles andere verweigern. Bei diesem Ansatz wird die Netzwerkleitung auf Netzwerkflüsse beschränkt, die erforderlich sind, um den Betrieb der Workload zu unterstützen. Die Unterstützung von mehr Netzwerkflüssen als nötig führt zu unnötigen Angriffsvektoren und erweitert den Oberflächenbereich.

Das Einschränken des Datenverkehrs bedeutet nicht, dass zulässige Flüsse über den Umfang eines Angriffs hinausgehen. Da Netzwerksicherheitsgruppen auf den Ebenen 3 und 4 im OSI-Stapel (Open Systems Interconnection) arbeiten, enthalten sie nur Shape- und Richtungsinformationen. Wenn Ihre Workload beispielsweise DNS-Datenverkehr in das Internet zulassen muss, verwenden Sie eine Netzwerksicherheitsgruppe von Internet:53:UDP. In diesem Fall kann ein Angreifer Daten über UDP auf Port 53 zu einem anderen Dienst exfiltrieren.
Verstehen Sie, dass Netzwerksicherheitsgruppen leicht voneinander abweichen können. Es ist einfach, die Absicht der Unterschiede zu übersehen. Um eine präzise Filterung zu erhalten, ist es sicherer, zusätzliche Netzwerksicherheitsgruppen zu erstellen. Richten Sie mindestens eine Netzwerksicherheitsgruppe ein.
- Durch das Hinzufügen einer Netzwerksicherheitsgruppe werden viele Diagnosetools wie Ablaufprotokolle und Netzwerkdatenverkehranalysen entsperrt.
- Verwenden Sie Azure-Richtlinie, um den Datenverkehr in Subnetzen zu steuern, die nicht über Netzwerksicherheitsgruppen verfügen.
Wenn ein Subnetz Netzwerksicherheitsgruppen unterstützt, fügen Sie eine Gruppe hinzu, auch wenn es minimal beeinträchtigt ist.

Azure-Dienstfirewalls

Die meisten Azure-Dienste bieten eine Firewall auf Dienstebene. Dieses Feature prüft den Datenverkehr an den Dienst aus angegebenen klassenlosen domänenübergreifenden Routingbereichen (CIDR). Diese Firewalls bieten Vorteile:

Sie bieten eine grundlegende Sicherheitsstufe.
Es gibt eine erträgliche Leistungsbeeinträchtigung.
Die meisten Dienste bieten diese Firewalls ohne zusätzliche Kosten an.
Die Firewalls geben Protokolle über die Azure-Diagnose aus, was für die Analyse von Zugriffsmustern nützlich sein kann.

Es gibt jedoch auch Sicherheitsbedenken, die diesen Firewalls zugeordnet sind, und es gibt Einschränkungen im Zusammenhang mit der Bereitstellung von Parametern. Wenn Sie beispielsweise von Microsoft gehostete Build-Agents verwenden, müssen Sie den IP-Adressbereich für alle von Microsoft gehosteten Build-Agents öffnen. Der Bereich ist dann für Ihren Build-Agent, andere Mandanten und Angreifer geöffnet, die Ihren Dienst missbrauchen könnten.

Wenn Sie Zugriffsmuster für den Dienst haben, die als Dienstfirewallregelsätze konfiguriert werden können, sollten Sie den Dienst aktivieren. Sie können Azure-Richtlinie verwenden, um sie zu aktivieren. Stellen Sie sicher, dass Sie die Option für vertrauenswürdige Azure-Dienste nicht aktivieren, wenn sie standardmäßig nicht aktiviert ist. Dadurch werden alle abhängigen Dienste in den Geltungsbereich der Regeln aufgenommen.

Weitere Informationen finden Sie in der Produktdokumentation einzelner Azure-Dienste.

Private Endpunkte

Private Link bietet ihnen eine Möglichkeit, einer PaaS-Instanz eine private IP-Adresse zu geben. Der Dienst ist dann über das Internet nicht erreichbar. Private Endpunkte werden für alle SKUs nicht unterstützt.

Beachten Sie die folgenden Empfehlungen, wenn Sie private Endpunkte verwenden:

Konfigurieren Sie Dienste, die an virtuelle Netzwerke gebunden sind, um paaS-Dienste über private Endpunkte zu kontaktieren, auch wenn diese PaaS-Dienste auch öffentlichen Zugriff bieten müssen.
Fördern Sie die Verwendung von Netzwerksicherheitsgruppen für private Endpunkte, um den Zugriff auf private Endpunkt-IP-Adressen einzuschränken.
Verwenden Sie immer Dienstfirewalls, wenn Sie private Endpunkte verwenden.
Wenn Sie über einen Dienst verfügen, auf den nur über private Endpunkte zugegriffen werden kann, entfernen Sie die DNS-Konfiguration für seinen öffentlichen Endpunkt.
Berücksichtigen Sie beim Implementieren privater Endpunkte Laufzeitaspekte. Berücksichtigen Sie aber auch DevOps und Überwachungsaspekte.
Verwenden Sie Azure-Richtlinie, um die Ressourcenkonfiguration zu erzwingen.

Kompromiss: Dienst-SKUs mit privaten Endpunkten sind teuer. Private Endpunkte können Vorgänge aufgrund von Netzwerkunsicherheit erschweren. Sie müssen selbst gehostete Agents, Sprungfelder, ein VPN und andere Komponenten zu Ihrer Architektur hinzufügen.

Die DNS-Verwaltung kann in allgemeinen Netzwerktopologien komplex sein. Möglicherweise müssen Sie DNS-Weiterleitungen und andere Komponenten einführen.

Einspeisung in virtuelle Netzwerke

Sie können den Prozess zum Einfügen virtueller Netzwerke verwenden, um einige Azure-Dienste in Ihrem Netzwerk bereitzustellen. Beispiele für solche Dienste sind Azure-App Dienst, Funktionen, Azure API Management und Azure Spring Apps. Dieser Prozess isoliert die Anwendung aus dem Internet, Systemen in privaten Netzwerken und anderen Azure-Diensten. Eingehender und ausgehender Datenverkehr von der Anwendung wird basierend auf Netzwerkregeln zugelassen oder verweigert.

Azure Bastion

Sie können Azure Bastion verwenden, um eine Verbindung mit einem virtuellen Computer herzustellen, indem Sie Ihren Browser und die Azure-Portal verwenden. Azure Bastion verbessert die Sicherheit von RDP- und SSH-Verbindungen. Ein typischer Anwendungsfall umfasst das Herstellen einer Verbindung mit einem Sprungfeld im selben virtuellen Netzwerk oder einem virtuellen Peer-Netzwerk. Die Verwendung von Azure Bastion entfernt die Notwendigkeit, dass der virtuelle Computer über eine öffentliche IP-Adresse verfügt.

Azure DDoS Protection

Jede Eigenschaft in Azure wird durch den Azure DDoS-Infrastrukturschutz ohne zusätzliche Kosten und ohne zusätzliche Konfiguration geschützt. Das Schutzniveau ist einfach, aber der Schutz hat hohe Schwellenwerte. Es stellt auch keine Telemetrie oder Warnung bereit, und es ist workloadagnostisch.

Höherstufige SKUs des DDoS-Schutzes sind verfügbar, sind jedoch nicht kostenlos. Die Skalierung und Kapazität des global bereitgestellten Azure-Netzwerks bietet Schutz vor allgemeinen Netzwerkebenenangriffen. Technologien wie always-on Traffic Monitoring und Echtzeit-Entschärfung bieten diese Funktion.

Weitere Informationen finden Sie in der Übersicht über Azure DDoS Protection Standard.

Beispiel

Hier sind einige Beispiele, die die Verwendung von In diesem Artikel empfohlenen Netzwerksteuerelementen veranschaulichen.

IT-Umgebung

Dieses Beispiel baut auf der IT-Umgebung (Information Technology) auf, die in der Sicherheitsgrundlinie (SE:01) eingerichtet wurde. Dieser Ansatz bietet ein umfassendes Verständnis für Netzwerksteuerelemente, die auf verschiedenen Umkreisen angewendet werden, um den Datenverkehr einzuschränken.

Netzwerkangriffspersonas. Mehrere Personas können in einem Netzwerkangriff berücksichtigt werden, darunter Administratoren, Mitarbeiter, Kundenclients und anonyme Angreifer.
VPN-Zugriff. Ein schlechter Akteur kann über ein VPN oder eine Azure-Umgebung, die über ein VPN mit der lokalen Umgebung verbunden ist, auf die lokale Umgebung zugreifen. Konfigurieren Sie das IPSec-Protokoll, um die sichere Kommunikation zu ermöglichen.
Öffentlicher Zugriff auf die Anwendung. Verfügen Sie über eine Webanwendungsfirewall (WAF) vor der Anwendung, um sie auf Layer 7 der Netzwerk-OSI-Ebene zu schützen.
Operatorzugriff. Der Remotezugriff über Layer 4 von Netzwerk-OSI-Schichten muss gesichert werden. Erwägen Sie die Verwendung von Azure Firewall mit IDP/IDS-Features.
DDoS Protection. Verfügen Sie über DDoS-Schutz für Ihr gesamtes VNet.
Netzwerktopologie. Eine Netzwerktopologie wie Hub-Spoke, ist sicherer und optimiert Kosten. Das Hubnetzwerk bietet zentralen Firewallschutz für alle Peered Spokes.
Private Endpunkte: Erwägen Sie das Hinzufügen öffentlich verfügbarer Dienste in Ihr privates Netzwerk mithilfe privater Endpunkte. Diese erstellen eine Netzwerkkarte (Network Card, NIC) in Ihrem privaten VNet und binden an den Azure-Dienst.
TLS-Kommunikation. Schützen Sie Daten während der Übertragung, indem Sie über TLS kommunizieren.
Netzwerksicherheitsgruppe (Network Security Group, NSG): Schützen sie Segmente innerhalb eines VNet mit NSG, einer kostenlosen Ressource, die TCP/UDP-eingehende und ausgehende Kommunikation unter Berücksichtigung von IP- und Portbereichen filtert. Teil von NSG ist die Anwendungssicherheitsgruppe (Application Security Group, ASG), mit der Sie Tags für Datenverkehrsregeln für die einfachere Verwaltung erstellen können.
Log Analytics: Azure-Ressourcen geben Telemetrie aus, die in Log Analytics aufgenommen wird und dann mit einer SIEM-Lösung wie Microsoft Sentinel für die Analyse verwendet wird.
Microsoft Sentinel-Integration. Log Analytics ist in Microsoft Sentinel und andere Lösungen wie Microsoft Defender für Cloud integriert.
Microsoft Defender für Cloud: Microsoft Defender für Cloud bietet viele Workload-Schutzlösungen, einschließlich Netzwerkempfehlungen für Ihre Umgebung.
Datenverkehrsanalyse: Überwachen Sie Ihre Netzwerksteuerelemente mit Traffic Analytics. Dies wird über die Netzwerküberwachung, einen Teil von Azure Monitor und aggregiert eingehende und ausgehende Treffer in Ihren Subnetzen, die von NSG gesammelt werden.

Architektur für eine containerisierte Workload

Diese Beispielarchitektur kombiniert die in diesem Artikel beschriebenen Netzwerksteuerelemente. Das Beispiel zeigt nicht die vollständige Architektur an. Stattdessen konzentriert es sich auf Eingangssteuerelemente in der privaten Cloud.

Das Anwendungsgateway ist ein Lastenausgleich für Webdatenverkehr, den Sie zum Verwalten des Datenverkehrs zu Ihren Webanwendungen verwenden können. Sie stellen das Anwendungsgateway in einem dedizierten Subnetz bereit, das Über Steuerelemente für Netzwerksicherheitsgruppen und Firewall-Steuerelemente für Webanwendungen verfügt.

Die Kommunikation mit allen PaaS-Diensten erfolgt über private Endpunkte. Alle Endpunkte werden in einem dedizierten Subnetz platziert. DDoS Protection schützt alle öffentlichen IP-Adressen, die für einen grundlegenden oder höheren Firewallschutz konfiguriert sind.

Der Verwaltungsdatenverkehr ist über Azure Bastion eingeschränkt, wodurch eine sichere und nahtlose RDP- und SSH-Konnektivität zu Ihren VMs direkt vom Azure-Portal über TLS bereitgestellt wird. Build-Agents werden im virtuellen Netzwerk platziert, sodass sie über eine Netzwerkansicht für Arbeitsauslastungsressourcen wie Computeressourcen, Containerregistrierungen und Datenbanken verfügen. Dieser Ansatz trägt dazu bei, eine sichere und isolierte Umgebung für Ihre Build-Agents bereitzustellen, die den Schutz für Ihren Code und Ihre Artefakte erhöht.

Netzwerksicherheitsgruppen auf Subnetzebene der Computeressourcen beschränken den Ausgehenden Datenverkehr. Das erzwungene Tunneling wird verwendet, um den gesamten Datenverkehr über die Azure Firewall zu leiten. Dieser Ansatz trägt dazu bei, eine sichere und isolierte Umgebung für Ihre Computeressourcen bereitzustellen, wodurch der Schutz für Ihre Daten und Anwendungen erhöht wird.

Checkliste für die Sicherheit

Lesen Sie den vollständigen Satz von Empfehlungen.

Checkliste für die Sicherheit

Freigeben über

Empfehlungen für Netzwerk und Konnektivität