AWS IAMとOCI IAMを比較してみる – 実際のコード例で学ぶ権限設定の違い

Posted at 2025-08-27

1.はじめに

AWSのIAMに慣れ親しんだエンジニアにとって、OCIのIAMは似ているようで異なる概念が多く存在します。
特にコンパートメントとIAMの関係性やポリシー言語の違いは、実際の運用において重要な要素となります。
本記事ではAWS IAMとOCI IAMの違いを具体例とともに詳しく解説します。

2.IAMユーザー/グループ/ロールの概念比較

AWSからOCIへ移行する際に最も混乱しやすいのが、IAMの概念の違いです。
ここでは、両サービスの認証・認可の仕組みを比較してOCIの独特な機能であるDynamic Groupsの活用方法を具体的に説明します。

基本概念の対比表

概念	AWS IAM	OCI IAM	主な違い
ユーザー	IAMユーザー	ユーザー	OCIは新しいテナンシーではIdentity Domainが標準、従来のIAMユーザーも利用可能
グループ	IAMグループ	グループ	OCIはDynamic Groupsも存在
ロール	IAMロール	IAMロール	OCIのロールはIdentity Domain内で管理
サービス認証	AssumeRole	Instance Principal	インスタンスが直接権限を持つ
権限境界	Account境界	Compartment境界	OCIは階層構造を持つ

OCIのDynamic Groupsとは

OCIには、AWSにはないDynamic Groupsという概念があります。
これは条件に基づいてインスタンスを自動的にグループ化する機能です。

OCI CLIでDynamic Groupの作成例

oci iam dynamic-group create \
  --compartment-id ocid1.tenancy.oc1..xxxxx \
  --name "compute-instances-group" \
  --description "All compute instances in production compartment" \
  --matching-rule "instance.compartment.id = 'ocid1.compartment.oc1..xxxxx'"

Dynamic Groupsの最大の利点は、条件に基づいてリソースが動的に評価され、条件に一致するリソースが自動的にグループのメンバーとして扱われることです。
これはリアルタイムの評価であり、物理的なメンバーシップリストが更新されるわけではありません。
AWSでは新しいEC2インスタンスを起動する際にインスタンスプロファイルを指定する必要がありますが、OCIではルールベースで自動的に権限が付与されます。
これにより大規模なインフラストラクチャにおける権限管理が大幅に簡素化され、運用負荷が軽減されます。

3.ポリシー言語（Policy Language）の具体的比較

IAMの概念の違いをご理解いただけたところで、次に重要なのがポリシー言語の違いです。
AWSとOCIでは、権限を定義する際の記述方法が大きく異なります。
ここでは同じ権限を設定する場合の具体的な記述の違いを比較し、OCIポリシー言語の特徴と実装時の注意点を詳しく解説します。

↺AWS IAM

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-server-side-encryption": "AES256"
        }
      }
    }
  ]
}

AWS IAMポリシーはJSON形式で記述され、各要素が構造化されています。
この例では、my-bucket内のオブジェクトに対して暗号化（AES256）が設定されている場合のみ、GetObjectとPutObjectを許可する設定です。
細かい権限制御が可能ですが可読性に課題がある印象です。

❍OCI IAM

Allow group storage-admins to use objects in compartment storage-compartment
Allow group storage-admins to use buckets in compartment storage-compartment

一方でOCI IAMポリシーは自然言語に近い記述で、直感的に理解できます。
上記例では、storage-adminsグループに対してstorage-compartment内のバケットとオブジェクトの使用権限（読み取り・書き込み）を付与しています。

※重要な注意点※　完全同等の条件設定について

OCIのポリシー言語でも条件文（where句）を使用して詳細な制御が可能です。
ただし記述方法がAWSとは異なり、多くのセキュリティ機能がサービスレベルでデフォルト有効化されているため、ポリシーでの細かい制御の必要性が相対的に低くなっています。
これには以下の理由があります。

アーキテクチャの違い
OCIでは暗号化はサービスレベルで自動的に適用される設計になっているため。
ポリシー言語の抽象化
OCIは権限レベルを抽象化していますが、where句を使用した細かい条件指定も可能です。
（記述方法がAWSとは異なります）
セキュリティモデルの違い
OCIでは暗号化を前提とした設計をしており、ポリシーで暗号化条件を制御する必要性が低いため。

同等の制御を実現する場合
↺AWS　ポリシーレベルで暗号化条件を細かく指定可能
❍OCI　バケット作成時に暗号化を必須設定し、ポリシーでは基本的な権限のみ制御

この違いは、AWSがより細かい制御を可能にする一方で、OCIがよりシンプルで安全なデフォルト設定を重視する設計思想の違いを反映しています。

主な文法の違い

AWSとOCIのポリシー言語では、記述形式が根本的に異なります。
JSON形式と比べて、自然言語に近い記述方法を採用しているため可読性が大幅に向上している印象を受けました。
また権限レベルの考え方も異なるため、両者の対応関係を理解することが重要です。

要素	AWS	OCI
記述形式	JSON	自然言語ライク
動詞	Action（細かい権限）	manage/use/read/inspect（抽象化）
対象	Resource（ARN）	リソースタイプ + Compartment
条件	Condition（JSON）	where句（SQL風）

※補足　OCI権限レベルの詳細

OCIでは、AWSのような細かいアクション指定ではなく、4つの権限レベルで抽象化されています。
この設計によりポリシーの記述が簡潔になるため、管理が容易になっています。
以下の表で各権限レベルがAWSのどの権限に相当するかを整理しました。

権限レベル	対象操作	説明	AWSでの相当権限
manage	作成、削除、更新、読み取り	全ての操作が可能	全アクション
use	更新、読み取り	操作権限（作成・削除以外）	Get, Put, List*等
read	読み取り、一覧表示	読み取り権限のみ	Get, List, Describe*
inspect	メタデータ閲覧	基本情報のみ閲覧可能	ListBuckets, DescribeInstances等

4.OCI特有であるコンパートメントの概念とIAMの関係性

OCIで最も強力で重要な特徴の一つが、コンパートメントによる階層的なリソース管理です。
AWSは主にアカウント単位での境界管理ですが、OCIでは単一のテナンシー内で複数の論理的な境界を作成できます。
これにより、企業の組織構造に合わせた柔軟な権限管理が可能になります。

コンパートメントの階層構造

コンパートメントはネスト（入れ子）構造にすることができます。
一例として以下のような階層構造を作成することで、組織の部門やプロジェクトごとにリソースを分離して適切な権限管理を実現できます。

Root Compartment (テナンシー)
├── Production
│   ├── Web-Tier
│   ├── App-Tier
│   └── DB-Tier
├── Development
│   ├── Dev-Web
│   └── Dev-DB
└── Shared-Services
    ├── Networking
    └── Security

コンパートメント作成とポリシー設定

実際にコンパートメントを作成し、そこに適切なポリシーを設定する手順を以下に示します。
AWSのアカウント分離と異なり、OCIでは単一のテナンシー内でこれらの操作を完結できます。

# コンパートメント作成
oci iam compartment create \
  --compartment-id ocid1.tenancy.oc1..xxxxx \
  --name "production" \
  --description "Production environment compartment"

# ポリシー作成
oci iam policy create \
  --compartment-id ocid1.tenancy.oc1..xxxxx \
  --name "production-policy" \
  --description "Production access policy" \
  --statements '["Allow group production-admins to manage all-resources in compartment production"]'

継承の仕組み

OCIのポリシーでは、明示的に継承を指定することで階層的な権限管理が可能です。
デフォルトでは権限は継承されないため、サブコンパートメントへの権限適用には明示的な指定が必要です。
これにより共通の権限は上位で定義し、特定の制限は下位で設定するという柔軟な権限管理が可能です。
この継承機能により、AWSでは複数のアカウントにまたがって設定が必要だった権限管理を、OCIでは一元的に管理できるようになります。

# 上位コンパートメントでの権限付与
Allow group network-admins to manage virtual-network-family in tenancy

# 特定コンパートメントでの制限
Allow group app-developers to use virtual-network-family in compartment development

5.CLIやTerraformによる権限設定方法

次にCLIとTerraformを使用したAWSとOCIの権限設定方法を具体的に比較し、それぞれの特徴と実装時の注意点を解説します。

①CLIでの設定比較

AWSとOCIのCLI操作を比較すると、最も大きな違いは権限付与の方法です。
AWSではユーザーに直接ポリシーをアタッチできますが、OCIではグループベースの権限管理が推奨されており、ユーザー作成、グループ作成、メンバーシップ設定という3つのステップが必要です。
一見手順が多く見えますが、この設計により大規模な組織での権限管理が体系的に行えるようになっています。

↺AWS CLI例

# IAMユーザー作成
aws iam create-user --user-name developer-user

# ポリシーアタッチ
aws iam attach-user-policy \
  --user-name developer-user \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

❍OCI CLI例

# ユーザー作成
oci iam user create \
  --compartment-id ocid1.tenancy.oc1..xxxxx \
  --name "developer-user" \
  --description "Developer user"

# グループ作成
oci iam group create \
  --compartment-id ocid1.tenancy.oc1..xxxxx \
  --name "developers" \
  --description "Developers group"

# ユーザーをグループに追加
oci iam group add-user \
  --group-id ocid1.group.oc1..xxxxx \
  --user-id ocid1.user.oc1..xxxxx

②Terraformでの設定比較

Terraformの実装では、AWSとOCIの設計思想の違いが顕著に現れます。
AWSではJSON形式でのポリシー記述が必要で、細かいアクションを個別に指定する必要がありますが、OCIでは自然言語に近い記述で権限レベルを指定できます。
またOCIではコンパートメントの概念があることにより、構造的な権限管理が可能です。
結果としてOCIのTerraformコードは可読性が高く、長期的なメンテナンスが容易になります。

↺AWS Terraform例

# IAMユーザー作成
resource "aws_iam_user" "developer" {
  name = "developer-user"
}

# S3アクセス用のポリシー作成（JSON形式）
resource "aws_iam_policy" "s3_policy" {
  name = "s3-access-policy"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = [
          "s3:GetObject",  # オブジェクト取得権限
          "s3:PutObject"   # オブジェクト作成権限
        ]
        Resource = "arn:aws:s3:::my-bucket/*"  # 特定バケット内のオブジェクト
      }
    ]
  })
}

# ユーザーにポリシーを直接アタッチ
resource "aws_iam_user_policy_attachment" "developer_s3" {
  user       = aws_iam_user.developer.name
  policy_arn = aws_iam_policy.s3_policy.arn
}

❍OCI Terraform例

# 開発環境用のコンパートメント作成
resource "oci_identity_compartment" "development" {
  compartment_id = var.tenancy_ocid
  name           = "development"
  description    = "Development environment"
}

# ユーザー作成（テナンシー直下）
# 新しいテナンシーではIdentity Domainユーザーが推奨
resource "oci_identity_user" "developer" {
  compartment_id = var.tenancy_ocid
  name           = "developer-user"
  description    = "Developer user"
}

# グループ作成（権限管理の基本単位）
resource "oci_identity_group" "developers" {
  compartment_id = var.tenancy_ocid
  name           = "developers"
  description    = "Developers group"
}

# ユーザーをグループに追加
resource "oci_identity_user_group_membership" "developer_membership" {
  group_id = oci_identity_group.developers.id
  user_id  = oci_identity_user.developer.id
}

# グループに権限を付与（自然言語風の記述）
resource "oci_identity_policy" "developer_policy" {
  compartment_id = var.tenancy_ocid
  name           = "developer-policy"
  description    = "Developer access policy"

  statements = [
    # バケット管理権限（作成・削除・更新・参照）
    "Allow group developers to manage buckets in compartment ${oci_identity_compartment.development.name}",
    # オブジェクト管理権限（作成・削除・更新・参照）
    "Allow group developers to manage objects in compartment ${oci_identity_compartment.development.name}"
  ]
}

6.IAMの監査ログ取得方法

IAMの運用において、「誰がいつ何を実行したか」 を追跡することは重要です。
AWSとOCIではそれぞれ異なる監査サービスを提供しており、ログの取得方法や形式も大きく異なります。
ここでは両サービスの監査機能を比較し、実際の運用に必要な監査ログの取得方法を詳しく解説します。

AWSのCloudTrailは基本的に管理イベントを自動で記録してくれますが、データイベントなどの詳細な監査には追加設定が必要です。
一方で、OCIのCloud Auditは標準で有効化されています。
また、ログの取得方法も大きく異なるためそれぞれの特徴を理解することが重要です。

↺AWS CloudTrail

AWSでは、CloudTrailによってJSON形式でイベントログが記録されます。
以下は典型的な監査ログの例です。

{
  "eventVersion": "1.05",
  "userIdentity": {
    "type": "IAMUser",                                    // ユーザータイプ
    "principalId": "AIDACKCEVSQ6C2EXAMPLE",
    "arn": "arn:aws:iam::123456789012:user/developer-user" // 実行者のARN
  },
  "eventTime": "2024-01-15T12:00:00Z",                    // イベント発生時刻
  "eventName": "AssumeRole",                              // 実行されたアクション
  "eventSource": "sts.amazonaws.com"                     // イベントソース
}

❍OCI Cloud Audit

OCIではデフォルトで全てのテナンシーで有効化されており、追加設定不要で柔軟な監査ログの取得が可能です。

# 指定期間の監査ログを取得
oci audit event list \
  --compartment-id ocid1.tenancy.oc1..xxxxx \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T23:59:59Z

# 特定の操作（ユーザー作成）に絞った監査ログを取得
oci audit event list \
  --compartment-id ocid1.tenancy.oc1..xxxxx \
  --start-time 2024-01-15T00:00:00Z \
  --end-time 2024-01-15T23:59:59Z \
  --query "data[?\"event-name\"=='CreateUser']"

両サービスの監査ログには共通する項目もありますが、記録される情報の詳細度や取得方法が異なります。
特にOCIはコンパートメント単位での監査が可能で、より細かい権限管理と連携した監査が実現できます。

7.実際につまずいたポイントと解決方法

OCIの構築&移行時に、AWSエンジニアが特に困るのは実際の運用でのつまずきポイントではないでしょうか。
ここでは実際に私が直面した問題と、その具体的な解決方法を紹介します。

①コンパートメント権限の継承

AWSのアカウント境界に慣れていたことに加え、OCIのコンパートメント継承の仕組みを完全に理解していなかったため、混乱したことがありました。
親コンパートメントで権限を付与したにも関わらず、子コンパートメントでアクセスできないという問題です。

問題
親コンパートメントで権限を付与したのに、子コンパートメントでアクセスできない

解決方法

# 基本的な権限付与（そのコンパートメントのみ）
Allow group admins to manage all-resources in compartment production

# サブコンパートメントも含める場合の正しい記述
Allow group admins to manage all-resources in compartment production and all sub-compartments

②Dynamic Groupsの条件設定

Dynamic Groupsの条件設定で、最初は条件の組み合わせ方が分からずに意図しないインスタンスを含んでしまったことがありました。

問題
Dynamic Groupsの条件が複雑で、意図しないインスタンスが含まれる

解決方法

# 複数条件をANDで組み合わせる（コンパートメント＋インスタンス形状）
instance.compartment.id = 'ocid1.compartment.oc1..xxxxx' AND instance.shape = 'VM.Standard2.1'

# タグベースの条件設定（部門タグによる制御）
tag.department.value = 'engineering'

③ポリシーの評価順序

OCIのポリシー評価は「デフォルトDeny」が基本原則で、明示的に許可されていないアクションはすべて拒否されます。
複数のポリシーが存在する場合の評価順序を理解していなかったため、期待通りの動作にならないことがありました。

問題
複数のポリシーが競合して期待通りの動作にならない

解決方法

# 基本的な読み取り権限を付与
Allow group users to read all-resources in compartment development

# 特定のリソースには別の制限的なポリシーを作成
# （secret-familyに対する権限を付与しないことで制御）
Allow group users to read compute-family in compartment development
Allow group users to read storage-family in compartment development

8.まとめ

両者においてIAMの概念や実装方法には大きな違いがありますが、エンジニア視点で見るとOCIの設計は多くの運用上の利点を提供すると感じました。

①技術的な主要な違いとOCIの利点

概念の整理と構造化

AWSのアカウント単位での境界に対して、OCIのコンパートメントは階層的な権限管理を実現
Dynamic Groupsにより、インスタンスの動的な権限管理が自動化される
グループベースの権限管理により、大規模組織での一貫した権限運用が可能

ポリシー言語の可読性向上

JSON形式から自然言語ライクな記述への変更により、コードレビューやメンテナンスが容易
4段階の権限レベル（manage/use/read/inspect）による抽象化で、権限設計の複雑さが軽減
Terraformでの実装時も、OCIの方は直感的で理解しやすいコード記述が可能

②実践で得られた知見

実際のプロジェクトを通じて感じたことですが、初期の学習コストは発生するものの以下の点でOCIは運用効率が高いということでした。

コンパートメント権限の継承
一度理解すればAWSの複数アカウント管理よりもシンプルに扱える
Dynamic Groupsの活用
条件設定に慣れれば、EC2のロール管理よりも自動化が容易
監査ログの標準化
CloudTrailの設定が不要で、デフォルトで包括的な監査が可能

③エンジニアの方へおすすめしたいこと

AWSエンジニアがOCIを学習する際は、まずOCIの設計思想を理解することが重要だと感じました。
特に以下の点を重視することで、スムーズな移行が可能になると思います。

コンパートメント設計
組織構造に合わせた階層設計を最初に検討
Dynamic Groups
インスタンスの自動権限管理を前提とした設計
ポリシー記述
自然言語ライクな記述の利点を活かした可読性の高いコード作成

AWSと比較してOCIは、より構造化されて運用効率を重視した設計となっています。
初期の学習投資により、長期的な運用負荷の大幅な軽減が期待できるため、非常に価値の高い選択肢と言えるでしょう。

権限周りを適切に設計することで、より明確で管理しやすい権限体系を構築できることから、特に大規模な組織での権限管理においてはコンパートメントの階層構造は強力な機能となります。

本記事の内容に誤りや不足がございましたら、お手数ですがコメントでご指摘いただけると幸いです
この記事が皆様の技術的な課題解決や学習の一助となれば嬉しく思います。
次回も有用な技術情報をお届けできるよう頑張りますので、イイネやコメントをお待ちしております！

最後までお読みいただき、ありがとうございました。

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

AWS IAMとOCI IAMを比較してみる – 実際のコード例で学ぶ権限設定の違い

1.はじめに

2.IAMユーザー/グループ/ロールの概念比較

基本概念の対比表

OCIのDynamic Groupsとは

OCI CLIでDynamic Groupの作成例

3.ポリシー言語（Policy Language）の具体的比較

↺AWS IAM

❍OCI IAM

主な文法の違い

※補足 OCI権限レベルの詳細

4.OCI特有であるコンパートメントの概念とIAMの関係性

コンパートメントの階層構造

コンパートメント作成とポリシー設定

継承の仕組み

5.CLIやTerraformによる権限設定方法

①CLIでの設定比較

↺AWS CLI例

❍OCI CLI例

②Terraformでの設定比較

↺AWS Terraform例

❍OCI Terraform例

6.IAMの監査ログ取得方法

↺AWS CloudTrail

❍OCI Cloud Audit

7.実際につまずいたポイントと解決方法

①コンパートメント権限の継承

②Dynamic Groupsの条件設定

③ポリシーの評価順序

8.まとめ

①技術的な主要な違いとOCIの利点

②実践で得られた知見

③エンジニアの方へおすすめしたいこと

参考リンク

※補足　OCI権限レベルの詳細