Freigeben über

Ändern einer Azure-Zielzonenarchitektur, um Anforderungen an mehrere Standorte zu erfüllen

Organisationen in vielen Branchen unterliegen gesetzlichen Anforderungen, einschließlich Datenhaltungs-, Datensicherheits- und Datenhoheitsanforderungen. Einige Organisationen müssen widersprüchliche Vorschriften an mehreren geografischen Standorten einhalten. In diesem Fall müssen sie ihre Azure-Zielzonenarchitektur gemäß allen geltenden Vorschriften ändern.

Beispielsweise kann es zwei widersprüchliche Vorschriften, Verordnung A und Verordnung B geben. Verordnung A kann eine Datenaufbewahrung in Land oder Region A erfordern, und Verordnung B kann datenaufbewahrung in Land oder Region B erfordern.

Solche regulatorischen Konflikte können gelten 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 Softwareanbieter (ISVs), die Lösungen für Organisationen an mehreren Standorten bereitstellen, und die Lösung muss die lokalen Vorschriften an jedem Standort einhalten.

  • ISVs, die Lösungen für multinationale Organisationen bereitstellen, die die lokalen Vorschriften der einzelnen 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 Azure-Zielzonenarchitektur", um die Anforderungen zu erfüllen.

Überlegungen zu gesetzlichen Vorschriften

Regulatorische Anforderungen beziehen sich in der Regel auf Datenschutz, Datenspeicherung, Datenübertragungen, Isolation oder Personalabfertigung. Diese Anforderungen können zwischen mehreren geografischen Standorten in Konflikt geraten. Eine Verordnung der Europäischen Union (EU) kann z. B. eine Datenaufbewahrung in einem EU-Land erfordern, während eine Verordnung des Vereinigten Königreichs eine Datenaufbewahrung im Vereinigten Königreich erfordern kann.

Wenn Vorschriften zu widersprüchlichen Richtlinienkontrollen führen, müssen Sie die Architektur der Azure-Zielzone und die Richtlinienzuweisungen entsprechend anpassen. Weitere Informationen finden Sie im Abschnitt in diesem Artikel, Szenarien, die Änderungen erfordern.

Wenn mehrere Vorschriften gelten, müssen Sie die Azure-Zielzonenarchitektur nicht ändern, wenn:

  • Mehrere Vorschriften erfordern identische Azure-Richtlinienzuweisungen.

  • Die Kontrollen in einer Verordnung sind eine Obermenge einer anderen Verordnung. Die übergreifenden Steuerelemente gelten automatisch für beide Vorschriften.

  • Die Steuerelemente in mehreren Vorschriften überschneiden sich nicht. Wenn Sie mehrere Kontrollsets implementieren, deckt eine einzige Implementierung alle Vorschriften ab. Azure-Richtlinienzuweisungen ergänzen sich.

  • Verschiedene Vorschriften haben unterschiedliche Arten von Implementierungen. Aus regulatorischer Sicht spielt es keine Rolle, welche Implementierung Sie auswählen. Beispielsweise gibt es zwei Vorschriften, die jeweils ein anderes Autorisierungsmodell haben, aber beide Autorisierungsmodelle sind akzeptabel. Sie können die Implementierung auswählen, die am besten zu Ihrer Organisation passt.

Tipp

Sie sollten darauf achten, möglichst wenige Richtlinienzuweisungen sowie Ausnahmen oder Befreiungen zu haben.

Ü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.

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

  • SaaS mit dualer Bereitstellung: Dieses Modell kombiniert das vom Kunden bereitgestellte Modell und das reine SaaS-Modell.

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

In einem vom Kunden bereitgestellten Modell ist der Kunde für die Verwaltung der Compliance verantwortlich. Für dieses Modell muss der ISV die Landungszonen nicht ändern. Die Lösung wird jedoch in einer Landing Zone bereitgestellt, die vom Kunden eingerichtet wird, einschließlich sämtlicher Richtliniensteuerungen und benutzerdefinierter Richtlinien.

Tipp

ISVs können Richtlinieninitiativen auf bestimmte Complianceanforderungen abzielen, um eine Lösung zu testen. Diese Vorgehensweise kann dazu beitragen, die Wahrscheinlichkeit von Konflikten mit Richtlinien zu minimieren, die Kunden verwenden, um ihre Complianceanforderungen zu erfüllen.

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

Überlegungen für multinationale Organisationen

Multinationale Organisationen verwenden verschiedene Strukturen, um ihre IT-Governance zu organisieren.

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

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

  • Hybridstruktur: Globale IT-Funktionen werden zentral bereitgestellt, während IT-Funktionen, die nur lokal erforderlich sind, an jedem geografischen Standort geregelt werden.

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

In einem zentralen Szenario ist das zentrale IT-Team für die Verwaltung der Compliance verantwortlich und muss sicherstellen, dass 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 in Konflikt stehen, und es kann erforderlich sein, Landezonen zu ändern.

In einem Hybridszenario gelten die Überlegungen für die dezentralen und zentralisierten Szenarien. Die zentrale Organisation bietet Lösungen, die die lokalen Organisationen in ihrer Umgebung bereitstellen müssen. Die zentrale Organisation testet außerdem, dass diese Lösungen in allen Landezonen der lokalen Organisationen bereitgestellt werden.

Szenarien, die Änderungen erfordern

Möglicherweise müssen Sie Landezonen ändern, wenn konfliktende Richtliniensätze vorhanden sind, die verschiedenen Bereitstellungen zugewiesen sind. Möglicherweise gibt es mehrere Lösungen oder eine einzelne Lösung, die verschiedenen geografischen Standorten oder Datenklassifizierungen zur Verfügung gestellt werden muss.

Die erforderliche Änderung hängt von der Isolationsstufe ab, die von der Verordnung gefordert wird. Je mehr Bedingungen eine Verordnung hat, desto mehr muss die Landungszone geändert werden. Wenn z. B. Vorschriften Bedingungen wie gelöschtes Personal, verschiedene Identitätsanbieter oder Verzeichnisse, separate Verwaltungsinfrastruktur oder separate Konnektivitätsinfrastruktur erfordern, erfordert die Landezone umfangreiche Änderungen. Wenn vorschriften nur erfordern, dass die Anwendungs- und Konnektivitätsinfrastruktur isoliert ist, benötigt die Zielzone minimale Änderungen.

Microsoft Entra-Mandanten

Wir empfehlen die Verwendung eines einzelnen Microsoft Entra-Mandanten für die meisten Szenarien, einschließlich multinationaler Szenarien. Es gibt jedoch Szenarien, in denen Sie mehrere Microsoft Entra-Mandanten bevorzugen oder erfordern, z. B.:

Wenn Sie in mehreren Microsoft Entra-Mandanten zusammenarbeiten, müssen Sie wichtige Herausforderungen und Anforderungen sorgfältig planen. Erstellen Sie nur die Mindestanzahl von Microsoft Entra-Mandanten, die Sie zur Erfüllung betrieblicher oder behördlicher Anforderungen benötigen. Sie können Verwaltungsgruppen und rollenbasierte Zugriffssteuerung (Azure Role-Based Access Control, RBAC) verwenden, um den Zugriff auf Abonnements und Ressourcen unter einem einzelnen Mandanten zu steuern, wie im nächsten Abschnitt beschrieben.

Tipp

Der Microsoft Entra-Mandant, den Sie für Ihre Zielzone auswählen, wirkt sich nicht auf Ihre Authentifizierung auf Anwendungsebene aus. Sie können weiterhin andere Identitätsanbieter verwenden, unabhängig davon, welchen Mandanten Sie auswählen. Für Kunden des öffentlichen Sektors und Kunden in regulierten Branchen werden Endbenutzeridentitäten in der Regel bereitgestellt, wenn Sie in einen genehmigten Identitätsanbieter integriert werden, z. B. einen öffentlichen oder zertifizierten Identitätsanbieter.

Die folgenden Diagramme zeigen Optionen, mit denen Sie Microsoft Entra-Mandanten organisieren können.

Ein Diagramm, das drei Möglichkeiten zum Organisieren von Microsoft Entra-Mandanten zeigt.

Tipp

Wenn Sie über mehrere Microsoft Entra-Mandanten verfügen, um behördliche Anforderungen zu erfüllen, benennen Sie die Mandanten basierend auf dem geografischen Standort anstelle bestimmter Vorschriften, z. B. contoso-ops-us.com im Beispieldiagramm.

Weitere Informationen finden Sie unter Azure-Landezonen und mehrere Microsoft Entra-Mandanten und ISV-Überlegungen für Azure-Landezonen.

Verwaltungsgruppen

Wenn Sie keine separaten Microsoft Entra-Mandanten benötigen, um eine strenge Isolierung bereitzustellen, sollten Sie mehrere Azure-Zielzonen in einem einzigen Microsoft Entra-Mandanten bereitstellen. Sie können die Verwaltungsgruppenhierarchie anpassen, um die Anforderungen von widersprüchlichen Vorschriften zu erfüllen.

Sie können eine vollständige Zielzonenarchitektur für jede Reihe von Vorschriften bereitstellen, die Sie trennen möchten. Dieses Modell erfordert die geringste Anpassung und ermöglicht es Ihnen, die vorhandene Automatisierung für die Bereitstellung zu nutzen.

Ein Diagramm, das separate Landezonen für jede Verordnung zeigt.

Hinweis

Dieses Diagramm zeigt nicht alle Verwaltungsgruppen an.

Plattformverwaltungsgruppe teilen

Wenn die Verordnung es zulässt, kann die Plattformverwaltungsgruppe geteilt werden. Sie können separate Verwaltungsgruppen unter der Zielzonenverwaltungsgruppe für jede Gruppe von Vorschriften erstellen, die getrennt werden müssen. Sie können den einzelnen Anwendungsverwaltungsgruppen die entsprechenden Richtlinien zuweisen. Die Anwendungs-Stützpunkte nutzen dieselben Verwaltungsgruppen, die unter der Plattformverwaltungsgruppe stehen. Die Ressourcen in den Anwendungsverwaltungsgruppen können auch durch Abonnement oder Ressourcengruppe getrennt werden.

Diese Verwaltungsgruppenhierarchie ist ein einfaches und kostengünstiges Design zum Isolieren von Anwendungen mit widersprüchlichen Vorschriften. In diesem Design müssen jedoch die Plattformverwaltungsgruppen für Konnektivität, Identität/Sicherheit und Verwaltung denselben Richtliniensatz aufweisen. Möglicherweise benötigen Sie für jede Plattformverwaltungsgruppe unterschiedliche Richtliniensätze, wenn die Verordnung Einschränkungen für die Freigabe von Konnektivitätsinfrastruktur, Identitätsdiensten, Schlüsselverwaltungsdiensten oder die Infrastruktur festlegt, von der die gesamte Umgebung verwaltet wird.

Ein Diagramm, das eine Architektur zeigt, die die Plattformverwaltungsgruppe teilt.

Identität und Sicherheit isolieren

Wenn Vorschriften die Freigabe der Identitäts- und Schlüsselverwaltungsinfrastruktur verhindern, können Sie die Plattformverwaltungsgruppe unterteilen. Behalten Sie die Verwaltungsgruppen für Konnektivität und Verwaltung in der Gruppe für die gemeinsame Plattformverwaltung bei und verfügen über eine Identitäts- und Sicherheitsverwaltungsgruppe, die den einzelnen Vorschriften 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 Regelsätze und die freigegebene Umgebung bereitstellen und die überflüssigen Verwaltungsgruppen ignorieren oder löschen.

Ein Diagramm, das eine Architektur zeigt, die Identität und Sicherheit isoliert.

Isolieren der Konnektivität

Viele Vorschriften haben Anforderungen im Zusammenhang mit der Verarbeitung und Speicherung von Daten an einem bestimmten geografischen Standort, mit wenigen Anforderungen hinsichtlich der Verbindung von Benutzern mit Anwendungen. Für diese Regelungen können Sie die Konnektivitätsverwaltung freigeben, wie in der vorhergehenden Architektur dargestellt. Möglicherweise gibt es keine Vorschriften, die erfordern, dass Sie die Infrastruktur in mehreren Regionen duplizieren, aber Sie müssen möglicherweise zu Latenzzwecken. Die zugewiesenen Richtlinien müssen die Duplizierung der Infrastruktur in mehreren Regionen unterstützen.

Wenn Vorschriften widersprüchliche Konnektivitätsanforderungen aufweisen, können Sie eine Konnektivitätsverwaltungsgruppe erstellen, die den einzelnen Vorschriften zugeordnet ist. Diese Struktur ähnelt der vorherigen Architektur, die Identitäts- und Sicherheitsverwaltungsgruppen jeder Reihe von Vorschriften zuordnet.

Wenn Vorschriften mit Konnektivität und Identität und Sicherheit in Konflikt geraten, können Sie den folgenden Entwurf verwenden.

Ein Diagramm, das eine Architektur zeigt, die konnektivitätsisoliert.

Nächste Schritte