一般的なセキュリティ

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

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

セキュリティ通知メール

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

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

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

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

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

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

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

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

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

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

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

制限事項

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

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

• サインインに成功すると、デバイスのフィンガープリントがキャプチャされます。
• ユーザーのオペレーティングシステムまたはブラウザーに変更があると、新しいデバイス通知が生成される場合があります。
• Okta以外のIDプロバイダーによって開始されたサインインでは、新しいデバイス通知は生成されません。
• デバイスのフィンガープリントは、使用しているブラウザーに基づきます。エンドユーザーは、新しいブラウザータイプでサインインすると、新しいデバイス通知メールを受信します。
• ユーザーがサインインしたデバイスではなく、新しいモバイルアプリが検出されると、Oktaから新しいデバイスに関する通知メールが送信されます。
• 新しいデバイスの検出は常に完全に保証されるわけではありません。
• エンドユーザーは、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統合（CAPTCHA Integration）セクションで以下の設定を構成します。
   • タイプ（Type）：使用するCAPTCHAサービスを選択します。
   • サイトキー（Site key）：サービス構成からサイトキーをコピーします。
   • 秘密鍵（Secret key）：サービス構成から秘密鍵をコピーします。

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

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

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

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

   • orgが認証にIDプロバイダーを使用していないことを確認します。グローバルセッションポリシールールのIDプロバイダー（AND［Identity provider is）で Okta オプションを使用できますが、特定のIdP（Specific 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）に移動し、組織のグローバル設定を構成します。

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

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

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

1. Admin Consoleで、セキュリティ（Security） > 一般（General）に移動します。

2. パスワードベースの攻撃から保護（Protect against password based attacks）セクションで、編集（Edit）をクリックします。
3. MFA時にパスワードの前に所有要素を必須にする（Require possession factor before password during MFA）（Enabled）ドロップダウンメニューで有効（Enabled）（Require possession factor before password during MFA）を選択してこの機能を有効にするか、無効（Disabled）を選択して無効にします。
4. 保存（Save）をクリックします。

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

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

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

1. Admin Consoleで、セキュリティ（Security） > 一般（General）に移動します。

2. ユーザーによる列挙の防止（User Enumeration Prevention）セクションで、編集（Edit）をクリックします。
3. プレビューのみ。ユーザーによる列挙の防止を有効にするには、次のオプションのいずれか、または両方を選択します。
   • 認証（Authentication）：ユーザー認証試行でユーザーによる列挙の防止を有効または無効にします。

     早期アクセスリリース。セルフサービス機能を有効にするを参照してください。

     認証（Authentication）を選択すると、方式（Methods）フィールドが表示されます。ユーザーが検証に使用するAuthenticatorの名前を入力し、Enterキーを押します。追加する各Authenticatorについてこれを繰り返します。Authenticator名の横にあるxをクリックして削除します。

   • 復旧（Recovery）：復旧シナリオでユーザーによる列挙の防止を有効または無効にします。
4. ユーザーによる列挙の防止を無効にするには、認証（Authentication）と復旧（Recovery）のチェックボックスをオフにします。
5. 保存（Save）をクリックします。

Okta ThreatInsightの設定

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

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

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

関連項目

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

HealthInsight

Okta ThreatInsight