翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
グローバル拡張の戦略
アンケート
ご意見をお待ちしています。簡単なアンケート
AWS セキュリティ保証サービスは
以下の質問は一般的であり、ユースケースに応じて回答できるのはお客様だけです。
-
顧客の個人データはどこに保存する必要がありますか？
-
顧客データはどこに保存されますか？
-
個人データが国境を越える方法と場所
-
人的またはサービスによるリージョン間のデータへのアクセスは、転送を構成しますか？
-
顧客の個人データに外国政府がアクセスしていないことを確認するにはどうすればよいですか？
-
バックアップ、ホットサイト、コールドサイトはどこに保存できますか？
-
データをローカルに維持するために、サービスを提供するすべてのリージョンで AWS ランディングゾーンを維持する必要がありますか？ または、既存の AWS Control Tower ランディングゾーンを使用できますか？
データレジデンシー要件では、アーキテクチャのデプロイが異なると、組織によってうまく機能する可能性があります。一部の組織では、顧客の個人データを特定のリージョン内に保持するという要件がある場合があります。その場合は、これらの義務を維持しながら、規制に一般的に準拠する方法に関心があるかもしれません。状況に関係なく、マルチアカウントデプロイ戦略を選択する際には複数の考慮事項があります。
主要なアーキテクチャ設計コンポーネントを定義するには、コンプライアンスチームと契約チームと緊密に連携し、個人データが をどこで、いつ、どのように通過できるかの要件を確認します AWS リージョン。移動、コピー、表示など、データ転送の対象となるものを決定します。さらに、実装する必要がある特定の耐障害性とデータ保護コントロールがあるかどうかを理解します。バックアップおよびディザスタリカバリ戦略には、クロスリージョンフェイルオーバーが必要ですか？ その場合は、バックアップデータの保存に使用できるリージョンを決定します。特定の暗号化アルゴリズムやキー生成専用のハードウェアセキュリティモジュールなど、データ暗号化の要件があるかどうかを確認します。これらのトピックについてコンプライアンス関係者と調整したら、マルチアカウント環境の設計アプローチを検討し始めます。
マルチアカウント戦略を計画 AWS するために使用できる 3 つのアプローチを、インフラストラクチャの分離の昇順で次に示します。
また、プライバシーコンプライアンスはデータ主権だけで停止するわけではないことを覚えておくことも重要です。このガイドの残りの部分を確認して、同意管理、データ対象者のリクエスト、データガバナンス、AI バイアスなど、他の多くの課題に対して考えられる解決策を理解してください。
マネージドリージョンを持つ中央ランディングゾーン
グローバルに拡張したいが、既にマルチアカウントアーキテクチャを確立している場合は AWS、同じマルチアカウントランディングゾーン (MALZ) を使用して追加を管理することが一般的です AWS リージョン。この設定では、作成したリージョンで、既存の AWS Control Tower ランディングゾーンからのログ記録、Account Factory、一般管理などのインフラストラクチャサービスを引き続き運用します。
本番ワークロードでは、 AWS Control Tower ランディングゾーンを新しいリージョンに拡張することで、リージョンデプロイを運用できます。これにより、ガバナンスを AWS Control Tower 新しいリージョンに拡張できます。これにより、特定のマネージドリージョン内に個人データストアを保持できます。データは、インフラストラクチャサービスと AWS Control Tower ガバナンスの恩恵を受けるアカウントにまだ存在します。では AWS Organizations、個人データを含むアカウントは、引き続き専用の個人データ OU にロールアップされ、 のすべてのデータ主権ガードレール AWS Control Tower が実装されます。さらに、リージョン固有のワークロードは、複数のリージョンに同じワークロードを含む本番稼働用アカウントを確立するのではなく、専用アカウントに含まれています。
このデプロイは最も費用対効果が高い場合がありますが、 AWS アカウント およびリージョンの境界を越えて個人データの流れを制御するには、追加の考慮事項が必要です。以下の点を考慮してください。
-
ログには個人データが含まれている可能性があるため、集約中のクロスリージョン転送を防ぐために、機密性の高いフィールドを格納または編集するために追加の設定が必要になる場合があります。リージョン間のログ集約を制御するための詳細と推奨されるプラクティスについては、このガイド一元化されたログストレージの「」を参照してください。
-
VPCs の分離と、 AWS Transit Gateway 設計における適切な双方向ネットワークトラフィックフローを考慮します。どの Transit Gateway アタッチメントを許可および承認するかを制限したり、VPC ルートテーブルを変更できるユーザーや内容を制限したりできます。
-
クラウド運用チームのメンバーが個人データにアクセスできないようにする必要がある場合があります。例えば、顧客のトランザクションデータを含むアプリケーションログは、他のログソースよりも機密性が高いと見なされる場合があります。ロールベースのアクセスコントロールや属性ベースのアクセスコントロールなど、追加の承認と技術的なガードレールが必要になる場合があります。また、アクセスに関しては、データにレジデンシーの制限が適用される場合があります。たとえば、1 つのリージョン A のデータは、そのリージョン内からのみアクセスできます。
次の図は、リージョンデプロイによる一元化されたランディングゾーンを示しています。
リージョンランディングゾーン
複数の MALZ を使用することで、非重要ワークロードと比較して個人データを処理するワークロードを完全に分離することで、より厳格なコンプライアンス要件を満たすことができます。 AWS Control Tower 一元化されたログ集約はデフォルトで設定できるため、簡素化されます。この方法では、秘匿化が必要なログの個別のストリームによるログ記録の例外を維持する必要はありません。MALZ ごとにローカルおよび専用のクラウド運用チームを配置し、オペレーターのローカルレジデンシーへのアクセスを制限することもできます。
多くの組織では、米国ベースと欧州ベースのランディングゾーンを別々にデプロイしています。各リージョンランディングゾーンには、リージョン内のアカウントに対して単一の包括的なセキュリティ体制と関連するガバナンスがあります。例えば、専用 HSMs を使用した個人データの暗号化は、1 つの MALZ のワークロードでは必要ではない場合がありますが、別の MALZ では必要になる場合があります。
この戦略は、現在および将来の多くの要件を満たすようにスケールできますが、複数の MALZs の維持に関連する追加コストと運用オーバーヘッドを理解することが重要です。詳細については、AWS Control Tower 料金表
次の図は、2 つのリージョンに別々のランディングゾーンを示しています。
AWS 欧州主権雲
一部の組織では、欧州経済地域 (EEA) で運用されているワークロードと、他の場所で運用されているワークロードを完全に分離する必要があります。この状況では、AWS 欧州主権
European AWS Sovereign Cloud は、物理的および論理的に既存の から分離されていますが AWS リージョン、すべて同じセキュリティ、可用性、パフォーマンスを提供します。EU に拠点を置く AWS 従業員のみが AWS 、欧州主権クラウドの運用とサポートを管理できます。厳格なデータレジデンシー要件がある場合、 AWS European Sovereign Cloud は、作成したすべてのメタデータ (実行に使用するロール、アクセス許可、リソースラベル、設定など AWS) を EU に保持します。 AWS European Sovereign Cloud には、独自の請求および使用状況計測システムも用意されています。
このアプローチでは、前のセクションのリージョンランディングゾーンと同様のパターンを使用します。ただし、欧州の顧客に提供するサービスについては、 AWS 欧州の主権クラウドに専用の MALZ をデプロイできます。
