Ändern einer Azure-Zielzonenarchitektur zum Erfüllen der Anforderungen über mehrere Standorte hinweg

Organisationen in vielen Branchen unterliegen gesetzlichen Anforderungen, zu denen Anforderungen an die Datenresidenz, Datensicherheit und Datenhoheit gehören. Manche Organisationen müssen an verschiedenen geografischen Standorten gegensätzliche Vorschriften einhalten. In diesem Fall müssen sie ihre Azure-Zielzonenarchitektur in Übereinstimmung mit allen geltenden Vorschriften ändern.

Es könnte zum Beispiel zwei gegensätzliche Vorschriften, Vorschrift A und Vorschrift B, geben. Während Vorschrift A die Datenresidenz in Land oder Region A vorschreibt, verlangt Vorschrift B die Datenresidenz in Land oder Region B.

Solche Konflikte zwischen Vorschriften können bestehen für:

• Multinationale Organisationen wie multinationale Unternehmen oder Nichtregierungsorganisationen (NGOs), die lokale Vorschriften in den Ländern oder Regionen einhalten müssen, in denen sie tätig sind.

• Unabhängige Softwarehersteller (ISVs), die Lösungen für Organisationen an mehreren Standorten bereitstellen, wobei die Lösung jeweils die lokalen Vorschriften jedes Standorts einhalten muss.

• ISVs, die Lösungen für multinationale Organisationen bereitstellen, die die lokalen Vorschriften der jeweiligen Länder oder Regionen einhalten müssen, in denen sie tätig sind.

Wenn Sie nur einen einzigen Satz gesetzlicher Anforderungen erfüllen müssen, lesen Sie Anpassen der Architektur der Azure-Zielzonen an die Anforderungen.

Überlegungen zu gesetzlichen Vorschriften

Gesetzliche Anforderungen betreffen in der Regel den Datenschutz, die Datenresidenz, Datenübertragungen, die Isolation oder die Sicherheitsüberprüfung von Personal. Diese Anforderungen können an verschiedenen geografischen Standorten gegensätzlich sein. Eine Verordnung der Europäischen Union (EU) kann z. B. eine Datenresidenz in einem EU-Land vorschreiben, während eine Verordnung des Vereinigten Königreichs eine Datenresidenz im Vereinigten Königreich verlangt.

Wenn Vorschriften zu Konflikten bei der Richtlinienkontrolle führen, müssen Sie die Azure-Zielzonenarchitektur und die Richtlinienzuweisungen entsprechend anpassen. Weitere Informationen finden Sie im Abschnitt Szenarien, die Änderungen erfordern in diesem Artikel.

Wenn mehrere Vorschriften gelten, müssen Sie die Azure-Zielzonenarchitektur in folgenden Fällen nicht ändern:

• Mehrere Vorschriften erfordern die gleichen Azure Policy-Zuweisungen.

• Die Kontrollen einer Vorschrift sind eine Obermenge einer anderen Vorschrift. Die Kontrollen der Obermenge gelten automatisch für beide Vorschriften.

• Die Kontrollen in mehreren Vorschriften überschneiden sich nicht. Bei Implementierung mehrerer Kontrollsätze deckt eine einzige Implementierung alle Vorschriften ab. Die Azure Policy-Zuweisungen ergänzen einander.

• Verschiedene Vorschriften haben unterschiedliche Arten der Implementierung. Aus regulatorischer Sicht spielt es keine Rolle, welche Implementierung Sie auswählen. Es könnte zum Beispiel zwei Vorschriften mit einem jeweils anderen Autorisierungsmodell geben, das aber in beiden Fällen akzeptabel ist. Sie können die für Ihre Organisation am besten geeignete Implementierung auswählen.

Überlegungen für ISVs

Es gibt drei Bereitstellungsmodelle für ISVs.

• Reine Software-as-a-Service (SaaS): Der ISV stellt die Lösung als Service bereit.

• Kundenseitige Bereitstellung: Der Kunde stellt die Lösung in seiner eigenen Umgebung bereit.

• SaaS mit dualer Bereitstellung: Dieses Modell kombiniert das Modell der kundenseitigen Bereitstellung mit dem reinen SaaS-Modell.

In einem reinen SaaS-Modell ist der ISV für die Verwaltung der Compliance im Auftrag des Kunden verantwortlich. Der ISV muss dem Kunden und gegebenenfalls Prüfern oder Regulierungsbehörden die Compliance nachweisen. Wenn Sie das SaaS-Modell nutzen, gelten für Ihre Architektur möglicherweise mehrere Vorschriften, die zueinander in Konflikt stehen können. Der ISV muss die Compliance für diese verschiedenen Vorschriften verwalten. Weitere Informationen finden Sie im Abschnitt Szenarien, die Änderungen erfordern in diesem Artikel.

In einem Modell mit kundenseitiger Bereitstellung ist der Kunde für die Verwaltung der Compliance verantwortlich. Für dieses Modell muss der ISV die Zielzonen nicht ändern. Die Lösung wird jedoch in einer vom Kunden bereitstellten Zielzone bereitgestellt, inklusive Richtlinienkontrollen und benutzerdefinierte Richtlinien.

In einem SaaS-Modell mit dualer Bereitstellung gelten alle Überlegungen für das Modell mit kundenseitiger Bereitstellung und das reine SaaS-Modell.

Überlegungen für multinationale Organisationen

In multinationalen Organisationen gibt es verschiedene Strukturen zur Organisation ihrer IT-Governance.

• Dezentrale Struktur: IT-Funktionen werden an jedem geografischen Standort lokal gesteuert.

• Zentrale Struktur: IT-Funktionen werden von einem zentralen Ort, in der Regel vom Hauptsitz der Organisation, gesteuert.

• Hybride Struktur: Globale IT-Funktionen werden zentral bereitgestellt, während die nur lokal benötigten IT-Funktionen am jeweiligen geografischen Standort gesteuert werden.

In einem dezentralen Szenario ist das lokale IT-Team für die Verwaltung der Compliance verantwortlich und kann seine Zielzone entsprechend anpassen.

In einem zentralen Szenario ist das zentrale IT-Team für die Verwaltung der Compliance verantwortlich und muss sicherstellen, dass die Lösungen die lokalen Complianceanforderungen aller geografischen Standorte erfüllen, an denen die multinationale Organisation tätig ist. Die Complianceanforderungen verschiedener geografischer Standorte können gegensätzlich sein, so dass Zielzonen geändert werden müssen.

In einem hybriden Szenario gelten die Überlegungen für das dezentrale und zentrale Szenario. Die zentrale Organisation liefert Lösungen, die die lokalen Organisationen in ihrer Umgebung bereitstellen müssen. Die zentrale Organisation prüft außerdem die Bereitstellung dieser Lösungen in allen Zielzonen der lokalen Organisationen.

Szenarien, die Änderungen erfordern

Die Zielzonen müssen gegebenenfalls geändert werden, wenn die den verschiedenen Bereitstellungen zugewiesenen Richtliniensätze gegensätzlich sind. Es kann mehrere Lösungen oder eine einzelne Lösung geben, die für verschiedene geografische Standorte oder Datenklassifizierungen zur Verfügung gestellt werden müssen.

Der Umfang der erforderlichen Änderung hängt von dem in der Vorschrift verlangten Isolationsgrad ab. Je mehr Bedingungen eine Vorschrift enthält, desto mehr Änderungen sind an der Zielzone erforderlich. Wenn z. B. Vorschriften Bedingungen wie Personal mit Sicherheitsüberprüfung, verschiedene Identitätsanbieter oder Verzeichnisse, separate Verwaltungsinfrastruktur oder separate Konnektivitätsinfrastruktur vorgeben, sind umfangreiche Änderungen an der Zielzone erforderlich. Wenn Vorschriften nur die Isolation der Anwendungs- und Konnektivitätsinfrastruktur verlangen, sind nur minimale Änderungen an der Zielzone erforderlich.

Microsoft Entra-Mandanten

Wir empfehlen den Einsatz eines einzigen Microsoft Entra-Mandanten für die meisten Szenarien, einschließlich multinationaler Szenarien. Es gibt jedoch Szenarien, in denen Sie gegebenenfalls mehrere Microsoft Entra-Mandanten bevorzugen oder brauchen, wie z. B.:

• Wenn Sie den Microsoft Entra-Mandanten des Unternehmens vom SaaS Microsoft Entra-Mandanten trennen müssen, um die Sicherheit zu verbessern und klare Grenzen zwischen Produkt- und Geschäftsvorgängen zu schaffen.

• Wenn gegensätzliche Vorschriften gelten und Sie separate Microsoft Entra-Mandanten für unterschiedliche Rechtssysteme benötigen. So könnten Vorschriften zum Beispiel Sicherheitsüberprüfungs- und Staatsangehörigkeitsanforderungen umfassen, die eine vollständige Isolation zwischen Microsoft Entra-Mandanten erfordern, oder Datenresidenzanforderungen, die separate Mandanten erfordern. Zu den häufigen Szenarien gehört ein ISV, der isolierte Instanzen einer SaaS-Lösung bereitstellen muss, oder eine multinationale Organisation, die isolierte Instanzen derselben Lösung bereitstellen muss.

Im Fall der Zusammenarbeit über mehrere Microsoft Entra-Mandanten hinweg müssen Sie sich sorgfältig auf beträchtliche Herausforderungen und Erfordernisse einstellen. Erstellen Sie nur die Mindestanzahl von Microsoft Entra-Mandanten, die Sie zur Erfüllung betrieblicher oder gesetzlicher Anforderungen benötigen. Sie können anhand von Verwaltungsgruppen und rollenbasierter Zugriffssteuerung in Azure (RBAC) den Zugriff auf Abonnements und Ressourcen unter einem einzigen Mandanten steuern, wie im nächsten Abschnitt beschrieben.

Die folgenden Diagramme zeigen Optionen, die Sie für die Organisation Ihrer Microsoft Entra-Mandanten nutzen können.

Weitere Informationen finden Sie unter Azure-Zielzonen und mehrere Microsoft Entra-Mandanten und ISV-Überlegungen zu Azure-Zielzonen.

Verwaltungsgruppen

Wenn Sie keine separaten Microsoft Entra-Mandanten für eine strenge Isolation brauchen, sollten Sie mehrere Azure-Zielzonen in einem einzigen Microsoft Entra-Mandanten bereitstellen. Sie können die Verwaltungsgruppenhierarchie so anpassen, dass die Anforderungen gegensätzlicher Vorschriften erfüllt werden.

Sie können eine vollständige Zielzonenarchitektur für jeden Satz von Vorschriften bereitstellen, die voneinander getrennt werden sollen. Dieses Modell erfordert die geringste Anpassung und ermöglicht Ihnen die Nutzung der vorhandenen Automatisierung für die Bereitstellung.

Freigabe der Plattformverwaltungsgruppe

Wenn die Vorschrift es zulässt, kann die Plattformverwaltungsgruppe freigegeben werden. Sie können unter der Zielzonenverwaltungsgruppe separate Verwaltungsgruppen für jeden Satz von Vorschriften erstellen, die voneinander getrennt werden müssen. Sie können den einzelnen Anwendungsverwaltungsgruppen die entsprechenden Richtlinien zuweisen. Die Anwendungszielzonen teilen die Verwaltungsgruppen, die sich unter der Plattformverwaltungsgruppe befinden. Die Ressourcen in den Anwendungsverwaltungsgruppen können auch durch Abonnement oder Ressourcengruppe voneinander getrennt werden.

Diese Verwaltungsgruppenhierarchie ist ein einfaches und kostengünstiges Design zum Isolieren von Anwendungen mit gegensätzlichen Vorschriften. In diesem Design müssen aber die Plattformverwaltungsgruppen für Konnektivität, Identität/Sicherheit und Verwaltung denselben Richtliniensatz haben. Gegebenenfalls brauchen Sie für jede Plattformverwaltungsgruppe unterschiedliche Richtliniensätze, wenn die Vorschrift Einschränkungen vorgibt für die Freigabe von Konnektivitätsinfrastruktur, Identitätsdiensten und Schlüsselverwaltungsdiensten oder für die Infrastruktur, von der die gesamte Umgebung verwaltet wird.

Isolieren von Identität und Sicherheit

Wenn Vorschriften die Freigabe der Identitäts- und Schlüsselverwaltungsinfrastruktur verhindern, können Sie die Plattformverwaltungsgruppe unterteilen. Belassen Sie die Verwaltungsgruppen für Konnektivität und Verwaltung in der freigegebenen Plattformverwaltungsgruppe und unterhalten Sie eine Identitäts- und Sicherheitsverwaltungsgruppe, die den jeweiligen Vorschriftensätzen zugeordnet ist.

Diese Verwaltungsgruppenhierarchie ist wesentlich komplexer als eine vollständig freigegebene Plattformverwaltungsgruppe, da Sie die Plattformverwaltungsgruppe teilweise replizieren müssen. Um die Komplexität zu begrenzen, können Sie die vollständige Hierarchie für die einzelnen Vorschriftensätze und die freigegebene Umgebung bereitstellen und die überflüssigen Verwaltungsgruppen ignorieren oder löschen.

Isolieren der Konnektivität

Viele Vorschriften umfassen Anforderungen in Bezug auf die Verarbeitung und Speicherung von Daten an einem bestimmten geografischen Standort und nur wenige Anforderungen hinsichtlich der Verbindung von Benutzern mit Anwendungen. Für diese Vorschriften können Sie die Konnektivitätsverwaltung freigeben, wie in der vorherigen Architektur gezeigt. Es gibt zwar vielleicht keine Vorschriften, die verlangen, dass Sie die Infrastruktur in mehreren Regionen duplizieren, aber zu Latenzzwecken könnte das dennoch erforderlich sein. Die zugewiesenen Richtlinien müssen das Duplizieren der Infrastruktur in mehreren Regionen unterstützen.

Wenn Vorschriften gegensätzliche Konnektivitätsanforderungen enthalten, können Sie eine Konnektivitätsverwaltungsgruppe erstellen, die dem jeweiligen Satz von Vorschriften zugeordnet wird. Diese Struktur ähnelt der vorherigen Architektur, in der Identitäts- und Sicherheitsverwaltungsgruppen dem jeweiligen Satz von Vorschriften zuordnet werden.

Wenn Vorschriften hinsichtlich der Konnektivität und auch in Bezug auf Identität und Sicherheit zueinander in Konflikt stehen, können Sie das folgende Design verwenden.

Nächste Schritte

• Azure-Zielzonen und mehrere Microsoft Entra-Mandanten
• ISV-Überlegungen zu Azure-Zielzonen
• Microsoft Cloud Adoption Framework für Azure
• Microsoft Entra ID und Datenresidenz
• Übersicht über die Säule „Sicherheit“
• Empfehlungen für das Identity & Access Management
• Anpassen der Architektur der Azure-Zielzonen an die Anforderungen