- ホーム
- /
- 投稿記事
コメントありがとうございます。
安全な通話とスパム対策
この記事の内容
フィードバックがある場合電話ネットワークはスパム通話やフィッシング攻撃の脅威に直面しており、 企業、中小企業、消費者に影響を及ぼしています。スパム通話は業務時間を無駄にする一方、フィッシング 攻撃は機密情報を危険にさらし、 銀行、医療、政府業務などの重要なサービスを妨害する可能性があります。
スパム対策 STIR/SHAKEN ポリシー
サービスプロバイダーは STIR/SHAKEN 消費者をスパム電話から保護するためにネットワークに導入されています。このフレームワークは、FCC ガイドラインの一部として、すでに米国とカナダ全土で実施されています。発信者ID情報を検証することで、疑わしい電話にフラグを立て、知らない番号からの電話を受ける際にユーザーがより安心して対応できるようになります。
一つの方法について理解する
安全な電話 ID 再訪 (済み) および TOKEN (SHAKEN) を使用した確認済み情報の署名ベースの取り扱いは、相互に接続された標準のフレームワークです。これは、相互に接続された電話ネットワークを通じて移動する通話が、元のサービス プロバイダーによる正当性として署名され、利用者に到達する前に受け取るサービス プロバイダーによって検証された発信者 ID をもたて確認します。
SIP P-Asserted-Identityヘッダーの verstat パラメータを通じて検証結果を伝えるために、終端サービスプロバイダはこれらを使用する。 options:
-
TN-Validation-Passed— 検証は結果 A, B, C が発信番号に対して証明した結果, 正常に行いました。 -
TN-Validation-Failed- 発信者が確認できませんでした。 -
No-TN-Validation— これはさまざまな理由により検証が失敗する場合があります。例: E.164 番号の形式が正されません。
SHAKEN のテストレベル A、B、C では、元のサービス プロバイダーが通話番号との関係をテストします。
-
A：サービスプロバイダは、発信者が電話番号を発信者 ID として使用する権利を持っている可能性を証明できます。
-
B：顧客が既知です。しかし、発信者 ID を使用する権利を持っている場合は不明です。
-
C: A または B の要件を満たしてない。例えば：国際通話。
Verstat の値と証明
Webex Calling は着信コールの verstat パラメータを処理し、Cisco クライアントに発信者 ID の処理結果を表示します。
この表は、クライアントへの発信者 ID 通知を実行するために使用される verstat 情報を示しています。
|
値を変換 |
テストレベル |
Cisco クライアントに表示される値 |
|---|---|---|
|
TN 検証に成功しました |
提供されていない |
検証済みの発信者 |
|
A |
検証済みの発信者 | |
|
B |
スパムの疑いあり | |
|
C |
スパムの疑いあり | |
|
TN 検証に失敗しました |
任意の値 |
不正の疑いあり |
|
TN 検証なし |
任意の値 |
スパムの疑いあり |
|
verstat パラメータなし |
任意の値 |
スパムの疑いあり |
Unified Call History をサポートする Cisco クライアントは、顧客レコードの発信者 ID の処理に応じてアイコン通話履歴します。
Webex アプリでは、テストのテキストとアイコンが表示され、MPP デバイスにのみアイコンが表示されます。
オンネット通話の検証
1 つの電話PSTNに加えて、ネット上の通話の発信者-ID の処理は以下のルールに従って行われます。
-
Webex Calling ユーザー間のネット上の通話—検証されたユーザー (アイコン付き)。
-
ユーザーから別のユーザーへのCisco Unified Communications ManagerネットWebex Calling - 検証済みユーザー (アイコン付き)。オンプレミスおよび Communication Manager ユーザー Cisco Unifiedからの通話は、設定されたエンタープライズ ダイヤル プランと一致する発信者 ID に基づいて分類されます。
-
ユーザーからオンプレミスWebex CallingユーザーへのCisco Unified Communications Managerネット通話—Communication Manager クライアントにCisco Unified通知なし。
通話転送、コール パーク、コール ピックアップ、通話転送、発信者 ID などの通話中の機能の場合、発信者 ID の処理は、最初の通話レグの verstat 値の処理に基づいて処理されます。
Webex Calling ユーザーへの着信コールが転送され、発信番号が変更されると、着信コール要求の verstat 値に基づいて発信者 ID の処理が決定されます。
サポートされているデバイス
スパム検出は次の Cisco エンドポイントでサポートされています。
-
Webex アプリ—デスクトップおよびモバイル バージョン 42.5 以上。
-
MPP 電話 - ファームウェア バージョン 11.3.7 以降の 6800、7800、8800、および 9800 MPP デバイスをサポートします。
管理者の構成
Control Hub を使用したユーザー通知のプロビジョニング
管理者は、未確認の発信者についてユーザーに通知する送信を構成することができます。管理者は、読み込み中に大振り分けできなかった問題の通話をブロックできるよう設定することができます。これにより、潜在的な詐欺通話がユーザーのエンドポイントに送信されなくなります。
組織レベルで通知設定を構成するには、以下の手順に従います。
| 1 | |
| 2 |
サービス へ移動 > を呼び出します。 |
| 3 |
[サービスの設定 ] に進 み、[発信者 ID 検証] までスクロールします。 |
| 4 |
トグルを使用して、以下のオプションをアクティブにします。
通話表示機能と着信 ID 設定は、米国とカナダの Webex Calling の場所にのみ適用されます。その他の場所では、発信者 ID 設定に関係なく、通話が通常どおり表示されます。 |
スパム表示のために CUBE を構成する
verstat 情報を Webex Calling に渡すには、Local Gateway または CUBE を使用して Webex Calling に接続されたオンプレミスの PSTN を使用する米国およびカナダの組織は、CUBE でこれらの設定を構成する必要があります。
PSTN サービス プロバイダーが新しい通話のセットアップ中に verstat パラメータを送信する場合は、CUBE を設定します。
-
ここで参照しているタグは、[ローカル ゲートウェイ設定ガイド ] に基づいて作成されています。
-
サービスプロバイダーが
verstatパラメータを送信していない場合でも、この構成を実行しても通話には影響しません。
voice class sip-copylist 200
sip-header From
sip-header P-Asserted-Identity
sip-header P-Attestation-Indicator
dial-peer voice 200
voice-class sip copy-list 200
voice class sip-profiles 100
rule 90 request INVITE peer-header sip P-Asserted-Identity copy "(;verstat=[A-Z|a-z|-]+)" u01
rule 91 request INVITE sip-header P-Asserted-Identity modify "@" "\u01@"
rule 92 request ANY peer-header sip From copy "(;verstat=[A-Z|a-z|-]+)" u02
rule 93 request ANY sip-header From modify "@" "\u02@"
rule 94 request INVITE peer-header sip P-Attestation-Indicator copy "(.*)" u03
rule 95 request INVITE sip-header P-Attestation-Indicator add "P-Attestation-Indicator: Dummy Header"
rule 96 request INVITE sip-header P-Attestation-Indicator modify "Dummy Header" "\u03"
rule 97 request INVITE sip-header P-Attestation-Indicator modify "P-Attestation-Indicator: $" "Remove: Me"
rule 98 request INVITE sip-header Remove removeサービスプロバイダーがサポートしていないPSTNからの通話の場合 STIR/SHAKEN:
PSTN プロバイダーが着信通話で verstat 情報を送信しない場合は、コントロール ハブの 未確認の発信者からの通話を通常の通話として表示する 設定の既定値を変更しないでください。設定が無効になっている場合、ユーザーのクライアントに スパムの可能性 という表示が表示されます。
Webex Calling 認定の発信者レピュテーション プロバイダー
Webex Calling は、Certified Calling Reputation Providers (CCRP) の統合により、安全なコラボレーションを強化し続けます。この統合により、新たな脅威からプロアクティブに保護されるため、期待どおりのシームレスなコミュニケーション エクスペリエンスを楽しむことができます。
この機能は、リアルタイムのレピュテーション インテリジェンスを使用して着信 PSTN 通話を動的に評価し、既知の脅威をブロックし、疑わしい発信者に CAPTCHA 検証を通じて挑戦し、信頼できる通話が中断なく接続できるようにすることで、自動的にアクションを実行します。このクラウド管理ソリューションは、認定プロバイダー Mutareを通じて北米 に本社を置く顧客に提供され、最小限の構成でスパムやフィッシング攻撃に対するエンタープライズ レベルの保護を提供します。つまり、チームは最も重要なことに集中できるということです。正当な発信者と有意義な会話をする。
機能ワークフロー
この機能の動作については、次の手順で説明します。
| 1 |
Cisco の CCRP である Mutareの評判サービスに登録します。詳細および Mutareの CCRP サービスへのサインアップについては、 Webex Calling 向け CCRPをご覧ください。お客様は、 Connect with Mutare を使用してサインアップする必要があります。Mutareのオンボーディング チームがサブスクリプション プロセスを案内し、アカウントが適切にプロビジョニングされるようにします。 |
| 2 |
サブスクリプションを完了すると、 Mutare が組織に固有の 会社 ID と 秘密キー をプロビジョニングします。これらの安全な資格情報により、Webex Calling 環境と Mutareの評判プラットフォームとの間に信頼できる接続が確立されます。これらの資格情報は、Control Hub で設定する必要があります。 |
| 3 |
組織のセキュリティ体制とビジネス ニーズに合わせてレピュテーションしきい値レベルを構成することで、通話処理ポリシーをカスタマイズします。詳細については、次の構成セクションを参照してください。 |
| 4 |
設定を保存すると、Webex Calling は組織の Webex 環境と Mutareの CCRP プラットフォーム内の専用テナントとの間に安全な接続を自動的に確立します。 |
| 5 |
着信 PSTN 通話が Webex Calling に到着します。 |
| 6 |
通話が宛先にルーティングされる前に、Webex Calling は SIP From ヘッダー (または必要な場合は P-Asserted-Identity) から発信者の番号を抽出します。 |
| 7 |
リアルタイムクエリは発信者の番号とともに Mutare に送信されます。 |
| 8 |
CCRP は、グローバル番号のデータベースに対する検証に基づいて評判スコアを返します。 |
| 9 |
Webex は設定されたポリシーを適用して通話を適切に処理します。 |
| 10 |
スコアと設定されたしきい値に基づいて、通話が接続、チャレンジ、またはブロックされます。 |
発信者レピュテーションプロバイダーを構成する
組織レベルで発信者レピュテーションプロバイダーとポリシー設定を構成するには、次の手順に従います。
| 1 |
Control Hub に サインインします。 |
| 2 |
を呼び出します。 |
| 3 |
設定 に移動し、 発信者評価サービスまで下にスクロールします。 |
| 4 |
トグルを有効にして、発信者レピュテーションプロバイダーとポリシー設定を構成します。
アカウントの有効期限が切れている場合は、発信者評価プロバイダーに問い合わせてください。ライセンスが復元されたら、 [再試行 オプションをクリックして、期限切れの状態に戻します。 |
通話フィルタリングの優先順位
CCRP と Webex Calling の統合により、Webex Calling の優先階層内で機能し、不要な通話からユーザーを保護する高度なスパム回避ソリューションが提供されます。これにより、正当な通話が確実に行われるようになります。
Webex Calling における通話フィルタリングの優先レベルは次のとおりです。
通話処理とレポート
|
治療の種類 |
Action/Outcome |
|---|---|
|
ブロック |
着信ユーザーには通話が提供されません。呼び出しは原因 603 で解放されます。通話は、着信側ユーザーの通話履歴に「ブロック」という処理で記録されます。 |
|
チャレンジ（CAPTCHA） |
発信者はチャレンジに合格するために 3 回試行できます。数字を入力する間に 15 秒のタイムアウトがあります。
|
|
許可 |
通話は、何の表示もなく、通常の通話としてユーザーに表示されます。 |
|
Mutareからの応答がない、または応答が遅い |
呼び出しは、以下の結果とともにユーザーに表示されます。 STIR/SHAKEN PSTN キャリアから入手できる場合は、証明書。 |
-
通話が潜在的なスパムとしてマークされた場合 STIR/SHAKEN 処理中であるが、Mutare の通話レピュテーション サービスから高いレピュテーション スコアを獲得するか、CAPTCHA テストに合格すると、Webex Calling ユーザーには通常の通話として表示されます。
-
通話が認証済み発信者としてマークされた場合 STIR/SHAKEN 処理中であるが、Mutare の通話レピュテーション サービスから低いレピュテーション スコアを取得したり、CAPTCHA テストに失敗したりすると、通話はブロックされます。
通話データとレポートを強化するために、レピュテーション サービスから情報を取得するための次のフィールドが通話詳細レコード (CDR) に追加されます。
- コールスコア
- 通話レピュテーションサービスの結果
- 発信者評判スコアの理由
これらのフィールドの詳細については、 Webex Calling の詳細な通話履歴レポートを参照してください。
グループ機能の発信者評判スコアリングプロセス
発信者レピュテーションスコアリングは、着信コールがシステムに初めて入ったときに、各着信コールに対して 1 回だけ実行されます。このプロセスは、ワークスペースや、自動応答、コール キュー、ハント グループなどのグループ機能を含む、すべての種類のエンドポイントを対象としています。グループ機能からの通話を受信する宛先の場合、グループまたは機能のエントリ ポイントで初期評価がすでに行われているため、追加の発信者レピュテーション チェックは実行されません。着信番号がグループ機能に割り当てられているレピュテーション チェックに失敗した通話の場合、通話履歴エントリは作成されません。
コールバック ヘッダーを含む緊急番号からのコールバック通話は、レピュテーション プロバイダーによるスクリーニングを受けません。
サポートとサービスのパートナーシップ
Cisco と Mutare は、発信者レピュテーション サービスの統合に関して顧客が迅速かつ専門的なサポートを受けられるように、サポート パートナーシップを確立しました。Webex Calling インフラストラクチャ、通話ルーティング、または Control Hub 構成に関連する問題については、お客様は標準のサポート チャネルを通じて Cisco Technical Assistance Center (TAC) に連絡する必要があります。レピュテーション スコアの計算、プロバイダー ポータルへのアクセス、アカウントのプロビジョニング、請求に関する質問など、CCRP サービスに固有の事項については、お客様は Mutare の専用サポート チームに直接問い合わせる必要があります。
このサポート構造により、各問い合わせは、最も効果的かつ効率的な解決策を提供できる適切なチームに確実に届きます。
制限
ユーザーは、誤検知を特定するために、通話履歴内のブロックされた通話リストを定期的に確認する必要があります。誤ってブロックリストに番号が表示された場合、特にブロックすべきでない不在着信の場合、ユーザーは管理者に連絡してそれらの番号のブロックを解除する必要があります。
