Amazon Web Services ブログ

AWS Control Towerの新機能–データレジデンシー要件を満たすのに役立つリージョン拒否とガードレール

規制の厳しい業界や公共部門などの多くのお客様が、データの保存場所と処理場所を管理したいと考えています。AWS では、現地の法律や規制に準拠するためのツールや機能がすでに多数提供されていますが、データレジデンシー要件を、シングルアカウントおよびマルチアカウント環境に適用できるコントロールに簡単に変換する方法を提供したいと考えています。

2021 年 11 月 30 日（米国時間）より、AWS Control Tower を使用して、ガードレールというデータレジデンシーの予防および検出コントロールをデプロイできます。これらのガードレールは、AWS Control Tower によって構築および管理されるサービスコントロールポリシー (SCP) 経由で AWS API へのアクセスを制限することにより、不要な AWS リージョンにリソースをプロビジョニングすることを防ぎます。このように、インフラストラクチャレベルで、選択したリージョン以外にコンテンツを作成したり転送したりすることはできません。この場合、コンテンツは、処理または保存のために AWS でホストされるソフトウェア (マシンイメージを含む)、データ、テキスト、オーディオ、ビデオ、またはイメージになります。たとえば、ドイツの AWS のお客様は、AWS Identity and Access Management (IAM) や AWS Organizations などのグローバルサービスを除き、フランクフルト以外のリージョンの AWS サービスへのアクセスを拒否できます。

また、AWS Control Tower には、Amazon Simple Storage Service (Amazon S3) のクロスリージョンレプリケーションのブロック、インターネットゲートウェイ作成のブロックなど、基盤となる AWS サービスオプションでデータレジデンシーをさらに制御するためのガードレールも用意されています。

AWS Control Tower の管理に使用される AWS アカウントは、新しいリージョン拒否設定による制限を受けません。リージョン拒否を有効にする前に不要なリージョンにデータがある場合、そのアカウントを修正に使用できます。

検出ガードレールは AWS Config ルールによって実装され、許可してはならない予期しない設定変更をさらに検出できます。

アプリケーションレベルでのデータレジデンシーに対する責任共有モデルは引き続き保持されますが、これらのコントロールを利用してインフラストラクチャチームとアプリケーションチームが AWS で実行できる操作を制限できます。

AWS Control Tower でのデータレジデンシーガードレールの使用
新しいデータレジデンシーガードレールを使用するには、AWS Control Tower を使用してランディングゾーンを作成する必要があります。詳細については、AWS Control Tower landing zone を計画するを参照してください。

使用可能な新しいコントロールをすべて表示するには、AWS Control Tower コンソールの左側にあるペインで [Guardrails] (ガードレール) を選択し、[Data Residency] (データ所在地) カテゴリからコントロールを見つけます。結果を [Behavior] (動作) で並べ替えます。[Prevention] (防止) 動作があるガードレールは、SCP として実装されます。[Detection] (検出) 動作があるものは AWS Config ルールとして実装されます。

コンソールのスクリーンショット。

最も興味深いガードレールは、おそらく、リクエストされた AWS リージョンに基づいて AWS へのアクセスを拒否しているガードレールです。一覧から選択しましたが、他のガードレールとは異なることがわかりました。これは、すべての組織単位 (OU) に影響し、ここでは有効化できませんが、ランディングゾーン設定で有効化する必要があるためです。

コンソールのスクリーンショット。

[Overview] (概要) の下にある [Guardrail components] (ガードレールコンポーネント)には、このガードレールの全体 SCP へのリンクがあります。この設定を有効にすると、非統制リージョンに対して引き続き許可される AWS API のリストが表示されます。要件に応じて、Amazon CloudFront や AWS Global Accelerator などの一部のサービスは、カスタム SCP によってさらに制限される場合があります。

[Landing zone settings] (ランディングゾーン設定) では、リージョン拒否ガードレールは現在有効になっていません。[Modify settings] (設定変更) を選択し、[Region deny settings] (リージョン拒否設定) を有効にします。

コンソールのスクリーンショット。

[Region deny settings] (リージョン拒否設定) の下には、ランディングゾーンによって管理される AWS リージョン一覧があります。リージョン拒否を有効にすると、これらのリージョンが許可されます。

コンソールのスクリーンショット。

私の場合は 4 つの統治リージョンがあり、2 つは米国に、2 つは欧州に属します。

  • ランディングゾーンの本拠地でもある米国東部 (バージニア北部)
  • 米国西部 (オレゴン)
  • 欧州 (アイルランド)
  • 欧州 (フランクフルト)

一番下の [Update landing zone] (ランディングゾーンを更新) を選択します。ランディングゾーンの更新が完了するまでに数分かかります。現在、AWS API の大部分は、管理対象リージョンのいずれにも送信されないとブロックされます。いくつかテストしてみよう。

サンドボックスアカウントでのリージョン拒否テスト
AWS Single Sign-On の使用 I AWS 認証情報をコピーして、AWSAdministratorAccess 許可を持つサンドボックスアカウントを使用します。ターミナルで、これらの認証情報を使用するように環境変数を設定するコマンドを貼り付けます。

コンソールのスクリーンショット。

ここで、私は新しい Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを非統制リージョンの 1 つである米国東部 (オハイオ) で開始しようとしています。ランディングゾーンでは、デフォルト VPC は AWS Control Tower が管理する VPC に置き換えられます。インスタンスを起動するには、VPC サブネットを指定する必要があります。使用できるサブネット ID を探しましょう。

aws ec2 describe-subnets --query 'Subnets[0].SubnetId' --region us-east-2

DescribeSubnets オペレーションの呼び出し時にエラーが発生しました (UnauthorizedOperation)。
この操作を実行する権限がありません。

予想どおり、米国東部 (オハイオ) ではこの操作を行う権限がありません。サブネット ID を渡さずに EC2 インスタンスを起動してみましょう。

aws ec2 run-instances --image-id ami-0dd0ccab7e2801812 --region us-east-2 \
    --instance-type t3.small                                     

RunInstances オペレーションの呼び出し時にエラーが発生しました (UnauthorizedOperation)。
この操作を実行する権限がありません。
エンコードされた認証失敗メッセージ: <ENCODED MESSAGE>

繰り返しますが、私は許可されていません。エンコードされた認証失敗メッセージには、この記事で説明されているようにデコードできる詳細情報が多く含まれています。

aws sts decode-authorization-message --encoded-message <ENCODED MESSAGE>

デコードされたメッセージ (簡潔にするために省略しました) は、私の要求に対して明示的な拒否があったことを示しており、拒否の原因となった完全な SCP を含んでいます。この情報は、この種のエラーをデバッグする際に非常に役立ちます。

それでは、4 つの統治リージョンの 1 つである米国東部 (バージニア北部) で試してみましょう。

aws ec2 describe-subnets --query 'Subnets[0].SubnetId' --region us-east-1
"subnet-0f3580c0c5e56c210"

今度は、コマンドはリクエストから返された最初のサブネットのサブネット ID を返します。このサブネットを使用して、米国東部 (バージニア北部) でインスタンスを開始しましょう。

aws ec2 run-instances --image-id  ami-04ad2567c9e3d7893 --region us-east-1 \
    --instance-type t3.small --subnet-id subnet-0f3580c0c5e56c210

予想通り動作し、EC2 インスタンスがコンソールで実行されているのがわかります。

コンソールのスクリーンショット。

同様に、他の AWS サービスの API はリージョン拒否設定によって制限されます。たとえば、非統制リージョンに S3 バケットを作成することはできません。

コンソールのスクリーンショット。

バケットを作成しようとすると、アクセス拒否エラーが表示されます。

コンソールのスクリーンショット。

予想どおり、S3 バケットの作成は管理対象リージョンで機能します。

誰かがこのアカウントに非統制リージョンのバケットへのアクセスを許可したとしても、そのバケットにデータをコピーすることはできません。

その他の予防ガードレールでは、以下のようなデータレジデンシーを強制できます。

  • Amazon EC2、Amazon CloudFront、および AWS Global Accelerator のクロスリージョンネットワーキングを許可しない
  • 顧客が管理する Amazon VPC インスタンスへのインターネットアクセスを許可しない
  • Amazon バーチャルプライベートネットワーク (VPN) 接続を許可しない

それでは、検出ガードレールがどのように機能するか見てみましょう。

サンドボックスアカウントでの検出ガードレールのテスト
サンドボックス OU 内のすべてのアカウントに対して、以下のガードレールを有効にします。

  • Amazon EBS スナップショットがすべての AWS アカウントで復元可能かどうかを検出する
  • インターネットゲートウェイのルートテーブルに公開ルートが存在するかどうかを検出する

さて、これらのガードレールに逆らった場合に何が起こるかを見てみたいと思います。EC2 コンソールで、以前に開始した EC2 インスタンスのボリュームの EBS スナップショットを作成します。次に、すべての AWS アカウントと共有するようにアクセス許可を変更します。

コンソールのスクリーンショット。

次に、VPC コンソールでインターネットゲートウェイを作成し、AWS Control Tower のマネージド VPC に添付して、インターネットゲートウェイを使用するようにプライベートサブネットの 1 つのルートテーブルを更新します。

コンソールのスクリーンショット。

数分後、サンドボックスアカウント内の非準拠リソースが、検出ガードレールによって検出されます。

コンソールのスクリーンショット。

ガードレールから提供された情報を確認し、設定を更新して問題を修正します。マルチアカウント設定では、アカウント所有者に連絡して修正を依頼します。

利用可能なリージョンと料金
データレジデンシーガードレールを使用して、任意の AWS リージョンのリソースを制御できます。ランディングゾーンを作成するには、AWS Control Tower が提供されているリージョンの 1 つから開始する必要があります。詳細については、AWS リージョン別のサービス表を参照してください。この機能を使用するために追加費用はかかりません。AWS Config など、使用した他のサービスの費用はお客様に負担していただきます。

この機能により、データレジデンシー要件に対応するマルチアカウント環境を設定するためのコントロールとガイダンスのフレームワークが提供されます。ユースケースに応じて、新しいデータレジデンシーガードレールの任意のサブセットを使用できます。

AWS Control Tower では、データレジデンシー要件に基づいてガードレールを設定します。

– Danilo

原文はこちらです。