宣言ポリシーは何が違うのか？

はじめに

こんにちは akiraです。今年は雪が少ないと思っていたら遅れを取り戻すかのような降雪に驚いています。

AWS Organizationsを利用されている方であればご存じの方も多いかと思いますが、昨年のre:InventではDeclarative policies（以降は宣言ポリシーと記載）が新機能として発表されました。
これまでの管理方法との違いや使い分けが気になったので整理してみようと思います。

ポリシーの種類

まずはじめに、AWS Organizations のポリシータイプはAuthorization PoliciesとManagement Policies（以降は認証ポリシー/管理ポリシーと記載）に分かれています（表 ポリシーの比較 を参照）。

すべてご紹介するとなるとあまりにも量が多くなってしまうので、本ブログでは宣言ポリシーとの使い分けが特に重要になると思われる認証ポリシーについて整理したうえで管理ポリシーから宣言ポリシーについて整理していこうと思います。

認証ポリシー

認証ポリシーにはサービスコントロールポリシー/リソースコントロールポリシー（以降はSCP/RCPと記載）の2種類が存在します。どちらもAPIを直接的に制御することでアカウントの管理を実現するセキュリティ性の向上を目的とした機能です。

RCPは昨年の11月に発表された比較的新しいポリシーであるため、まずはSCPを振り返り、それと比較する形で整理していきたいと思います。

SCP

SCPはプリンシパル中心のポリシーです。ここでのプリンシパルとは、IAMユーザーやIAMロールなどを指しています。
つまり特定のプリンシパル（IAMユーザーやロール）に対して、特定のアクションを許可または拒否することができるのがSCPといえます。

例

例を挙げてみると、ユーザーAとユーザーBが存在するときに ユーザーAにはS3へアップロードを拒否し、ユーザーBにはS3へのアップロードを許可する といった制御を行いたい場合にSCPは有効です。

適用時の影響

SCPはプリンシパル中心のポリシーであるため、制限適用している組織内から外部へのリクエストに影響が出る可能性があります。
さきほどの例でいうと、十分な権限が付与されていてもSCPの設定前後でユーザーBは外部へのS3へアップロードを引き続き実行できるのに対して、ユーザーAは外部へのS3へのアップロードも実行できなくなる点に注意が必要です。

RCP

一方でRCPはリソース中心のポリシーです。さきほどのSCPでは特定のプリンシパルに対しての動作を制御できましたが、RCPではリソース対してどのような動作を許可するのかを制御できます。

例

早速例を考えてみます。SCPの例では特定のユーザーに対してS3バケットへのアップロードを許可するかどうかを制御しました。一方でRCPではS3バケットに対してHTTPS通信のみを許可する といった制御を行うことができます。この場合、適用後、HTTPS通信以外を用いてのS3への通信はすべて拒否されます。

適用時の影響

SCPはプリンシパル中心のポリシーであるため、制限適用している組織内から外部へのリクエストに影響が出る可能性があります。
さきほどの例でいうと、SCPの設定前後でユーザーAは外部へのS3へアップロードを引き続き実行できるのに対して、ユーザーBは外部へのS3へのアップロードも実行できなくなる点に注意が必要です。

RCPはリソース中心のポリシーであるため、制限適用している組織内だけではなく組織外からのリクエストにも影響が出る可能性があります。
さきほどの例では、RCPの設定前後でS3バケットに対してHTTPS通信を実行していた外部サービスに対する影響はありませんが、非HTTPS通信（HTTP通信）を用いてS3バケットにアクセスしていた外部サービスに対しては影響が出てしまいます。

SCPとRCPの比較

ここまでの2つのポリシーを比較すると以下のようにまとめることができます。

管理ポリシー

ここからが本題の管理ポリシーです。管理ポリシーの目的はAWSサービスとその機能を一元的に設定および管理することです。そのため、ポリシーの適用は管理アカウント自体にも及ぶ点を忘れてはいけません。

今回は管理ポリシーのうち、Declarative policies（宣言ポリシー）について詳しく見ていきたいと思います。

宣言ポリシー

宣言ポリシーの大きな特徴は、容易にOrganizations全体へAWSサービスのベースライン設定適用を宣言的に実施できることです。
また、認証ポリシーと異なってAPIを意識した設定が不要で、APIの変更時に更新作業が発生しない点も特徴の1つです。
加えて、アカウントステータスレポートによる確認や、ポリシーによるユーザーへのエラー内容のカスタマイズも可能となっています。

改めて特徴をまとめると以下のようになります。

• 容易性：Organizations全体へAWSサービスのベースライン設定の適用を宣言的に実施可能
• 更新不要：APIの変更に伴う影響がない
• 透明性：管理者としてはアカウントステータスレポートによってステータスを確認可能、ユーザーとしてはポリシーによるエラー発生時にエラー内容からアクション失敗の理由がわかる

執筆時点での機能紹介

ブログを執筆している2025年2月6日時点でEC2に関連する6項目に対するポリシーが提供されています。（参考：Supported AWS services and attributes）

認証ポリシーとの比較

最後にここまでの内容を元に比較表でまとめたいと思います。

表にまとめるとわかるように、認証ポリシー（SCP/RCP）は主語（プリンシパル/リソース）を制限するためにAPIレベルでの統制を行っています。一方で宣言ポリシーはサービスのベースライン適用をAPIを用いずに実現していることがわかります。

どちらか一方があればすべてが満たされるものではないため、それぞれの特性を活かし、要件に応じた選択が重要であることがわかります。

まとめ

これまでのSCPに加えてRCPや宣言ポリシーを活用することで、より統制の取れたアカウント運用が実現できそうです。
記載のとおり、各ポリシーは目的が異なってくるのでアカウントの目的に応じて適切な設定を行う必要があることを改めて確認できました。
また、将来的に宣言ポリシーの対象が拡充されてくるとより便利になりそうですね。

本ブログでは宣言ポリシーの機能詳細には触れることが出来なかったので、また別の機会にまとめたいと思います。

こちらの記事がどなたかの参考になれば幸いです。

akira