【Okta | OIGシリーズ】Access request conditions による効率的なアプリケーションアクセス申請管理

はじめに

ネクストモードのゆきなわです。

このブログシリーズでは、ID ガバナンスに特化したソリューションである Okta Identity Governance (OIG) の各機能について、実際の検証も交えてその効果および活用方法を解説していきます。

本記事では、Okta Identity Governance (OIG) の主要機能の一つである Access Requests から、 Access request conditions (Conditions) について解説します。

前半では Conditions の概要と利点を説明し、Access Requests のもう一つの機能である Request Types との比較と効果的な使い分け方を紹介します。後半では具体的なユースケースを通じて、ステップバイステップでの設定手順と実際のユーザーエクスペリエンスについて説明します。

Access request conditions (Conditions) とは

Access Requests の概要

本ブログシリーズの Request Types に関する解説記事「【Okta｜OIGシリーズ】Request Typesを試してみた）」でも触れていますが、ここでは改めて Okta Access Requests の概要から説明したいと思います。

Okta Access Requests は、Okta Identity Governance (OIG) が提供する機能の一つです。ユーザーがアプリ、グループメンバーシップ、エンタイトルメントバンドル (Entitlement Bundles) ※1 といったリソースへのアクセス権を自身でリクエストできるセルフサービスポータルを提供します。ユーザーは Okta ダッシュボード (Okta End-User Dashboard) と統合された Access Requests アプリを通じて、必要なアクセス権を申請し、管理者が事前に定義した承認フロー ※2 に基づいて承認を得ることができます。

※1 特定の権限セットをまとめたもの
※2 承認フローは申請から承認までの業務プロセスを示す一般的な用語ですが、Okta の Conditions では承認シーケンス (Approval Sequences) と呼びます（「Conditions とは」で後述）。

Access Requests の主な目的は、アクセス権の付与・剥奪プロセスを自動化し、社内 IT 部門やヘルプデスクの運用負荷を軽減することです。同時に、誰が何にアクセスできるかを明確にし、適切な承認プロセスを経ることで、組織全体のガバナンスとコンプライアンスを強化します。

Conditions の概要

Conditions は、Request Types と並ぶ Access Requests の主要機能であり、アプリ（Okta で設定したアプリ統合）ごとにカスタマイズ可能なアクセス申請ルールを定義するための仕組みです。具体的には、

1. Requester scope: どのユーザー（どのグループのメンバー）がアクセスを申請可能か
2. Access level: ユーザーが申請できるアクセス権限のレベル
3. Access Duration: アクセス期間をどのように設定するか
4. Approval sequence: どの承認シーケンスを用いるか

といったユーザーのアプリケーションアクセスに対する条件を定義することができます。

ここで、Conditions における承認シーケンスとは、申請者への質問、タスク、承認、アクションとして実行する Okta Workflows フローなどのステップから成る一連のプロセスです。承認シーケンスを通じて、アプリへのアクセス申請をどのように処理するかを設定します。シーケンスの各ステップでは、申請時にユーザーが提供する情報、承認・拒否の担当者（承認者）、シーケンスの中で実行するアクションを具体的に定義できます。

Conditions を活用することで、ユーザーごとのアクセス権限管理を効率化すると同時に、アプリへのアクセス申請プロセスにおいて一貫したユーザーエクスペリエンスを実現できます。

Conditions の利点

Okta 公式ドキュメントの内容を補足しつつ、その利点について説明します。

1. 設定の容易さと高いスケーラビリティ

   • アプリに関連付けられた既存の Okta グループをそのまま条件設定に活用可能です。1つ以上のグループをまとめて条件に指定することもできます。

   • Entitlements（権限）、Entitlement bundles（権限バンドル）※を有効化している場合、それらを条件として使うことができます。

   • 承認シーケンスは事前定義された9種類のテンプレート（下図）から選択、カスタマイズを行うことで、定型的なものから自由度の高いフローまで効率的に作成することが可能です。例えば、テンプレート “Justification + Manager Approval” を選ぶことで、ユーザーからの申請理由を上長が閲覧して承認するまでの一連のフローをワンクリックで作成することが可能です。

     

   • 作成した承認シーケンスは複数のアプリの条件として適用できるため、アプリごとに作り直す手間がなく、スムーズに運用できます。

   このように、多数のアプリやリソースを管理する際に設定を再利用できるため、アプリごとの設定作業を大幅に効率化することができます。

   ※ Entitlement、Entitlement bundles については、下記公式ドキュメントを参照してください。

   • Entitlement Management | Okta

2. Okta ダッシュボード (Okta End-User Dashboard) との統合

   • ユーザーは自身のダッシュボードの中にあるリソースカタログから対象アプリを選択し、そこに表示される項目を入力するだけで、シンプルにアクセス申請が行えます。
   • ユーザーはアプリへのアクセス申請の際、Okta Access Requests の専用画面を開き、Request Types （リクエストタイプ）の中から適切なものを探す手間が不要となります。

   このように、エンドユーザーの立場ではダッシュボードからのシンプルな操作で申請手続きが完結します。これによりユーザーエクスペリエンスが向上し、管理者への問い合わせや操作トレーニングの手間も軽減できます。

Request Types との機能比較と使い分け

ここまでの説明で、Okta Access Requests の Request Types についてご存知の方は、Conditions との機能的な重複を感じられたのではないでしょうか。以下の表では、Conditions と Request Types それぞれの特徴を比較し、効果的な使い分け方を明らかにします。

ユースケース

シナリオ

具体的な利用例として、Conditions を使用したアプリへのアクセス権限の申請と付与の基本的なケースを紹介します。今回のシナリオでは、特定のグループ（ConditionsPoCGroup1）に所属するユーザーに対して、AWS Account Federation アプリの1時間の利用を許可する設定とします。以下に Okta の設定詳細を示します。

ユーザー設定

対象アプリ

• AWS Account Federation（事前に Okta のアプリ統合で設定済みとします）

Access request condition

設定手順（管理者）

以下に示す、1) アプリ統合画面の Access Requests へのアクセス、2) Access request condition の作成、3) 承認シーケンスの新規作成、4) 作成した Access request condition の有効化、の4ステップに従い設定します。

1. アプリ統合画面の Access Requests へのアクセス
   
   Admin Console メニューから Applications > Applications を開き、今回の設定対象となるアプリ統合 AWS Account Federation を選択し、Access Requests タブを選択します（下図: 1）。Access Requests アプリの認証後、Create condition ボタンを押下します（下図: 2）。

   

2. Access request condition の作成
   
   前述のシナリオの内容に沿って Access request condition を下図の通り設定していきます。

   

   1: Condition name を設定します。本例では Condition 1 とします。

   2. 3: Requester scope には、Requester として Specific groups を選択し、Groups として ConditionsPoCGroup1 を設定します。

   4: Access level には Only app を指定し、アプリへのアクセス権限のみを設定します。

   5, 6, 7: Access duration では、Access duration のオン、オプションとして Specify expiration now を選択し、値と単位にはそれぞれ 1、Hours を設定します。

   8: Approval sequence には、これから作成する承認シーケンス Justification + Group Member Approval を設定します（上図は作成・設定済みの状態となります）。承認シーケンスの作成手順については、以下の 3. 承認シーケンスの新規作成を参照してください。

   9: 1から8の設定が完了したら、Create ボタンを押下します。

3. 承認シーケンスの新規作成
   
   Access request condition の作成画面の Approval Sequence にて、Select sequence ボタンを押下します。画面が遷移するので、New sequence を押下します（下図）。

   

   新規ウインドウで承認シーケンス作成画面が開きます。Templates ボタンを押下し（下図: 1）、表示されるテンプレートから今回利用する Justification + Group Member Approval を選択します。（下図: 2）

   

   選択したテンプレートの内容に従って、作成画面左のシーケンス図が更新されます。

   

   1, 2: Approval を押下すると画面右に詳細設定が表示されるので、Assign to に承認者となる Okta グループ AppAccessApprovers を指定します。

   3: Approval sequence 名を Justification + Group Member Approval に設定します。

   4: Save ボタンを押して承認シーケンスを保存・パブリッシュします。

   以上により、Access request condition 作成画面から承認シーケンスが選択可能になります。

4. 作成した Access request condition の有効化
   
   アプリ統合の画面に戻ります。ステップ 2 で作成した Access request condition は、作成直後は無効化されているので画面右のメニューボタンを押下し Enable を選択し有効化します（下図）。

   

以上で設定は完了です。

ユーザー利用方法（申請者・承認者）

ここでは、申請者と承認者それぞれの具体的な操作手順と実際のユーザーエクスペリエンスについて説明します。

1. 申請者
   
   Okta ダッシュボード (Okta End-User Dashboard) にログインし、アクセスを要求する (Request access) ボタンを押下します（下図）。

   

   Access Requests アプリの認証後、Conditions の設定によりアクセス申請可能なアプリ一覧が表示されます※。AWS Account Federation アイコンを押下します（下図）。

   ※ 条件に当てはまらないユーザーの場合、該当のアプリは表示されません。

   

   設定した Access request condition Condition 1 の内容に従い、Access level の選択画面に遷移します（下図）。

   

   1: Access level を選択します。今回設定した Condition 1 ではアプリへのアクセス権限のみ設定されているため、Default application access のみが選択可能となっています。選択後、画面右に Access duration に関する情報と承認シーケンスで求められる入力欄が表示されます。

   2-3: 作成・設定した承認シーケンス Justification + Group Member Approval に従い、申請理由が求められているので適切な内容で入力します。Submit request ボタンを押下して申請を完了します。

   承認者により承認されると※、ダッシュボードに AWS Account Federation が現れます（下図）。
   ※ 承認・否決はメール、Slack などで通知されます。

   

   以上により、ユーザーはアプリにアクセスできるようになりました！

2. 承認者
   
   承認者にはメール、Slack などでアクセス申請通知が届きます。Access Requests アプリにログインし、該当のリクエストを確認し、承認・否決を行います（下図、承認の場合）。

   

まとめ

本記事では、Okta Identity Governance の Access Requests における Access request conditions (Conditions) 機能の概要と基本的なユースケースを解説しました。Conditions の利用により、アプリごとにアクセス申請のルールを柔軟かつ効率的に設定できます。

Conditions の主な利点:

• 効率的な管理と拡張性: 設定を再利用でき、多数のアプリのアクセス管理も容易です。
• ユーザー体験向上: ユーザーは Okta ダッシュボードから簡単にアクセス申請できます。
• ガバナンス強化: 適切な承認プロセスにより、セキュリティと統制を向上させます。

特に次のようなケースでおすすめです。

• 管理するアプリが多い。
• アクセス権管理を自動化・効率化したい。
• 標準化されたルールや承認プロセスを適用したい。
• 一時的なアクセス権を安全に管理したい。

なお、今回はご紹介しきれませんでしたが、Conditions は複数の条件を組み合わせたり、Entitlement Bundles と連携させたりすることで、さらに高度なアクセス管理や特権管理も実現できます。これら応用的な活用については、また別の機会にご紹介できればと思います。本記事が、皆様のアクセス管理改善のヒントとなれば幸いです。

OIG シリーズでは、これからも Okta Identity Governance の多様で便利な機能を紹介していきます。ぜひ、今後の記事もチェックしてください。

Okta についてのお問い合わせ

Okta Identity Governance の導入、Access Requests の実践的な活用方法、ライセンス体系や価格についてさらに詳しく知りたい方は、ぜひ弊社窓口までお気軽にお問い合わせください。

• お問い合わせ | ネクストモード株式会社

弊社サービス「Okta ライセンス＆サポート」では、Okta の導入から運用、活用まで、経験豊富なエンジニアがお客様を手厚くサポートいたします。

• Okta ライセンス＆サポート | ネクストモード株式会社