みなさん、こんにちは。 AWS CLI が好きなテクニカルサポート課の市野です。
先日のブログでこの 11月 に追加された Declarative policies（宣言型ポリシー）について整理してみた投稿をしました。
今日はその時に、サラッと流していた RCPs（Resource control policies）について整理してみたブログです。
また、本記事はサーバーワークス Advent Calendar 2024 の シリーズ１、14日目の記事として執筆しています。
時節柄、AWS re:Invent 2024 で現地体験してきた内容の投稿なども多く、弊社の他のメンバーのアウトプットも是非ご覧いただけると幸いです。
クリックで目次が表示されます。
公式発表
位置付け
AWS Organzations におけるポリシータイプには、大きく「Authorization policies（承認ポリシー）」と「Management policies（管理ポリシー）」の二つのカテゴリが存在しますが、AWS 公式ドキュメントによりますと RCPs（Resource control policies）はそのうちの「Authorization policies（承認ポリシー）」に属するとなっています。
なお、上記二つのポリシーカテゴリについてや継承の考え方について「AWS Organizations の各ポリシーと継承について整理する (2024年10月版)」の記事で弊社の佐竹が整理していますので、ぜひご一読ください。
SCPs と RCPs の違い
SCPs（Service control policies） も RCPs（Resource control policies） もどちらも前述した Authorization policies（承認ポリシー）に分類されるポリシーとなります。
そのため、Authorization policies（承認ポリシー）が持つ共通点もあるものの、適用対象とするオブジェクトが異なる違いもあります。
Authorization policies（承認ポリシー）としての共通点
- 管理アカウントには影響を及ぼさない
- 組織のRoot や OU、アカウントへアタッチできるポリシー数は 5
- ポリシードキュメントの最大サイズは 5,120 文字
適用対象とするオブジェクトから見た違い
- SCPs（Service control policies） ：プリンシパルを対象とした制御を行う
- RCPs（Resource control policies）：リソースを対象とした制御を行う
AWS におけるプリンシパルとは IAM ユーザーや IAM ロール、フェデレーションユーザあるいはアプリケーションを指しますので、すなわち「誰が」「何が」などの操作主体＝主語にあたるオブジェクトを対象に制御を行うことができるのが SCPs、「何に」にあたる操作の影響を受ける AWS リソースを対象に制御を行うことができるのが RCPs となります
その他、細かな違い
ワイルドカードの取り扱い
RCPs では、SCPs で利用ができなかった Action 要素へのワイルドカードを利用できるようになっています。
そのため s3:List* といった書き方を採ることができます。
Note Wildcards (*) and question marks (?) can be used anywhere in the action name
Unlike with SCPs, you can use wildcard characters such as asterisk (*) or question mark (?) anywhere in the action name.
サポートされない要素
SCPs では Principal、NotPrincipal、NotResource がサポートされていない要素だったのに対し、RCPs では NotPrincipal、NotAction がサポートされない要素となっています。
RCPs が適用対象とできる AWS リソース
AWS ドキュメント List of AWS services that support RCPs に、RCPs をサポートする AWS サービスの一覧がまとめられています。
今後、サービスの拡充により RCPs をサポートするサービスは増えていくことが予想されますので、適宜、最新情報をご確認いただきたいですが、本エントリ執筆時点でサポートされている AWS サービスは以下のとおりです。
また、上記のうちでも影響を受けない以下のリソースがあります。
- サービスリンクロール
- AWS KMS（Key Management Service）における AWS 管理キー
- AWS KMS（Key Management Service）における
kms:RetireGrantAPI
RCPs の登場によって変更となった評価ロジック
RCPs の登場に伴い、AWS の利用において allow または、deny と判定される評価ロジックにも変更がありました。
詳細は、後述のリンクよりご確認いただきたいですが、ページより引用した以下画像にあるとおり RCPs は SCPs よりも前、ポリシーの中で最初に評価されるポリシータイプとなります。
出典：Amazon Web Services, Inc.. "How AWS enforcement code logic evaluates requests to allow or deny access". AWS Identity and Access Management. https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic_policy-eval-denyallow.html .（引用2024-12-14）
何がうれしいか
例えば S3 バケットへのアクセスについてを考えた場合、従来の SCPs を用いても、RCPs を用いても似たような結果とすることは可能かと考えられます。
ただ、前述の評価ロジックでも見たように、RCPs の方が評価順位が高いため、以下のような記載をすることで、メンバーアカウントの S3 バケットに対し一元的な制限を行うことができ、より予防的統制が行いやすくなることが考えられます。
- 誰（＝指定されたプリンシパル）からのアクセス以外は、アクセスを拒否する。と SCPs で制御する
- 自組織の AWS Organizations ID 以外からの全ての S3 バケットへの操作を拒否する。と RCPs でも制御する
これにより、いわゆる「混乱する代理問題」に対し、外部 ID の条件指定のし忘れがあっても前段で防ぐことに寄与する、などの使い方も考えられます。
まとめ
AWS re:Invent 2024 の前にしれっと発表されていた新機能で、新機能をいち早く利用すること自体が目的ではないので、現状の SCPs や S3 バケットポリシーから置き換えてくださいという話ではないですが、設計によってはより厳密な制御を行うこともできるようになり、ポリシー戦略に大きな選択肢が追加されたのではないかと思われます。
対象とできるリソースや、評価ロジックの適用順も踏まえ、自組織での予防的統制にどのように活用できそうか、ご検討いただけると良いかと思います。
本エントリがどなたかのお役に立てば幸いです。
ではまた。
市野 和明 (記事一覧)
マネージドサービス部・テクニカルサポート課
お客様から寄せられたご質問や技術検証を通じて得られた気づきを投稿していきます。
情シスだった前職までの経験で、UI がコロコロ変わる AWS においては GUI で手順を残していると画面構成が変わってしまって後々まごつくことが多かった経験から、極力変わりにくい AWS CLI での記事が多めです。
X（Twitter）：@kazzpapa3（AWS Community Builder）
