OCI IAM拒否ポリシーを触ってみた
1.はじめに
OCIでIAM拒否ポリシーが定義できるようになったらしいので触ってみました。
2.IAMポリシーとは
そもそもIAMポリシーとは？という方向けにポリシーについて簡単に説明します。
IAMポリシーとは、Oracle Cloud Infrastructure（OCI）テナンシ内のリソースへのアクセス権や操作権限を管理し、制御するための仕組みです。
そのため、IAMポリシーはOCIを扱う上で必須となるコンポーネントとなります。
IAMポリシーを設定することで、柔軟でセキュアな運用を実現することが可能となります。
ポリシーの作成方法や構文については、弊社過去ブログに掲載されていますので過去ブログをご覧ください。
OCI IAMポリシー作成方法と構文について | 株式会社シイエヌエス
3.拒否ポリシーの特徴
2025年11月20日以前までは、許可ポリシーのみ定義することが可能でしたが、2025年11月20日より拒否ポリシーも定義することが可能となりました。
拒否ポリシーの特徴としては以下4点が挙げられます。
l 拒否ポリシーの導入はオプトイン
拒否ポリシーはデフォルトで無効となり、拒否ポリシーを導入する場合はテナンシ管理者による有効化が必要となります。
一度有効化すると、コンソールから無効にすることはできなくなります。
なお、有効化直後に拒否ポリシーを有効化したユーザーにのみ拒否ポリシーの定義を許可する以下ポリシーが自動的に設定されます。ただし、後述する通りデフォルトドメインのデフォルトAdministratorsグループに所属するユーザーは拒否ポリシーが適応されないため、拒否ポリシーの定義が可能となります。
拒否ポリシー有効化後に自動で設定されたポリシー（IAMDenyPolicy
※ポリシーステートメントのrequest.principal.idに拒否ポリシーを有効化したユーザーのOCIDがデフォルトで設定されていました。
l 許可ポリシーのオーバーライド
拒否ポリシーは許可ポリシーよりも優先されます。
ただし、Administratorsロールはオーバーライドしません。
l コンパートメントレベルで動作し、より細かな制御が可能
拒否ポリシーと同様にコンパートメントレベルでポリシーが継承されます。
IAMポリシーは明示的に拒否ポリシーを設定せずとも暗黙的に拒否されますが、拒否ポリシーを設定することでより細かな制御が可能になります。
l アカウントロック防止
拒否ポリシーによるテナンシからのユーザーロックアウト防止策としてデフォルトドメインのデフォルトAdministratorsグループに対しては拒否ポリシーが適応されません。
4.許可ポリシーと拒否ポリシーの相違点
許可ポリシーと拒否ポリシーとでは、ポリシー構文において明確な違いがあります。
① 文頭
許可ポリシーと拒否ポリシーはポリシー文の文頭が異なります。
ポリシー構文 | 許可ポリシー | 拒否ポリシー |
文頭 | allow | deny |
また、クロステナンシポリシーのポリシー構文についても文頭が異なります。
クロステナンシポリシー構文 | 許可ポリシー | 拒否ポリシー |
文頭 | define admit endorse | define deny admit deny endorse |
② 権限の優位順
許可ポリシーと拒否ポリシーの間で権限の優位順が逆の順序となります。
ポリシー構文 | 許可ポリシー | 拒否ポリシー |
権限の優位順 | inspect < read < use < manage | manage < use < read < inspect |
動詞そのものの挙動としては許可ポリシーと拒否ポリシーの間で変わらず、ある権限を指定すれば下位の権限も許可または拒否されますが、動詞の優位順は許可ポリシーと拒否ポリシーで逆となるため、注意が必要です。
5.拒否ポリシーの動作検証
拒否ポリシーがどのように機能するのか簡単に動作を検証してみました。
〇検証内容
① バケットの管理権限とバケットの削除だけを拒否ポリシーとして設定されたグループに所属するユーザーが、バケットの削除を実行した際にバケットを削除できないこと
② ①のユーザーが所属するグループからバケットの削除拒否ポリシーを削除し、再度バケットの削除をした際にバケットを削除できること
〇検証準備
検証用に用意したグループ、ポリシー、ユーザーは以下の通りです。
※今回検証用に作成したリソースはリソース名の末尾を「_test_<リソース名>」で統一しています。
★グループ
★ポリシー
★ユーザー
〇検証
→ 検証ユーザーでバケットを作成します。
作成については管理権限を許可しているため何事もなく作成できます。
→検証ユーザーで作成したバケットの削除を試みます。
バケットの削除が拒否された結果、APIエラーとなりました。
拒否ポリシーによりバケット削除できないこと（検証内容①）が確認できました。
→検証ユーザーが所属しているグループに割り当てられているバケット削除の拒否ポリシーを削除します。
→検証ユーザーで再度バケットの削除を試みます。
拒否ポリシーが設定されていないため、バケット管理権限が正常に機能したこと（検証内容②）が確認できました。
6.まとめ
今回は、拒否ポリシーについて簡単に動作確認してみました。
拒否ポリシーは、リソースの削除など特定の操作だけを拒否したいという要件において、従来の複雑化したポリシー設定に比べ、ポリシーの可読性と権限の制御において柔軟性が期待できると思います。
こちらの発言は全て個人的意見です。内容につきましては、十分注意し投稿しておりますが、誤りがあれば直接ご指導頂けますとありがたいです。
