Empfehlungen für Netzwerk und Konnektivität

Artikel
11/15/2023

Gilt für die folgende Empfehlung der Sicherheitsprüfliste für Azure Well-Architected Framework:

SE:05	Isolieren, Filtern und Steuern des Netzwerkdatenverkehrs über eingehende und ausgehende Datenflüsse hinweg. Wenden Sie tiefgehende Defense-Prinzipien an, indem Sie lokalisierte Netzwerksteuerungen an allen verfügbaren Netzwerkgrenzen sowohl im Ost-West- als auch im Nord-Süd-Datenverkehr verwenden.

In diesem Leitfaden werden die Empfehlungen für den Netzwerkentwurf 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. Neben der identitätsbasierten Zugriffssteuerung hat die Netzwerksicherheit eine hohe Priorität beim Schutz von Ressourcen. Die richtigen Netzwerksicherheitskontrollen können ein umfassendes Sicherheitselement bereitstellen, das dazu beitragen kann, Bedrohungen zu erkennen und einzudämmen und zu verhindern, dass Angreifer in Ihre Workload gelangen.

Definitionen

Begriff	Definition
Ost-West-Datenverkehr	Netzwerkdatenverkehr, der innerhalb einer vertrauenswürdigen Grenze verschoben wird.
Ausgehender Fluss	Ausgehender Workloaddatenverkehr.
Feindliches Netzwerk	Ein Netzwerk, das nicht als Teil Ihrer Workload bereitgestellt wird. Ein feindliches Netzwerk gilt als Bedrohungsvektor.
Eingehender Flow	Eingehender Workloaddatenverkehr.
Netzwerkfilterung	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 an den Grenzen Sicherheitskontrollen angewendet werden. Diese Technik trägt dazu bei, Ressourcen vor feindlichen Netzwerken wie dem Internet zu schützen.
Netzwerktransformation	Ein Mechanismus, der Netzwerkpakete mutiert, um sie zu verdecken.
Nord-Süd-Verkehr	Netzwerkdatenverkehr, der von einer vertrauenswürdigen Grenze zu potenziell feindseligen externen Netzwerken wechselt und umgekehrt.

Wichtige Entwurfsstrategien

Die Netzwerksicherheit verwendet Verschleierung, um Workloadressourcen vor feindlichen Netzwerken zu schützen. Ressourcen, die sich hinter einer Netzwerkgrenze befinden, werden ausgeblendet, bis die Begrenzungssteuerelemente den Datenverkehr als sicher markieren. Der Entwurf der Netzwerksicherheit basiert auf drei Standard Strategien:

Segment. Diese Technik isoliert den Datenverkehr in separaten Netzwerken, indem Grenzen hinzugefügt werden. Beispielsweise übergibt Datenverkehr zu und von einer Anwendungsebene eine Grenze für die Kommunikation mit anderen Ebenen, die unterschiedliche Sicherheitsanforderungen haben. Segmentierungsebenen verwirklichen den Defense-in-Depth-Ansatz.

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

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

Sie können auch andere logische Grenzen verwenden, z. B. herausgeschnittene Subnetze innerhalb eines virtuellen Netzwerks. Ein Vorteil von Subnetzen besteht darin, dass Sie sie verwenden können, um Ressourcen zu gruppieren, die sich innerhalb einer Isolationsgrenze befinden und ähnliche Sicherheitsgarantien haben. Anschließend können Sie Steuerelemente an der Grenze konfigurieren, um Datenverkehr zu filtern.
Filtern. Diese Strategie trägt dazu bei, sicherzustellen, dass Datenverkehr, der in eine Grenze eintritt, erwartet, zugelassen und sicher ist. Aus Zero-Trust Perspektive überprüft die Filterung explizit alle verfügbaren Datenpunkte auf Netzwerkebene. Sie können Regeln an der Grenze platzieren, um nach bestimmten Bedingungen zu suchen.

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

Klassifizieren der Datenverkehrsflüsse

Der erste Schritt beim Klassifizieren von Flows besteht darin, ein Schema Ihrer Workloadarchitektur zu untersuchen. Bestimmen Sie im Schema die Absicht und die Merkmale des Flows im Hinblick auf den funktionalen Nutzen und die betrieblichen Aspekte Ihrer Workload. Verwenden Sie die folgenden Fragen, um den Flow zu klassifizieren:

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

Es gibt viele Möglichkeiten, Datenverkehrsflüsse zu klassifizieren. In den folgenden Abschnitten werden häufig verwendete Kriterien erläutert.

Sichtbarkeit von externen Netzwerken

Öffentlich. Eine Workload ist öffentlich zugänglich, wenn ihre Anwendung und andere Komponenten über das öffentliche Internet erreichbar sind. Die Anwendung wird über eine oder mehrere öffentliche IP-Adressen und öffentliche DNS-Server (Domain Name System) verfügbar gemacht.
Privat. Eine Workload ist privat, wenn auf sie 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 möglicherweise über einen privaten DNS-Server verfügbar gemacht.

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

Achten Sie auch bei öffentlichen Workloads darauf, einen möglichst privaten Teil der Workload zu halten. Dieser Ansatz erzwingt, dass Pakete eine private Grenze überschreiten, wenn sie aus einem öffentlichen Netzwerk eingehen. Ein Gateway in diesem Pfad kann als Übergangspunkt fungieren, indem es als Reverseproxy fungiert.

Richtung des Datenverkehrs

Eingang: Eingehender Datenverkehr ist eingehender Datenverkehr, der zu einer Workload oder ihren Komponenten fließt. Wenden Sie zum Schutz des Eingangs die oben genannten 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 überprüfen, können erfolgreich in Ihre Schutzmaßnahmen eindringen, wenn Sie den Eingang nicht überprüfen oder grundlegende Netzwerksicherheitsmaßnahmen implementieren.
Ausgehend. Ausgehender Datenverkehr ist ausgehender Datenverkehr, der von einer Workload oder ihren Komponenten entfernt wird. Um den ausgehenden Datenverkehr zu überprüfen, bestimmen Sie, wohin der Datenverkehr geht und ob das Ziel erwartet, zugelassen und sicher ist. Das Ziel kann böswillig sein oder mit Datenexfiltrationsrisiken verbunden sein.

Sie können auch Die Höhe der Gefährdung bestimmen, indem Sie die Nähe Ihrer Workload zum öffentlichen Internet berücksichtigen. Beispielsweise werden von der Anwendungsplattform in der Regel öffentliche IP-Adressen bereitgestellt. 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 jedes andere Netzwerk sein, das außerhalb Ihres Kontrollbereichs liegt.

Ein- und Ausgehender Verkehr kann sowohl Nord-Süd-Verkehr sein.

Betrachten Sie als Beispiel den ausgehenden Fluss einer Hub-Spoke-Netzwerktopologie. Sie können den Netzwerkrand Ihrer Workload definieren, sodass der Hub ein externes Netzwerk ist. In diesem Fall ist ausgehender Datenverkehr aus dem virtuellen Netzwerk des Spokes Nord-Süd-Datenverkehr. Wenn Sie jedoch das Hubnetzwerk in Ihrem Kontrollbereich betrachten, wird der Nord-Süd-Datenverkehr auf die Firewall im Hub ausgeweitet, da der nächste Hop das Internet ist, das potenziell feindselig ist.
Ost-West. Datenverkehr, der innerhalb eines Workloadnetzwerks fließt, ist Ost-West-Datenverkehr. Diese Art von Datenverkehr ergibt sich, wenn Komponenten in Ihrer Workload miteinander kommunizieren. Ein Beispiel ist der Datenverkehr zwischen den Ebenen einer n-Ebenen-Anwendung. In Microservices ist die Service-to-Service-Kommunikation Ost-West-Datenverkehr.

Um die Umfassende Verteidigung zu gewährleisten, behalten Sie die End-to-End-Kontrolle der Sicherheitsangebote bei, die in jedem Hop enthalten sind oder die Sie verwenden, wenn Pakete interne Segmente kreuzen. Unterschiedliche Risikostufen erfordern unterschiedliche Risikobehebungsmethoden.

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

Hinweis

Identität ist immer der primäre Umkreis. Die Zugriffsverwaltung muss auf Netzwerkflows angewendet werden. Verwenden Sie verwaltete Identitäten, wenn Sie die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) von Azure zwischen Komponenten Ihres Netzwerks verwenden.

Führen Sie nach der Klassifizierung von Flows eine Segmentierungsübung durch, um Firewallinjektionspunkte auf den Kommunikationspfaden Ihrer Netzwerksegmente zu identifizieren. Wenn Sie Ihre Netzwerkverteidigung über alle Segmente und alle Datenverkehrstypen hinweg eingehend entwerfen, gehen Sie von einer Sicherheitsverletzung an allen Stellen aus. Verwenden Sie eine Kombination aus verschiedenen lokalisierten Netzwerksteuerelementen 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 eingehenden und ausgehenden Datenverkehr. Um Bedrohungen zu erkennen oder zu blockieren, muss eine Edgestrategie so viele Angriffe wie möglich auf und aus dem Internet abschwächen.

Senden Sie für ausgehenden Datenverkehr den gesamten internetgebundenen Datenverkehr über eine einzige Firewall, die eine verbesserte Überwachung, Governance und Kontrolle des Datenverkehrs ermöglicht. Erzwingen Sie beim Eingehenden, dass der gesamte Datenverkehr aus dem Internet über ein virtuelles netzwerkinternes Anwendung (NVA) oder eine Webanwendungsfirewall geleitet wird.

Firewalls sind in der Regel Singletons, die pro Region in einem organization bereitgestellt werden. Daher werden sie von Workloads gemeinsam genutzt und sind im Besitz eines zentralen Teams. Stellen Sie sicher, dass alle von Ihnen verwendeten NVAs so konfiguriert sind, dass sie die Anforderungen Ihrer Workload unterstützen.
Es wird empfohlen, native Azure-Steuerelemente so weit wie möglich zu verwenden.

Zusätzlich zu nativen Steuerelementen können Sie auch Partner-NVAs in Betracht ziehen, die erweiterte oder spezialisierte Features bieten. Partnerfirewall- und Web Application Firewall-Anbieterprodukte sind in Azure Marketplace verfügbar.

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

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

Alle technologischen Optionen, die Sie in Betracht ziehen, sollten Sicherheitskontrollen und -überwachungen sowohl für eingehende als auch für ausgehende Flows bereitstellen. Informationen zu optionen, die für Azure verfügbar sind, finden Sie im Abschnitt Edge-Sicherheit in diesem Artikel.

Entwerfen der Sicherheit virtueller Netzwerke und Subnetze

Das Hauptziel einer privaten Cloud besteht darin, Ressourcen aus dem öffentlichen Internet zu verschleiern. 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 Netzwerksicht auch innerhalb Ihrer eigenen privaten Netzwerke.
Minimieren Sie die Anzahl öffentlicher DNS-Einträge, die Sie verwenden, um weniger Ihrer Workload verfügbar zu machen.
Fügen Sie ein- und ausgehende Netzwerkflusssteuerung hinzu. Lassen Sie keinen Datenverkehr zu, der nicht vertrauenswürdig ist.

Segmentierungsstrategie

Um die Netzwerktransparenz zu minimieren, segmentieren Sie Ihr Netzwerk, und beginnen Sie mit 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 segmentieren, indem Sie Subnetze erstellen. Die Kriterien für die Aufteilung sollten beabsichtigt sein. Wenn Sie Dienste in einem Subnetz zusammenordnen, stellen Sie sicher, dass diese Dienste einander sehen können.

Sie können ihre Segmentierung auf viele Faktoren stützen. Beispielsweise können Sie verschiedene Anwendungsebenen in dedizierten Segmenten platzieren. Ein weiterer Ansatz besteht darin, Ihre Subnetze basierend auf gängigen 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 überprüfen. Verwenden Sie die drei Standard Strategien, die weiter oben in diesem Artikel unter Schlüsselentwurfsstrategien erläutert wurden. Überprüfen Sie, ob der Flow 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 einen Subnetzentwurf finden Sie unter Azure Virtual Network Subnetzen.

Verwenden von Steuerelementen auf Komponentenebene

Nachdem Sie die Sichtbarkeit Ihres Netzwerks minimiert haben, ordnen Sie Ihre Azure-Ressourcen aus der Netzwerkperspektive ab, und bewerten Sie die Flows. Die folgenden Arten von Flows sind möglich:

Geplanter Datenverkehr oder absichtliche Kommunikation zwischen Diensten gemäß Ihrem Architekturentwurf. Beispielsweise haben Sie Datenverkehr geplant, wenn Ihre Architektur empfiehlt, dass Azure Functions Nachrichten von Azure Service Bus abruft.
Verwalten von Datenverkehr oder Kommunikation, die als Teil der Funktionalität des Diensts erfolgt. Dieser Datenverkehr ist nicht Teil Ihres Entwurfs, 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.

Die Unterscheidung zwischen geplantem Und Verwaltungsdatenverkehr hilft Ihnen, lokalisierte Steuerelemente oder Steuerelemente auf Dienstebene zu erstellen. Haben Sie ein gutes Verständnis der Quelle und des Ziels bei jedem Hop. Verstehen Sie insbesondere, wie Ihre Datenebene verfügbar gemacht wird.

Bestimmen Sie als Ausgangspunkt, ob die einzelnen Dienste für das Internet verfügbar gemacht werden. Wenn dies der Grund ist, planen Sie, wie Sie den Zugriff einschränken. Wenn dies nicht der Fall ist, platzieren Sie sie in einem virtuellen Netzwerk.

Dienstfirewalls

Wenn Sie erwarten, dass ein Dienst im 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 PaaS-Diensten (Platform-as-a-Service)

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 es anderen Ressourcen im Netzwerk, mit dem PaaS-Dienst über die private IP-Adresse zu kommunizieren.

Die Kommunikation mit einem PaaS-Dienst erfolgt über die öffentliche IP-Adresse und den DNS-Eintrag des Diensts. Diese Kommunikation erfolgt über das Internet. Sie können diese Kommunikation privat gestalten.

Ein Tunnel vom PaaS-Dienst in eines 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 links den Fluss für öffentlich zugängliche Endpunkte. Auf der rechten Seite wird dieser Flow mithilfe privater 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 ist, dass Sie die Ports an der Firewall nicht für ausgehenden Datenverkehr öffnen müssen. Private Endpunkte sperren den gesamten ausgehenden Datenverkehr am Port für das öffentliche Internet. Die Konnektivität ist auf Ressourcen innerhalb des Netzwerks beschränkt.

Kompromiss: Azure Private Link ist ein kostenpflichtiger Dienst mit Zählern für eingehende und ausgehende Daten, die verarbeitet werden. Außerdem werden Ihnen private Endpunkte in Rechnung gestellt.

Schutz vor DDoS-Angriffen (Distributed Denial of Service)

Ein DDoS-Angriff versucht, die Ressourcen einer Anwendung zu erschö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 zu lokalisieren und zu blockieren.

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

Azure-Erleichterung

Sie können die folgenden Azure-Dienste verwenden, um Ihrem Netzwerk Defense-in-Depth-Funktionen hinzuzufügen.

Azure Virtual Network

Virtual Network unterstützt Ihre Azure-Ressourcen bei der sicheren Kommunikation untereinander, im Internet und in 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.

Virtual Network bietet Funktionen zum Filtern von Datenverkehr. Sie können den Zugriff auf der Ebene des virtuellen Netzwerks einschränken, indem Sie eine benutzerdefinierte Route (UDR) und eine Firewallkomponente verwenden. Auf Subnetzebene können Sie Datenverkehr mithilfe von Netzwerksicherheitsgruppen filtern.

Edgesicherheit

Standardmäßig werden eingehende und ausgehende Daten über öffentliche IP-Adressen übertragen. Je nach Dienst oder Topologie legen Sie entweder diese Adressen fest oder Azure weist sie zu. Weitere Ein- und Ausgehende Möglichkeiten sind das Übergeben von Datenverkehr über ein Load Balancer- oder NAT-Gateway (Network Address Translation). Diese Dienste sind jedoch für die Verteilung des Datenverkehrs und nicht unbedingt für die Sicherheit bestimmt.

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. Sie stellen in der Regel Azure Firewall als ausgehende Firewall bereit, die als letztes Sicherheitsgate fungiert, bevor der Datenverkehr ins Internet fließt. Azure Firewall können 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 von Azure Firewall umfasst Folgendes:
- Zielnetzwerkadressübersetzung (DNAT) oder Portweiterleitung.
- Signaturerkennung von Intrusion Detection and Prevention System (IDPS)
- Starke Netzwerkregeln für Ebene 3, Ebene 4 und vollqualifizierte Domänennamen (FQDN).
Hinweis

Die meisten Organisationen verfügen über eine Tunnelerzwingrichtlinie, die den Datenverkehr dazu zwingt, durch eine NVA zu fließen.

Wenn Sie keine Virtual WAN-Topologie verwenden, müssen Sie eine UDR mit einem NextHopType von Internet für die private IP-Adresse Ihres NVA bereitstellen. UDRs werden auf Subnetzebene angewendet. Standardmäßig fließt Subnetz-zu-Subnetz-Datenverkehr nicht über die NVA.

Sie können auch Azure Firewall gleichzeitig für den Eingangseingang verwenden. Es kann HTTP- und HTTPS-Datenverkehr weiterleiten. In skUs mit höheren Ebenen bietet Azure Firewall eine TLS-Terminierung, sodass Sie Inspektionen auf Nutzlastebene implementieren können.

Die folgenden Methoden werden empfohlen:
- Aktivieren Sie Diagnose Einstellungen in Azure Firewall, um Datenverkehrsflussprotokolle, IDPS-Protokolle und DNS-Anforderungsprotokolle zu sammeln.
- Seien Sie in Regeln so spezifisch wie möglich.
- Wenn es praktisch ist, vermeiden Sie 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 über die Lebensdauer der IP-Gruppe dieselben Regeln aufweisen müssen. IP-Gruppen sollten Ihre Segmentierungsstrategie widerspiegeln.
- Überschreiben Sie die FQDN-Zulassungsregel der Infrastruktur nur, wenn Ihre Workload eine absolute Ausgangssteuerung erfordert. Das Außerkraftsetzung dieser Regel ist mit einem Kompromiss zwischen zuverlässigkeit und zuverlässigkeitsbedingt, da sich die Anforderungen der Azure-Plattform für Dienste ändern.
Kompromiss: Azure Firewall können sich auf Ihre Leistung auswirken. Regelreihenfolge, Menge, TLS-Überprüfung und andere Faktoren können zu erheblicher Latenz führen.

Es kann sich auch auf die Zuverlässigkeit Ihrer Workload auswirken. Es kann zu einer Portauslastung für die Quellnetzwerkadressenübersetzung (Source Network Address Translation, SNAT) kommen. Fügen Sie bei Bedarf öffentliche IP-Adressen hinzu, um dieses Problem zu beheben.

Risiko: Für ausgehenden Datenverkehr weist Azure eine öffentliche IP-Adresse zu. Diese Zuweisung kann sich nachgelagert auf Ihr externes Sicherheitsgate auswirken.
Azure Web Application Firewall. 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. Azure Web Application Firewall bietet auch andere Sicherheitsfeatures, die sich auf Ebene 7 konzentrieren, z. B. Ratenbegrenzung, SQL-Einschleusungsregeln und standortübergreifende Skripterstellung.

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

Sie können Azure Web Application Firewall mit Routern wie Azure Application Gateway oder Azure Front Door integrieren. Azure Web Application Firewall Implementierungen 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 Edgesicherheitslösung stehen verschiedene Optionen zur Verfügung. Beispiele finden Sie unter Firewall und Application Gateway für virtuelle Netzwerke.

Netzwerksicherheitsgruppen

Eine Netzwerksicherheitsgruppe ist eine Firewall der Ebene 3 und 4, die Sie auf der Ebene des Subnetzes oder der Netzwerkschnittstelle Karte (NIC) anwenden. Netzwerksicherheitsgruppen werden nicht standardmäßig erstellt oder angewendet.

Netzwerksicherheitsgruppenregeln fungieren als Firewall , um Datenverkehr zu beenden, der im Umkreis eines Subnetzes ein- und ausfließt. Eine Netzwerksicherheitsgruppe verfügt über einen Standardregelsatz, der übermäßig freizügig 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 oder eingehenden Datenverkehr:
- Virtueller Netzwerkdatenverkehr aus direkten, Peering- und VPN-Gatewayquellen ist zulässig.
- Azure Load Balancer Integritätstests sind zulässig.
- Sämtlicher anderer Datenverkehr wird blockiert.
Für ausgehenden oder ausgehenden Datenverkehr:
- Virtueller Netzwerkdatenverkehr für Direkte, Peering- und VPN-Gatewayziele ist zulässig.
- Datenverkehr ins Internet ist zulässig.
- Sämtlicher anderer Datenverkehr wird blockiert.

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

Protocol
Quell-IP-Adresse
Quellport
IP-Zieladresse
Zielport

Die fehlende Unterstützung für FQDN schränkt die Funktionalität von Netzwerksicherheitsgruppen ein. Sie müssen bestimmte IP-Adressbereiche für Ihre Workload angeben, die schwer zu verwalten sind.

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 an Azure übertragen wird. Sie können auch eine Anwendungssicherheitsgruppe als Zieltyp zuweisen, an den Datenverkehr weitergeleitet werden soll. Dieser Typ der benannten Gruppe enthält Ressourcen, die ähnliche Anforderungen an eingehenden oder ausgehenden Zugriff haben.

Risiko: Die Servicetag-Bereiche sind sehr breit, sodass sie für eine möglichst große Kundenspanne geeignet sind. Updates zu Diensttags hinter Änderungen im Dienst zurück.

In der obigen Abbildung werden Netzwerksicherheitsgruppen auf die NIC angewendet. Internetdatenverkehr und Subnetz-zu-Subnetz-Datenverkehr werden verweigert. Die Netzwerksicherheitsgruppen werden mit dem VirtualNetwork Tag angewendet. In diesem Fall haben also die Subnetze von Peeringnetzwerken eine direkte Sichtverbindung. 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. Bei diesem 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 lassen in der Regel Datenverkehr von allen Hostingworkloads wie AzureFrontDoor.Backendoder von Azure zu, um Dienstruntimes zu unterstützen, z LogicAppsManagement. B. . Analog dazu ermöglichen ausgehende Tags Datenverkehr zu allen Hostingworkloads oder aus Azure, um Dienstruntimes zu unterstützen.

Die Regeln so weit wie möglich festlegen. Im folgenden Beispiel wird die Regel auf bestimmte Werte festgelegt. Jeder andere Datenverkehrstyp wird verweigert.

Informationen	Beispiel
Protocol	TCP (Transmission Control Protocol), UDP
Quell-IP-Adresse	Zulassen des Eingangs in das Subnetz aus dem <Quell-IP-Adressbereich>: 4575/UDP
Quellport	Eingehenden Eingang in das Subnetz aus dem <Diensttag> zulassen: 443/TCP
IP-Zieladresse	Ausgehende Daten aus dem Subnetz zum <Ziel-IP-Adressbereich> zulassen: 443/TCP
Zielport	Ausgehende Daten aus dem Subnetz zum <Diensttag> zulassen: 443/TCP

Zusammenfassung:

Seien Sie beim Erstellen von Regeln präzise. Lassen Sie nur Datenverkehr zu, der für die Funktion Ihrer Anwendung erforderlich ist. Alles andere verweigern. Bei diesem Ansatz wird die Netzwerksichtlinie auf Netzwerkflows 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 die Oberfläche.

Das Einschränken des Datenverkehrs bedeutet nicht, dass zulässige Flows den Bereich eines Angriffs sprengen. Da Netzwerksicherheitsgruppen auf den Ebenen 3 und 4 des OSI-Stapels (Open Systems Interconnection) arbeiten, enthalten sie nur Form- 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 an Port 53 an einen anderen Dienst exfiltrieren.
Verstehen Sie, dass Netzwerksicherheitsgruppen geringfügig voneinander abweichen können. Es ist leicht, 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.
- Das Hinzufügen einer Netzwerksicherheitsgruppe entsperrt viele Diagnose Tools, z. B. Flowprotokolle und Netzwerkdatenverkehranalysen.
- Verwenden Sie Azure Policy, um den Datenverkehr in Subnetzen ohne Netzwerksicherheitsgruppen zu steuern.
Wenn ein Subnetz Netzwerksicherheitsgruppen unterstützt, fügen Sie eine Gruppe hinzu, auch wenn dies nur minimale Auswirkungen hat.

Azure-Dienstfirewalls

Die meisten Azure-Dienste bieten eine Firewall auf Dienstebene. Dieses Feature überprüft eingehenden Datenverkehr an den Dienst aus angegebenen CIDR-Bereichen (Classless Inter-Domain Routing). Diese Firewalls bieten Vorteile:

Sie bieten ein grundlegendes Maß an Sicherheit.
Es gibt eine tolerierbare Auswirkung auf die Leistung.
Die meisten Dienste bieten diese Firewalls ohne zusätzliche Kosten an.
Die Firewalls geben Protokolle über Azure Diagnose aus, was für die Analyse von Zugriffsmustern nützlich sein kann.

Es gibt jedoch auch Sicherheitsbedenken im Zusammenhang mit diesen Firewalls, 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 möglicherweise missbrauchen.

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 Policy verwenden, um sie zu aktivieren. Stellen Sie sicher, dass Sie die Option vertrauenswürdige Azure-Dienste nicht aktivieren, wenn sie nicht standardmäßig aktiviert ist. Dadurch werden alle abhängigen Dienste in den Geltungsbereich der Regeln integriert.

Weitere Informationen finden Sie in der Produktdokumentation zu einzelnen Azure-Diensten.

Private Endpunkte

Private Link bietet Ihnen die Möglichkeit, einem PaaS-instance eine private IP-Adresse zu geben. Der Dienst ist dann über das Internet nicht erreichbar. Private Endpunkte werden nicht für alle SKUs 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 IP-Adressen privater Endpunkte 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 nach Möglichkeit die DNS-Konfiguration für den öffentlichen Endpunkt.
Berücksichtigen Sie beim Implementieren privater Endpunkte Laufzeitprobleme . Berücksichtigen Sie aber auch DevOps- und Überwachungsaspekte.
Verwenden Sie Azure Policy, um die Ressourcenkonfiguration zu erzwingen.

Kompromiss: Dienst-SKUs mit privaten Endpunkten sind teuer. Private Endpunkte können Vorgänge aufgrund der Netzwerkverschleierung erschweren. Sie müssen Ihrer Architektur selbstgehostete Agents, Jumpboxen, ein VPN und andere Komponenten hinzufügen.

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

Einspeisung in virtuelle Netzwerke

Sie können den Einschleusungsprozess für virtuelle Netzwerke verwenden, um einige Azure-Dienste in Ihrem Netzwerk bereitzustellen. Beispiele für solche Dienste sind Azure App Service, Functions, Azure API Management und Azure Spring Apps. Bei diesem Prozess wird die Anwendung vom Internet, systemen in privaten Netzwerken und anderen Azure-Diensten isoliert. 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 einer Jumpbox im selben virtuellen Netzwerk oder einem virtuellen Netzwerk mit Peering. Wenn Sie Azure Bastion verwenden, muss der virtuelle Computer nicht mehr über eine öffentliche IP-Adresse verfügen.

Azure DDoS Protection

Jede Eigenschaft in Azure wird ohne zusätzliche Kosten und ohne zusätzliche Konfiguration durch azure DDoS-Infrastrukturschutz geschützt. Das Schutzniveau ist einfach, aber der Schutz hat hohe Schwellenwerte. Es bietet auch keine Telemetrie oder Warnungen und ist workloadunabhängig.

Höherstufige SKUs von DDoS Protection sind verfügbar, aber nicht kostenlos. Die Größe und Kapazität des global bereitgestellten Azure-Netzwerks bietet Schutz vor allgemeinen Angriffen auf Netzwerkebene. Technologien wie die Überwachung des always-on-Datenverkehrs und die Risikominderung in Echtzeit bieten diese Funktion.

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

Beispiel

Hier finden Sie einige Beispiele, die die Verwendung von Netzwerksteuerelementen veranschaulichen, die in diesem Artikel empfohlen werden.

IT-Umgebung

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

Personas für Netzwerkangriffe. Bei einem Netzwerkangriff können mehrere Personas in Betracht gezogen werden, darunter Administratoren, Mitarbeiter, Kundenclients und anonyme Angreifer.
VPN-Zugriff. Ein fehlerhafter 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 mit dem IPSec-Protokoll, um die sichere Kommunikation zu ermöglichen.
Öffentlicher Zugriff auf die Anwendung. Sie verfügen über eine Web Application Firewall (WAF) vor der Anwendung, um sie auf Ebene 7 der Netzwerk-OSI-Schicht zu schützen.
Operatorzugriff. Der Remotezugriff über Ebene 4 der Netzwerk-OSI-Ebenen muss gesichert werden. Erwägen Sie, Azure Firewall mit IDP/IDS-Features zu verwenden.
DDoS Protection. Verfügen Sie über DDoS-Schutz für Ihr gesamtes VNET.
Netzwerktopologie. Eine Netzwerktopologie wie Hub-Spoke ist sicherer und optimiert die Kosten. Das Hubnetzwerk bietet zentralisierten Firewallschutz für alle Spokes mit Peering.
Private Endpunkte: Erwägen Sie das Hinzufügen öffentlich verfügbarer Dienste zu Ihrem privaten Netzwerk mithilfe privater Endpunkte. Dadurch wird eine Netzwerkkarte (Network Card, NIC) in Ihrem privaten VNET erstellt und an den Azure-Dienst gebunden.
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 eingehende und ausgehende TCP/UDP-Kommunikation unter Berücksichtigung von IP- und Portbereichen filtert. Teil der NSG ist die Application Security Group (ASG), mit der Sie Tags für Datenverkehrsregeln erstellen können, um die Verwaltung zu vereinfachen.
Log Analytics: Azure-Ressourcen geben Telemetriedaten aus, die in Log Analytics erfasst und dann mit einer SIEM-Lösung wie Microsoft Sentinel für die Analyse verwendet werden.
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 Workloadschutzlösungen, einschließlich Netzwerkempfehlungen für Ihre Umgebung.
Traffic Analytics: Überwachen Sie Ihre Netzwerksteuerungen mit Traffic Analytics. Dies wird über Network Watcher konfiguriert, teil von Azure Monitor, und aggregiert eingehende und ausgehende Treffer in Ihren Subnetzen, die von der NSG erfasst werden.

Architektur für eine Containerworkload

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

Application Gateway ist ein Lastenausgleich für Webdatenverkehr, mit dem Sie den Datenverkehr zu Ihren Webanwendungen verwalten können. Sie stellen Application Gateway in einem dedizierten Subnetz bereit, das über Netzwerksicherheitsgruppensteuerelemente und Firewallsteuerelemente für Webanwendungen verfügt.

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

Der Verwaltungsdatenverkehr wird über Azure Bastion eingeschränkt, wodurch eine sichere und nahtlose RDP- und SSH-Konnektivität für Ihre VMs direkt aus dem Azure-Portal über TLS bereitgestellt wird. Build-Agents werden im virtuellen Netzwerk platziert, sodass sie eine Netzwerkansicht für Workloadressourcen wie Computeressourcen, Containerregistrierungen und Datenbanken haben. 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 schränken ausgehenden Datenverkehr ein. Erzwungenes Tunneling wird verwendet, um den gesamten Datenverkehr über Azure Firewall weiterzuleiten. Dieser Ansatz trägt dazu bei, eine sichere und isolierte Umgebung für Ihre Computeressourcen bereitzustellen, was den Schutz Für Ihre Daten und Anwendungen erhöht.

Checkliste für die Sicherheit

Weitere Informationen finden Sie im vollständigen Satz von Empfehlungen.

Checkliste für die Sicherheit

Empfehlungen für Netzwerk und Konnektivität