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