はじめに
従来、OCI IAM ポリシーの定義は許可のみ可能でした。所謂ホワイトリスト方式です。
しかし、 2025年11月のアップデートにより、拒否の定義が可能となりました。
本記事では、拒否ポリシーについて整理するとともに、拒否ポリシーの設定時の注意点について動作確認を交えてまとめていきます。
概要
おさらいとして、IAM ポリシー構文は以下の通りです。
allow <subject> to <verb> <resource-type> in <location> where <conditions>
アップデート前は、ポリシーの先頭に以下4つのみ定義可能でした。
allow # 許可
endorse # [クロステナンシ (アクセスする側)]：自テナンシ内のグループに別テナンシへの権限付与する
admit # [クロステナンシ (アクセスされる側)]：別テナンシにてEndorseしたグループに対して、自テナンシ内での権限付与・承認
define # [クロステナンシ (両方)]：別テナンシリソースの名前を定義
アップデート後は、ポリシーの先頭に deny を定義可能となりました。
allow # 許可
+ deny
endorse # [クロステナンシ (アクセスする側)]：自テナンシ内のグループに別テナンシへの権限付与する
+ deny endorse
admit # [クロステナンシ (アクセスされる側)]：別テナンシにてEndorseしたグループに対して、自テナンシ内での権限付与・承認
+ deny admit
define # [クロステナンシ (両方)]：別テナンシリソースの名前を定義
拒否ポリシーは許可ポリシーよりも優先されます。（後述する一部を除いて）
元々ポリシーは 暗黙のdeny なので、許可ポリシーで定義されていない権限は拒否されます。
そのため、拒否ポリシーはガードレール的な役割として利用するものだと考えてください。
特徴
利用するにはオプトインが必要
拒否ポリシーは、デフォルトでは利用できません。
明示的に有効化する必要があります。
また、一度有効化すると無効化することができなくなります。
リリースノート上では、UIからはできないと書いてありますが、正式なドキュメントには無効化できないと記載があるので、無効化不可という認識で問題ないかと思います
拒否ポリシーの有効化は、UIでは元に戻せません。
Default Identity Domain の Adminsitrators グループ には適用されない
OCI テナンシを払い出した際に、デフォルトで Default Identity Domain が作成されており、Administrators グループも作成されています。
アカウントロックアウト防止のため、いかなる拒否ポリシーも Administrators グループには適用されません。
デフォルト・ドメインの各テナンシに作成されるデフォルトの管理者グループは、拒否ポリシーから除外されます。これにより、広範な拒否ポリシーによって誰かが誤ってロックアウトされた場合に、デフォルトの管理者グループ・アクセスが可能になります。
管理者ロールはオーバーライドされない
OCI には、IAM ポリシーで権限を付与する他に、管理者ロールという特定の権限が付与されるロールが存在します。
いかなる拒否ポリシーも 管理者ロールの権限をオーバーライドしません。
IAM拒否ポリシーは、アイデンティティ・ドメインの管理ロール(アイデンティティ・ドメイン管理者、セキュリティ管理者、ユーザー・マネージャなど)をオーバーライドしません。
注意点
適用される権限レベル範囲
再掲にはなりますが、IAM ポリシー構文は以下の通りです。
allow <subject> to <verb> <resource-type> in <location> where <conditions>
OCI の IAM ポリシーは、上記構文の verb にて権限レベルを設定します。
verb にて指定可能な権限と、その範囲は以下の通りです。
# 下位 < -------------- > 上位
inspect ⊃ read ⊃ use ⊃ manage
許可ポリシー においては、上位の権限を指定すれば下位の権限も許可 されます。
例えば、use を指定すれば、下位の read, inspect も許可されます。ただし、上位の manage は許可されません。
拒否ポリシー においては その逆 で、下位の権限を指定すれば上位の権限も拒否 されます。
例えば、use を指定すれば、上位の manage も拒否されます。ただし、下位の read, inspect は拒否されません。
有効化手順
有効化手順は以下の通りです。
OCI コンソール左上のハンバーガーマークをクリックし、「Identity & Security」→「Policies」をクリックします。
「Actions」→「Policy settings」をクリックします。
コンパートメントは関係ないので、ルートコンパートメント以外が選択されていても大丈夫です
「Enable IAM Deny policy」の有効化ボタンをクリックします。
すると以下の通り確認ポップアップが表示されるため「Enable」をクリックします。
- 全ユーザーが拒否ポリシーを作成できないようにするポリシーを自動で作成
- 「Administrators グループ」「拒否ポリシーを有効化した IAM ユーザー」は拒否ポリシーの設定を可能とする
クリックすると、画面下部に成功を示すポップアップが表示されるため完了です。
そして、自動で作成されたデフォルト拒否ポリシーの画面が表示されます。
ステートメントを見ましたが、有効化したユーザー以外の拒否ポリシー設定を拒否している内容となっています。
deny any-user to manage policies in tenancy where all {target.policy.type = 'deny', request.principal.id != '拒否ポリシーを有効化したIAMユーザーのOCID'}
検証
幾つか検証していきます。
検証する際の初期構成は以下の通りです。
登場人物は以下の通りです。全員管理者権限をポリシーにて付与しています。
- テナンシ開設時に登録したユーザー
- 拒否ポリシーを有効化したユーザー
- 検証ユーザー
自動作成されたデフォルトポリシーは削除可能かどうか
結果は以下の通りでした。
- 検証ユーザー： 削除不可
- 拒否ポリシーを有効化したユーザー： 削除可
- テナンシ開設時に登録したユーザー： 削除可
Administrators グループが拒否ポリシー適用対象外かどうか
試しに、以下のようにユーザーを入れ替えてみます。
この状態で、本章 で試した自動作成拒否ポリシーの削除が可能かどうかを試します。
本章 の記載が正しければ、Administrators グループに所属すれば如何なる拒否ポリシーも適用されないため、以下の結果になると予想ができます。
- 検証ユーザーは削除可
- テナンシ開設時に登録したユーザーは削除不可
結果は以下の通りでした。予想通りの結果です。
- 検証ユーザー： 削除可
- テナンシ開設時に登録したユーザー： 削除不可
本章 で記載の通り、 Default Identity Domain に所属する Administrators グループには、いかなる拒否ポリシーも適用されないということがわかります
逆を言えば、テナンシ開設時に登録したユーザーであっても、所属するグループによってはロックアウトされてしまうということになります
おわりに
本記事では、拒否ポリシーについて整理しました。
本アップデートにより、柔軟な権限付与が期待できそうです。
🌟この記事が誰かの役に立てば幸いです！
また、ご質問やフィードバックもお待ちしています。