Oktaサインオンポリシーを構成する
Oktaサインオンポリシーでは、Oktaにアクセスできるユーザー、Oktaにアクセスできる場所、本人確認の方法を指定できます。Oktaサインオンポリシーを作成するには、ポリシーを作成してルールを追加する必要があります。
Oktaにはデフォルトで、リストに1つのデフォルトのOktaサインオンポリシーがあります。このポリシーの設定をカスタマイズして、包括的なポリシーとして組織のすべてのユーザーに適用することができます。それからさらにOktaサインオンポリシーを追加して、特定のユーザーグループに適用できます。たとえば、特定のネットワークゾーンからのみOktaにサインインできる特定のユーザーグループや、認証方法やセッションの長さなどを指定できます。
Oktaサインオンポリシーは、ポリシーのリストに表示されている順序で、リストの最上部から評価されます。Oktaは、サインイン試行を満たすポリシーが見つかるまで、各ポリシーに対するサインイン試行を検証します。サインイン試行がいずれのカスタムポリシーの要件も満たさない場合、OktaはデフォルトのOktaサインオンポリシーに対してサインイン試行を検証します。サインイン試行がいずれかのポリシーの要件を満たす場合、残りのポリシーは検証されず、ユーザーはOktaにアクセスできます。Oktaでは、リストの並び順は最も制限の高いポリシーを最上部に、最も制限の低いポリシーを下から2番目に、デフォルトのOktaサインオンポリシーを最下部に配置することを推奨しています。
- 新しいOktaサインオンポリシーを作成したら、新しいポリシーを有効にするためにすべてのアクティブなセッションを閉じる必要があります。
- Oktaサインオンポリシーは、APIトークンの有効性やライフタイムには影響しません。「APIトークンの管理」を参照してください。
Oktaサインオンポリシーを作成する
-
管理コンソールで、[Security(セキュリティ)] > [Authentication(認証)]に移動します。
-
[Sign On(サインオン)]タブをクリックします。
-
[Add New Okta Sign-On Policy(Oktaサインオン ポリシーを追加)]をクリックします。
-
以下のフィールドに入力します。
-
[ポリシー名]:サインオン・ポリシーの名前を入力します。
-
[Policy Description(ポリシーの説明)]:オプションです。Oktaサインオンポリシーの説明を入力します。
-
[Assign to Groups(グループに割り当てる)]:ポリシーを適用するグループの名前を入力します。ポリシーは複数のグループに適用できます。
-
-
[ポリシーを作成してルールを追加]をクリックします。
Oktaサインオンポリシールールを追加する
-
[ルールを追加]をクリックして、ルールをポリシーに追加します。必要に応じて以下のフィールドに入力します。
ルール名 | 作成するルールのわかりやすい名前を追加します。 |
ユーザーを除外 | 必要に応じて、グループの個々のユーザーをルールから除外できます。 |
IF [User's IP is(ユーザーのIP)] | ドロップダウンメニューを使用して場所のパラメーターを割り当てます。認証を求める場所の種類を指定できます。「ネットワークゾーン」および「ダイナミックゾーンについて」を参照してください。 |
AND [Authenticates via(次で認証:)] | このドロップダウンリストを使用して、必要な認証方法を指定します。 |
AND [Behavior is(行動:)] |
以前に作成された既存の行動の名前を入力します。行動を追加するには、行動名の入力を開始します。一致するすべての定義済みの挙動のドロップダウンリストが表示され、そこから行動を選択できます。追加する各行動について繰り返します。複数の挙動を追加すると、それらはOR条件として扱われます。「サインオン・ポリシー・ルールに挙動を追加する」を参照してください。 リスクの高い行動に対しては、予備の要素の要件を[Every time(毎回)]に設定します。行動条件をデバイスごとまたはセッションごとの予備の要素の要件と組み合わせないでください。 |
AND [Risk is(リスクレベル)] |
リスクスコアリングでは、データ主導のリスクエンジンを使用して、各サインインイベントが異常なアクティビティを表す可能性が高いかどうかを判断します。[Low(低)]、[Medium(中)]、または[High(高)]のリスクレベルを選択します。 [High(高)]を選択した場合は、予備の要素の要件を[Every time(毎回)]に設定します。高リスクレベルをデバイスごとまたはセッションごとの予備の要素の要件と組み合わせないでください。 「リスクスコアリング」を参照してください。 |
THEN [Access is(アクセスの可否)] | 前のドロップダウンリストの認証フォームに基づき、このフォームを使用して条件がアクセスを許可または拒否するかを決定します。 |
[Authentication(認証)] |
多要素認証が必要かどうかを示します。 |
ユーザーの認証方法: |
ユーザーの認証方法を選択します。
|
[Users will be prompted for MFA(ユーザーにMFA用のプロンプトを表示)] |
ユーザーが多要素認証を使用する必要がある場合に、使用するためのプロンプトがいつ表示されるかを示します。
|
セッションのライフタイム |
Oktaセッションの長さを構成します。 |
[Maximum Okta session lifetime(Oktaセッションの最大ライフタイム)] |
Oktaセッションのライフタイムを構成するか、なしにします。
|
[Expire session after user has been idle on Okta for(ユーザーがOktaで次の間アイドル状態になった後にセッションを期限切れにする:)] |
Oktaセッションの最大ライフタイムに関係なく、Oktaセッションが自動的に期限切れになるまでのアイドル時間を構成します。
|
[Persist session cookies across browser sessions(ブラウザセッション間でセッションCookieを保持)] |
ブラウザセッション間でのセッションCookieの保持を有効化または無効化します。ドロップダウンリストからオプションを選択します。
|
セッションのライフタイムの最大値は、Okta APIを通じて設定できます。以前にAPIでこの数値を設定した場合、Oktaのアプリでその最大値を超えることはできません。APIの最大値を超える数値を設定すると、エラーが発生します。
複数のOktaサインオンポリシーを追加する場合、選択した基準に一致する最初のポリシーのみが適用されます。
ユニバーサルなOktaサインオンポリシーのアクション
- 以下のポリシー1の左側に表示されているような、ポリシー名の横にある点線のバーをつかんで、リスト内の目的の位置にポリシーを移動することで、デフォルトポリシーを除くすべてのポリシーの順序を変更します。
- ルール名の左側にあるバーをつかんで、ポリシー内のルールの順序を変更します。
- [Add New Okta Sign-on Policy(新しいOktaサインオン ポリシーを追加)]を選択して新しいポリシーを追加します。
個別のOktaサインオンポリシーのアクション
1つのポリシーに対して次のアクションを実行できます。リストからポリシーを選択して開始します。
- 選択したポリシーをアクティブ化または非アクティブ化します。ポリシーを非アクティブ化した場合、そのポリシーはどのユーザーにも適用されませんが、後で再アクティブ化できます。
- ポリシーを編集するには、[編集]をクリックします。
- ポリシーを削除するには、[Delete(削除)]をクリックします。デフォルトのポリシーは削除できません。削除されたポリシーは復元できません。
- 選択したポリシーにルールを追加するには、[Add Rule(ルールを追加)]をクリックします。ポリシー内で、ルールをアクティブ化、非アクティブ化、編集、または削除できます。
- ルールの詳細を表示するには、[Add Rule(ルールを追加)]でルール名をクリックします。
認証前サインオン評価ポリシー
AuthN APIを使用してサインインするエンドユーザーは、パスワードまたはその他の要素が確認される前に、まずサインオンポリシーが評価されます。この評価は、組織全体で発生するアカウントロックアウトの数を減らすために役立ちます。
サインオンポリシーが[deny(拒否)]に設定されている場合、ユーザーのサインオンの試行は拒否され、「Authentication failed(認証に失敗しました)」という一般的なエラーがプロンプトに表示されます。このシナリオでは、失敗したログイン数のカウンターは増加しませんが、代わりに認証前サインオンポリシーの評価を示すイベントがトリガーされます。
- このバックエンド機能を有効にするために、管理コンソールに表示されるUIの変更や必要な設定はありません。
- このポリシーは、JITプロビジョニングを使用するために構成された、新しく作成されたアカウントの初期認証では機能しません。このポリシーの影響を受けるには、エンドユーザーアカウントがOktaに既に存在している必要があります。
- このポリシーでは、ユーザーが拒否された場所から認証情報をリセットすることは妨げません。