Okta Identity Governanceリリースノート

一般利用可能な機能

リソースコレクションの認定 - リソースキャンペーンがプレビュー環境で一般利用可能になりました

アクセス認定リソースキャンペーンを使用して、リソースコレクションへのユーザーアクセスを認定します。個々のアプリ、エンタイトルメント、またはバンドルを個別にレビューするよりも、リソースコレクションに対してリソースキャンペーンを実行すると、レビュアーのレビューアイテムの量を減らし、情報に基づいた意思決定を行うために必要なコンテキストを提供することができます。「リソースキャンペーンを作成する」を参照してください。

リソースコレクションの認定 - ユーザーキャンペーンがプレビュー環境で一般利用可能になりました

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

統一された要求者のエクスペリエンスがプレビュー環境で一般利用可能になりました

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

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

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

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

開始前の認定キャンペーンのステージングがプレビュー環境で一般利用可能になりました

キャンペーンをステージングすることで、ターゲットユーザー、リソース、レビュアーの割り当てを事前にプレビューして正確なスコープを確保し、構成エラーを修正して、初日からリクエストが正しいレビュアーに確実に届くようにできます。「キャンペーンをステージングする」を参照してください。

カスタムからポリシーへのアクセス変更を伴わないユーザー変換が本番環境で一般利用可能になりました

既存のエンタイトルメントを維持したまま、カスタムエンタイトルメントとバンドル割り当てからポリシーにユーザーを変換できるようになりました。「ユーザーエンタイトルメントを管理する」を参照してください。

キャンペーン通知の頻度

キャンペーンのレビュー期間終了前に、最大3つの異なる日にレビュー担当者へのリマインダーを設定できるようになりました。複数の日にリマインダーを送信することで、キャンペーン終了前に完了するレビューの件数を増やすことができます。

アクセスリクエストのメール通知設定

Orgレベルでアクセスリクエストのメール通知をオフにできるようになりました。これは、デフォルトのOktaのメールを使用する代わりに、独自のブランドに合わせたカスタムメール通知を作成したいorgにとって便利な機能です。

早期アクセス機能

グループの職務分掌

職務分掌（SOD）ルールを使用して、アプリ内のグループ（割り当てグループまたはプッシュグループ）のどの組み合わせが、org内で利益相反を引き起こすかを定義します。これらのルールを使用して作業と責任を分割し、組織内の同じユーザーが重要なプロセスの全局面を制御することがないようにします。SODルールを構成すると、エラーや詐欺、不正なアクションのリスクを軽減できます。

SODルールを使用すると、予防と修復という2方面のアプローチを採用して、矛盾するグループとプッシュグループの割り当てを管理できます。

アクセスリクエストを使用して、SODルール相反を引き起こす可能性のあるアクセス要求を、ユーザーに許可（またはカスタム設定で許可）するか、ブロックするかを指定します。また、過去のアクセスリクエスト（条件）（Past Access Requests (Conditions)） レポートを実行し、 矛盾名（Conflict name） 列を使用してSODルール相反があるアクセスリクエストを表示することもできます。

SODルール相反がある場合、リソースキャンペーンを実行して、アクセス認定を使用し、既存のユーザーアクセス権を確認して修正します。

さらに、職務分掌（Separation of duties）、過去のキャンペーンの詳細（Past campaign details）、または過去のアクセスリクエスト（条件）（Past Access Requests (Conditions)）レポートのいずれかを実行すると、SODの相反情報を利用できます。

「職務分掌」を参照してください。

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

修正事項

• キャンペーンのステージングに関するメール通知の後に、キャンペーン開始時の検証結果を知らせるメールが届くことがあり、そのためにキャンペーンの開始に失敗する場合がありました。（OKTA-1247953）