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

:::note warn
《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)** の ２種類 が 存在しており、２つの 最も大きな 違いは、カバーしている範囲 にあります。

[<img width="634" alt="コメント 2020-06-05 162150.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/384668/5b568aeb-07bb-b425-2e1d-1b3078908045.png">](https://speakerdeck.com/ocise/ociji-shu-zi-liao-idoyobiakusesuguan-li-iam-gai-yao?slide=4)  

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

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

###コンソール画面へのログイン
第１弾 の [概要編](https://qiita.com/Skogkatter112/items/98c6f815b4e0b6556b7e) でも少し触れたのですが、IDCS と IAM という ２つの認証・認可の仕組みがあることによって、最も始めに戸惑うのが、ログインだと思います。作成したアカウントにログインする流れは、下記の通りとなっています。
<img width="657" alt="無題.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/384668/0675c226-14d9-a9a4-0dd4-343ad7d8f8c6.png">  
まず、インターネットで「OCI ログイン」と 検索頂くと、上記 左のイメージ にあるような候補 が 出てくるかと思います。

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

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

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

IAM の ログイン画面 の URL については、ホームリージョンごとに異なるので、[マニュアル](https://docs.oracle.com/cd/E97706_01/Content/GSG/Tasks/signingin.htm#one) をご参照ください。（どのリージョンから入っても ホームリージョン に リダイレクトされますが 画面遷移が増えて 手間です）

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

###その他 提供機能の違い
IDCS と IAM の その他の違い は、下記の通りとなっています。（最新情報は マニュアルをご参照ください。）
<img width="546" alt="コメント 2020-06-16 024360.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/384668/199d7590-ad20-1c78-d485-4a0b5897d7d9.png">

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

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

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

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

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

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

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

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

###画面アクセス
IAM に関連する画面 は それぞれのコンポーネントごとに画面が分かれています。コンソール画面 から 下記のメニューに アクセスしてください。
![UkME1dtVzKv0HvbhrycS1592601287-1592601409.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/384668/70dae40e-d953-a0c4-1180-7218683052fd.gif)


###認証の種類
IAM では、下記の要素を用いて 認証が行われます。
最も ポピュラーな認証方法 である「ユーザ名」「パスワード」以外に、API 利用時の認証に使える ３種類の認証情報 が 提供されています。  
<img width="686" alt="コメント 2020-06-16 184121.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/384668/10884b42-208d-c28e-2433-7d8846a06ce4.png">

それぞれの利用シーンについては、「ユーザ名」「パスワード」については 自明ですが、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）／登録済モバイル・デバイス による **ワンタイムパスワード** も 認証情報として 必要になってきます。

###認可の方法
認可 は、**その権限を与えたい グループ に対して、ポリシー を 関連付ける** ことで 設定が可能です。コンポーネントの説明でも触れましたが、必ず "グループに対して" ポリシーを関連付けます。**プリンシパル に対して 直接 関連付けることは できません**。  
[<img width="698" alt="コメント 2020-06-20 045637.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/384668/b2b33610-e966-a468-f599-5e95097ba50a.png">](https://speakerdeck.com/ocise/ociji-shu-zi-liao-idoyobiakusesuguan-li-iam-gai-yao?slide=27)

- **他社クラウドとの違い**
認可において、他社クラウドと異なるポイントとしては、**ポリシーは JSON形式で記述するものではなく**、また、**予め用意されたポリシー が ない** ということでしょうか。
他社クラウドですと、例えば AWS ですと、「[AWS管理ポリシー](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_managed-vs-inline.html)」がありますし、Azureでは Azure RBAC にて 「[組み込みロール](https://docs.microsoft.com/ja-jp/azure/role-based-access-control/built-in-roles)」 などがあるかと思います。
それによって よくある役割（ネットワーク管理者 など）に応じた選択肢 を 選ぶだけで 認可 が 可能になるのですが、OCI の IAM では、そういった 予め用意された選択肢が ありません。
とはいえ、**よくある役割 については、[マニュアル](https://docs.oracle.com/cd/E97706_01/Content/Identity/Concepts/commonpolicies.htm) に お手本があります** ので、そこまで 難易度は 高くないかと思います。

  - 共通ポリシー：  
[https://docs.oracle.com/cd/E97706_01/Content/Identity/Concepts/commonpolicies.htm](https://docs.oracle.com/cd/E97706_01/Content/Identity/Concepts/commonpolicies.htm)  


- **ポリシーの文法**
ポリシーは JSON形式 による 記述ではない 旨に 触れましたが、OCI の IAM におけるポリシー は、下記のような構文 となっています。  
[<img width="699" alt="コメント 2020-06-21 045638.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/384668/ea1d6ee4-e6b8-940f-386b-829d3d541a45.png">](https://speakerdeck.com/ocise/ociji-shu-zi-liao-idoyobiakusesuguan-li-iam-gai-yao?slide=11)

#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 の 管理画面 へは、コンソール画面 から 下記の順序で 行けます。
![8rs7KQF2Q5aQzO8OO71v1592601516-1592601945.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/384668/7d38d425-648b-06d8-c26c-f8008e76f9a7.gif)


###IAMとの連携
IDCS は、OCI の アカウント作成時に 自動的に、SCIM という プロトコル によって、**IAM と 連携された状態（フェデレーションされた状態）で 提供** されますが、この 二者間の関係性 は、下記のようになっています。  
<img width="689" alt="コメント 2020-06-21 192033.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/384668/86c2842e-8250-f58b-a81f-221622f116ae.png">

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」があったりします。
<img width="544" alt="コメント 2020-06-16 001406.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/384668/06621b1b-e5f9-39a8-5db4-a9ffff5497bf.png">

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


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

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

Oracle Cloud Free Tier：
[https://www.oracle.com/jp/cloud/free/](https://www.oracle.com/jp/cloud/free/)