N-01 IAMの登場人物（User / Group / Policy / Compartment）

Uncategorized

はじめに（全体の体系と記事の種類）

本ブログでは、OCI学習を体系立てて整理するために、次の2種類の記事を扱います。

  • 知識ノート（N-xx）：概念・設計の考え方・判断基準を整理します。
  • 検証（L-xx）：手順・設定値・つまずきポイントを、再現可能な形で記録します。

ブログの全体像についてはこちら：〔URL N-00〕

本記事は知識ノート（N-01）として、OCI IAMの中核となる「登場人物（User / Group / Policy / Compartment）」を整理します。

この記事の目的

OCI IAMの基本要素である User / Group / Policy / Compartment を、次の観点で理解できる状態を目指します。

  • 各用語の違いを説明できる
  • IAMを設計できる
  • 代表的な設計パターンと、よくある落とし穴を回避できる

どこで使う（ユースケース）

IAMは、日々の運用で「誰に、どのコンパートメントの、どの操作まで許可するか」を切り分ける場面で最もよく使います。代表例を以下に示します。

  • 検証環境を作る：コンパートメント作成、最小権限付与、操作範囲の限定をする際に使用します。
  • チームで運用する：異動・退職などの人の入れ替わりを前提に、グループ単位で権限を管理します。
  • 環境分離（検証/開発/本番）：コンパートメントとポリシーで誤操作の影響範囲を限定します。
  • 監査・統制（最小権限、責任分界）：誰が何をできるかを説明可能な状態にし、監査に耐える構成を実現します。

図（1枚）

図の内容

「User → Group → Policy → Compartment → Resource」 の関係を1枚で示します。

補足説明
User（人）はGroup（役割）に所属し、GroupはPolicy（許可ルール）によって権限を付与されます。Policyは対象となるCompartment（管理境界）のスコープ（範囲）を定義し、そのCompartmentがResources（Compute、VCN、Object Storageなど）を含みます。実務ではUserに直接権限を付与せず、Groupに集約したうえで、Compartment内リソースに対する操作レベル（read/use/manage）をPolicyで制御します。

代表パターン例（3つ）

「代表パターン」として、組織運用で利用されやすいIAM設計の型を取り上げます。あらかじめ型を決めて横展開する方が権限の事故を抑制しやすくなります。

パターン1：環境分離（prod / dev / sandbox をCompartmentで分離）

構成（例）

  • Compartment：prod / dev / sandbox
  • Group：ProdAdmin / DevAdmin / SandboxUser
  • Policy：各Groupに対して、対象Compartment内の必要最小限の操作を許可

なぜ（理由）
Compartmentはアクセス権を区切る単位です。環境（本番・開発・検証）を同じCompartmentに置くと、「本番を見るための権限」や「検証で作業するための権限」が混ざり、不要な権限が増えやすくなります。環境ごとにCompartmentを分けると、付与する権限と操作対象を環境単位で限定でき、誤操作が起きても影響をその環境内に留められます。

パターン2：職務分離（Network / App / DB など役割で分離）

構成（例）

  • Group：NetworkAdmin / AppOperator / DBOperator
  • Policy：役割ごとに必要なResource操作のみを許可

なぜ（理由）
広く権限を付与すると誤操作や責任所在が不明確になります。職務ごとに権限を分けることにより、各担当者は必要な操作だけが可能になり、不要な変更を防げます。さらに、監査やレビューの場面で「この担当はこの範囲だけ操作できる」と説明しやすくなります。

パターン3：閲覧専用（ReadOnly / Auditor グループ）

構成（例）

  • Group：Auditor（またはReadOnly）
  • Policy：原則readのみ

なぜ（理由）
参照目的の業務は多い一方で、変更する作業（権限）は不要な場合が多いです。閲覧専用として権限を分離することで、誤操作のリスクを抑えつつ、監査・レビュー業務ができます。

落とし穴（3つ）

落とし穴1：Userへ直接権限を付与する

問題：権限の棚卸が困難になり、担当の異動・退職時の管理が難しくなります。
対策：権限はGroupへ集約し、UserはGroup所属で管理します。

落とし穴2：Compartment設計が曖昧でポリシーが肥大化する

問題：例外が増え、最小権限が崩れやすくなります。
対策：先にCompartment（アクセス権を区切る単位）を設計し、その後にポリシーを当てます。

落とし穴3：どのポリシーが効いているか追えない

問題：運用が進むほど、権限の追跡と説明が難しくなります。
対策：命名規約、役割と範囲の単純化、例外削減を徹底します。

用語ミニ辞典

  • User：操作主体（人）。実務ではGroup所属で権限管理します。
  • Group：役割の単位。複数Userを束ね、権限をまとめて付与します。
  • Policy：許可ルール。主体・範囲・対象・操作レベルを定義します。
  • Compartment：管理の境界。アクセス制御と運用分離の基本単位です。
  • Tenancy：OCI契約の最上位単位（ルート）。Compartmentは配下に作成します。

さいごに

OCI IAMは複数の要素で構成されていますが、要素間の流れを図で整理することで、全体像を把握しやすくなりました。また、「人（User）に権限を持たせる」のではなく、役割（Group）に権限を集約し、ルール（Policy）を管理境界（Compartment）に適用することが重要であると理解しました。

情報ソース（リンク）

コメント

タイトルとURLをコピーしました