iam-identity-management

OCI IAM とアイデンティティ管理 - エキスパート向け知識

🏗️ OCI Landing Zone Terraform モジュールを使用する

一から作り直す必要はありません。 IAM 構造には oracle-terraform-modules/landing-zone を使用してください。

Landing Zone で解決できること：

• ❌ 悪い慣行 #1：フラットなコンパートメント（Landing Zone は階層構造を提供します）
• ❌ 悪い慣行 #2：日常業務での管理者権限の使用（Landing Zone は最小権限を徹底します）
• ❌ 悪い慣行 #6：IAM ポリシーの手動管理（Landing Zone は CIS 準拠の IaC を提供します）

このスキルが提供するもの：Landing Zone 内にデプロイされたリソース向けの IAM 構文、トラブルシューティング、ポリシーパターンです。

---

⚠️ OCI CLI/API に関する知識の不足

OCI CLI コマンドや OCI API の構造については把握していません。

トレーニングデータに含まれる以下の知識は限られており、古くなっている可能性があります。

• OCI CLI の構文とパラメーター（月次で更新されます）
• OCI API エンドポイントとリクエスト／レスポンスの形式
• IAM サービスの CLI 操作（oci iam policy、oci iam dynamic-group）
• ポリシーの動詞とリソースの組み合わせ（OCI 固有のもので、AWS／Azure のものとは異なります）
• 最新の IAM 機能と Identity Domains

OCI の操作が必要な場合：

1. このスキルのリファレンスに記載された正確な CLI コマンドを使用してください
2. OCI IAM ポリシーの構文を推測しないでください
3. AWS／Azure の IAM パターンが OCI でも使えると決めつけないでください
4. IAM ポリシーの詳しいドキュメントについては、リファレンスファイルを読み込んでください

把握していること：

• 一般的な IAM の概念（プリンシパル、ポリシー、グループ）
• ロールベースのアクセス制御の原則
• 最小権限のセキュリティ概念

このスキルは、最新の OCI 固有の IAM パターンと構文を提供することで、この不足を補います。

あなたは OCI IAM のエキスパートです。このスキルは、Claude が把握していないポリシー構文の注意点、権限のトラブルシューティング、動的グループのパターン、OCI 固有の IAM 運用知識を提供します。

絶対にしてはいけないこと

❌ 範囲が広すぎるポリシーは絶対に使用しないでください（セキュリティリスク）

# WRONG - grants admin access to everyone
Allow any-user to manage all-resources in tenancy

# WRONG - too broad for production
Allow group Developers to manage all-resources in compartment Production

# RIGHT - least privilege, specific resources
Allow group AppDevelopers to manage instance-family in compartment AppDev where target.instance.name =~ 'dev-*'

❌ ポリシーでコンパートメント階層を絶対に忘れないでください

# WRONG - policy in child compartment can't access parent resources
Policy location: Compartment A/B/C
"Allow group X to read buckets in compartment A"  # Fails! Policy must be in A or above

# RIGHT - policy must be at or above target location
Policy location: Compartment A (or root)
"Allow group X to read buckets in compartment A"

❌ プリンシパルの種類を絶対に取り違えないでください（「not authorized」エラーの原因になります）

# WRONG - instance is NOT a user
Allow user <instance-ocid> to read buckets in compartment X

# RIGHT - use dynamic group for instances
Allow dynamic-group app-instances to read buckets in compartment X

❌ 動的グループのルールにリソース OCID を絶対にハードコードしないでください

# WRONG - not scalable, breaks when instance replaced
ALL {instance.id = 'ocid1.instance.oc1.phx.xxxxx'}

# RIGHT - use compartment or tag matching
ALL {instance.compartment.id = '<compartment-ocid>'}
ANY {instance.freeform-tags.environment = 'production'}

❌ 循環するポリシー依存関係は絶対に作成しないでください

# WRONG - Group A needs policy to manage Group B, but Group B policy grants access to Group A
# Creates deadlock where neither can be created first

# RIGHT - use separate administrative groups with clear hierarchy

❌ 本番環境のポリシーで「any-user」を絶対に使用しないでください（セキュリティ監査に失敗します）

# WRONG - grants access to ALL users including future unknown users
Allow any-user to read buckets in tenancy

# RIGHT - explicit group membership
Allow group DataReaders to read buckets in compartment SharedData

コストへの影響：SOC2／HIPAA 監査でコンプライアンス違反が指摘されると、1 件あたり 10,000 ドル以上

IAM 権限のトラブルシューティング

「404 - NotAuthorizedOrNotFound」

このエラーは、次のいずれかを意味します。

1. リソースが存在しない
2. ユーザーに、リソースの存在を確認する権限がない

トラブルシューティングの判断ツリー：

404 NotAuthorizedOrNotFound?
│
├─ Does resource definitely exist?
│  ├─ YES → Permission issue
│  │  └─ Check: Does user have 'inspect' or 'read' permission?
│  │     └─ Check: Is policy in correct compartment (at or above target)?
│  └─ NO → Resource doesn't exist
│     └─ Verify OCID, compartment, region
│
├─ Using dynamic group/instance principal?
│  └─ Check: Is instance in dynamic group?
│     └─ `oci compute instance get --instance-id <ocid>` (shows compartment, tags)
│     └─ Verify matching-rule matches instance properties
│
└─ Cross-compartment access?
   └─ Policy must be in compartment that CONTAINS both source and target
      OR in root compartment

「403 - NotAuthorized」

明確なアクセス拒否です。 ユーザー／プリンシパルは識別されていますが、必要な権限がありません。

よくある原因：

1. 動詞が不足している：ポリシーには read があるものの、操作には use または manage が必要
2. リソースタイプが間違っている：ポリシーで instance-family の権限を付与しているが、volume-family にアクセスしようとしている
3. 条件が一致しない：ポリシーに where target.instance.name = 'prod-*' があるものの、インスタンス名が dev-web-1
4. ポリシーがまだ有効になっていない：ポリシーの反映には 10～60 秒かかります

動詞の階層（それぞれ、下位の権限をすべて含みます）：

inspect < read < use < manage

ポリシー構文の注意点

リソースタイプファミリー（よく混同されます）

ファミリー	含まれるリソース	よくある間違い
instance-family	instances、instance-consoles、instance-console-connections、vnics、vnic-attachments	volumes も含まれると思い込む（含まれません）
volume-family	volumes、volume-backups、volume-attachments	instances とは別です
object-family	buckets、objects	オブジェクトは別のリソースです
database-family	db-systems、databases、autonomous-databases	範囲が非常に広い
all-resources	すべて	慎重に使用してください - セキュリティリスク

場所の構文

# Compartment (specific)
in compartment <compartment-name or ocid>

# Compartment + descendants
in compartment <compartment-name> where target.compartment.id = <ocid>

# Tenancy (root)
in tenancy

# Specific resource (rare, for delegation)
in resource <resource-ocid>

条件（WHERE 句）

# Tag-based conditions
where target.resource.tag.environment = 'production'
where target.resource.freeform-tags.CostCenter = 'Engineering'

# Resource name patterns
where target.instance.name =~ 'web-*'  # Regex match

# Request properties
where request.operation = 'LaunchInstance'
where request.region = 'us-phoenix-1'

# Multiple conditions
where all {target.resource.tag.env = 'prod', target.compartment.name = 'AppProd'}
where any {target.instance.shape = 'VM.Standard.E4.Flex', target.instance.shape = 'VM.Standard.A1.Flex'}

動的グループのパターン

マッチングルールのベストプラクティス

コンパートメント単位（最も一般的）：

ALL {instance.compartment.id = '<compartment-ocid>'}

タグ単位（柔軟）：

ANY {instance.freeform-tags.app = 'webserver'}

複数の条件による指定（制限的）：

ALL {instance.compartment.id = '<comp-ocid>', instance.freeform-tags.environment = 'production'}

よくある間違い：instance.compartment.id（コンパートメント内のすべてのインスタンス）ではなく、instance.id（特定のインスタンス）を使用する

動的グループのメンバーシップのテスト

# 1. Get instance details to see compartment/tags
oci compute instance get --instance-id <instance-ocid>

# 2. Check dynamic group matching rule
oci iam dynamic-group get --dynamic-group-id <group-ocid>

# 3. Verify rule matches instance properties
# Example: If rule is "instance.compartment.id = X"
# Check instance's compartment_id matches X

# 4. Test with actual API call from instance
# SSH to instance and run:
oci os ns get  # Should work if instance principal configured correctly

コンパートメント戦略のアンチパターン

❌ 誤り：フラットな構造（整理されていない）

Tenancy
├─ Application1  (mix of dev/test/prod)
├─ Application2  (mix of dev/test/prod)
└─ SharedServices

✅ 正しい：環境ベースの階層構造

Tenancy
├─ Production
│  ├─ App1
│  └─ App2
├─ Development
│  ├─ App1
│  └─ App2
└─ SharedServices
   ├─ Networking
   └─ Security

メリット：IAM の境界が明確になり、環境ごとのコストをレポートでき、影響範囲を限定できます

認証方法（それぞれの使いどころ）

方法	ユースケース	メリット	デメリット
API キー	ローカル開発、OCI 外部の CI/CD ランナー	シンプルで持ち運び可能	手動でのローテーション、キー管理
インスタンスプリンシパル	OCI コンピュート上のアプリ	認証情報不要、自動ローテーション	OCI コンピュート上でのみ動作
リソースプリンシパル	OCI Functions、Data Flow	サーバーレス認証	特定のサービスに限定
セッショントークン	IDCS 経由のコンソールフェデレーション	SSO、MFA	有効期間が短く、セットアップが複雑

IDCS 統合時の注意点

フェデレーションのセットアップ（OCI + IDCS）：

• IDCS ユーザーはフェデレーションを介して OCI にマッピングされます
• IDCS のグループメンバーシップ → OCI のグループマッピング
• 重要：OCI のグループ名は IDCS のグループ名と完全に一致している必要があります

よくある問題：

• ユーザーはコンソールにログインできるが、リソースが表示されない → フェデレーショングループに対する OCI IAM ポリシーが不足しています
• 「Invalid credentials」 → OCI テナンシーで IDCS フェデレーションが設定されていません
• グループメンバーシップが同期されない → OCI のグループ名が IDCS のグループ名と一致していません

参考資料の段階的な読み込み

OCI IAM ポリシーのリファレンス（Oracle 公式ドキュメント）

次の場合に読み込みます oci-iam-policies-reference.md：

• IAM ポリシーの構文と例を網羅的に確認する必要がある
• 条件付きの複雑なポリシーを記述する
• サービス固有の動詞と権限を理解する
• 最小権限アクセスのパターンを実装する
• ポリシーの評価順序をトラブルシューティングする

次の場合は読み込まないでください：

• ポリシー構文の簡単な例（このスキルで説明しています）
• 一般的な権限パターン（上記の判断ツリーを参照）
• 動的グループのルール（このスキルで説明しています）

---

このスキルを使う場面

• IAM ポリシーの作成：構文、動詞の選択、条件
• トラブルシューティング：403/404 エラー、認可の失敗、権限のデバッグ
• 動的グループ：マッチングルール、メンバーシップのテスト、インスタンスプリンシパル
• コンパートメント戦略：階層設計、ポリシーの配置
• IDCS 統合：フェデレーションのセットアップ、グループマッピング、SSO のトラブルシューティング