このセクションでは、ハイブリッドサービスに関連する主要な設定項目に関する追加のコンテキストを提供します。

これらのポイントは、Webexデバイスにハイブリッド通話を正常に導入するうえで重要です。 これらの項目を特に強調したのは、 次の理由からです。

• ハイブリッド展開における彼らの役割を理解し、安心できるように、説明したいと思います。

• これらは、クラウドとお客様のオンプレミス環境間の安全な導入を保証するための必須の前提条件です。

• これらは前日のゼロアクティビティとして扱うべきです。ユーザーインターフェースでの通常の設定よりも完了までに少し時間がかかることがあるので、これらの項目を整理するには時間的余裕を持ってください。

• これらの項目がお客様の環境で処理されれば、ハイブリッドサービスの残りの構成はスムーズに進みます。

Expressway-CとExpressway-Eのペア配置では、ファイアウォールトラバーサル技術を使用してインターネットとの間の通話が可能になります。 この導入により、 オンプレミスの通話制御が安全に行われ、 Webexに結び付けられます。

Expressway-CとExpressway-Eでは、ファイアウォールトラバーサルアーキテクチャのため、非武装地帯（DMZ） ファイアウォールでインバウンドポートを開く必要はありません。 ただし、着信を受け付けるには、TCP SIP信号ポートとUDPメディアポートをインターネットファイアウォールで着信時に開く必要があります。 企業のファイアウォールで適切なポートを開くには、 時間をとる必要があります。

ファイアウォールトラバーサルアーキテクチャを次の図に示します。

たとえば、 SIPプロトコルを使用した企業間（B2B）のインバウンド通話では、音声、ビデオ、コンテンツ共有、 デュアルビデオなどのサービスに使用されるUDPメディアポートとともに、TCPポート5060と5061（5061はSIP TLSに使用） を外部のファイアウォールで開く必要があります。 どのメディアポートを開くかは、 同時通話の数とサービスの数によって異なります。

エクスプレスウェイのSIPリスニングポートは、 1024から65534までの任意の値に設定できます。 同時に、 DNS SRVこの値とプロトコルの種類を公の記録に公開し、 同じ値をインターネットファイアウォールで公開する必要があります。

SIP TCPの標準は5060で、SIP TLSの標準は5061ですが、 次の例に示すように、 異なるポートの使用を妨げるものは何もありません。

例

この例では、SIP TLSの着信にポート5062が使用されていると仮定しています。

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

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

priority = 10

weight = 10

port = 5062

svr ホスト名 = us-expe1.example.com

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

priority = 10

weight = 10

port = 5062

svr ホスト名 = us-expe2.example.com

これらの記録は、トランスポートタイプとしてTLS、リスニングポート番号として5062を使用して、 コールがus-expe1.example.comとus-expe2.example.comに同等のロードシェアリング（優先度と重み）で転送されることを意味します。

ネットワークの外部（インターネット上）にあり、 企業ドメインのユーザー（user1@example.com） にSIP通話を行うデバイスは、DNSに問い合わせて、使用するトランスポートタイプ、 ポート番号、トラフィックの負荷分担方法、 および呼び出しを送信するSIPサーバーを把握する必要があります。

DNSエントリに_sipsが含まれている場合。_tcp、エントリはSIP TLSを指定しています。

TLSはクライアント/サーバープロトコルで、 最も一般的な実装では認証に証明書を使用します。 企業間通話のシナリオでは、TLSクライアントは発信側のデバイスで、 TLSサーバーは着信側のデバイスです。 TLSでは、 クライアントはサーバーの証明書をチェックし、証明書の確認に失敗すると通話を切断します 。 クライアントは証明書を必要としません。

TLSハンドシェイクは次の図に示されています。

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

次の図に示すように、 発信側と着信側の両方が相手側のピアの証明書をチェックします。

クラウドはExpresswayのアイデンティティをチェックし、 Expresswayはクラウドのアイデンティティをチェックします。 たとえば、証明書（CNまたはSAN） のクラウドIDがExpresswayに設定されているものと一致しない場合、 接続は切断されます。

相互認証がオンになっている場合、 Expressway-Eは常にクライアント証明書を要求します。 その結果、 ほとんどの場合、 証明書がJabberクライアントに展開されないため、 モバイルとRemote Access（MRA）は機能しません。 企業間取引では、 発信側企業が証明書を提供できない場合、 通話は切断されます。

相互認証のTLSには、ポート5062など、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ペアでの企業間トラフィックRemote Access、モバイルトラフィック、Webexトラフィック

企業間（B2B）とモバイル、Remote Access（MRA） の通話はSIP TLSにポート5061を使用し、Webexトラフィックは相互認証のあるSIP TLSにポート5062を使用します。

ドメイン所有権の確認は、本人確認の一部です。 ドメイン認証は、あなたが言うとおりの人物であることを証明するためにWebexクラウドが実装するセキュリティ対策と本人確認です。

本人確認は2段階で行われます。

1. ドメイン所有権のチェック。 このステップには3種類のドメインが含まれ、1回限りの検証です。

   • メールドメイン

   • エクスプレスウェイ-E DNSドメイン

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

2. Expressway-E DNS名の所有権チェックです。 このステップは、相互認証を備えたTLSの実装を通じて実行され、クラウドとExpresswayの両方で公開証明書を使用する必要があります。 ドメインのIDチェックとは異なり、このステップはクラウドとの間で送受信されるすべての通話中に実行されます。

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

Webex クラウドは、セキュリティを強化するためにドメイン所有権のチェックを行います。 このチェックを行わないと、個人情報の盗難が脅威となる可能性があります。

次の記事では、ドメインの所有権の確認を行わないとどうなるかを詳しく説明します。

DNSドメインが「hacker.com」に設定されている会社が、Webex ハイブリッドサービスを購入します。 独自のドメインを「example.com」に設定している別の会社も、 ハイブリッドサービスを使用しています。 Example.comという会社のゼネラルマネージャーの一人はジェーン・ローという名前で、 ディレクトリURIは jane.roe@example.com です。

Hacker.com社の管理者は、ディレクトリURIの1つを jane.roe@example.com に、電子メールアドレスを jane.roe@hacker.com に設定します。 この例ではクラウドがSIP URIドメインをチェックしないので、彼女はそれができます。

次に、彼女は jane.roe@hacker.com で Webex アプリにサインインします。 彼女はドメインを所有しているので、 確認メールを読んで返信し、サインインすることができます。 最後に、彼女は自分のWebexアプリから john.doe@example.com にダイヤルして、同僚のJohn Doeに電話をかけます。 ジョンはオフィスに座っていて、ビデオデバイスに jane.roe@example.com からの電話がかかってくるのを見ています。これは、そのメールアカウントに関連付けられているディレクトリURIです。

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

Example.com社には、インターネットからの不正通話を防ぐためのさまざまな方法がありますが、Webexクラウドの責任の1つは、Webexから電話をかけてきた人の身元が正しく、改ざんされていないことを確認することです。

身元を確認するために、Webexは会社がハイブリッド通話で使用されるドメインを所有していることを証明することを要求します。 そうでなければ、ハイブリッドサービスは機能しません。

この所有権を確保するには、次の2つのドメイン認証手順が必要です。

1. 会社がメールドメイン、Expressway-Eドメイン、ディレクトリURIドメインを所有していることを証明してください。

   • これらのドメインはすべてルーティング可能で、パブリックDNSサーバーで認識されている必要があります。

   • 所有権を証明するには、DNS管理者はDNSテキストレコード（TXT）を入力する必要があります。 TXTレコードは、任意のフォーマットされていないテキストをホストまたは他の名前に関連付けるために使用されるDNSのリソースレコードの一種です。

   • DNS管理者は、所有権を証明する必要があるゾーンにそのTXTレコードを入力する必要があります。 そのステップの後、Webex クラウドはそのドメインの TXT レコードクエリを実行します。

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

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

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

     

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

     

   • この時点で、クラウドはexample.comドメインのTXTレコードがトークンと一致することを確認できます。

   • クラウドは TXT DNS ルックアップを実行します。

     

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

2. エクスプレスウェイ-E DNS名の所有権チェックです。

   • クラウドは、Expressway-Eに、クラウドが信頼する認証局の1つからの確認済みのIDがあることを確認する必要があります。 Expressway-Eの管理者は、それらの認証機関のいずれかにExpressway-Eの公開証明書を要求する必要があります。 証明書を発行するために、認証局はドメイン検証チェック（ドメイン検証証明書の場合）または組織検証チェック（組織検証証明書の場合）に基づいて本人確認プロセスを実行します。

   • クラウドへの通話とクラウドからの通話は、Expressway-Eに発行された証明書によって異なります。 証明書が有効でない場合、電話は切断されます。

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

Webex Device Connectorは内部ネットワークに導入されており、 クラウドと通信する方法はアウトバウンドのHTTPS接続です。これは、 Webサーバーに接続するブラウザで使用されるものと同じタイプです。

Webex クラウドへの通信には TLS を使用します。 Webex デバイスコネクタは TLS クライアントで、Webex クラウドは TLS サーバーです。 そのため、Webex デバイスコネクタはサーバー証明書をチェックします。

認証局は、独自の秘密鍵を使用してサーバー証明書に署名します。 公開鍵を持っている人なら誰でもその署名を解読して、 同じ認証局がその証明書に署名したことを証明できます。

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であることを直接証明します。

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

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

セキュリティを強化するには、Cisco Webexハイブリッドカレンダーサービスの導入ガイドの手順に従ってTLSを有効にし、有線でのEWS接続を保護してください。

セキュリティを強化するには、「Expressway Calendar Connectorの導入」Microsoft Exchange の手順に従ってTLSを有効にして、有線でのEWS接続を保護してください。