はじめに

どうも、初めまして。
レックのエンジニア Y.Yと申します。

OCIのサービスの一つである「IAM」をご存じでしょうか。
「Identity and Access Management」の略で、何となくユーザの認証で使用するサービスと理解している方も多いのではないでしょうか。
言葉は知っているけど詳しくは知らない。そんな方向けにIAMについて解説していきます。

こんな方におすすめ

• エンジニア歴の浅い方
• 「IAM」をよく知らない方
  
  

IAMとは

IAMは、OCI（Oracle Cloud Infrastructure）内で「誰が」「どこに」「どのような操作ができるか」を管理するための仕組みです。
OCI環境の特定のリソース（コンピュート、ネットワーク、ストレージ、データベースなど）に対するアクセス権を管理し、セキュアな運用を実現できます。

IAMの認証・認可

IAMでどのようなことができるかは理解いただけたかと思いますので、次はIAMで実現可能な２つの機能について説明していきます。
IAMには様々な機能が存在していますが、大きく分けて「認証（Authentication）」と「認可（Authorization）」の２つに分類されます。

認証（Authentication）

• ユーザやエンティティが本人であることを確認する機能です。
• フェデレーションを使うことで、企業の既存のIDプロバイダ（AD、IDCSなど）でもシングルサインオンすることが可能になります。
• 具体例としては、ユーザ名＋パスワード、APIキー、インスタンス・プリンシパル（ComputeインスタンスがOCIのAPIを呼ぶ際の認証）などの認証方法があります。

認可（Authorization）

• 認証されたユーザがどのリソースにどの操作を行えるかを決める機能です。
• OCIでは主に「ポリシー」を使用して実装されることが多く、ユーザやグループとリソースを紐づけて認可を行います。
• ポリシーは明示的に許可がなければ操作を拒否する「deny」が基本ルールとなっており、不要な権限を付与しない「最小権限」を意識した設計となっています。

IAMのコンポーネント

ここでは認証と認可に分類されるコンポーネント(機能)についてもう少し細かく紹介していきます。
IAMには下記のようなコンポーネントが存在しています。

コンポーネント一覧

分類※	コンポーネント名	役割
認証	ユーザ（User）	オペレータやアカウントの識別単位です。 ログインやAPI呼び出しに利用します。
	グループ（Group）	複数ユーザをまとめることで、ポリシーなどで指定することが可能になる単位です。 権限付与は基本的にグループに対して行われます。
	動的グループ （Dynamic Group）	インスタンスやリソース属性に基づいて自動適用されるグループです。 インスタンス・プリンシパルで利用されます。
	プリンシパル（Principal）	ユーザ/動的グループ/サービスなどの複数の認証対象(認証の主体)を1つの範囲として扱うための論理的な単位です。 ポリシーを定義する時の「誰が」に相当します。
	アイデンティティ・ドメイン （Identity Domain）	ユーザやグループだけでなく、フェデレーションなどの「何を使って認証を行うか」まで管理できる論理的な単位です。 大規模な組織やユーザごとに別管理が必要な場合に利用します。
認可	リソース（Resource）	コンピュート、ストレージ、ネットワークなどのOCI上の操作対象のことを指します。 リソースごとに権限の制御が可能です。
	コンパートメント（Compartment）	リソースを論理的に分割する単位です。 リソースの所有者や料金の請求を決定する時に利用されることが多いです。
権限制御	ポリシー（Policy）	「誰」が「どこに」に「どんな操作」ができるかを定義するルールです。 宣言的な構文でルールを定義します。
	ネットワーク・ソース （Network Source）	アクセス元IPやVCNを限定するルールです。 ポリシーと組み合わせて使用することが可能です。
	フェデレーション （Federation）	外部のIDプロバイダと連携して認証を委譲することが可能になる機能です。 SAML/OIDC等を使ってSSO(シングルサインオン)を実現します。

※公式にコンポーネントの「分類」は存在しませんが、解説の便宜上記載しております。ご了承ください。

認証

IAMの「誰が」に相当する部分を決めるコンポーネントになります。
ユーザ、グループと言ったお馴染みのワード以外に、様々な認証対象をまとめるプリンシパルやアイデンティティ・ドメインが存在していますので、注意してください。

• ユーザ（User）
  • 人やサービスに対して割り当てられる個別アカウント。
  • コンソールログインやAPIアクセスに使う。
  • 権限は直接与えることもできるが、グループ経由で付与するのが一般的。
• グループ（Group）
  • ユーザをまとめる単位。
  • ポリシーでは「group X」として定義する。
  • 使用例としては開発者グループ、運用グループ、読み取り専用グループなどがある。
• 動的グループ（Dynamic Group）
  • インスタンスや他のOCIリソースの属性(インスタンスのタグやコンパートメントなど)に基づき自動でメンバーが決まるグループ。
  • インスタンスを"ユーザ"のように扱うために使用される機能。
  • 主に「インスタンス・プリンシパル」でOCI APIを呼ぶ際の権限付与に使う
• プリンシパル（Principal）
  • 認証された主体（ユーザ、動的グループ、サービスプリンシパルなど）をまとめて扱うための単位。
  • ポリシーではプリンシパルに対して許可（allow）や拒否（deny）を定義する。

• アイデンティティ・ドメイン（Identity Domain）
  • ユーザやグループなどのアイデンティティ管理の範囲を示す論理単位。
  • 大規模な組織での使用を想定しており、組織の要件に応じて、管理の切り分けや外部連携を行うことが可能。

認可

IAMの「どこに」に相当する部分を決めるコンポーネントになります。

• リソース（Resource）
  • OCI上の実体（コンピュート、ブロック・ストレージ、オブジェクトストレージ、VCN、ロードバランサーなど）を示す。
  • ポリシーでは特定の種類のリソース（バケット、インスタンスなど）を指定する。
• コンパートメント（Compartment）
  • リソースを論理的に分離するための単位。
  • アクセス制御、請求、ライフサイクル管理などで使用される。
  • 大きな組織ではプロジェクト/チーム/環境（dev/prod）ごとにリソース分けて管理することが可能。

権限制御

IAMの「どのような操作ができるか」に当たる部分になります。
権限制御の軸となるポリシーについてはしっかり覚えておくと良いと思います。

• ポリシー（Policy）
  • 「誰が（プリンシパル）どこで（リソース/コンパートメント）何ができるか（アクション）」を文で記述する機能。
  • ポリシー最小権限や役割ベースを意識した設計となっている。
  • 下記のような構文でルールを定義する。
    • allow group Devs to manage instances in compartment ProjectA
• ネットワーク・ソース（Network Source）
  • ポリシーに条件として組み入れられる、アクセス元のIPレンジやVCN等の制限。
  • 管理コンソールやAPIアクセスを特定のネットワークからのみ許可したい場合に利用。
• フェデレーション（Federation）
  • 外部のアイデンティティプロバイダ（例：Active Directory、SAML/OIDC対応）と連携して認証を委譲。
  • 中央のIdPでユーザ管理を行い、OCI側は認可（ポリシー）に集中できる。SSO運用や既存ID基盤活用に便利。

まとめ

IAMについて解説してきましたが、いかがでしたでしょうか。
IAMはOCIのリソースへのアクセスをきめ細かく管理する仕組みとなっており、
機能を組み合わせ下記を実現できます。

• 最小権限
• 運用しやすさ
• セキュリティ

詳しく学習したい方は、以下のURLからOracle社が提供しているトレーニング資料（Become an OCI Architect Associate)を、ご覧いただけると理解が深まると思います。

https://www.oracle.com/jp/education/training/oracle-cloud-infrastructure/

出典：Oracle Cloud Infrastructureのトレーニングと認定資格

皆様がOCIのイメージを掴む手助けとなれば幸いです。