Unified Communications Manager により、CTIManager と CTI/JTAPI/TAPI アプリケーション間のシグナリング接続とメディアストリームをセキュアにすることができます。

（注）

当社は、CiscoJTAPI/TSP プラグインのインストール時にセキュリティ設定を構成したものと仮定しています。 また、Cisco CTL クライアントまたは CLI コマンドセット utils ctl で設定されているように、クラスターセキュリティモードは混合モードと等しいと想定します。 本章で説明されているタスクを実行する際にこれらの設定が構成されていない場合、CTIManager とアプリケーションは非セキュアなポート、ポート 2748 経由で接続します。 Cisco の CTL クライアントは Release 14 からサポートされなくなりました。Cisco CTL プラグインの代わりに、CLI コマンドを使用して Unified Communications Manager サーバーを混合モードに切り替えることを推奨します。

CTIManager とアプリケーションは、相互に認証された TLS ハンドシェイク (証明書交換) を通じて、相手の身元を確認します。 TLS 接続が確立されると、CTIManager とアプリケーションは TLS ポートのポート 2749 経由で QBE メッセージを交換します。

アプリケーションの認証を行うために、CTIManager は Unified Communications Manager 証明書を使用します。この証明書には、インストール時に Unified Communications Manager サーバーに自動的にインストールされる自己署名証明書、またはサードパーティの CA 署名証明書が使用されます。

CLI コマンドセット utils ctl または Cisco CTL クライアントで CTL ファイルを生成すると、この証明書が自動的に CTL ファイルに追加されます。 アプリケーションは CTIManager への接続を試みる前に、TFTP サーバーから CTL ファイルをダウンロードします。

JTAPI/TSP クライアントが初めて CTL ファイルを TFTP サーバーからダウンロードするとき、JTAPI/TSP クライアントは CTL ファイルを信頼します。 JTAPI/TSP クライアントは CTL ファイルを検証しないため、ダウンロードは安全な環境で行うことを推奨します。 JTAPI/TSP クライアントは、後続の CTL ファイルのダウンロードを確認します。たとえば、CTL ファイルを更新した後、JTAPI/TSP クライアントは CTL ファイルのセキュリティトークンを使用して、ダウンロードする新しい CTL ファイルのデジタル署名を認証します。 このファイルの内容には Unified Communications Manager 証明書および CAPF サーバー証明書が含まれます。

CTL ファイルが危険にさらされている場合、JTAPI/TSP クライアントはダウンロードされた CTL ファイルを置き換えません。クライアントはエラーをログに記録し、既存の CTL ファイル中の古い証明書を使用して TLS 接続の確立を試みます。 CTL ファイルが変更されているか、または不正使用されている場合、接続は失敗する可能性があります。 CTL ファイルのダウンロードが失敗し、しかも複数の TFTP サーバーが存在する場合、ファイルをダウンロードするように別の TFTP サーバーを設定できます。 JTAPI/TAPI クライアントは、次の状況ではどのポートにも接続しません。

• 何らかの理由でクライアントが CTL ファイルをダウンロードできません。たとえば、CTL ファイルが存在しません。

• クライアントに既存の CTL ファイルがありません。

• アプリケーションユーザーをセキュアな CTI ユーザーとして構成しました。

CTIManager で認証するために、アプリケーションは 認証局プロキシ 機能 (CAPF) が発行する証明書を使用します。 アプリケーションと CTIManager 間のすべての接続で TLS を使用するには、アプリケーション PC で実行される各インスタンスに固有の証明書が必要です。 1 つの証明書ですべてのインスタンスをカバーできるわけではありません。 Cisco Unified Communications Manager Assistant サービスが実行されているノードに証明書が確実にインストールされるように、 Cisco Unified Communications Manager Administrationの各アプリケーション・ユーザー CAPF プロファイル構成またはエンドユーザー CAPF プロファイル構成に対して固有のインスタンス ID を構成します。次のように、 「アプリケーションおよびエンドユーザー CAPF プロファイルの構成設定」を参照してください 。

ヒント	ある PC からアプリケーションをアンインストールして別の PC にインストールする場合、新しい PC の各インスタンスに対して新しい証明書をインストールする必要があります。

Unified Communications Manager でアプリケーションユーザーまたはエンドユーザーを標準 CTI セキュアコネクションユーザーグループに追加し、アプリケーションの TLS を有効にする必要があります。 ユーザをこのグループに追加し、証明書をインストールした後、アプリケーションはユーザが TLS ポート経由で接続することを確認します。

ヒント	認証は暗号化の最小要件として機能します。つまり、認証を設定していない場合、暗号化を使用することはできません。 Unified Communications Manager、Cisco QRT、および Cisco Web Dialer は暗号化をサポートしていません。 CTIManager サービスに接続する CTI クライアントは、クライアントが音声パケットを送信する場合、暗号化をサポートしている可能性があります。

アプリケーションと CTIManager の間のメディア ストリームをセキュアにするには、アプリケーション ユーザーまたはエンド ユーザーを標準 CTI SRTP キー マテリアルの受信を許可するユーザー グループに追加します Unified Communications Manager。 これらのユーザーが標準 CTI セキュア接続ユーザーグループにも存在し、クラスタセキュリティモードが混合モードである場合、CTIManager はアプリケーションとの TLS 接続を確立し、メディアイベントでアプリケーションにキーマテリアルを提供します

（注）	クラスタセキュリティモードでは、スタンドアロンサーバーまたはクラスタのセキュリティ機能を設定します。

アプリケーションが SRTP キー情報を記録または保存することはありませんが、アプリケーションはキー情報を使用して RTP ストリームを暗号化し、CTIManager からの SRTP ストリームを復号化します。

何らかの理由でアプリケーションがノンセキュア ポートのポート 2748 に接続する場合、CTIManager はキー情報を送信しません。 制限を設定したために、CTI/JTAPI/TAPI がデバイスまたはディレクトリ番号を監視または制御できない場合、CTIManager はキー情報を送信しません。

ヒント	アプリケーションが SRTP セッションキーを受信するには、アプリケーションまたはエンドユーザーが、[標準CTIを有効にする（Standard CTI Enabled）]、[標準 CTI セキュア接続（Standard CTI Secure Connection）]、および [標準 CTI SRTP 重要素材の受信許可（Standard CTI Allow Reception of SRTP Key Material）] の 3 つのグループに属している必要があります。

ただし、Unified Communications Manager は CTI ポートとルートポイントとの間の安全なコールを容易にすることができますが、アプリケーションがメディアパラメータを処理するため、安全なコールをサポートするようにアプリケーションを設定する必要があります。

CTI ポート/ルートポイントは、動的または静的な登録によって登録されます。 ポート/ルート ポイントが動的登録を使用する場合、メディア パラメータは各コールに対して指定されます。静的登録の場合、メディアパラメータは登録時に指定され、呼び出しごとに変更することはできません。 CTIports/ルートポイントが TLS 接続を介して CTIManager に登録されると、アプリケーションがデバイス登録リクエストで有効な暗号化アルゴリズムを使用し、相手側がセキュアな場合、デバイスは安全に登録され、メディアは SRTP 経由で暗号化されます。

CTI アプリケーションが確立済みの通話の監視を開始するとき、アプリケーションは RTP イベントを受信しません。 確立された通話については、CTI アプリケーションは DeviceSnapshot イベントを提供します。これは、通話のメディアがセキュアか非セキュアかを定義します。このイベントは暗号化キーを提供しません。

Unified Communications Manager と共に自動的にインストールされる CAPF（認証局プロキシ機能）は、設定に応じて、コンピュータ電話統合/TAPI/TAPI アプリケーションに対して次のタスクを実行します。

• 認証文字列を使って JTAPI/TSP クライアントを認証します。

• ローカルで有効な証明書（LSC）を コンピュータ電話統合/JTAPI/TAPI アプリケーションユーザーまたはエンドユーザーに発行します。

• 既存のローカルで有効な証明書をアップグレードします。

• 表示とトラブルシューティングのために証明書を取得します。

JTAPI/TSP クライアントが CAPF と対話するとき、クライアントは認証文字列を使用して CAPF に対して自身を認証します。それから、クライアントは公開鍵と秘密鍵のペアを生成し、公開鍵を署名されたメッセージで CAPF サーバーに転送します。 秘密鍵はクライアント内に残り、外部に公開されることはありません。 CAPF は証明書に署名し、署名したメッセージで証明書をクライアントに送り返します。

アプリケーションユーザーまたはエンドユーザーに証明書を発行するには、それぞれ [アプリケーションユーザーの CAPF プロファイル設定] ウィンドウまたは [エンドユーザーの CAPF プロファイル設定] ウィンドウで設定を行います。 以下の情報では、 Unified Communications Manager がサポートする CAPF プロファイル間の違いについて説明しています。

• アプリケーションユーザー CAPF プロファイルこのプロファイルにより、ローカルで有効な証明書を発行してアプリケーションユーザーを保護し、CTIManager サービスとアプリケーションの間で TLS 接続を開くことができます。

  1 つのアプリケーション ユーザー CAPF プロファイルが、サーバー上のサービスまたはアプリケーションの単一インスタンスに対応します。 同じサーバー上で複数のウェブ サービスまたはアプリケーションをアクティベートする場合、サーバー上の各サービスに対して 1 つずつ、複数のアプリケーション ユーザー CAPF プロファイルを設定する必要があります。

  クラスタ内の 2 つのサーバーでサービスまたはアプリケーションをアクティベートする場合、各サーバーに 1 つずつ、合計 2 つのアプリケーション ユーザー CAPF プロファイルを設定する必要があります。

• エンドユーザー CAPF プロファイル—このプロファイルにより、ローカルで有効な証明書を CTI クライアントに発行し、CTI クライアントが TLS 接続経由で CTIManager サービスと通信できるようになります。

ヒント	JTAPI クライアントは、[JTAPI 基本設定] ウィンドウで設定したパスに、LSC を Java キーストア形式で保存します。 TSP クライアントは LSC を暗号化された形式で既定のディレクトリまたは設定したパスに保存します。

以下の情報は、通信障害や電源障害の発生時に適用されます。

• 証明書のインストール中に通信障害が発生すると、JTAPI クライアントは 30 秒間隔でさらに 3 回証明書の取得を試みます。 この値を構成することはできません。

  TSP クライアントの場合、再試行と再試行タイマーを設定できます。 TSP クライアントが割り当てられた時間内に証明書の取得を試みる回数を指定することにより、これらの値を設定します。 両方の値のデフォルトは 0 です。1 (1 回のリトライ)、2、または 3 を指定することで、最大 3 回の再試行を設定できます。各再試行の時間は最大30秒まで設定できます。

• JTAPI/TSP クライアントが CAPF でセッションを試みている間に電源障害が発生すると、クライアントは電源が回復した後に証明書のダウンロードを試みます。

証明書の処理状況は、特定の [アプリケーションユーザー（Application User）] または [エンドユーザーの CAPF プロファイル設定（End User CAPF Profile configuration）] ウィンドウ（[検索/一覧表示（Find/List）] ウィンドウではない）、または [JTAPI/TSP の設定（JTAPI/TSP Preferences）] GUI ウィンドウで確認できます。