はじめに
AWSでIAMポリシーを使いこなしてきたエンジニアが、初めてOracle Cloud Infrastructure （OCI） に触れたとき、こう思うはずです。「あれ、Deny（拒否）はどこ？」「ロール（Role）はどうやって作るの？」と。
OCIのIAMは一見シンプルに見えますが、その設計思想はAWSとは根本的に異なります。「AWSのつもり」で設計を進めると、意図せぬ権限継承が発生したり、逆にガバナンスが効かなくなったりといった落とし穴にハマることも少なくありません。
本記事では、AWSエンジニアがOCIへスムーズにシフトできるよう、IAMポリシーの記述方式や独特の仕様を詳しく解説します。
AWSエンジニアの方に「OCIとしての正しいメンタルモデル」を構築していただくため、本記事では安易な用語の読み替え（例：コンパートメントをAWSの〇〇と呼ぶ等）は行わず、OCIの標準用語を用いて解説を進めます。
なお、本記事はポリシーの「書き方・考え方」にフォーカスするため、以下の項目については理解しているものとして解説を省略します。あらかじめご了承ください。
- コンパートメントの概念
- アイデンティティ・ドメイン / IDCS
- フェデレーション（外部ID連携）設定
1.IAMポリシーの概要
OCIのIAMポリシーはテナンシ（全体）、もしくはコンパートメント単位での適用範囲が決められ、上位のコンパートメントに付与している権限は下位のコンパートメントにも継承される仕様になります。下記のようなコンパートメント構成において、Aコンパートメントを適用範囲とした権限を与えた場合、下位のCコンパートメントにも同様の権限が与えられます。
そのため、各コンパートメントの管理者権限を付与する場合は上位のコンパートメントにIAMポリシーを作成し、そこで下位のコンパートメントの管理者権限を与えるのが推奨されます。
なお、ポリシーを作成するコンパートメントの直下にないコンパートメントを指定する場合は、 compartment compartment_A:compartment_C のようにパスで指定します。
※Aコンパートメントに作成した場合（パス指定が不要な例）
Allow group groupA to manage all-resources in compartment compartment_C
※具体的なIAMポリシーの記述方式については後述。
※上記のコンパートメント構成の場合、CコンパートメントにCコンパートメントの管理者権限を付与するIAMポリシーがあると、Cコンパートメントの管理者権限を持つユーザがそれを変更できてしまうため、セキュリティの観点からは推奨されません。
1.1.AWSとの相違点
AWSではIAMポリシーはユーザ/グループ/ロールのいずれかに付与することが出来ますが、OCIではグループ単位での付与のみ可能です。
そのため、『ユーザ作成と同時にどのグループに所属させるのか』というワンクッションが必要になります。
※OCIにはAWSのような『リソースにアタッチするIAMロール』の概念がありませんが、代わりに後述する動的グループが存在します。
2.プリンシパル
OCIにおけるポリシーの適用対象（プリンシパル）は主に以下の3つに整理されます。リソースとサービスは混同しがちですが、リソースは各サービス内の実体であり、サービスはそれを包括するものを指します。（オブジェクトストレージというサービスの中に、リソースとしてのバケットがあるイメージです。）
- ユーザ / グループ: 人物やその集まり
- インスタンス・プリンシパル / リソース・プリンシパル（動的グループで集約）: ComputeインスタンスやFunctionsなどのリソース自体
- サービス（サービスプリンシパル）: OCIの各種バックエンドサービス
2.1.AWSとの相違点
リソースに対する権限付与の仕組みがAWSと大きく異なり、OCIでは動的グループ（Dynamic Group）と呼ばれる仕組みを使い、個々のインスタンスやFunctionsといったリソースをグループ化してリソースに対しての権限付与を行います。
動的グループでリソースを指定するために記載する一致ルールには下記のものがあり、用途に応じて使い分ける必要があります。
| 定義可能な値 | 対象範囲 | 具体例 |
|---|---|---|
| instance.compartment.id / resource.compartment.id | 特定のコンパートメント内のリソース | resource.compartment.id = 'ocid1.compartment...' |
| instance.id / resource.id | 特定のリソース（OCID指定） | resource.id = 'ocid1.instance...' |
| tag.<tagnamespace>.<tagkey>.value | 特定のタグが付与されたリソース | tag.Operations.environment.value = 'test' |
| resource.type | 特定のリソースタイプ（※1） | resource.type = 'fnfunc' |
※1 resource.type には、OCIDの第2セグメントに該当するタイプ名（instance や fnfunc など）を指定します。
一致ルール具体例（特定のコンパートメントのインスタンスを指定したい場合） ALL {resource.type = 'instance', resource.compartment.id = 'ocid1.compartment...'}
3.IAMポリシーの記述方式
OCIのIAMポリシーは下記のように直感的に理解できる形式で記述されるため、「誰が」「どの操作を」「どのリソースに対して」「どの適用範囲で」「どういった条件で」というのが一目で理解できるかと思います。 IAMポリシー文を構成する要素の仕様について具体的な例をまじえて解説していきます。
Allow {subject} to {verb} {resource-type} in {location} where {conditions}
3.1.subject
「誰が」の部分になります。 指定できる形式は下記のとおりです。なお、グループ名やコンパートメント名などの名前指定はポリシー作成時に内部でOCIDへ解決されるため、グループ等を削除して同名で再作成した場合は、ポリシーを編集して再保存（再コンパイル）する必要がある点に注意してください。
| subject | 内容 |
|---|---|
| group <GroupName> | IAMグループ名（※デフォルト以外のドメインの場合は group <DomainName>/<GroupName> ） |
| group id <GroupOcid> | IAMグループのOCID（※視認性が低いため非推奨） |
| dynamic-group <DynamicGroupName> | 動的グループ名 |
| dynamic-group id <DynamicGroupOcid> | 動的グループのOCID（※視認性が低いため非推奨） |
| any-group | 全グループ（動的グループも含む） |
| any-user | 全ユーザ/全プリンシパル |
※ any-user はテナンシ内のすべての認証済みエンティティが対象となります。一般ユーザ権限としては範囲が広すぎるため注意が必要ですが、リソース・スケジューラやData Science等のリソース・プリンシパルに対して where request.principal.type = '...' のような条件と組み合わせて権限を与える際の公式定型パターンとして頻繁に使用されます。
3.2.verb（動詞）
「どの動作を」の部分になります。 下記の4つから指定可能になりますが、サービスによって動作のレベルに差分があるためご注意ください。 また、read には inspect の権限が含まれるように、より上位のverbには下位のverbの権限が含まれます。
| verb（動詞） | 内容 |
|---|---|
| inspect | 一覧取得（ユーザー指定メタデータや機密情報は含まない）。 ※ポリシー本文やネットワーク構成(セキュリティ・リスト等)は inspect でも内容まで取得できる |
| read | 読み取り権限 |
| use | リソースに対する日常的な操作権限 ※作成・削除は基本的に不可 |
| manage | リソースに対する全ての権限 |
3.3.resource-type
「どのリソースに対して」の部分になります。 すべてのリソースタイプを列挙することは困難なため、特殊な集合リソースタイプによる指定方法をご紹介します。
通常リソースタイプを指定する場合には下記のように記載していきますが、instances ではインスタンス自体の起動・停止などの操作しか含まれておらず、カスタムイメージを作成したい場合は instance-images という別のリソースタイプも指定する必要があります。
また、カスタムイメージの作成（CreateImage）を行うには、manage instance-images に加えて、インスタンス側の操作権限である use instances も併せて必要になる点に注意してください。
Allow group groupA to use instances in compartment compartment_prod
# カスタムイメージ作成には manage が必要 Allow group groupA to manage instance-images in compartment compartment_prod
ここで「instance-family」というインスタンスに関わる複数のリソースタイプを束ねた集合リソースタイプを使用することで、ポリシー文を簡略化し、視認性を高めることができます。
Allow group groupA to use instance-family in compartment compartment_prod
※集合リソースタイプで use を指定した場合でも、含まれる各リソースの権限レベルは use 止まりとなります。そのため、カスタムイメージの作成など manage 権限が必要な操作は use instance-family だけでは実行できません。
※設計的に不要なリソースへの権限は付与しないなどの厳格な制約がある場合は、集合リソースタイプを使わず個別リソースタイプで指定する必要があります。
3.4.location
「どの適用範囲で」の部分になります。 「1.IAMポリシーの概要」で解説したとおり、テナンシ全体もしくはコンパートメントを指定することが可能です。 コンパートメントはOCIDでの指定も可能ですが、どのコンパートメントなのかの判別がつかないため、一般的にはコンパートメント名での指定が推奨されます。
3.5.conditions
「どういった条件で」の部分になります。 conditionsはオプションのため必須ではありませんが、特定のリクエスト条件を満たした場合にのみポリシーを適用させることができます。 条件指定には =、!=、in、not in、ALL {}（AND条件）、ANY {}（OR条件）や、パターン一致（/test*/ などのワイルドカード）が利用可能です。
※in 、not in はタグ変数でのみ利用可能です。
# 適用範囲をAコンパートメントとし、東京リージョン（NRT）での操作に限定する場合 Allow group groupA to manage instance-family in compartment compartment_A where request.region = 'NRT'
# 「instance-family」の権限を与え、インスタンスの削除操作（TerminateInstance）だけを除外する場合 Allow group groupA to manage instance-family in compartment compartment_A where request.operation != 'TerminateInstance'
# リソースのタグ値が「test」または「prod」のリソースを対象とする場合 Allow group groupA to use instance-family in compartment compartment_A where target.resource.tag.Operations.environment in ('test', 'prod')
※ target.resource.tag による制御を行う場合、コンソールでの一覧表示（List/Inspect）や一部の起動/停止操作などでリソースタグによる絞り込みがサポートされていない場合があります。そのため、コンソール操作を許可するには inspect 権限を別文で付与するなどの考慮が必要です。 ※新規作成時はリソースがまだ存在せず評価対象のタグがないため、作成権限にはタグ条件を含めない別のポリシーとの併用が必要になります。
3.6.AWSとの相違点
ここまでのIAMポリシー例でお気づきかもしれませんが、OCIのIAMポリシーではAllow文のみ記述可能で、Explicit Deny（明示的な拒否文）が存在しません。デフォルトはすべて拒否となっています。AWSのSCP（Service Control Policies）に相当する明示的なガードレールは、IAMポリシーではなく『コンパートメント割当て制限（Quotas）』や『セキュリティ・ゾーン』などで制御する必要があります。
また、ポリシーの評価には「許可の累積（累計）」という原則があります。あるポリシーの条件文（!= など）で特定の操作を除外していたとしても、他のポリシーでその操作が許可されていればアクセスが許可されます。 そのため、意図しない権限のすり抜けを防ぐようシンプルかつ厳格にAllowを定義するのがOCIの設計思想です。
4.まとめ
本記事では、AWSエンジニアがOCIを触れた際につまずきやすいポイントを中心に、OCIのIAMポリシーの仕様を解説しました。
最後に、今回特に押さえておきたいポイントを振り返ります。
- 「グループ」が主役: ユーザーやロールではなく、常にグループ（または動的グループ）単位で権限を考える。
- 「累積」の美学: Denyがない代わりに、Allowを必要最小限に積み上げていくシンプルな設計を心がける。
- 「ガードレール」の併用: IAMポリシーで拒否しようとせず、Quotasやセキュリティ・ゾーンを組み合わせて統制を効かせる。
AWSでの経験が長いほど、最初は「Denyがない不安」や「ロールがない不便さ」を感じるかもしれません。しかし、OCIのIAMは非常に一貫性があり、一度その「作法」を理解してしまえば、大規模なマルチコンパートメント環境でも迷いのない設計が可能になります。
本記事が皆様の技術的な課題解決や学習の一助となれば嬉しく思います。
