Strategien für die globale Expansion entwickeln - AWS Präskriptive Leitlinien

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Strategien für die globale Expansion entwickeln

Umfrage

Wir würden uns freuen, von Ihnen zu hören. Bitte geben Sie Feedback zur AWS PRA, indem Sie an einer kurzen Umfrage teilnehmen.

AWS Security Assurance Services erhält AWS bei globalen Expansionen häufig Fragen zur Architektur für den Datenschutz. Die Fragen drehen sich um die Einhaltung besonderer Datenschutzanforderungen wie Datenhoheitspflichten oder Kundenverträge bei gleichzeitiger Vermeidung zusätzlicher Kosten und betrieblicher Mehrkosten. Zu den Entwurfsüberlegungen gehören häufig der Speicherort der Daten, die Beschränkung des Benutzerzugriffs, die Ausfallsicherheit und Überlebensfähigkeit sowie die allgemeine Unabhängigkeit. Weitere Informationen finden Sie unter Erfüllung der Anforderungen an digitale Souveränität auf AWS (Präsentation AWS re:Invent 2022).

Die folgenden Fragen kommen häufig vor und nur Sie können sie für Ihren Anwendungsfall beantworten:

  • Wo müssen die personenbezogenen Daten meiner Kunden gespeichert werden?

  • Wo werden meine Kundendaten gespeichert?

  • Wie und wo können personenbezogene Daten Grenzen überschreiten?

  • Stellt der Zugriff von Menschen oder Dienstleistungen auf Daten zwischen Regionen eine Übertragung dar?

  • Wie kann ich sicherstellen, dass keine ausländischen Regierungen auf die personenbezogenen Daten meiner Kunden zugreifen?

  • Wo kann ich meine Backups und meine heißen oder kalten Websites speichern?

  • Sollte ich in jeder Region, in der ich Dienste erbringe, eine AWS landing zone einrichten, um Daten lokal zu halten? Oder kann ich eine bestehende AWS Control Tower landing zone nutzen?

Was die Anforderungen an die Datenresidenz angeht, eignen sich unterschiedliche Architekturbereitstellungen möglicherweise besser für verschiedene Organisationen. Einige Organisationen verlangen möglicherweise, dass die personenbezogenen Daten ihrer Kunden in einer bestimmten Region bleiben. In diesem Fall sind Sie möglicherweise besorgt darüber, wie Sie die Vorschriften generell einhalten und gleichzeitig diese Verpflichtungen einhalten können. Unabhängig von der Situation gibt es bei der Wahl einer Implementierungsstrategie für mehrere Konten mehrere Überlegungen.

Um die wichtigsten Komponenten des Architekturentwurfs zu definieren, arbeiten Sie eng mit Ihren Compliance- und Vertragsteams zusammen, um die Anforderungen zu klären, wo, wann und wie personenbezogene Daten übertragen werden können. AWS-Regionen Stellen Sie fest, was als Datenübertragung gilt, z. B. Verschieben, Kopieren oder Ansehen. Machen Sie sich außerdem darüber im Klaren, ob bestimmte Maßnahmen zur Ausfallsicherheit und zum Datenschutz implementiert werden müssen. Erfordern Backup- und Disaster Recovery-Strategien ein regionsübergreifendes Failover? Falls ja, bestimmen Sie, in welchen Regionen Sie Ihre Backup-Daten speichern können. Ermitteln Sie, ob Anforderungen für die Datenverschlüsselung bestehen, z. B. ein bestimmter Verschlüsselungsalgorithmus oder spezielle Hardware-Sicherheitsmodule für die Schlüsselgenerierung. Nachdem Sie sich mit den für die Einhaltung der Vorschriften zuständigen Personen zu diesen Themen abgesprochen haben, beginnen Sie, über Entwurfsansätze für Ihre Umgebung mit mehreren Konten nachzudenken.

Im Folgenden finden Sie drei Ansätze, mit denen Sie Ihre Strategie für AWS mehrere Konten planen können, und zwar in aufsteigender Reihenfolge der Trennung der Infrastruktur:

Es ist auch wichtig, sich daran zu erinnern, dass die Einhaltung des Datenschutzes möglicherweise nicht nur bei der Datensouveränität endet. Lesen Sie den Rest dieses Leitfadens, um mögliche Lösungen für viele andere Herausforderungen zu verstehen, wie z. B. das Einwilligungsmanagement, Anfragen von Datensubjekten, Datenverwaltung und KI-Voreingenommenheit.

Zentrale landing zone mit verwalteten Regionen

Wenn Sie global expandieren möchten, aber bereits eine Multi-Account-Architektur eingerichtet haben AWS, möchten Sie häufig dieselbe Multi-Account-Landing landing zone (MALZ) verwenden, um weitere zu verwalten. AWS-Regionen In dieser Konfiguration würden Sie weiterhin Infrastrukturdienste wie Logging, Account Factory und allgemeine Verwaltung von Ihrer bestehenden AWS Control Tower landing zone aus in der Region betreiben, in der Sie sie erstellt haben.

Für Produktionsworkloads können Sie regionale Bereitstellungen durchführen, indem Sie die AWS Control Tower landing zone auf eine neue Region ausdehnen. Auf diese Weise können Sie die AWS Control Tower Verwaltung auf die neue Region ausdehnen. Auf diese Weise können Sie persönliche Datenspeicher in einer bestimmten, verwalteten Region speichern. Die Daten befinden sich weiterhin auf Konten, die von den Infrastrukturdiensten und der AWS Control Tower Verwaltung profitieren. In: Konten AWS Organizations, die personenbezogene Daten enthalten, werden immer noch unter einer speziellen Organisationseinheit für personenbezogene Daten zusammengefasst, in AWS Control Tower der alle Schutzmaßnahmen für die Datenhoheit implementiert sind. Darüber hinaus werden regionsspezifische Workloads in speziellen Konten gespeichert, anstatt Produktionskonten einzurichten, die denselben Workload in mehreren Regionen beinhalten können.

Diese Bereitstellung kann am kostengünstigsten sein, es sind jedoch zusätzliche Überlegungen erforderlich, um den Fluss personenbezogener Daten über regionale Grenzen hinweg AWS-Konto zu kontrollieren. Berücksichtigen Sie dabei Folgendes:

  • Protokolle können personenbezogene Daten enthalten, sodass möglicherweise eine zusätzliche Konfiguration erforderlich ist, um sensible Felder zu enthalten oder zu unkennzeichnen, um eine regionsübergreifende Übertragung während der Aggregation zu verhindern. Weitere Informationen und empfohlene Vorgehensweisen zur Steuerung der Protokollaggregation zwischen Regionen finden Sie Zentralisierter Protokollspeicher in diesem Handbuch.

  • Berücksichtigen Sie beim Entwurf die Isolierung VPCs und den entsprechenden bidirektionalen Netzwerkdatenverkehr. AWS Transit Gateway Sie können einschränken, welche Transit Gateway Gateway-Anlagen zulässig und genehmigt sind, und Sie können einschränken, wer oder was die VPC-Routentabellen ändern kann.

  • Möglicherweise müssen Sie verhindern, dass Mitglieder Ihres Cloud-Betriebsteams auf personenbezogene Daten zugreifen. Anwendungsprotokolle, die Kundentransaktionsdaten enthalten, können beispielsweise als sensibler eingestuft werden als andere Protokollquellen. Möglicherweise sind zusätzliche Genehmigungen und technische Schutzmaßnahmen erforderlich, z. B. eine rollenbasierte Zugriffskontrolle und eine attributbasierte Zugriffskontrolle. Außerdem können Daten in Bezug auf den Zugriff auf Daten Aufenthaltsbeschränkungen unterliegen. Beispielsweise kann auf Daten in einer Region A nur von dieser Region aus zugegriffen werden.

Das folgende Diagramm zeigt eine zentrale landing zone mit regionalen Bereitstellungen.

Zentralisierte landing zone mit regionalen Einsätzen.

Regionale Landezonen

Wenn Sie mehr als ein MALZ haben, können Sie strengere Compliance-Anforderungen erfüllen, da Workloads, die personenbezogene Daten verarbeiten, vollständig von immateriellen Workloads isoliert werden. AWS Control Tower Die zentrale Protokollierungsaggregation könnte standardmäßig konfiguriert und somit vereinfacht werden. Bei diesem Ansatz müssen Sie keine Ausnahmen für die Protokollierung mit separaten Protokollströmen einrichten, die geschwärzt werden müssen. Sie könnten sogar ein lokales und dediziertes Cloud-Betriebsteam für jedes MALZ einrichten, wodurch der Betreiberzugriff auf die lokale Niederlassung beschränkt wird.

Viele Organisationen verfügen über separate landing zone in den USA und der EU. Jede regionale landing zone hat eine einzige, pauschale Sicherheitslage und die damit verbundene Verwaltung der Konten in der Region. Beispielsweise ist die Verschlüsselung personenbezogener Daten mithilfe von dedizierten Daten für Workloads in einer MALZ HSMs möglicherweise nicht erforderlich, in einer anderen MALZ jedoch möglicherweise.

Diese Strategie kann zwar skaliert werden, um viele aktuelle und future Anforderungen zu erfüllen, es ist jedoch wichtig, die zusätzlichen Kosten und den Betriebskosten zu verstehen, die mit der Wartung mehrerer erforderlich sind MALZs. Weitere Informationen finden Sie unter AWS Control Tower Preise.

Das folgende Diagramm zeigt separate Landezonen in zwei Regionen.

Separate Landezonen in zwei Regionen.

AWS Europäische Souveräne Cloud

Einige Unternehmen benötigen eine gründliche Trennung ihrer Workloads, die im Europäischen Wirtschaftsraum (EWR) betrieben werden, und Workloads, die in anderen Ländern betrieben werden. In dieser Situation sollten Sie die AWS European Sovereign Cloud in Betracht ziehen. Die AWS European Sovereign Cloud ist eine neue, unabhängige Cloud für Europa, die Kunden dabei unterstützen soll, den sich wandelnden Souveränitätsanforderungen der Region gerecht zu werden, einschließlich strenger Anforderungen an Datenresidenz, Betriebsautonomie und Ausfallsicherheit.

Die AWS European Sovereign Cloud ist physisch und logisch von der bestehenden AWS-Regionen Cloud getrennt und bietet gleichzeitig die gleiche Sicherheit, Verfügbarkeit und Leistung. Nur AWS Mitarbeiter, die in der EU ansässig sind, haben die Kontrolle über den Betrieb und den Support der AWS European Sovereign Cloud. Wenn Sie strenge Anforderungen an die Datenresidenz haben, speichert die AWS European Sovereign Cloud alle Metadaten, die Sie erstellen (z. B. die Rollen, Berechtigungen, Ressourcenbezeichnungen und Konfigurationen, die sie für die Ausführung verwenden AWS) in der EU. Die AWS European Sovereign Cloud verfügt auch über eigene Abrechnungs- und Nutzungszählungssysteme.

Für diesen Ansatz würden Sie ein ähnliches Muster wie im vorherigen Abschnitt, Regionale Landezonen, verwenden. Für Dienste, die Sie europäischen Kunden anbieten, könnten Sie jedoch ein spezielles MALZ in der AWS European Sovereign Cloud bereitstellen.