アクセスリクエスト

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

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

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

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

• 条件

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

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

• リクエストタイプ

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

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

  リクエストタイプを作成してOkta管理者ロールバンドルのアクセスリクエストを管理することはできません。また、リクエストタイプによって管理されるアクセスリクエストを使って、Okta管理者ロールを付与するグループを割り当てることはできません。このようなグループをリクエストしたユーザーは、リクエストの詳細ページでエラーを受け取ります。

メリット

• セルフサービスの自動化

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

• 多段階のリクエストルーティング

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

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

• オムニチャンネルのサポート

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

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

• Okta管理者ロールの割り当てへのアクセスを制御する

  管理者ロールのバンドルと条件を構成したら、適格な要求者はダッシュボードから管理者アクセスをリクエストできます。リクエストが承認された場合に管理者ロールへのアクセスが要求者に付与される期間を指定することもできます。「管理者ロールへのアクセスリクエスト」を参照してください。

• 拡張性と構成しやすさ

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

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

• 要求者のエンドユーザーダッシュボードとの統合

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

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