AWS Control Towerのコントロールからリージョン拒否設定を設定してみよう

はじめに

こんにちは。CTCの朴木です。

AWS Control Towerのリージョン拒否設定についていつしか執筆したことがあります。
懐かしいですね、以前の記事はこちらから。

あの頃のControl Towerではリージョン拒否設定をランディングゾーンの設定からでしか設定ができませんでした。
いまではコントロール（ガードレール）の数も大きく増え、リージョン拒否設定をOUに対して設定できるようになりました。

さらに単純なリージョン拒否だけではなく、サービスやIAMプリンシパルへのアクセス拒否の除外設定を追加することが可能になっています。

本記事ではそのコントロール（CT.MULTISERVICE.PV.1）について記載していきます！

リージョン拒否設定とは

リージョン拒否設定は指定のリージョン以外（または指定のリージョンのみ）へのアクセスを拒否する設定となりSCPにて実装できます。

例えば東京リージョンのみ利用するお客様は、この拒否設定によって東京リージョン以外へのアクセスを一律で制限でき、他のリージョンへのリソースのデプロイを防ぐことができます。

この機能を用いることでお客様のコンプライアンスに沿ったリージョンへのアクセス制限が実施できるようになります。

コントロール：CT.MULTISERVICE.PV.1について

まずコントロール：CT.MULTISERVICE.PV.1のSCPの内容について確認してみましょう。

用意されているのは下記のポリシーです。このコントロールを設定するにあたり3点押さえていただきたいポイントがあります。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "CTMULTISERVICEPV1",
            "Effect": "Deny",
            "NotAction": [
                {{ExemptedActions}}
                "a4b:*",
                "access-analyzer:*",
                "account:*",
                "acm:*",
                "activate:*",
                "artifact:*",
                "aws-marketplace-management:*",
                "aws-marketplace:*",
                "aws-portal:*",
                "billing:*",
                "billingconductor:*",
                "budgets:*",
                "ce:*",
                "chatbot:*",
                "chime:*",
                "cloudfront:*",
                "cloudtrail:LookupEvents",
                "compute-optimizer:*",
                "config:*",
                "consoleapp:*",
                "consolidatedbilling:*",
                "cur:*",
                "datapipeline:GetAccountLimits",
                "devicefarm:*",
                "directconnect:*",
                "ec2:DescribeRegions",
                "ec2:DescribeTransitGateways",
                "ec2:DescribeVpnGateways",
                "ecr-public:*",
                "fms:*",
                "freetier:*",
                "globalaccelerator:*",
                "health:*",
                "iam:*",
                "importexport:*",
                "invoicing:*",
                "iq:*",
                "kms:*",
                "license-manager:ListReceivedLicenses",
                "lightsail:Get*",
                "mobileanalytics:*",
                "networkmanager:*",
                "notifications-contacts:*",
                "notifications:*",
                "organizations:*",
                "payments:*",
                "pricing:*",
                "quicksight:DescribeAccountSubscription",
                "resource-explorer-2:*",
                "route53-recovery-cluster:*",
                "route53-recovery-control-config:*",
                "route53-recovery-readiness:*",
                "route53:*",
                "route53domains:*",
                "s3:CreateMultiRegionAccessPoint",
                "s3:DeleteMultiRegionAccessPoint",
                "s3:DescribeMultiRegionAccessPointOperation",
                "s3:GetAccountPublicAccessBlock",
                "s3:GetBucketLocation",
                "s3:GetBucketPolicyStatus",
                "s3:GetBucketPublicAccessBlock",
                "s3:GetMultiRegionAccessPoint",
                "s3:GetMultiRegionAccessPointPolicy",
                "s3:GetMultiRegionAccessPointPolicyStatus",
                "s3:GetStorageLensConfiguration",
                "s3:GetStorageLensDashboard",
                "s3:ListAllMyBuckets",
                "s3:ListMultiRegionAccessPoints",
                "s3:ListStorageLensConfigurations",
                "s3:PutAccountPublicAccessBlock",
                "s3:PutMultiRegionAccessPointPolicy",
                "savingsplans:*",
                "shield:*",
                "sso:*",
                "sts:*",
                "support:*",
                "supportapp:*",
                "supportplans:*",
                "sustainability:*",
                "tag:GetResources",
                "tax:*",
                "trustedadvisor:*",
                "vendor-insights:ListEntitledSecurityProfiles",
                "waf-regional:*",
                "waf:*",
                "wafv2:*" 
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": {{AllowedRegions}}
                },
                "ArnNotLike": {
                    "aws:PrincipalARN": [
                        {{ExemptedPrincipalArns}}
                        "arn:*:iam::*:role/AWSControlTowerExecution",
                        "arn:*:iam::*:role/aws-controltower-ConfigRecorderRole",
                        "arn:*:iam::*:role/aws-controltower-ForwardSnsNotificationRole",
                        "arn:*:iam::*:role/AWSControlTower_VPCFlowLogsRole"
                    ]
                }
            }
        }
    ]
}

上記ポリシーを見てみると、ユーザが任意で設定できる項目があることがわかります。設定できる内容に関するポイントを確認してみましょう。

"NotAction": [
	{{ExemptedActions}}

“NotAction”に任意のサービスアクションを追加できます。

ここにサービスのアクションを追加することで、そのアクションはアクセス拒否の項目から除外されるため、指定したサービスのアクションを実施できるようになります。
例えばec2:*を追加すれば、ec2のすべてのアクションが可能になるということです。

"Condition": {
	"StringNotEquals": {
		"aws:RequestedRegion": {{AllowedRegions}}
	},

"Condition" 句で“StringNotEquals”の中に任意のリージョンを追加できます。

ここにリージョンを追加することで、そのリージョンはアクセス拒否の項目から除外されるため、そのリージョン内でのアクションが実施できるようになります。
AWS Control Towerのホームリージョンは必ず除外されるため、ホームリージョン以外でアクセスを有効にしたいリージョンがあれば追加します。

"ArnNotLike": {
	"aws:PrincipalARN": [
		{{ExemptedPrincipalArns}}

"Condition" 句で"ArnNotLike"の中に任意のIAMプリンシパルを追加できます。

ここにサービスのIAMプリンシパルを追加することで、そのIAMプリンシパルはアクセス拒否の項目から除外されるため、リージョン拒否を設定したリージョン内でもアクションを実施できるようになります。
アクションを実施したい特定のIAMユーザやロールがある場合は設定します。

以上を踏まえ、整理するべき内容が3つあります。

リージョン拒否設定ではアカウントの運用に必要なサービス以外、指定したリージョン以外はアクセスが拒否されるものになります。
その中で、操作が必要なサービスがあるか、アクセスが必要なリージョンはあるか、アクションを実施させたいユーザやロールがあるか、を明確にしましょう。

リージョン拒否設定の実施

それでは実際に設定していきましょう。今回の記事ではコントロール設定から実施します。

AWS Control Towerのサービスページより、左ペインにある「Control Catalog」を選択します。コントロール画面より、「CT.MULTISERVICE.PV.1」と入力し、対象のコントロールを検索します。
チェックボックスにチェックを入れ、「コントロールを有効にする」ボタンをクリックします。

リージョン拒否を設定したいOUにチェックを入れ、「次へ」をクリックします。

アクセスを許可するリージョンにチェックを入れ、「次へ」をクリックします。ホームリージョン以外に許可したいリージョンがなければチェックを入れなくても問題ありません。
ここでは例としてオハイオリージョンを選択してみました。ホームリージョンは東京リージョンになります。

許可したいアクションがある場合はNotActionsにサービスアクションを記載して「追加」ボタンをクリックし、「次へ」で先に進みます。
許可したいアクションがない場合は空欄で問題ありません。ここでは例としてec2:*を入れてみました。
これによってEC2のすべてのアクションが拒否の対象から外れます。

アクションを実施したい（リージョン拒否設定から除外したい）特定のIAMプリンシパルを入力します。
アクセス拒否を除外したいIAMプリンシパルがなければ空欄で問題ありません。
ここでは例として、test-admin-roleというロールを指定してみました。

設定内容を確認して「コントロールを有効にする」をクリックし、コントロールをOUに適用します。
正常に有効になったことを確認できれば完了です！

今回適用したOU配下のメンバーアカウントにアクセスしてみましょう。
除外設定をしなかったユーザでバージニアリージョンのRDSにアクセスしてみました。
今回アクセスを許可しているのは東京リージョンとオハイオリージョンのみのため、想定どおりアクセスが拒否されました。

そのほかキャプチャは割愛しますが、アクセス拒否を除外したいIAMプリンシパルとして指定した「test-admin-role」では問題なくRDSへのアクセスができました。
また、オハイオリージョン、東京リージョンではどのサービスにもアクセスが可能となりました。

おわりに

いかがでしたでしょうか。

ランディングゾーンから実施するリージョン拒否設定より短時間で設定完了できましたね。AWS Control Towerのコントロールから設定するリージョン拒否設定は、あるリージョン以外へのアクセス制限を一律で実施したいというお客様に向いている機能となりますが、このコントロールから設定することで特定のOUに対しても設定することが可能になりました。

ランディングゾーンから設定するものよりも、より細やかな制御をすることができるようになり、使いやすくなった印象です。複数のアカウント環境において、役割に応じた一律のIAMロールを作成していれば、管理者ロールや運用ロールからのアクセスのみを許可するような制限をかけることが可能になります。

アカウント管理の中でユーザやロール役割や要件を明確に設計している場合には取り入れやすい機能となるのでマルチアカウントの中でガバナンスをより強く効かせたい要望がありましたらご検討いただければと思います。