Okta Access Requestsを使ってみた

# 前置き

この記事は[株式会社ビットキー 情シス Advent Calendar 2023](https://qiita.com/advent-calendar/2023/bitkey-corp-eng) の12日目の投稿です。

はじめまして。株式会社ビットキーの日浦です。
[昨日](https://qiita.com/gzock/items/a598a5695b7ce9d88616)に引き続きOktaのお話です。


https://qiita.com/gzock/items/a598a5695b7ce9d88616


弊社ではIDaaSとしてOktaを利用しています。
2022年にOkta Identity Governanceという新機能が発表され、我々も今年から利用しています。

特にAccess Requestの導入・活用に際して、代理店やコンサル企業が出している解説記事がとても参考になったのですが、そういえば利用している情シス目線での記事をあまり見かけなかったので利用者目線での情報をまとめておきます。

# Okta Access Requestsとは

2022年に発表、2023年にリリースされた**Okta Identity Governance**という新機能群の中に含まれている機能の一つです。

要するにOktaに内包された「ワークフロー」であり、すでに実装されていた「****Okta Workflows****」よりも更に簡単にOktaリソースに関わる「申請」「承認」の自動化を実現することができます。

個人的には下記のように整理しています。

- **Okta Access Requests**
    
    2023年12月現在はノーコード、Okta内のリソース（アカウントやグループ、アプリケーション）へのアサイン（Assign）やリボーク（Reboke）についてのワークフローを構築できる
    **良くも悪くもGUIからの操作のみなので、わりと誰でも実装可能**

    
- ****Okta Workflows****
    
    ローコード、Oktaの外側にあるアプリ（Google, Slack…etc）とのインテグレーションを得意とする
    **それなりにコーディングスキルや知識が必要**
    

ぶっちゃけOkta Access Requestsでやりたいことは、作り込めばOkta Workflowsでも全部できそうな気がしていますが、後述する「Slack上で全部解決可能」「Oktaの既存リソースをそのまま借用できる」という点に利用上の優位性を感じています。

# 結局Okta Access Requestsで何が嬉しいの？

情シス目線では、下記を実現できたことが一番嬉しいポイントです。

- **「一時的なアクセス許可」を実現できる**
    - 情シスがいちいちOKta上でアサイン＆リボークしなくて良い
    - 定期的なアカウント棚卸しも大幅に楽になる
- **管理者による承認業務を情シスとは手離れさせてツールの管理者に任せることができる**
    - 情シスがいちいち申請に対して承認しなくてもいい
    - 現場運用に任せてもちゃんとワークフローの記録が残る
- **一連の流れをSlack App上で実行できるので、ユーザー目線でも導入・キャッチアップコストが低い**
    - 現時点では機能や表現力に課題はありますが、Slackに慣れ親しんでいる会社であればスムーズに導入できるかと思います。

---
:::note 
実際に弊社で活用している代表的なケースを3つ紹介します
:::

# Cace1：特定のSaaSにアクセスする際に申請・承認のワークフローを実現したい

`Sample App` を利用する際に、利用者によるOkta Access Requestsからの申請と、IT管理者による承認が必要な例を考えてみます。

事前準備として、Okta上に下記リソースを作成します。
```
Okta Application：Sample App
Okta Group：App_Assign_Sample_App
```

```yaml
resource "okta_app_saml" "Sample_App" {
  label      = "Sample_App"
  logo       = "../terraform/assets/sample.png"
  admin_note = "Created by terraform"
}

resource "okta_group" "App_Assign_Sample_App" {
  name        = "App_Assign_Sample_App"
  description = "Created by terraform"
}

resource "okta_app_group_assignments" "App_Assign_Sample_App" {
  app_id = okta_app_saml.Sample_App.id
  group {
    id       = okta_group.App_Assign_Sample_App.id
    priority = 1
  }
}
```
[以前の記事](https://qiita.com/h_r_w_t_r/items/62f3516d96bb49ba86fb)でも書きましたが、弊社ではOktaのGroupとApplicationはTerraformでの管理を進めています。

https://qiita.com/h_r_w_t_r/items/62f3516d96bb49ba86fb

Okta上に作成された `App_Assign_Sample_App` を ****Okta Access Requests****アプリケーションからグループプッシュしておきましょう。

## 1. 新しいRequestを作成します

![スクリーンショット 2023-12-03 16.03.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/12368e5a-f346-aad3-893e-add949d097e9.png)

### Team
- デフォルトでITというチームが用意されています。
- 最終的な承認者としてアサインされる人たちだと思いますが、正直あまり有用な使い方を思いついていません。
### Audience
- このRequestを選択（申請）できるグループを指定します。
- Okta上でデフォルトで作成されている `Everyone at HOGE Inc.` や上述のTeam、Okta Groupを選択することができます。（Case3で後述）
### Mark as done automatically?
- 申請された「Access Request」にはステータスがあり、「自動でCloseさせるかどうか」をここで選択できます。基本的に、TRUE一択だと思うんですが、何故か作成時には有効化できません。

## 2. Requestの中身を作成する

![スクリーンショット 2023-12-12 22.43.53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/af4ebedb-1696-59bc-ed57-433675bc3864.png)


GUIからRequestの中身を作成していきます。

:::note warn
※ ちなみに2023年12月現在、GUIからしか作成できない模様
:::

### Question
    
![スクリーンショット 2023-12-03 16.27.08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/80453407-88ae-8e18-4cfe-bce328457f77.png)

    
- **利用者への質問**（「利用用途」など申請内容の説明）をテキスト形式で入力させる
- **日付**を入力させる
- Dropdownで任意の項目や、**Oktaのリソース** を選択させる

などが可能です。
    
### Task
- そういえば使ったことないな・・・割愛
### Approval
    
![スクリーンショット 2023-12-03 16.27.13 (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/0e64fa29-3bfe-ba86-212d-7350526dcd5d.png)

    
- TeamやOkta Group、特定の個人、申請者（Requester）のマネージャーなどを指定して、申請に対して「承認」や「却下」をさせることができます。
- 詳しくは後述しますが、このセクション自体が 任意項目なので、**承認不要のワークフローも作成可能**です。
### Action

![スクリーンショット 2023-12-03 16.27.18.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/992af4d6-6715-f1f1-72e3-61274b1da528.png)

    
- ここで「申請者」（Requester email）を ``App_Assitn_Sample_App`` グループにアサインするという処理を書きます。（事前にOktaグループをプッシュしておく必要があります）
    
![スクリーンショット 2023-12-03 16.27.40.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/b89ba3ca-efdc-6882-32be-d4874e90e581.png)
    
- Approvalと紐付けるため（承認を条件とするため）、ActionのLogicタブを開き、``Only show this task if``を選択します。

完了したら「Publish」しましょう。

Publish後には、Request名の右隣の鉛筆マークをクリックし、ダイアログから ``Mark as done automatically?``を有効化します（作業後、「Update」が必要です）

## 3. 実際に申請してみる

Access RequestはSlackやTeamsなどのChatツール、OktaのAccess Requestアプリケーション（GUI）から利用可能です。
※Jira/servicenowといったTicket管理ツールとのインテグレーションもできるようですが、弊社ではまだ未使用なため割愛します

### Slackからの申請

SlackにOktaアプリケーションをインストールします。

- **申請者目線**
    
    下記のように、「Choose resource…」から `Sample_Appの利用申請` を選択します
    
![スクリーンショット 2023-12-03 16.43.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/edddd7fb-fc7c-ab60-3fc1-f20dc6751450.png)

    
するとダイアログが立ち上がるため、必要な情報を入力してSubmitしてください
    
![スクリーンショット 2023-12-03 16.43.32.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/df604d75-2793-c852-cfce-96fee4d603ad.png)

    

- **IT管理者目線**
    
申請されると、承認者にOkta Appから通知が届きます。
    
![スクリーンショット 2023-12-08 13.26.11.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/2e060302-d2dc-7eac-526e-a255fb15c9c3.png)

    

- **申請者目線**
    
承認されると、Slackのスレッドに通知が来ます
    
![スクリーンショット 2023-12-03 16.48.57.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/96c3e3d2-f77d-868a-b8a5-322d19caa9f8.png)

    
OktaのダッシュボードにもSample Appが表示されました
    
![スクリーンショット 2023-12-03 16.50.05.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/662ba2e8-596d-26c0-0e93-4d13b3df70d2.png)
    

### Okta Access Requests GUIからの申請

Okta Access RequestsにはGUIも存在しており、アサインされていればOktaのダッシュボードからアクセス可能です。

正直Slack Appの使い勝手が良いので最初は不要かと思いましたが、Slack障害時の代替手段として使える他、「Oktaのアカウントは貸与しているが、Slackはゲスト」という形で参画してくださっている業務委託者の方にもAccess Requestから申請してもらえるというメリットもあります。

![スクリーンショット 2023-12-03 16.51.18.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/5a380664-3bbd-6539-03e4-9e5b359baa04.png)


![スクリーンショット 2023-12-03 16.52.13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/bd07f977-4520-f819-4fc0-37d34efdba24.png)


# Case2：特定のSaaSへのアクセスは一時的（有効期限付き）にしたい

Case1のAccess Requestは恒久的にアクセス権を付与するものでした。

しかしこの運用は実際の情シス目線だと、アカウントやアクセス権限の定期的な棚卸し等によって精査を行う必要があります（おそらくそのニーズに応えるのが「Okta Identity Governance」に含まれる「Access Certification」や「Reporting」だとは思う）

そもそもアクセス権を恒久で付与するよりも、あくまで「承認を得てから一定期間のみ」とするほうが安全なのは間違いないので、Access Requestで設定してみます。

Case1と同様に、Sample Appを例として説明しますが、実際は設定を1箇所追加するだけなので簡単です。

![スクリーンショット 2023-12-03 16.27.18 (2).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/185ffa43-61b1-f151-5971-750173ec7e20.png)


「Action」をクリックし、「Add a time limit」をクリックします

![スクリーンショット 2023-12-03 17.00.48.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/15e77e71-126d-794d-2066-9619db3590a6.png)



ダイアログが表示されるため、「承認後、アクセス権限が自動で剥奪されるまでの猶予期間」を入力しましょう。

2023年12月時点では下記が選択可能です

- Timer type
    - End after duration
        - 指定した期間経過後に剥奪
    - End on date
        - 指定した日に剥奪（Questionで日付を申請者に指定させることも可能）

Continueをクリックすると、自動的に下記のタスクが追加されます。

- **Wait for X hours**
- **Revoke: Sample Appへのアサイン**

![スクリーンショット 2023-12-03 17.04.02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/578b1395-cb9b-c254-a182-576f73de14fb.png)

![スクリーンショット 2023-12-03 17.04.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/0ff15366-8679-5c37-c62b-936048d2c523.png)



これにより、一定期間（サンプルでは3時間）経過すると申請者のSample Appへのアクセス権限は剥奪されるようになりました。

# Case3：利用は申請制にしたいが、毎回承認するのはめんどくさいから自動付与がいい

Slackから申請・承認ができるとはいえ、必要なタイミングで承認者が承認できるとは限りません。

- 普段はアクセス権限を付与しておらず、申請ベースで付与するルール
- 権限付与は一時的であり、利用の都度申請をしてもらう
- 申請記録が残っており、後から監査可能

などの条件が満たせれば、利便性を高めるために「自動付与」であってもいいというSaaSもあるかと思います。

そういった場合は、「Approval」部分を削除する（最初から作らない）ことで実現可能です。

### 承認必須パターン
![スクリーンショット 2023-12-03 17.04.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/cfed64ec-f7c6-3649-32de-f7207adec361.png)

### 承認不要パターン
![スクリーンショット 2023-12-03 17.19.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/efe2f196-c429-0434-5868-61ba5cf416ca.png)

Approvalのセクションがないため、申請されると自動でアサインされます。


# Case X

今回はすべてを紹介できませんでしたが、弊社ではアクセスや権限に関わる様々なワークフローをOkta Access Requestsで実装しています。冒頭で触れた通りAccess Request内で利用できるリソースはOkta上のユーザーやグループ、アプリケーションであり、Workflowsとのインテグレーションも可能なため、表現力は想像以上に高いです。

今後機会があれば下記についても紹介できればと思います。

- Jamfによって利用禁止にしているアプリケーションを、Access Requestにより一時的に利用許可する
- Netskopeのクライアントの強制化を、Access Requestにより一時的に無効化できるようにする
- Google Workspaceの共有ドライブへのアクセスコントロールをGoogle GroupとAccess Requestで実現する
- 申請できる人や承認できる人を `User Profile Attribute Based`でアサインすることで組織図ドリブンなワークフローの提供

# 余談。今後Access Requestに期待するアップデート

### DescriptionをSlack上に表示してほしい
マニュアルへのリンクとか貼りたいんや・・・
        
![スクリーンショット 2023-12-03 17.26.47.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/6abe04bc-b2e4-54bb-eae4-d7ce488d32a7.png)

↑ ここで書いたものはSlackやGUI上から申請時確認できないため

![スクリーンショット 2023-12-03 17.28.52.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/02f7e871-2e94-0e38-73fe-6741e7320d9e.png)


![スクリーンショット 2023-12-03 17.28.28.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/2ca030b2-5b7b-6c45-a0c2-5e0525c93526.png)

こういうあんまりイケてない運用をしている。
    

### 申請時に「入力」「選択」された内容が管理者側のSlack通知本文に記載されてほしい
    
この入力内容を見るために
    
![スクリーンショット 2023-12-03 16.45.52 (2).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/0faf0552-2421-5856-e31d-007ed33b4bbe.png)

承認者側はQuestion」をクリックしないといけないのがちょっとめんどくさい
    
![スクリーンショット 2023-12-08 13.26.11 (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/32ca4da9-2311-706b-5740-07d0f53d7346.png)

    
![スクリーンショット 2023-12-08 13.26.27.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/817f39c0-b6fa-90b9-ef23-d3b0ef043d95.png)

    
### Configuration Listsで動的に取得できるようにしてほしい
Okta Groupを動的に取得して、いちいちConfiguration Listsのアップデートをしないで良いようにしたい

### 【解決済み】Export、jsonじゃなくてCSVで出してほしい
~~jsonでしかも1申請1ファイルは流石にめんどくさい~~
※ 後述

### Typeで「Date」だけじゃなく、時間も指定したい
今だと 「12/4」という指定はできるが、できれば「12/4 12:00 - 16:00」みたいな指定がしたい
### Mark as done automatically?は作成中でもTRUEにできてよくない？
オープンされっぱなしのRequests残ってしまう問題
### Access RequestをIaCで管理したい
GroupやApplicationと同じノリでTerraformで管理したい

などなど、今年リリースされた機能なので細かい要望はありますが、総合的にはとても有用な機能で、今後Oktaを導入する際には必須な機能かと思います。

---
### 2024/01/04 追記
> Export、jsonじゃなくてCSVで出してほしい
> jsonでしかも1申請1ファイルは流石にめんどくさい

たまたま気付きましたが、Okta管理画面からいい感じに確認できました
Okta Admin > レポート > レポート > 過去の​アクセスリクエスト

![スクリーンショット 2024-01-04 16.14.21.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/545278/f5d43824-4fd7-be58-7e35-a5884e3228ad.png)