N-02 ポリシー文法（Allow …）と設計の考え方

OCI

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

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

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

ブログの全体像についてはこちら
本記事は、知識ノート（N-02）として、OCI IAMポリシーの基本文法（Allow …）と、実務で活用できる設計の考え方を整理します。

1. この記事の目的

OCI IAMポリシーについて、次を説明できる状態を目指します。

  • Allow文の読み方（誰が・どこで・何を・どのレベルで）を分解して理解する
  • read / use / manage / inspect の使い分けを説明できる
  • 例外が増えにくいように、ポリシー設計の基本方針（型）を持つ

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

  • 閲覧専用（read-only）ユーザーを作る：監査・問い合わせ対応で「参照のみ」を安全に提供します。
  • 運用の担当範囲を分ける：ネットワーク担当はネットワーク、運用担当はCompute運用など、担当範囲をポリシーで固定します。
  • 環境分離（本番/開発/検証）を維持する：コンパートメント単位で許可範囲を限定し、誤操作の影響範囲を抑制します。

3. 図

「Allow文が表現している4要素」について

  • ①：Principal（主体）
    • 例：group 'Default'/'grp-readonly-sandbox'
  • ②：Verb（操作レベル）
    • 例：inspect / read / use / manage
  • ③：Resource-type（対象）
    • 例：virtual-network-family / instance-family / all-resources
      ※ *-family は、Oracleが公式に定義しているresource-type（リソースタイプ）名です。利用者が任意に作った名称ではなく、ポリシー文でそのまま指定できる識別子として、Policy Referenceに一覧化されています。
  • ④：Scope（範囲）
    • 例：in compartment cmp-sandbox / in tenancy

補足説明
OCI IAMのポリシーは、Allow文により「主体（誰に）」「操作レベル（何をどこまで）」「対象（どの種類に）」「範囲（どこで）」を宣言します。設計では、最初に範囲（Compartment）を確定し、その範囲内で対象と操作レベルを絞ることで、権限が肥大化しにくくなります。

4. 代表パターン例（3つ）

代表パターンの意味

ここでいう代表パターンとは、人の入れ替わりや環境追加があっても、ルールを増やし過ぎずに運用できる設計の型を指します。

パターン1：まず「read-only」を作り、必要に応じて拡張する

  • 例（出発点）
    • Allow group 'Default'/'grp-readonly-sandbox' to read all-resources in compartment cmp-sandbox
  • 意図
    • 参照が必要な利用者に対し、変更権限を与えずに（＝read-only）業務を成立させます。
  • 拡張の方針
    • 「見たいサービスだけ」に絞る場合は virtual-network-family などへ段階的に分解します。

パターン2：対象は *-family を優先し、サービス単位で管理する

  • 例（ネットワーク運用者）
    • Allow group 'Default'/'grp-net-admin' to manage virtual-network-family in compartment cmp-sandbox
  • 意図
    • 影響範囲（Compartment）を固定したうえで、対象（family）を明確にし、担当外の操作を抑止します。

パターン3：スコープを「環境単位」で固定し、ルール増殖を防ぐ

  • 例（本番/開発/検証をCompartmentで分離）
    • Allow group 'Default'/'grp-dev-ops' to use instance-family in compartment cmp-dev
    • Allow group 'Default'/'grp-prod-ops' to use instance-family in compartment cmp-prod
  • 意図
    • 同じ役割でも環境が異なれば別のスコープに切り、例外の混入を防ぎます。

5. 落とし穴（3つ）

落とし穴1：manage all-resources を安易に付与する

  • 問題：範囲内の変更操作が広く可能になり、誤操作の影響が大きくなります。
  • 対策：最初は read または use を基本とし、対象は *-family を優先して絞ります。

落とし穴2：スコープ（compartment / tenancy）が曖昧なまま作成する

  • 問題：意図せず見える範囲が広がり、権限の説明が困難になります。
  • 対策：Allow文を書く前に、対象Compartmentを確定し、原則「環境・用途で分割」します。

落とし穴3：ドメイン・グループ参照の不一致（ポリシーが効かない）

  • 問題：Identity Domainが異なるグループを参照すると、権限が付与されず、コンソールでAuthorization errorとなります。
  • 対策：'Default'/'group-name' のように、必要に応じてドメインを明示し、ユーザーの所属グループと整合させます。

6. 用語ミニ辞典

  • Policy：アクセス許可ルール。複数のStatements（Allow文）で構成されます。
  • Statement（Policy Statement）：Allow文1行。主体・操作・対象・範囲を宣言します。
  • Principal（主体）：権限を付与される対象。主に group（人の集まり）を用います。
  • Verb：操作レベル。代表例は inspect / read / use / manage です。
  • Resource-type：許可対象の種類。all-resources や *-family を用いて範囲を表現します。
  • Scope：許可範囲。in compartment X または in tenancy で指定します。
  • Identity Domain：ユーザー・グループを管理する単位。グループ参照が一致しないと権限評価が想定どおりになりません。

さいごに

もか
もか

OCI IAMポリシーは、Allow文を「主体・操作レベル・対象・範囲」の4要素に分解して理解すると、読み書きが安定します。設計では、最初にCompartmentで範囲を固定し、次に対象（*-family）と操作レベル（read/use/manage）を絞る方針を徹底することで、権限の肥大化を防ぎたいと考えています。

情報ソース（リンク）

コメント

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