一般的なセキュリティ

ユーザー通知メール、ユーザーによる列挙の防止、Okta ThreatInsightなど、さまざまなグローバルorgセキュリティ設定を構成します。

管理コンソールでこれらの設定にアクセスするには、[Security(セキュリティ)]>[General(一般)]に移動します。

セキュリティ通知メール

[Security(セキュリティ)]>[General(一般)]>[Security Notification Emails(セキュリティ通知メール)]に進み、エンドユーザー向けの通知メールを設定します。

メール通知とテンプレートのカスタマイズの詳細については、「メールテンプレートをカスタマイズする」を参照してください。

新規サインオンに関する通知メール エンドユーザーが新規または認識されていないクライアントからサインインすると、エンドユーザーにメール通知が送信されます。このメールには、認証の時間と場所に加えて、サインインに使用したWebブラウザーやオペレーティングシステムなどのユーザーサインオンの詳細が含まれています。新規クライアントの識別に関する制限の詳細については、「新規サインオンに関する通知メール」を参照してください。

注:新規orgの場合、この機能はデフォルトで無効になっています。

詳細については、「エンドユーザー向けのサインオン通知」を参照してください。

オーセンティケーターの登録に関する通知メール エンドユーザーまたは管理者がアカウントの新しいオーセンティケーターに登録すると、エンドユーザーに確認メールが送信されます。

注:新規orgの場合、この機能はデフォルトで有効になっています。

詳細については、<MadCap:xref href="../identity-engine/healthinsight/notifications-authenticator-enroll.htm">「エンドユーザーへのオーセンティケーターの登録通知」</MadCap:xref>を参照してください。

オーセンティケーターのリセットに関する通知メール エンドユーザーまたは管理者がアカウントのオーセンティケーターをリセットすると、エンドユーザーにメールが送信されます。

注:新規orgの場合、この機能はデフォルトで有効になっています。

詳細については、「エンドユーザーへのオーセンティケーターのリセット通知」を参照してください。

パスワードの変更に関する通知メール エンドユーザーは、アカウントのパスワードを変更またはリセットすると、メール通知を受信します。このメールにはパスワードがリセットされた時刻や場所など、パスワードリセットの詳細が含まれています。

注:

  • 管理者が一時パスワードを設定した場合、エンドユーザーは一時パスワードからパスワードを変更した後にのみメール通知を受信します。
  • 代理認証(DelAuth)を使用したパスワードリセットのエンドユーザー通知はサポートされていません。
  • ユーザーが非アクティブの場合、エンドユーザーにメール通知は送信されません。

詳細については、「エンドユーザーへのパスワードの変更通知」を参照してください。

新規サインオンに関する通知メール

新規サインオンに関する通知メールは、オーセンティケーターなどのほかのセキュリティ機能を補完するものであり、代替機能として使用するべきではありません。多くの場合、クライアントを簡単かつ正確に識別しますが、一部制約があります。

新規デバイスのサインインに関する通知メールは、エンドユーザーのブラウザーのCookieまたはフィンガープリントに基づいて新規クライアントと識別された場合に送信されます。

次の1つ以上のシナリオでは、クライアントは新規と見なされます。

  • 新しいブラウザータイプまたはバージョン
  • 新しいオペレーティングシステムのタイプまたはバージョン
  • 新規または更新されたアプリケーション
  • 認識されないブラウザーまたはオペレーティングシステム(通知メールでは不明と表示されます)

エンドユーザーが任意のブラウザータイプおよびOkta FastPassを使用してOktaにサインインする場合、クライアントは新規とは見なされません。

orgで新規デバイス行動検知が向上している場合、サインオン行動評価でデバイスが既知であると判断されると、メール通知は送信されません。新しいデバイスの行動検知には以下が必要です。

認証が認識されない場合、エンドユーザーはすぐに管理者に連絡してアカウントのアクティビティを調査する必要があります。管理者は、ユーザーのセッションの終了、ユーザーのアカウントのロック、オーセンティケーターの追加などのアクションを実行して、セキュリティを向上させることができます。

制限事項

識別において課題となる制限事項がいくつかあります。新しいIPアドレスや新しい場所などのほかの識別子に加えてメール通知を有効にすると、エンドユーザーのアカウントで不審なアクティビティを特定する際の精度が向上します。

新規クライアントを識別するための現在の制限事項は次のとおりです。

  • サインインに成功すると、デバイスのフィンガープリントがキャプチャされます。
  • ユーザーのオペレーティングシステムまたはブラウザーに変更があると、新しいデバイス通知が生成される場合があります。
  • Okta以外のIDプロバイダーによって開始されたサインインでは、新しいデバイス通知は生成されません。
  • デバイスのフィンガープリントは、使用しているブラウザーに基づきます。エンドユーザーは、新しいブラウザータイプでサインインすると、新しいデバイス通知メールを受信します。
  • モバイルサインインの場合、新しいデバイス通知メールは、サインインに使用されたデバイスではなく、新しいモバイルアプリケーションの検出に基づいて送信されます。
  • 新しいデバイスの検出は常に完全に保証されるわけではありません。
  • エンドユーザーは、40日以内にアカウントにサインインしなかった場合、予期しない新規または不明なデバイス通知メールを受信することがあります。

エンドユーザー通知の詳細については、「メールテンプレートをカスタマイズする」を参照してください。

CAPTCHA統合

orgのセキュリティを強化するためのオプションとして、OktaはCAPTCHAをサポートし、自動サインインの試行を防ぎます。hCaptchaまたはreCAPTCHA v2の2つのサービスのいずれかを統合できます。

Oktaでサポートされているベンダーの実装はどちらも表示されません。各ユーザーはサインイン時にバックグラウンドでリスク分析ソフトウェアを実行し、ユーザーがボットである可能性を判断します。このリスク分析は、サービスに対して構成した設定に基づいています。

CAPTCHAを使用するようにorgを構成する前に、任意のベンダーにサインインするか、アカウントにサインアップしてから、次の手順に従います。

reCAPCHA v2の場合は、[Invisible reCAPTCHA badge(非表示のreCAPTCHAバッジ)]を選択してください。

いずれかのサービスの構成時に、org構成のサイトキーと秘密鍵を取得する必要があります。

reCAPTCHAまたはhCAPTCHAサービスを作成したら、ベンダーのサービス構成ページでドメインを指定してください。例:

  • Webアプリケーションがカスタマイズされたドメインmyapp.comおよびtestapp.comに基づいている場合、CAPTCHAサービスの各ドメインを指定する必要があります。
  • Okta Sign-in WidgetOktaベースの場合、CAPTCHAサービスのドメインリストにokta.comを追加する必要があります。

OktaでCAPTCHAサービスを構成するには、次の手順を実行します。

  1. Okta APIへのリクエストを認証するために必要なAPIトークンを作成します。「APIトークンを作成」を参照してください。
  2. Okta Admin Consoleで、[Security(セキュリティ)]>[General(一般)]の順に進みます。
  3. [CAPTCHA Integration(CAPTCHA統合)]セクションで以下の設定を構成します。
  • [Type(タイプ)]:使用するCAPTCHAサービスを選択します。
  • [Site key(サイトキー)]:サービス構成からサイトキーをコピーします。
  • [Secret key(秘密鍵)]:サービス構成から秘密鍵をコピーします。

[Enable CAPTCHA for(次に対してCAPTCHAを有効化)]:CAPTCHAを使用する認証のタイプを1つ以上選択します。

  • [Sign Up(サインアップ)]:ユーザーは最初の登録およびサインイン時にCAPTCHAに合格するよう求められます。
  • [Password Reset(パスワードリセット)]:ユーザーはパスワードをリセットするときにCAPTCHAに合格するよう求められます。
  • [Sign On(サインオン)]:ユーザーはサインイン時にCAPTCHAに合格するよう求められます。

現在、CAPTCHAは、識別子優先の認証フロー(つまり、ユーザーが2番目のサインインページでパスワードを入力するとき)のパスワードリセットではサポートされていません。

この制限の回避するには、サインインウィジェットの同じページでユーザー名とパスワードがユーザーに表示されるように認証フローを変更します。

  • orgが認証にIDプロバイダーを使用していないことを確認します。グローバルセッションポリシールールのAND[Identity provider is(IDプロバイダー)][Okta]オプションを使用できますが、[Specific IdP(特定のIdP)]オプションは使用できません。

  • すべてのグローバルセッションポリシールールで[Establish the user session with(次を使用してユーザーセッションを確立:)]オプションを[A password(パスワード)]に設定します。

手順については、「グローバルセッションポリシールールを追加する」と「サインインフロー」を参照してください。

  1. [Save(保存)]をクリックします。

トラブルシューティング

Okta構成で誤ったサービスサイトキーを入力すると、ユーザーはOkta orgにアクセスできなくなります。再構成するには、まず次の手順をCAPTCHA管理の公開APIに送信します。

コピー
curl -v -X PUT \ -H "Accept: application/json" \
-H "Content-Type: application/json" \
-H "Authorization: SSWS ${api_token}" \
-d '{"captchaId": null,
"enabledPages": null}'
"https://${yourOktaDomain}/api/v1/org/captcha"

組織のセキュリティ

[Security(セキュリティ)]>[General(一般)]>[Organization Security(組織のセキュリティ)]に進んで、組織のグローバル設定を構成します。

サインイン時にユーザーを記憶する この設定により、Okta Sign-in Widget[Username(ユーザー名)]フィールドが事前に入力されます。エンドユーザーは引き続き認証が必要です。最近のMFAオーセンティケーターや以前のセッションは記憶されません。
[Keep me signed in(サインインしたままにする)]オプションを表示 この設定により、サインイン画面でのエンドユーザーに対する[Keep me signed in(サインインしたままにする)]チェックボックスの表示と非表示を切り替えます。エンドユーザーがこの機能をオンにしてサインインすると、セッションは記憶され、グローバルセッションポリシーの設定に基づいて認証が不要になる場合があります。
アクティベーションメールの有効期限 エンドユーザーに送信されるアカウントのアクティベーションメールでリンクの有効期限を設定します。メール通知の詳細については、「メールテンプレートをカスタマイズする」を参照してください。
セッションの作成にデバイスバインディングを適用 デバイスバインディングにより、リダイレクトリクエストはそのリクエストが生成されたブラウザーでのみ使用されるようになります。Okta Classic Engineとの互換性を考慮してこの機能を無効にすることもできますが、Oktaでは無効にすることを推奨していません。この機能を無効にした場合、Oktaは認証フローを開始したアクターのみが状態トークンを使用できるようにするための確認を行いません。
サインイン時のユーザー名の一致基準 この設定によって、ユーザーのサインイン時にユーザーのプロファイルを照合する方法が決まります。[Match entire username(ユーザー名全体の一致)]を選択すると、ユーザーはドメインを含む完全なユーザー名を入力しないかぎりサインインできません。[Allow short match(短い一致を許可する)]を選択すると、ユーザーはドメインがなくてもサインインできます。
ユーザーが最近のアクティビティを表示可能 この設定により、ユーザーの[Recent Activity(最近のアクティビティ)]ページが有効になります。このページには、ユーザーの最近のサインインアクティビティとアカウントのセキュリティイベントが表示されます。

ユーザーによる列挙の防止

この機能を有効にすると、ユーザーアカウントを特定してオーセンティケーターを登録しようとする攻撃者からorgを保護できます。orgで認証が許可されている場合は、デバイスから新しいサインインを試行するたびにパスワードとメールが表示されるようになります。

ユーザーが存在しないかサインインできない場合は、オーセンティケーター検証エラーが送信されます。アカウントの存在確認は行われません。

この機能はデフォルトで無効になっています。この機能を有効にする方法については、「ユーザーによる列挙の防止を有効にする」を参照してください。この機能を無効にする方法については、「ユーザーによる列挙の防止を無効にする」を参照してください。

ユーザーによる列挙の防止を有効にする

  1. Okta Admin Consoleで、[Security(セキュリティ)]>[General(一般)]の順に進みます。
  2. [User Enumeration Prevention(ユーザーによる列挙の防止)]セクションで、[Edit(編集)]をクリックします。
  3. [User Enumeration Prevention(ユーザーによる列挙の防止)]ドロップダウンリストから[Enabled(有効化)]オプションを選択します。
  4. [Save(保存)]をクリックします。

ユーザーによる列挙の防止を無効にする

  1. Okta Admin Consoleで、[Security(セキュリティ)]>[General(一般)]の順に進みます。
  2. [User Enumeration Prevention(ユーザーによる列挙の防止)]セクションで、[Edit(編集)]をクリックします。
  3. [User Enumeration Prevention(ユーザーによる列挙の防止)]ドロップダウンリストから[Disabled(無効化)]オプションを選択します。
  4. [Save(保存)]をクリックします。

次の条件のいずれかが許可されている場合、[User Enumeration Prevention(ユーザーによる列挙の防止)]は有効になりません。

  • セルフサービス登録
  • JITフロー(メール認証あり)

詳細については、「ユーザーの管理」を参照してください。

Oktaへのエンドユーザーのサインイン試行の詳細については、「新規ユーザーの登録、アクティベーション、およびサインインエクスペリエンス」を参照してください。

Okta ThreatInsight

Okta ThreatInsightOkta顧客ベース全体のデータを集約し、このデータを使用して、認証情報ベースの攻撃を試みる悪意のあるIPアドレスを検出します。

悪用を防ぐため、Okta ThreatInsightの無料の試用版では機能を制限して動作しています。完全な機能を搭載したOkta ThreatInsightが必要な場合は、Oktaサポートまでご連絡ください。

この機能についての詳細は、「Okta ThreatInsight」を参照してください。

関連項目

グローバルセッションポリシー

Okta HealthInsight

Okta ThreatInsight