アクセスリクエスト

Okta Identity Governanceは、サブスクリプションベースで一般利用可能です。詳細については、担当のアカウントエグゼクティブまたはカスタマーサクセスマネージャーにお問い合わせください。

Okta orgに直接統合されたアクセスリクエストは、アプリケーション、グループ、エンタイトルメントバンドルへのアクセスをリクエストするプロセスを自動化します。Oktaの既存のセルフサービスサービスを拡張するアクセスリクエストにより、アクションのためにユーザーリクエストを1人以上の承認者に自動的にルーティングする簡素化されたスムーズなアプローチが提供されます。

このため、アクセスリクエストにより、従来のワークフローに共通する以下のような課題を排除できます。

  • リクエストエクスペリエンスが悪い
  • ヒューマンエラーのリスク
  • ITの生産性の低下
  • 複雑で厳格なワークフロー
  • 監査とコンプライアンスの不備

管理者ロールのアクセスリクエストの合理化については、代わりに「Okta管理者ロールを管理する」と「アクセスリクエスト管理者ロール」を参照してください。

orgの適格性によっては、Okta管理者ロールの管理を利用できない場合があります。詳細については、アカウントエグゼクティブまたはカスタマーサクセスマネージャーまでお問い合わせください。

ロール

アクセスリクエストは、異なる組織のロールに対するニーズを満たします。

ロール 説明
要求者 要求者はリソースへのアクセスを要求するユーザーであり、必要な手順が完了するとリソースが割り当てられます。要求者は、チャット、メール、Webなどの一般的な生産性向上ツールを使用して、特定のリソースへのアクセスをすばやくリクエストしたいと考えています。

ユーザーがリクエストを作成したり、アクセスリクエストコンポーネントでリクエストを参照したりするには、ユーザーがOkta アクセスリクエストアプリに割り当てられている必要があります。

リクエスト作成者

他者に代わってリクエストを送信するユーザーをリクエスト作成者と呼びます。アクセスを要求したユーザーが要求者です。要求者は、リソースへのアクセスを最終的に獲得するユーザーです。

承認者 承認者は、何を誰のために承認するかを理解できるように、リクエストの明確な可視性とコンテキストを必要とします。

承認者は、効率を向上させてリクエストを迅速に解決するために、チャット、メール、Webなどの一般的な生産性向上ツールを使って承認をレビューする必要があります。

管理者 管理者は、リクエストを完了する前に関係者が適切なアクションを実行できるように、独自のコードなしブループリントを作成したいと考えています。

管理者は、チームが低リスクのアクセスリクエストを管理する責任を負わないように、自動化されたリクエスト実施を調整したいと考えています。

コンポーネント

アクセスリクエストでは、次のコンポーネントの組み合わせを使用します。

コンポーネント 説明

リクエスト

リクエストは、リソースへのアクセスに対するユーザーの希望の記録です。各リクエストにはリクエストタイプが割り当てられます。リクエストは、リソースのリクエストタイプに定義された手順に従います。

これには、リクエスト作成者、要求者、ステータス、メッセージなどの詳細情報が含まれます。

アクセスリクエストチーム チームを使用すると、アクセスリクエスト内でユーザーを論理グループに編成できます。「アクセスリクエストチームを作成する」を参照してください。

チームは、リクエストタイプを作成し、関連するリクエストを管理できます。

1つ以上のチームをリクエストタイプに関連付けて、それらのチームにそのリクエストタイプとそれに対応する受信リクエストの管理を任せることもできます。リクエストタイプ内での承認タスクの処理には、チームではなくグループを利用することをお勧めします。

自動化されたタスクでリソースを使用するには、目的のリソースにチームを追加します。

リクエストタイプ リクエストタイプは、アクセスリクエストの処理方法を定義します。各リクエストタイプは1つ以上の手順で構成されます。これらの手順は、要求者がリクエストを送信した後のレビューのために適切な担当者にルーティングされます。

アクセスリクエスト チームは、リクエストタイプを作成して所有します。「リクエストタイプ」を参照してください。

手順

手順は、質問、タスク(カスタム、承認、アクション)、タイマーなど、リクエストタイプに追加できる項目です。

質問とタスクは、その完了をユーザーに割り当てることができる手順です。手順をユーザーに割り当てると、手順の担当者にアクセスリクエストが通知を送信します。

オーディエンス オーディエンスは、特定のリクエストタイプのリクエストを送信できるユーザーを制御します。オーディエンスメンバーは、仲間のオーディエンスメンバーに代わってアクセスを要求することもできます。

チームは、リクエストタイプを全員が利用できるようにすることも、特定のアクセスリクエストチームまたはOktaグループに制限することもできます。

リクエスト担当者 担当者は常に、リクエストタイプを所有するアクセスリクエストチームのメンバーであり、送信されたリクエストを管理します。

担当者は、個々のタスクまたは承認を再割り当てして、リクエストが迅速に完了するようにする責務を負います。

リソース

リソースは統合から直接同期されます。現在、アクセスリクエストでは、Okta、Jira、Service Nowからのリソースの同期が可能です。

リソースから構成リストを作成し、リクエストタイプで利用できます。アクセスリクエストコンソールからリソースを修正することはできません。

デフォルトでは、アクセスリクエストは関連するOkta orgと同期され、アプリケーション、Oktaグループ、Okta Workflows、エンタイトルメントバンドルなどのリソースを作成します。

  • アクセスリクエストコンソールでOkta Workflowsオプションを利用できるのは、orgの[Access Requests(アクセスリクエスト)]および[Assign admin roles to apps(アプリに管理者ロールを割り当てる)]機能のOkta Workflowsアクションが有効化され、Okta Access Request OAuthアプリが管理者として割り当てられている場合のみです。[Access Requests(アクセスリクエスト)]内のOkta Workflowsアクションは早期アクセス機能です。これを有効化する方法については、「セルフサービス機能を有効にする」を参照してください。また、「はじめに」も参照してください。
  • エンタイトルメントバンドルを利用できるのは、アプリのGovernance Engineが有効化され、管理者がエンタイトルメントとエンタイトルメントバンドルを作成した場合のみです。「エンタイトルメント管理を開始する」を参照してください。

構成リスト

構成リストは、リソースまたは管理者が定義した値がカスタマイズされたコレクションです。チームがリクエストタイプで使用できるアプリケーションまたはグループを決定します。これをリクエストタイプで使用して、エンドユーザーが使用できるオプションを特定したり、リクエストタイプ内での自動アクションの動作をコントロールしたりできます。

リソースタイプごとに個別の構成リストを作成する必要があります。

たとえば、管理者がリクエストタイプの作成中に要求者への割り当てにいくつかのグループを利用できるようにするとします。さらに、ユーザーがいくつかのアプリケーションをリクエストできるようにするとします。このようなときは、アプリケーション用とグループ用にそれぞれ構成リストを作成する必要があります。

構成リストには2つのタイプがあります。

  • リソースリスト

    リソースリストは、リソースから作成される構成リストです。リソースへのアクセスを自動化するには、リソースから構成リストを作成し、リソースタイプでそれを参照します。

    たとえば、ユーザーは、特定のOktaグループで利用可能なアプリケーションへのアクセスのみをリクエストできる場合があります。リソースリストを作成し、エンドユーザーが使用できるアプリケーションを含めます。次に、リクエストタイプのリソースリストを参照し、特定のOktaグループのメンバーのみがリクエストタイプを利用できるように構成します。

    Workflowsベースのリソースリストは作成できません。

  • カスタムリスト

    カスタムリストは、リクエストタイプで参照可能な、管理者によって定義される値のリストです。これはリソースに関連付けられません。カスタムリストを使用すると、組織のニーズをより適切に満たすことができます。

    たとえば、チームは、利用可能なラップトップモデルをリストする構成リストを作成する場合があります。要求者がラップトップのリクエストを提出する場合、要求者はリクエストを行う際に利用可能なモデルの1つを選択できます。