Vonage Protection Suite for Oktaのセットアップ方法

はじめに

ユーザーがOktaで本人確認を行う必要がある場合、Oktaはワンタイムパスワード（OTP）を生成します。ただし、OktaはOTPを直接送信しません。代わりに、OTPをユーザーに配信する外部プロバイダーに依存しています。そのため Okta用Vonage Protection Suite SMS および音声 OTP 配信用の管理されたプラグアンドプレイコネクタを提供することで、この目的に対応します。このコネクタは、Telephony Inline Hooksを介してOkta Identity Engineに直接統合され、Vonage Verifyを介してSMSまたは音声通話でOTPを配信します。このコネクタは、Vonage Cloud Runtime (VCR) 上に構築されています。

サポートされるOktaプラットフォーム

Vonage Protection Suite for Oktaは、Okta Workforce Identity Cloudで利用可能なOktaのTelephony Inline Hook（Oktaアイデンティティエンジン（OIE）と従来のClassic Engineの両方を含む）を介して統合されます。このリリースでは、Auth0（Okta Customer Identity Cloud）はサポートされていません。Auth0は、Telephony Inline Hookとは異なる拡張性モデル（Actions/カスタムクレデンシャルプロバイダ）を使用しており、別途統合が必要です。

2層の不正インテリジェンス・モデル

について Okta用Vonage Protection Suite は2層の不正インテリジェンス・モデルを使用している：

  • アイデンティティ・インサイトのOTP番号事前検証（オプション）:キャリアデータベース（有効性、キャリア）に照らし合わせて番号をスクリーニングし、OTP配信が開始される前に不正をブロックする。エンドユーザーからのアクションを必要としないため、これは受動的なインテリジェンスレイヤーです。
  • OTP中のレイヤー2不正防御装置:SMSポンピング保護、地理的許可、速度制御、速度制限。

このガイドでは、OktaテナントをVonage Verifyに接続するために Okta用Vonage Protection SuiteOTPはSMSまたは音声で確実に配信される。

コネクターの流れ

次の図は、OktaとVonage Verifyの間のコネクタの配置を示しています：

Vonage Protection Suite for Okta Flow Diagram

前提条件

始める前に、以下を確認してください：

  • Okta Identity Engine (OIE)を備えたアクティブなOktaテナント。
  • Oktaで電話認証を有効にするOkta Admin Console > Security > Authenticators > Setup > Phone).
  • Okta Admin Consoleにアクセスし、インラインフックとイベントフックを設定できます。
  • Vonage API アカウント (無料でご登録いただけます。)とAPIキー(これらの認証情報はあなたの API設定 Vonage Dashboard内)。
  • へのアクセス Vonageダッシュボード.
  • Vonage Cloud Runtime Advancedサブスクリプション。お持ちでない場合は、Vonage Customer Success Associate (CSA)に連絡してアクティベートしてください。

Vonage Cloud Runtimeにコネクタをデプロイする

  1. ログイン Vonage Cloud Runtime をクリックしてください。 Okta用Vonage Protection Suite タイルを使用している。
  2. 右側のメニューから APIキー に対してコネクタをデプロイします。アカウントに API キーが 1 つしかない場合、この手順は自動的にスキップされます。
  3. クリック 新しいインスタンスをデプロイする.
Deploy the Connector on Vonage Cloud Runtime
  1. コネクタ構成タイプで スタンダード をクリックしてください。 続ける.
Set up your project deployment
  1. パラメータを入力してください：
    • 地域:地域 : エンティティがホストされる地域。
    • インスタンス名： インスタンスの固有名。
    • Vonage番号（オプション）:この番号はSMS送信者IDとなり、E.164形式で数字のみで構成されている必要があります(「+」記号のない国際番号)。この番号が設定されていない場合、以下に指定するブランド名が代わりに使用されます。発信者番号はVerifyによってランダムに選択されるため、この値は音声通話には適用されません。
    • ブランド名（必須）:OTP メッセージ本文は、SMS でこのブランド名を使用する。この値は音声通話では無視されます。代わりに、発信者番号は宛先地域に適したものとしてVerifyによってランダムに選択されます。
    • 音声通話のフォールバック（必須）: 有効にすると、SMS配信に失敗した場合、コネクタは自動的に音声通話を試みます。
Set up your project parameters part 1
Set up your project parameters part 2
  1. クリック 続ける インスタンスをデプロイする。

コネクタの設定

管理者アプリケーションの起動

インスタンスのデプロイ後、コネクタの Admin Applications を起動します。これにより、セキュリティ・ポリシーの設定と認証トークンの生成が可能になります。そのためには、以下の手順に従ってください：

  1. 以前に作成したインスタンスを選択し 打ち上げ ボタンをクリックする。
Launch the Admin App
  1. をクリックして、Vonage 認証情報を使って認証します。 Vonageで本人確認を行う ボタンをクリックする。

ダッシュボード・タブを見直す

コネクタのAdmin Applicationを起動すると、次のようにリダイレクトされます。 ダッシュボード タブを使用します。これは、OTP の配信と認証アクティビティをリアルタイムで可視化します。

Review the Dashboard

について ダッシュボード タブには以下のデータが表示される：

  • カウンターセクション は次のような指標を示している：
    • SMS合計:SMS 配信の全体的な試行回数（成功した回数と失敗した回数の両方）。
    • SMSの成功:正常に完了したSMSの配信数。
    • SMSブロック:Identity InsightsまたはFraud DefenderによってブロックされたSMS配信の数。
    • トータル・ボイス:音声配信の試行回数の合計（成功および失敗の両方）。
    • 声の成功:正常に完了した音声配信の総数。
    • 音声ブロック:ブロックされた音声配信の数。
  • 最近のOTP活動 には、すべてのトークンについて最近 10 回の OTP 配信試行が表示される：
    • タイムスタンプ:いつ配達を試みたか。
    • 目的地:マスクされた電話番号。
    • チャンネル:SMS/VOICE.
    • ステータス:SUCCESS（成功）、FAILED（失敗）、FLAGGED（フラグ・アンド・デリバリーの場合はアンバー）。
    • 説明:目のアイコンをクリックすると、失敗またはフラグが立った完全な理由が表示されます。
    • レイテンシー:配信完了までの時間（ミリ秒）。
    • トークン:短縮されたトークン識別子。
  • 最近の認証イベント は、Oktaから取得した直近10件の認証イベントを表示します：
    • タイムスタンプ:イベントがいつ公開されたかを示す
    • トークン:トークンの短縮識別子。
    • イベント:Oktaイベントの種類（例． user.authentication.auth_via_mfa).
    • ファクター:使用される認証要素（例：SMS_FACTOR、CONVERSION）。
    • 成果:SUCCESS、FAILURE、または UNKNOWN。
    • ユーザー:OktaアクターID。
    • リクエスト:認証要求に関連付けられたID。
  • トークン一覧:ダッシュボードには、作成されたすべてのトークンが現在のステータスとともに表示されます：
    • アクティブ:トークンは現在有効であり、利用されている。
    • 猶予期間:新しいトークンがこのトークンの代わりとなり、24時間の移行期間中は両方のトークンが同時に機能する。
    • 期限切れ:トークンの有効期限を超えました。
    • 取り消された:トークンは手動で無効化され、使用できなくなりました。
  • トークンの回転 は、元のトークンと同じセキュリティ・クレームを持つ新しいトークンを生成する。元のトークンは、両方のトークンが受け入れ可能な 24 時間の猶予期間に入ります。トークン・ローテーションを使用して、サービスを中断することなく定期的に認証情報を更新します。
  • トークンの失効 トークンは即座に無効化される。このアクションは、トークンが侵害された場合や不要になった場合に実行する必要があります。失効の効果は即座に現れ、取り消すことはできません。

トークン生成タブ

次に トークン作成 タブで、セキュリティポリシーの設定とトークンの生成を行います。このトークンは、Okta とコネクタ間の通信を認証する役割を果たします。さらに、そのトークンを使用して実行される各OTP配信に適用されるセキュリティポリシーがエンコードされます。

Generate the Token

レイヤー 1: Identity Insights による OTP ナンバーの事前検証 (オプション）

コネクタの2層セキュリティモデルは、オプションのIdentity InsightsによるOTP番号事前検証から始まります。

アイデンティティ・インサイト は、携帯電話事業者のデータベースにリアルタイムでアクセスできるVonage APIです。電話番号のリスクレベルを評価するのに役立ちます。コネクタでは、OTP送信前のスクリーニング・ツールとして機能します。コネクタはこれらのチェック結果を使用します。

注： 有効化する各チェックはリクエストごとに課金されますが、Numbers FormatとValidityのチェックは無料です。Original Carrier LookupおよびCurrent Carrier Lookupは、リクエストごとに料金が発生することにご留意ください。料金の詳細については Vonage料金ページ.

  1. を有効にする。 アイデンティティ・インサイト 機能を使用するには、トグルを オン.
  2. 実施したいチェックを選択する：
    • Numbersのフォーマットと有効性（無料）:有効な携帯電話番号かどうかを確認し、VoIPやバーチャル番号に自動的にフラグを付けます。
    • オリジナルキャリア検索（リクエストごとに課金）:この番号が最初に発行されたときに割り当てられたネットワークと回線タイプを識別する。最初からVoIPとして登録された番号をスクリーニングするのに便利。後にVoIPにポートされた携帯電話番号は捕捉されない。
      • ネットワーク・タイプ・フィルター:選択されていないネットワーク・タイプのNumbersはフラグが立てられます。
    • 現在のキャリア検索（リクエストごとに有料）:ポーティングによる変更も含め、現在この番号にサービスを提供しているネットワークとライブ回線タイプを識別します。
  3. 地理的およびチャネルフィルタ：これらのフィルタは、電話番号の地理的またはネットワーク特性に基づいて、OTP配信を制限します。
    • 国別許可リスト:ISO 3166-1 alpha-2の国コードを入力してください（例：US、GB、DE）。これらの国に関連する番号のみが許可されます。すべての国を許可するには空欄にしてください。
  4. 検証チェック中に宛先番号にフラグが立った場合に取るアクションを選択します：
    • ブロックOTP:OTP が配信されません。失敗の理由は ダッシュボードタブ > 最近の OTP アクティビティ > 説明.
    • フラッグ＆デリバリー:OTPは配信されるが、ダッシュボードではアンバーのフラグが立ち、さらに確認する必要がある。潜在的に正当なユーザーをブロックせずに可視化したい場合に使用します。ステータスは ダッシュボードタブ > 最近のOTPアクティビティ > ステータス.
    • ログのみ:チェック結果は記録されるが、それ以上の処置は取られない。フラグは付けられない。ブロックまたはフラグポリシーにコミットする前に、フラグレートを理解するために初期展開時に便利です。OTPは通常通り送信されます。には何も表示されません。 ダッシュボード タブ

レイヤー2：OTP時の不正防御

番号がレイヤー1のチェックを正常に通過すると（またはIdentity Insightsが無効の場合）、OTPがVonage Verifyに送信され、配信されます。この段階で、追加の保護レイヤーとして Fraud Defender が引き継がれます。

詐欺ディフェンダー SMSポンピング、人為的なトラフィック増加（AIT）、およびトラフィックバースト攻撃に対する防御。この機能を有効にするための操作は必要ありません。Vonage Verifyを通じて処理されるすべてのOTPトラフィックに自動的に適用されます。

ティアの選択

コネクタの設定パネルで、Fraud Defender Advancedは次のように表示されます。 含まれている、 Verifyトラフィックすべてに追加料金なしでご利用いただけます。Fraud Defender Premiumが必要な場合は、Vonage Account Managerに連絡して有効にしてください。

重要だ： AITプロテクションやSMSバーストプロテクションなどの高度なプロテクションは自動的には有効になりません。別途、Vonage Dashboardでの有効化と設定が必要です。これらを設定するには Fraud Defender オンボーディング・ガイド.

レートリミット

10分間のウィンドウ内で、電話番号ごとにOTPリクエストの最大数を設定します。デフォルトは5回です。これにより、同じ電話番号をターゲットに OTP 要求が繰り返されるのを防ぐことができます。この機能は不要な場合は無効にできます。

配送

ブランド名:OTP メッセージで受信者に表示されるブランド名。サーバーで設定されたグローバルブランド名を上書きします。
SMSから音声へのフォールバック:SMS配信に失敗した場合、音声通話で自動的に再試行します。この機能は必要なければ無効にできます。

トークンの有効期限

生成するトークンの有効期間を、24時間、7日間、30日間、90日間（デフォルト）、またはNeverから選択します。有効期間が短いほどセキュリティは向上しますが、より頻繁にローテーションする必要があります。トークンには、現在の国のネットワークと電話番号の設定が埋め込まれます。

生成されたトークンの詳細を記録する

セキュリティポリシーが設定され、トークンが生成されたら、生成されたトークンの詳細を記録してください。トークンの詳細は二度と表示されません。この情報は、Oktaの設定ステップでOktaを設定するために不可欠です：

  • テレフォニーウェブフックURL
  • イベント・ウェブフックURL
  • 認証ヘッダー名
  • トークンの秘密

Oktaを設定する

コネクタをデプロイしてトークンを生成したら、Okta Admin ConsoleでTelephony Inline HookとEvent HookをWebhook URLとトークンで設定します。

テレフォニー・インラインフックの設定

次に、以下の手順に従って、テレフォニー・インライン・フックを設定します：

  1. Okta Admin Consoleにログインします。
  2. に移動する。 ワークフロー > インラインフック.をクリックしてください。 インライン・フックの追加を選択する。 テレフォニー.
Configure the Telephony Inline Hook
  1. フックの詳細を記入してください：
  • 名称:名前（例："Vonage OTP"）を入力します。
  • URL:生成されたトークンの詳細からTelephony Webhook URLを貼り付けます。
  • 認証フィールド:生成されたトークンの詳細から Auth Header Name を貼り付けます。
  • 認証秘密:生成されたトークンの詳細からトークンシークレットを貼り付けます。
  1. クリック セーブ.

イベント・フックの設定

次に、以下の手順でイベントフックを設定します：

  1. に移動する。 ワークフロー > イベントフック.
Configure the Event Hook
  1. をクリックする。 イベントフックの作成.
  2. フックの詳細を記入してください：
  • 名称:名前（例："Vonage Events"）を入力します。
  • URL:生成されたトークンの詳細からEvent Webhook URLを貼り付けます。
  • 認証フィールド:生成されたトークンの詳細から Auth Header Name を貼り付けます。
  • 認証秘密:生成されたトークンの詳細からトークンシークレットを貼り付けます。
  1. について リクエスト セクションでは、Okta がエンドポイントに送信するリクエストを定義します。リクエストを MFAによるユーザー認証 イベントを開催する。
  2. クリック 保存して続行.

接続性の検証

次に、Oktaとコネクタ間の接続がアクティブであることを確認します。そのためには、Okta Admin Consoleで両方のフックにActive & Verifyのステータスが表示されていることを確認する必要があります：

  1. のVerifyボタンをクリックします。 エンドポイントの所有権の検証 イベントフックを作成した直後に表示されるポップアップ。
Verify Connectivity

統合のテスト

Oktaのビルトインプレビューツールを使用して、手順に従って統合をテストすることができます：

  1. Okta Admin Consoleで、次の場所に移動します。 セキュリティ > 認証機能 > セットアップ > 電話 をクリックして、Oktaで電話認証が有効になっていることを確認してください。
  2. プレビューテストを実行する：
    • に移動する。 ワークフロー > インラインフック.
    • 作成したテレフォニー・インライン・フックを見つけ アクション > プレビュー.
    • で インラインフックリクエストの設定:
      • テストユーザーの情報を入力します： data.userProfile (有効な認証手段として電話を持っているユーザー）。
      • 選択 requestType (MFA登録、MFA認証、Accountロック解除、またはパスワードリセット）。
    • クリック リクエストの作成 でJSONペイロードを構築する。
    • クリック 編集 をクリックし、必要であればリクエストを修正する。
    • デフォルトの電話番号（9876543210）をE.164形式の実際の携帯電話番号（例：+447700900000）に置き換えてください。
    • クリック 回答を見る を使ってフックを起動します。成功するとステータスが表示される： 成功 を配達期間と一緒に送る。

重要だ： OktaとVonage間の接続に失敗すると、OktaはOTPを生成しません。コネクタのログを確認し、Webhook URLとトークンが正しいかVerifyしてください。

トラブルシューティング

クイックチェック

フルフローをトレースする前に、以下をVerifyする：

資格証明書:OktaのTelephony Webhook URL、Event Webhook URL、Auth Header Name、Token Secretが、トークン生成詳細の値と完全に一致していることを確認します。

フックの状態:Okta Admin Consoleで、次の場所に移動します。 ワークフロー > インラインフック をクリックし、フックのステータスが「Active」および「Verify」であることを確認します。

ダッシュボード:コネクタの「ダッシュボード」タブで最近の OTP アクティビティを確認します。FAILED または FLAGGED イベントを探し、説明アイコンをクリックしてエラーの詳細を確認します。

アイデンティティ・インサイト:OTP がブロックされる場合、Identity Insights が宛先番号にフラグを立てているかどうかを確認する。を調整することを検討してください。 Numbersの場合 フラグが立つ アクションをブロック > フラグと配信またはテストのためのログのみ。

電話認証:Oktaで電話認証が有効になっていることを確認します： Okta Admin Console > Security > Authenticators > Setup > Phone.

問題を段階的に追跡する

何かが期待通りに動作しない場合、以下の段階を経て問題を追跡する：

  1. Oktaはリクエストを送信します。:をチェックする。 Okta Admin Console > レポート > システムログ フックコール、ターゲットURL、リクエストステータスを指定する。
  2. コネクタがリクエストを処理する:チェック Vonage Cloud Runtime > インスタンス > あなたのインスタンス > ログ 受信リクエスト、Identity Insights の結果、および Verify API 呼び出しについて。
  3. OTP配信:チェック Vonage Dashboard > メッセージログ メッセージのステータス、チャンネル、送信者ID、エラーコード、Fraud Defenderのブロック。
  4. 認証イベントを受信:チェック コネクタ管理者ダッシュボード > 最近の認証イベント 受信したイベント、イベントの種類、要因、結果、トークンの一致。
  5. コンバージョンを記録:チェック Vonage Dashboard > ベリファイログ コンバージョン・ステータス、コンバージョン・フィー、コンバージョン・ミッシングについて。

コネクタエラーコードとIdentity Insightsサブコード

コネクタのエラーコードとIdentity Insightsのサブコードの完全なリストについては、以下を参照してください。 Vonage Protection Suite for Okta ユーザーガイド.

お困りですか？

上記の「トラブルシューティング」を使用しても問題が解決しない場合は、以下までご連絡ください。 Vonageヘルプセンター.リクエストを送信する際は、APIキー（アカウントIDのみ、シークレットは不可）、OktaシステムログのInline HookイベントID、および関連するスクリーンショットやログを含めると、迅速な解決に役立ちます。

さらに読む