Wenden Sie Zero Trust-Prinzipien auf ein virtuelles Spoke-Netzwerk in Azure an
Zusammenfassung: Um Zero Trust-Prinzipien auf ein virtuelles Spoke-Netzwerk in Azure anzuwenden, müssen Sie rollenbasierte Zugriffssteuerung (RBAC), Subnetze und virtuelle Computer (Ressourcengruppen, Netzwerksicherheitsgruppen und Anwendungssicherheitsgruppen), sicheren Datenverkehr und Ressourcen innerhalb der VNet- und virtuellen Computeranwendungen nutzen und erweiterte Bedrohungserkennung, Warnungen und Schutz aktivieren.
Dieser Artikel hilft Ihnen, die Prinzipien von Zero Trust auf folgende Weise auf ein virtuelles Spoke-Netzwerk (VNet) für IaaS-Workloads in Azure anzuwenden:
| Zero Trust-Prinzip | Definition | Erfüllt von |
|---|---|---|
| Explizit verifizieren | Authentifizieren und autorisieren Sie immer basierend auf allen verfügbaren Datenpunkten. | Verwenden Sie Anwendungssicherheitsgruppen, um zu überprüfen, ob einzelne NICs Berechtigungen zur Kommunikation über bestimmte Kanäle haben. |
| Geringstmögliche Zugriffsberechtigungen verwenden | Beschränken Sie den Benutzerzugriff mit Just-In-Time- und Just-Enough-Access (JIT/JEA), risikobasierten adaptiven Richtlinien und Datenschutz. | Aktivieren Sie auf keinem Kanal standardmäßig den 3389/RDP-Zugriff. Verwenden Sie die richtigen Rollenberechtigungen für den Spoke-Kontext. |
| 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 sich bei Netzwerksicherheitsgruppen anmelden können und dass Sie einen angemessenen Überblick über anomalen Datenverkehr haben. Verfolgen Sie Änderungen an Netzwerksicherheitsgruppen. |
Dieser Artikel ist Teil einer Reihe von Artikeln, die zeigen, wie die Prinzipien von Zero Trust in einer Umgebung in Azure angewendet werden, die ein Spoke-VNet umfasst, das eine auf einer virtuellen Maschine basierende Arbeitslast hostet. Weitere Informationen finden Sie in der Übersicht über die Anwendung von Zero Trust-Prinzipien auf Azure IaaS.
Referenzarchitektur
Das folgende Diagramm zeigt eine gemeinsame Referenzarchitektur für IaaS-basierte Workloads.
In der Abbildung:
- Ein Spoke-VNet umfasst Komponenten zur Unterstützung einer IaaS-Anwendung, die aus virtuellen Maschinen besteht.
- Die IaaS-Anwendung ist eine dreischichtige Anwendung, die aus zwei virtuellen Maschinen für jede Schicht besteht: Front-End, Anwendung und Daten.
- Jede Ebene ist in einem dedizierten Subnetz mit einer dedizierten Netzwerksicherheitsgruppe enthalten.
- Jede Rolle einer virtuellen Maschine wird einer Anwendungssicherheitsgruppe zugewiesen, die ihrer Rolle entspricht.
- Der Zugriff auf die Anwendung erfolgt über ein Application Gateway, das in einem eigenen Subnetz enthalten ist.
Die in der Referenzarchitektur gezeigte Anwendung folgt dem N-Tier-Architekturstil
Das folgende Diagramm zeigt die Komponenten einer Ressourcengruppe für ein Spoke-VNet in einem Azure-Abonnement, getrennt vom Abonnement für das Hub-VNet.
Im Diagramm sind alle 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, eine für jede Anwendungsebene
- Drei Anwendungssicherheitsgruppen, eine für jede Anwendungsebene
Inhalt dieses Artikels
Zero-Trust-Prinzipien werden in der gesamten Architektur angewendet, von der Mandanten- und Verzeichnisebene bis hin zur Zuweisung virtueller Maschinen zu Anwendungssicherheitsgruppen. In der folgenden Tabelle werden die Empfehlungen zum Sichern dieser Architektur beschrieben.
| Schritt | Task | Es gelten die Zero Trust-Prinzipien |
|---|---|---|
| 1 | Nutzen Sie die rollenbasierte Zugriffskontrolle (RBAC) von Microsoft Entra oder richten Sie benutzerdefinierte Rollen für Netzwerkressourcen ein. | Geringstmögliche Zugriffsberechtigungen verwenden |
| 2 | Isolieren Sie die Infrastruktur in einer eigenen Ressourcengruppe. | Von einer Sicherheitsverletzung ausgehen |
| 3 | Erstellen Sie für jedes Subnetz eine Netzwerksicherheitsgruppe. | Verwenden des Zugriffs mit den geringsten Rechten Von einer Sicherheitsverletzung ausgehen |
| 4 | Erstellen Sie für jede Rolle einer virtuellen Maschine eine Anwendungssicherheitsgruppe. | Explizit verifizieren Verwenden des Zugriffs mit den geringsten Rechten Von einer Sicherheitsverletzung ausgehen |
| 5 | Sicherer Datenverkehr und Ressourcen innerhalb des VNet: |
Explizit verifizieren Verwenden des Zugriffs mit den geringsten Rechten Von einer Sicherheitsverletzung ausgehen |
| 6 | Sicherer Zugriff auf das VNet und die Anwendung. | Verwenden des Zugriffs mit den geringsten Rechten Von einer Sicherheitsverletzung ausgehen |
| 7 | Aktivieren Sie erweiterte Bedrohungserkennung, Warnungen und Schutz. | Von einer Sicherheitsverletzung ausgehen |
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 verwenden. Ein anderer Ansatz besteht jedoch darin, benutzerdefinierte Rollen zu verwenden. Spoke-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. Sie können eine benutzerdefinierte Rolle verwenden, 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 ist die benutzerdefinierte Rolle Netzwerkverwaltung mit den folgenden Berechtigungen:
- Lesen Sie alles im Umfang
- Alle Aktionen mit dem Netzwerkanbieter
- Alle Aktionen mit dem Support-Anbieter
- Alle Aktionen mit dem Ressourcenanbieter
ie können diese Rolle mithilfe der Skripts für die benutzerdefinierten Rollen oder über Microsoft Entra ID mit dem unter Benutzerdefinierte Azure-Rollen – Azure RBAC beschriebenen Prozess erstellen.
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. Die in diesem Artikel unterstützte Referenzarchitektur veranschaulicht dieses Konzept.
In der Abbildung sind Ressourcen und Komponenten in der Referenzarchitektur in dedizierte Ressourcengruppen für virtuelle Maschinen, Speicherkonten, Hub-VNet-Ressourcen und Spoke-VNet-Ressourcen unterteilt.
Mit einer dedizierten Ressourcengruppe können Sie mithilfe des folgenden Prozesses eine benutzerdefinierte Rolle zuweisen: Tutorial: Gewähren Sie einem Benutzer Zugriff auf Azure-Ressourcen über das Azure-Portal – Azure RBAC.
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ätsverwaltungsmuster.
Wenn Sie keine Richtlinien verwenden, die die Protokollweiterleitung für Ressourcengruppen erzwingen, konfigurieren Sie dies im Aktivitätsprotokoll für die Ressourcengruppe: Navigieren Sie zu Aktivitätsprotokoll > Aktivitätsprotokolle exportieren und wählen Sie dann + Diagnoseeinstellung hinzufügen.
Wählen Sie auf dem Einstellungsbildschirm Diagnose alle Protokollkategorien (insbesondere Sicherheit) aus und senden Sie sie an die entsprechenden Protokollierungsquellen, z. B. einen Log Analytics-Arbeitsbereich für die Beobachtbarkeit oder ein Speicherkonto für die Langzeitspeicherung.
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 zur Demokratisierung von Abonnements finden Sie unter Designprinzipien für Azure-Zielzonen – Cloud Adoption Framework.
Sie konfigurieren die Diagnose aus der Kategorie Sicherheit der Diagnoseeinstellung in Azure Monitor, wie hier gezeigt.
Unter Diagnoseeinstellungen erfahren Sie, wie Sie diese Protokolle überprüfen und darauf aufmerksam machen können.
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, auf jedes Subnetz eine Netzwerksicherheitsgruppe anzuwenden, die bei der Bereitstellung von Azure-Zielzonen standardmäßig durch die Azure-Richtlinie erzwungen wird. 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 die Quelle und das Ziel, den Port und das Protokoll angeben.
Für eine mehrschichtige, auf einer virtuellen Maschine basierende Anwendung wird empfohlen, für jedes Subnetz, das eine Rolle einer virtuellen Maschine hostet, eine dedizierte Netzwerksicherheitsgruppe (NSG in der folgenden Abbildung) zu erstellen.
In der Abbildung:
- Jede Ebene der Anwendung wird in einem dedizierten Subnetz gehostet, z. B. Front-End-Ebene, App-Ebene und Datenebene.
- 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.
Erstellen Sie mit diesem Prozess eine Netzwerksicherheitsgruppe: Erstellen, ändern oder löschen Sie eine Azure-Netzwerksicherheitsgruppe
Unter Netzwerksicherheitsgruppen erfahren Sie, wie Sie sie zum Schutz der Umgebung verwenden können.
Schritt 4: Erstellen Sie für jede Rolle einer virtuellen Maschine eine Anwendungssicherheitsgruppe.
Mit Anwendungssicherheitsgruppen können Sie die Netzwerksicherheit als natürliche Erweiterung einer Anwendungsstruktur konfigurieren und virtuelle Computer gruppieren sowie auf der Grundlage dieser Gruppen Netzwerksicherheitsrichtlinien definieren. Sie können Ihre Sicherheitsrichtlinie nach Bedarf wiederverwenden, ohne dass Sie explizite IP-Adressen manuell warten müssen. Die Plattform übernimmt die komplexe Verarbeitung von expliziten IP-Adressen und mehreren Regelsätzen, damit Sie sich auf Ihre Geschäftslogik konzentrieren können.
Identifizieren Sie innerhalb Ihrer Workload die spezifischen Rollen der virtuellen Maschine. Erstellen Sie dann für jede Rolle eine Anwendungssicherheitsgruppe. In der Referenzarchitektur sind drei Anwendungssicherheitsgruppen vertreten.
In der Abbildung:
- Zur Unterstützung dieser App werden drei Anwendungssicherheitsgruppen erstellt, eine für jede Ebene: Front-End, App und Daten.
- Jede virtuelle Maschine ist für ihre Rolle der entsprechenden Anwendungssicherheitsgruppe zugeordnet (roter Text im Diagramm).
Weitere Informationen zu Anwendungssicherheitsgruppen und deren Zuweisung zu virtuellen Maschinen finden Sie unter Übersicht über Azure-Anwendungssicherheitsgruppen.
Hinweis
Wenn Sie Load Balancer verwenden, ist die Verwendung der IP-Adresse des Load Balancers in den Netzwerksicherheitsgruppen erforderlich, da Anwendungssicherheitsgruppen einen Load Balancer nicht festlegen können.
Schritt 5: Sicherer Datenverkehr und Ressourcen innerhalb des VNet
In diesem Abschnitt werden die folgenden Empfehlungen behandelt:
- Stellen Sie grundlegende Verweigerungsregeln für Netzwerksicherheitsgruppen bereit
- Stellen Sie anwendungsspezifische Regeln für Anwendungssicherheitsgruppen 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 zulässige Regeln. Durch das Hinzufügen einer Grundlinie von Verweigerungsregeln können Sie die geringste Zugriffsebene erzwingen.
Erstellen Sie nach der Bereitstellung in jeder eingehenden und ausgehenden Regel eine Regel „Alle verweigern“ mit der Priorität 4096. Dies ist die letzte verfügbare benutzerdefinierte Priorität, was bedeutet, dass Sie noch über den verbleibenden Spielraum zum Konfigurieren von Allow-Aktionen verfügen.
Navigieren Sie 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. Sie werden feststellen, dass auf der Registerkarte Eingehende Sicherheit Regeln ein Warnzeichen für die Regel angezeigt wird, wie hier gezeigt.
Wenn Sie auf die Regel klicken und nach unten scrollen, werden weitere Details angezeigt, wie hier gezeigt.
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 hat. Für jedes Verkehrsmuster müssen Sie eine Regel erstellen, die es explizit zulässt, und Sie sollten dies mit der geringsten Anzahl an Berechtigungen tun. Wenn Sie also bestimmte ausgehende Verbindungen für die Verwaltung haben – etwa 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
Wenn Sie Azure Firewall zum Verwalten Ihrer ausgehenden Verbindungen verwenden, können Sie, anstatt alle ausgehenden Verbindungen zu verweigern, alle ausgehenden Verbindungen offen lassen. Als Teil der Azure Firewall-Implementierung richten Sie eine Routentabelle ein, die die Standardroute (0.0.0.0/0) an die Firewall sendet, die den Datenverkehr außerhalb des VNet verarbeitet.
Sie können dann entweder ein „Alle ausgehenden VNet verweigern“ erstellen oder stattdessen alle ausgehenden Daten zulassen (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.
Regeln für die Verwaltung virtueller Maschinen
Um virtuelle Maschinen mit aktivierter Microsoft Entra-Anmeldung, Anti-Malware und automatischen Updates zu konfigurieren, müssen Sie die folgenden ausgehenden Verbindungen zulassen. Viele davon basieren auf FQDN, was bedeutet, dass entweder Azure Firewall für FQDN-Regeln erforderlich ist oder Sie einen komplexeren Plan erstellen. Azure Firewall wird empfohlen.
Die ausgehenden Verbindungen sind:
- Bei Port 443:
- enterpriseregistration.windows.net
- settings-win.data.microsoft.com
- sls.update.microsoft.com
- v10.events.data.microsoft.com
- login.microsoftonline.com
- pas.windows.net
- 169.254.169.254
- Bei Port 80:
- ctldl.windowsupdate.com
- www.msftconnecttest.com
- Bei Port 123:
- 40.119.6.228
- Bei Port 1688:
- 40.83.235.53
Stellen Sie anwendungsspezifische Regeln für Anwendungssicherheitsgruppen bereit
Definieren Sie Verkehrsmuster mit der geringsten Anzahl an Berechtigungen und folgen Sie nur explizit erlaubten Pfaden. Hier ist ein Beispieldiagramm für die Verwendung von Anwendungssicherheitsgruppen zum Definieren von Netzwerkdatenverkehrsmustern in den Netzwerksicherheitsgruppen für ein Spoke-VNet, das zusammen mit einem Hub-VNet verwendet wird. Dies ist die empfohlene Konfiguration.
Als weiteres Beispiel sehen Sie hier eine Konfiguration für ein eigenständiges Spoke-VNet, in dem die Web Application Firewall im Application Gateway-Subnetz des Spoke-VNet platziert ist.
Sie benötigen die folgenden Netzwerksicherheitsgruppenregeln:
- Zulassen von Internetverkehr in das APP GW-Subnetz (HTTPS 443).
- Ermöglichen des Datenverkehrs vom APP-GW-Subnetz zu den virtuellen Maschinen der Front-End-Ebene (HTTPS 433).
- Zulassen von Datenverkehr von den virtuellen Maschinen der Front-End-Ebene zum Load Balancer der App-Ebene (HTTPS 443).
- Zulassen von Datenverkehr vom App-Tier-Load-Balancer zu den virtuellen Maschinen der App-Tier (HTTPS 443).
- Zulassen von Datenverkehr von den virtuellen Maschinen der App-Ebene zum Load Balancer der Datenebene (SQL 1433).
- Zulassen von Datenverkehr vom Lastenausgleich der Datenschicht zu den virtuellen Maschinen der Datenschicht (SQL 1433).
- Zulassen von Datenverkehr zwischen virtuellen Maschinen der Datenebene (SQL 1433)
Konfigurieren Sie zunächst das SQL-Muster und wiederholen Sie den Vorgang dann mit den verbleibenden Ebenen. In den folgenden Abschnitten werden die Konfigurationen für die Regeln beschrieben, die den Netzwerkverkehr für eine einzelne Anwendungsebene beschränken.
Regel 5 - Zulassen von Datenverkehr von den virtuellen Maschinen der App-Ebene zum Load Balancer der Datenebene (SQL 1433).
Navigieren Sie in der Netzwerksicherheitsgruppe für das App-Tier-Subnetz zu Eingehende Sicherheitsregeln und wählen Sie Hinzufügen. Füllen Sie die Liste mit Folgendem:
- Quelle: Anwendungssicherheitsgruppe
- Sicherheitsgruppen der Quellanwendung: Wählen Sie Ihre Anwendungssicherheitsgruppe der Unternehmensebene aus
- Quellportbereiche: 1433 (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.)
- Ziel: IP-Adressen
- Ziel-IP-Adressen/CIDR-Bereiche: die explizite IP des Load Balancers
- Sie müssen hier die explizite IP verwenden, da Sie einen Load Balancer keiner Anwendungssicherheitsgruppe zuordnen können.
- Sie können Ihr IP-Schema planen oder den Load Balancer bereitstellen und sich auf die ihm zugewiesene IP beziehen.
- Service: MS SQL
- Zielportbereiche: Dies wird automatisch für Port 1433 ausgefüllt
- Protokoll: Dies wird automatisch für TCP ausgewählt
- Aktion: Zulassen
- Priorität: Ein Wert zwischen 100 und 4096. Sie können mit 105 beginnen.
- Name: Allow-App-Tier-to-Data-LB-Inbound
- Beschreibung: Ermöglicht eingehenden Zugriff vom Datenschicht-Lastausgleichsmodul auf die virtuellen Maschinen der App-Ebene.
Nach Abschluss werden Sie feststellen, dass es ein blaues Symbol für Informationswarnungen zur Regel gibt. Wenn Sie auf die Regel klicken, wird die folgende Meldung angezeigt:
- „Regeln, die Anwendungssicherheitsgruppen verwenden, dürfen nur angewendet werden, wenn die Anwendungssicherheitsgruppen Netzwerkschnittstellen im selben virtuellen Netzwerk zugeordnet sind.“
Im Folgenden sehen Sie ein Beispiel.
Die Regel gilt nur, wenn diese Anwendungssicherheitsgruppe in diesem Netzwerk verwendet wird.
Navigieren Sie abschließend in derselben Netzwerksicherheitsgruppe zu Ausgehende Sicherheitsregeln und wählen Sie Hinzufügen. Füllen Sie die Liste ähnlich wie im Beispiel aus und ändern Sie dabei Eingehend in Ausgehend.
Regel 6 - Zulassen von Datenverkehr zum Load Balancer der Datenebene (SQL 1433).
Navigieren Sie in der Netzwerksicherheitsgruppe für das Datenebene-Subnetz zu Eingehende Sicherheitsregeln und wählen Sie Hinzufügen. Füllen Sie die Liste mit Folgendem:
- Quelle: IP-Addresse
- Quell-IP-Adresse: Die IP-Adresse des Load Balancers
- Quellportbereiche: 1433
- Ziel: Anwendungssicherheitsgruppe
- Zielanwendungssicherheitsgruppen: Wählen Sie Ihre Datenebenenanwendungssicherheitsgruppe aus
- Service: MS SQL
- Zielportbereiche: Dies wird automatisch für Port 1433 ausgefüllt.
- Protokoll: Dies wird automatisch für TCP ausgewählt.
- Aktion: Zulassen
- Priorität: Ein Wert zwischen 100 und 4096. Sie können mit 105 beginnen.
- Name: Allow-SQL-LB-to-SQL-VMs-Inbound
- Beschreibung: Ermöglicht eingehenden Zugriff auf die SQL-basierten virtuellen Datenschichtmaschinen vom Datenschicht-Lastausgleichsmodul.
Navigieren Sie in der gleichen Netzwerksicherheitsgruppe zu Ausgehende Sicherheitsregeln und wählen Sie Hinzufügen. Füllen Sie die Liste wie im Beispiel beschrieben aus und ändern Sie dabei Eingehend in Ausgehend.
Regel 7 - Zulassen von Datenverkehr zwischen virtuellen Maschinen der Datenebene (SQL 1433)
Navigieren Sie in der Netzwerksicherheitsgruppe für das Datenebene-Subnetz zu Eingehende Sicherheitsregeln und wählen Sie Hinzufügen. Füllen Sie die Liste mit Folgendem:
- Quelle: Anwendungssicherheitsgruppe
- Zielanwendungssicherheitsgruppen: Wählen Sie Ihre Datenebenenanwendungssicherheitsgruppe aus
- Quellportbereiche: 1433
- Ziel: Anwendungssicherheitsgruppen
- Zielanwendungssicherheitsgruppen: Wählen Sie Ihre Datenebenenanwendungssicherheitsgruppe aus
- Service: MS SQL
- Zielportbereiche: Dies wird automatisch für Port 1433 ausgefüllt.
- Protokoll: Dies wird automatisch für TCP ausgewählt.
- Aktion: Zulassen
- Priorität: Ein Wert zwischen 100 und 4096. Sie können mit 105 beginnen.
- Name: Allow-SQL-VM-to-SQL-VM-Inbound
- Beschreibung: Ermöglicht eingehenden Zugriff zwischen virtuellen Maschinen der SQL-basierten Datenebene.
Navigieren Sie in der gleichen Netzwerksicherheitsgruppe zu Ausgehende Sicherheitsregeln und wählen Sie Hinzufügen. Füllen Sie die Liste wie die vorherige Liste aus und ändern Sie dabei Eingehend in Ausgehend.
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
Zusätzlich zum anwendungsspezifischen Datenverkehr müssen Sie den Verwaltungsdatenverkehr einplanen. Allerdings stammt der Verwaltungsdatenverkehr im Allgemeinen außerhalb des Spoke-VNet. Es sind zusätzliche Regeln erforderlich. Zunächst müssen Sie die spezifischen Ports und Quellen verstehen, von denen der Verwaltungsverkehr kommt. Im Allgemeinen sollte der gesamte Verwaltungsverkehr von einer Firewall oder einem anderen NVA fließen, der sich im Hub-Netzwerk für den Spoke befindet.
Die vollständige Referenzarchitektur finden Sie im Artikel Übersicht über die Anwendung von Zero Trust-Prinzipien auf Azure IaaS.
Dies variiert je nach Ihren spezifischen Verwaltungsanforderungen. Allerdings sollten Regeln für die Firewall-Appliances und Regeln für die Netzwerksicherheitsgruppe verwendet werden, um Verbindungen sowohl auf der Plattform-Netzwerkseite als auch auf der Workload-Netzwerkseite explizit zuzulassen.
Stellen Sie die Flussprotokollierung für Netzwerksicherheitsgruppen bereit
Selbst wenn Ihre Netzwerksicherheitsgruppe unnötigen Datenverkehr blockiert, bedeutet das nicht, dass Ihre Ziele erreicht werden. Sie müssen weiterhin den Datenverkehr beobachten, der außerhalb Ihrer expliziten Muster stattfindet, damit Sie wissen, ob ein Angriff stattfindet.
Um die Protokollierung des Netzwerksicherheitsgruppenflusses zu aktivieren, können Sie dem Tutorial: Protokollieren des Netzwerkverkehrsflusses zu und von einer virtuellen Maschine anhand der vorhandenen Netzwerksicherheitsgruppe folgen, die erstellt wird.
Hinweis
- Das Speicherkonto sollte den Leitlinien für Zero Trust-Speicherkonten folgen.
- Der Zugriff auf die Protokolle sollte nach Bedarf eingeschränkt werden.
- Sie sollten bei Bedarf auch in Log Analytics und Sentinel einfließen.
Schritt 6: Sicherer Zugriff auf das VNet und die Anwendung.
Die Sicherung des Zugriffs auf das VNet und die Anwendung umfasst Folgendes:
- Sichern des Datenverkehrs innerhalb der Azure-Umgebung zur Anwendung.
- Die Verwendung von Multi-Faktor-Authentifizierung und Richtlinien für bedingten Zugriff für den Benutzerzugriff auf die Anwendung.
Das folgende Diagramm zeigt diese beiden 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. ichere Verbindungen zwischen Speicherressourcen und den virtuellen Maschinen werden unter Zero Trust-Prinzipien auf Speicher in Azure anwenden konfiguriert.
Informationen zum Sichern des Zugriffs von Hub-Ressourcen auf das VNet finden Sie unter Anwenden von Zero Trust-Prinzipien auf ein virtuelles Hub-Netzwerk in Azure.
Verwenden der Multi-Faktor-Authentifizierung und Richtlinien für bedingten Zugriff für den Benutzerzugriff auf die Anwendung
Der Artikel Zero Trust-Prinzipien auf virtuelle Maschinen anwenden empfiehlt, wie Zugriffsanfragen direkt an virtuelle Maschinen mit Multi-Faktor-Authentifizierung 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 die Anwendung durch Multi-Faktor-Authentifizierung und bedingten Zugriff zu sichern. Dies gilt für alle Benutzer, die auf die App zugreifen.
Wenn die Anwendung noch nicht in Microsoft Entra ID integriert ist, lesen Sie zunächst Anwendungstypen für die Microsoft Identity Platform.
Als nächstes fügen Sie die Anwendung zum Geltungsbereich Ihrer Identitäts- und Gerätezugriffsrichtlinien hinzu.
Verwenden Sie beim Konfigurieren der Multi-Faktor-Authentifizierung 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 virtuellen Maschinen 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 (MDC) 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 Microsoft Defender for Cloud ein Cloud Security Posture Management (CSPM) und Cloud Workload Protection (CWP)-Tool, das Sicherheitsempfehlungen, Warnungen und erweiterte Funktionen wie Adaptive Netzwerkhärtung, um Sie auf Ihrer Reise zur Cloud-Sicherheit zu unterstützen. Um besser zu veranschaulichen, wo Defender für Cloud in die größere Microsoft-Sicherheitslandschaft passt, lesen Sie Microsoft Cybersecurity Regerenzarchitekturen.
In diesem Artikel wird Microsoft Defender für Cloud nicht im Detail behandelt, es ist jedoch wichtig zu verstehen, dass Microsoft Defender für 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 des Sicherheitsstatus sehen. Sie können diese Empfehlungen weiter nach MITRE-Taktik, Ressourcengruppe usw. filtern. Erwägen Sie, die Lösung von Empfehlungen zu priorisieren, die einen größeren Einfluss auf die Sicherheitsbewertung Ihrer Organisation haben.
Hier ist ein Beispiel im Microsoft Defender für Cloud-Portal.
Wenn Sie sich für die Integration eines der Defender für Cloud-Pläne entscheiden, die erweiterten Workload-Schutz bieten, enthält dieser Empfehlungen zur adaptiven Netzwerkhärtung, um Ihre vorhandenen Netzwerksicherheitsgruppenregeln 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
- Sichern des Zugriffs auf Ihre Anwendungen mithilfe von Azure-Identitätsdiensten
Weitere Trainings zur Sicherheit in Azure finden Sie in den folgenden Ressourcen im Microsoft-Katalog:
Sicherheit in Azure | Microsoft Learn
Nächste Schritte
Lesen Sie diese zusätzlichen Artikel zur Anwendung von Zero Trust-Prinzipien auf Azure:
- Azure IaaS – Übersicht
- Azure Virtual Desktop
- Azure Virtual WAN
- IaaS-Anwendungen in Amazon Web Services
- Microsoft Sentinel und Microsoft Defender XDR
Technische Illustrationen
Dieses Poster bietet auf einer Seite eine Übersicht über die Komponenten von Azure IaaS als Referenz- und logische Architekturen sowie die Schritte, um sicherzustellen, dass diese Komponenten den „Niemals vertrauen, immer überprüfen“-Prinzipien des Zero-Trust-Modells angewandt werden.
| Element | Beschreibung |
|---|---|
 PDF | Visio Aktualisiert im März 2024 |
Verwenden Sie diese Abbildung zusammen mit diesem Artikel: Zero Trust-Prinzipien auf Azure IaaS anwenden – Übersicht. Verwandte Lösungsleitfäden |
Dieses Poster stellt die Referenz- und logischen Architekturen sowie die detaillierten Konfigurationen der einzelnen Komponenten von Zero Trust für Azure IaaS bereit. Nutzen Sie die Seiten dieses Posters für einzelne IT-Abteilungen oder Fachgebiete oder passen Sie die Diagramme mit der Microsoft Visio-Version der Datei an Ihre Infrastruktur an.
| Element | Beschreibung |
|---|---|
 PDF | Visio Aktualisiert im März 2024 |
Verwenden Sie diese Diagramme zusammen mit den Artikeln, die hier beginnen: Zero Trust-Prinzipien auf Azure IaaS anwenden – Übersicht. Verwandte Lösungsleitfäden |
Für weitere technische Illustrationen klicken Sie hier.
References
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für