Wenden Sie Zero Trust-Prinzipien mit Azure PaaS Services auf ein virtuelles Spoke-Netzwerk an

Dieser Artikel hilft Ihnen, die Prinzipien des Zero-Trust-Sicherheitsmodells auf eine PaaS-Workload anzuwenden, indem Sie virtuelle Azure-Netzwerke (VNets) und private Endpunkte auf folgende Weise nutzen:

Zero Trust-Prinzip	Definition	Erfüllt von
Explizit verifizieren	Authentifizieren und autorisieren Sie immer basierend auf allen verfügbaren Datenpunkten.	Verwenden Sie die Bedrohungserkennung in Azure Firewall und Azure Application Gateway, um den Datenverkehr zu validieren und zu überprüfen, ob der Datenverkehr akzeptabel ist.
Geringstmögliche Zugriffsberechtigungen verwenden	Beschränken Sie den Benutzerzugriff mit Just-In-Time- und Just-Enough-Access (JIT/JEA), risikobasierten adaptiven Richtlinien und Datenschutz.	Reduzieren Sie den Ein- und Ausgang von Azure-Diensten in Ihr privates Netzwerk. Verwenden Sie Netzwerksicherheitsgruppen, um nur bestimmten Eingang aus Ihrem VNet zuzulassen. Verwenden Sie eine zentrale Azure Firewall-Instanz, um Nicht-VNet-Datenverkehr Zugriff auf den Azure-Dienst zu gewähren.
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.	Begrenzen Sie unnötige Kommunikation zwischen Ressourcen. Stellen Sie sicher, dass Sie die Protokollierung von Netzwerksicherheitsgruppen aus durchführen und dass Sie über einen ordnungsgemäßen Einblick in anormalen Datenverkehr verfügen. Verfolgen Sie Änderungen an Netzwerksicherheitsgruppen.

Weitere Informationen zur Anwendung der Zero Trust-Prinzipien in einer Azure IaaS-Umgebung finden Sie in der Übersicht Zero Trust-Prinzipien auf Azure IaaS anwenden.

Wenden Sie Zero Trust-Prinzipien mit Azure PaaS Services auf einem virtuellen Spoke-Netzwerk an

Viele PaaS-Dienste enthalten ihre eigenen, dienstnativen Funktionen zur Eingangs- und Ausgangskontrolle. Sie können diese Kontrollen verwenden, um den Netzwerkzugriff auf PaaS-Dienstressourcen zu sichern, ohne dass eine Infrastruktur wie VNets erforderlich ist. Beispiel:

• Azure SQL-Datenbank verfügt über eine eigene Firewall, die verwendet werden kann, um bestimmten Client-IP-Adressen den Zugriff auf den Datenbankserver zu ermöglichen.
• Azure-Speicherkonten verfügen über eine Konfigurationsoption, mit der Verbindungen von einem bestimmten VNet zugelassen oder der Zugriff auf öffentliche Netzwerke blockiert werden können.
• Azure App Service unterstützt Zugriffsbeschränkungen, um eine nach Priorität geordnete Zulassungs-/Verweigerungsliste zu definieren, die den Netzwerkzugriff auf Ihre App steuert.

Bei Zero Trust-gesteuerten Implementierungen reichen diese service-nativen Zugriffskontrollen jedoch häufig nicht aus. Dies führt zu einer Verbreitung von Zugriffskontrollen und Protokollierung, die die Verwaltung verbessern und die Sichtbarkeit verringern können.

Darüber hinaus können PaaS-Dienste vollqualifizierte Domänennamen (FQDN) verwenden, die in eine dynamisch zugewiesene öffentliche IP-Adresse aufgelöst werden, die aus einem Pool öffentlicher IP-Adressen in einer bestimmten Region für einen Diensttyp zugewiesen wird. Aus diesem Grund können Sie keinen Datenverkehr von oder zu einem bestimmten PaaS-Dienst zulassen, indem Sie dessen öffentliche IP-Adresse verwenden, die sich ändern kann.

Microsoft empfiehlt die Verwendung von privaten Endpunkten. Ein privater Endpunkt ist eine VNet-Schnittstelle, die eine private IP-Adresse aus Ihrem VNet verwendet. Diese Netzwerkschnittstelle bietet eine private und sichere Verbindung zwischen Ihnen und einem von Azure Private Link unterstützten Dienst. Durch die Aktivierung eines privaten Endpunkts bringen Sie den Dienst in Ihr VNet.

Abhängig von Ihrem Lösungsszenario benötigen Sie möglicherweise weiterhin öffentlichen eingehenden Zugriff auf Ihre PaaS-Dienste. Sofern Sie dies jedoch nicht tun, empfiehlt Microsoft, dass der gesamte Datenverkehr privat bleibt, um potenzielle Sicherheitsrisiken auszuschließen.

Dieser Leitfaden enthält Anweisungen für eine bestimmte Referenzarchitektur, die Prinzipien und Methoden können jedoch bei Bedarf auf andere Architekturen angewendet werden.

Referenzarchitektur

Das folgende Diagramm zeigt eine gemeinsame Referenzarchitektur für PaaS-basierte Workloads.

In der Abbildung:

• Ein Spoke-VNet umfasst Komponenten zur Unterstützung einer PaaS-Anwendung.
• Die PaaS-Anwendung ist eine zweistufige Anwendung, die Azure Application Services für eine Web-App/ein Front-End und eine Azure SQL-Datenbank für relationale Datenbanken nutzt.
• Jede Ebene ist in einem dedizierten Subnetz für den Eingang mit einer dedizierten Netzwerksicherheitsgruppe enthalten.
• Die Webebene enthält ein dediziertes Subnetz für ausgehenden Datenverkehr.
• Der Zugriff auf die Anwendung erfolgt über ein Application Gateway, das in einem eigenen Subnetz enthalten ist.

Das folgende Diagramm zeigt die logische Architektur dieser Komponenten innerhalb eines Azure-Abonnements.

Im Diagramm sind alle die Komponenten des Spoke-VNet in einer dedizierten Ressourcengruppe enthalten:

• Ein VNet
• Ein Azure Application Gateway (App GW), einschließlich einer Web Application Firewall (WAF)
• Drei Netzwerksicherheitsgruppen (im Diagramm mit „NSG“ bezeichnet) für die Datenbank-, Anwendungs- und Front-End-Ebene
• Zwei Anwendungssicherheitsgruppen (im Diagramm mit „ASG“ bezeichnet)
• Zwei private Endpunkte

Darüber hinaus werden Ressourcen für das Hub-VNet im entsprechenden Konnektivitätsabonnement bereitgestellt.

Inhalt dieses Artikels

Zero-Trust-Prinzipien werden in der gesamten Architektur angewendet, von der Mandanten- und Verzeichnisebene bis hin zur Zuweisung von VMs zu Anwendungssicherheitsgruppen. In der folgenden Tabelle werden die Empfehlungen zum Sichern dieser Architektur beschrieben.

Schritt	Task
1	Verwenden Sie Microsoft Entra RBAC oder richten Sie benutzerdefinierte Rollen für Netzwerkressourcen ein.
2	Isolieren Sie die Infrastruktur in einer eigenen Ressourcengruppe.
3	Erstellen Sie für jedes Subnetz eine Netzwerksicherheitsgruppe.
4	Sicherer Datenverkehr und Ressourcen innerhalb des VNet: Stellen Sie grundlegende Verweigerungsregeln für Netzwerksicherheitsgruppen bereit. Planen Sie den Verwaltungsdatenverkehr in das VNet. Stellen Sie die Flussprotokollierung für Netzwerksicherheitsgruppen bereit.
5	Sicherer Ein- und Ausgang für Azure PaaS-Dienste.
6	Sicherer Zugriff auf das VNet und die Anwendung.
7	Aktivieren Sie erweiterte Bedrohungserkennung, Warnungen und Schutz.

In diesem Leitfaden wird davon ausgegangen, dass Sie bereits über einen Azure Application Service und eine Azure SQL-Datenbank verfügen, die in ihren eigenen Ressourcengruppen bereitgestellt sind.

Schritt 1: Verwenden Sie Microsoft Entra RBAC oder richten Sie benutzerdefinierte Rollen für Netzwerkressourcen ein.

Sie können integrierte Microsoft Entra RBAC-Rollen für Netzwerkmitwirkende nutzen. Ein anderer Ansatz besteht jedoch darin, benutzerdefinierte Rollen zu nutzen. Spoke VNet-Netzwerkmanager benötigen keinen vollständigen Zugriff auf Netzwerkressourcen, die durch die Microsoft Entra RBAC-Netzwerkmitwirkender-Rolle gewährt werden, benötigen jedoch mehr Berechtigungen als andere allgemeine Rollen. Eine benutzerdefinierte Rolle kann verwendet werden, um den Zugriff auf genau das zu beschränken, was benötigt wird.

Eine einfache Möglichkeit, dies zu implementieren, besteht darin, die benutzerdefinierten Rollen bereitzustellen, die in der Referenzarchitektur der Azure-Zielzone enthalten sind.

Die spezifische Rolle, die verwendet werden kann, ist die benutzerdefinierte Rolle Netzwerkverwaltung, die über die folgenden Berechtigungen verfügt:

• Lesen Sie alles im Umfang
• Alle Aktionen mit dem Netzwerkanbieter
• Alle Aktionen mit dem Support-Anbieter
• Alle Aktionen mit dem Ressourcenanbieter

Diese Rolle kann mithilfe der Skripts im GitHub-Repository der Azure Landing Zone Reference Architecture oder über Microsoft Entra ID mit benutzerdefinierten Azure-Rollen erstellt werden. ​

Schritt 2: Isolieren Sie die Infrastruktur in einer eigenen Ressourcengruppe

Indem Sie Netzwerkressourcen von Rechen-, Daten- oder Speicherressourcen isolieren, verringern Sie die Wahrscheinlichkeit von Berechtigungsverlusten. Indem Sie sicherstellen, dass sich alle zugehörigen Ressourcen in einer Ressourcengruppe befinden, können Sie außerdem eine einzige Sicherheitszuweisung vornehmen und die Protokollierung und Überwachung dieser Ressourcen besser verwalten.

Anstatt die Spoke-Netzwerkressourcen in mehreren Kontexten in einer gemeinsam genutzten Ressourcengruppe verfügbar zu machen, erstellen Sie eine dedizierte Ressourcengruppe dafür. Das folgende Architekturdiagramm zeigt diese Konfiguration.

Im Diagramm sind Ressourcen und Komponenten in der Referenzarchitektur in dedizierte Ressourcengruppen für Anwendungsdienste, Azure SQL-Datenbanken, Speicherkonten, Hub-VNet-Ressourcen und Spoke-VNet-Ressourcen unterteilt.

Mit einer dedizierten Ressourcengruppe können Sie mithilfe des Tutorials Gewähren Sie einem Benutzer Zugriff auf Azure-Ressourcen über das Azure-Porta eine benutzerdefinierte Rolle zuweisen.

Weitere Empfehlungen:

• Verweisen Sie auf eine Sicherheitsgruppe für die Rolle statt auf benannte Personen.
• Verwalten Sie den Zugriff auf die Sicherheitsgruppe über Ihre Unternehmensidentitätsverwaltungspraktiken.

Wenn Sie keine Richtlinien verwenden, die die Protokollweiterleitung für Ressourcengruppen erzwingen, konfigurieren Sie dies im Aktivitätsprotokoll für die Ressourcengruppe:

1. Suchen Sie die Ressourcengruppe im Azure-Portal.
2. Navigieren Sie zu Aktivitätsprotokoll-> Aktivitätsprotokolle exportieren und wählen Sie dann + Diagnoseeinstellung hinzufügen.
3. Wählen Sie auf dem Bildschirm Diagnoseeinstellung alle Protokollkategorien (insbesondere Sicherheit) aus und senden Sie sie an die entsprechenden Protokollierungsquellen, z. B. einen Log-Analytics-Arbeitsbereich für den Einblick oder ein Speicherkonto für die Langzeitspeicherung. Ein Beispiel:

Unter Diagnoseeinstellungen erfahren Sie, wie Sie diese Protokolle überprüfen und darauf aufmerksam machen können.

Demokratisierung von Abonnements

Auch wenn dies nicht direkt mit der Vernetzung zusammenhängt, sollten Sie Ihr RBAC-Abonnement auf ähnliche Weise planen. Neben der logischen Isolierung von Ressourcen nach Ressourcengruppen sollten Sie das Abonnement auch nach Geschäftsbereichen und Portfolioeigentümern isolieren. Das Abonnement als Verwaltungseinheit sollte eng begrenzt sein.

Weitere Informationen finden Sie unter Entwurfsprinzipien für Azure-Zielzonen.

Schritt 3: Erstellen Sie für jedes Subnetz eine Netzwerksicherheitsgruppe.

Azure-Netzwerksicherheitsgruppen werden verwendet, um den Netzwerkverkehr zwischen Azure-Ressourcen in einem Azure-VNet zu filtern. Es wird empfohlen, eine Netzwerksicherheitsgruppe auf jedes Subnetz anzuwenden. Dies wird standardmäßig durch die Azure-Richtlinie erzwungen, wenn Azure-Zielzonen bereitgestellt werden. Eine Netzwerksicherheitsgruppe enthält Sicherheitsregeln, die eingehenden Netzwerkdatenverkehr an verschiedene Typen von Azure-Ressourcen oder ausgehenden Netzwerkdatenverkehr von diesen zulassen oder verweigern. Für jede Regel können Sie Quell- und Ziel-IP-Adressen, ein Protokoll (z. B. TCP oder UDP) und einen Port angeben.

Für mehrschichtige Anwendungen wird empfohlen, für jedes Subnetz, das eine Netzwerkkomponente hostet, eine dedizierte Netzwerksicherheitsgruppe („NSG“ im folgenden Diagramm) zu erstellen.

In der Abbildung:

• Jede Ebene der Anwendung verfügt über ein dediziertes Eingangssubnetz, beispielsweise eines für die Webebene und eines für die Datenebene.
• Azure Application Services verfügt über ein dediziertes Ausgangssubnetz für einen bestimmten Anwendungsdienst.
• Für jedes dieser Subnetze wird eine Netzwerksicherheitsgruppe konfiguriert.

Wenn Sie Netzwerksicherheitsgruppen anders als in der Abbildung konfigurieren, kann dies zu einer falschen Konfiguration einiger oder aller Netzwerksicherheitsgruppen führen und zu Problemen bei der Fehlerbehebung führen. Es kann auch die Überwachung und Protokollierung erschweren.

Informationen zum Verwalten der Einstellungen Ihrer Netzwerksicherheitsgruppen finden Sie unter Erstellen, ändern oder löschen Sie eine Azure-Netzwerksicherheitsgruppe.

Lesen Sie mehr über Netzwerksicherheitsgruppen, um zu verstehen, wie sie zum Schutz Ihrer Umgebungen verwendet werden können.

Schritt 4: Sicherer Datenverkehr und Ressourcen innerhalb des VNet

In diesem Abschnitt werden die folgenden Empfehlungen beschrieben:

• Stellen Sie grundlegende Verweigerungsregeln für Netzwerksicherheitsgruppen bereit
• Stellen Sie anwendungsspezifische Regeln bereit
• Planen Sie den Verwaltungsdatenverkehr in VNet
• Stellen Sie die Flussprotokollierung für Netzwerksicherheitsgruppen bereit

Stellen Sie grundlegende Verweigerungsregeln für Netzwerksicherheitsgruppen bereit

Ein Schlüsselelement von Zero Trust ist die Verwendung der geringsten erforderlichen Zugriffsebene. Standardmäßig verfügen Netzwerksicherheitsgruppen über Zulassen Regeln. Durch das Hinzufügen einer Basislinie von Verweigern Regeln können Sie die geringste Zugriffsebene erzwingen. Erstellen Sie nach der Bereitstellung eine Alle verweigern Regel in jeder der eingehenden und ausgehenden Regeln mit einer Priorität von 4096. Dies ist die letzte verfügbare benutzerdefinierte Priorität, was bedeutet, dass Sie noch über den verbleibenden Spielraum zum Konfigurieren von Erlauben-Aktionen verfügen.

Navigieren Sie dazu in der Netzwerksicherheitsgruppe zu Ausgehende Sicherheitsregeln und wählen Sie Hinzufügen. Geben Sie Folgendes ein:

• Quelle: Beliebig
• Quellportbereiche: *
• Ziel: Beliebig
• Dienst: Benutzerdefiniert
• Zielportbereiche: *
• Protokoll Beliebig
• Aktion: Deny
• Priorität: 4096
• Name: DenyAllOutbound
• Beschreibung: Verweigert den gesamten ausgehenden Datenverkehr, sofern dies nicht ausdrücklich erlaubt ist.

Im Folgenden sehen Sie ein Beispiel.

Wiederholen Sie diesen Vorgang mit eingehenden Regeln und passen Sie den Namen und die Beschreibung entsprechend an.

Auf der Registerkarte Eingehende Sicherheitsregeln wird das Warnzeichen für die Regel angezeigt. Im Folgenden sehen Sie ein Beispiel.

Klicken Sie auf die Regel und scrollen Sie nach unten, um weitere Details zu sehen. Ein Beispiel:

Diese Nachricht gibt die folgenden zwei Warnungen aus:

• Azure Load Balancer können standardmäßig nicht über diese Netzwerksicherheitsgruppe auf Ressourcen zugreifen.
• Andere Ressourcen in diesem VNet können standardmäßig nicht auf Ressourcen zugreifen, die diese Netzwerksicherheitsgruppe verwenden.

Für unseren Zweck bei Zero Trust sollte es so sein. Das heißt, nur weil sich etwas in diesem VNet befindet, heißt das nicht, dass es sofort Zugriff auf Ihre Ressourcen haben wird. Erstellen Sie für jedes Verkehrsmuster eine Regel, die es explizit zulässt, und Sie sollten dies mit der geringsten Anzahl an Berechtigungen tun.

Wenn Sie bestimmte ausgehende Verbindungen zur Verwaltung haben, z. B. zu Active Directory Domain Services (AD DS)-Domänencontrollern, privaten DNS-VMs oder zu bestimmten externen Websites, müssen diese hier gesteuert werden.

Alternative Ablehnungsregeln

Hinweis

Die Empfehlungen in diesem Abschnitt gelten nur für das Web-Egress-Subnetz.

Wenn Sie Azure Firewall zum Verwalten Ihrer ausgehenden Verbindungen verwenden, können Sie anstelle einer Verweigerung aller ausgehenden Verbindungen (deny-outbound-all) alternative Regeln für ausgehende Verbindungen erstellen. Als Teil der Azure Firewall-Implementierung richten Sie eine Routentabelle ein, die Datenverkehr über die Standardroute (0.0.0.0/0) an die Firewall sendet. Dadurch wird der Datenverkehr außerhalb des VNet verarbeitet.

Sie können dann entweder eine Regel zum Verweigern aller ausgehenden VNet-Daten oder eine Regel zum Zulassen aller ausgehenden Daten erstellen, aber Elemente mit ihren eingehenden Regeln sichern.

Lesen Sie mehr über Azure Firewall und Routentabellen, um zu verstehen, wie Sie diese nutzen können, um die Sicherheit der Umgebung weiter zu erhöhen.

Stellen Sie anwendungsspezifische Regeln bereit

Definieren Sie Verkehrsmuster mit der geringsten Anzahl an Berechtigungen und folgen Sie nur explizit erlaubten Pfaden. Definieren Sie Netzwerkmuster in den Netzwerksicherheitsgruppen, indem Sie Subnetze als Quellen verwenden. Im Folgenden sehen Sie ein Beispiel.

InVerwenden Sie den Prozess Netzwerksicherheitsgruppen verwalten: Erstellen Sie eine Sicherheitsregel, um Regeln zu Ihren Netzwerksicherheitsgruppen hinzuzufügen.

Um dieses Szenario abzusichern, fügen Sie die folgenden Regeln hinzu:

Netzwerksicherheitsgruppe für Subnetz	Direction	Quelle	Quellendetails	Quellport	Destination	Zieldetails	Dienst	Name der Netzwerksicherheitsgruppe	Beschreibung der Netzwerksicherheitsgruppe
App-Dienst Subnetz	Eingehend	IP-Adressen	Der private IP-Adressbereich Ihres Subnetz des Anwendungs-Gateways	443	IP-Adressen	Die explizite IP-Adresse des privaten Endpunkts Ihres App-Dienstes	MS SQL	AllowGWtoAppInbound	Ermöglicht eingehenden Zugriff auf den App-Dienst vom Application Gateway.
App-Dienst Integrationssubnetz	Ausgehend	IP-Adressen	Der IP-Adressbereich Ihres App-Dienst Integrationssubnetzes	1433	IP-Adressen	Die eindeutige IP-Adresse des privaten Endpunkts Ihres App-Dienstes	MS SQL	AllowApptoSQLDBOutbound	Ermöglicht ausgehenden Zugriff auf den privaten SQL-Endpunkt vom App-Dienst Integrationssubnetzes.
SQL-Subnetz in Azure	Eingehend	IP-Adressen	Der IP-Adressbereich Ihres App-Dienst Integrationssubnetzes	1433	IP-Adressen	Die eindeutige IP-Adresse des privaten Endpunkts Ihres App-Dienstes	MS SQL	AllowApptoSQLDBInbound	Ermöglicht eingehenden Zugriff auf den privaten SQL-Endpunkt vom App-Dienst Integrationssubnetzes.

Hinweis

Manchmal kann der Quellverkehr von verschiedenen Ports kommen. Wenn dieses Muster auftritt, können Sie Quellportbereiche zu „*“ hinzufügen, um jeden Quellport zuzulassen. Der Zielport ist wichtiger und einige Empfehlungen lauten, immer „*“ für den Quellport zu verwenden.

Hinweis

Verwenden Sie für die Priorität einen Wert zwischen 100 und 4000. Sie können bei 105 beginnen.

Dies gilt zusätzlich zu den Netzwerksicherheitsgruppenregeln in Ihrem Subnetz des Anwendungs-Gateways.

Mit diesen drei Regeln haben Sie das Zero Trust-Konnektivitätsmuster für eine einzelne Anwendungsebene definiert. Sie können diesen Vorgang bei Bedarf für weitere Flows wiederholen.

Planen Sie den Verwaltungsdatenverkehr in VNet

Planen Sie neben dem anwendungsspezifischen Datenverkehr auch den Verwaltungsdatenverkehr ein. Da der Verwaltungsdatenverkehr seinen Ursprung jedoch typischerweise außerhalb des Spoke-VNet hat, sind weitere Regeln erforderlich. Machen Sie sich zunächst mit den spezifischen Ports und Quellen vertraut, von denen der Verwaltungsdatenverkehr ausgeht. Normalerweise sollte der gesamte Verwaltungsverkehr von einer Firewall oder einer anderen virtuellen Netzwerk-Appliance (NVA) fließen, die sich im Hub-Netzwerk für den Spoke befindet.

Die vollständige Referenzarchitektur finden Sie unter Übersicht über die Anwendung von Zero Trust-Prinzipien auf Azure IaaS.

Ihre Konfiguration variiert je nach Ihren spezifischen Verwaltungsanforderungen. Sie sollten jedoch Regeln für Firewall-Appliances und Regeln für die Netzwerksicherheitsgruppe verwenden, um Verbindungen sowohl auf der Plattformnetzwerk- als auch auf der Workload-Netzwerkseite explizit zuzulassen.

Planung für Deployment

Da Ihre Anwendungsdienste und Datenbanken jetzt private Netzwerke nutzen, müssen Sie planen, wie die Bereitstellung von Code und Daten für diese Ressourcen funktioniert. Fügen Sie Regeln hinzu, um Ihren privaten Build-Servern den Zugriff auf diese Endpunkte zu ermöglichen.

Stellen Sie die Flussprotokollierung für Netzwerksicherheitsgruppen bereit

Selbst wenn Ihre Netzwerksicherheitsgruppe unnötigen Datenverkehr blockiert, bedeutet das nicht, dass Ihre Ziele erreicht werden. Um einen Angriff zu erkennen, müssen Sie weiterhin den Datenverkehr beobachten, der außerhalb Ihrer expliziten Muster stattfindet.

Der Datenverkehr zu den privaten Endpunkten wird nicht protokolliert, aber wenn später andere Dienste in den Subnetzen bereitgestellt werden, hilft dieses Protokoll bei der Erkennung der Aktivitäten.

Um die Protokollierung des Netzwerksicherheitsgruppenflusses zu aktivieren, befolgen Sie das Tutorial: Protokollieren des Netzwerkverkehrsflusses zu und von einer virtuellen Maschine für die vorhandene Netzwerksicherheitsgruppe für die privaten Endpunkte.

Hinweis

Beachten Sie diese Empfehlungen:

• Sie sollten den Zugriff auf die Protokolle nach Bedarf einschränken.

• Protokolle sollten nach Bedarf in Log Analytics und Microsoft Sentinel einfließen.

Schritt 5: Sicherer Ein- und Ausgang für Azure PaaS-Dienste.

Dieser Abschnitt enthält zwei Schritte, die zum Sichern des Ein- und Ausgangs für Ihre PaaS-Dienste erforderlich sind:

• Stellen Sie private Endpunkte für den Zugang zu Ihren Diensten bereit.
• Stellen Sie die VNet-Integration bereit, damit Ihr Anwendungsdienst mit Ihrem VNet kommunizieren kann.

Darüber hinaus sollten Sie auch Ihre DNS-Konfiguration berücksichtigen, um die Auflösung von Namen zu ermöglichen.

Stellen Sie private Endpunkte für den eingehenden Datenverkehr bereit

Während Sie bei vielen Diensten private Endpunkte über das ressourcenspezifische Blatt im Azure-Portal erstellen können, ist es konsistenter, einen privaten Endpunkt aus der eigenen Ressourcenerstellung zu erstellen. Hierzu sollten bereits Ressourcen bereitgestellt sein. Nach der Bereitstellung können Sie einen privaten Endpunkt erstellen.

Konfigurieren Sie die privaten Endpunkte bei der Bereitstellung wie folgt:

• Platzieren Sie sie in der spezifischen Ressourcengruppe, die die übergeordneten Ressourcen beherbergt, um Ressourcen mit einem ähnlichen Lebenszyklus zusammenzuhalten und einen zentralen Zugriff zu ermöglichen.
• Platzieren Sie sie basierend auf ihrer Rolle im entsprechenden Subnetz im VNet.
• Für den Azure Application Service können Sie private Endpunkte sowohl für sein normales Frontend als auch für seinen SCM-Endpunkt konfigurieren, der für Bereitstellungen und Verwaltung verwendet wird.

Außerdem sollten Sie im Rahmen dieser Bereitstellung sicherstellen, dass die dienstspezifische Firewall so eingestellt ist, dass sie eingehenden Datenverkehr verweigert. Dadurch werden alle Versuche des öffentlichen Eindringens verhindert.

Für die Azure SQL-Datenbank müssen Sie die IP-Firewallregeln auf Serverebene verwalten. Stellen Sie sicher, dass Zugriff auf öffentliches Netzwerk im Netzwerkbereich im Azure-Portal auf Deaktivieren eingestellt ist.

Für den Azure Application Service wird durch das Hinzufügen des privaten Endpunkts dessen Service-Level-Firewall so eingestellt, dass eingehender Zugriff standardmäßig blockiert wird. Weitere Informationen finden Sie unter Verwenden privater Endpunkte für App-Service-Apps.

Stellen Sie die VNet-Integration für ausgehend bereit

Aktivieren Sie zusätzlich zu den privaten Endpunkten für den Ingress die VNet-Integration. Für jeden App Service-Plan kann die VNet-Integration aktiviert werden, wodurch dem App Service ein ganzes Subnetz zugewiesen wird. Weitere Informationen finden Sie unter Integrieren Sie Ihre App in ein Azure VNet.

Informationen zum Konfigurieren Ihres App-Dienstes finden Sie unter VNet-Integration in Azure App Service aktivieren. Stellen Sie sicher, dass Sie dies in Ihrem Subnetz platzieren, das für ausgehende Verbindungen bestimmt ist.

DNS Überlegungen

Aktivieren Sie im Rahmen der Verwendung privater Endpunkte die DNS-Auflösung der FQDNs der Ressourcen auf ihre neuen privaten IP-Adressen. Anweisungen zur Implementierung auf verschiedene Arten finden Sie unter Private Endpoint DNS-Konfiguration.

Hinweis

Die DNS-Auflösung muss für den gesamten Datenverkehr gelten. Ressourcen im selben VNet können nur dann aufgelöst werden, wenn sie die richtigen DNS-Zonen verwenden.

Schritt 6: Sicherer Zugriff auf das VNet und die Anwendung.

Zur Sicherung des Zugriffs auf das VNet und die Anwendungen gehören:

• Sichern des Datenverkehrs innerhalb der Azure-Umgebung zur Anwendung
• Verwenden der Multi-Faktor-Authentifizierung (MFA) und der Richtlinien für bedingten Zugriff für den Benutzerzugriff auf Anwendungen.

Das folgende Diagramm zeigt beide Zugriffsmodi in der Referenzarchitektur.

Sicherer Datenverkehr innerhalb der Azure-Umgebung für das VNet und die Anwendung

Ein Großteil der Arbeit an der Sicherheit des Datenverkehrs in der Azure-Umgebung ist bereits abgeschlossen. Weitere Informationen zum Konfigurieren sicherer Verbindungen zwischen Speicherressourcen und den VMs finden Sie unter Zero Trust-Prinzipien auf Speicher in Azure anwenden.

Siehe Anwenden von Zero Trust-Prinzipien auf ein virtuelles Hub-VNet in Azure, um den Zugriff von Hub-Ressourcen auf das VNet zu sichern.

Verwenden von MFA- und bedingten Zugriffsrichtlinien für den Benutzerzugriff auf Anwendungen

Der Artikel Zero-Trust-Prinzipien auf virtuelle Maschinen anwenden empfiehlt, wie Zugriffsanfragen direkt an VMs mit MFA und bedingtem Zugriff geschützt werden können. Diese Anfragen stammen höchstwahrscheinlich von Administratoren und Entwicklern. Der nächste Schritt besteht darin, den Zugriff auf Anwendungen mit MFA und bedingten Zugriff zu sichern. Dies gilt für alle Benutzer, die auf die Anwendung zugreifen.

Wenn die Anwendung noch nicht in Microsoft Entra ID integriert ist, lesen Sie zunächst Anwendungstypen für die Microsoft Identity Platform.

Fügen Sie als Nächstes die Anwendung zum Geltungsbereich Ihrer Identitäts- und Gerätezugriffsrichtlinien hinzu.

Verwenden Sie beim Konfigurieren von MFA mit bedingtem Zugriff und zugehörigen Richtlinien den empfohlenen Richtliniensatz für Zero Trust als Leitfaden. Dazu gehören Startpunkt-Richtlinien, die keine Geräteverwaltung erfordern. Im Idealfall werden die Geräte, die auf Ihre VMs zugreifen, verwaltet und Sie können den für Zero Trust empfohlenen Enterprise-Level implementieren. Weitere Informationen finden Sie unter Gemeinsame Zero Trust-Identitäts- und Gerätezugriffsrichtlinien.

Das folgende Diagramm zeigt die empfohlenen Richtlinien für Zero Trust.

Schritt 7: Aktivieren Sie erweiterte Bedrohungserkennung und Schutz.

Ihr auf Azure aufgebautes Spoke-VNet ist möglicherweise bereits durch Microsoft Defender for Cloud geschützt, da auch andere Ressourcen aus Ihrer IT-Geschäftsumgebung, die auf Azure oder lokal ausgeführt wird, geschützt sein können.

Wie in den anderen Artikeln dieser Serie erwähnt, ist Defender für Cloud ein Cloud Security Posture Management (CSPM) und Cloud Workload Protection (CWP)-Tool, das Sicherheitsempfehlungen, Warnungen und erweiterte Funktionen wie Adaptive Netzwerkhärtung bietet, um Sie auf Ihrer Reise zur Cloud-Sicherheit zu unterstützen.

In diesem Artikel wird Defender for Cloud nicht ausführlich beschrieben, es ist jedoch wichtig zu verstehen, dass Defender for Cloud auf Azure-Richtlinien und -Protokollen basiert, die in einem Log Analytics-Arbeitsbereich erfasst werden. Sobald die Abonnements mit Ihrem Spoke-VNet und den zugehörigen Ressourcen aktiviert sind, können Sie Empfehlungen zur Verbesserung der Sicherheitslage sehen. Sie können diese Empfehlungen weiter nach MITRE-Taktik, Ressourcengruppe und anderen filtern. Erwägen Sie, Prioritäten zu setzen, um Empfehlungen zu lösen, die einen größeren Einfluss auf den Secure Score Ihrer Organisation haben. Im Folgenden sehen Sie ein Beispiel.

Es gibt Defender for Cloud-Pläne, die erweiterte Mechanismen für den Workloadschutz bieten. Dazu zählen Empfehlungen für adaptive Netzwerkhärtungen, um Ihre vorhandenen Regeln für Netzwerksicherheitsgruppen zu verbessern. Im Folgenden sehen Sie ein Beispiel.

Sie können die Empfehlung akzeptieren, indem Sie Erzwingen auswählen, wodurch entweder eine neue Netzwerksicherheitsgruppenregel erstellt oder eine vorhandene geändert wird.

Empfohlenes Training

• Schützen Ihrer Azure-Ressourcen mit der rollenbasierten Zugriffssteuerung von Azure (Azure Role-Based Access Control, Azure RBAC)
• Konfiguration und Verwaltung von Azure Monitor
• Konfigurieren von Netzwerksicherheitsgruppen
• Entwerfen und Implementieren von Netzwerksicherheit
• Entwerfen und Implementieren des privaten Zugriffs auf Azure-Dienste

Nächste Schritte

Lesen Sie diese zusätzlichen Artikel zur Anwendung von Zero Trust-Prinzipien auf Azure:

• Für Azure IaaS:
  • Übersicht
  • Azure Storage
  • Virtuelle Computer
  • Spoke virtuelle Netzwerke
  • Virtuelle Hubnetzwerke
• Azure Virtual Desktop
• Azure Virtual WAN
• IaaS-Anwendungen in Amazon Web Services
• Microsoft Sentinel und Microsoft Defender XDR

References

• Sicherheit mit Zero Trust proaktiv umsetzen
• Schützen von Netzwerken mit Zero Trust
• Zero Trust-Netzwerk für Webanwendungen mit Azure Firewall und Application Gateway
• Azure-Zielzonenrichtlinien
• Gemeinsame Zero-Trust-Identität und -Gerät für alle Richtlinien
• Was ist ein privater Endpunkt?
• DNS-Konfiguration für private Endpunkte
• Integrieren Sie Ihre App in ein Azure VNet
• Verwenden privater Endpunkte für App-Service-Apps
• Herstellen einer Verbindung mit einem Azure SQL-Server über einen privaten Azure-Endpunkt