AWS Organizations の新しいタイプの認可ポリシーであるリソースコントロールポリシー (RCP) のご紹介

11 月 13 日は、リソースコントロールポリシー (RCP) をご紹介します。これは、AWS Organizations で管理される新しい認可ポリシーで、組織全体のリソースに対する使用可能な最大の許可を設定するために使用できます。これは、AWS 環境にデータ境界を確立し、リソースに対する外部アクセスを大規模に制限するのに役立つ予防的コントロールの一種です。Organizations 内で一元的に強制適用される RCP により、中心的なガバナンスチームとセキュリティチームは、AWS アカウント内のリソースに対するアクセスが、組織のアクセスコントロールガイドラインに準拠していることに自信をもつことができます。

RCP はすべての商用 AWS リージョンで利用可能で、リリース時には次のサービスがサポートされています: Amazon Simple Storage Service (Amazon S3)、AWS Security Token Service (AWS STS)、AWS Key Management Service (AWS KMS)、Amazon Simple Queue Service (Amazon SQS)、AWS Secrets Manager。

RCP を有効にして使用しても追加料金はかかりません。

サービスコントロールポリシー (SCP) との違い
本質的には似ている一方で、RCP はサービスコントロールポリシー (SCP) を補完しますが、独立して機能します。

サービスコントロールポリシー (SCP) を使用すると、AWS Identity and Access Management (IAM) ロールなどの組織内のプリンシパルに付与される許可を制限できます。これらの許可を Organizations 内で一元的に制限することで、AWS サービス、特定のリソース、さらにはプリンシパルが複数の AWS アカウントにまたがってリクエストを実行するために満たさなければならない条件に対するアクセスを制限できます。

一方、RCP を使用すると、組織内のリソースに付与される許可を制限できます。RCP は Organizations 内で一元的に実装するため、複数の AWS アカウントにまたがって、リソースに対する、一貫性のあるアクセスコントロールを強制適用できます。例えば、アカウント内の S3 バケットに対するアクセスを制限して、組織に属するプリンシパルのみがアクセスできるようにすることができます。RCP は、誰が API リクエストを実行しているのかにかかわらず、リソースがアクセスされたときに評価されます。

SCP と RCP のいずれも許可を付与するものではないことに留意してください。これらは、組織内のプリンシパルとリソースに使用可能な最大の許可を設定するだけです。許可を付与するには、適切な IAM ポリシー (ID ベースのポリシーやリソースベースのポリシーなど) を使用する必要があります。

SCP と RCP のクォータは、互いに完全に独立しています。各 RCP は最大 5,120 文字です。組織のルート、各 OU、およびアカウントに最大 5 個の RCP をアタッチでき、組織で最大 1,000 個の RCP を作成して保存できます。

開始方法
RCP の使用を開始するには、まず RCP を有効にする必要があります。これは、Organizations コンソール、AWS SDK、または AWS コマンドラインインターフェイス (AWS CLI) を使用して行うことができます。ポリシータイプを有効または無効にできるのは、Organizations 管理アカウントまたは委任された管理者のみであるため、必ずそれらを使用してください。

[すべての機能] オプションで Organizations を使用していることを確認してください。[一括請求 (コンソリデーティッドビリング) 機能] モードを使用している場合は、RCP を有効にする前に、すべての機能を使用するように移行する必要があります。

コンソールユーザーは、まず Organizations コンソールに移動します。[ポリシー] を選択すると、[リソースコントロールポリシー] を有効にするオプションが表示されます。

RCP を有効にすると、[リソースコントロールポリシー] ページで、RCPFullAWSAccess という新しいポリシーが使用可能になっていることがわかります。これは、自動的に作成され、ルート、各 OU、AWS アカウントなど、組織内のすべてのエンティティにアタッチされる AWS マネージドポリシーです。

このポリシーにより、すべてのプリンシパルが組織のリソースに対して任意のアクションを実行できるようになります。つまり、独自の RCP を作成してアタッチするまで、既存の IAM 許可はすべてこれまでどおりに動作します。

これは、次のようになります。

{
  "Version": "2012-10-17",
  "Statement": [
    { 
        "Effect": "Allow",
        "Principal": "*",
        "Action": "*",
        "Resource": "*" 
    }
  ]
}

RCP の作成

これで、最初の RCP を作成する準備が整いました。 例を見てみましょう。

デフォルトでは、AWS リソースは外部プリンシパルに対するアクセスを許可しません。リソース所有者は、ポリシーを設定することで、そのようなアクセスを明示的に付与する必要があります。デベロッパーはアプリケーションのニーズに応じてリソースベースのポリシーを柔軟に設定できますが、RCP を使用すると、中心的な IT チームは組織内のリソース全体で、有効な許可に対するコントロールを維持できます。これにより、デベロッパーが広範なアクセスを付与した場合でも、外部 ID によるアクセスは組織のセキュリティ要件に従って制限されます。

組織内のプリンシパルのみがアクセスできるように、S3 バケットに対するアクセスを制限する RCP を作成してみましょう。

[リソースコントロールポリシー] ページで、[ポリシーを作成] を選択すると、新しいポリシーを作成できるページが表示されます。

このポリシーを EnforceOrgIdentities と呼びます。このポリシーがどのような効果を有するのかを一目で理解しやすくし、適切にタグ付けできるよう、明確な説明を入力することをお勧めします。

次のセクションでは、ポリシーステートメントを編集できます。事前入力済みのポリシーテンプレートを独自のものに置き換えます。

完全な JSON ポリシードキュメントは次のとおりです。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EnforceOrgIdentities",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": "*",
            "Condition": {
                "StringNotEqualsIfExists": {
                    "aws:PrincipalOrgID": "[MY ORG ID]"
                },
                "BoolIfExists": {
                    "aws:PrincipalIsAWSService": "false"
                }
            }
        }
    ]
}

詳しく見てみましょう。

Version – これは IAM ポリシーの標準かつ必須の要素です。AWS は下位互換性を維持しているため、最新バージョン (現在は 2012-10-17) を使用しても既存のポリシーが壊れることはなく、新しい機能を使用できます。

Statement – 1 つ以上のステートメントオブジェクトを含めることができる配列。これらの各ステートメントオブジェクトは、単一の許可または許可セットを定義します。

Sid – これはオプションのフィールドで、ポリシー管理とトラブルシューティングに役立ちます。この JSON ポリシードキュメントの範囲内で一意である必要があります。

Effect – 前述のとおり、デフォルトでは、組織内のあらゆるエンティティにアタッチされているすべての AWS プリンシパル、アクション、およびリソースに対するアクセスを許可する RCP があります。そのため、制限を適用するには、Deny を使用する必要があります。

Principal – RCP では、このフィールドは常に "*" に設定する必要があります。このポリシーを特定のプリンシパルにのみ適用する場合は、Condition フィールドを使用します。

Action – このポリシーが適用される AWS サービスとアクションを指定します。この場合、アクセスコントロールガイドラインを満たしていない場合は、Amazon S3 とのすべてのインタラクションを拒否します。

Resource – RCP が適用されるリソースを指定します。

Condition – 各リクエストについてポリシーを適用すべきかどうかを決定するために評価される条件のコレクション。

RCP を適用するには、すべての条件が true と評価される必要があることを覚えておいてください。ここでは、2 つの条件を適用しています。

1.リクエストは外部プリンシパルによって実行されたか?

"StringNotEqualsIfExists": 
 { 
   "aws:PrincipalOrgID": "[MY ORG ID]" 
 }

この条件は、まず、キー aws:PrincipalOrgID がリクエスト内に存在するかどうかをチェックします。存在しない場合、この条件はそれ以上評価せずに true と評価します。

存在する場合、値を組織 ID と比較します。値が同じ場合は false と評価され、RCP は適用されません。なぜなら、すべての条件が true と評価される必要があるからです。組織内のプリンシパルに対するアクセスを拒否したくないため、これは意図された動作です。

ただし、値が組織 ID と一致しない場合は、リクエストが組織外のプリンシパルによって実行されたことを意味します。条件は true と評価されます。これは、2 つ目の条件も true と評価されれば、RCP が適用される可能性がまだあることを意味します。

2.リクエストは AWS サービスからのものか?

"BoolIfExists": 
   { 
     "aws:PrincipalIsAWSService": "false"
   }

この条件は、aws:PrincipalIsAWSService という特別なキーがリクエストに含まれているかどうかをテストします。このキーは、署名されたすべての API リクエストのリクエストコンテキストに自動的に挿入され、S3 バケットにイベントを書き込む AWS CloudTrail などの AWS サービスからのものである場合は true に設定されます。このキーが存在しない場合、この条件は true と評価されます。

存在する場合は、ステートメントで宣言した値と比較されます。ここでは、値が false と等しいかどうかをテストしています。等しい場合は、リクエストが AWS サービスによって実行されたものではなく、組織外の誰かによって実行された可能性があることを意味するため、true を返します。それ以外の場合は、false を返します。

つまり、リクエストが組織内のプリンシパルからのものではなく、AWS サービスからのものでもない場合、S3 バケットに対するアクセスは拒否されます。

このポリシーは単なるサンプルであり、独自のビジネス目標とセキュリティ目標に合わせてカスタマイズすべきです。例えば、このポリシーをカスタマイズして、ビジネスパートナーによるアクセスを許可したり、AWS サービスに対するアクセスを制限して、パートナーがお客様に代わってのみリソースにアクセスできるようにしたりすることができます。詳細については、「Establishing a data perimeter on AWS: Allow only trusted identities to access company data」をご覧ください。

RCP のアタッチ
RCP をアタッチするプロセスは SCP に似ています。前述のように、組織のルート、OU、または組織内の特定の AWS アカウントに RCP をアタッチできます。

RCP をアタッチした後、影響を受ける AWS リソースに対するアクセスリクエストは RCP 制限に準拠する必要があります。大規模に強制適用する前に、アカウント内のリソースに対する RCP の影響を徹底的にテストすることをお勧めします。個々のテストアカウントまたはテスト OU に RCP をアタッチすることから始めることができます。

実際の動作
これで RCP を作成してアタッチしたので、実際に機能している様子を確認する準備ができました。 デベロッパーがリソースベースのポリシーを組織内の S3 バケットにアタッチし、外部アカウントの ID に対してアクセスを明示的に付与したと仮定します。

RCP は、ユーザーが RCP で許可されているよりも許容度が高いリソースベースのポリシーを保存することを妨げません。ただし、前述のとおり、RCP は認可プロセスの一環として評価されるため、外部 ID によるリクエストはいずれにしても拒否されます。

この外部アカウントを使用してバケットにアクセスを試みることで、これを証明できます。今回は AWS CLI から実行します。

$ aws s3api get-object —bucket 123124ffeiufskdjfgbwer \
  --key sensitivefile.txt \
  --region us-east-1 local_file

An error occurred (AccessDenied) when calling the GetObject operation: Access Denied

環境内での RCP のデプロイのスケール
これまで、コンソールを使用して RCP を管理する方法について見てきました。ただし、大規模なコントロール管理の場合は、それらを Infrastructure as Code として設定することを検討し、既存の継続的インテグレーションおよび継続的デリバリー (CI/CD) パイプラインとプロセスに統合されることを確認すべきです。

AWS Control Tower を使用する場合は、SCP ベースのコントロールに加えて RCP ベースのコントロールをデプロイできます。例えば、AWS Control Tower を使用して、前述の例で作成したものと同様の RCP をデプロイし、外部プリンシパルが組織内の S3 バケットにアクセスできないようにすることができます。これにより、マネージドアカウントのリソースに RCP が一貫して適用され、アクセスコントロールガバナンスが大規模に合理化および一元化されます。

さらに、SCP と同様に、AWS Control Tower は RCP のためにドリフト検出もサポートしています。AWS Control Tower の外部で RCP が変更または削除された場合、ドリフトについて通知され、是正のステップが提供されます。

まとめ
リソースコントロールポリシー (RCP) は、組織内の AWS リソースに使用可能な最大の許可に対する一元管理を提供します。SCP とともに、RCP は AWS 環境全体でデータ境界を一元的に確立し、意図しないアクセスを大規模に防ぐのに役立ちます。SCP と RCP は独立したコントロールであり、異なる一連のセキュリティ目標を達成することを可能にします。SCP または RCP のみを有効にするか、または両方のポリシータイプを併用して、多層防御セキュリティモデルの一部として包括的なセキュリティベースラインを確立するかを選択できます。

詳細については、「AWS Organizations ユーザーガイド」の「Resource control policies (RCPs)」をご覧ください。

Matheus Guimaraes | @codingmatheus

原文はこちらです。