LoginSignup
2
0

Okta Access Requestsを使ってみた

Last updated at Posted 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_AppOkta Access Requestsアプリケーションからグループプッシュしておきましょう。

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

スクリーンショット 2023-12-03 16.03.48.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

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

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

Question

スクリーンショット 2023-12-03 16.27.08.png

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

などが可能です。

Task

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

Approval

スクリーンショット 2023-12-03 16.27.13 (1).png

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

Action

スクリーンショット 2023-12-03 16.27.18.png

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

スクリーンショット 2023-12-03 16.27.40.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

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

スクリーンショット 2023-12-03 16.43.32.png

  • IT管理者目線

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

スクリーンショット 2023-12-08 13.26.11.png

  • 申請者目線

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

スクリーンショット 2023-12-03 16.48.57.png

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

スクリーンショット 2023-12-03 16.50.05.png

Okta Access Requests GUIからの申請

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

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

スクリーンショット 2023-12-03 16.51.18.png

スクリーンショット 2023-12-03 16.52.13.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

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

スクリーンショット 2023-12-03 17.00.48.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

スクリーンショット 2023-12-03 17.04.07.png

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

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

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

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

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

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

承認必須パターン

スクリーンショット 2023-12-03 17.04.07.png

承認不要パターン

スクリーンショット 2023-12-03 17.19.07.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

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

スクリーンショット 2023-12-03 17.28.52.png

スクリーンショット 2023-12-03 17.28.28.png

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

申請時に「入力」「選択」された内容が管理者側のSlack通知本文に記載されてほしい

この入力内容を見るために

スクリーンショット 2023-12-03 16.45.52 (2).png

承認者側はQuestion」をクリックしないといけないのがちょっとめんどくさい

スクリーンショット 2023-12-08 13.26.11 (1).png

スクリーンショット 2023-12-08 13.26.27.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

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0