はじめに
こんにちは、大林です。2024年11月と12月に、RCP（リソースコントロールポリシー）および宣言型ポリシーが発表されました。
AWS Organizations におけるポリシーの発展が進む中で、「SCP（サービスコントロールポリシー）とどう違うのか」、「それぞれのポリシーをどのように使い分けるべきか」と疑問に思う方も多いのではないでしょうか。
そこで今回のブログでは、SCP・RCP・宣言型ポリシーの違いを整理し、それぞれの特徴についてわかりやすく解説していきたいと思います。
承認ポリシーと管理ポリシー
それぞれのポリシーについて、説明する前に全体の大枠について説明していきます。
AWSにおけるポリシーは、大きく「承認ポリシー」と「管理ポリシー」の2つに分類されます。承認ポリシーは、特定のアクションやリソースへのアクセス権を制御するもので、SCPやRCPがこれに該当します。SCPはIAM プリンシパルに対して制限をかけるのに対し、RCPはAWSリソースに対して制限をかけるという特徴があります。一方、管理ポリシーは、AWSサービスの設定を統一的に適用するために使用され、宣言型ポリシーが含まれます。これらのポリシーは、それぞれ異なる役割で連携して、AWS環境全体のセキュリティ向上や運用の効率化を図っています。
下記では、これらのポリシーの特徴と使い分けについて説明していきます。
SCP（サービスコントロールポリシー）
SCPは、AWS Organizations を利用する際に、管理アカウントや組織単位（以下 OU）内のアカウントに対して適用できる制御ポリシーです。SCPは、アカウントで実行できる操作を管理するルールセットで、IAMポリシーに加えて、より広い範囲のアクセスを制御する役割を担っています。SCPは、IAM ポリシーのように直接リソースにアクセス許可を与えるのではなく、「どの操作を許可または拒否できるか」を制御できます。
上記は、管理者用のIAMロールの設定変更を禁止するSCPを図示しています。
IAMロールの設定変更以外にもAWS Config (以下 Config)を対象としたSCPの活用方法も紹介します。
Configはコンプライアンス違反のAWSリソースを検知できるため、AWSアカウント内のリソースをセキュアに保つことに有効なサービスです。そのため、一般ユーザーでConfigを無効化できてしまうと、アカウント管理者がAWSリソースのコンプライアンス違反に気づくことができず、脆弱な設定のAWSリソースが放置されてしまいます。そこで、SCPを活用して、一般ユーザーにConfigが無効化されないように制限をかけます。
下記は、「example-admin-role」というIAMロール以外のIAMロールでは、Configの無効化ができないポリシーの例です。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"config:DeleteConfigurationRecorder",
"config:DeleteDeliveryChannel",
"config:DeleteRetentionConfiguration",
"config:PutConfigurationRecorder",
"config:PutDeliveryChannel",
"config:PutRetentionConfiguration",
"config:StopConfigurationRecorder"
],
"Resource": [
"*"
],
"Condition": {
"ArnNotLike": {
"aws:PrincipalARN": "arn:aws:iam::*:role/example-admin-role"
}
}
}
]
}
※ Configの大量課金リスクと対策について以下のブログでまとめているので、よろしければ参考にしてみてください。
RCP（リソースコントロールポリシー）
RCPは、AWSにおいてリソースそのものにアクセス制御を直接適用するためのポリシーを指します。これはIAMユーザーやロールをベースにした制御ではなく、リソース単位でポリシーを設定する仕組みで、S3バケットやSNSトピック、SQSキューなどの主要なAWSリソースで使用される「リソースポリシー」という形態がその具体例です。RCPの大きな特徴は、リソースごとにアクセスの制御を細かく設定できる点にあります。
RCPはSCPよりも先に評価される仕様になっています。
RCPの活用例として、組織外から組織内のIAMロールに対するアクセスを制限する方法があります。この例では、組織外のIAMロールが組織内のIAMロールにスイッチする際、STS（セキュリティトークンサービス）を使用するリクエストが失敗するように制御します。図に示されているように、外部のIAMロールが組織内のIAMロールにアクセスしようと試みても、このRCPによりアクセスが遮断されます。
組織外から組織内のIAMロールにSTSを実行することを禁止するRCPの例は下記です。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RestrictSTSAccessToOrganization",
"Effect": "Deny",
"Principal": "*",
"Action": "sts:*",
"Resource": "*",
"Condition": {
"StringNotEqualsIfExists": {
"aws:SourceOrgID": "org-id"
}
}
}
]
}
この機能は、外部からの不正アクセスや意図しない操作を防ぐための重要な対策となります。しかし、適用にあたっては注意が必要です。例えば、監視サービスのように、特定のケースで組織外のIAMロールに意図的に公開されたIAMロールがある場合には、このポリシーの適用によりサービスの正常な動作が妨げられる可能性があります。意図的な公開が必要な状況では、RCPの設定が意図しないサービス停止や障害を引き起こすリスクがあります。
そのため、RCPを適用する際には、組織単位やアカウント単位での運用要件を慎重に検討する必要があります。特に、不用意に広範囲にわたって適用すると、想定外の重大なインシデントにつながる恐れがあるため、事前の設計や影響範囲の確認を徹底することが重要です。
RCPがサポートしているAWSサービスは下記です。
Amazon S3
AWS Security Token Service
AWS Key Management Service
Amazon SQS
AWS Secrets Manager
宣言型ポリシー
宣言型ポリシーは、AWS Organizationsを活用して、組織全体で統一されたセキュリティや構成ポリシーを適用するための新しいポリシー形式です。これにより、組織内のすべてのアカウントに対して一貫性のあるベースライン構成を設定することが可能となります。このポリシーは、従来のIAMポリシーやSCPと補完的に機能し、AWS サービスの設定を定義、強制適用できる点が特徴です。
例えば、EBSスナップショットをパブリックに公開することを禁止するポリシーを宣言型ポリシーとして定義し、組織全体に適用することで、すべてのアカウントでEBSスナップショットが意図せず公開されるリスクを回避できます。このように、宣言型ポリシーは特定のリソースや操作に対して統一的なルールを適用するために非常に有効です。
EBSスナップショットをパブリックに公開することを禁止する宣言型ポリシーは下記です。
"snapshot_block_public_access": {
"state": {
"@@assign": "block_all_sharing"
}
}
宣言型ポリシーがSCPやRCPと異なる点は、下記の2点です。
サービスリンクロールを利用すること
エラーメッセージをカスタマイズできること
宣言型ポリシーがサポートしている機能は下記です。
ポリシーの適用を自動化する
上記の図では、AWS Organizationsで作成したポリシーをOUに適用する作業を自動化する例を示しています。
ケース1は、アカウント管理者が適用するポリシーと適用先のOUを手動で指定する場合のシナリオです。このケースでは、管理者がSlackなどのチャットツールを利用して操作可能なチャットボットを通じてポリシー名と適用するOUを指定し、その内容がAmazon API Gatewayを経由してLambda関数に渡されます。Lambda関数は指定されたポリシーをOUに適用します。このアプローチは、自動化を実現しつつ、特定のOUにポリシーを適用したい場合や、適用内容を細かく制御したい場合に適しています。一方で、複数のOUに異なるポリシーを適用する場合は管理が煩雑になりがちです。そのため、社内Wikiなどで設定値を整理し、一元管理を行うことを推奨します。
ケース2は、新しいOUが作成されたことを自動的に検知して処理を実行するシナリオです。この場合、Amazon EventBridgeがトリガーとして機能し、OU作成のイベントを受けてLambda関数を起動します。Lambda関数は、事前に定義されたポリシーを新規OUに適用します。このケースは、全てのOUに同一のポリシーを適用するシンプルな運用や統制を効かせた環境を目指す場合に特に有効です。
それぞれのケースは運用方針や適用要件によって適したシナリオが異なりますが、これらを必要に応じて活用することで、ポリシー適用作業の効率化を図ることが可能です。
おわりに
今回のブログでは、SCP・RCP・宣言型ポリシーについて解説しました。これらのポリシーはいずれも、外部からの攻撃に対する防御策となる一方で、適切な設計と運用が欠かせません。「ポリシーを適用すればそれで良い」というわけではなく、ケースバイケースでどのポリシーをどのように適用すべきかを十分に検討することが重要です。その結果として、「SCPは適用するが、RCPは適用しない」といった選択が正しい場合もあると思います。
本ブログが、AWS環境のセキュリティ強化に向けた検討の参考となれば幸いです。
