Oktaサインオン・ポリシーを構成する

Oktaサインオン・ポリシーを作成するには、[新規Oktaサインオン・ポリシーを追加]をクリックします。開いた画面で、目的のポリシー名と説明を入力します。

ポリシーを特定のグループにのみ適用できるように指定できます。ポリシーをグループに割り当てるには、[グループに割り当て]フィールドに目的のグループ名を入力します。ポリシーに割り当てる前に、グループ名がすでに存在している必要があります。完了したら、[ポリシーを作成してルールを追加]をクリックします。

ポリシーが評価されるときは、ポリシーの条件がルールの条件と組み合わされます。これらすべての条件が満たされた場合にルールが適用されます。ルールのないポリシーは適用できません。

また、ポリシーを追加する順序も重要です。ルールに一致する最初のポリシーが適用されます。一度条件が満たされると、ほかのポリシーは適用されません。

新しいポリシーを作成したら、新しいポリシーを有効にするために、すべてのアクティブなセッションを閉じる必要があります。
サインオン・ポリシーは、APIトークンの有効性やライフタイムには影響しません。「APIトークンの管理」を参照してください。

Oktaサインオン・ポリシーを作成する

新しいポリシーを作成したら、すべてのアクティブなセッションを閉じて新しいポリシーをアクティブ化します。

管理コンソールで、[セキュリティー] > に移動します。
[新規Oktaサインオン・ポリシーを追加]をクリックします。
以下のフィールドに入力します。
- [ポリシー名]：サインオン・ポリシーの名前を入力します。
- [ポリシーの説明]：オプションです。サインオン・ポリシーの説明を入力します。
- [グループに割り当て]：ポリシーを適用するグループの名前を入力します。ポリシーは複数のグループに適用できます。
[ポリシーを作成してルールを追加]をクリックします。

Oktaサインオン・ポリシー・ルールを追加する

[ルールを追加]をクリックして、ルールをポリシーに追加します。必要に応じて以下のフィールドに入力します。

ルール名	作成するルールのわかりやすい名前を追加します。
ユーザーを除外	必要に応じて、グループの個々のユーザーをルールから除外できます。
`IF`ユーザーのIP：	ドロップダウン・メニューを使用して場所のパラメーターを割り当てます。認証を求める場所の種類を指定できます。
`And`次で認証：	このドロップダウン・リストを使用して、必要な認証方法を指定します。
`AND`挙動：	以前に作成された既存の挙動の名前を入力します。挙動を追加するには、挙動名の入力を開始します。一致するすべての定義済みの挙動のドロップダウン・リストが表示され、そこから挙動を選択できます。追加する追加の各挙動について繰り返します。複数の挙動を追加すると、それらはOR条件として扱われます。「サインオン・ポリシー・ルールに挙動を追加する」を参照してください。
`Then`リスク：	リスク・スコアリングでは、データ主導のリスク・エンジンを使用して、各サインイン・イベントが異常なアクティビティーを表す可能性が高いかどうかを判断します。ドロップダウン・リストからリスク・レベルを選択します。リスク・スコアリングを参照してください。
`THEN`アクセスの可否	前のドロップダウン・メニューの認証フォームに基づき、このフォームを使用して条件がアクセスを許可または拒否するかを決定します。
[多要素認証の構成を管理]：	[多要素認証の構成を管理]リンクをクリックすると、[認証]ページと[多要素]タブにすばやくアクセスできます。それぞれの認証オプションの詳細については、「多要素認証を構成する」を参照してください。このボックスを選択すると、デバイスごと、サインオンごと、または指定したセッション時間ごとにトリガーされるプロンプトを決められるラジオ・ボタンが表示されます。セッションごとに指定する場合、セッションには構成されたデフォルトのライフタイムがありますが、ユーザーがOktaセッションからサインアウトするたびにセッションが終了することに注意してください。
[要素のライフタイム]：	このドロップダウン・メニューを使用して、ユーザーが多要素認証を求められるまでの経過時間を指定します。ライフタイムはデフォルトで15分となっていて、最長期間は6か月です。要素のライフタイムを設定することで、エンド・ユーザーは、[要素のライフタイム]に記載されている時間まではサインアウトしても次回のサインイン時に多要素認証で再度認証する必要がなくなります。エンド・ユーザーはボックスをオンにして、この設定を適用することを確認する必要があります。例として、次の15分間はこのデバイスで確認しない場合があります。この場合、サインアウト後に、多要素認証を使用した最後のサインインから15分以内に新規サインインを実行すると、多要素認証プロンプトは表示されません。ユーザーがボックスをオンにしない場合、常に多要素認証が求められます。最後にサインインしてからの時間がダッシュボードの下部に表示されます。ただし、エンド・ユーザーは更新された値を表示するために画面を更新する必要があります。
[セッションは次の経過後に期限切れになります]：	このドロップダウン・メニューを使用して、認証プロンプトがトリガーされるまでの最大アイドル時間を指定します。このオプションの最大許容時間は90日です。これは合計接続時間ではありません。デフォルトのセッションのライフタイムは2時間です。これは、残りのセッション時間の5分のマークでカウントダウン・タイマーが表示されるまでのアイドル時間です。

セッションのライフタイムの最大値は、Okta APIを通じて設定できます。以前にAPIでこの数値を設定した場合、Oktaのアプリでその最大値を超えることはできません。APIの最大値を超える数値を設定すると、エラーが発生します。

複数のサインオン・ポリシーを追加する場合、選択した基準に一致する最初のポリシーのみが適用されます。

グローバル・サインオン・ポリシーのアクション

以下のポリシー1の左側に表示されているような、ポリシー名の横にある点線のバーをつかんで、リスト内の目的の位置にポリシーを移動することで、デフォルト・ポリシーを除くすべてのポリシーの順序を変更します。
ルール名の左側にあるバーをつかんで、ポリシー内のルールの順序を変更します。
[新規Oktaサインオン・ポリシーを追加]を選択して新しいポリシーを追加します。

個別のサインオン・ポリシーのアクション

選択したポリシーのみに影響する以下のアクションを実行できます。リストのポリシー名をクリックして選択します。選択したポリシーは青色で表示されます。

選択したポリシーをアクティブ化または非アクティブ化します。ポリシーを非アクティブ化した場合、そのポリシーはどのユーザーにも適用されませんが、後で再アクティブ化できます。
ポリシーを編集するには、[編集]をクリックします。
ポリシーを削除するには、[削除]をクリックします。デフォルトのポリシーは削除できません。削除されたポリシーは復元できません。
選択したポリシーにルールを追加するには、[ルールを追加]をクリックします。ポリシー内で、ルールをアクティブ化、非アクティブ化、編集、または削除できます。
ルールの詳細を表示するには、[ルールを追加]の下でルール名をクリックします。

エンド・ユーザーによる多要素認証プロンプトの制御

[要素を求める]チェックボックスをオンにすると、以下に示されているように、特定のセッションでエンド・ユーザーに多要素認証が求められる方法に影響を与える3つのオプションが表示されます。

これらのオプションのうち、2つのオプションではエンド・ユーザーがこれらのプロンプトを制御できますが、1つのオプションでは制御できません。

[デバイスごと]：エンド・ユーザーの多要素認証チャレンジのダイアログ・ボックスで、[このデバイスで再度確認しない]というオプションが提供されます。このオプションでは、新しいデバイスに対してのみプロンプトを表示できます。
[毎回]：エンド・ユーザーがOktaにサインインするたびにプロンプトが表示され、要素の提供を求められるタイミングに影響を与えることはできません。
[セッションごと]：エンド・ユーザーの多要素認証チャレンジのダイアログ・ボックスで、[次の間はこのデバイスで確認しない]（分/時間/日）というオプションが提供されます。付随する[要素のライフタイム]フィールドで要素のライフタイムを指定します。セッションごとに指定する場合、セッションには構成されたデフォルトのライフタイムがありますが、ユーザーがOktaセッションからサインアウトするたびにセッションが終了することに注意してください。

認証前サインオン評価ポリシー

AuthN APIを使用してサインインするエンド・ユーザーは、パスワードまたはその他の要素が確認される前に、まずサインオン・ポリシーが評価されます。この評価は、組織全体で発生するアカウント・ロックアウトの数を減らすために役立ちます。

サインオン・ポリシーが 拒否に設定されている場合、ユーザーのサインオンの試行は拒否され、次の一般的なエラーがプロンプトに表示されます：認証が失敗しました。このシナリオでは、失敗したログイン数のカウンターは増加しませんが、代わりに認証前サインオン・ポリシーの評価を示すイベントがトリガーされます。

このバックエンド機能を有効にするために、管理コンソールに表示されるUI の変更や必要な設定はありません。
このポリシーは、JITプロビジョニングを介して新しく作成されたアカウントの初期認証では機能しません。このポリシーの影響を受けるには、エンド・ユーザー・アカウントがOktaに存在している必要があります。
このポリシーでは、ユーザーが拒否された場所から認証情報をリセットすることは妨げません。