一般的なセキュリティ

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

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

セキュリティ通知メール

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

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

通知メールが受信者に届かない場合、配信エラーの原因を示すイベント（配信済み、遅延、ドロップ、バウンス）がSystem Logに表示されます。

新規サインオンに関する通知メール	エンドユーザーが新規または認識されていないクライアントからサインインすると、エンドユーザーにメール通知が送信されます。このメールには、認証の時間と場所に加えて、サインインに使用したWebブラウザーやオペレーティングシステムなどのユーザーサインオンの詳細が含まれています。新規クライアントの識別に関する制限の詳細については、「新規サインオンに関する通知メール」を参照してください。注：新規orgの場合、この機能はデフォルトで無効になっています。詳細については、「エンドユーザー向けのサインオン通知」を参照してください。
オーセンティケーターの登録に関する通知メール	エンドユーザーまたは管理者がアカウントの新しいオーセンティケーターに登録すると、エンドユーザーに確認メールが送信されます。注：新規orgの場合、この機能はデフォルトで有効になっています。詳細については、「エンドユーザーへのオーセンティケーター登録完了通知メール」を参照してください。
オーセンティケーターのリセットに関する通知メール	エンドユーザーまたは管理者がアカウントのオーセンティケーターをリセットすると、エンドユーザーにメールが送信されます。注：新規Orgの場合、この機能はデフォルトで有効になっています。詳細については、「エンドユーザーへのオーセンティケーターのリセット通知」を参照してください。
パスワードの変更に関する通知メール	エンドユーザーは、アカウントのパスワードを変更またはリセットすると、メール通知を受信します。このメールにはパスワードがリセットされた時刻や場所など、パスワードリセットの詳細が含まれています。注：管理者が一時パスワードを設定した場合、エンドユーザーは一時パスワードからパスワードを変更した後にのみメール通知を受信します。代理認証（DelAuth）を使用したパスワードリセットのエンドユーザー通知はサポートされていません。ユーザーが非アクティブの場合、エンドユーザーにメール通知は送信されません。詳細については、「エンドユーザーへのパスワードの変更通知」を参照してください。

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

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

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

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

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

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

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

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

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

制限事項

識別において課題となる制限事項がいくつかあります。新しい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を参照してください。

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サービスを構成するには、次の手順を実行します。

Okta APIへのリクエストを認証するために必要なAPIトークンを作成します。「APIトークンを作成」を参照してください。
Admin Consoleで、［Security（セキュリティ）］［General（一般）］の順に進みます。
［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は、identifier first認証フローのパスワードリセットではサポートされていません。つまり、ユーザーが2番目のサインインページでパスワードを入力するときには、CAPTCHAは使用できません。

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

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

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

［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"

Organizationのセキュリティ

［Security（セキュリティ）］>［General（一般）］>［Organization Security（Organizationのセキュリティ）］に進んで、Organizationのグローバル設定を構成します。

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

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

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

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

Admin Consoleで、［Security（セキュリティ）］［General（一般）］の順に進みます。
［User Enumeration Prevention（ユーザーによる列挙の防止）］セクションで、［Edit（編集）］をクリックします。

プレビューのみ：ユーザーによる列挙の防止を有効にするには、次のオプションのいずれか、または両方を選択します。

［Authentication（認証）］：ユーザー認証試行でユーザーによる列挙の防止を有効または無効にします。
［Recovery（復旧）］：復旧シナリオでユーザーによる列挙の防止を有効または無効にします。

ユーザーによる列挙の防止を無効にするには、［Authentication（認証）］と［Recovery（復旧）］のチェックボックスをオフにします。

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

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

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

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

Okta ThreatInsightの設定

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

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

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