OCI(Oracle Cloud Infrastructure) 基本のキ -アカウント管理偏-

はじめに

こんにちは株式会社TIELECのタカシユウトです。 この記事ではOCI(Oracle Cloud Infrastructure)について紹介します。

先日Oracle Cloud Infrastructure のハンズオンに参加してきました。自分の理解を整理するためにも学んだことを記事にしていきたいと思います。

OCIを始めようと思っている方の参考になれば幸いです。

OCI のアカウント管理

キーワード

OCIのアカウント管理は上記に基づいて行います。 ではそれぞれについて説明をしていきたいと思います。

テナンシとコンパートメント

OCIのアカウントの考え方を理解するうえでテナンシ、コンパートメントという二つのワードを抑えておく必要があります。

イメージでいうと

となります。

テナンシはOCIのアカウントのことで、組織全体で一つ持ちます。

コンパートメントはテナンシの中を部署、部門といった役割事に分割するものです。

組織には様々な役割や部門が存在しています。 OCIではこうした役割や部門に対してOCIのアカウント付与するのではなく、コンパートメントという階層型の管理を取り入れることによって、権限の管理や、組織ごとにやれることを制限することができます。

以下のようなイメージです。

テナンシ（会社）
├ コンパートメント (製品開発部)
│　　├ 　コンパートメント (○○課)
│　　└　コンパートメント (▲▲課)　
├ コンパートメント (研究開発部)
│　　└　コンパートメント (▲▲課)　
└ コンパートメント (管理部)

また、コンパートメントごとに予算の管理を行うことも可能です。

AWSでは組織をまたがる場合のような設定はもともとはなかった？のでこういった運用をやろうとするとAWS Organizationsのような機能を使って実現することになると思います。OCIではデフォルトで組織の役割ベースでの管理が行えるようになっている点が優れていると感じました。

グループとユーザー

グループ

次にグループについて説明します。組織には様々な役割を持った人がいますよね。マネージャーやメンバーといった役割を持った人がいると思います。OCIではこういった役割ベースでの権限管理にグループを使います。

例えばこういった権限設定を行います。

このように役割ベースで権限の設定を行うこができます。

ユーザー

ユーザーはOCIを利用する各々の人のことを指します。 ユーザーは必ず何らかのグループに所属します。

ポリシー

ポリシーとはコンパートメントとグループに設定する権限設定のことです。作成したコンパートメントとグループに対してどのような操作を許可するのかを設定します。

例えば、コンパートメント (製品開発部) のリソースをほかの部署の人が操作できないようにするといったことをポリシーの設定を通じて行います。

部署、部門といった組織による管理がコンパートメント、Manager/Memberといった役割による管理がグループ、コンパートメント・グループを横断して権限設定をするのがポリシーです。

このように、OCIではコンパートメント、グループ、ポリシーをそれぞれ設定することによって組織、および役割での権限管理を行う点が特徴です。

現代のベストプラクティス（2026年版）

ここまで説明してきたテナンシ、コンパートメント、グループ、ポリシーといった基本概念は今も変わらず重要です。しかし、2026年現在、OCIのIAM（アイデンティティとアクセス管理）はさらに進化しています。ここでは現代の組織運用で押さえておくべきベストプラクティスを紹介します。

Identity Domains（アイデンティティ・ドメイン）

2022年以降、OCIではIdentity Domainsという新しいIAMコンテナが導入されました。これは従来のIAM機能を包含し、より柔軟な認証・認可を実現するものです。

従来のIAMでは、テナンシごとに1つのIAM設定しか持てませんでしたが、Identity Domainsを使うことで、複数の独立したIAM環境を1つのテナンシ内に作成できます。

例えば：

このように環境や用途ごとに分離することで、セキュリティと管理性が向上します。これは、これまで説明してきた「コンパートメント」がリソースを組織単位で分けるのに対し、ユーザーやグループ自体を環境単位で分ける仕組みと考えると分かりやすいでしょう。

多要素認証（MFA）の重要性

現代のクラウドセキュリティでは、パスワードだけでは不十分です。OCIでは多要素認証（Multi-Factor Authentication: MFA）を強く推奨しています。

MFAを有効にすると、ログイン時にパスワードに加えて、スマートフォンアプリなどで生成されるワンタイムパスワードの入力が求められます。これにより、万が一パスワードが漏洩しても、第三者による不正アクセスを防ぐことができます。

特に、管理者権限を持つユーザーや、本番環境のコンパートメントにアクセスできるユーザーには、MFAを必須にすることが重要です。OCIではポリシーを使ってMFAを強制することもできます。

# MFAを使用していないユーザーのアクセスを拒否するポリシー例
Allow group Administrators to manage all-resources in tenancy where request.user.mfaTotpVerified='true'

フェデレーションとSSO

大規模な組織では、複数のクラウドサービスやアプリケーションを使用しています。それぞれに個別のアカウントを作成するのは管理が煩雑になります。

OCIではフェデレーション（Federation）とSSO（シングルサインオン）をサポートしています。これにより、既存の企業アイデンティティプロバイダー（Microsoft Entra ID、Okta、Google Workspaceなど）と連携し、1つのアカウントで複数のサービスにログインできます。

メリット：

Identity Domainsを使えば、SAMLやOIDC（OpenID Connect）といった標準プロトコルで、簡単にフェデレーションを設定できます。

セキュリティのベストプラクティス

最後に、これまで説明してきた概念を踏まえた、現代のセキュリティベストプラクティスをまとめます。

1. 最小権限の原則

ユーザーやグループには、業務に必要最小限の権限のみを付与します。「とりあえず全権限を付与して後で調整」というのは危険です。ポリシーを細かく設定し、必要なコンパートメントとリソースにのみアクセスできるようにしましょう。

2. Dynamic Groups（動的グループ）の活用

OCIにはDynamic Groupsという機能があり、インスタンスやサービスなどのリソースに対して、ユーザーと同じようにポリシーを設定できます。これにより、アプリケーションが実行時に必要なリソースへアクセスする際、APIキーをハードコードする必要がなくなります。

例：特定のコンパートメント内のインスタンスが、Object Storageにアクセスできるようにする

# Dynamic Group の定義
ALL {instance.compartment.id = 'ocid1.compartment.oc1..xxxxx'}

# ポリシー
Allow dynamic-group MyAppInstances to read objects in compartment ProductionData

3. 定期的な監査

アクセスログやポリシーの設定を定期的に見直しましょう。OCIのAudit Serviceを使えば、誰がいつ何をしたかを追跡できます。不要になったユーザーやポリシーを削除することで、セキュリティリスクを減らせます。

4. ルートユーザーの使用を制限

テナンシ作成時に作られるルートユーザーは、全ての権限を持ちます。このアカウントは初期設定やMFA設定以外では使用せず、日常業務には管理者グループに所属する通常ユーザーを使いましょう。

まとめ：基本を理解し、現代の機能を活用する

この記事で紹介した基本概念（テナンシ、コンパートメント、グループ、ポリシー）は、OCIのIAM設計の土台です。そして、Identity Domains、MFA、フェデレーション、Dynamic Groupsといった現代の機能を組み合わせることで、より安全で管理しやすいクラウド環境を構築できます。

OCIを始めたばかりの方は、まず基本概念を理解し、小規模な環境で試してみることをおすすめします。その後、組織の成長に合わせて、これらのベストプラクティスを段階的に導入していきましょう。

参考資料（2026年版）

まとめ

いかがでしたでしょうか。改めて内容をまとめますと次のようになります。

OCIを使っていくうえで必要な考え方になります。 特にコンパートメント、ポリシーは特徴的な考え方だと思うので参考にしていただければと思います。

参考ドキュメント

参考

関連書籍

もっと深く学びたい方へ

この記事で、OCIのアカウント管理の仕組みは理解できたと思います。

でも、実際の組織運用では「どういう権限設計が適切か」「セキュリティポリシーをどう実装するか」「複数環境をどう管理するか」という判断が求められます。

より深い理解のために、こちらの記事もおすすめです：

CloudFormationでクロスアカウントIAMロールを作るとき、「作成順序」でハマった話

CloudFormationでクロスアカウントのAssumeRole構成を組むとき、信頼ポリシーは参照先ロールの実在をチェックします。作成順序を間違えると `Invalid principal in policy` で弾かれます。実際にハマ...

Tech

開発ラボ

なぜSREへの投資は軽視されがちなのか――警察・消防との比喩から考える、デジタルインフラの価値

SREやPlatform Engineeringへの投資は、なぜ経営層から軽視されがちなのか。警察・消防との比喩を通じて、「見えない損失」を可視化し、デジタルインフラへの投資判断を考える。経営層向けガイドも付録として掲載。

Tech

SRE