ハイブリッド サービスの展開のための重要な項目

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

これらのポイントは、Webex デバイスのハイブリッド コールを正常に導入する場合に重要です。特に、以下の理由によりこれらの項目をハイライトしました。

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

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

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

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

インターネット ファイアウォール上の TCP ポート 5062

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 レコードを指定することをお勧めします。

 サービスとプロトコル: _sips._tcp.mtls.example.com 優先順位: 1 重み: 10 ポート番号: 5062 ターゲット: us-expe1.example.com

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

Business-to-business (B2B) および Mobile and Remote Access (MRA) コールは、ポート 5061 を SIP TLS に使用し、Webex トラフィックはポート 5062 を相互認証付きの SIP TLS に使用します。

クラウドがドメインの所有権を確認する理由

ドメイン所有権の確認は ID 認証の一部です。ドメイン検証は、Webex クラウドが実装するセキュリティ対策と ID チェックで、自分が何者なのかを証明するものです。

この身元確認は 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 ドメインを確認しないため、そのようなことができてしまいます。

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

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

Example.com 社はインターネットからの詐欺的な電話から保護する多くの方法がありますが、Webex クラウドの責任の 1 つは、Webex から発信するユーザーの身元が正しく、偽装されたものではないことを確認することです。

ID を確認するために、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 管理者は、次の例のように、値を 123456789abcdef123456789abcdef123456789abcdef123456789abcdef に設定して、このドメインの TXT レコードを作成します。

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

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

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

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

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

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

サポートされている認証局

ハイブリッド コールが機能するためには、Webex デバイス コネクタが Webex と通信する必要があります。

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

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 ドメインの所有権は、証明書に署名するために証明される必要があります。当社 (Cisco) はそのドメインを所有しているため、DNS 名「callservice.webex.com」はリモート ピアが本当に Webex であることを直接証明します。

関連情報
Exchange 偽装アカウント

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 を有効にしてください。