Expressway-C および Expressway-E のペア展開により、ファイアウォール トラバーサル テクノロジーを使用してインターネットと通話を行うことができます。 この展開では、オンプレミスの通話制御をセキュアに取り扱って、Cisco Webex に統合します。

Expressway-C と Expressway-E は、非武装地帯 (DMZ) ファイアウォールのインバウンド ポートを開いておくことを要件としていません。DMZ ファイアウォールがトラバーサル アーキテクチャを持っているからです。 しかし、インターネット ファイアウォールでは、着信通話を通過させるために、TCP SIP シグナリング ポートと UDP メディア ポートはインバウンドに開いておく必要があります。 エンタープライズ ファイアウォール上で適切なポートが開く時間を確保してください。

ファイアウォール トラバーサル アーキテクチャ は、以下のダイアグラムに示されています。

たとえば、SIP プロトコル、TCP ポート 5060 おょび 5061 (5061 は SIP TLS に使用されます) を使用したインバウンド Business-to-Business (B2B) 通話は、音声、ビデオ、コンテンツ共有、デュアルビデオなどのサービスに使用される UDP メディアポートと共に外部ファイアウォール上に開く必要があります。 どのメディア ポートを開いておくかは、同時通話の数とサービスの数に依存します。

SIP リスニングポートは、1024 ～ 65534 の間の値を Expressway 上で設定できます。 同時に、この値およびプロトコル種類はパブリック DNS SRV レコード内に提供される必要があり、同じ値がインターネットファイアウォール上に開く必要があります。

SIP TCP の標準は 5060 および SIP TLS の標準は 5061 ですが、以下に例を示すように別のポートの使用を妨げるものではありません。

例

この例では、5062 ポートがインバウンド SIP TLS 通話に使用されていると考えます。

2 つの Expressway サーバーのクラスターの DNS SRV レコードは以下のようになります。

_sips._tcp.example.com SRV service location:

優先順位 = 10

ウェート = 10

ポート = 5062

svr hostname = us-expe1.example.com

_sips._tcp.example.com SRV service location:

優先順位 = 10

ウェート = 10

ポート = 5062

svr hostname = us-expe2.example.com

これらのレコードは、トランスポート タイプとして TLS を使用し、リスニング ポート番号として 5062 を使用する均等負荷共有機能 (優先順位と重み) を用いて、架電が us-expe1.example.com と us-expe2.example.com に、振り向けられることを意味しています。

ネットワークの外部 (インターネット上) からコーポレート ドメイン (user1@example.com) 内のユーザーに SIP 架電を行うデバイスは、使用するトランスポート タイプ、ポート番号、トラフィックの負荷共有方法、架電の転送先となる SIP サーバーを知るために、DNS に対してクエリを発行する必要があります。

DNS 入力に _sips._tcp が含まれる場合は、その入力は SIP TLS を指定します。

TLS は クライアント・サーバープロトコルであり、最も一般的な実施では証明書を認証に使用します。 B2B 通話シナリオでは、TLS クライアントが発信デバイスであり、TLS サーバーはデバイスと呼ばれます。 TLS では、クライアントはサーバーの証明書を確認し、証明書の確認に失敗した場合は通話を切断します。 クライアントには証明書は不要です。

TLS ハンドシェイクは以下のダイヤグラムに表示されます。

しかし、TLS 仕様書は、サーバーも TLS ハンドシェイク プロトコル中に証明書要請メッセージをクライアントに送信して、クライアントの証明書を確認することができると記載しています。 このメッセージは、Expressway-E および Cisco Webex クラウド間に確立された通話といったサーバー間接続に役立ちます。 このコンセプトは相互認証付き TLS と呼ばれ、Cisco Webex に統合する際に必要となります。

発信者および受信者の双方は、以下のダイヤグラムに示すように他のピアの証明書を確認します。

クラウドは Expressway ID を確認し、Expressway はクラウド ID を確認します。 たとえば、証明書 (CN ないしは SAN) のクラウド ID が Expressway で設定したものと一致しない場合、接続は落ちます。

相互認証がオンになると、Expressway-E は常時クライアント証明書を要請します。 結果として、ほとんどの場合、証明書が Jabber クライアント上で展開しないためモバイルおよび リモートアクセス (MRA) が動作しなくなります。 B2B シナリオでは、発信者が証明書を提供できない場合に通話が切断されます。

5062 ポートなどの相互認証付き TLS では、5061 以外の値を使用することを推奨します。 Cisco Webex ハイブリッド サービスは、B2B に使用されたものと同じ SIP TLS レコードを使用します。 5061 ポートの場合は、TLS クライアント証明書を提供できない他のサービスは動作しません。

同じ Expressway ペア上の Business-to-business、Mobile and Remote Access、および Cisco Webex トラフィック

Business-to-business と Mobile and Remote Access 通話は、ポート 5061 を SIP TLS で使用し、Cisco Webex トラフィックは、ポート 5062 を相互認証付きの SIP TLS で使用します。

ドメイン所有権の確認は ID 認証の一部です。 ドメイン検証はセキュリティ対策および Cisco Webex クラウドがあなたを名乗る人物があなたであることを証明するために行う身元確認です。

この身元確認は 2 ステップで行なわれます。

1. ドメインの所有権確認 このステップは、3 種類のドメインが含まれる、ワンタイム検証チェックです。

   • メールドメイン

   • Expressway-E DNS ドメイン

   • ディレクトリ URI ドメイン

2. Expressway-E DNS 名称の所有権確認 このステップでは、相互認証付き TLS の実施を通じて行われ、クラウドおよび Expressway の両方におけるパブリック証明書の使用が実施されます。 ドメインの身元確認とは異なり、このステップはクラウドとの間で行う通話中に実施されます。

ドメイン所有権チェックの重要性を示すストーリー

Cisco Webex クラウドはセキュリティ確保のため、ドメインの所有権確認を行います。 ID の盗難はこのチェックが行われない場合に起こりうる盗難の例です。

以下のストーリーは、ドメインの所有権確認が行われない場合に発生し得る事態を詳しく説明しています。

DNS ドメインに「hacker.com」を設定している会社が Cisco Webex ハイブリッド サービスを購入します。 独自のドメインに「example.com」を設定している別の会社も、ハイブリッド サービスを利用しています。 Example.com 社の部長に Jane Roe という名前の人物がおり、そのディレクトリ URI は jane.roe@example.com です。

Hacker.com 社の管理者は、自分のディレクトリ URI の 1 つを jane.roe@example.com に設定し、メール アドレスを jane.roe@hacker.com としました。 この例では、管理者はクラウドが SIP URI ドメインを確認しないため、そのようなことができてしまいます。

次に、管理者は jane.roe@hacker.com で Cisco Webex Teams に署名します。 彼女はこのドメインを所有しているため、確認メールは読まれて返答され、またサイン インもできます。 最終的に彼女は、彼女の Cisco Webex Teams アプリから john.doe@example.com にダイヤルして、同僚のジョン・ドウに電話をします。ジョンは彼のオフィスに座っており、自分のビデオ デバイスに、電子メール アカウントに関連付けられたディレクトリ URI である jane.roe@example.com からの着信があることに気付きます。

彼は「彼女は海外にいる」と思い出します。 「彼女は何か非常に重要なことを必要としているのかも知れない」 彼が電話に応答すると、偽のジェーン・ロウが重要な書類を要求します。 彼女は、自分のデバイスが故障したと説明し、旅行中のためその書類を自分のプライベートのメール アドレスである jane.roe@hacker.com に送るように依頼します。 このように、会社は Jane Roe がオフィスに戻った後でしか、重要情報が社外に漏れたと気づくことができません。

Example.com 社はインターネット経由でかかってくる詐欺的な電話の防御を多数講じていましたが、Cisco Webex クラウドの責任の 1 つは、Cisco Webex から発信する全員の身元が正しく、かつ偽装されたものでないことを確認することです。

身元を確認するため Cisco Webex は会社に、ハイブリッド通話で使用するドメインを所有していることを証明するように義務付けています。 証明しない場合、 は動作しません。

所有権確認のため、2 段階のドメイン検証が義務付けられています。

1. 会社がそのメールドメイン、Expressway-E ドメイン、Directory URI ドメインを所有していることを証明します。

   • これらすべてのドメインはアクセスが可能かつパブリック DNS サーバー に把握されている必要があります。

   • 所有権を証明するには、DNS 管理者は DNS テキストレコード (TXT) を入力する必要があります。 TXT レコードは DNS のリソースレコードの一種であり、ホストまたは他の名前を持つ任意および不定様式のテキストに関連付けられる能力を提供するために使用されます。

   • DNS 管理者は、所有権が証明される必要のある領域に TXT レコードを入力する必要があります。 この手順の後、Cisco Webex クラウドは TXT レコード クエリーをそのドメインのために実行します。

   • TXT クエリーは成功率が高く、結果はドメインが検証された Cisco Webex クラウドから生成されたトークンと一致します。

   • たとえば、管理者が および Cisco Webex ハイブリッド サービスを自分のドメインで動作させる場合、彼女は自分がドメイン「example.com」を所有していることを証明する必要があります。

   • 管理者は https://admin.webex.com を通して、TXT レコードを作成して検証プロセスを開始し、Cisco Webex クラウドが生成したトークンと照合します。

     

   • DNS 管理者は、以下の例にあるように 123456789abcdef123456789abcdef123456789abcdef123456789abcdef にセットする値でこのドメイン用に TXT レコードを作成します。

     

   • ここでは、クラウドは example.com の TXT レコード がトークンと一致することを検証します。

   • クラウドは TXT DNS 検索を実行します。

     

   • TXT の値がトークンの値と一致しているため、この一致は管理者が自身のドメイン用に TXT レコードをパブリック DNS に追加し、自身がそのドメインを所有していることを証明します。

2. Expressway-E DNS 名称の所有権確認

   • Expressway-E はクラウドが信頼している認証局のいずれかから確認された ID を持っていることクラウドがチェックする必要があります。 Expressway-E の管理者は、自らの Expressway-E の公開証明書をこれらの認証局のいずれかに要請する必要があります。 証明書を発行するには、証明機関はドメイン検証確認 (ドメイン検証証明書) ないしは組織検証確認 (組織検証証明書) に基づいた身元確認プロセスを実行します。

   • クラウドとの通話は、Expressway-E に発行された証明書 に依存します。 証明書が有効でない場合、通話は落ちます。

Cisco Webexハイブリッド サービス が機能するには、Expressway-C コネクタ ホストが に登録されている必要があります。

Expressway-C は、社内ネットワーク内に展開されると、それがクラウドに登録する方法はアウトバウンド HTTPS 接続を経由する方法になります。これはブラウザがウェブ サーバーに接続するために使用する方法と同じです。

Cisco Webex クラウドへの登録および通信では TLS を使用します。 Expressway-Cは TLS クライアントであり、Cisco Webex クラウドは TLS サーバーです。 そのため、Expressway-C はサーバー証明書を確認します。

証明機関は独自のプライベートキーを使用してサーバー証明書に署名します。 パブリックキーを所持している者は、誰であれその署名をデコードし、同じ証明機関がその証明書に署名したことを証明できます。

Expressway-C はクラウドが提供した証明書を検証する必要がある場合、署名をデコードするためにその証明書に署名した証明機関のパブリック キーを使用する必要があります。 パブリックキーは、証明機関の証明書に記載されています。 クラウドが使用した証明機関との信頼を確立するために、これらの信頼された証明機関の証明書リストは Expressway の信頼ストアにある必要があります。 そうであれば Expressway はその発信が Cisco Webex クラウドから本当になされたものであるかを確認できます。

手動アップロードにより、すべての関連する証明機関の証明書を Expressway-C の信頼ストアにアップロードできます。

自動アップロードにより、Expressway-C の信頼ストアにある証明書をクラウド自身がアップロードします。 自動アップロードを使用することを推奨します。 証明書リストは変更されることがありますが、自動アップロードは最新のアップデートされたリストを入手することを保証します。

認証局の証明書の自動インストールを有効にすると、https://admin.webex.com (管理ポータル) にリダイレクトされます。 リダイレクトは、ユーザーの介入無しに Expressway-C 自身によって行われます。 Cisco Webex 管理者として、HTTPS 接続を通じて認証する必要があります。 その後すぐに、クラウド CA 証明書を Expressway-C にプッシュします。

証明書が Expressway-C の信頼ストアにアップロードされるまで、HTTPS 接続を確立できません.

この問題を回避するには、Expressway-C に Cisco Webex が信頼する CA 証明書をプリインストールします。 この証明書は初回の HTTPS 接続のセットアップおよび検証のみに使用され、Expressway-C 信頼リストには記載されません。 信頼された証明機関の証明書がこの初回の HTTPS 接続を通じてクラウドから引かれると、その証明書はプラットフォーム全体に使用できるようになり、Expressway-C の信頼リストに記載されます。

このリストには、Cisco Webex クラウドが現在使用している証明機関の証明書が記載されています。 このリストは将来変更される可能性があります。

• C=IE, O=Baltimore, OU=CyberTrust, CN=Baltimore CyberTrust Root

• C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root

• C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certificate Authority

• C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2

• C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2

• C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA

• C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certificate Authority

証明機関の証明書リストも、トラバーサルペアの Expressway-E に必要です。 Expressway-E は相互認証によって強制されるため、TLS と共に SIP を使用して Cisco Webex と通信します。 Expressway-E がクラウドとの間で発着信する通話を信頼するのは、TLS 接続のセットアップ時にクラウドによって示された証明書の CN または SAN が、Expressway の DNS ゾーンに構成されているサブジェクト名 (「callservice.webex.com」) と一致する場合のみです。 証明機関は身元確認の後にのみ証明書をリリースします。 callservice.webex.com ドメインの所有権は、証明書の署名を得るために証明される必要があります。 当社 (Cisco) はそのドメインを所有しているので、DNS 名「callservice.webex.com」はリモートピアが真に Cisco Webex であることの直接の証明となります。

Calendar ConnectorCisco Webex を Microsoft Exchange 2010、2013、2016、または Office 365 に偽装アカウントを通じて統合します。 Exchange のアプリケーション偽装管理ロールは、組織のユーザーを偽装するためにアプリケーションを有効化し、ユーザーに代わってタスクを実行します。 アプリケーション偽装ロールは Exchange 内に設定される必要があり、Calendar Connector インターフェイス上の Exchange 構成の一部として Expressway-C に使用されます。

Exchange の偽装アカウントは、このタスクで Microsoft によって推奨された方法です。Expressway-C の管理者はパスワードを知る必要がありません。これは、Exchange 管理者によって値は Expressway-C インターフェイスに入力されるためです。 Expressway-C 管理者が Expressway-C ボックスにルートアクセスを持っている場合においても、パスワードは明確に表示されません。 パスワードは Expressway-C の他のパスワードと同じく、同じ証明書暗号化メカニズムを使用して暗号化され保存されます。

セキュリティの強化については、「Cisco Webex ハイブリッド カレンダー サービスの展開ガイド」の手順に従い、ワイヤーで安全な EWS 接続を確保するため TLS を有効にします。