コンパートメント階層でのIAMポリシーの管理 (2026/02/26)

https://www.ateam-oracle.com/managing-iam-policies-in-compartment-hierarchy

投稿者：Kiran Thakkar | Master Principal Cloud Architect

Rahul Pratap Singh | Senior Product Manager

はじめに

Oracle Cloud Infrastructureでは、コンパートメント階層ベースの新しいポリシー評価方法が導入されました。この方法では、これまでよりも多くのIAMポリシーステートメントがサポートされます。この変更により、お客様はポリシー評価の一貫性とサービスの信頼性を維持しながら、IAMポリシーを従来の制限を超えて拡張できるようになります。

Oracle Cloud Infrastructure (OCI) では、ルート・コンパートメントからリーフ・コンパートメントに至るまで、コンパートメント階層に沿って評価される IAM ポリシー・ステートメントの総数に制限が設けられるようになりました。このガイドでは、ポリシー関連のエラーが発生する可能性のある理由を説明し、それらのエラーを解決および防止するための実践的で優先順位の高いアクションを紹介します。

コンパートメント階層

まず、コンパートメント階層とは何かを理解しましょう。以下のコンパートメント構造では、すべてのコンパートメント階層を示しています。

上記のコンパートメント構造について、すべてのコンパートメント階層を示す図を以下に示します。

上の図にある色付きの縦線はすべて、コンパートメント階層を表しています。図に示されているように、ルートコンパートメントはすべてのコンパートメント階層の一部です。同様に、レベル1のコンパートメントは複数のコンパートメント階層の一部となります。一方、リーフコンパートメントは1つのコンパートメント階層のみに含まれます。そのため、可能な限り、ほとんどのポリシーをリーフコンパートメントレベルで記述することをお勧めします。

注: 一部のサービスはルートコンパートメントに存在します。これらのポリシーはルートコンパートメントに記述する必要があります。

この制限の背景については、公式ドキュメントを参照してください:
https://docs.oracle.com/en-us/iaas/Content/Identity/policymgmt/policy-limits-compartment-hierarchy.htm

IAM ポリシーステートメントの制限

いずれかのコンパートメント階層で IAM ポリシーステートメントの制限を超えると、IAM ポリシーの作成、更新、または削除中にエラーが発生する可能性があります。

エラーの例:
このコンパートメント階層に許可されているポリシーステートメントの最大数に達しました (制限: 500、現在の使用量: 502)。

上記のエラーが表示された場合、影響を受けないもの:

コンパートメント階層内のサポートされている制限内の既存の IAM ポリシーは影響を受けません。
すでに作成され有効なポリシーについては、ランタイムアクセスの強制には影響はありません。
ポリシーまたはコンパートメントをアクティブに変更しない限り、アクションは必要ありません。

なぜこのエラーが表示されるのでしょうか？ IAMポリシーの制限は、コンパートメント階層レベルで評価されます。ルートコンパートメントで定義され、子コンパートメントに継承されたすべてのポリシーは、まとめてカウントされます。階層の上位、特にルートにポリシーが多すぎると、たとえそれらのポリシーがリソースの小さなサブセットにしか関連していなくても、すぐに制限に達する可能性があります。コンパートメント階層のポリシーステートメント数を説明するために、上に示したコンパートメント階層の小さなサブセットについて、下の図で各コンパートメント階層のポリシーステートメント数をカウントします。

上の図では、赤い円はそれぞれ、そのコンパートメント内のポリシーステートメントの数を表しています。図示されている構造には4つのコンパートメント階層が含まれており、各階層のポリシーステートメントの総数がその下に表示されます。4つの階層全体で、1つの階層あたりのポリシーステートメントの最大数は450です。

これにより、強調する価値のあるいくつかの重要な観察結果が得られます。

ルートコンパートメントレベルで定義されたポリシーステートメントは、すべてのコンパートメント階層にカウントされるため、ルートレベルのポリシーは、スコープの点で最も広範囲に及び、ポリシーステートメントの制限への影響の点でも広範囲に及びます。
AppDev コンパートメントで定義されたポリシーは、構造内の共有位置を反映して、3 つの異なる階層に貢献します。
対照的に、リーフコンパートメント内のポリシー (PRD や NPRD など) は、それぞれの個別の階層に対してのみカウントされるため、ポリシー制限の観点からは最も効果的です。

階層ごとの制限に近づくと、環境の拡大に応じてポリシーを追加する能力が制限される可能性があるため、コンパートメント構造を計画する際には、ポリシーステートメントが階層間でどのように蓄積されるかを理解することが重要です。

推奨されるアクション：
コンパートメント階層内のIAMポリシーステートメントの数を減らし、ポリシーの作成/更新の失敗やコンパートメントの移動の失敗を防ぐには、以下の手順に従ってください。リスクの最も低い変更から順番にアクションを実行してください。

1. 未使用、重複、または不要なポリシーを削除します。
これは、コンパートメント構造を変更せずにポリシーステートメントの数を減らす最も速い方法です。

廃止されたプロジェクトまたは環境に関連付けられたポリシー
同じ権限を付与する重複ステートメント
必要なくなった一時的な移行またはブレイクグラスポリシー

例 1:
以前 (重複ステートメント):
グループ AppTeamA にコンパートメント Dev 内のインスタンスの管理を許可する
グループ AppTeamA にコンパートメント Dev 内のインスタンスの読み取りを許可する

後 (重複を削除):
グループ AppTeamA がコンパートメント Dev 内のインスタンスを管理できるようにします。
上記の例では、重複または冗長な権限 (「読み取り」や「管理」など) を削除して重複するポリシーステートメントを統合し、全体的なポリシー数を減らすことを提案しています。

例2：
サービス osms にテナンシー内のインスタンスの読み取りを許可する
サービス osms にテナンシー内のインスタンスの読み取りを許可する
複数のアプリケーションチームが、ルートコンパートメント内の異なるポリシーオブジェクトに同じポリシーステートメントを作成する場合があります。これらの重複ステートメントを見つけて、どちらか一方を削除できます。

例3:
サービスobjectstorage-us-ashburn-1にコンパートメントDevのキーの読み取りを許可する
サービスobjectstorage-us-ashburn-1にテナンシーのキーの読み取りを許可する

サービス FaaS がコンパートメント Dev で仮想ネットワークファミリを使用できるようにする
サービス FaaS がテナンシーで仮想ネットワークファミリを使用できるようにする

上記の例は、コンパートメント階層の異なるレベルで冗長なステートメントを排除し、ルートコンパートメントとリーフコンパートメントの両方で権限が不必要に重複しないようにする必要があることを示しています。ポリシーはリーフレベルに保持し、ルートからは削除するのがベストプラクティスですが、他のチームがユースケースでルートのポリシーに依存していないことを確認する必要があります。

2. ポリシーをターゲットコンパートメントに近づけるルートコンパートメント
で定義されたポリシーはテナンシー全体に適用され、すべてのコンパートメント階層でカウントされます。ポリシーのスコープを適切な最下位のコンパートメント（主にリーフコンパートメント）に限定すると、継承が削減され、関連のない階層のステートメント数も減少します。

例：
グループFinanceAdminsにコンパートメントRoot:App:Prod:Finance内のバケットの管理を許可する
上記のポリシーステートメントは、テナンシ内のすべてのコンパートメント階層のポリシーステートメント制限にカウントされます。
代わりに、以下に示すように、ポリシーをFinanceコンパートメントに移動します。
グループFinanceAdminsにコンパートメントFinance内のバケットの管理を許可する
上記のポリシーステートメントは、「Finance」コンパートメント階層のみにカウントされ、ルートコンパートメント内のポリシー数も削減されます。

3. 既存のポリシーをリファクタリングして簡素化する
最小限の権限を維持しながらポリシーを統合することで、限定的で繰り返しの多い記述を削減します。
典型的なリファクタリング

同じグループとリソースファミリのステートメントを結合する
不要になった権限を削除する
多数の単一リソースステートメントを、より少ないファミリーレベルのステートメントに置き換えます（適切な場合）

例
(複数の狭いステートメント):
グループ DevOps にコンパートメント App 内のインスタンスの読み取りを許可する
グループ DevOps にコンパートメント App 内のボリュームの読み取りを許可する
グループ DevOps にコンパートメント App 内の vnic-attachments の読み取りを許可する

後（ファミリーごとに統合）：
グループ DevOps がコンパートメントアプリの compute-family を読み取ることを許可します。

4. タグベースのポリシーを使用する（長期的な最適化）
タグベースのポリシーを使用すると、より少ないポリシーステートメントでアクセス制御を拡張できます。タグの一貫性が保たれている場合、タグベースのポリシーは、コンパートメントまたはリソース固有の多くのステートメントを置き換えることができます。

仕組み

リソースにタグを適用する（例：Environment=PROD）
一致するタグに基づいてアクセスを許可するポリシーを記述する

リソースに適用されるタグの例
:
環境 = PROD
ポリシー:
グループ ProdAppAdmins がコンパートメント Network 内の network-family-resources を使用できるようにします (target.resource.tag.Environment = 'PROD')

ガイダンス