アクセスリクエスト

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

これにより、アクセスリクエストは従来のリクエスト管理プロセスで一般的な次のような課題を排除できます。

リクエストエクスペリエンスが貧弱
人的エラーのリスク
IT生産性の低下
複雑で硬直的なプロセス
監査とコンプライアンスの不備

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

Okta管理者ロールの管理は早期アクセス機能です。ただし、Okta Identity Governanceをサブスクライブしている方向けには公開されています。

スーパー管理者としてアクセスリクエスト条件およびリソースカタログ機能を有効化すると、条件とリクエストタイプを使ってリクエストを合理化できるようになります。アプリ管理者ロール割り当てを持つアクセスリクエスト管理者は、条件の作成と管理を行うこともできます。

条件

条件は、誰がアクセスをリクエストできるか、リクエストできるアクセスのレベル、アクセス期間、Admin Consoleでのアプリのプロファイルページからの直接的な各アプリの承認シーケンスを定義するルールです。承認シーケンスは、質問、Okta Workflows、承認、タスクなどの一連の直線的なステップです。これらのステップは、特定のユーザーが提供する必要がある情報、要求の承認または拒否を担当するユーザー、完了する必要があるアクションを管理します。

アクセスリクエストを初めて使用するときは、最初に条件を使ってアクセスリクエストを管理します。
リクエストタイプ

リクエストタイプは、リクエストのライフサイクルを定義する構造化フローです。これらのフローは、質問、タスク、タイマーなどのステップから構成されます。リクエストタイプは、構成リストを使ってリソース（アプリ、グループ、エンタイトルメントバンドル）と関連付けることができます。各アクセスリクエストチームは、複数のリクエストタイプと関連リクエストを所有および管理します。自動化された一部のアクションは、Oktaや、Jira、ServiceNowなどの統合外部システムでセットアップすることもできます。

要求者は、リクエストタイプを使ってエンドユーザーダッシュボードからOkta アクセスリクエストWebアプリに移動してリクエストタイプを選択し、アクセスを要求するために必要な情報を入力します。要求者は、SlackまたはMicrosoft Teamsからアクセスを要求することもできます（アクセスリクエストと統合されている場合）。

リクエストタイプを作成してOkta管理者ロールバンドルのアクセスリクエストを管理することはできません。

メリット

セルフサービスの自動化

誰がどのリソースへのアクセスを要求できるか、リクエストの承認を担当するユーザー、リソースへのアクセス期間を定義するコードなしプロセスを作成します。これにより、ユーザーはセルフサービスでリソースへのアクセスを要求できます。
多段階のリクエストルーティング

リクエストタイプまたは承認シーケンスを使用することで、コンテキストの提供やリクエストの承認などの手動タスクを要求者、承認者、タスク担当者に自動的に委任できます。実行する委任されたフローを承認シーケンスまたはリクエストタイプからトリガーすることもできます。

重要なリクエストが必要な監視を受け、十分にレビューされるように、1つ以上の承認タスクを特定のユーザーに割り当てることができます。リクエストの承認または拒否の正当性を取り込んで最終的にレポートすることもできます。
オムニチャンネルのサポート

ユーザーは、リクエストの合理化に使用している方式に応じて、OktaアクセスリクエストWebアプリ、Slack、またはMicrosoft Teamsからアクセスリクエストを操作または承認できます。

アクセスリクエスト条件を有効化している場合、さらにいくつかの利点があります。

拡張性と構成しやすさ

条件内でアプリと関連付けられている既存のOktaグループを再利用して、そのスコープを制御します。条件内の複数のグループを参照できます。アプリのエンタイトルメントとエンタイトルメントバンドルを構成した場合、それを使ってスコープを定義できます。

アクセスリクエスト条件では、条件内の承認シーケンスを別のアプリで再利用することもできます。つまり、リクエストタイプの場合と同様に、アプリごとにリクエストルーティングフローを再作成する必要はありません。
要求者のエンドユーザーダッシュボードとの統合

要求者は、エンドユーザーダッシュボードのOkta アクセスリクエストWebアプリに移動して、必要なアクセスを得るためにどのリクエストタイプを選択するかを決定する必要はありません。エンドユーザーダッシュボードのリソースカタログに移動してアプリのタイルを選択し、アクセスのリクエストに必要な情報を入力できます。

SlackまたはMicrosoft Teamsを使ったアプリへのアクセスリクエストは、条件によって管理されるアプリではサポートされません。

ペルソナ

アクセスリクエストは、いくつかの異なる組織ロールのニーズに対応します。

ロール	説明
管理者	標準のスーパー管理者ロールまたはアクセスリクエスト管理者ロールが割り当てられているユーザー。管理者は、リクエストを完了する前に関係者が適切なアクションを実行できるように、独自のノーコードブループリントを作成したいと考えています。管理者は、チームが低リスクのアクセスリクエストを管理する責任を負わないように、自動化されたリクエスト実行をオーケストレーションしたいと考えています。
要求者	リソースへのアクセスを要求するユーザーであり、必要な手順が完了するとリソースが割り当てられます。要求者は、チャットやWebなどの一般的な生産性向上ツールを使って特定リソースへのアクセスを迅速に要求したいと考えています。
リクエスト作成者	他者に代わってリクエストを送信するユーザーをリクエスト作成者と呼びます。アクセスを要求した人物は要求者です。要求者は、リソースへのアクセスを最終的に獲得するユーザーです。
承認者	自分に割り当てられている承認タスクへの対応を担当するユーザーです。承認者は、誰のために何を承認するかを理解できるように、リクエストの明確な可視性とコンテキストを必要とします。承認者は、効率を向上させてリクエストを迅速に解決するために、チャットやWebなどの一般的な生産性向上ツールを使って承認をレビューする必要があります。
タスク割り当て先	リクエストで自分に割り当てられたカスタムタスクや質問への対応を担当するユーザーです。
リクエスト割り当て先	送信後のリクエストの管理側面の管理を割り当てられているスーパー管理者、アクセスリクエスト管理者、チームメンバー（リクエストタイプによって管理されるリクエストの場合）。リクエストが迅速に完了するように、未割り当てのステップや承認者の再割り当てなどの管理を担当します。条件によって管理されるリクエストでは、Oktaはリクエスト割り当て先を自動的に割り当てません。スーパー管理者とアクセスリクエスト管理者は、アクセスリクエストWebアプリを使って、リクエスト割り当て先の表示や編集を行うことができます。リクエストタイプによって管理されるリクエストでは、リクエスト割り当て先は常に、そのリクエストタイプを所有するアクセスリクエストチームのメンバーとなります。