一般的なセキュリティ

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

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

セキュリティ通知メール

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

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

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

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

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

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

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

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

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

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

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

制限事項

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

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

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

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

CAPTCHA統合

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

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

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

• hCaptchaについては、https://docs.hcaptcha.com/api/#getting-your-api-keyを参照してください。
• reCAPTCHA v2については、https://developers.google.com/recaptcha/intro#overviewを参照してください。

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

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（保存）］をクリックします。

トラブルシューティング

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

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

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

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

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

1. Admin Consoleで、［Security（セキュリティ）］［General（一般）］の順に進みます。
2. ［パスワードベースの攻撃から保護］セクションで、［Edit（編集）］をクリックします。
3. ［Require possession factor before password during MFA（MFA時にパスワードの前に所有要素を必須にする）］ドロップダウンメニューで［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（保存）］をクリックします。

Okta ThreatInsightの設定

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

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

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

関連項目

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

Okta HealthInsight

Okta ThreatInsight