こんばんは。
今回は、パーミッションバウンダリについて整理していきます。
パーミッションバウンダリとは
パーミッションバウンダリとは、IAM ユーザーまたは IAM ロールが持てる権限の上限を定義する仕組みです。
IAM ポリシーでアクセスを許可していても、パーミッションバウンダリで許可されていない操作は実行できません。
つまり、
「この IAM ユーザー（またはロール）は、この範囲を超える権限は持てない」
という上限を設定するための機能です。
IAMポリシーとの違い
| 項目 | IAMポリシー | パーミッションバウンダリ |
|---|---|---|
| 役割 | 権限を付与する | 権限の上限を決める |
| 許可できる操作 | ○ | ×（直接許可しない） |
| 適用対象 | IAM ユーザー・グループ・ロール | IAM ユーザー・ロール |
| 主な用途 | 権限管理 | 権限の制限 |
ポイントは、パーミッションバウンダリだけでは何もできるようにならないということです。
イメージ
例えば、開発者へ次の IAM ポリシーを付与したとします。
EC2
S3
RDS
Lambda
一方、パーミッションバウンダリでは
EC2
S3
だけを許可していた場合、
最終的に利用できるのは
EC2
S3
だけになります。
つまり、実際に利用できる権限 = IAM ポリシー ∩ パーミッションバウンダリという考え方になります。
明示的な Deny がある場合
IAM のアクセス制御では、明示的な Deny（拒否）が最優先されます。
そのため、IAM ポリシーやパーミッションバウンダリで Allow（許可）されていても、いずれかに Deny が設定されている場合、その操作は実行できません。
AWS のポリシー評価では、「明示的な Deny は Allow よりも優先される」というルールを覚えておきましょう。
利用例
例えば、大規模な企業では各開発チームが IAM ロールを作成できるようにしたい場合があります。
しかし、
- IAM AdministratorAccess を付与されてしまう
- 本番環境へアクセスできてしまう
といった事態は避けたいものです。
そこで、
- IAM ポリシーではロール作成を許可
- パーミッションバウンダリで許可できる権限を制限
という構成にします。
これにより、開発者は自由に IAM ロールを作成できますが、許可された範囲を超える権限を持つロールは作成できません。
IAMポリシー・SCP・パーミッションバウンダリの違い
| 機能 | 対象 | 目的 |
|---|---|---|
| IAM ポリシー | ユーザー・ロールなど | 権限を付与する |
| パーミッションバウンダリ | ユーザー・ロール | 権限の上限を設定する |
| SCP（Service Control Policy） | AWS アカウント・OU | アカウント全体の上限を設定する |
SCP、パーミッションバウンダリ、IAM ポリシーがすべて適用される場合は、すべてで許可されて初めてアクセスが許可されます。
逆に、いずれかで拒否されている場合は、その操作は実行できません。
まとめ
パーミッションバウンダリは、IAM ユーザーや IAM ロールが持てる権限の上限を定義する仕組みです。
特徴をまとめると、
- IAM ポリシーとは役割が異なる
- 権限を付与するのではなく、上限を設定する
- IAM ポリシーと組み合わせて利用する
- 明示的な Deny は最優先で評価される
- SCP と組み合わせることで、より強力なアクセス制御を実現できる
- 権限昇格の防止やセルフサービス型 IAM 管理に役立つ