Okta Identity Governanceリリースノート

機能と機能拡張

修正事項

• エンタイトルメントを持たないアプリは、ユーザーキャンペーンにレビューアイテムとして表示されませんでした。（OKTA-1120669）

• レビュアーがキャンペーンでActive Directoryソースグループへのユーザーのアクセスを取り消す場合は、手動修復が必要でした。（OKTA-1167090）

修正事項

修正事項

修正事項

機能と機能強化

リソースコレクションの認定 - ユーザーキャンペーン

アクセス認定のユーザーキャンペーンを実行して、リソースコレクションへのアクセスを認定します。コレクションを含むユーザーキャンペーンを実行すると、レビュアーのレビューアイテムの量を減らし、キャンペーンの完了を加速することができます。コンテキスト情報（Contextual Information）設定を使用すると、レビュアーが情報提供を行い、より正確な決定を下すことができるように、必要なコンテキストをレビュアーに提供することもできます。「ユーザーキャンペーンを作成する」を参照してください。

これは早期アクセスリリースです。セルフサービス機能を有効にするを参照してください。

修正事項

非アクティブ化または一時停止されたユーザーを次のユーザーに代わって要求：（Request On Behalf of）ドロップダウンメニューから選択できました。（OKTA-1095701）

アクセスを編集（Edit access）ボタンがアクセスを管理（Manage access）に更新されませんでした。（OKTA-1107686）

セキュリティアクセスのレビューがプレビュー環境で一般利用可能

セキュリティアクセスレビューは、セキュリティに焦点を当てた新しいタイプのユーザーアクセスレビューで、イベントによって自動的にトリガーできます。これらのレビューは、ユーザーのアクセス状況を包括的に把握できるだけでなく、AIが生成したアクセス概要を含むアクセス履歴に関するコンテキスト情報も提供するため、調査を行い、アクセス権の取り消しなどの即時的な是正措置を講じることができます。設定（Settings）ページのGovernance AIタブでAIの要約を有効または無効にすることもできます。「セキュリティアクセスレビュー」を参照してください。

ADグループのAccess Requestsが本番環境で一般利用可能になりました

Oktaから直接Active Directory（AD）をソースとするグループのアクセスリクエストを管理できるようになりました。これにより、アクセスリクエスト条件を構成するときにADグループを使用できるようになり、ユーザーはOkta Dashboardから直接メンバーシップをリクエストできるようになります。リクエストが承認されると、ADで要求者のアクセス権が付与されます。また、期限が切れたときは削除されます（期限付きの場合）。さらに、承認シーケンスでタスクの割り当て先としてリソース所有者を選択すると、ADをソースとするグループのマネージャーがタスクに割り当てられます。この機能により、重複したOktaグループやカスタムワークフローが不要になり、期限付きアクセスによって強力なセキュリティポスチャの構築をサポートします。「ADグループのアクセスガバナンス」を参照してください。

タスクのエスカレーションが本番環境で一般利用可能

アクセスリクエスト管理者とリクエスト割り当て先は、リクエスト内の失効タスクをタスク割り当て先のマネージャーにエスカレーションできます。設定（Allow requesters to escalate tasks）ページで 要求者にタスクのエスカレーションを許可する（Settings）トグルを有効にした場合、要求者はアクセスリクエスト内のタスクもエスカレーションできます。これにより、リクエストの解決が早くなり、ボトルネックを防ぎ、生産性を向上させ、危険な回避策の使用を減らすことができます。タスクエスカレーションは、安全で監査可能な自動化されたプロセスです。効率的な操作と強力なセキュリティポスチャの両方をサポートすることで、時間ベースのアクセスリクエストモデルの導入に役立ちます。「タスクを管理する」および「要求者にタスクのエスカレーションを許可する」を参照してください。

キャンペーンの要約レポートの変更

リソースキャンペーンに事前定義されたユーザースコープが選択されている場合、選択内容に応じて、キャンペーンの要約レポートのユーザースコープ（User scope）列に最近のアクティビティのないユーザー（Users with no recent activity）またはSOD競合が発生しているユーザー（Users with SoD conflicts）のいずれかが表示されるようになりました。

Access Requestsのメール通知の新しい外観と操作性

Access Requestsのメール通知で、テキストの配置や使用される色、Oktaロゴの場所、グレー背景の追加など、外観と操作性が新しくなりました。

承認シーケンスにおけるグループ所有者機能の変更

承認シーケンスで、アクセスリクエスト条件のアクセスレベル（Access level）で指定したグループのグループ所有者にタスクを割り当てたい場合に、リソース所有者（Resource Owner）オプションを選択できるようになりました。グループ所有者（Group owner）とリクエストされているグループ（The group being requested）の組み合わせにタスクが割り当てられている既存の承認シーケンスは、自動的にリソース所有者（Resource owner）に更新されます。引き続きグループ所有者（Group owner） オプションを使用して、（アクセスリクエスト条件のアクセスレベルで指定されていない）他のグループのグループ所有者にタスクを割り当てることができます。さらに、次の承認シーケンステンプレートの名前が変更されました。

• 理由 + グループ所有者の承認（Justification + Group Owner Approval）が理由 + リソース所有者の承認（Justification + Resource Owner Approval）に変更

• マネージャー、グループメンバーおよび所有者の承認（Manager, Group Member & Owner Approvals）がマネージャー、グループメンバーおよびリソース所有者の承認（Manager, Group Member & Resource Owner Approvals）に変更

「承認シーケンスを構成する」を参照してください。

アプリグループがキャンペーンスコープにリソースとして含まれている場合、アプリグループのメンバーシップが適切に反映されませんでした。（OKTA-1080290）

サービスアカウントを認定する

リソースキャンペーンを作成して、SaaSアプリケーションとOktaサービスアカウントの両方のアクセスをレビューおよび認証できるようになりました。この機能により、ガバナンス戦略が非人間アイデンティティに拡張され、重要なサービスアカウントアクセスに対する可視性と制御を維持できます。サービスアカウントを認定するを参照してください。

これは早期アクセスリリースです。「セルフサービス機能を有効にする」を参照してください。

Workflowsのガバナンス

Okta Identity Governanceを使用して、Workflowsロールへのアクセスを管理できるようになりました。これにより、Workflowsへのアクセスを会社の要件に準拠し、一貫して付与できるようになります。Governance for Workflowsを参照してください。

これは早期アクセスリリースです。「セルフサービス機能を有効にする」を参照してください。

ADグループのAccess Requestsがプレビュー環境で一般利用可能になりました

Oktaから直接Active Directory（AD）をソースとするグループのアクセスリクエストを管理できるようになりました。これにより、アクセスリクエスト条件を構成するときにADグループを使用できるようになり、ユーザーはOkta Dashboardから直接メンバーシップをリクエストできるようになります。リクエストが承認されると、ADで要求者のアクセス権が付与されます。また、期限が切れたときは削除されます（期限付きの場合）。さらに、承認シーケンスでタスクの割り当て先としてリソース所有者を選択すると、ADをソースとするグループのマネージャーがタスクに割り当てられます。この機能により、重複したOktaグループやカスタムワークフローが不要になり、期限付きアクセスによって強力なセキュリティポスチャの構築をサポートします。「ADグループのアクセスガバナンス」を参照してください。

この機能は、プレビュー環境で一般利用可能ですが、本番環境向けの早期アクセスリリースです。

タスクのエスカレーションがプレビュー環境で一般利用可能になりました

アクセスリクエスト管理者とリクエスト割り当て先は、リクエスト内の失効タスクをタスク割り当て先のマネージャーにエスカレーションできます。設定（Allow requesters to escalate tasks）ページで 要求者にタスクのエスカレーションを許可する（Settings）トグルを有効にした場合、要求者はアクセスリクエスト内のタスクもエスカレーションできます。これにより、リクエストの解決が早くなり、ボトルネックを防ぎ、生産性を向上させ、危険な回避策の使用を減らすことができます。タスクエスカレーションは、安全で監査可能な自動化されたプロセスです。効率的な操作と強力なセキュリティポスチャの両方をサポートすることで、時間ベースのアクセスリクエストモデルの導入に役立ちます。「タスクを管理する」および「要求者にタスクのエスカレーションを許可する」を参照してください。

この機能は、プレビュー環境で一般利用可能ですが、本番環境向けの早期アクセスリリースです。

リソースラベルが本番環境で一般利用可能になりました

Okta全体のリソースにラベルを定義して、キャンペーンのスコーピングや維持を行う際にアクセス認定内の可視性、絞り込み、自動化を向上します。「リソースラベル」を参照してください。

委任フローの更新

委任フローに呼び出し元（Caller）入力フィールドが含まれるようになりました。これにより、別のOkta製品から呼び出されたフローに追加情報を渡すことができます。たとえば、アクセスリクエストのrequestIDが委任フローに渡されるようになりました。「委任フローを構築する」を参照してください。

メールによるアクセスリクエスト承認の変更

メールからのリクエストを承認または拒否する際に、承認（Approve）または拒否（Deny）をクリックした後、誤りに気付いた場合は、5秒以内であればその決定をキャンセルできるようになりました。その後、その決定は自動的に適用されます。

ユーザーのプレビュー機能の変更

キャンペーンウィザードのユーザー（User）ページで、ユーザーをプレビュー（Preview user）は式スコープをプレビュー（Preview expression scope）に変わりました。ユーザーをプレビューするとき、Oktaは指定したOkta Expression Language式に対してのみユーザーを検証します。式に一致するもののキャンペーン内のリソースに割り当てられていないユーザーは、キャンペーンに含まれません。

職務分離ルールおよび競合の警告が、職務分離ルールの競合が発生するリクエストを要求者が送信するのをブロックしていませんでした。（OKTA-1076749）

Active Directoryグループがキャンペーンスコープ内のリソースとして含まれていませんでした。（OKTA-1080290）

一部の管理者は、本番環境のAdmin Consoleでセキュリティアクセスレビューを作成または起動できませんでした。（OKTA-1053960）

セキュリティアクセスのレビューがプレビュー環境で一般利用可能になりました

セキュリティアクセスレビューは、イベントによって自動的にトリガーできる、セキュリティ重視の新しいユーザーアクセスレビューです。これらのレビューは、ユーザーのアクセスと、 AI生成アクセスの要約を含むユーザーのアクセス履歴に関するコンテキスト情報について、統合されたビューを提供します。これにより、調査、およびアクセスの取り消しなどの修復アクションを即座に実行できます。また、設定（Settings） ページの ガバナンスAI（Governance AI） タブで、 AIの要約を有効または無効にするオプションもあります。「セキュリティアクセスレビュー」を参照してください。

セキュリティアクセスレビューへの変更が、プレビュー環境で一般利用可能になりました

• 手動による修復が必要なリソースの場合、レビュアーはアクセスの取り消し（Revoke access）またはアクセスの復元（Restore access）を選択できるようになりました。レビュアーがこれらを選択すると、Oktaはこのアクションをレビュー履歴に記録し、管理者が手動で修復アクションを実行できるようにします。またOktaは、access.review.actionSystem Logイベントも発生させます。「アクセスをレビューする」を参照してください。

• セキュリティアクセスレビューの開始後に、レビュアーと終了日を更新できるようになりました。「セキュリティアクセスレビューを管理する」を参照してください。

エンタイトルメント履歴がプレビュー環境で一般利用可能に

管理者が、ユーザーのエンタイトルメント履歴にアクセスできるようになりました。この機能により、監査とコンプライアンスタスクが改善され、アクセス問題のトラブルシューティングの可視性が向上します。「ユーザーのエンタイトルメントを表示する」を参照してください。

リソース所有者が本番環境で一般利用可能になりました

グループ、アプリ、エンタイトルメント、エンタイトルメントバンドルに所有者を割り当てます。この機能により、アクセスリクエストのステップとアクセス認定キャンペーンのレビューを正しい関係者に自動的にルーティングできるようになり、ガバナンスプロセスの効率性と正確性が向上します。また、構成を手動で更新する必要なく、適切な関係者がアクセスの決定に常に関与するようにするのに役立ちます。

• Access Requests：アクセスリクエスト条件で承認シーケンスを構成する際に、承認、タスク、質問を直接リソース所有者に割り当てることができるようになりました。「承認シーケンスを構成する」を参照してください。

• アクセス認定：認定キャンペーンを作成する際に、指定されたレビュアーとしてリソース所有者を選択できるようになりました。「認定キャンペーンレビュー」を参照してください。

「リソース所有者」を参照してください。

Okta Access Requests Webアプリのセキュリティ強化機能が本番環境で一般利用可能になりました

Okta Access Requests Webアプリでは、新しいアクセストークンを付与する前にポリシー評価を実行するようになりました。

Okta Identity GovernanceレポートのPDF形式でのエクスポートが本番環境で一般利用可能になりました。

Okta Identity GovernanceレポートをPDFにエクスポートできるようになりました。エクスポート時に、レポートに含める特定の列を選択することもできます。

Okta Access Requests WebアプリでのUniversal Logout

Okta Access Requests WebアプリでUniversal Logoutがサポートされるようになりました。これにより管理者は、Universal Logoutがトリガーされると、ユーザーをこのアプリから自動的にサインアウトさせることができます。

Okta Access Requests Webアプリのセキュリティ強化機能がプレビュー環境で一般利用可能になりました

Okta Access Requests Webアプリでは、新しいアクセストークンを付与する前にポリシー評価を実行するようになりました。

• リクエストタイプを編集する際、またはリクエストタイプが管理するリクエストとやり取りする際に、ドロップダウンメニューおよびフィールドの長文テキストラベルが正しく表示されず、またカーソルを合わせると表示されるヒントがありませんでした。（OKTA-993083）

• アクセスリクエストとアプリ管理者ロールを持つユーザーは、アプリ管理者ロールが特定のアプリにスコープ設定されている場合でも、さまざまなアプリのアプリプロファイルページにアクセスリクエスト（Access Request）タブが表示されていました。 （OKTA-1030035）

• Access Requestsタブが、 APIサービスアプリのアプリのプロファイルページに表示されていました。（OKTA-1035925）

• リソースアクセスの変更 - キャンペーンの開始からキャンペーンの完了まで（Resource access changes - Campaign launch to campaign complete） レポートに、キャンペーンのユーザースコープに含まれていないユーザーの詳細が含まれていました。（OKTA-1038132）

• アクセスリクエスト（Access Request） - V2のAPIが、クライアント資格情報認証フローをサポートしていませんでした。（OKTA-1044065）

• マルチレベルレビューが設定された繰り返しキャンペーンでキャンペーン作成者の情報が不足している場合、レビュー詳細（Review details）パネルの履歴（History）セクションにレビュアーの決定が表示されませんでした。（OKTA-1046833）

• APIサービスアプリのクライアントの資格情報フローが、一部のガバナンスAPIリクエストに対して機能していませんでした。（OKTA-926552）

• 管理者は、過去のAccess RequestsレポートをPDFにエクスポートできませんでした。（OKTA-997865）

PDF形式でのOkta Identity Governanceレポートのエクスポートが、プレビュー環境で一般利用可能になりました

Okta Identity GovernanceレポートをPDFにエクスポートできるようになりました。エクスポート時に、レポートに含める特定の列を選択することもできます。

エンタイトルメント履歴がプレビュー環境で一般利用可能になりました

管理者が、ユーザーのエンタイトルメント履歴にアクセスできるようになりました。この機能により、監査とコンプライアンスタスクが改善され、アクセス問題のトラブルシューティングの可視性が向上します。「ユーザーのエンタイトルメントを表示する」を参照してください。

リソース所有者がプレビュー環境で一般利用可能になりました

グループ、アプリ、エンタイトルメント、エンタイトルメントバンドルに所有者を割り当てます。この機能により、アクセスリクエストのステップとアクセス認定キャンペーンのレビューを正しい関係者に自動的にルーティングできるようになり、ガバナンスプロセスの効率性と正確性が向上します。また、構成を手動で更新する必要なく、適切な関係者がアクセスの決定に常に関与するようにするのに役立ちます。

• Access Requests

  アクセスリクエスト条件で承認シーケンスを構成する際に、承認、タスク、質問を直接リソース所有者に割り当てることができるようになりました。「承認シーケンスを構成する」を参照してください。

• アクセス認定

  認定キャンペーンを作成する際に、指定されたレビュアーとしてリソース所有者を選択できるようになりました。「認定キャンペーンレビュー」を参照してください。

「リソース所有者」を参照してください。

リソースラベルがプレビュー環境で一般利用可能になりました

Okta全体のリソースにラベルを定義して、キャンペーンのスコーピングや維持を行う際にアクセス認定内の可視性、絞り込み、自動化を向上します。「リソースラベル」を参照してください。

監査レポートパッケージが本番環境で一般利用可能になりました

この機能を使用すると、監査者要件を満たすようにカスタマイズされたアクセス認定キャンペーンレポートが自動的に生成されます。これらのレポートにより、キャンペーンおよびユーザーアクセスデータの収集とエクスポートに必要な時間と手作業が削減され、コンプライアンス監査の準備がより迅速かつ容易になります。「監査者レポートパッケージ」を参照してください。

Governance代理人が本番環境で一般利用可能になりました

ユーザーの代理人を設定したり、ユーザーが別のユーザーを代理人に指定して、ユーザーのGovernanceタスクを完了できるようにしたりできます。Governanceタスクには、アクセス認定キャンペーンのレビューアイテム、およびアクセスリクエストの承認や質問、その他のタスクが含まれます。代理人を指定すると、今後のすべてのGovernanceタスク（アクセスリクエストの承認やアクセス認定のレビュー）が、元の承認者またはレビュアーではなく代理人に割り当てられます。これにより、承認者が対応不可の場合や、タスクを長期間別の関係者に再ルーティングする必要がある場合にGovernanceプロセスが停止しないようにできます。また、リクエストやレビューを手動で再割り当てする時間も短縮されます。「Governance代理人」を参照してください。

新しいシステムログイベント

スーパー管理者が委任設定を更新して、ユーザーによる自身の代理人の割り当てを許可またはブロックすると、governance.settings.updateSystem Logイベントが発生します。

アクセスリクエスト通知への変更

プラットフォーム全体で会話が一貫して表示されるように、Webアプリからのアクセスリクエスト内で送信されたメッセージが、SlackまたはMicrosoft Teamsの該当するチャットでメッセージ送信者に自動的に表示されるようになりました。これにより、リクエストのある関連メッセージにてメッセージ送信者の混乱が軽減されます。

過去のAccess Requests（条件）レポートの変更

過去のAccess Requests（条件）レポートから リクエスト 件名（Request subject）の列が削除されました。

• アプリおよびアクセスリクエスト管理者ロールを最近割り当てられた管理者に、アプリインスタンスページのAccess Requestsタブが表示されていませんでした。（OKTA-1020342）

• 保留中のレビューがあるかどうかに関係なく、すべてのレビュアーに対して保留中のレビューに関するメールが作成されていました。この問題により、レビューアイテムが含まれないメールが配信されていました。（OKTA-1020491）

• キャンペーンの開始に失敗することがありました。（OKTA-1020732）

• Oktaのワークフローを通じてSalesforceに割り当てられ、かつエンタイトルメントバンドルが割り当てられた後も、一部のユーザーがプッシュおよび同期されないため、Salesforceに表示されませんでした。（OKTA-1021934）

• エンタイトルメントのdescriptionフィールドが、SCIM 2.0を通してOktaにインポートされませんでした。（OKTA-935291）

アクセスリクエストの代理自己承認を削除しました

職務分離を適切にするために、代理人は、自分の代理で行われたリクエストを承認できなくなりました。

• 変更されたキャンペーン終了日のAccess Certification通知メールの件名行に保留中のレビュー（Pending reviews）が 誤って表示されていました。（OKTA-1007068）

• 非アクティブ化されたユーザーのアクセス認定キャンペーンで、Okta Identity Governanceのユーザーステータスが正しく自動入力されていませんでした。（OKTA-991451）

• アプリおよびアクセスリクエスト管理者ロールを最近割り当てられた管理者に、アプリインスタンスページの Access Requests タブが表示されていませんでした。（OKTA-1020342）

リリース：2025.09.0

機能と機能強化

Access Certification UIの変更

Access Certificationページのキャンペーン（Campaigns）タブの名前が 認定キャンペーン（Certification campaigns）に変更されました。+キャンペーンを作成（+ Create campaign）ボタンの位置が認定キャンペーン（Certification campaigns）タブに移動しました。

これは早期アクセスリリースです。「セルフサービス機能を有効にする」を参照してください。

Access Certification制限の変更

リソースキャンペーンに関する次の制限が更新されました。

• キャンペーンに含まれるリソースの最大数が50から250に増加しました。

• エンタイトルメントをレビューするアプリの最大数が10から20に増加しました。

ユーザーキャンペーンでは、除外するリソースの最大数が50から100に増加しました。最大100のアプリ、グループ、またはその組み合わせを除外できます。

リソースキャンペーンUIの変更

リソースキャンペーンに含めるアプリを選択する際、使用可能なエンタイトルメントを持つアプリの検索結果では、アプリ名の後ろに括弧付きで「エンタイトルメント」と付くようになりました。

Governance代理人

ユーザーの代理人を設定したり、ユーザーが別のユーザーを代理人に指定して、ユーザーのGovernanceタスクを完了できるようにしたりできます。Governanceタスクには、アクセス認定キャンペーンのレビューアイテム、およびアクセスリクエストの承認や質問、その他のタスクが含まれます。代理人を指定すると、今後のすべてのGovernanceタスク（アクセスリクエストの承認やアクセス認定のレビュー）が、元の承認者またはレビュアーではなく代理人に割り当てられます。これにより、承認者が対応不可の場合や、タスクを長期間別の関係者に再ルーティングする必要がある場合にGovernanceプロセスが停止しないようにできます。また、リクエストやレビューを手動で再割り当てする時間も短縮されます。「Governance代理人」を参照してください。

グループ所有者ロールがリソース所有者になりました

グループ所有者（Group owner）ロールがリソース所有者（Resource owner）に変更されました。

アクセスリクエストのユーザーエクスペリエンスの改善

アクセスリクエストの詳細ページとメール通知が改善され、承認者のタスクと要求者の応答がわかりやすくなりました。SlackをAccess Requestsと統合した場合、承認者が受け取るアクセスリクエストメッセージに同様の変更が加えられました。また、リクエストの割り当て先がSlackおよびメール通知から削除され、メール通知送信者の名前とアドレスが変更されました。送信者の名前はOkta Access Requestsで、新しいメールアドレスはnoreply@at.okta.comです。「Access Requestsの承認者エクスペリエンスの再設計」を参照してください。

セキュリティアクセスレビュー

セキュリティアクセスレビューは、イベントによって自動的にトリガーできる、セキュリティ重視の新しいユーザーアクセスレビューです。これらのレビューは、ユーザーのアクセスと、 AI生成アクセスの要約を含むユーザーのアクセス履歴に関するコンテキスト情報について、統合されたビューを提供するため、調査してアクセスの取り消しなどの即時修復アクションを実行することを可能にします。 セキュリティアクセスレビュー を参照してください。

キャンペーンのリソーススコープに個別に割り当てられたエンタイトルメントのみを含めるように設定されていても、ポリシーで割り当てられたエンタイトルメントが誤ってユーザーキャンペーンに含まれることがありました。（OKTA-1001535）

ユーザーがアイテムの検索後にEnd-User Dashboardでリソースカタログを更新すると、検索結果が消去されていました。（OKTA-1006498）

セルフレビュー有効キャンペーンと無効キャンペーンが混在するキャンペーンをレビュアーが取得しようとすると、エラーが発生し、キャンペーンが表示されませんでした。（OKTA-1012083）

レビュアーへのメール通知に表示される保留中のレビューアイテムの数が正しくありませんでした。（OKTA-962525）

キャンペーンが開始され、レビューが割り当てられたときに、一部のレビュアーはメール通知を受信しませんでした。（OKTA-994146）

リソースカタログタイル向けのUIの改善

リクエストタイプおよびリソースコレクション向けのリソースカタログタイルに説明が含まれるようになりました。タイルの説明が長い場合は、テキストにカーソルを合わせると、ヒントで完全な説明が表示されます。

管理者が、自身のアクセスリクエストの承認者として自分を割り当てる場合がありました。（OKTA-793993）

Governance代理人

スーパー管理者とユーザーは、別のユーザーを代理人として割り当て、そのGovernanceタスクを完了できます。Governanceタスクには、アクセス認定キャンペーンのレビューアイテム、およびアクセスリクエストの承認や質問、その他のタスクが含まれます。代理人を指定すると、今後のすべてのGovernanceタスク（アクセスリクエストの承認やアクセス認定のレビュー）が、元の承認者またはレビュアーではなく代理人に割り当てられます。これにより、承認者が対応不可の場合や、タスクを長期間別の関係者に再ルーティングする必要がある場合にGovernanceプロセスが停止しないようにできます。また、リクエストやレビューを手動で再割り当てする時間も短縮されます。「Governance代理人」を参照してください。

これは早期アクセスリリースです。「セルフサービス機能を有効にする」を参照してください。

統一された要求者のエクスペリエンス

この機能を使用すると、リクエストが条件またはリクエストタイプによって管理されるかどうかに関係なく、エンドユーザーダッシュボード、Slack、Microsoft Teamsでリクエストを開始するための一貫した統合されたエクスペリエンスを作成できます。これにより、いずれかまたは両方の方法を柔軟に組み合わせて使用し、要求者のエクスペリエンスを変更することなくリソースアクセスを管理できます。

• リクエストタイプは、End-User Dashboardのリソースカタログに他のリソースとともにタイルとして表示されるようになりました。リクエストタイプのオーディエンスの設定は、引き続きどのユーザーがダッシュボードとリクエストアクセスでリクエストタイプを表示できるかを管理します。

• SlackとMicrosoft Teamsでは、ユーザーはアクセスリクエスト条件によって管理されるリソースへのアクセスを要求できるようになり、リクエストタイプによって管理されるリソースを要求するユーザーエクスペリエンスも変更されました。

さらに、 Okta Access Requestsアプリの、アクセスリクエスト（Access requests）ページの名前が リソースカタログ（Resource catalog）に変更されました。これをクリックすると、要求者がエンドユーザーダッシュボードのリソースカタログにリダイレクトされます。Webアプリのリクエストタイプ（Request types）セクションは、管理者およびリクエストタイプを所有するチームメンバーにのみ表示されます。「リクエストを作成する」を参照してください。

これは早期アクセスリリースです。「セルフサービス機能を有効にする」を参照してください。

PDF形式でのOkta Identity Governanceレポートのエクスポート

Okta Identity GovernanceレポートをPDFにエクスポートできるようになりました。エクスポート時に、レポートに含める特定の列を選択することもできます。

これは早期アクセスリリースです。「セルフサービス機能を有効にする」を参照してください。

リクエストタイプのリクエスト割り当て先の変更が本番環境で利用になりました

リクエストタイプのタスクまたは質問が、完了するグループに割り当てられた場合、リクエストを最初に送信したユーザーが、そのグループのメンバーであっても、割り当てから自動的に除外されるようになりました。これにより、要求者がリクエスト管理容量内の自分のリクエストに対してアクションを実行できなくなります。

Oktaは、リクエスト割り当て先として、リクエスト内のタスクを完了する最後のユーザーを自動的に割り当てていました。（OKTA-959802）

Access Certificationキャンペーンの設定（Settings）ページの コンテキスト情報（Contextual Information）セクションで社員番号（Employee number）チェックボックスが利用できるようになりました。「カスタマイズ可能なレビュアーコンテキスト」を参照してください。

リソースへのユーザーのアクセスを承認または取り消すと、レビュアーがエラーを受け取ることがありました。（OKTA-917776）

Okta Access Requestsリソースカタログアプリの名前が変更されました

Okta Access Requestsリソースカタログアプリの名前が、Okta Identity Governanceに変更されました。このアプリは、自動的にすべてのユーザーに割り当てられ、アプリの管理は必要ありません。ユーザーは、エンドユーザーダッシュボードでアクセスをリクエスト（Request access）をクリックすると新しい名前が表示される場合があります。この変更は、キャンペーンのレビュアーとリクエスト承認者が使用する既存のOkta Access Certification ReviewsアプリとOkta Access Requestsアプリには影響しません。

リクエストタイプによって管理されるアクセスリクエストへの変更は、本番環境で利用可能です。

アクセスリクエストがリクエストタイプによって管理される場合、そのリクエストを使ってOkta管理者ロールを付与するグループを割り当てることはできません。Okta管理者ロールを付与するグループをリストに追加することはできません。また、リクエストタイプを作成または編集すると、これらのグループを割り当てるリクエストタイプが無効になります。Okta管理者ロールを付与するグループをリクエストしたユーザーには、エラーが返されます。管理者ロールへのアクセスリクエストを参照してください。

プレビューでOktaアプリへの変更を利用可能になりました

次のアプリの表示およびユーザーへの割り当てができなくなりました。

• Okta Access Certifications

• Okta Access Requests Admin

• Okta Entitlement Management

また、これらのアプリのサインオンポリシーは、Okta Admin Consoleで使用する既存のサインオンポリシーがデフォルトとして設定されます。

一部のアクセスリクエストイベントがシステムログに記録されていませんでした。（OKTA-955700）

リクエストタイプによって管理されるアクセスリクエストへの変更が、プレビュー環境で利用できるようになりました

アクセスリクエストがリクエストタイプによって管理される場合、そのリクエストを使ってOkta管理者ロールを付与するグループを割り当てることはできません。Okta管理者ロールを付与するグループをリストに追加することはできません。また、リクエストタイプを作成または編集すると、これらのグループを割り当てるリクエストタイプが無効になります。Okta管理者ロールを付与するグループをリクエストしたユーザーには、エラーが返されます。管理者ロールへのアクセスリクエストを参照してください。

リクエストタイプのリクエスト割り当て先の変更がプレビュー環境で利用になりました

リクエストタイプのタスクまたは質問が、完了するグループに割り当てられた場合、リクエストを最初に送信したユーザーが、そのグループのメンバーであっても、割り当てから自動的に除外されるようになりました。これにより、要求者がリクエスト管理容量内の自分のリクエストに対してアクションを実行できなくなります。