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