Freigeben über

Anwenden von Zero Trust-Prinzipien auf das Verschlüsseln von Azure-basierter Netzwerkkommunikation

  • Artikel

Dieser Artikel bietet Anleitungen zum Anwenden der Prinzipien von Zero Trust für das Verschlüsseln der Netzwerkkommunikation zu, von und zwischen Azure-Umgebungen auf die folgenden Arten.

Zero Trust-Prinzip Definition Erfüllt von
Explizit verifizieren Authentifizieren und autorisieren Sie immer basierend auf allen verfügbaren Datenpunkten. Verwenden von Richtlinien für bedingten Zugriff für Ihre Azure VPN Gateway-Verbindungen sowie Secure Shell (SSH) und Remotedesktopprotokoll (RDP) für Ihre Verbindungen zwischen Benutzern und virtuellen Computern.
Geringstmögliche Zugriffsberechtigungen verwenden Beschränken Sie den Benutzerzugriff mit Just-In-Time- und Just-Enough-Access (JIT/JEA), risikobasierten adaptiven Richtlinien und Datenschutz. Konfigurieren Ihrer Microsoft Enterprise Edge-Geräte (MSEE) für die Verwendung von statischen Connectivity Association Keys (CAK) für Azure ExpressRoute mit Direktanschlüssen und Verwenden der verwalteten Identität zur Authentifizierung von ExpressRoute-Leitungsressourcen.
Von einer Sicherheitsverletzung ausgehen Minimieren Sie Auswirkungsgrad und Segmentzugriff. Überprüfen Sie die End-to-End-Verschlüsselung, und verwenden Sie Analysen, um für Transparenz zu sorgen, die Bedrohungserkennung voranzutreiben und die Abwehr zu verbessern. Schützen des Netzwerkdatenverkehrs mit Verschlüsselungsmethoden und Protokollen, die die Vertraulichkeit, Integrität und Authentizität Ihrer Daten während der Übertragung bereitstellen.

Verwenden von Azure Monitor zum Bereitstellen von ExpressRoute-Netzwerkleistungsmetriken und Warnungen.

Verwenden von Azure Bastion zum Verwalten einzelner Sitzungen über den Bastion-Dienst und Löschen oder Erzwingen einer Verbindung.

Dieser Artikel ist Teil einer Reihe von Artikeln, die veranschaulichen, wie die Prinzipien von Zero Trust für Azure-Netzwerke angewendet werden.

Verschlüsselungsebenen für Netzwerkdatenverkehr:

  • Verschlüsselung der Netzwerkschicht

    • Sichern und Überprüfen der Kommunikation aus dem Internet oder im lokalen Netzwerk zu Azure-VNets und virtuellen Computern

    • Sichern und Überprüfen der Kommunikation innerhalb von und zwischen Azure-VNets

  • Verschlüsselung der Anwendungsschicht

    • Schutz für Azure-Webanwendungen

  • Schutz für Workloads, die auf VMs ausgeführt werden

Referenzarchitektur

Das folgende Diagramm zeigt die Referenzarchitektur für diese Zero Trust-Anleitung für die verschlüsselte Kommunikation zwischen Benutzern und Administratoren (lokal oder im Internet) und Komponenten. Es bezieht sich auf die Azure-Umgebung für die in diesem Artikel beschriebenen Schritte.

Diagramm der Referenzarchitektur für die Azure-Netzwerkkomponenten mit angewendeter Verschlüsselung und angewendeten Zero Trust-Prinzipien.

Die Zahlen im Diagramm entsprechen den Schritten in den folgenden Abschnitten.

Was ist in diesem Artikel enthalten?

Zero Trust-Prinzipien werden in der gesamten Referenzarchitektur angewendet, von Benutzern und Administratoren im Internet oder im lokalen Netzwerk bis zur Azure-Cloud und innerhalb der Cloud. In der folgenden Tabelle werden die Empfehlungen für die Sicherstellung der Verschlüsselung des Netzwerkdatenverkehrs in dieser Architektur beschrieben.

Schritt Task Es gelten die Zero Trust-Prinzipien
1 Implementieren der Verschlüsselung in der Netzwerkschicht Explizit verifizieren
Verwenden des Zugriffs mit den geringsten Rechten
Von einer Sicherheitsverletzung ausgehen
2 Sichern und Überprüfen der Kommunikation von einem lokalen Netzwerk zu Azure-VNets Explizit verifizieren
Von einer Sicherheitsverletzung ausgehen
3 Sichern und Überprüfen der Kommunikation innerhalb von und zwischen Azure-VNets Von einer Sicherheitsverletzung ausgehen
4 Implementieren der Verschlüsselung in der Anwendungsschicht Explizit verifizieren
Von einer Sicherheitsverletzung ausgehen
5 Schützen virtueller Azure-Computer mit Azure Bastion Von einer Sicherheitsverletzung ausgehen

Schritt 1: Implementieren der Verschlüsselung in der Netzwerkschicht

Die Verschlüsselung der Netzwerkschicht ist wichtig, wenn Sie Zero Trust-Prinzipien auf Ihre lokale und Azure-Umgebung anwenden. Wenn der Netzwerkdatenverkehr über das Internet geleitet wird, sollten Sie immer davon ausgehen, dass es eine Möglichkeit für das Abfangen von Datenverkehr durch Angreifer gibt und dass Ihre Daten offengelegt oder manipuliert werden, bevor sie ihr Ziel erreichen. Da Dienstanbieter steuern, wie Daten über das Internet weitergeleitet werden, sollten Sie sicherstellen, dass der Datenschutz und die Integrität Ihrer Daten ab dem Moment, in dem sie Ihr lokales Netzwerk verlassen, bis in die Microsoft-Cloud beibehalten werden.

Das folgende Diagramm zeigt die Referenzarchitektur für die Implementierung der Netzwerkschichtverschlüsselung.

Diagramm der Referenzarchitektur für die Implementierung der Netzwerkschichtverschlüsselung für Azure-Netzwerke.

In den nächsten beiden Abschnitten werden die Internetprotokollsicherheit (Internet Protocol Security, IPsec) und Media Access Control Security (MACsec) erläutert, welche Azure-Netzwerkdienste diese Protokolle unterstützen und wie Sie sicherstellen können, dass sie verwendet werden.

IPsec

IPsec ist eine Gruppe von Protokollen, die Sicherheit für die IP-Kommunikation (Internet Protocol) bereitstellt. Hiermit werden Netzwerkpakete mithilfe einer Reihe von Verschlüsselungsalgorithmen authentifiziert und verschlüsselt. IPSec ist das Sicherheitskapselungsprotokoll, das zum Einrichten virtueller privater Netzwerke (VPNs) verwendet wird. Ein IPsec-VPN-Tunnel besteht aus zwei Phasen: Phase 1, die als Hauptmodus, und Phase 2, die als Schnellmodus bezeichnet wird.

Phase 1 von IPsec ist die Tunneleinrichtung, bei der Peers Parameter für die IKE-Sicherheitszuordnung (Internet Key Exchange, Internetschlüsselaustausch) aushandeln, z. B. Verschlüsselung, Authentifizierung, Hashing und Diffie-Hellman-Algorithmen. Um ihre Identitäten zu überprüfen, tauschen Peers einen zuvor geteilten Schlüssel aus. Phase 1 von IPsec kann in zwei Modi ausgeführt werden: Hauptmodus oder aggressiver Modus. Azure VPN Gateway unterstützt zwei Versionen von IKE, IKEv1 und IKEv2, und wird nur im Hauptmodus ausgeführt. Der Hauptmodus stellt die Verschlüsselung der Identität der Verbindung zwischen Azure VPN Gateway und dem lokalen Gerät sicher.

In Phase 2 von IPsec verhandeln die Peers Sicherheitsparameter für die Datenübertragung. In dieser Phase stimmen beide Peers den Verschlüsselungs- und Authentifizierungsalgorithmen, dem Lebensdauerwert der Sicherheitszuordnung (Security Association, SA) und den Datenverkehrsselektoren (Traffic Selectors, TS) zu, die definieren, welcher Datenverkehr über den IPsec-Tunnel verschlüsselt wird. Der in Phase 1 erstellte Tunnel dient als sicherer Kanal für diese Aushandlung. IPsec kann IP-Pakete mithilfe des Authentifizierungsheaderprotokolls (AH) oder des ESP-Protokolls (Encapsulating Security Payload) sichern. AH bietet Integrität und Authentifizierung, während ESP auch Vertraulichkeit (Verschlüsselung) bereitstellt. IPsec Phase 2 kann entweder im Transportmodus oder im Tunnelmodus ausgeführt werden. Im Transportmodus wird nur die Nutzlast des IP-Pakets verschlüsselt, während im Tunnelmodus das gesamte IP-Paket verschlüsselt und ein neuer IP-Header hinzugefügt wird. IPsec Phase 2 kann entweder auf IKEv1 oder IKEv2 aufgebaut werden. Die aktuelle IPsec-Implementierung in Azure VPN Gateway unterstützt nur ESP im Tunnelmodus.

Einige der Azure-Dienste, die IPsec unterstützen:

Es gibt keine Einstellungen, die Sie ändern müssen, um IPsec für diese Dienste zu aktivieren. Diese sind standardmäßig aktiviert.

MACsec und Azure Key Vault

MACsec (IEEE 802.1AE) ist ein Netzwerksicherheitsstandard, der das Zero Trust-Prinzip Von einer Sicherheitsverletzung ausgehen in der Netzzugangsschicht anwendet, indem Authentifizierung und Verschlüsselung über eine Ethernet-Verbindung bereitgestellt werden. MACsec geht davon aus, dass jeder Netzwerkdatenverkehr, auch im selben lokalen Netzwerk, von böswilligen Akteuren kompromittiert oder abgefangen werden kann. MACsec überprüft und schützt jeden Frame mithilfe eines Sicherheitsschlüssels, der von zwei Netzwerkschnittstellen gemeinsam genutzt wird. Diese Konfiguration kann nur zwischen zwei MACsec-fähigen Geräten erreicht werden.

MACsec wird mit Verbindungszuordnungen konfiguriert, bei denen es sich um eine Reihe von Attributen handelt, die Netzwerkschnittstellen zum Erstellen von eingehenden und ausgehenden Sicherheitskanälen verwenden. Nach der Erstellung wird der Datenverkehr über diese Kanäle über zwei MACsec-gesicherte Verbindungen ausgetauscht. MACsec verfügt über zwei Verbindungszuordnungsmodi:

  • Modus für statische Verbindungszuordnungsschlüssel (Connectivity Association Key, CAK): MACsec-gesicherte Verbindungen werden mithilfe eines vordefinierten Schlüssels eingerichtet, der einen Verbindungszuordnungsschlüsselnamen (Connectivity Association Key Name, CKN) und den zugewiesenen CAK enthält. Diese Schlüssel sind an beiden Enden der Verbindung konfiguriert.
  • Dynamischer CAK-Modus: Die Sicherheitsschlüssel werden dynamisch mithilfe des 802.1x-Authentifizierungsprozesses generiert, der ein zentralisiertes Authentifizierungsgerät wie einen RADIUS-Server (Remote Authentication Dial-In User Service) verwenden kann.

Microsoft Enterprise Edge (MSEE)-Geräte unterstützen statisches CAK, indem sie CAK und CKN in einem Azure Key Vault speichern, wenn Sie Azure ExpressRoute mit Direktanschlüssen konfigurieren. Um auf die Werte im Azure Key Vault zuzugreifen, konfigurieren Sie die verwaltete Identität zum Authentifizierender ExpressRoute-Leitungsressource. Dieser Ansatz folgt dem Zero Trust-Prinzip Geringstmögliche Zugriffsberechtigungen verwenden, da nur autorisierte Geräte über den Azure Key Vault auf die Schlüssel zugreifen können. Weitere Informationen finden Sie unter Konfigurieren von MACsec für ExpressRoute Direct-Ports.

Schritt 2: Sichern und Überprüfen der Kommunikation von einem lokalen Netzwerk zu Azure-VNets

Da die Cloudmigration in Unternehmen unterschiedlicher Größen immer weiter verbreitet ist, spielt die Hybridkonnektivität eine wichtige Rolle. Es ist wichtig, die Netzwerkkommunikation zwischen dem lokalen Netzwerk und Azure nicht nur zu sichern und zu schützen, sondern auch zu überprüfen und zu überwachen.

Das folgende Diagramm zeigt die Referenzarchitektur zum Sichern und Überprüfen der Kommunikation von einem lokalen Netzwerk zu Azure-VNets.

Diagramm der Referenzarchitektur zum Sichern und Überprüfen der Kommunikation von einem lokalen Netzwerk zu Azure-VNets.

Azure bietet zwei Optionen, um Ihr lokales Netzwerk mit Ressourcen in einem Azure-VNet zu verbinden:

  • Mit Azure VPN Gateway können Sie einen Site-to-Site-VPN-Tunnel mithilfe von IPsec erstellen, um die Netzwerkkommunikation zwischen Ihrem Netzwerk in zentralen oder Remotebüros und einem Azure-VNet zu verschlüsseln und zu authentifizieren. Darüber hinaus können einzelne Clients eine Point-to-Site-Verbindung herstellen, um ohne VPN-Gerät auf Ressourcen in einem Azure-VNet zuzugreifen. Konfigurieren Sie für die Einhaltung von Zero Trust die Microsoft Entra ID-Authentifizierung und Richtlinien für bedingten Zugriff für Ihre Azure VPN Gateway-Verbindungen, um die Identität und Compliance der Geräte zu überprüfen, die die Verbindung herstellen. Weitere Informationen finden Sie im Artikel zum Verwenden des Microsoft Tunnel-VPN-Gateways mit Richtlinien für bedingten Zugriff.

  • Azure ExpressRoute bietet eine private Verbindung mit hoher Bandbreite, mit der Sie Ihr lokales Netzwerk mit Unterstützung eines Konnektivitätsanbieters in Azure erweitern können. Da der Netzwerkdatenverkehr nicht über das öffentliche Internet übertragen wird, werden die Daten nicht standardmäßig verschlüsselt. Um Ihren Datenverkehr über ExpressRoute zu verschlüsseln, konfigurieren Sie einen IPsec-Tunnel. Beachten Sie jedoch, dass beim Ausführen von IPsec-Tunneln über ExpressRoute die Bandbreite auf die Tunnelbandbreite beschränkt ist und Sie möglicherweise mehrere Tunnel ausführen müssen, um der ExpressRoute-Leitungsbandbreite zu entsprechen. Weitere Informationen finden Sie unter Konfigurieren einer Site-to-Site-VPN-Verbindung über privates ExpressRoute-Peering (Azure VPN Gateway).

    Wenn Sie ExpressRoute Direct-Ports verwenden, können Sie Ihre Netzwerksicherheit erhöhen, indem Sie die Authentifizierung aktivieren, wenn Sie BGP-Peers einrichten, oder MACsec für die sichere Kommunikation mit Schicht 2 konfigurieren. MACsec bietet Verschlüsselung für Ethernet-Frames und stellt die Vertraulichkeit, Integrität und Authentizität der Daten zwischen Ihrem Edgerouter und dem Microsoft-Edgerouter sicher.

    Azure ExpressRoute unterstützt außerdem Azure Monitor für Netzwerkleistungsmetriken und Warnungen.

Die Verschlüsselung kann Ihre Daten vor unbefugtem Abfangen schützen, führt aber auch eine zusätzliche Verarbeitungsebene zum Verschlüsseln und Entschlüsseln von Netzwerkdatenverkehr ein, was sich auf die Leistung auswirken kann. Netzwerkdatenverkehr über das Internet kann auch unvorhersehbar sein, da er durch mehrere Netzwerkgeräte geleitet werden muss, was zu Netzwerklatenz führen kann. Um Leistungsprobleme zu vermeiden, empfiehlt Microsoft die Verwendung von ExpressRoute, da dies eine zuverlässige Netzwerkleistung und Bandbreitenzuweisung bietet, die Sie für Ihre Workload anpassen können.

Berücksichtigen Sie bei der Entscheidung zwischen Azure VPN Gateway und ExpressRoute die folgenden Fragen:

  1. Auf welche Arten von Dateien und Anwendungen greifen Sie zwischen Ihrem lokalen Netzwerk und Azure zu? Benötigen Sie eine konsistente Bandbreite für die Übertragung großer Datenmengen?
  2. Benötigen Sie eine konsistente und niedrige Latenz, damit Ihre Anwendungen optimal ausgeführt werden können?
  3. Müssen Sie die Netzwerkleistung und den Status Ihrer Hybridkonnektivität überwachen?

Wenn Sie einer dieser Fragen mit Ja beantwortet haben, sollte Azure ExpressRoute Ihre primäre Methode sein, um Ihr lokales Netzwerk mit Azure zu verbinden.

Es gibt zwei häufige Szenarien, in denen ExpressRoute und Azure VPN Gateway koexistieren können:

  • Azure VPN Gateway kann verwendet werden, um Ihre Zweigstellen mit Azure zu verbinden, während Ihr Hauptbüro über ExpressRoute verbunden ist.
  • Sie können Azure VPN Gateway auch als Sicherungsverbindung zu Azure für Ihre Zentrale verwenden, falls der ExpressRoute-Dienst ausfällt.

Schritt 3: Sichern und Überprüfen der Kommunikation innerhalb von und zwischen Azure-VNets

Der Datenverkehr in Azure weist eine zugrunde liegende Verschlüsselungsebene auf. Wenn der Datenverkehr zwischen VNets in verschiedenen Regionen fließt, verwendet Microsoft MACsec zum Verschlüsseln und Authentifizieren von Peeringdatenverkehr auf der Daten-Netzzugangsschicht.

Das folgende Diagramm zeigt die Referenzarchitektur zum Sichern und Überprüfen der Kommunikation innerhalb von und zwischen Azure-VNets.

Diagramm der Referenzarchitektur zum Sichern und Überprüfen der Kommunikation innerhalb von und zwischen Azure-VNets.

Die Verschlüsselung allein reicht jedoch nicht aus, um Zero Trust sicherzustellen. Sie sollten außerdem die Netzwerkkommunikation innerhalb von und zwischen Azure-VNets überprüfen und überwachen. Eine weitere Verschlüsselung und Überprüfung zwischen VNets ist mithilfe von Azure VPN Gateway oder virtuellen Netzwerkgeräten (NVAs) möglich, ist jedoch keine gängige Methode. Microsoft empfiehlt, Ihre Netzwerktopologie so zu entwerfen, dass ein zentralisiertes Datenverkehrsüberprüfungsmodell verwendet wird, das präzise Richtlinien erzwingen und Anomalien erkennen kann.

Um den Aufwand für die Konfiguration eines VPN-Gateways oder einer virtuellen Appliance zu verringern, aktivieren Sie die VNet-Verschlüsselungsfunktion für bestimmte Größen von virtuellen Computern, um den Datenverkehr zwischen virtuellen Computern auf Hostebene, innerhalb eines VNet und zwischen VNet-Peerings zu verschlüsseln und zu überprüfen.

Schritt 4: Implementieren der Verschlüsselung in der Anwendungsschicht

Die Verschlüsselung in der Anwendungsschicht spielt eine wichtige Rolle für Zero Trust, das vorgibt, dass alle Daten und Kommunikationen verschlüsselt werden müssen, wenn Benutzer mit Webanwendungen oder Geräten interagieren. Die Verschlüsselung in der Anwendungsschicht stellt sicher, dass nur überprüfte und vertrauenswürdige Entitäten auf Webanwendungen oder Geräte zugreifen können.

Das folgende Diagramm zeigt die Referenzarchitektur für die Implementierung der Verschlüsselung in der Anwendungsschicht.

Diagramm der Referenzarchitektur für die Implementierung der Verschlüsselung in der Anwendungsschicht.

Eines der häufigsten Beispiele für die Verschlüsselung in der Anwendungsschicht ist Hypertext Transfer Protocol Secure (HTTPS), das Daten zwischen einem Webbrowser und einem Webserver verschlüsselt. HTTPS verwendet das Transport Layer Security-Protokoll (TLS) zum Verschlüsseln der Kommunikation zwischen Client und Server und ein digitales TLS-Zertifikat, um die Identität und Vertrauenswürdigkeit der Website oder Domäne zu überprüfen.

Ein weiteres Beispiel für die Sicherheit auf Anwendungsebene sind Secure Shell (SSH) und Remotedesktopprotokoll (RDP), die Daten zwischen dem Client und dem Server verschlüsseln. Diese Protokolle unterstützen auch die Multi-Faktor-Authentifizierung und Richtlinien für bedingten Zugriff, um sicherzustellen, dass nur autorisierte und kompatible Geräte oder Benutzer auf Remoteressourcen zugreifen können. Informationen zum Sichern von SSH- und RDP-Verbindungen mit virtuellen Azure-Computern finden Sie in Schritt 5.

Schutz für Azure-Webanwendungen

Sie können Azure Front Door oder Azure Application Gateway verwenden, um Ihre Azure-Webanwendungen zu schützen.

Azure Front Door

Azure Front Door ist ein globaler Verteilungsdienst, der die Inhaltsübermittlung an Endbenutzer über die Edgestandorte von Microsoft optimiert. Mit Features wie Web Application Firewall (WAF) und dem Private Link-Dienst können Sie böswillige Angriffe auf Ihre Webanwendungen am Edge des Microsoft-Netzwerks erkennen und blockieren, während Sie privat über das interne Microsoft-Netzwerk auf Ihre Ursprünge zugreifen.

Um Ihre Daten zu schützen, wird der Datenverkehr zu Azure Front Door-Endpunkten mithilfe von HTTPS mit End-to-End-TLS geschützt. Dies gilt für den gesamten Datenverkehr zu und von den Endpunkten. Der Datenverkehr wird vom Client zum Ursprung und vom Ursprung zum Client verschlüsselt.

Azure Front Door verarbeitet HTTPS-Anforderungen und ermittelt, welcher Endpunkt in seinem Profil den zugehörigen Domänennamen hat. Anschließend wird der Pfad überprüft und bestimmt, welche Routingregel mit dem Pfad der Anforderung übereinstimmt. Wenn die Zwischenspeicherung aktiviert ist, überprüft Azure Front Door den Cache, um festzustellen, ob eine gültige Antwort vorhanden ist. Wenn keine gültige Antwort vorhanden ist, wählt Azure Front Door den besten Ursprung aus, der den angeforderten Inhalt bereitstellen kann. Bevor die Anforderung an den Ursprung gesendet wird, kann ein Regelsatz auf die Anforderung angewendet werden, um den Header, die Abfragezeichenfolge oder das Ursprungsziel zu ändern.

Azure Front Door unterstützt sowohl Front-End- als auch Back-End-TLS. Front-End-TLS verschlüsselt Datenverkehr zwischen dem Client und Azure Front Door. Back-End TLS verschlüsselt Datenverkehr zwischen Azure Front Door und dem Ursprung. Azure Front Door unterstützt die TLS-Versionen 1.2 und 1.3. Sie können Azure Front Door so konfigurieren, dass ein benutzerdefiniertes TLS-Zertifikat oder ein Zertifikat verwendet wird, das von Azure Front Door verwaltet wird.

Hinweis

Sie können auch das Private Link-Feature für die Verbindung mit NVAs für weitere Paketüberprüfungen verwenden.

Azure Application Gateway

Azure Application Gateway ist ein regionaler Lastenausgleich, der auf Schicht 7 betrieben wird. Er leitet den Webdatenverkehr basierend auf HTTP-URL-Attributen weiter und verteilt ihn. Er kann den Datenverkehr mit drei verschiedenen Ansätzen weiterleiten und verteilen:

  • Nur HTTP: Application Gateway empfängt eingehende HTTP-Anforderungen und leitet sie an das entsprechende Ziel in unverschlüsselter Form weiter.
  • SSL-Terminierung: Application Gateway entschlüsselt eingehende HTTPS-Anforderungen auf Instanzebene, prüft sie und leitet sie unverschlüsselt an das Ziel weiter.
  • End-to-End-TLS: Application Gateway entschlüsselt eingehende HTTPS-Anforderungen auf Instanzebene, prüft sie und verschlüsselt sie vor der Weiterleitung an das Ziel erneut.

Die sicherste Option ist End-to-End TLS, das die Verschlüsselung und Übertragung vertraulicher Daten ermöglicht, indem Authentifizierungszertifikate oder vertrauenswürdige Stammzertifikate verwendet werden müssen. Außerdem müssen diese Zertifikate auf die Back-End-Server hochgeladen werden, und es muss sichergestellt werden, dass diese Back-End-Server für Application Gateway bekannt sind. Weitere Informationen finden Sie unter Konfigurieren von End-to-End-TLS mit Application Gateway im Azure-Portal.

Darüber hinaus können lokale Benutzer oder Benutzer auf virtuellen Computern in einem anderen VNet das interne Front-End von App Gateway mit denselben TLS-Funktionen verwenden. Zusammen mit der Verschlüsselung empfiehlt Microsoft, WAF für mehr Front-End-Schutz für Ihre Endpunkte immer zu aktivieren.

Schritt 5: Schützen virtueller Azure-Computer mit Azure Bastion

Azure Bastion ist ein verwalteter PaaS-Dienst, mit dem Sie über eine TLS-Verbindung sicher eine Verbindung mit Ihren virtuellen Computern herstellen können. Diese Konnektivität kann über das Azure-Portal oder über einen nativen Client zur privaten IP-Adresse auf dem virtuellen Computer hergestellt werden. Zu den Vorteilen der Verwendung von Azure Bastion zählen:

  • Virtuelle Azure-Computer benötigen keine öffentliche IP-Adresse. Verbindungen erfolgen über TCP-Port 443 für HTTPS und können die meisten Firewalls durchlaufen.
  • Virtuelle Computer sind vor Portüberprüfung geschützt.
  • Die Azure Bastion-Plattform wird ständig aktualisiert und vor Zero-Day-Exploits geschützt.

Mit Bastion können Sie die RDP- und SSH-Konnektivität mit Ihrem virtuellen Computer von einem einzigen Einstiegspunkt aus steuern. Sie können einzelne Sitzungen über den Bastion-Dienst im Azure-Portal verwalten. Sie können außerdem eine laufende Remotesitzung löschen oder ihre Trennung erzwingen, wenn Sie vermuten, dass ein Benutzer keine Verbindung mit diesem Computer herstellen darf.

Das folgende Diagramm zeigt die Referenzarchitektur für die Verwendung von Azure Bastion zum Schutz virtueller Azure-Computer.

Diagramm der Referenzarchitektur für die Verwendung von Azure Bastion zum Schutz virtueller Azure-Computer.

Um Ihren virtuellen Azure-Computer zu schützen, stellen Sie Azure Bastion bereit, und beginnen Sie mit der Verwendung von RDP und SSH, um eine Verbindung mit Ihren virtuellen Computern mithilfe ihrer privaten IP-Adressen herzustellen.

Nächste Schritte

Weitere Informationen zum Anwenden von Zero Trust auf Azure-Netzwerke finden Sie unter:

References

Unter diesen Links erfahren Sie mehr über die verschiedenen in diesem Artikel erwähnten Dienste und Technologien.