📑
AWS Organizations の新機能 Resource Control Policies の使いどころ

2025/01/28に公開
 はじめに2024年11月、AWS Organizations で使用できる新しい統制機能である Resource Control Policies(RCP) がリリースされました。

近年は多くの組織が複数のAWSアカウントを利用するマルチアカウント方式を採用しており、このRCPはマルチアカウント環境における統制とイノベーションのバランスを保つのに役立ちます。

この記事では従来からあるSCPとの差異に触れ、規模の大きい組織でこの新機能をどのように導入していけばよいか考察しています。
https://aws.amazon.com/jp/blogs/aws/introducing-resource-control-policies-rcps-a-new-authorization-policy/

 SCP との違いSCPは多くの組織ですでに導入されていると思います。SCPは Organizations の機能の1つで、組織内の複数のAWSアカウントに対してIAMで実行できるポリシーを制限することができます。例えば以下の画像のように Production OU に拒否のステートメントを持つSCPをアタッチすると配下のアカウントAとBの両方が特定のサービスへのアクセスを拒否されるようになります。

SCPがサービスに対する拒否を設定できるものであったのに対して、RCPは組織内のリソースに付与される権限を制限できます。例えば、以下のように Organizations 外のAWSプリンシパルから組織内のアカウントのS3にアクセスすることを禁止できます。



気になるのはSCPが絡んだ時の評価の順序だと思いますが、以下の評価論理フローに従って権限が決まります。


 RCP実装のアプローチここからは実際に組織にRCPを適用するうえでどのように取り組んでいけばよいかを考えていきます。特に Organizations に適用するということもあり、影響範囲が大きいので慎重になってしまいがちだと思いますが、適切に利用すれば効果的な統制を利かせることができます。

 AWSサンプルの利用最初の一歩はAWSサンプルを眺めるところから始め、適用できるものがあれば取り入れていくのがよいと思います。
https://github.com/aws-samples/resource-control-policy-examples
サンプルによると、RCPは主に以下のようなコントロールを実現するのに適しているようです。
データ境界ガードレール: 信頼できる ID のみが想定されるネットワークから信頼できるリソースにアクセスできるようにする予防的制御を実施
組織内境界を確立する: 組織内の異なる組織単位間の境界とアクセス制御を定義するコントロール
リソースアクセスパターンを制限する: 組織のリソースにアクセスするために使用される方法に特定のルールを適用し、準拠したアクセスパターンのみが許可されるようにするコントロール
信頼できるOIDC IDプロバイダーへのアクセスを制限する: 組織のリソースへのアクセスを許可するために外部OIDC IDプロバイダー(IdP)が使用する承認メカニズムを管理するコントロール
サービス固有のコントロール: セキュリティとコンプライアンスに対する標準化されたアプローチを確保するために、個々のAWSサービス全体に実装されるベースラインセキュリティ要件またはガイドラインを定義するコントロール
イメージが湧きやすいようにサンプルをいくつかご紹介します。

 権限ガードレールの設計適切なRCPを設計することでセキュリティ目標を効率的に達成できます。例えば、組織外のIDによるIAMロールへのアクセスを制限するRCPは次のようになります。
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RestrictAccessToMyOrg",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "sts:AssumeRole",
      "Resource": "*",
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:PrincipalOrgID": "<my-org-id>"
        },
        "BoolIfExists": {
          "aws:PrincipalIsAWSService": "false"
        }
      }
    }
  ]
}
このポリシーは、プリンシパルが組織に属していない場合、またはAWSサービスプリンシパルでない場合にIAMロールの引き受けを拒否します。

 例外の計画特定のケースでは、組織外のIDによるリソースへのアクセスを許可する必要があるかもしれません。例えば
公開データを含むリソース
信頼できるパートナーとの統合
このような例外を管理するためには、次のような手法が考えられます
特定のアカウントや組織単位（OU）に別のポリシーを適用する
条件キー（例：aws:ResourceAccount）を使用して特定のアカウントを除外する
リソースタグを利用して例外を管理する
例えば、タグベースの例外を実装するRCPは次のようになります。
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RestrictAccessToMyOrgExceptTaggedRoles",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "sts:AssumeRole",
            "Resource": "*",
            "Condition": {
                "StringNotEqualsIfExists": {
                    "aws:PrincipalOrgID": "<my-org-id>",
                    "aws:ResourceTag/partner-access-exception": "trusted-partner"
                },
                "BoolIfExists": {
                    "aws:PrincipalIsAWSService": "false"
                }
            }
        },
        {
            "Sid": "RestrictAccessForTaggedRoles",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "sts:AssumeRole",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/partner-access-exception": "trusted-partner"
                },
                "StringNotEqualsIfExists": {
                    "aws:PrincipalAccount": "<trusted-partner-account-id>"
                }
            }
        }
    ]
}
タグベースの例外を使用する場合は、タグ自体の管理に対する厳格な制御も必要です。不正なタグ操作を防止するためのSCPを実装することを検討しましょう。

 影響の予測RCPの展開は、SCPと同じように行う必要があります。RCPには、SCPと同様に、ポリシーが適用される前に影響を確認できる「ドライラン」のようなモードがないため、既存のアクセスを確認する必要があります。たとえば、S3バケットへのパブリックアクセスを禁止する予定の場合は、パブリックにする必要があるS3バケットがないことを確認する必要があります。
影響を評価するためのツールとして以下が有効です。

IAM Access Analyzer: 外部エンティティと共有されているリソースを特定するのに利用できます
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/what-is-access-analyzer.html
ちなみにRCPは現時点でS3,STS,SQS,SecretsManager,KMSをサポートしているのですが、これらは全て IAM AccessAnalyzer でカバーされています。

また、IAM AccessAnalyzerではどの外部プリンシパルにリソースへのアクセスが許可されているかは分かるのですが、アクセス方法は分かりません。こうした場合には CloudTrail を利用してさらなる調査を行う必要があります。

 権限ガードレールの実装AccessAnalyzerを利用して事前の分析ができるとはいえ、RCPは影響範囲が大きいため以下のように実装していくとよいと思います。

 段階的な導入例ですが、以下のような段階的な手順を踏んで適用するのがよいと思います。
開発環境でRCPをテストし、影響を評価する
既存の制御からの移行期間中は、リソースベースのポリシーと並行してRCPを運用する
最も重要なリソースやアカウントから始めて、徐々に展開範囲を拡大する
二重管理が気になるのであれば、リソースベースのポリシーからリソースコントロールポリシーと重複する部分を削除する(ただし、多層防御の観点からはRCPとリソースベースポリシーの重ね掛けが推奨であることを強調しておきます)

 まとめリソース制御ポリシー（RCP）は、マルチアカウントAWS環境で大規模にリソースアクセスを管理するための強力なツールだと言えます。RCPを適切に実装すれば開発速度を損なわずに統制を利かせることが可能なので、ぜひ積極的に利用してください。
はじめに

SCP との違い

RCP実装のアプローチ

AWSサンプルの利用

権限ガードレールの設計

例外の計画

影響の予測

権限ガードレールの実装

段階的な導入

まとめ

Discussion
