Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Dieser Artikel hilft Ihnen beim Einrichten von Governance- und Sicherheitsbaselines, sodass jede Azure-VMware-Lösung Workload konsistente Kontrollen erbt und risiken vor dem Onboarding reduziert.
Dieser Artikel hilft Entscheidungsträgern beim Einrichten der Governance- und Sicherheitsbasis, die jeder Azure-VMware-Lösung Workload standardmäßig erbt. Eine Baseline ist die Mindestmenge an Sicherheitskontrollen, die jede Azure-VMware-Lösung-Workload bevor ein Workloadteam eingebunden wird, übernimmt. Sie erstellen und verwalten diese Basispläne. Erstellen Sie zusätzliche Steuerelemente, um die Anforderungen der Organisation zu erfüllen, z. B. die Einhaltung gesetzlicher Vorschriften oder die Verwaltung von arbeitslastspezifischen Risiken.
Die grundlegende Anleitung hier geht von Azure-VMware-Lösung Generation 2 (Gen 2) aus, bei der die private Cloud standardmäßig innerhalb eines virtuellen Azure-Netzwerks bereitgestellt wird, wodurch eine native Konnektivität mit Azure-Diensten und Azure-native Steuerungsmöglichkeiten gegeben ist. Generation 1 (Gen 1) ist die Legacyausnahme und wird nur dann aufgerufen, wenn sich ihre Funktionen unterscheiden.
Wenden Sie die gleichen Governance- und Sicherheitsgrundwerte auf Nichtproduktionsumgebungen an, wie Sie es für Produktionsumgebungen tun. Wenn Sie konsistente Basispläne haben, bedeutet dies das geringere Risiko von Schwachstellen in Ihrem Gesamtbestand und vereinfacht den Übergang von Arbeitslasten von einer Umgebung zu einer anderen.
Empfehlung: Bestimmen Sie die Governance- und Sicherheitsgrundwerte, die jeder Azure-VMware-Lösung Workload sowohl in der Azure-Umgebung als auch in der privaten VMware-Cloud erben muss, bevor Sie Anwendungen oder Betriebsteams integrieren.
1. Umfang der Governance-Basislinie
Azure-VMware-Lösung erfordert Governance auf zwei Oberflächen, und ein Basisplan, der nur eine davon abdeckt, hinterlässt Lücken bei der Kontrolle und dem Risiko.
Azure Governance: Die Azure Oberfläche ist der Satz von Azure Ressourcen, die die private Cloud unterstützen, z. B. das Abonnement, das virtuelle Netzwerk, die Überwachung und Azure Rollenzuweisungen. Sie steuern es mit Azure nativen Tools.
Private Cloud-Governance: Die VMware-Oberfläche ist die private Cloud selbst, z. B. Netzwerksegmente, Firewallrichtlinien, vCenter- und DLP-Rollen und Speicherrichtlinien. Sie steuern die meisten davon mit VMware-nativen Tools in der privaten Cloud.
Eine Governance-Basislinie, die nur die Azure Umgebung oder nur die VMware-Umgebung behandelt, schafft Lücken bei der betrieblichen Kontrolle und dem Risikomanagement.
2. Durchsetzung von Governance-Vorgaben
Erzwingen Sie Mindestanforderungen nach Möglichkeit über die Landing Zone der Plattform. Verwenden Sie manuelle Betriebsprozesse, um die Erzwingung zu unterstützen, wenn technische Steuerelemente nicht verfügbar sind.
Wenden Sie Azure Policy auf Verwaltungsgruppen-, Abonnement- oder Ressourcengruppenebene an, um obligatorische Anforderungen für jede Azure-VMware-Lösung Bereitstellung festzulegen. Mithilfe von Azure Policy können Sie die Konsistenz in Azure-VMware-Lösung privaten Clouds sicherstellen, insbesondere wenn Sie die VMware-Verwaltung an Workloadbesitzer delegieren. Bringen Sie diese Anforderungen mit den Standards in Einklang, die bereits in der gesamten Azure-Umgebung verwendet werden. Einige Standarderzwingungsrichtlinien und -mechanismen umfassen:
Bereitstellungsgrenzen:Zulässige Speicherorte
Azure-VMware-Lösung SKUs:Zulässige Ressourcentypen (angepasst für Azure-VMware-Lösung)
Schützen der privaten Cloud: Ressourcensperren (keine Azure Policy Definition)
3. Sicherheitsgrundwerte
Jede Azure-VMware-Lösung-Bereitstellung sollte vor dem Onboarding von Workloads eine genehmigte Sicherheitsbaseline übernehmen. Beginnen Sie mit der Azure Sicherheitsbasislinie für Azure-VMware-Lösung, die Azure-VMware-Lösung Funktionen dem Microsoft Cloud Security Benchmark zuordnet und Microsoft empfohlenen Sicherheitsleitfaden bereitstellt. Microsoft Defender for Cloud kann die Umgebung kontinuierlich anhand anwendbarer Empfehlungen und behördlicher Kontrollen bewerten. Azure Policy-Definitionen, die Benchmarkkontrollen zugeordnet sind, werden im Bereich „Regulatorische Compliance“ in Microsoft Defender for Cloud angezeigt. Siehe Azure-VMware-Lösung Sicherheitsempfehlungen.
4. Azure-VMware-Lösung Identitätsbasisplan
Da Azure-VMware-Lösung Ihre vorhandenen Identitätsdienste verwendet, bezieht sich die Baseline darauf, wie Sie sich mit Ihren Ressourcen, z. B. virtuellen Maschinen, verbinden, anstatt neue Identitätsdienste bereitzustellen. Dieser Basisplan bezieht sich auf die von Azure-VMware-Lösung selbst verwendeten Identitätsdienste und wirkt sich nicht auf die Identitätsdienste aus, die von einzelnen Anwendungsworkloads verwendet werden, die auf VMware ausgeführt werden.
4.1 Identitätsanbieter
Verwenden Sie eine externe Identitätsquelle für den vCenter-Zugriff anstelle des integrierten CloudAdmin-Kontos. Azure-VMware-Lösung unterstützt sowohl Microsoft Entra ID als auch Active Directory (LDAPS) als externe Identitätsquellen für vCenter Server.
Option 1: Microsoft Entra ID (empfohlen). Organisationen, die bereits Microsoft Entra ID als Standard verwenden, sollten den Entra ID-Verbund bevorzugen, da er die Identitätsgovernance, den Bedingten Zugriff und die mehrstufige Authentifizierung für die Azure- und VMware-Verwaltung zentralisiert.
Option 2. Active Directory Domain Services über LDAPS. Organisationen mit betrieblichen Abhängigkeiten von einer in Active Directory integrierten VMware-Verwaltung können weiterhin LDAPS verwenden. Sie gewährleistet die Kontinuität bestehender AD-integrierter VMware-Admin-Workflows. Sie betreiben AD-Domänencontroller in Azure zentral im Abonnement für die Plattformidentität.
4.2 Benutzerberechtigungen
Benutzerzugriffsentscheidungen richten die Grundlage für die sichere Verwaltung von Azure-VMware-Lösung ein. Definieren Sie vor dem Onboarding von Betriebsteams, wie Administratoren Zugriff erhalten, welche Rollen sie verwenden können und wie der Zugriff im Laufe der Zeit überprüft wird.
Gruppenbasierte Zuordnung: Definieren Sie Administratorgruppen vor dem Onboarding von operativen Teams. Weisen Sie Benutzern Gruppen zu, und weisen Sie Rollen Gruppen zu. Vermeiden Sie direkte Benutzerzuweisungen mit Ausnahme temporärer Ausnahmen.
VCenter-Rollen mit geringsten Rechten: Verwenden Sie benutzerdefinierte vCenter-Rollen, wenn die CloudAdmin-Rolle mehr Zugriff gewährt als ein Team benötigt. Azure-VMware-Lösung unterstützt benutzerdefinierte Rollen in vCenter mit Berechtigungen, die der Rolle "CloudAdmin" entsprechen oder niedriger sind. Im Azure-VMware-Lösung-Portal werden keine benutzerdefinierten Rollen angeboten.
NSX Manager gleich behandeln: Wenden Sie denselben Prozess für die Zugriffsgovernance auf den NSX Manager an. Definieren Sie genehmigte Administratorrollen, wenden Sie die geringsten Berechtigungen an, und führen Sie regelmäßige Zugriffsüberprüfungen durch. Nicht jede vordefinierte NSX-Rolle wird unterstützt, also definieren Sie eine kleine Auswahl genehmigter NSX-Rollen und überprüfen Sie diese regelmäßig.
4.3 CloudAdmin-Rolle
Die Rolle "CloudAdmin" in Azure-VMware-Lösung verhält sich anders als der lokale VMware-Administratorzugriff, und die Behandlung wie ein tägliches Treiberadministratorkonto ist ein häufiger Fehler. Behandeln Sie CloudAdmin als Notfallzugangsdaten, die regelmäßig geändert, überwacht und auf Notfälle beschränkt werden. Gewähren des täglichen Zugriffs über externe Identitätsgruppen, die den Rollen mit den geringsten Berechtigungen zugeordnet sind.
Nur für Notfälle: Verwenden Sie das integrierte CloudAdmin-Konto nicht für die tägliche Verwaltung oder die Serviceintegration. Behalten Sie es als Break-Glass-Konto für den Zugriff im Notfall vor. Speichern Sie die Zugangsdaten über Ihren Prozess für privilegierten Zugriff, wechseln Sie sie nach einem festgelegten Zeitplan, und lösen Sie bei Abruf oder Verwendung einen Alarm aus.
Kein Zugriff auf Hostebene: Azure-VMware-Lösung Administratoren erhalten nicht das vCenter Server-Konto administrator@vsphere.local oder das ESXi-Stammkonto. Administratoren können jedoch Active Directory Benutzer und Gruppen der CloudAdmin-Rolle in vCenter Server zuweisen.
Verwaltete SSO-Domäne: Die vsphere.local SSO-Domäne ist eine verwaltete Ressource , die Plattformvorgänge unterstützt. Sie können es nicht verwenden, um lokale Benutzer und Gruppen zu erstellen oder zu verwalten, die über die Standardkonten hinausgehen, die mit der privaten Cloud bereitgestellt werden.
Hinzufügen einer Identitätsquelle: Die CloudAdmin-Rolle kann keine Identitätsquelle (z. B. LDAP/LDAPS) direkt hinzufügen. Verwenden Sie Befehle "Ausführen" , um eine externe Identitätsquelle hinzuzufügen und benutzern und Gruppen die Rolle "CloudAdmin" zuzuweisen.
5. Azure-VMware-Lösung Netzwerkbasisplan
Jede private Cloud verwendet VMware NSX als softwaredefinierte Netzwerkebene und ersetzt damit das VLAN-basierte Modell aus der lokalen VMware-Umgebung. Ihre Teams erstellen NSX-Segmente für Workloads, leiten Datenverkehr über NSX-Tier-0- und Tier-1-Gateways und definieren verteilte Firewallregeln. Planen Sie den Netzwerksicherheitsansatz frühzeitig, und legen Sie eine klare Grenze fest:
Verwenden Sie NSX für den Datenverkehr innerhalb der Azure-VMware-Lösung-Umgebung (Ost-West).
Verwenden Sie Azure-native oder lokale Steuerungen für Datenverkehr, der die Grenze der Azure-VMware-Lösung überschreitet (Nord-Süd).
5.1 Ost-West-Verkehrsbasis
Ost-West-Kontrollen steuern den Datenverkehr zwischen Workloads innerhalb der privaten Cloud. Setzen Sie Mikrosegmentierung mit der verteilten NSX-Firewall für jede Workload durch. Fügen Sie vDefend nur hinzu, wenn ein bestimmtes Steuerelementziel dies erfordert.
Option 1: NSX-Firewall. Verwenden Sie immer die verteilte NSX-Firewall, um die Mikrosegmentierung zwischen Workloads durchzusetzen. Mikrosegmentierung begrenzt die Lateralausbreitung, wenn ein Angreifer einen Workload erreicht, indem sie beispielsweise einen kompromittierten Webserver daran hindert, auf eine Datenbank zuzugreifen. Teams schöpfen diese Funktion direkt nach der Migration oft nicht aus, daher sollte sie zum Standard gehören.
Option 2. NSX-Firewall und VMware vDefend Firewall. Wenn die verteilte Firewall eine bestimmte Anforderung nicht erfüllt, prüfen Sie das optionale Add-on VMware vDefend Firewall hinsichtlich von Funktionen, die NSX allein nicht bietet, wie z. B. Einbruchserkennung und URL-Filterung. Setzen Sie sie nur ein, wenn diese Funktionen einem Kontrollziel entsprechen, das Sie erfüllen müssen.
Wenden Sie denselben Least-Privilege-Ansatz auf NSX an, indem Sie einschränken, wer Änderungen an Firewallregeln, Segmenten und dem Routing vornehmen darf. Implementieren Sie Änderungskontrolle und Auditierung, da NSX-Aktualisierungen die gemeinsam genutzte Konnektivität beeinträchtigen und mehrere Workloads stören können.
5.2 Nord-Süd-Verkehrsbasis
Nord-Süd-Kontrollen steuern den Datenverkehr, der in die Azure-VMware-Lösung Umgebung eintritt und verlässt. Das richtige Tool hängt von Ihrem umfassenderen Azure Netzwerkdesign ab.
Option 1.Azure Firewall oder ein Drittanbieter-NVA. Viele Organisationen untersuchen diesen Datenverkehr mit Azure Firewall oder einer virtuellen Drittanbieter-Appliance, die in Ihrem zentralisierten Plattformabonnement "Konnektivität" platziert wurde.
Option 2.GATEWAY-Firewall am Edge. Verwenden Sie die GATEWAYfirewall am Azure-VMware-Lösung Edge, wenn Sie lieber an der Grenze der privaten Cloud prüfen möchten.
Option 3.Lokale Firewall. Einige leiten den Internetausgang über eine vorhandene lokale Firewall weiter.
Fügen Sie unter Gen 2 auf der Ebene des virtuellen Azure-Netzwerks Azure-Netzwerksicherheitsgruppen (NSGs) hinzu, um eine zusätzliche Azure-native Ebene zu schaffen, die NSX ergänzt. Gen 1 bietet keine NSGs an.
Wenn Sie Steuerelemente auf mehr als eine Ebene anwenden, planen Sie, wie Sie diese konsistent halten. Steuerelemente, die über Ebenen aufgeteilt werden, fügen Komplexität hinzu, erschweren die Problembehandlung und können unbeabsichtigte Datenverkehrspfade erstellen. Wenn Sie automatisierte Netzwerktools verwenden, entscheiden Sie vorab, wie Richtlinien über VMware und Azure synchronisiert werden. Dokumentieren Sie die Netzwerkkonnektivitätsanforderungen der Workload, und stellen Sie sicher, dass die gleiche Dokumentation und derselbe Änderungsbenachrichtigungsprozess von VMware-Administratoren und vorgelagerten Netzwerkadministratorteams verwendet wird.
6. Azure-VMware-Lösung Kostenbasisplan
Die Kostengovernance legt die Finanzschutzschienen fest, die jede Azure-VMware-Lösung Bereitstellung erbt. Sie benötigen mindestens ein Budget mit Warnungen, einen erforderlichen Taggingstandard und einen benannten Genehmiger für Kapazitätsänderungen für jedes Azure-VMware-Lösung-Abonnement.
Budgets und Warnungen: Verwenden Sie Microsoft Cost Management, um Budgetschwellenwerte und Ausgabenwarnungen festzulegen, damit Budgetüberschreitungen frühzeitig erkannt werden. Fordern Sie Workloadteams an, Warnungen für CPU-, Arbeitsspeicher- und vSAN-Auslastungsschwellenwerte zu konfigurieren und diese Warnungen an einen benannten Vorgangsbesitzer weiterzuleiten, damit die Antwort nicht mehrdeutig ist. Legen Sie die Schwellenwerte zentral fest, z. B. die Warnung bei einer nachhaltigen CPU-Auslastung von 75 Prozent für Produktionscluster, sodass Kapazitätsentscheidungen auf denselben Daten in jedem Team basieren. Siehe Konfigurieren von Benachrichtigungen für Azure-VMware-Lösung.
Tagging: Verwenden Sie Tags für Azure-VMware-Lösung-Ressourcen, damit sich Kosten den Besitzern und Workloads zuordnen lassen und Sie darüber Berichte erstellen können. Siehe Richtliniendefinitionen zum Kategorisieren von Ressourcen.
Kapazität: Behandeln Sie das Hinzufügen von Hosts als absichtliche, genehmigte Aktion. Entscheiden Sie, wer neue Kapazität genehmigen kann. Legen Sie Standards für die minimale und maximale Clustergröße und für genehmigte Bereitstellungsregionen fest, und benötigen Sie einen Kapazitätskopfpuffer, damit ein Datenspeicher nie zu voll ausgeführt wird. Anfordern des Hostkontingents vor Bedarf. Kontingentanforderungen fügen keine Kosten hinzu, aber eine Kapazitätszugabe kann mehrere Tage dauern, bis sie erfüllt werden. Stellen Sie sicher, dass Ihr Prozess den Erwerb der erforderlichen VCF-Lizenzen für neu hinzugefügte Azure-VMware-Lösung Hosts umfasst.
7. Azure-VMware-Lösung Basisplan für Gast-VM
Microsoft verwaltet die Azure-VMware-Lösung-Infrastruktur, einschließlich der ESXi-Hosts, des vCenter Server und von NSX. Sie bleiben für die Gastbetriebssysteme, Anwendungen und die Sicherheitskontrollen verantwortlich, die auf jedem virtuellen Computer ausgeführt werden.
Weiten Sie die Governance auf Gastbetriebssysteme aus, indem Sie virtuelle Maschinen in Azure Arc-fähiges VMware vSphere integrieren. Siehe Azure Arc-fähiges VMware vSphere.
Sobald ein virtueller Computer für Arc aktiviert ist, können Organisationen Azure Policy-Computerkonfiguration, Microsoft Defender-Dienste, Update-Manager und andere Azure-Verwaltungsfunktionen unter Verwendung derselben Governanceprozesse nutzen wie für virtuelle Azure-Computer. Siehe integrierte Richtliniendefinitionen für Azure Arc-fähige Server und Erstellen benutzerdefinierter Computerkonfigurationsrichtliniendefinitionen.
7.1 Gastkonfigurationsbasisplan
Erfordert Azure Arc Onboarding als Teil des Bereitstellungsprozesses für virtuelle Computer. Ein frühzeitiges Onboarding stellt sicher, dass Governance-Kontrollen vom ersten Tag an greifen, statt erst später mit manuellem Aufwand hinzugefügt zu werden. Azure Arc ermöglicht Funktionen wie Bestand, Änderungsnachverfolgung und Computerkonfiguration.
Diese Dienste funktionieren in Azure-VMware-Lösung genauso wie für Azure-VMs, sobald das Gastbetriebssystem für Arc aktiviert ist. Organisationen können dann die gleichen Konfigurationsstandards für Azure, lokale VMware und Azure-VMware-Lösung Umgebungen anwenden.
7.2 Endpunktschutz
Endpunktschutzstandards sollten unabhängig davon, wo der virtuelle Computer ausgeführt wird, konsistent bleiben. Für Azure-VMware-Lösung virtuelle Computer bietet Azure Arc-fähige VMware vSphere den Integrationspfad, der zum Bereitstellen von Microsoft Defender for Endpoint und anderen Azure Sicherheitsdiensten erforderlich ist. Dieser Ansatz ermöglicht Es Sicherheitsteams, einen einheitlichen Überblick über die Sicherheitslage von Endpunkten in der gesamten Hybridumgebung zu erhalten. Siehe Integrieren von Microsoft Defender for Cloud mit Azure-VMware-Lösung.
7.3 Patch-Basislinie
Microsoft ist für das Patchen der Azure-VMware-Lösung-Infrastruktur verantwortlich. In Ihrer Organisation sind in der Regel das IT-Betriebsteam oder Die Workload-Administratorteams für das Patchen von Gastbetriebssystemen und -anwendungen verantwortlich. Wenn Ihre Organisation von etablierten Enterprise-Patching-Lösungen abhängt, verwenden Sie weiterhin diese Tools, in denen erweiterte Planungs- oder Orchestrierungsanforderungen vorhanden sind. Diese Anforderungen können Azure Update Manager auf arcfähigen Azure-VMware-Lösung virtuellen Computern enthalten.
7.4 VM-Erweiterungsbasisplan
VM-Erweiterungen bieten Funktionen wie Sicherheitsüberwachung, Telemetriesammlung und Betriebsverwaltung. Ohne Governance kann die Erweiterungsbereitstellung fragmentiert und schwer zu kontrollieren sein.
Definieren Sie einen genehmigten Erweiterungskatalog, und erfordern Sie Arbeitsauslastungsteams, nur autorisierte Erweiterungen zu verwenden. Koppeln Sie die Erweiterungsgovernance mit Azure Policy, um Compliance zu erzwingen und nicht autorisierte Konfigurationen zu erkennen.