OCI入門 Vol2 IAM入門 Identity Domains・ポリシー・ダイナミックグループ

1. この記事について — OCIの権限設計へ踏み込む

1-1. 本記事の位置づけ — Vol1の続きとして

OCI入門シリーズVol1では、テナンシとコンパートメントというOCIアカウントの器の構造、そしてリージョン・アベイラビリティドメイン(AD)・フォルトドメイン(FD)という物理配置の考え方を整理しました。テナンシ・コンパートメントの階層設計やAlways Free枠の詳細については、Vol1で解説済みのため本記事では改めて扱いません。

器の形が整った次に問われるのは、その器の中で「誰が、何を、どこまで操作できるか」を定義する権限管理です。本記事ではOCIのIAM(Identity and Access Management)機能を取り上げ、その中核であるIdentity Domains、ユーザーとグループ、ポリシーの文法、ダイナミックグループという4つの要素を順に解説します。テナンシやコンパートメントの階層設計そのものを見直したい場合は、Vol1を参照してください。

どれほど精緻にコンパートメントを設計しても、そこに適切な権限管理を組み合わせなければ、意図しないユーザーが本番環境のリソースを操作できてしまうといった事態を防げません。Vol1で整えた器の中身を安全に保つには、「誰が」「何を」「どこまで」操作できるかを明確に定義するIAMの設計が欠かせません。本記事は、この権限設計の入口として、OCIのIAMを構成する主要な要素を一つずつ解説していきます。

1-2. AWS IAMとの発想の違い(本記事の軸)

AWSの実務経験がある方にとって、OCIのIAMは似て非なる設計に見えるはずです。AWS IAMでは、IAMユーザー・IAMロール・JSON形式のポリシー、そしてPassRoleやAssumeRoleによるロールの受け渡しが中心的な概念になります。

一方OCIでは、ユーザーとグループを内包する「Identity Domain」という認証境界のもとで、ポリシーは「Allow group Admins to manage instances in compartment X」のような英語の自然文に近い構文で記述します。またAWSのインスタンスプロファイルに相当する仕組みは、OCIでは「ダイナミックグループ」というmatching ruleに基づく動的なグルーピングで実現します。この発想の違いを軸に、§2以降で一つずつ掘り下げていきます。

具体的には、AWSのIAMユーザー・IAMロールに相当する概念としてOCIのユーザーとグループがあり(§3)、AWSのJSON形式のIAMポリシーに相当する概念としてOCIの英語風ポリシー構文があります(§4)。さらに、AWSのインスタンスプロファイルやAssumeRoleによる一時的な権限付与に相当する概念として、OCIのダイナミックグループとインスタンスプリンシパルがあります(§5)。似た目的を持ちながらも文法や運用の勘所が異なるため、それぞれの対応関係を意識しながら読み進めることをお勧めします。

1-3. 本記事で扱う範囲・扱わない範囲

本記事は、OCIのIAM機能であるIdentity Domains、ユーザーとグループ、ポリシーの英語風構文、ダイナミックグループの4点を中心に扱います。

一方、次の内容についてはすでに前巻(Vol1)で解説済み、または次巻以降で扱う予定のため、本記事では扱いません。

• テナンシ・コンパートメントの階層設計(前巻Vol1)
• リージョン・アベイラビリティドメイン(AD)・フォルトドメイン(FD)の物理配置(前巻Vol1)
• Always Free枠の詳細(前巻Vol1)
• VCN(仮想クラウドネットワーク)などのネットワーキング(次巻Vol3以降)

まずは本記事で、OCIの権限管理の全体像を掴んでいただければと思います。

1-4. 読み進め方 — AWSの知識を橋渡しに

本記事は、§2でOCI IAMとAWS IAMの概念対応マップを俯瞰した後、§3でユーザーとグループ、§4でポリシー構文、§5でダイナミックグループという順に、個々の要素を掘り下げていく構成です。各章では、対応するAWSの仕組みを都度示しながら解説を進めるため、AWSでの実務経験を手がかりにOCIのIAMを理解していただけます。

AWSの経験がない方でも、対比元となるAWSの概念については各章で簡単に補足しますので、本記事単体でも読み進めていただけます。

対比を軸に読み進めるメリットは、単に用語を覚える手間を減らせることだけではありません。「AWSではこう設計していたから、OCIでも近い考え方が使えるはずだ」という仮説を持って読み進められるため、細部の違いに気づいたときの理解の定着も早くなります。それでは、まずOCI IAMとIdentity Domainsの全体像から見ていきましょう。

← 前巻: OCI入門 Vol1 アカウント設計の基礎(テナンシ・コンパートメント・リージョン)

2. OCI IAMとIdentity Domains — 権限管理の全体像

2-1. Identity Domainsとは — IDCS統合で刷新された現行世代

OCI IAMの現在の中核をなす概念が「Identity Domain」です。Identity Domainは、テナンシ内のプリンシパル(ユーザーやグループ)を区切って管理するためのコンテナであり、認証情報のポリシー、多要素認証(MFA)、SSO(シングルサインオン)の設定などをドメイン単位で保持します。

Identity Domainsは、2023年3月から順次適用されたIDCS(Oracle Identity Cloud Service)統合によって刷新された、現行世代の枠組みです。この統合により、従来IDCSという独立したサービスが担っていたユーザー管理・フェデレーション・SSO関連の機能がOCI IAMへネイティブに統合され、IDCSは独立したサービスとしては提供されなくなりました。統合後は、既存のIDCSインスタンスがそのままidentity domainとして引き継がれ、ユーザー・グループ・ポリシー・各種設定はそのまま維持されます。

IDCSからidentity domainへの移行は、テナンシごとにリージョン単位で、事前に2週間程度の通知を経てシームレスに実施されました。移行時期についてはすでに完了しているため、現在OCIでアカウントを新規作成すると、最初から現行のIdentity Domainsとして提供されます。

ネイティブなOCIサービスとして統合されたことで、性能とスケーラビリティの向上に加えて、グローバルなリージョンへの即時展開、クロスリージョンでの災害復旧(DR)機能といった強化が図られています。テナンシには自動的に「デフォルトドメイン」と呼ばれるIdentity Domainがルートコンパートメント内に作成され、このデフォルトドメインはテナンシのライフサイクルと結びついており削除できません。必要に応じて、開発用・本番用などの目的別に追加のIdentity Domainを作成し、ユーザーの母集団を分離できます。

なお、本記事で扱うIdentity Domainsは、2023年のIDCS統合以降の現行世代を前提としています。統合以前の古いドキュメントや記事に見られる記述とは仕様が異なることもあるため、実務で参照する際は必ず公式ドキュメントの最新版でご確認ください。

たとえば、複数の事業部を持つ企業がOCIを利用する場面を考えてみます。多くの企業では、まずデフォルトドメインの中に全社員のユーザーとグループを作成し、ポリシーで各コンパートメントへの権限を制御するというシンプルな構成から始めます。開発環境と本番環境でユーザーの母集団やセキュリティポリシー(パスワード要件やMFAの必須化など)を明確に分けたいという要件が出てきた段階で、目的別に追加のIdentity Domainを作成し、ドメイン単位で管理を分離する構成へ移行するのが一般的な流れです。

2-2. IDCS統合が実務にもたらした変化

2023年のIDCS統合は、既存のOCI利用者にとって「見た目や操作性は大きく変わらないが、管理体系が刷新された」という変化として現れました。統合前は、IDCSインスタンスの管理画面とOCIコンソールのIAM画面が別々のシステムとして存在し、両者を行き来しながら設定する必要がありました。統合後は、OCIコンソールの「Identity & Security」配下にIdentity Domainsの管理画面が統合され、単一のコンソール(single pane of glass)からユーザー・グループ・ポリシー・セキュリティ設定をまとめて管理できるようになりました。

この統合にあたっては、既存のアプリケーション連携・ユーザー・グループ・ポリシー・各種設定を利用者側で作り直す必要はなく、既存のIDCSインスタンスの設定内容がそのままidentity domainへ引き継がれました。移行はテナンシ単位・リージョン単位で自動的に実施されており、利用者側で移行作業そのものを行う必要はありませんでした。

このため、2023年より前に書かれたOCI関連のドキュメントやブログ記事では、「IDCS」という独立したサービス名や、それに紐づく個別の管理コンソールへの言及を見かけることがあります。現在のOCI環境ではこれらは統合済みのIdentity Domainsとして扱われているため、古い記事を参照する際は、記載されている操作画面や用語が現行のコンソールと異なる可能性がある点に注意が必要です。実務で手順を確認する際は、必ず公式ドキュメントの最新版を参照することを推奨します。

ここまでの用語を整理すると、次のとおりです。

2-3. Identity Domainとホームリージョンの関係

前巻(Vol1)の§3-2で触れたとおり、テナンシには「ホームリージョン」と呼ばれる、IAMリソースのマスター定義を置くリージョンが1つ存在します。Identity Domainも同様にホームリージョンでマスターとして管理され、テナンシがサブスクライブしている他のリージョンには自動的に複製されます。ユーザー・グループ・ポリシーを変更できるのはホームリージョン側のみで、登録リージョン側では参照のみとなる点は、Vol1で説明したIAMリソース全般の挙動と共通しています。

AWSのIAMは元来グローバルサービスとして扱われ、IAMユーザーやポリシーはリージョンを問わず単一のグローバルなデータストアで管理されます。一方OCIのIdentity Domainは、リージョンごとに存在するOCIのサービス構成に合わせて、ホームリージョンでマスター管理しつつ登録リージョンへ複製するという設計です。マルチリージョン展開を検討する際は、AWSのようにIAMをリージョン非依存として扱うのではなく、OCIではホームリージョンが単一障害点になり得る点を意識しておくとよいでしょう。この設計は、前巻(Vol1)の§3-2で扱ったホームリージョンの重要性(後から変更できない点を含む)が、コンパートメントだけでなくIdentity Domainにも同様に当てはまることを示しています。

ネイティブなOCIサービスとして刷新されたことで、Identity Domainsは新しいリージョンが追加された際にもすぐに利用できるようになり、また複数リージョンにまたがる災害復旧(クロスリージョンDR)の構成もサポートされています。東京リージョン(ap-tokyo-1)を含む主要リージョンでは、Identity Domainsは通常のOCIリソースと同様に利用可能です。ただし、個別の新機能がどのリージョンから展開されるかは変わる可能性があるため、特定の機能を前提に設計する場合は公式ドキュメントで対象リージョンの提供状況を確認することを推奨します。

2-4. Identity Domainのタイプ — Free・Oracle Apps Premium・Premium・External User

Identity Domainには、利用目的に応じて次の4種類のタイプが用意されています。

テナンシ作成時に自動的に用意されるデフォルトドメインはFreeタイプですが、必要に応じて追加のドメインを異なるタイプで作成し、用途ごとに使い分けることもできます。各タイプで利用できる機能や上限は変更される可能性があるため、実際の要件に応じて公式ドキュメントの最新情報を確認することを推奨します。

たとえば、オンプレミスでOracle E-Business Suiteを運用しながら、認証基盤だけをOCI側のIdentity Domainに統合したい場合には、Oracle Apps Premiumタイプのドメインが選択肢になります。Freeタイプのドメインは追加の課金なしで利用できますが、Premium・Oracle Apps Premium・External Userタイプのドメインでは、アクティブユーザー数などに応じて課金は発生する場合があります。具体的な料金体系は変更される可能性があるため、必要な機能とコストのバランスは公式の価格情報に応じて確認することをお勧めします。

AWS IAMには、ドメイン(≒認証境界)自体を用途別のタイプで分けるという概念はありません。OCIでハイブリッドなOracleアプリケーション連携や消費者向けID管理を検討する場合は、通常の従業員向けIAM(Premiumタイプ)とは異なるドメインタイプの検討が必要になる点を覚えておくとよいでしょう。

2-5. AWS IAMとOCI IAMの概念対応マップ

ここまでの内容を踏まえ、AWS IAMとOCI IAMの主要な概念を対応表として整理します。

この対応表もVol1同様、厳密な1対1ではなく「近い概念」を並べたものです。特にAWSのIAMロールという概念は、OCIには直接対応する単一の仕組みがなく、ダイナミックグループ(§5)やグループへのポリシー付与という複数の仕組みの組み合わせで近い機能を実現します。この違いは§3-3と§5で改めて扱います。

なお、テナンシやコンパートメントといったOCIアカウントの器の構造自体は、Vol1で解説済みのため本記事では再説明しません。この対応表は、あくまで権限管理(IAM)の観点に絞った対比です。

権限スコープの考え方の違い

AWS IAMでは、ポリシーのResource要素にARNを指定することで、個々のリソース単位まで権限の対象を絞り込めます。一方OCIのポリシーでは、リソースの種類(resource-type)と、テナンシまたはコンパートメントという範囲(location)の組み合わせで権限を表現するのが基本であり、個々のリソースを名指しで指定する場面は多くありません。コンパートメントの設計(前巻Vol1)がそのまま権限のスコープ設計に直結するのは、この考え方の違いによるものです。この点は§4-3で改めて扱います。

「ロール」に対応する仕組みの分散

AWSのIAMロールは、人間のユーザーへの一時的な権限付与(AssumeRole)と、EC2インスタンスなどリソースへの権限付与(インスタンスプロファイル)という2つの目的を1つの仕組みでカバーしています。OCIではこの2つの目的が、グループ+ポリシー(人間向け、§3)とダイナミックグループ+インスタンスプリンシパル(リソース向け、§5)という別々の仕組みに分かれています。どちらが優れているというより、権限管理の設計思想が異なる点として押さえておくとよいでしょう。

SSOとフェデレーションの位置づけ

AWSでは、複数アカウントにまたがるSSO(シングルサインオン)やIDプロバイダー連携を、IAMとは別のサービスであるAWS IAM Identity Center(旧AWS SSO)が担います。一方OCIでは、SSOやSAML/OAuthによるフェデレーションの設定は、Identity Domain自体に組み込まれた機能として提供されます。別サービスを追加で有効化する必要がなく、Identity Domainの設定画面からユーザー管理と合わせて設定できる点が特徴です。

2-6. Identity Domainの構成要素

Identity Domainの内部には、次のような要素が含まれます。

• ユーザーとグループ(§3で詳しく扱います)
• OAuthやSAMLによるアプリケーション連携の設定
• MFA(多要素認証)やパスワードポリシーといったセキュリティ設定
• SSO(シングルサインオン)のための各種構成

前節で触れたとおり、テナンシには「Default」という名前のデフォルトドメインが自動的に用意されており、多くの小規模〜中規模の環境ではこのデフォルトドメインのみで運用が完結します。一方、開発環境と本番環境でユーザーの母集団(population)を明確に分離したい場合や、パートナー企業向けに別のセキュリティポリシーを適用したい場合には、追加のIdentity Domainを作成し、ドメインごとに異なるユーザー・グループ・セキュリティ設定を持たせることができます。

また、Identity Domain内のユーザーは、自身のプロフィール更新・パスワード変更・多要素認証(MFA)の設定などをセルフサービスで行えます。管理者がすべての設定変更を代行する必要がないため、ユーザー数が多い環境でも運用負荷を抑えられます。

セキュリティ設定の面では、パスワードの複雑性要件やMFAの必須化に加えて、ドメインタイプによってはリスクベース認証など、より高度なセキュリティ機能も利用できます。具体的にどの機能がどのドメインタイプで使えるかは変更される可能性があるため、要件を検討する際は公式ドキュメントで対象機能の対応状況を確認することを推奨します。

ドメインを分ける設計は、AWSでいう「アカウントを分けてIAMユーザーを分離する」という発想に近い側面がありますが、OCIではテナンシそのものを分けるのではなく、単一テナンシ内でIdentity Domainという単位を追加することで分離を実現する点が異なります。

2-7. 本章以降の道筋

ここまでで、OCI IAMの中核となるIdentity Domainsの全体像と、AWS IAMとの主な対応関係を確認しました。以降の章では、この全体像を構成する各要素を順番に掘り下げていきます。

§3 ユーザーとグループ

Identity Domain内でプリンシパル(ユーザー・グループ・ダイナミックグループ・サービス)がどのように権限管理の主体となるかを、AWSのIAMユーザー・グループとの対比を交えて解説します。

§4 ポリシー

「Allow subject to verb resource-type in location」という英語風の自然文構文と、inspect・read・use・manageというverbの4段階を、具体的な例とともに見ていきます。

§5 ダイナミックグループ

matching ruleによってコンピュートインスタンスなどのリソースを動的にグルーピングし、インスタンスプリンシパルとして認証させる仕組みを扱います。

§6・§7 実践とまとめ

§6ではここまでの要素を組み合わせた最小権限のIAM設計を、§7では本記事全体の振り返りと次巻(Vol3・ネットワーキング)への橋渡しをします。

それでは、まずユーザーとグループから見ていきましょう。

3. ユーザーとグループ — プリンシパルの管理

3-1. ユーザーとグループの基本

Identity Domain内での権限管理は、ユーザーとグループという2つの単位を組み合わせて行います。ユーザーはIdentity Domain内に作成する個々のアカウントで、コンソールへのログインやAPIキーの発行によってOCIリソースを操作する主体になります。グループは、複数のユーザーをまとめる論理的な集まりです。

OCIのIAM設計における基本原則は、個々のユーザーに直接ポリシーを紐付けず、必ずグループを経由して権限を付与することです。ユーザーを作成したら該当するグループに所属させ、そのグループに対してポリシーで権限を定義するという流れになります。この「ユーザーへの直接権限付与を避ける」考え方自体は、AWSでIAMユーザーに直接ポリシーをアタッチせずグループやロールを介して権限を管理する運用と同じ発想です。

ユーザーは複数のグループに所属でき、その場合は所属する全グループに定義されたポリシーの権限を合算して持つことになります。職務ごとにグループを分ける設計については、§6-1で改めて取り上げます。

3-2. プリンシパルという考え方

OCIのIAMでは、ポリシーの主体になり得るものを総称して「プリンシパル」と呼びます。プリンシパルには、ユーザー・グループ・ダイナミックグループ(§5)・サービスの4種類が含まれます。

§4で扱うポリシー構文のsubject(主語)の位置には、このプリンシパルのいずれかが入ります。つまり、ユーザーとグループを理解しておくことは、そのまま次章のポリシー構文を読み解く前提になります。プリンシパルという言葉自体は、AWSでもIAMユーザーやロールなど「認証された主体」を指す言葉として使われており、概念としては共通しています。

3-3. AWSとの違い — ロールの扱い

AWSのIAMには、ユーザーやグループとは別に「ロール」という仕組みがあり、AssumeRoleによって一時的に別の権限セットを引き受けたり、EC2インスタンスにロールを割り当てて権限を持たせたりします。

OCIのIAMには、AWSのIAMロールに1対1で対応する単体の概念はありません。その代わりに、次の2つの仕組みで同等の目的を実現します。

• 人間のユーザーに対する権限管理は、ユーザーをグループに所属させ、そのグループにポリシーで権限を付与する方法で行います
• コンピュートインスタンスなどのリソースに権限を持たせたい場合は、ダイナミックグループ(§5)という仕組みを使い、リソースを条件に基づいて自動的にグルーピングした上でポリシーを適用します

つまりOCIでは、「誰が(ユーザー/グループ)」と「何が(リソース)」のどちらが権限の主体になるかによって、グループとダイナミックグループという別々の仕組みを使い分けます。AWSのロールが両方の用途をカバーしているのに対し、OCIは主体の種類によって仕組みを分けている点が発想の違いです。ダイナミックグループの詳細は§5で扱います。

4. ポリシー — 英語風の自然文で権限を記述する

4-1. ポリシー構文の基本形

OCIのポリシーは、AWS IAMのようなJSON形式ではなく、英語の自然文に近い1行の文で権限を記述します。基本構文は次のとおりです。

Allow <subject> to <verb> <resource-type> in <location> [where <condition>]

subjectにはグループやダイナミックグループなどのプリンシパル(§3-2)、verbには後述する4段階の権限レベル、resource-typeにはインスタンスやバケットなどの操作対象、locationにはテナンシまたはコンパートメントを指定します。where以降の条件句は省略可能です。たとえば、開発者グループに対して開発用コンパートメント内のコンピュートインスタンスを操作できる権限を与える場合、次のように記述します。

Allow group Developers to manage instances in compartment Development

AWS IAMのJSONポリシーでは、Effect・Action・Resource・Conditionという要素を組み合わせて権限を表現しますが、OCIではこれらの要素が英語風の自然文の中で、verb・resource-type/location・where句としてそれぞれAction・Resource・Conditionに相当する形で組み込まれています。Effectに相当する要素は常に許可(Allow)であり、OCIには明示的な拒否(Deny)を記述するポリシーステートメントはありません。特定の対象を権限の範囲から除外したい場合は、locationの絞り込みやwhere句の条件で対応します。

4-2. verb の4段階 — inspect / read / use / manage

OCIのポリシーで指定するverbには、次の4種類があります。権限の強さはinspectからmanageに向かって段階的に大きくなり、上位のverbは下位のverbの権限を含みます。

この4段階は、AWS IAMのようにActionを個別のAPIオペレーション単位(例: s3:GetObject)で列挙する方式とは異なり、リソースタイプに対してまとまった権限レベルを指定する方式です。細かい操作単位での制御はできませんが、その分ポリシー文がシンプルになります。より細かい制御が必要な場合は、リソースタイプの選び方やwhere句の条件(§4-4)で調整します。

4-3. location とスコープ — tenancy と compartment

ポリシーが適用される範囲(スコープ)は、locationとしてtenancyまたはcompartment <name>のいずれかを指定します。in tenancyはテナンシ全体、つまり全コンパートメントにわたって権限が及ぶ範囲であり、in compartment <name>は指定した名前のコンパートメント配下に権限を絞り込む範囲です。

前巻(Vol1)で解説したコンパートメントの階層設計は、このlocationの絞り込みと直結します。コンパートメントを開発・検証・本番のように分けておけば、ポリシーのlocationをcompartment Developmentのように指定するだけで、権限の及ぶ範囲を必要なコンパートメントだけに限定できます。コンパートメント自体の設計方針については、前巻(Vol1)を参照してください。

最小権限の観点では、特別な理由がない限りin tenancyではなくin compartment <name>で権限範囲を絞り込むことが基本方針になります。テナンシ全体に権限を及ぼす設定は、管理者グループなど本当に必要な範囲に限定すべきです。

4-4. 条件(where)による絞り込み

ポリシー文の末尾には、where句を使って条件付きの権限を記述できます。たとえば、グループ名が特定の命名規則に合致するグループだけを操作対象にしたい場合、次のように記述します。

Allow group GroupAdmins to manage groups in tenancy where target.group.name = /A-Users-*/

この例では、GroupAdminsグループが「manage groups」の権限を持つものの、その対象はA-Users-という接頭辞に合致する名前のグループに限定されます。where句は、AWS IAMのポリシーにおけるCondition要素と役割が近く、タグの値や名前のパターンといった属性に基づいて権限の対象をさらに絞り込む用途で使います。where句で指定できる変数や比較演算子は多岐にわたるため、実装時には公式ドキュメントで具体的な指定方法を確認することを推奨します。

5. ダイナミックグループ — リソースの動的グルーピング

5-1. ダイナミックグループとは

AWSでEC2インスタンスにIAMロールを直接アタッチする感覚に近いものとして、OCIには「ダイナミックグループ」という仕組みがあります。ダイナミックグループは、ユーザーではなくコンピュートインスタンスやファンクションといったリソースを対象に、matching rule(マッチングルール)と呼ばれる条件式に基づいて動的にメンバーを決定するグループです。

通常のグループのようにメンバーを一件ずつ手動で登録する必要はありません。リソースが持つ属性(所属するコンパートメントのOCID、リソースの種類、付与されたタグなど)がmatching ruleの条件に合致していれば、そのリソースは自動的にダイナミックグループのメンバーとして扱われます。新しいインスタンスを追加してもルールの条件さえ満たしていれば自動的にメンバーへ組み込まれるため、リソースの増減が多い環境ほど運用の手間を減らせます。

5-2. matching rule の書き方

matching ruleは、対象とするリソースの属性を条件式として記述します。たとえば、特定のコンパートメントに配置されたコンピュートインスタンスをすべて対象にする場合、次のように記述します。

instance.compartment.id = 'ocid1.compartment.oc1..xxxxxxxxxx'

このルールは「instance.compartment.idが指定したコンパートメントのOCIDと一致するインスタンス」をメンバーとする、という意味です。複数の条件を組み合わせたい場合は、All{}やAny{}という演算子でAND条件・OR条件を表現できます。たとえば特定のインスタンスだけを除外したい場合や、複数のコンパートメントにまたがるインスタンスをまとめて対象としたい場合に使います。matching ruleの具体的な構文や指定できる属性の詳細は、実装時に公式ドキュメントで確認することを推奨します。

5-3. インスタンスプリンシパル — リソースが主体になる

matching ruleによってダイナミックグループのメンバーとなったリソースは、「インスタンスプリンシパル」としてOCIに対して自ら認証し、ポリシーで許可された範囲の権限を利用できるようになります。これは、AWSでEC2インスタンスにIAMロールをアタッチし、インスタンスプロファイルを介して一時的な認証情報を取得する仕組みと同じ発想です。

この仕組みを使うことで、インスタンスやアプリケーションの内部にAPIキーなどの認証情報を直接埋め込む必要がなくなります。キーをコード内やインスタンス内に保持しない設計は、キーの漏えいや流出によるリスクを避けるうえで重要です。リソースからOCIの他サービスを呼び出す構成を検討する際は、埋め込み型の認証情報ではなく、まずダイナミックグループとインスタンスプリンシパルの活用を検討するとよいでしょう。

5-4. ダイナミックグループへのポリシー付与

ダイナミックグループも、§4で説明したポリシー構文のsubjectとして指定できます。たとえば、あるダイナミックグループに対して特定コンパートメント内のクラスターを管理する権限を与えるポリシーは、次のように記述します。

Allow dynamic-group 'Default'/'DynamicGroupName' to manage clusters in compartment X

ユーザーやグループに対するポリシーとまったく同じ構文で、リソース側にも権限を付与できる点がOCIのポリシー体系の特徴です。ダイナミックグループへの権限付与も、§4-2で触れたverbの4段階(inspect/read/use/manage)とlocationの考え方がそのまま適用されるため、ここでも必要最小限のverbとlocationを選ぶことが基本になります。

6. 実践 — 最小権限のIAM設計

6-1. グループ設計 — 職務ごとに分離する

最小権限のIAM設計を実践する第一歩は、ユーザーを職務単位のグループに分割することです。たとえば「管理者」「開発者」「読み取り専用」のようにグループを分け、それぞれに必要なverbとlocationだけを許可するポリシーを個別に付与します。特定のグループに複数の職務を詰め込まず、グループ単位で役割を明確に分離しておくことが、後から権限を見直す際のしやすさにつながります。

なお、前巻(Vol1)の§7-2で触れたとおり、テナンシ管理者(Administratorsグループ)は強力な権限を持つため、日常運用では使用せず、専用の職務別グループで運用することが基本方針です。

6-2. コンパートメントスコープで権限を絞る

ポリシーのlocationにtenancy(テナンシ全体)ではなくcompartment (特定のコンパートメント)を指定することで、権限が適用される範囲を必要最小限に絞り込めます。前巻(Vol1)で設計したコンパートメント階層と組み合わせれば、「開発チームは開発用コンパートメントのみ操作できる」「本番環境のコンパートメントは運用担当グループのみが管理できる」といった権限設計が実現します。

コンパートメントの階層設計そのものの詳細は、前巻(Vol1)を参照してください。コンパートメントの切り方がそのままIAMポリシーの適用範囲の設計に直結するという関係は、Vol1と本記事を通じて繰り返し出てくる重要な考え方です。

6-3. ダイナミックグループでキーレス運用

コンピュートインスタンスやファンクションからOCIの他サービスを呼び出す構成を検討する際、認証情報(APIキーなど)をリソース内に直接埋め込むと、漏えい時の影響範囲が大きくなります。§5で説明したダイナミックグループとインスタンスプリンシパルを組み合わせることで、リソースにキーを持たせることなく、必要な権限だけを安全に渡せます。

新規にリソースからOCI APIを呼び出す設計をする場合は、キーの埋め込みを既定の選択肢にせず、まずダイナミックグループの活用を検討することをお勧めします。

6-4. IAM設計チェックリスト

最小権限のIAM設計に着手する際の初期チェックリストとして、次の項目を確認してください。

• 職務ごとにグループを分離しているか(管理者・開発者・読み取り専用など)
• ポリシーのlocationをtenancyではなくcompartmentに絞れないか確認したか
• テナンシ管理者(Administratorsグループ)を日常運用で使用していないか
• インスタンスやファンクションからのAPI呼び出しに、ダイナミックグループを活用できないか
• where条件による絞り込みの必要な操作がないか確認したか

これらは最低限の初期チェック項目であり、実際の組織のセキュリティ要件やガバナンス方針に応じて、公式ドキュメントも参照しながら適宜見直すことを推奨します。

7. まとめ — OCI IAMの基礎と次のステップ

7-1. 本記事の振り返り

本記事では、OCIの権限設計を支える4つの柱を確認してきました。まず、2023年のIDCS統合によって刷新された現行世代の権限管理基盤であるIdentity Domainsです。次に、ユーザーとグループというプリンシパルの管理単位で、AWS IAMと同様に権限はグループ単位で付与するのが基本という点を押さえました。続いて、「Allow subject to verb resource-type in location」という英語風の自然文で権限を記述するポリシー構文と、inspect・read・use・manageという4段階のverbによる権限の粒度分けを見てきました。そして、matching ruleによってコンピュートインスタンスなどのリソースを自動的にグルーピングし、インスタンスプリンシパルとして認証させるダイナミックグループです。

いずれの仕組みも、AWS IAMのユーザー・ロール・JSONポリシー・インスタンスプロファイルとは発想は異なるものの、「誰(あるいは何)が」「何に対して」「どこまでの権限を」持つかを定義するという目的は共通しています。Vol1で学んだテナンシとコンパートメントという器に対して、本記事で学んだIAMが「誰が何をできるか」を定義する、という関係を押さえておくと、OCI全体の設計思想が見通しやすくなります。

7-2. 次のステップ — ネットワーキングへ

OCI入門シリーズは、Vol1でアカウントの器(テナンシ・コンパートメント・リージョン)を学び、Vol2となる本記事で権限設計(IAM)を学びました。次巻のVol3では、いよいよネットワーキング(VCN)に踏み込みます。コンパートメント・IAM・ネットワークの3要素がそろって初めて、OCI上に安全なワークロードを構築する土台が完成します。引き続き、AWSでの経験を手がかりにOCIの発想の違いを確認しながら、学習を進めていきましょう。

← 前巻: OCI入門 Vol1 アカウント設計の基礎

→ 次巻: OCI入門 Vol3 ネットワーキング(VCN)