OCI IAM

解決する課題

• 全員がテナンシ管理者、では事故が起きる → 必要な人に必要な権限だけ渡したい
• リソースをチーム・環境ごとに分離したい → コンパートメントで論理的に区切り、境界に権限を付ける
• インスタンスやFunctionにキーを埋め込みたくない → インスタンスプリンシパル/リソースプリンシパルで安全に
• 監査で「誰が何をできるか」を説明したい → ポリシーは英語ライクな文で記述でき可読性が高い

主要概念と用語

• テナンシ（Tenancy）: OCI アカウントのルートに当たる最上位コンテナ。ルートコンパートメントを内包する
• コンパートメント（Compartment）: リソースを入れる論理的な箱。ポリシーを当てる主な境界で、最大6階層までネスト可能。リージョンをまたいでグローバルに存在する
• アイデンティティドメイン（Identity Domain）: ユーザー／グループ／認証設定（MFA・フェデレーション・サインオンポリシー）を束ねる入れ物。OCI 版 IDaaS（旧 Oracle Identity Cloud Service の後継）
• ユーザー / グループ: 人やアプリに紐づく ID と、その束。権限はグループ単位で付与するのが基本
• ポリシー（Policy）: Allow <group> to <verb> <resource-type> in <compartment> [where <condition>] という構文で許可を記述。**OCI のポリシーは「許可（Allow）のみ」**で、明示的 Deny 文は書かない（デフォルト全拒否）
• 動的グループ（Dynamic Group）: ユーザーではなくリソース（インスタンス等）をメンバーにするグループ。ルールにマッチした計算リソースに権限を渡せる
• プリンシパル: 認証主体。ユーザー（人）、インスタンスプリンシパル、リソースプリンシパル（Functions など）の3種が代表

仕様・制限・クォータ

• IAM はグローバル（ホームリージョンで管理。ユーザー/グループ/ポリシーは全リージョンに伝播）。テナンシ作成時に選んだホームリージョンでのみ IAM の書き込みができる
• ポリシーはコンパートメント単位でアタッチし、サブコンパートメントへ継承される（上位で許可した権限は下位にも及ぶ）
• ポリシー文の動詞は粒度の粗い順に inspect < read < use < manage の4段階。リソース種別ごとに対応する API 操作がマッピングされている
• ポリシーには**条件（where）**を付けられる（例: request.region、target.compartment.name、特定タグの有無など）
• フェデレーション: アイデンティティドメインは SAML 2.0 / OpenID Connect に対応し、Microsoft Entra ID 等の外部 IdP と連携できる
• 主な上限の目安（テナンシ既定、引き上げ申請可）: コンパートメント階層 6 レベル、ポリシー/グループ/ユーザー数などにサービス制限あり

内部の仕組み

API リクエストが来ると、OCI は次のように認可を評価します。

1. デフォルトは全拒否（どのポリシーにも該当しなければ拒否）
2. リクエスト元グループ・対象リソース種別・対象コンパートメントに一致するポリシー文（Allow）があれば許可
3. ポリシーの継承により、対象コンパートメントの祖先コンパートメントに書かれた Allow も評価対象になる
4. where 条件があれば、リクエスト属性（リージョン・タグ等）が条件を満たす場合のみ許可

設計パターン / ベストプラクティス

• 最小権限の原則: グループ × コンパートメント × 動詞（read/use/manage）を必要最小限に絞る
• コンパートメント設計を先に: 環境（dev/stg/prod）やチームでコンパートメントを切り、境界にポリシーを当てる。これが OCI の権限設計の核
• 動的グループ + インスタンス/リソースプリンシパル: Compute や Functions にはキーを置かず、動的グループ経由で権限を付与する
• グループに権限、ユーザーは権限を直接持たせない: 権限はグループ単位、人の入れ替えはグループのメンバー変更で対応
• 管理者の最小化: テナンシ管理者（Administrators グループ）は緊急時のみ。日常は用途別の管理グループへ委譲

運用・監視・トラブルシュート

• OCI Audit で「誰がいつ何の API を呼んだか」をテナンシ全体で記録（既定で有効）
• Cloud Guard で過剰権限・公開リソース・設定ミスを検出し、自動レスポンスを設定
• 権限エラー（NotAuthorizedOrNotFound が典型）が出たら、グループ所属 → 対象コンパートメント → ポリシー文の動詞/リソース種別 → where 条件の順に確認
• ポリシーの効果確認には、ポリシー文の対象を絞ってテストし、Audit ログで実際の許可/拒否を突き合わせる

コスト

IAM 自体は無料。アイデンティティドメインも基本機能（OCI 操作のための認証認可）は追加料金なしで、追加のアプリ連携や高度な機能を使う上位タイプのみ課金されます。

セキュリティ

• MFA を必須化: アイデンティティドメインのサインオンポリシーで、特に管理者に多要素認証を強制
• 長期 API キーよりプリンシパル認証: Compute はインスタンスプリンシパル、Functions はリソースプリンシパルを使い、~/.oci の鍵配布をなくす
• 条件で締める: ポリシーの where で request.region や送信元・タグを縛り、適用範囲を限定
• フェデレーションで一元管理: 既存の IdP（Entra ID 等）と SAML/OIDC 連携し、人の ID を社の認証基盤に集約

関連サービス・比較（AWS との対応）

ハンズオン / CLI例

# 1) グループを作成（--compartment-id にはテナンシOCIDを指定）
oci iam group create \
  --name app-readers \
  --description "Read-only group for app team" \
  --compartment-id $OCI_TENANCY

# 2) ポリシーを作成：app-readers に dev コンパートメント内の
#    オブジェクトストレージを read だけ許可（OCIポリシーはAllow文の配列）
oci iam policy create \
  --name app-readers-policy \
  --description "Allow read on object storage in dev" \
  --compartment-id $OCI_TENANCY \
  --statements '["Allow group app-readers to read object-family in compartment dev"]'

# 3) 動的グループを作成：dev コンパートメント内の全インスタンスをメンバーに
oci iam dynamic-group create \
  --name dev-instances \
  --description "All compute instances in dev compartment" \
  --matching-rule "ALL {instance.compartment.id = '$DEV_COMPARTMENT_OCID'}"

# 4) インスタンスプリンシパルで認証して自分の権限主体を確認（鍵不要）
#    Compute インスタンス上で実行する
oci os ns get --auth instance_principal