Cisco Spark ハイブリッドサービスを展開する前に準備する 5 つの重要事項

Document created by Cisco Localization Team on Feb 4, 2017
Version 1Show Document
  • View in full screen mode
 

Cisco Spark ハイブリッドサービスの展開にこの 5 項目が重要な理由

 

このドキュメントには、Cisco Spark ハイブリッドサービス に関する 5 つの主な構成項目についての追加内容が記載されています。

  

Expressway がホストする Cisco Spark ハイブリッドサービス (通話サービス認識/コネクトおよびカレンダーサービス) の展開を成功させたいのであれば、この 5 項目は非常に重要です。 特に、以下の理由により 5 項目をハイライトしました。

  
  •  

    5 項目を説明しますので、ハイブリッド展開にそれらが果たす役割について理解していただき、改めて自信を持っていただきたいと思います。

      

  •  

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

      

  •  

    この 5 項目は、導入前の措置として考えてください。 ユーザーインターフェースの典型的な構成よりも少しラインアップに時間がかかりますので、項目を整理するために時間を確保してください。

      

  •  

    お使いの環境でこれらの項目に対処すると、残りの Cisco Spark ハイブリッドサービス構成がスムーズになります。

      

  

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

 

Expressway-C および Expressway-E のペア展開により、ファイヤーウォール トラバーサル テクノロジーを使用してインターネットと通話を行うことができます。 この展開は、セキュリティを Cisco Collaboration Cloud を通じた Cisco Spark でのオンプレミス通話コントロール に結びつけるものです。

Expressway-C および Expressway-E は、ファイヤーウォール トラバーサル アーキテクチャのため非武装地帯 (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 入力に _sips._tcp が含まれる場合は、その入力は SIP TLS を指定します。

 

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

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


 

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

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


 

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

 

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

 

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

     

B2B、モバイル、リモートアクセス、および同一 Expressway ペア上の Spark トラフィック

B2B およびリモートアクセス通話は 5061 ポートを SIP TLS に使用し、 Cisco Spark トラフィックは 5062 ポートを相互認証付き SIP TLS に使用します。

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

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

 

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

  1. ドメインの所有権確認 3 種類のドメイン検証を含むこのステップは、以下のワンタイム検証を行います。

     

    • メールドメイン

       

    • Expressway-E DNS ドメイン

       

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

       

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

     

       

ドメインの所有権確認の重要性を示すストーリー

Cisco Collaboration Cloud はセキュリティ確保のため、ドメインの所有権確認を行います。 なりすましは、この確認が行われない際に発生しうる盗難です。

 

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

 

「;hacker.com」; に設定された DNS ドメインを持つ会社が Cisco Spark ハイブリッドサービスを購入します。 独自のドメインが「;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 Spark に署名します。 彼女はこのドメインを所有しているため、確認メールは読まれて返答され、またサインインもできます。 最後に、彼女は自分の Cisco Spark クライアントから john.doe@example.com にダイヤルして同僚の John Doe に電話をかけます。 John は自分のオフィスに腰掛けて、自分のビデオデバイスにメールアカウントに関連付けられたディレクトリ URI である jane.roe@example.com; からかかってきた通話を見ます。

 

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

 

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

 

身元を確認するために、Cisco Spark は Spark ハイブリッド通話で使用されるドメインを証明するよう会社に義務付けています。 そうしない場合、Cisco Spark ハイブリッドサービスは動作しません。

 

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

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

      

    •  

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

        

    •  

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

        

    •  

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

        

    •  

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

        

    •  

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

        

    •  
      管理者は、管理ポータルサイトを通じて TXT レコードを作成して Cisco Collaboration Cloud が生成したトークンと一致させるため、確認プロセスを開始します。


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


        
    •  

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

        

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


        
    •  

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

        

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

      

    •  

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

        

    •  

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

        

    

対象となる証明機関

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

 

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

 

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

 

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

 

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

 

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

 

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

 

証明機関の証明書の自動インストールを許可する場合は、Cisco Cloud Collaboration Management (管理ポータルサイト) にリダイレクトされます。 リダイレクトは、ユーザーの介入無しに Expressway-C 自身によって行われます。 Cisco Spark 管理者として、あなたは HTTPS 接続を通じて認証する必要があります。 その後すぐに、クラウド CA 証明書を Expressway-C にプッシュします。

 

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

 

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

 
以下の理由により、このプロセスは安全です。
  •  

    管理者は Expressway-C および Cisco Cloud Collaboration Management (admin.ciscospark.com) にアクセスする必要があります。 この接続は HTTPS を使用し、暗号化します。

      

  •  

    証明書は、同じ暗号化接続を使用してクラウドから Expressway にプッシュされます。

      

   

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

  • 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 Collaboration Cloud と通信します。 TLS 接続セットアップが証明書の CN ないしは SAN がクラウドによって提示された場合、 Expressway (「;callservice.ciscospark.com」;) 上のDNS 領域に設定された件名と一致する間のみ Expressway-E はクラウドとの通話を信頼します。 証明機関は身元確認の後にのみ証明書をリリースします。 callservice.ciscospark.com ドメインの所有権は、証明書の署名を得るために証明される必要があります。 弊社 (Cisco) はそのドメインを所有しているため、DNS 名「;callservice.ciscospark.com」; はリモートピアが本当に Cisco Collaboration Cloud であることの直接の証明となります。

 

Exchange 偽装アカウント

 

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

Exchange 偽装アカウントはこのタスクについて Microsoft が推奨する方法です。 偽装アカウントを使用した Exchange Web サービス (ESW) を通じたアクセスは以下の理由により安全です。

  • アクセスはユーザーに利用可能であり、EWS 接続は TLS を通じて電話上で安全である可能性があります。

     

  • アカウントは EWS を通じてのみ使用可能であり、偽装した権利を持ちアカウントにアクセスし、メールボックスクライアントを通じてメールボックスに直接アクセスできなかったユーザーは、ユーザーのメールボックスにアクセスするため EWS アプリケーションを書き込む必要があることがあります。

     

  • 偽装アカウントのパスワードは Expressway-C 上に暗号化して保存されます。

     

  

このため、Expressway-C の管理者はパスワードを知る必要がありません。これは、Exchange 管理者によって値は Expressway-C インターフェースに入力されるためです。 Expressway-C 管理者が Expressway-C ボックスにルートアクセスを持っている場合においても、パスワードは明確に表示されません。

 

セキュリティは、Expressway-C アプリケーションがそのパスワードを使用する場合についてのみ確保されます。

 

複数の Expressway 展開

Expressway-C コネクタホストは 6 個までのサーバーでクラスター化されます。 異なる地域の複数 Unified CM クラスターでのシナリオでは、ローカル冗長性のみで複数 Expressway-C クラスター (Unified CM クラスターに 1 つ) を展開できます。 1 つの Expressway-C ノードがダウンすると、クラスター内の他のノードが Cisco Collaboration Cloud および Unified CM に接続します。 現在、地域的な冗長性は不可能です。

Expressway-C および Expressway-E は SIP シグナルポートおよびメディアに使用されます。

   

複数の Expressway-C および Expressway-E クラスター を異なる地域に持つことができます。 Unified CM は、最も近い Expressway クラスターをパーティションおよびコーリングサーチスペースの構成に基づいて Unified CM から Cisco Collaboration Cloud へのアウトバウンド通話に使用します。

  

インバウンド通話については、異なる Internet Edge の Expressway-E 間のトラフィックを分割する方法について理解する必要があります。

  
  •  

    Internet Edge が同じデータセンターないしは同じ領域に展開されている場合、不可分散は DNS SRV レベルで発生可能です。 例えば、エンタープライズ ネットワークに Spark ハイブリッド通話に使用された 3 つの Internet Edge が含まれる場合、それぞれが 2 つの Expressway-E および Expressway-C ノードからなるクラスターで構成され、 _sips._tcp.example.com は同じ優先順位とウェートを持つ 6 つすべての Expressway-E レコード (3 Expressway-Es x 2) を含みます。 このセットアップは、Cisco Collaboration Cloud からさまざまな Expressway-E および Expressway-C クラスターに通話を均等に配分します。

      

  •  

    Internet Edge が異なる地域に渡って展開されている場合は、Geo DNS サービスの使用が最良のソリューションとなります。

      

    Geo DNS サービスは多くの DNS プロバイダにより提供されており、Geo DNS の能力に基づいてソースの IP アドレスを確認し、その IP アドレスが属している国や地域がどこかを理解し、および物理的にその地域に最も近いエッジの要請を転送します。 Expressway-E へのハイブリッド通話は Spark クライアントから直接来るのではなく Cisco Collaboration Cloud から来ていることに注意してください。 このため、ソース IP アドレスは Cisco Collaboration Cloud が使用している IP アドレスのいずれかとなります。

      

    この分類と Geo DNS 上の構成に基いて、通話は物理的に発信 IP アドレスが属する領域に最も近い Expressway-E に送信されます。

      

  
一例として、AWS Geo DNS サービスは以下の方法で設定されます。


  

SRV レコードが作成されると、「;場所」; ラベルが適用され、国が特定されます。 同じ場所 (この例ではイタリア) の一部の IP アドレスのクラウドからの通話は emea-expe1.example.com. に送られます。 多くの SRV レコードは地域の数に基いて作成できます。

  

Geo DNS の構成は DNS プロバイダに依存し、このサンプル構成はあくまで参考用です。

  
2 つの異なる Expressway-C および Expressway-E クラスターが US および EMEA に展開される場合は、DNS SRV レコード _sips._tcp.example.com は 2 つの異なるゾーンに属するものとして設定されます。 AWS の使用には以下の例に示すように、_sips._tcp.example.com のための 2 つの DNS SRV レコードが必要です。


  

これにより、 US 内の Cisco Collaboration Cloud から出る通話は US 内の Expressway-E に入り、US 内の Expressway-E クラスター が使用可能でない場合にのみ EMEA の Expressway-E クラスターが使用されます。 通話が EMEA 内の Cisco Collaboration Cloud から出る場合、EMEA にある Expressway-E クラスターに入り、EMEA クラスターが使用可能でない場合にのみ US クラスターを使用します。

  
 

Attachments

    Outcomes