OCIのコンパートメントとは？役割・設計・注意点をわかりやすく解説

知識ノート
モカ
モカ

OCI を触り始めたときに、まず気になったのが「コンパートメント」でした。
他のクラウドにはあまりない考え方に感じたので、仕組みや役割を整理しながら調べてみました。
自分の理解のためのメモですが、同じように学んでいる方の参考になればうれしいです。

コンパートメントとは

コンパートメントは OCI テナント内の論理的なリソース分離単位です。
Compute、VCN、DB、Object Storage など、すべてのリソースは必ずいずれかのコンパートメントに属します。

重要 主目的は 権限管理とリソースの分離です。
重要 ネットワーク境界（ネットワークを区切る仕組み）ではない。

重要 root コンパートメントについて

OCI には必ず 1 つ、最上位のコンパートメントがあります。
これを root（ルート）コンパートメント と呼びます。

特徴：

  • すべてのコンパートメントの親
  • すべてのリソースの最終的な属先
  • 補足 IAM ポリシーはここから階層的に影響する

イメージ：

root
 ├─ prod
 ├─ dev
 └─ shared

ポイント root に直接リソースを作ると管理が複雑になるため、下位コンパートメントを使うのが一般的です。

コンパートメントの特徴

1: 重要 階層構造を持てる
OCI ではコンパートメントを階層化できます。

root
 ├─ prod
 │   ├─ app1
 │   └─ app2
 └─ dev

権限は下位に継承されます。

2: 重要 IAM ポリシーの適用単位
「誰が」「どのコンパートメント内の」「どのリソースに対して」「何をできるか」を定義します。

ポリシー例（赤字は変数）：

Allow group dev-admins to manage all-resources in compartment dev

意味：

dev-admins は dev 配下のすべてのリソースを manage できる

モカ
モカ

シンプルな構文ですね

3: 重要 ネットワーク境界（ネットワークを区切る仕組み）ではない

特徴の中でも誤解しやすいポイントです。

  • 通信を制御するのは VCN / ルート表 / セキュリティリスト / NSG
  • コンパートメントが違っても通信できます

つまり：

コンパートメントは「管理・権限の境界」であり、ネットワークの境界ではありません

4: 補足 監査・JSOX と相性が良い

コンパートメント単位で：

  • ログ
  • 権限
  • 変更管理

を分けられるため、内部統制や監査に有利です。
大企業がOCIを採用する理由のひとつでもあります。

典型的な設計パターン

環境単位（実務で最も多い）

prod
dev
shared

本番と開発の境界が明確になります。

アプリケーション単位

hr-app
erp-app
shared-db

組織単位

finance
sales
it

目的は 責任範囲と権限範囲を整理することです。

ポイント よくある落とし穴

1. リソースが見つからない

原因はほぼこれです。

現在のコンパートメントが違う

画面上部を都度確認することをおすすめします。

コンパートメント：prod

2. 権限のつけすぎ

権限レベルは区別します。

manage → ほぼすべて
read   → 閲覧のみ
use    → 実行のみ

必要最小の権限だけ付与します。

3. 下位継承と例外

root の設定は下位へ影響します。
例外は 明示的に書く必要があります。

設計で意識すること

  • どの単位で責任を分けたいか
  • どこで権限を制御したいか
  • 階層は深くしすぎない
  • 「見やすさ」を優先（監査/運用観点）

まとめ

最後に今回のまとめです。

  • コンパートメントは 管理・権限・監査の境界
  • ネットワーク境界ではない
  • 階層化できる（継承あり）
  • root は最上位（万能領域ではない）
  • ポリシーは英語のように書ける
  • どのコンパートメントを見ているか確認
モカ
モカ

論理的な区分として整理できる仕組みなので、
しっかり理解して使いこなせれば、とても便利だと感じました。
OCI独特の考え方ですが、慣れると設計がしやすくなると思います。

参考

コメント

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