このセクションでは、 ハイブリッド サービスに関連する重要な構成項目に関して追加されたコンテキストについて説明します。

これらの点は、Webexデバイスでハイブリッド通話を正常に展開するために非常に重要です。特に、以下の理由によりこれらの項目をハイライトしました。

• これからこれらの項目について説明します。ハイブリッドの展開におけるこれらの項目の役割を十分に理解して、展開に自信を持ってください。

• これらは 弊社のクラウドおよび貴社のオンプレミス環境間で安全に展開するための必須条件です。

• これらは、導入前の措置として考えてください。ユーザー インターフェイスの典型的な構成少し長い時間がかかるため、項目を整理するために時間を確保してください。

• お客様の環境でこれらの項目への対応が完了すれば、 の残りのハイブリッド サービス構成作業はスムーズに進めることができるようになります。

Expressway-C と Expressway-E のペア展開により ファイアウォール通過技術を使用してインターネットとの間の通話が可能になります。この導入により、オンプレミスの通話制御システムを安全に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 サービスの場所:

優先順位 = 10

ウェート = 10

ポート = 5062

svr hostname = us-expe1.example.com

_sips._tcp.example.com SRV サービスの場所:

優先順位 = 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とWebexクラウド間で確立された通話など、サーバー間接続において役立ちます。この概念は相互認証付きTLSと呼ばれ、Webexとの連携時に必要となります。

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

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

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

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

既存のレコードが既に企業間通信に使用されている場合は、Control HubでSIP宛先として企業ドメインのサブドメインを指定し、それに伴い、以下のようにパブリックDNS SRVレコードを指定することをお勧めします。

 Service and protocol: _sips._tcp.mtls.example.com 
Priority: 1 
Weight: 10 
Port number: 5062 
Target: us-expe1.example.com 

同一のExpresswayペア上で、企業間取引、モバイルおよびリモートアクセス、Webexトラフィックを処理

企業間通信（B2B）およびモバイル・リモートアクセス（MRA）通話では、SIP TLSにポート5061が使用され、Webexトラフィックでは、相互認証付きのSIP TLSにポート5062が使用されます。

ドメイン所有権の確認は ID 認証の一部です。ドメイン認証は、Webexクラウドが実装するセキュリティ対策および本人確認であり、ユーザーが名乗っている人物であることを証明するために行われます。

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

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

   • メールドメイン

   • Expressway-E DNS ドメイン

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

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

ドメイン所有権チェックの重要性

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

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

DNSドメインを「hacker.com」に設定した企業が、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 ドメインを確認しないため、そのようなことができてしまいます。

次に、彼女はWebexアプリにサインインします。 jane.roe@hacker.com. 彼女はこのドメインを所有しているため、確認メールは読まれて返答され、またサイン インもできます。最後に、彼女は同僚のジョン・ドウに電話をかける。 john.doe@example.com 彼女のWebexアプリから。John は自分のオフィスに腰掛けて、自分のビデオデバイスにメールアカウントに関連付けられたディレクトリ　URI　である jane.roe@example.com; からかかってきた通話を見ます。

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

Example.com社は、インターネットからの不正な電話から保護するための多くの方法を用意していますが、Webexクラウドの役割の一つは、Webexから電話をかけてくる人の身元が正しく、偽造されていないことを確認することです。

本人確認のため、Webexは企業がハイブリッド通話で使用されるドメインを所有していることを証明することを求めている。そうでない場合、ハイブリッドサービスは機能しません。

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

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

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

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

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

   • TXTクエリが成功し、その結果がWebexクラウドから生成されたトークンと一致する場合、ドメインは検証済みとなります。

   • 例えば、管理者が自分のドメインでWebexハイブリッドサービスを利用したい場合、ドメイン「example.com」の所有権を証明しなければなりません。

   • 彼女は https://admin.webex.comを通じて、Webexクラウドが生成したトークンに一致するTXTレコードを作成することで、検証プロセスを開始します。

     

   • 次に、DNS管理者は、次の例のように、このドメインのTXTレコードを作成し、値を 123456789abcdef123456789abcdef123456789abcdef123456789abcdefに設定します。

     

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

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

     

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

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

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

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

ハイブリッド通話を機能させるには、WebexデバイスコネクタがWebexと通信する必要があります。

Webex Device Connectorは内部ネットワークに展開され、クラウドとの通信方法は、Webサーバーに接続するあらゆるブラウザで使用されるのと同じタイプの、アウトバウンドHTTPS接続を介して行われます。

Webexクラウドとの通信にはTLSが使用されます。Webex Device ConnectorはTLSクライアントであり、WebexクラウドはTLSサーバーです。そのため、Webex Device Connectorはサーバー証明書を確認します。

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

Webex Device Connectorがクラウドから提供された証明書を検証する必要がある場合、その証明書に署名した認証局の公開鍵を使用して署名を復号する必要があります。パブリックキーは、証明機関の証明書に記載されています。クラウドで使用される認証局との信頼関係を確立するには、これらの信頼できる認証局の証明書のリストがWebex Device Connectorの信頼ストアに存在する必要があります。

このツールは、デバイスとの通信時に、ユーザーが提供する信頼できる証明書を使用します。現在、それを行う方法は、それらを [home folder]/.devicestool/certsで囲むことです。

証明機関の証明書リストも、トラバーサルペアの Expressway-E に必要です。Expressway-Eは、相互認証によって強制されるTLSを使用したSIPを用いてWebexクラウドと通信します。Expressway-E は、TLS 接続設定中にクラウドから提示される証明書の CN または SAN が、Expressway の DNS ゾーン ("callservice.webex.com") に設定されているサブジェクト名と一致する場合にのみ、クラウドとの間で送受信される通話を信頼します。証明機関は身元確認の後にのみ証明書をリリースします。証明書に署名してもらうには、callservice.webex.comドメインの所有権を証明する必要があります。弊社（シスコ）がそのドメインを所有しているため、DNS名「callservice.webex.com」は、リモートピアが真にWebexであることの直接的な証拠となります。

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

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

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

セキュリティの強化については、「 Microsoft Exchange 用の Expressway Calendar Connector を展開する」の手順に従い、ワイヤーで安全な EWS 接続を確保するために TLS を有効にしてください。