一般的なセキュリティ

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

これらの設定にアクセスするには、Admin Consoleの［Security（セキュリティ）］［General（一般）］に移動します。

セキュリティ通知メール

［Security（セキュリティ）］［General（一般）］［Security Notification Emails（セキュリティ通知メール）］に移動してエンドユーザー向けの通知メールを構成します。通知メールが受信者に届かない場合、配信エラーの原因を示すイベント（遅延、ドロップ、バウンス）がSystem Logに表示されます。

orgに複数のブランドがある場合、これらの設定はデフォルトブランドにのみ適用されます。特定ブランドのメール受信者を変更するときは、［Customizations（カスタマイズ）］［Brands（ブランド）］に移動します。目的のブランドを選択し、［Emails（メール）］をクリックします。テンプレートを選択し、オーディエンスの横の［Edit（編集）］をクリックします。メール通知とテンプレートのカスタマイズの詳細については、「メールテンプレートをカスタマイズする」を参照してください。

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

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

詳細については、「エンドユーザー向けのサインオン通知」を参照してください。
Authenticator enrolled notification email（Authenticatorの登録に関する通知メール） エンドユーザーまたは管理者がアカウントの新しいAuthenticatorに登録すると、エンドユーザーに確認メールが送信されます。

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

詳細については、「エンドユーザーへのAuthenticator登録完了通知メール」を参照してください。
Authenticatorのreset notification email（リセットに関する通知メール） エンドユーザーまたは管理者がアカウントのAuthenticatorをリセットすると、エンドユーザーにメールが送信されます。

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

詳細については、「エンドユーザーへのAuthenticatorのリセット通知」を参照してください。
Password changed notification email（パスワードの変更に関する通知メール） エンドユーザーは、アカウントのパスワードを変更またはリセットすると、メール通知を受信します。このメールにはパスワードがリセットされた時刻や場所など、パスワードリセットの詳細が含まれています。

注：

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

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

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

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

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

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

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

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

新しいデバイスの振る舞い検知には以下が必要です。

  • ［強化された新規デバイス振る舞い検知］が有効になっていること。
  • パスワード/IDP/と設定されているプライマリ要素、または認証ポリシールールで許可された任意の要素で構成されたグローバルセッションポリシー。

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

制限事項

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

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

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

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

CAPTCHA統合

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

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

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

reCAPTCHA v2の場合は、［Invisible reCAPTCHA badge（非表示のreCAPTCHAバッジ）］を選択してください。

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

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

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

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

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

    ［Enable CAPTCHA for（次に対してCAPTCHAを有効化）］：CAPTCHAを使用する認証のタイプを1つ以上選択します。

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

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

    Sign-In Widgetの同じページでユーザー名とパスワードが、ユーザーに表示されるように認証フローを変更することができます。

    • orgが認証にIDプロバイダーを使用していないことを確認します。グローバルセッションポリシールールのAND［Identity provider is（IDプロバイダー）］で［Okta］オプションを使用できますが、［Specific IdP（特定のIdP）］オプションは使用できません。
    • すべてのグローバルセッションポリシールールで［Establish the user session with（次を使用してユーザーセッションを確立：）］オプションを［A password（パスワード）］に設定します。

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

  4. ［Save（保存）］をクリックします。

CAPTCHA接続のトラブルシューティング

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（組織のセキュリティ）］に移動し、組織のグローバル設定を構成します。

IP binding for Admin Console（Admin ConsoleのIPバインディング） この設定は、管理者と管理者のサインイン元のIPアドレスを関連付けます。セッション中にIPが変更された場合、管理者はOktaからサインアウトされ、システムログにイベントが表示されます。
Remember user on sign in（サインイン時にユーザーを記憶する） この設定により、Sign-In Widgetの［Username（ユーザー名）］フィールドが事前に入力されます。エンドユーザーは引き続き認証を受ける必要があります。最近のMFA Authenticatorや以前のセッションは記憶されません。
Stay signed in（サインインしたままにする） この設定を使用すると、ユーザーはブラウザーを閉じて開き直した後も継続するOktaセッションを確立できます。サインインしたままにすることを選択したユーザーは、グローバルセッションポリシーで定められた時間、MFAを再度求められることはありません。「サインインしたままにする」を参照してください。
［Show option to stay signed in before users sign in（サインイン状態を維持するオプションをユーザーのサインイン前に表示する）］ 早期アクセスリリース。この設定では、ユーザーが資格情報を入力する前に、［Keep me signed in（サインインしたままにする）］オプションが「Sign-In Widget」に表示されます。認証後プロンプトが認証ポリシーで構成されるようになります。「サインインしたままにする」を参照してください。
Activation emails are valid for（アクティベーションメールの有効期限） エンドユーザーに送信されるアカウントのアクティベーションメールでリンクの有効期限を設定します。メール通知の詳細については、「メールテンプレートをカスタマイズする」を参照してください。
Enforce device matching for creating sessions（セッションの作成にデバイスマッチングを適用）

デフォルトで、Oktaは認証リダイレクトが開始されたブラウザー内に留まることを保証します。Oktaはリクエストに提供されたデバイス識別子を比較します。これらが一致しない場合、Oktaはアプリへのアクセスを拒否し、IDプロバイダーセッションを作成しません。Oktaサポートから無効にするよう指示がない限り、この設定は有効にしておきます。
Username match criteria on sign in（サインイン時のユーザー名の一致条件） この設定によって、ユーザーのサインイン時にユーザーのプロファイルを照合する方法が決まります。［Match entire username（ユーザー名全体の一致）］を選択すると、ユーザーはドメインを含む完全なユーザー名を入力しないかぎりサインインできません。［Allow short match（短い一致を許可する）］を選択すると、ユーザーはドメインがなくてもサインインできます。
Users can view Recent Activity（ユーザーが最近のアクティビティを表示可能） この設定により、ユーザーの［最近のアクティビティ］ページが有効になります。このページには、ユーザーの最近のサインインアクティビティとアカウントのセキュリティイベントが表示されます。

パスワードベースの攻撃から保護

MFA時にパスワードの前に所有要素を必須にする

この機能が有効になっている場合、ユーザーはパスワードやその他の知識要素でIDを確認する前に所有要素で確認する必要があります。これにより、orgをパスワードの推測やパスワードスプレー攻撃から保護できます。

この機能を有効にすると、パスワードを最後に使用した要素として記憶するためのユーザーの設定が上書きされます。

  1. Admin Consoleで、［Security（セキュリティ）］［General（一般）］の順に進みます。
  2. ［パスワードベースの攻撃から保護］セクションで、［Edit（編集）］をクリックします。
  3. ［Require possession factor before password during MFA（MFA時にパスワードの前に所有要素を必須にする）］ドロップダウンメニューで［Enabled（有効）］を選択してこの機能を有効にするか、［Disabled（無効）］を選択して無効にします。
  4. ［Save（保存）］をクリックします。

「パスワードの前に所有要素を必須にする」は以下のシナリオでは機能しません。

  • MFAが不要な場合

  • ユーザーによる列挙の防止がトリガーされた場合、ユーザーはメールアドレスまたはパスワードを最初に要求される。

  • Classic Engine認証エンドポイントが使用されている場合

不明なデバイスからの不審なパスワード試行をブロックする

この機能が有効になっている場合、Orgは不明なデバイスからの不審なパスワード試行をブロックします。以前に使用したことがあるデバイスでOktaにサインインするユーザーは、Oktaにとって不明な別のデバイスによってロックアウトが引き起こされる場合でもロックアウトされません。

  1. Admin Consoleで、［Security（セキュリティ）］［General（一般）］の順に進みます。
  2. ［パスワードベースの攻撃から保護］セクションで、［Edit（編集）］をクリックします。
  3. ［Block suspicious password attempts from unknown device（不明なデバイスからの不審なパスワード試行をブロック）］ドロップダウンメニューで［Enabled（有効）］を選択してこの機能を有効にするか、［Disabled（無効）］を選択して無効にします。
  4. ［Save（保存）］をクリックします。

詳細については、「ポリシールールを追加する」を参照してください。

個々のユーザーが不明なデバイスを使用してサインインするのを許可できます。これは、前のデバイスを紛失した可能性があるユーザーが新しい不明なデバイスで初めてサインインする場合に役立ちます。「不明なデバイスのサインインを許可する」を参照してください。

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

この機能を有効にすると、ユーザーアカウントを特定してAuthenticatorを登録しようとする攻撃者からorgを保護できます。ユーザーが存在しないかサインインできない場合は、Authenticator検証エラーが送信されます。Oktaはアカウントが存在することを確認しません。

この機能はデフォルトで無効になっています。Oktaへのエンドユーザーのサインイン試行の詳細については、「新しいサインイン環境」を参照してください。

  1. Admin Consoleで、［Security（セキュリティ）］［General（一般）］の順に進みます。
  2. ［User Enumeration Prevention（ユーザーによる列挙の防止）］セクションで、［Edit（編集）］をクリックします。
  3. プレビューのみ：ユーザーによる列挙の防止を有効にするには、次のオプションのいずれか、または両方を選択します。
    • ［Authentication（認証）］：ユーザー認証試行でユーザーによる列挙の防止を有効または無効にします。
    • ［Recovery（復旧）］：復旧シナリオでユーザーによる列挙の防止を有効または無効にします。
  4. ユーザーによる列挙の防止を無効にするには、［Authentication（認証）］と［Recovery（復旧）］のチェックボックスをオフにします。
  5. ［Save（保存）］をクリックします。

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

  • Self Service Registration（セルフサービス登録）
  • JITフロー（メール認証あり）

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

Okta ThreatInsightの設定

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

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

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

関連項目

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

Okta HealthInsight

Okta ThreatInsight