ThreatInsightなど、さまざまなグローバルorgセキュリティ設定を構成します。Consoleの[Security(セキュリティ)][General(一般)]に移動します。Emails(セキュリティ通知メール)]に移動してエンドユーザー向けの通知メールを構成します。Logに表示されます。orgに複数のブランドがある場合、これらの設定はデフォルトブランドにのみ適用されます。特定ブランドのメール受信者を変更するときは、[Customizations(カスタマイズ)][Brands(ブランド)]に移動します。目的のブランドを選択し、[Emails(メール)]をクリックします。テンプレートを選択し、オーディエンスの横の[Edit(編集)]をクリックします。メール通知とテンプレートのカスタマイズの詳細については、「メールテンプレートをカスタマイズする」を参照してください。エンドユーザーが新規または認識されていないクライアントからサインインすると、エンドユーザーにメール通知が送信されます。このメールには、認証の時間と場所に加えて、サインインに使用したWebブラウザーやオペレーティングシステムなどのユーザーサインオンの詳細が含まれています。新規クライアントの識別に関する制限の詳細については、「新規サインオンに関する通知メール」を参照してください。注:新規orgの場合、この機能はデフォルトで無効になっています。詳細については、「エンドユーザー向けのサインオン通知」を参照してください。エンドユーザーまたは管理者がアカウントの新しいAuthenticatorに登録すると、エンドユーザーに確認メールが送信されます。注:新規orgの場合、この機能はデフォルトで有効になっています。詳細については、「エンドユーザーへのAuthenticator登録完了通知メール」を参照してください。エンドユーザーまたは管理者がアカウントのAuthenticatorをリセットすると、エンドユーザーにメールが送信されます。注:新規Orgの場合、この機能はデフォルトで有効になっています。詳細については、「エンドユーザーへのAuthenticatorのリセット通知」を参照してください。エンドユーザーは、アカウントのパスワードを変更またはリセットすると、メール通知を受信します。このメールにはパスワードがリセットされた時刻や場所など、パスワードリセットの詳細が含まれています。注:管理者が一時パスワードを設定した場合、エンドユーザーは一時パスワードからパスワードを変更した後にのみメール通知を受信します。委任認証(DelAuth)を使用したパスワードリセットのエンドユーザー通知はサポートされていません。ユーザーが非アクティブの場合、エンドユーザーにメール通知は送信されません。詳細については、「エンドユーザーへのパスワードの変更通知」を参照してください。新規サインオンに関する通知メール新規サインオンに関する通知メールは、Authenticatorなどのほかのセキュリティ機能を補完するものであり、代替機能として使用するべきではありません。多くの場合、クライアントを簡単かつ正確に識別しますが、一部制限があります。新規デバイスのサインインに関する通知メールは、エンドユーザーのブラウザーのCookieまたはフィンガープリントに基づいて新規クライアントと識別された場合に送信されます。次の1つ以上のシナリオでは、クライアントは新規と見なされます。新しいブラウザータイプまたはバージョン。新しいオペレーティングシステムのタイプまたはバージョン。新規または更新されたアプリケーション。認識されないブラウザーまたはオペレーティングシステム(通知メールではUnknown(不明)と表示されます)。FastPassを使用してOktaにサインインする場合、クライアントは新規とは見なされません。新しいデバイスの振る舞い検知には以下が必要です。[強化された新規デバイス振る舞い検知]が有効になっていること。パスワード/IDP/と設定されているプライマリ要素、または認証ポリシールールで許可された任意の要素で構成されたグローバルセッションポリシー。認証が認識されない場合、エンドユーザーはすぐに管理者に連絡してアカウントのアクティビティを調査する必要があります。管理者は、ユーザーのセッションの終了、ユーザーのアカウントのロック、Authenticatorの追加などのアクションを実行して、セキュリティを向上させることができます。識別において課題となる制限事項がいくつかあります。新しいIPアドレスや新しい場所などのほかの識別子に加えてメール通知を有効にすると、エンドユーザーのアカウントで疑わしいアクティビティを特定する際の精度が向上します。新規クライアントを識別するための現在の制限事項は次のとおりです。サインインに成功すると、デバイスのフィンガープリントがキャプチャされます。ユーザーのオペレーティングシステムまたはブラウザーに変更があると、新しいデバイス通知が生成される場合があります。Okta以外のIDプロバイダーによって開始されたサインインでは、新しいデバイス通知は生成されません。デバイスのフィンガープリントは、使用しているブラウザーに基づきます。エンドユーザーは、新しいブラウザータイプでサインインすると、新しいデバイス通知メールを受信します。モバイルサインインの場合、新しいデバイス通知メールは、サインインに使用されたデバイスではなく、新しいモバイルアプリケーションの検出に基づいて送信されます。新しいデバイスの検出は常に完全に保証されるわけではありません。エンドユーザーは、40日以内にアカウントにサインインしなかった場合、予期しない新規または不明なデバイス通知メールを受信することがあります。エンドユーザー通知の詳細については、「メールテンプレートをカスタマイズする」を参照してください。CAPTCHA統合orgのセキュリティを強化するためのオプションとして、OktaはCAPTCHAをサポートし、自動サインインの試行を防ぎます。v2の2つのサービスのいずれかを統合できます。Oktaによってサポートされるベンダー実装はどちらも目には見えません。各サービスはサインイン時にバックグラウンドでリスク分析ソフトウェアを実行し、ユーザーがボットである可能性を判断します。このリスク分析は、サービスに対して構成した設定に基づいています。CAPTCHAを使用するようにorgを構成する前に、任意のベンダーにサインインするか、アカウントにサインアップしてから、次の手順に従います。hCaptchaについては、https://docs.hcaptcha.com/api/#getting-your-api-keyを参照してください。v2については、https://developers.google.com/recaptcha/intro#overviewを参照してください。badge(非表示のreCAPTCHAバッジ)]を選択してください。いずれかのサービスの構成時に、org構成のサイトキーと秘密鍵を取得する必要があります。reCAPTCHAまたはhCAPTCHAサービスを作成したら、ベンダーのサービス構成ページでドメインを指定してください。例:Webアプリケーションがカスタマイズされたドメイン[myapp.com]および[testapp.com]に基づいている場合、CAPTCHAサービスの各ドメインを指定する必要があります。Oktaベースの場合、CAPTCHAサービスのドメインリストに[okta.com]を追加する必要があります。OktaでCAPTCHAサービスを構成するには、次の手順を実行します。APIへのリクエストを認証するために必要なAPIトークンを作成します。「APIトークンを作成」を参照してください。Consoleで、[Security(セキュリティ)][General(一般)]の順に進みます。[CAPTCHA統合]セクションで以下の設定を構成します。[Type(タイプ)]:使用するCAPTCHAサービスを選択します。key(サイトキー)]:サービス構成からサイトキーをコピーします。key(秘密鍵)]:サービス構成から秘密鍵をコピーします。for(次に対してCAPTCHAを有効化)]:CAPTCHAを使用する認証のタイプを1つ以上選択します。Up(サインアップ)]:ユーザーは最初の登録およびサインイン時にCAPTCHAに合格するよう求められます。Reset(パスワードリセット)]:ユーザーはパスワードをリセットするときにCAPTCHAに合格するよう求められます。On(サインオン)]:ユーザーはサインイン時にCAPTCHAに合格するよう求められます。first認証フローのパスワードリセットではサポートされていません。ユーザーが2番目のサインインページでパスワードを入力するときには、CAPTCHAは使用できません。Widgetの同じページでユーザー名とパスワードがユーザーに表示されるように認証フローを変更します。orgが認証にIDプロバイダーを使用していないことを確認します。IdP(特定のIdP)]オプションは使用できません。password(パスワード)]に設定します。手順については、「グローバルセッションポリシールールを追加する」と「サインインフロー」を参照してください。[Save(保存)]をクリックします。orgにアクセスできなくなります。再構成するには、まず次の手順をCAPTCHA管理の公開APIに送信します。Security(組織のセキュリティ)]に移動し、組織のグローバル設定を構成します。この設定は、管理者と管理者のサインイン元のIPアドレスを関連付けます。セッション中にIPが変更された場合、管理者はOktaからサインアウトされ、システムログにイベントが表示されます。Widgetの[Username(ユーザー名)]フィールドが事前に入力されます。エンドユーザーは引き続き認証を受ける必要があります。Authenticatorや以前のセッションは記憶されません。この設定を使用すると、ユーザーはブラウザーを閉じて開き直した後も継続するOktaセッションを確立できます。サインインしたままにすることを選択したユーザーは、グローバルセッションポリシーで定められた時間、MFAを再度求められることはありません。「サインインしたままにする」を参照してください。早期アクセスリリース。Widget」に表示されます。認証後プロンプトが認証ポリシーで構成されるようになります。「サインインしたままにする」を参照してください。エンドユーザーに送信されるアカウントのアクティベーションメールでリンクの有効期限を設定します。メール通知の詳細については、「メールテンプレートをカスタマイズする」を参照してください。デバイスバインディングにより、リダイレクトリクエストはそのリクエストが生成されたブラウザーでのみ使用されるようになります。Engineとの互換性を考慮してこの機能を無効にすることもできますが、Oktaでは無効にすることを推奨していません。この機能を無効にした場合、Oktaは認証フローを開始したアクターのみが状態トークンを使用できるようにするための確認を行いません。この設定によって、ユーザーのサインイン時にユーザーのプロファイルを照合する方法が決まります。username(ユーザー名全体の一致)]を選択すると、ユーザーはドメインを含む完全なユーザー名を入力しないかぎりサインインできません。match(短い一致を許可する)]を選択すると、ユーザーはドメインがなくてもサインインできます。この設定により、ユーザーの[最近のアクティビティ]ページが有効になります。このページには、ユーザーの最近のサインインアクティビティとアカウントのセキュリティイベントが表示されます。パスワードベースの攻撃から保護MFA時にパスワードの前に所有要素を必須にするこの機能が有効になっている場合、ユーザーはパスワードやその他の知識要素でIDを確認する前に所有要素で確認する必要があります。これにより、orgをパスワードの推測やパスワードスプレー攻撃から保護できます。この機能を有効にすると、パスワードを最後に使用した要素として記憶するためのユーザーの設定が上書きされます。Consoleで、[Security(セキュリティ)][General(一般)]の順に進みます。[パスワードベースの攻撃から保護]セクションで、[Edit(編集)]をクリックします。MFA(MFA時にパスワードの前に所有要素を必須にする)]ドロップダウンメニューで[Enabled(有効)]を選択してこの機能を有効にするか、[Disabled(無効)]を選択して無効にします。[Save(保存)]をクリックします。「パスワードの前に所有要素を必須にする」は以下のシナリオでは機能しません。不明なデバイスからの不審なパスワード試行をブロックするこの機能が有効になっている場合、Orgは不明なデバイスからの不審なパスワード試行をブロックします。以前に使用したことがあるデバイスでOktaにサインインするユーザーは、Oktaにとって不明な別のデバイスによってロックアウトが引き起こされる場合でもロックアウトされません。Consoleで、[Security(セキュリティ)][General(一般)]の順に進みます。[パスワードベースの攻撃から保護]セクションで、[Edit(編集)]をクリックします。device(不明なデバイスからの不審なパスワード試行をブロック)]ドロップダウンメニューで[Enabled(有効)]を選択してこの機能を有効にするか、[Disabled(無効)]を選択して無効にします。[Save(保存)]をクリックします。詳細については、「ポリシールールを追加する」を参照してください。個々のユーザーが不明なデバイスを使用してサインインするのを許可できます。これは、前のデバイスを紛失した可能性があるユーザーが新しい不明なデバイスで初めてサインインする場合に役立ちます。「不明なデバイスのサインインを許可する」を参照してください。ユーザーによる列挙の防止この機能を有効にすると、ユーザーアカウントを特定してAuthenticatorを登録しようとする攻撃者からorgを保護できます。ユーザーが存在しないかサインインできない場合は、Authenticator検証エラーが送信されます。Oktaはアカウントが存在することを確認しません。この機能はデフォルトで無効になっています。Oktaへのエンドユーザーのサインイン試行の詳細については、「新しいサインイン環境」を参照してください。Consoleで、[Security(セキュリティ)][General(一般)]の順に進みます。Prevention(ユーザーによる列挙の防止)]セクションで、[Edit(編集)]をクリックします。プレビューのみ:ユーザーによる列挙の防止を有効にするには、次のオプションのいずれか、または両方を選択します。[Authentication(認証)]:ユーザー認証試行でユーザーによる列挙の防止を有効または無効にします。[Recovery(復旧)]:復旧シナリオでユーザーによる列挙の防止を有効または無効にします。ユーザーによる列挙の防止を無効にするには、[Authentication(認証)]と[Recovery(復旧)]のチェックボックスをオフにします。[Save(保存)]をクリックします。Prevention(ユーザーによる列挙の防止)]は有効になりません。Registration(セルフサービス登録)JITフロー(メール認証あり)詳細については、「ユーザーの管理」を参照してください。ThreatInsightはOkta顧客ベース全体のデータを集約し、このデータを使用して、資格情報を使った攻撃を試みる悪意のあるIPアドレスを検出します。ThreatInsightの無料の試用版では機能を制限して動作しています。ThreatInsightが必要な場合は、Oktaサポートまでご連絡ください。ThreatInsight」を参照してください。それぞれの商標は、それぞれの商標所有者に帰属します。