Lync Server 2013 の TLS と MTLS

 

トピック最終更新日時: 2013-11-07

TLS プロトコルと MTLS プロトコルにより、インターネット上での通信の暗号化とエンドポイント認証機能が提供されます。 Microsoft Lync Server 2013 では、これら 2 つのプロトコルを使用して、信頼されたサーバーのネットワークを作成し、そのネットワーク経由のすべての通信が暗号化されるようにします。 サーバー間のすべての SIP 通信は MTLS により行われます。 クライアントからサーバーへの SIP 通信は TLS により行われます。

TLS を使用すると、ユーザーはクライアント ソフトウェアを使用して、接続先の Lync Server 2013 サーバーを認証できます。 TLS 接続の場合、クライアントはサーバーからの有効な証明書を要求します。 証明書が有効であると見なされるためには、証明書の発行元の CA がクライアントからも信頼されていること、およびサーバーの DNS 名が証明書の DNS 名に一致していることが必要です。 証明書が有効な場合、クライアントは証明書内の公開キーを使用して、通信に使う対称暗号化キーを暗号化し、証明書の最初の所有者だけが、その秘密キーを使用して通信の内容を暗号化することができます。 この接続は信頼済みと見なされ、それ以降は他の信頼されたサーバーやクライアントからチャレンジされません。 このような意味合いで、Web サービスで使用される SSL (Secure Sockets Layer) は TLS ベースであるということができます。

サーバー間接続は、相互認証のために MTLS に依存します。 MTLS 接続では、サーバーが発信したメッセージをサーバーが受信すると、相互に信頼できる CA からの証明書を交換します。 証明書は、各サーバーの ID を他のサーバーに証明します。 Lync Server 2013 展開では、Active Directory ドメインのすべてのメンバーがそのドメイン内のエンタープライズ CA を信頼するため、エンタープライズ CA によって発行された証明書のうち、その有効期間中であり、発行元の CA によって失効していない証明書は、すべての内部クライアントとサーバーによって自動的に有効と見なされます。 フェデレーション シナリオでは、発行元 CA は両方のフェデレーション パートナーによって信頼されている必要があります。 各パートナーは、必要に応じて、その CA が他のパートナーからも信頼されている限り、異なる CA を使用できます。 この信頼は、信頼されたルート CA にパートナーのルート CA 証明書を持つエッジ サーバー、または両方の当事者によって信頼されているサード パーティ CA を使用することで、最も簡単に実現できます。

TLS と MTLS は、盗聴および中間者 (man-in-the-middle) 攻撃の両方を防ぐのに役立ちます。 中間者 (man-in-the-middle) 攻撃では、攻撃者は 2 つのネットワーク エンティティ間の通信を、双方に気付かれることなく、攻撃者のコンピューターを経由して再ルーティングします。 TLS と Lync Server 2013 の信頼されたサーバーの仕様 (トポロジ ビルダーで指定されたもののみ) は、2 つのエンドポイント間の公開キー暗号化を使用して調整されたエンド ツー エンド暗号化を使用して、アプリケーションレイヤー上の中間者攻撃のリスクを部分的に軽減します。攻撃者は、対応する秘密キーを持つ有効で信頼された証明書を持っている必要があり、クライアントが通信するサービスの名前に発行される必要があります。通信を行います。 とはいえ、結局は、現在のネットワーク インフラストラクチャ (このケースでは社内 DNS) でのセキュリティのベスト プラクティスに従う必要があります。 Lync Server 2013 では、ドメイン コントローラーとグローバル カタログが信頼されているのと同じ方法で DNS サーバーが信頼されていることを前提としていますが、DNS では、攻撃者のサーバーがスプーフィングされた名前への要求に正常に応答できないようにすることで、DNS ハイジャック攻撃に対する保護レベルが提供されます。

次の図は、Lync Server 2013 が MTLS を使用して信頼されたサーバーのネットワークを作成する方法を大まかに示しています。

Lync Server ネットワーク内の信頼された接続