[アップデート]Organizationsでの新たなる統制、Resource Control Policies (RCPs)がリリースされました！

はじめに

先日、AWS Organizationsで使用できる新しい統制機能であるResource Control Policies(RCPs)がリリースされました。本稿ではこれがどんな機能なのか、従来あったSCPとはどう違うのかをご紹介します。

公式ブログ
https://aws.amazon.com/jp/blogs/aws/introducing-resource-control-policies-rcps-a-new-authorization-policy/

SCPとの違い

SCPはOrganizationsの機能の1つで組織内の複数のAWSアカウントに対して、IAMポリシーアクションの使用を制限するためのポリシーです。組織的に推奨しないAWSサービスの禁止や特定ロールのみAWSサービスへの操作を許可することなどが可能です。

では、今回のRCPは何を禁止するのでしょうか。SCP(ServiceControlPolicy)が文字通りServiceに対して操作禁止を設定できるのに対して、RCP(ResourceControlPolicy)はResourceに対して操作禁止を設定できます。例えば公式ブログにもあるように、Organizations外のAWSプリンシパルから組織内のアカウントのS3にアクセスすることを禁止出来ます。

ざっと見たところ、組織外からのリソースへのアクセスを制限するために使うことが多くなりそうです。
IAMポリシーの評価論理の図も最新(2024年11月15日時点)のドキュメントでは変更されており、Denyの次でSCPよりも前に評価されるようです。リソースベースポリシーよりも先に評価されるので、バケットポリシーでアクセス許可していてもOrganizations側でアクセスを禁止することができます。

https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic_policy-eval-denyallow.html

対応しているサービス

現在は、S3、STS、KMS、SQS、Secrets Managerが対象です。

やってみる

今回はSTSの方で以下の図のように、信頼ポリシーは組織内外のアカウントに許可した状態で、組織内からはAssumeRole出来て、組織外からはAssumeRole出来ないことを確認してみます。

管理アカウントでOrganizationsの画面からポリシーを開くとリソースコントロールポリシーが追加されています。

リソースコントロールポリシーを押下すると、有効化用のボタンが表示されるので押下します。これでRCPを有効化出来ます。

少し待つとデフォルトのポリシーとポリシー操作画面が以下のように表示されます。STSの動作確認をするため、今回はポリシーを作成します。

restricting-stsという名前で以下の条件のポリシーを作ります。Organizations外のプリンシパルであり、かつAWSサービスからのリクエストでない場合に適用されます。

{
	"Version": "2012-10-17",
	"Statement": [
		{
            "Sid": "RestrictingSts",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "sts:*",
            "Resource": "*",
            "Condition": {
                "StringNotEqualsIfExists": {
                    "aws:PrincipalOrgID": "o-xxxxxxxxxx"
                },
                "BoolIfExists": {
                    "aws:PrincipalIsAWSService": "false"
                }
            }
        }
	]
}

ポリシーが以下のように作成されます。次にアタッチしてみます。

ポリシーはOUにも、アカウントにも直接アタッチできます。今回は下のCTから始まるアカウントにアタッチしてみます。

CTから始まるアカウントで以下のような信頼ポリシーのついたロールを作成します。4から始まる方が組織内のアカウントで、7から始まる方が組織外のアカウントです。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::4xxxxxxxxxxx:root",
                    "arn:aws:iam::7xxxxxxxxxxx:root"
                ]
            },
            "Action": "sts:AssumeRole",
            "Condition": {}
        }
    ]
}

それぞれのアカウントからAssumeRoleしてみます。まずは4から始まる組織内のアカウントからGUIでAssumeRoleします。以下のように必要項目を入力してAssumeRoleします。

想定通りAssumeRoleできます。

次に、組織外のアカウントで同じようにAssumeRoleしようとすると、以下のようにエラーになりました。

上記から組織内のプリンシパルからはAssumeRoleでき、組織外のプリンシパルに対しては、リソースベースポリシーで許可していてもRCPでAssumeRoleを禁止することができました。

所感

組織外のアカウントからのアクセスを網羅的に禁止することはSCPだけでは難しかったので、厳しい制約を設けたい環境ではかなり重要な機能になるのかと感じます。ただSCPのように強制的に操作を禁止するものなので、組織で利用するかは十分な検証の上で、既存のシステムへの影響が出ないことを確認したうえで適用することをおすすめします。

機能的には面白そうだったので検証してみました。今回は組織外からのアクセスの制限についてのみ取り上げましたが、他にも使い方には可能性がありそうです。他の方もこんな使い方ができるのでは？という気付きがあれば是非ブログやXなどで書いてみてください！