株式会社ビットキー情シスAdvent Calendar 2023

株式会社ビットキー / Bitkey Inc.

Okta Access Requestsを使ってみた

okta

Last updated at 2024-01-04Posted at 2023-12-12

前置き

この記事は株式会社ビットキー情シス Advent Calendar 2023 の12日目の投稿です。

はじめまして。株式会社ビットキーの日浦です。
昨日に引き続きOktaのお話です。

弊社では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に慣れ親しんでいる会社であればスムーズに導入できるかと思います。

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

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

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

事前準備として、Okta上に下記リソースを作成します。

Okta Application：Sample App
Okta Group：App_Assign_Sample_App

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
  }
}

以前の記事でも書きましたが、弊社ではOktaのGroupとApplicationはTerraformでの管理を進めています。

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

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

Team

デフォルトでITというチームが用意されています。
最終的な承認者としてアサインされる人たちだと思いますが、正直あまり有用な使い方を思いついていません。

Audience

このRequestを選択（申請）できるグループを指定します。
Okta上でデフォルトで作成されている Everyone at HOGE Inc. や上述のTeam、Okta Groupを選択することができます。（Case3で後述）

Mark as done automatically?

申請された「Access Request」にはステータスがあり、「自動でCloseさせるかどうか」をここで選択できます。基本的に、TRUE一択だと思うんですが、何故か作成時には有効化できません。

2. Requestの中身を作成する

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

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

Question

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

などが可能です。

Task

そういえば使ったことないな・・・割愛

Approval

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

Action

ここで「申請者」（Requester email）を App_Assitn_Sample_App グループにアサインするという処理を書きます。（事前にOktaグループをプッシュしておく必要があります）

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の利用申請 を選択します

するとダイアログが立ち上がるため、必要な情報を入力してSubmitしてください

IT管理者目線

申請されると、承認者にOkta Appから通知が届きます。

申請者目線

承認されると、Slackのスレッドに通知が来ます

OktaのダッシュボードにもSample Appが表示されました

Okta Access Requests GUIからの申請

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

承認必須パターン

承認不要パターン

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

Case X

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

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