皆さま、こんにちは！y.takanashiです。
詳細解説系の記事の第3弾となります。
今回は IAM ポリシー の基本機能について紹介します。
IAM ポリシーはOCI のアクセス管理において重要な役割を果たし、適切な設定が求められます。
本記事では、ポリシーの仕組みを理解し、実践的な活用方法を学んでいきましょう。
過去の詳細解説系の記事は以下からご覧いただけます。
Cloudiiブログ - 「OCI DRGの構成要素について解説してみる」
Cloudiiブログ - 「OCI モニタリングを詳しく解説する」
※注意
本記事はあくまで個人の検証に基づく内容です。
詳細情報については、以下のドキュメントをご参照ください。
Speaker Deck - 「IDおよびアクセス管理 概要」
※10ページ目からポリシーについての解説が記載されています。
目次
IAM ポリシーとは？
IAM ポリシー（以下ポリシー）とは、Oracle Cloud Infrastructure （以下OCI）でリソースへのアクセス権限を制御する仕組みです。
これにより、以下を定義できます。
- 誰が（Subject）
- どのような操作を（Verb）
- どのリソースに対して（Resource Type）
- どの範囲で（Location）
- どの条件で（Conditions）
これらの要素を組み合わせることで、リソースに対してきめ細かいアクセス制御を実現できます。
ポリシーは複数のステートメントによってアクセス権限を制御します。
基本構文は次の通りです。
Allow <Subject> to <Verb> <Resource Type> in <Location> [where <Conditions>]
ポリシー内では最大50個までステートメントを定義可能です。
（以降、ポリシー=ステートメントと捉えてください。）
注意点
ポリシーを作成する際、以下の点に注意が必要です。
- ポリシーは常に「Allow」で始まり、「Deny」は使用不可
- ただし、特定の操作を拒否する場合は 条件（Conditions） 内で定義可能（詳細は後日投稿する記事で紹介します。）
- ユーザーはグループに所属しないとポリシーによるアクセス制御ができない
- そのため、ユーザー作成時に必ず何らかのグループに所属させる必要 あり
- 「any-user」で定義可能だが、個別ユーザー毎の権限付与は不可
- デフォルトでは「最小権限の原則」により全操作が拒否される
- そのためユーザーをグループに追加した後、ポリシーで必要な権限を付与する必要がある
- ポリシーは大文字小文字を区別せず特定の文字列を認識するため、リソース名はテナンシ内で一意にする必要がある
- 「Administrators」グループにはデフォルトで全権限が付与され、削除・変更不可
（OCIで最初に登録したユーザーには自動で登録され、以降各設定を行えるようになる）
IAM ポリシーの構成要素
「1 IAM ポリシーとは？」で説明した以下構成要素について解説します。
- 主体（Subject）
- 動詞（Verb）
- リソース・タイプ（Resource Type）
- 場所（Location）
- 条件（Conditions）
主体（Subject）
主体（Subject）は「誰が」実行するか定義します。
ポリシーは 個々のユーザーには適用できず、 必ずグループに所属させる必要 があります。そのため、ユーザーを作成した際には、適切なグループに追加することが重要です。
また、通常のグループに加えて、動的グループ（OCIDやリソース・タイプを指定して、コンピュート・インスタンス等のリソースをグループ化する仕組み）を使用してポリシーを定義することも可能です。これにより、特定のインスタンスやリソースに対して柔軟な権限付与が可能になります。
詳細はOCI 公式ドキュメントをご覧ください。
グループ名の定義方法
ポリシー作成時には、グループ名の前に所属ドメインを定義する必要があります。
例）「A-Domain」というドメインに所属する「A-Admins」に IAM ポリシーを適用する場合：
Allow group 'A-Domain'/'A-Admins' to ~
※Defaultドメインに所属するグループの場合、ドメイン名の指定は省略可能です。
この場合、以下のように定義できます。
Allow group 'A-Admins' to ~
通常、IAM ポリシーは単一のグループに対して定義しますが、 複数のグループを指定することも可能です。その場合は、カンマ区切りで指定します。
Allow group 'A-Domain'/'A-Admins', 'A-Domain'/'B-Admins' to ~
同様に、グループ名ではなくグループの OCID を指定することも可能です。
Allow group id ocid1.group.oc1..aaaaaaaaqgroupid to ~
注意点
同じリソース名で グループ や 動的グループ を再作成した場合、ポリシーは自動で更新されず、以前の動的グループに対して権限が適用され続けてしまいます。
例えば、A-Resourcesという動的グループに以下ポリシーを適用したとします。
Allow dynamic-group 'A-Domain'/'A-Resources' to manage all-resources in tenancy
その後、動的グループのルールを変更した場合、ポリシーは自動で更新されず、以前の「A-Resources」に権限が残ったままとなります。
そのため同じリソース名のグループもしくは動的グループを再作成する場合、以下の手順を実施してください。
- 既存のポリシーを削除
- 新しいグループ、動的グループを作成
- 再度、同じポリシーを適用
これにより、新しいグループもしくは動的グループに正しく権限を適用できます。
その他の指定方法
その他ポリシーの主体として、以下のような特殊な定義も可能です。
1.any-group（グループに所属する全てのユーザーを対象）
すべてのグループのユーザーに権限を付与できます。
例）全ユーザーに対し、オブジェクト・ストレージの読み取り権限を付与する場合：
Allow any-group to read object-family in compartment Project-A
※「any-user」とほぼ同義ですが、「any-group」を使用するとグループのみに限定できるため、よりセキュアな設定が可能です。
2. service（OCI サービスに対して権限を付与）
特定の OCI サービスに対し、必要な操作権限を付与できます。
例）東京リージョンのオブジェクト・ストレージがリージョン間レプリケーションを実行できるようにする場合：
Allow service objectstorage-ap-tokyo-1 to manage object-family in compartment Project-A
これらの設定を活用することで、OCI のリソース管理をより効率的かつ安全に行うことができます。
動詞（Verb）
動詞（Verb）は上記で定義した主体（Subject）に対して「どのような操作を」実行するかを定義します。
ポリシーでは、適切な動詞を選択することで、必要最小限の権限を付与し、セキュリティリスクを低減できます。過剰な権限を付与すると、不必要な操作を許可してしまう可能性があるため、運用に応じた適切な動詞の設定が重要です。
ポリシーで利用可能な動詞は以下となっています。
| 動詞 | 許可される操作 | 対象ユーザー |
|---|---|---|
| manage | 全ての操作 | 管理者 |
| use | readの操作権限 + 既存リソースの操作（作成・削除は除く） | 日常のユーザー |
| read | inspectの操作権限 + リソースのメタデータ取得 | 内部監査者 |
| inspect | リソースのリスト取得 | 外部監査者 |
動詞の詳細
- manage：すべての操作を許可する最上位の権限であり、通常は管理者向けに設定されます。
- use：readの権限に加え、既存リソースの操作（作成・削除は除く）が可能。ただし、ポリシーの更新や ネットワーク・セキュリティ・グループ（NSG）/ セキュリティ・リスト（SL）の更新 など、一部の操作は含まれません。
- read：inspectの権限に加え、リソースのメタデータ（詳細情報）の取得が可能。内部監査目的で設定されることが多いです。
- inspect：最も制限の厳しい動詞で、リソースのリスト表示のみが可能。リソースの詳細な内容にはアクセスできませんが、 VCN のメタデータ（ルート表の内容や NSG/SL の詳細）や ポリシーのステートメントの閲覧 は可能です。
動詞の選択は、付与する権限の粒度を決定する重要な要素です。以下の基準を参考に、適切な動詞を選択してください。
・フルアクセスが必要な場合 → manage
・リソースの管理はできるが、更新範囲を制限したい場合 → use
・監査目的で、リソースの詳細を閲覧させたい場合 → read
・リソースの一覧表示のみを許可したい場合 → inspect
適切な動詞を設定することで、OCI 環境のセキュリティを強化し、運用管理を効率化できます。
リソース・タイプ（Resource Type）
リソース・タイプ（Resource Type）は「どのリソースに対して」実行できるかを定義します。
例えば、VCNに対して権限を付与する場合、以下のように定義します。
Allow 'A-Domain'/'A-Admins' to manage vcns in compartment Project-A
しかし、サブネットやルート表など、別のネットワーク系リソースにも権限を付与する場合、それぞれ個別に Iポリシーを定義する必要があります。
そのため、 ファミリー・リソース を使用することで、関連するリソースを一括管理できます。
例えば、ネットワーク系の全てのリソースに対し、以下のように定義できます。
Allow 'A-Domain'/'A-Admins' to manage virtual-network-family in compartment Project-A
主なファミリー・リソース一覧
| ファミリー・リソース名 | 用途 |
|---|---|
| all-resources | 全てのOCIリソース |
| cluster-family | Kubernetes（OKE） |
| compute-management-family | インスタンス構成、インスタンス・プール |
| database-family | データベース |
| dns | DNS |
| email-family | Email Delivery |
| file-family | ファイル・ストレージ |
| instance-family | コンピュート・インスタンス |
| object-family | オブジェクト・ストレージ |
| volume-family | ブロック・ボリューム、ブート・ボリューム等 |
※IAM はファミリー・リソースには含まれておらず、個々のリソース・タイプとして定義する必要があります。
その他のリソースについては以下ドキュメントをご覧ください。
場所（Location）
場所（Location）は「どの範囲で」実行できるかを定義します。
ここではコンパートメントまたはテナンシへのアクセスの範囲を指定します。
OCI では 組織のセキュリティ管理を適切に行うため、明確なスコープを定義することが重要です。特に、ポリシーの影響範囲を誤って広く設定すると、意図しないアクセス許可が発生する可能性があります。
1.テナンシ全体へのアクセス許可
テナンシ全体に対してアクセス制御を実施する場合、tenancyを場所として使用します。
Allow 'A-Domain'/'A-Admins' to manage all-resources in tenancy
2.特定のコンパートメントへのアクセス許可
特定のコンパートメント（ここでは「Project-A」）を指定してアクセスを制御する場合、以下のように定義します。
Allow 'A-Domain'/'A-Admins' to manage all-resources in compartment Project-A
なお、 OCI ではコンパートメントの継承が適用され、指定したコンパートメント配下の子コンパートメントにも自動的に権限が継承されます。この点に注意してポリシーを設定してください。
また、 複数のコンパートメントを1つのステートメントで定義することはできません。各コンパートメントに対して個別のステートメントを作成する必要があります。
Allow 'A-Domain'/'A-Admins' to manage all-resources in compartment Project-A
Allow 'A-Domain'/'A-Admins' to manage all-resources in compartment Project-B
3. コンパートメントの OCID を使用する
主体（Subject）と同様に、 コンパートメントの OCID を指定することも可能です。
Allow 'A-Domain'/'A-Admins' to manage all-resources in compartment id ocid1.compartment.oc1..aaaaaaaaexampleocid
4. 特定のリージョンまたは可用性ドメインの指定
特定のリージョンや可用性ドメインを場所として制限したい場合、 条件（Conditions） を使用して制御可能です。
※条件については後日投稿する記事で紹介します。
Allow 'A-Domain'/'A-Admins' to manage all-resources in tenancy where request.region = 'NRT' # 東京リージョンの場合
Allow 'A-Domain'/'A-Admins' to manage all-resources in tenancy where request.ad = 'AD1' # AD-1の場合
エラー：「Compartment does not exist or not part of the policy compartment subtree」について
ポリシーの作成時に以下のエラーが発生する場合があります。
このエラーについて、以下の原因によって発生する可能性があります。
- コンパートメント自体がそもそも存在しない
- IAMポリシーを作成するコンパートメントの子コンパートメントではない
2.の場合、 コンパートメントのパスをコロン（:）で区切って指定 することで、正しく定義できます。
Allow 'A-Domain'/'A-Admins' to manage all-resources in compartment Project-A:System-A:Team-A
この方法を活用することで、IAM ポリシーの適用範囲を明確に設定し、誤ったアクセス許可を防ぐことが可能です。
OCI 環境を適切に管理するために、 必要最小限のスコープを意識しながらポリシーを定義すること をおすすめします。
最後に
IAMポリシーは、OCIのアクセス管理において重要な役割を果たします。
本記事では、IAMポリシーの基本構成要素を解説し、適切な設定や注意点について説明しました。
適切なポリシー設計により、セキュアかつ効率的なOCI環境の管理が可能になります。
尚、IAM ポリシーの詳細の記事については後日投稿しますのでお楽しみに！
以上となります。
この記事を通じて読者の皆様の問題解決の一助となれば幸いです。
最後まで読んで頂き、ありがとうございましたm(_ _)m