AWS/Azure 経験者がはじめる OCI 入門 ～ IAM/IDCS編 ～

はじめに

本記事では、AWS/Azure と言った パブリッククラウド に続いて Oracle Cloud Infrastructure (OCI) の 学習を 始めた筆者 が、同じく 第２、第３のパブリッククラウド として OCI の 学習を 始めた方 向けに、OCI の 特徴や、他のパブリッククラウド との相違点 などについて、ご紹介していく内容となっています。

第２弾となる今回は、IAM/IDCS編 となります。

第１弾 概要編：https://qiita.com/Skogkatter112/items/98c6f815b4e0b6556b7e
第２弾 IAM/IDCS編：https://qiita.com/Skogkatter112/items/51b619026aa53a9c6069
第３弾 Compute編：https://qiita.com/Skogkatter112/items/540da610c7938cb74b55
第４弾 Storage編：https://qiita.com/Skogkatter112/items/200a1fe8c419fc9ee16e

《22/1/26 追記》 OCIのIAMとIDCSは、2021/11月に "OCI IAM Identity Domain" として統合されました。本記事は、統合前のIAMとIDCSについて記述したものとなりますのでご注意ください。

OCIにおける認証・認可

認証・認可とは

まず始めに、改めてになりますが、認証・認可とは何か？について 触れておきたいと思います。端的に言ってしまえば、誰が、何をできるか？ という管理を行うための仕組み になります。

多くの場合、パブリッククラウドというのは、１つの環境を 複数人で利用していきますが、そんな中で、誰でも 何にでも アクセス出来てしまっては、あらゆるリスクが伴ってしまいます。（例えば、重要データ が 含まれるリソース に 誰でもアクセス できてしまうことによる「情報漏洩」、本番環境として 稼働しているリソース を 誤って削除してしまうことによる「作業の手戻り」など）

その為、「誰が、何をできるのか？」という管理が行えるよう、認証・認可 という機能 が 提供されています。

認証 の 機能 によって、例えば「ユーザ名」と「パスワード」の入力などによって「このユーザは 確かに 〇〇である」といった証明 が為され、
認可 の 機能 によって、「このユーザには、この操作を許可する」といった 権限設定 が 可能になります。

尚、この権限設定においては、どのクラウドにおいても、セキュリティリスクを最小化すべく、最小権限の原則 に則った設計 が 推奨されています。（絶対に必要でないなら、その権限を与えるべからず！）

２つ の 認証基盤

OCI の 認証・認可の仕組み には、IDCS (Oracle Identity Cloud Service) および IAM (OCI Identity and Access Management) の ２種類 が 存在しており、２つの 最も大きな 違いは、カバーしている範囲 にあります。

• A) IDCS

  • IDCS というのは、もともと OCI とは 別に、Oracle が 提供している ID管理用 の サービス で、OCI の利用がなくとも、独立して 導入が可能 です。
    
  • Oracle が 提供している ほぼ全ての クラウドサービス に対して、認証・認可の機能を提供 します。
  • OCI における IDCS の利用は、別の認証基盤 を フェデレーション している、というイメージ になります。
    ※ただし、OCI の 利用者 が 意図して フェデレーション の 設定 を せずとも、アカウント作成時に 自動的に 連携されます。

• B) IAM

  • IAM は、OCI 単体に閉じた認証基盤 となっており、OCI Native ではないサービス に対する 認証・認可 は 行えません。("OCI Native" の 意味 については、当記事の最後に記載している 補足 をご参照ください)
  • OCI の 主たる 認証・認可 の 機能 であり、IAM ユーザ を 一切作成しない（ゼロ にする）ということは できません。
    

コンソール画面へのログイン

第１弾 の 概要編 でも少し触れたのですが、IDCS と IAM という ２つの認証・認可の仕組みがあることによって、最も始めに戸惑うのが、ログインだと思います。作成したアカウントにログインする流れは、下記の通りとなっています。


まず、インターネットで「OCI ログイン」と 検索頂くと、上記 左のイメージ にあるような候補 が 出てくるかと思います。

「Oracle Sign In」と記載されている方が「IDCS」の認証画面、「Oracle Cloud Infrastructure」と記載されている方が「OCI IAM」の認証画面 となっています。
※ただし、後者の画面にて アカウント名を入力後、IDCS の 認証画面 へ遷移することも 可能です。

それぞれ URL は、下記の通りです。

• IDCS ログイン画面：
  https://www.oracle.com/jp/cloud/sign-in.html
• OCI IAM ログイン画面：
  https://console.ap-tokyo-1.oraclecloud.com
  ※ホームリージョンが tokyo の場合
  

IAM の ログイン画面 の URL については、ホームリージョンごとに異なるので、マニュアル をご参照ください。（どのリージョンから入っても ホームリージョン に リダイレクトされますが 画面遷移が増えて 手間です）

尚、アカウント (テナント) 名の入力 を 省略したい場合は、「ホームリージョンのURL/?tenant=自分のアカウント名」と 入力することで、IAM の 認証情報を入力する画面 へ 直接 アクセス することが 可能です。

その他 提供機能の違い

IDCS と IAM の その他の違い は、下記の通りとなっています。（最新情報は マニュアルをご参照ください。）

上記の通り、他のサービスと 連携した SSO認証 を したい場合や、IPアドレス による フィルタリング を したい場合など、高度な連携・セキュリティ管理 を 行いたい場合は、IDCS が 必須 となってきます。

このように、IDCS の 方が 機能が充実していますが、その分 有料となる部分もあるため、適材適所で ご利用 を 検討頂ければと思います。

この辺りは Azure AD の 有償プラン と そうでないプラン の 関係性と似ていますね。

IAM について

前置きが 長くなりましたが、ここからは、それぞれの機能について 詳しく 見て行きたいと 思います。まずは IAM からとなります。

コンポーネント

IAM の コンポーネントは下記のようになっています。

• プリンシパル … その行動を起こす主体 の 総称 を意味します。

  • IAM ユーザ … OCI を利用する個人 や アプリケーション を意味します。
  • インスタンス・プリンシパル … OCI 上の インスタンス を意味します。
    ※ユーザの認証情報を用いることなく、インスタンス が 他の OCI サービスへ APIコールを 行う際の権限設定 が 可能になります。

• グループ … OCI では、プリンシパル に対して直接 権限を付与することはできません。必ず何かのグループに所属させた上で、そのグループに対して 権限を付与します。

• ポリシー … 何に どのような操作 を 許可するか？といった 具体的な 認可を設定する ステートメント です。
  詳細は 次の段落でご紹介しますが、OCI では、デフォルトは 全ての権限が "拒否" 状態 となっており、このポリシーによって "許可していく" という形になります。(許可した上で、一部 拒否の設定をする、といったことはできません。)

画面アクセス

IAM に関連する画面 は それぞれのコンポーネントごとに画面が分かれています。コンソール画面 から 下記のメニューに アクセスしてください。

認証の種類

IAM では、下記の要素を用いて 認証が行われます。
最も ポピュラーな認証方法 である「ユーザ名」「パスワード」以外に、API 利用時の認証に使える ３種類の認証情報 が 提供されています。

それぞれの利用シーンについては、「ユーザ名」「パスワード」については 自明ですが、API 利用時の認証方法 が ３種類もあるので、少しイメージしづらいかと思います。補足すると 下記の通りとなります。

• API キー … OCI Native のAPI。SDK、CLI を利用する場合、つまり、OCI が提供している API を 呼び出す際の 認証に 利用可能 です。
• 認証トークン … Swift と互換性のある API を 使用する場合に 利用可能な 認証情報 です。
  ※OCI の Object Storage (Amazon S3／Azure Blob Storage に類するストレージサービス) については、OCI Native の API の他に、このタイプのAPI による操作もサポートしているので、そういった場面で利用することになります。
• 顧客秘密キー … Amazon S3 の API と互換性のある API を使用する場面に 利用可能な 認証方法 です。
  ※こちらも 認証トークン同様、Object Storage が このタイプのAPIをサポートしている為、Amazon S3 の API を用いて Object Storage を操作したい場合などに 利用します。

尚、多要素認証を有効化している場合は、「ユーザ名」「パスワード」に加え、オーセンティケータ・アプリケーション（Oracle Mobile Authenticator や Google Authenticator）／登録済モバイル・デバイス による ワンタイムパスワード も 認証情報として 必要になってきます。

認可の方法

認可 は、その権限を与えたい グループ に対して、ポリシー を 関連付ける ことで 設定が可能です。コンポーネントの説明でも触れましたが、必ず "グループに対して" ポリシーを関連付けます。プリンシパル に対して 直接 関連付けることは できません。

• 他社クラウドとの違い
  認可において、他社クラウドと異なるポイントとしては、ポリシーは JSON形式で記述するものではなく、また、予め用意されたポリシー が ない ということでしょうか。
  他社クラウドですと、例えば AWS ですと、「AWS管理ポリシー」がありますし、Azureでは Azure RBAC にて 「組み込みロール」 などがあるかと思います。
  それによって よくある役割（ネットワーク管理者 など）に応じた選択肢 を 選ぶだけで 認可 が 可能になるのですが、OCI の IAM では、そういった 予め用意された選択肢が ありません。
  とはいえ、よくある役割 については、マニュアル に お手本があります ので、そこまで 難易度は 高くないかと思います。

  • 共通ポリシー：
    https://docs.oracle.com/cd/E97706_01/Content/Identity/Concepts/commonpolicies.htm
    

• ポリシーの文法
  ポリシーは JSON形式 による 記述ではない 旨に 触れましたが、OCI の IAM におけるポリシー は、下記のような構文 となっています。
  
  

IDCS について

続いて、IDCS について 解説していきたいと思います。

コンポーネント

IDCS の コンポーネントは下記のようになっています。（下記以外にも色々ありますが、OCI に 関連する 代表的なものに 絞って 紹介します。）

• アイデンティティ・ドメイン … IDCS の アカウント (≒テナント) 名 を 意味します。OCI アカウント の 作成時、OCI の アカウント名 と 同じ名称で アイデンティティ・ドメイン が 自動的に 作成されています。

• ユーザ … IDCS サービス を 利用する 個人 を 意味します。OCI アカウント の 作成時、登録されたメールアドレス を 元に、IDCS の 管理者ユーザとして 登録されます。この IDCSユーザ は、IAM と連携され、同期済ユーザ として OCI 側にも 登録されます。

• グループ … ユーザ を 所属させ、この グループ に対して アクセス権限の設定を行うことで、一括して 権限設定することが 可能です。OCI アカウント の 作成時に 作成される IDCS ユーザ は、「OCI_Administrators」という IDCS グループ に所属します。

• アプリケーション … IDCS の 利用者 が サブスクライブした クラウド・サービス を 意味します。OCI アカウント の 作成時、同時に IDCS では、OCI を サブスクライブ した状態になり、OCI 上のサービス が（＋OCI Native ではないPaaSなども）アプリケーション として 自動的に 登録されます。

• アプリケーション・ロール … IDCS では、PaaS や SaaS などの アプリケーション については、そのアプリケーションへの認証設定 だけでなく、アプリケーション内 における役割（権限）の 設定 も 行えます。この 各役割（権限） を「アプリケーション・ロール」と言います。
  例えば、ユーザA も B も ログインは可能にしたいが、A は 管理者として、B は 読取り専用ユーザ としたい、といった時に、このロールが利用できます。

画面アクセス

IDCS の 管理画面 へは、コンソール画面 から 下記の順序で 行けます。

IAMとの連携

IDCS は、OCI の アカウント作成時に 自動的に、SCIM という プロトコル によって、IAM と 連携された状態（フェデレーションされた状態）で 提供 されますが、この 二者間の関係性 は、下記のようになっています。

IDCS で作成した ユーザ は、自動的に IAM 側にも「同期済ユーザ」として登録され、すぐに OCI への ログインが可能 になります。（認証方法は、IAM同様、「ユーザ名」「パスワード」、MFAを設定している場合には、「ワンタイムパスワード」など で ログインできます。）

ただし、IDCSユーザ に OCI 上の権限 を 持たせるには、必ず、OCI IAM 側のグループとマッピング済みの IDCS グループに 所属 させる必要があります。

（補足）"OCI Native" という用語について

第１弾 の 概要編 にて、Oracle Cloud が 2017年に 基盤を刷新 している という点に触れましたが、OCI Native な サービス というのは、この 刷新された OCI 基盤上 で 稼働している サービス のことを 意味します。

一口に Oracle Cloud と言っても、一部 の サービス など、この OCI 基盤 とは 異なる基盤 で 提供されているサービス も あり、そういったサービス を 利用したい場合は、IAM ではなく、IDCS による 認証・認可 が 必要になってきます。（いずれのサービス でも 同じ OCI コンソール メニュー から 選択できたりするので、ぱっと見 理解しづらいのですが… ）

例えば、下記のイメージのように、同じ PaaS であっても、「OCI Native な PaaS」と「そうでない PaaS」があったりします。

※OCI Native でない サービス も、順次 OCI Native に 対応していっている場合がありますので、ご利用に当たっては、最新情報をご確認ください。

最後に

いかがでしょうか。個人的に、IAM/IDCS は OCI を始める上で １番最初に ひっかかるポイントかな、と思っています。
この記事が、少しでも 同じように モヤモヤ していた方 の 一助になれば幸いです。

また、「より深く知りたい」「実際に触って確認したい」と思って頂けた方は、是非 無償トライアル環境 を 申し込んで頂ければ と 思います。

Oracle Cloud Free Tier：
https://www.oracle.com/jp/cloud/free/