ネクストモードのゆきなわです。
このブログシリーズでは、ID ガバナンスに特化したソリューションである Okta Identity Governance (OIG) の各機能について、実際の検証も交えてその効果および活用方法を解説していきます。
本記事では、Okta Identity Governance (OIG) の主要機能の一つである Access Requests から、 Access request conditions (Conditions) について解説します。
前半では Conditions の概要と利点を説明し、Access Requests のもう一つの機能である Request Types との比較と効果的な使い分け方を紹介します。後半では具体的なユースケースを通じて、ステップバイステップでの設定手順と実際のユーザーエクスペリエンスについて説明します。
本ブログシリーズの 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 は、Request Types と並ぶ Access Requests の主要機能であり、アプリ（Okta で設定したアプリ統合）ごとにカスタマイズ可能なアクセス申請ルールを定義するための仕組みです。具体的には、
といったユーザーのアプリケーションアクセスに対する条件を定義することができます。
ここで、Conditions における承認シーケンスとは、申請者への質問、タスク、承認、アクションとして実行する Okta Workflows フローなどのステップから成る一連のプロセスです。承認シーケンスを通じて、アプリへのアクセス申請をどのように処理するかを設定します。シーケンスの各ステップでは、申請時にユーザーが提供する情報、承認・拒否の担当者（承認者）、シーケンスの中で実行するアクションを具体的に定義できます。
Conditions を活用することで、ユーザーごとのアクセス権限管理を効率化すると同時に、アプリへのアクセス申請プロセスにおいて一貫したユーザーエクスペリエンスを実現できます。
Okta 公式ドキュメントの内容を補足しつつ、その利点について説明します。
設定の容易さと高いスケーラビリティ
アプリに関連付けられた既存の Okta グループをそのまま条件設定に活用可能です。1つ以上のグループをまとめて条件に指定することもできます。
Entitlements（権限）、Entitlement bundles（権限バンドル）※を有効化している場合、それらを条件として使うことができます。
承認シーケンスは事前定義された9種類のテンプレート（下図）から選択、カスタマイズを行うことで、定型的なものから自由度の高いフローまで効率的に作成することが可能です。例えば、テンプレート “Justification + Manager Approval” を選ぶことで、ユーザーからの申請理由を上長が閲覧して承認するまでの一連のフローをワンクリックで作成することが可能です。
作成した承認シーケンスは複数のアプリの条件として適用できるため、アプリごとに作り直す手間がなく、スムーズに運用できます。
このように、多数のアプリやリソースを管理する際に設定を再利用できるため、アプリごとの設定作業を大幅に効率化することができます。
※ Entitlement、Entitlement bundles については、下記公式ドキュメントを参照してください。
Okta ダッシュボード (Okta End-User Dashboard) との統合
このように、エンドユーザーの立場ではダッシュボードからのシンプルな操作で申請手続きが完結します。これによりユーザーエクスペリエンスが向上し、管理者への問い合わせや操作トレーニングの手間も軽減できます。
ここまでの説明で、Okta Access Requests の Request Types についてご存知の方は、Conditions との機能的な重複を感じられたのではないでしょうか。以下の表では、Conditions と Request Types それぞれの特徴を比較し、効果的な使い分け方を明らかにします。
| 項目 | Conditions (Access request conditions) | Request Types |
|---|---|---|
| 概要・用途の違い | 特定のアプリに対して、1) 誰が、2) どのレベルのアクセスを、3) どの期間、4) どの承認シーケンスで付与するかを定義し、アクセス申請を処理。 | 特定の用途や状況に合わせた個別の申請フォームや承認シーケンスを設定し、それぞれの目的に応じて申請を処理。 |
| 設定の再利用性・拡張性 | 複数のアプリ間でグループや権限設定を共有・再利用できるため拡張性が高く、多数のアプを管理しやすい。 | 個別の入力フォームや承認シーケンスを Request Type ごとに設計する必要があり、数が多くなると管理が複雑化しやすい。 |
| プライバシー設定 | デフォルトでリクエストがプライベートとなり、申請者、承認者、担当者、管理者など関係者のみが閲覧・対応可能。 | ユースケースに応じてプライバシー設定を調節可能。 |
| ユーザー（申請者）の 利便性・使いやすさ | エンドユーザーダッシュボードのリソースカタログから直感的に申請できる。 | 複数の Request Types から用途に応じて適切なものを選ぶ必要があるため、ユーザーに対して申請手順に関する情報の事前周知が必要。 |
| 承認フロー・ルーティング | 承認シーケンスを再利用でき、複数アプリに共通の承認フローを簡単に適用することで設定の手間を削減。 | 個別ケースに特化した承認フローの構築が可能。ただし、リソースごとの構築が必要なため再利用性は限定的。 |
| どのようなケースで効果的か |
不定期に利用が必要な業務アプリケーションや、全社共通で利用する主要な業務アプリケーション (例: Microsoft 365, Google Workspace) へのアクセス権限を、部署や役職に応じて標準化されたフローで管理したい場合。 |
特定のプロジェクトメンバーのみが期間限定で利用する特殊な開発ツールへのアクセス申請や、アプリへのアクセスが起点とはならない機密情報アクセスなど、個別の承認ステップや情報入力が必要な場合。 |
具体的な利用例として、Conditions を使用したアプリへのアクセス権限の申請と付与の基本的なケースを紹介します。今回のシナリオでは、特定のグループ（ConditionsPoCGroup1）に所属するユーザーに対して、AWS Account Federation アプリの1時間の利用を許可する設定とします。以下に Okta の設定詳細を示します。
ユーザー設定
| ユーザー | 所属グループ | 備考 |
|---|---|---|
| 申請者 | ConditionsPoCGroup1 | AWS の運用保守に関わるチームを想定 |
| 承認者 | AppAccessApprovers | アプリの管理権限を持つチームが承認を行う運用を想定 |
対象アプリ
Access request condition
| 項目 | 設定値 | 備考 |
|---|---|---|
| Requester scope (対象ユーザー) | Okta グループ ConditionsPoCGroup1 に所属 | 全ユーザーを対象とすることも可能 |
| Access level (アクセス権) | アプリケーションアクセスのみ | アプリケーションに紐づいたグループへの割り当ても可能 |
| Access duration (アクセス期間) | 承認後1時間（緊急メンテナンスなど一時的なアクセスを想定） | ・最短1時間から最長12週間まで設定可能 ・期限なし、申請者による指定なども設定可能 |
| Approval sequence (承認シーケンス) |
テンプレート Justification + Group Member Approval から作成 |
以下に示す、1) アプリ統合画面の Access Requests へのアクセス、2) Access request condition の作成、3) 承認シーケンスの新規作成、4) 作成した Access request condition の有効化、の4ステップに従い設定します。
アプリ統合画面の Access Requests へのアクセス
Admin Console メニューから Applications > Applications を開き、今回の設定対象となるアプリ統合 AWS Account Federation を選択し、Access Requests タブを選択します（下図: 1）。Access Requests アプリの認証後、Create condition ボタンを押下します（下図: 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 ボタンを押下します。
承認シーケンスの新規作成
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 作成画面から承認シーケンスが選択可能になります。
作成した Access request condition の有効化
アプリ統合の画面に戻ります。ステップ 2 で作成した Access request condition は、作成直後は無効化されているので画面右のメニューボタンを押下し Enable を選択し有効化します（下図）。
以上で設定は完了です。
ここでは、申請者と承認者それぞれの具体的な操作手順と実際のユーザーエクスペリエンスについて説明します。
申請者
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 などで通知されます。
以上により、ユーザーはアプリにアクセスできるようになりました！
承認者
承認者にはメール、Slack などでアクセス申請通知が届きます。Access Requests アプリにログインし、該当のリクエストを確認し、承認・否決を行います（下図、承認の場合）。
本記事では、Okta Identity Governance の Access Requests における Access request conditions (Conditions) 機能の概要と基本的なユースケースを解説しました。Conditions の利用により、アプリごとにアクセス申請のルールを柔軟かつ効率的に設定できます。
Conditions の主な利点:
特に次のようなケースでおすすめです。
なお、今回はご紹介しきれませんでしたが、Conditions は複数の条件を組み合わせたり、Entitlement Bundles と連携させたりすることで、さらに高度なアクセス管理や特権管理も実現できます。これら応用的な活用については、また別の機会にご紹介できればと思います。本記事が、皆様のアクセス管理改善のヒントとなれば幸いです。
OIG シリーズでは、これからも Okta Identity Governance の多様で便利な機能を紹介していきます。ぜひ、今後の記事もチェックしてください。
Okta Identity Governance の導入、Access Requests の実践的な活用方法、ライセンス体系や価格についてさらに詳しく知りたい方は、ぜひ弊社窓口までお気軽にお問い合わせください。
弊社サービス「Okta ライセンス＆サポート」では、Okta の導入から運用、活用まで、経験豊富なエンジニアがお客様を手厚くサポートいたします。