デフォルトのセキュリティの概要
デフォルトのセキュリティ機能は、追加の設定要件を必要とせずに、サポートされている Cisco Unified IP 電話 に対して基本レベルのセキュリティを提供します。
この機能は、サポートされている IP 電話に次のデフォルト セキュリティを提供します。
-
TFTP のデフォルト認証
-
オプションの暗号化
-
証明書の検証
デフォルトのセキュリティは以下のコンポーネントを使用して、安全ではない環境で基本的なセキュリティを提供します。
-
Identity Trust List(ITL):このファイルは TFTP サービスがクラスタのインストール時に有効化された後にのみ作成され、信頼を確立するために Cisco Unified IP 電話 により使用されます。
-
信頼検証サービス:このサービスはすべての Unified Communications Manager ノードで実行され、Cisco Unified IP 電話 の証明書の認証を行います。 TVS 証明書は他のいくつかの重要な証明書と共に ITL ファイルにバンドルされています。
初期信頼リスト
初期セキュリティには初期信頼リスト(ITL)ファイルが使用され、エンドポイントが Unified Communications Manager を信頼できるようになります。 ITL では、セキュリティ機能を明示的に有効にする必要はありません。 TFTP サービスが有効になり、クラスターがインストールされると、ITL ファイルが自動的に作成されます。 Unified Communications Managerの TFTP サーバの秘密鍵は ITL ファイルへの署名に使用されます。
Unified Communications Manager クラスタまたはサーバがノンセキュアモードの場合、ITL ファイルはサポートされている Cisco Unified IP 電話毎にダウンロードされます。 CLI コマンド admin:show itlを使用して、ITL ファイルのコンテンツを表示できます。
Cisco Unified IP 電話 は、次のタスクを実行するために ITL ファイルを必要とします。
-
CAPF との安全な通信、これは設定ファイルの暗号化をサポートするための前提条件です。
-
構成ファイルの署名を認証する
-
TVS を使用して HTTPS を確立する際に、EM サービス、ディレクトリ、MIDlet などのアプリケーションサーバを認証します。
Cisco IP 電話に既存の CTL ファイルがない場合、最初の ITL ファイルが自動的に信頼されます。 TVS は署名者に対応する証明書を返すことができなければなりません。
Cisco IP 電話に既存の CTL ファイルがある場合、その CTL ファイルを使用して ITL ファイルの署名を認証します。
(注) |
SHA-1 または MD5 アルゴリズムの値は、Initial Trust List (ITL) ファイルの値が変更された場合にのみ変更されます。 ITL ファイルのチェックサム値を使用して、Cisco IP 電話の ITL ファイルと Unified Communications Manager クラスタ間の違いを識別することができます。 ITL ファイルのチェックサム値は、ITL ファイルを変更した場合にのみ変更されます。 |
初期信頼リスト (ITL) ファイルの形式は CTL ファイルと同じです。 しかし、それはより小さく、無駄のないバージョンです。
次の属性が ITL ファイルに適用されます。
-
TFTP サービスがアクティブで、クラスタをインストールすると、システムは ITL ファイルを自動的に構築します。 コンテンツが変更されると、ITL ファイルは自動的に更新されます。
-
ITL ファイルは eToken を必要としません。 ソフト eToken (TFTP サーバの CallManager 証明書に関連する秘密鍵) を使用します。
-
Cisco Unified IP 電話 は、リセット中、再起動中、または CTL ファイルのダウンロード後に、ITL ファイルをダウンロードします。
ITL ファイルには次の証明書が含まれます:
-
ITLRecovery 証明書 - この証明書は ITL ファイルに署名します。
-
TFTP サーバの CallManager 証明書—この証明書により、ITL ファイルの署名および電話構成ファイルの署名を認証することができます。
-
クラスターで使用可能なすべての TVS 証明書 - これらの証明書により、電話は TVS と安全に通信し、証明書による認証を要求できます。
-
CAPF 証明書:この証明書は設定ファイルの暗号化をサポートします。 CAPF 証明書は ITL ファイルで必要ではありませんが (TVS はそれを認証できます)、CAPF への接続を簡素化します。
ITL ファイルには各証明書のレコードが含まれています。 各レコードには以下の内容が含まれています。
-
証明書
-
Cisco IP 電話で簡単に検索できる事前抽出証明書フィールド
-
証明書の役割(TFTP、CUCM、TFTP+CCM、CAPF、TVS、SAST)
TFTP サーバの CallManager 証明書は、2 つの異なるロールを持つ 2 つの ITL レコードに存在します。
-
TFTP または TFTP と CCM ロール:設定ファイルの署名を認証します。
-
SAST ロール:ITL ファイルの署名を認証します。
ITLRecovery証明書のための証明書管理の変更
-
ITLRecovery の有効期間が 5 年から 20 年に延長され、ITLRecovery 証明書がより長期間同じ状態を維持できるようになりました。
(注)
ITLRecovery 証明書のデフォルトの有効期間は 5 年です。 しかし、ITLRecovery 証明書の有効期間を 5、10、15、または 20 年に設定することもできます。 Unified Communications Manager のアップグレード中に、ITLRecovery 証明書が新しいリリースにコピーされます。
-
ITLRecovery 証明書を再生成する前に、CLI と GUI の両方に警告メッセージが表示されます。 この警告メッセージは、トークンなしの CTL を使用する場合、および CallManager 証明書を再生成する場合は、CTL ファイルに更新された CallManager 証明書が含まれていること、およびその証明書がエンドポイントに更新されていることを確認するために表示されます。
ITLRecovery 証明書
ITLRecovery 証明書機能では、新しいドロップダウンリスト [ ITL ファイルの状況 ] を使用して、管理者は古い ITL を持つ電話を識別し、これらの電話に対して必要なアクションを実行できるようにすることができます。
一部の電話は最新の ITL ファイルを取得せず、ITL ファイルが更新されたときに古いものを保持します (CM 証明書の更新など)。 システムは、ユーザ インターフェイスに、一致しない ITL ファイルを持つ電話の一元化されたレポートを表示します。
以下は、さまざまな ITLRecovery シナリオです。
TFTP サービスのアクティベーション:
-
TFTP サービスがアクティブになると、生成された ITL ファイルのハッシュとサーバのホスト名が DB に保存されます。 TFTP コードで ITL 更新が行われるたびに更新されます。
-
TFTP ホスト名がすでにテーブルに存在する場合、生成された ITL ハッシュが保存されている値と比較されます。
-
ITL ハッシュが同じでない場合、新しい ITL ハッシュは DB で更新されます。
-
ITL ハッシュが同じである場合、TFTP ログは「TFTP ITL ハッシュが変更されていません」を示します。
-
デバイスの登録と ITLFile のダウンロード
-
電話が Unified Communications Managerで登録する際に、サーバに存在する ITLFile の詳細 (サーバのホスト名、ハッシュ、タイムスタンプ) が DB に存在しない場合に挿入されます。
-
電話が Unified Communications Manager に登録されると、その電話に適用されている ITL ファイルの詳細を含む SIP アラームが送信されます。 これは、データベースに保存されている ITL ファイルのハッシュと比較されます。
-
ITL ハッシュが同じ場合、デバイス ハッシュ情報は新しいタイムスタンプで更新されます。
-
ITL ハッシュが同じでない場合、報告された ITL ハッシュとタイムスタンプがデバイスに対して更新されます。
-
-
電話の登録を解除すると、そのデバイスの信頼ハッシュ情報は削除されます。
連携動作と制限事項
ある Unified Communications Manager クラスタに 39 個を超える証明書がある場合、Cisco IP 電話上の ITL ファイルサイズは 64KB を超えます。 ITL ファイルサイズの増加は、電話での ITL の適切な読み込みに影響を与え、その結果、Unified Communications Managerに登録する際に電話の登録が失敗することがあります。
信頼検証サービス
ネットワークには多数の電話が接続されており、これらの電話のメモリ容量は限られています。 Cisco Unified IP 電話 このため、 Unified Communications Manager はTVSを通じてリモートの信頼ストアとして機能し、証明書の信頼ストアを各電話に配置する必要がなくなります。 Cisco Unified IP 電話(電話)は CTL または ITL ファイルを通じて署名または証明書を確認できないため、確認のために TVS サーバと通信します。 このように、すべての Cisco Unified IP 電話(電話)にトラストストアがあるよりも、中央のトラストストアにある方が管理が容易です。
TVS により、HTTPS を確立する際に、EM サービス、ディレクトリ、MIDlet などのアプリケーションサーバを Cisco Unified IP 電話 (電話)で認証できるようになります。
TVS は以下の機能を提供します。
-
スケーラビリティ - Cisco Unified IP 電話 (電話)のリソースは信頼する証明書の数に影響されません。
-
柔軟性—信頼できる証明書の追加または削除は、システムに自動的に反映されます。
-
デフォルトでのセキュリティ - 非メディアおよびシグナリング セキュリティ機能は既定のインストールに含まれており、ユーザの介入を必要としません。
(注) |
セキュアなシグナリングとメディアを有効にする場合、CTL ファイルを作成し、クラスタを混合モードに設定します。 CTL ファイルを作成し、クラスタを混合モードに設定するには、CLI コマンド utils ctl set-cluster 混合モードを使用します。 |
以下は、TVS を説明する基本概念です。
-
TVS は Unified Communications Manager サーバ上で動作し、Cisco IP Phoneの代わりに証明書の認証を行います。
-
Cisco Unified IP 電話 すべての信頼できる証明書をダウンロードする代わりに、TVS のみを信頼する必要があります。
-
ITL ファイルはユーザの介入なしで自動的に生成されます。 ITL ファイルは Cisco Unified IP 電話 によりダウンロードされ、そこから信頼が流れます。
認証、完全性、および認可
整合性と認証により、次の脅威から保護します。
-
TFTP ファイル改ざん (整合性)
-
Unified Communications Manager と電話間のコール処理シグナリングの変更 (認証)
-
中間者攻撃 (認証) です。 頭字語 セクションに定義されています。
-
電話およびサーバでのなりすまし (認証)
-
リプレイ攻撃 (ダイジェスト認証)
承認では、認証されたユーザ、サービス、またはアプリケーションが実行できることを指定します。 単一のセッションで複数の認証および認可方法を実装できます。
イメージ認証(Image authentication)
このプロセスにより、IP電話にロードする前に、ファームウェア ロードであるバイナリ イメージの改ざんが防止されます。 イメージが改ざんされると、電話機は認証プロセスに失敗し、新しいイメージを拒否します。 画像認証は、ユニファイド コミュニケーションズ マネージャ のインストール時に自動的にインストールされる、署名されたバイナリファイルを通じて行われます。 同様に、ウェブからダウンロードしたファームウェア更新も署名済みバイナリイメージを提供します。
デバイス認証
このプロセスにより、通信デバイスの ID を検証し、エンティティが要求されているとおりのものであることを確認します。
Unified Communications Manager サーバとサポートされている Cisco Unified IP Phone 、SIP トランク、または JTAPI/TAPI/CTI アプリケーションの間で端末認証が行われる (サポートされている場合)。 認証された接続は、各エンティティが他のエンティティの証明書を受け入れる場合にのみ、これらのエンティティ間で発生します。 相互認証は、この相互証明書交換のプロセスを説明します。
端末認証は、CiscoCTL ファイル( Unified Communications Manager サーバノードとアプリケーションの認証用)と証明書機関プロキシ機能(端末と JTAPI/TAPI/CTI アプリケーションの認証用)の作成に依存しています。
ヒント |
SIP トランク経由で接続する SIP ユーザエージェントは、CallManager 信頼ストアに SIP ユーザエージェント証明書が含まれており、SIP ユーザエージェントが Unified Communications Manager 証明書を信頼ストアに含んでいる場合、 Unified Communications Manager で認証します。 CallManager トラストストアの更新についての詳細は、この Unified Communications Manager リリースをサポートする『 Cisco Unified Communications オペレーティングシステム管理ガイド 』を参照してください。 |
ファイル認証
このプロセスでは、電話がダウンロードしたデジタル署名されたファイルを検証します。たとえば、設定、着信音リスト、ロケール、および CTL ファイルです。 電話機は、ファイル作成後にファイルの改ざんが行われていないことを確認するために、署名を検証します。 対応端末については、 "対応電話モデル"をご覧ください。
混合モードでクラスターを設定する場合、TFTP サーバは、着信音リスト、ローカライズ、default.cnf.xml、着信音リスト wav ファイルなどの静的ファイルに.sgn 形式で署名します。 TFTP サーバは、ファイルにデータ変更があったことを確認するたびに、 <device name>.cnf.xml 形式のファイルに署名します。
キャッシュが無効になっている場合、TFTP サーバは署名済みファイルをディスクに書き込みます。 TFTP サーバは保存されたファイルが変更されたことを確認すると、ファイルに再署名します。 ディスク上の新しいファイルは、保存されたファイルを削除されると上書きします。 電話が新しいファイルをダウンロードする前に、管理者は影響を受けるデバイスを Unified Communications Manager で再起動する必要があります。
TFTP サーバからファイルを受信した後、電話機はファイルの署名を検証することにより、ファイルの整合性を確認します。 電話が認証された接続を確立するには、次の条件が満たされている必要があります。
-
証明書が電話に存在している必要があります。
-
CTL ファイルが電話機上に存在している必要があり、さらに Unified Communications Manager のエントリと証明書が CTL ファイル中に存在している必要があります。
-
デバイスの認証または暗号化を構成しました。
シグナリング認証(Signaling Authentication)
シグナリング整合性とも呼ばれるこのプロセスは、TLS プロトコルを使用して、送信中にシグナリング パケットに改ざんが発生していないことを検証します。
シグナリング認証は、証明書信頼リスト (CTL) ファイルの作成に依存しています。
ダイジェスト認証
SIP トランクと電話に対するこのプロセスにより、Unified Communications Manager は、Unified Communications Manager に接続するデバイスの身元を問い詰めることができます。 要求されると、デバイスは確認のため、ユーザ名とパスワードのようなダイジェスト資格情報を Unified Communications Manager に提示します。 提示された資格情報がその端末のデータベースで構成されているものと一致する場合、ダイジェスト認証が成功し、 Unified Communications Manager が SIP リクエストを処理します。
(注) |
クラスタ セキュリティ モードはダイジェスト認証には影響しないことに注意してください。 |
(注) |
デバイスのダイジェスト認証を有効にすると、デバイスを登録するための一意のダイジェスト ユーザ ID とパスワードが要求されます。 |
Unified Communications Manager データベース内の電話ユーザーまたはアプリケーションユーザー用に SIP ダイジェスト認証情報を設定します。
-
アプリケーションの場合は、[アプリケーションユーザーの設定(Application User Configuration)] ウィンドウでダイジェスト認証情報を指定します。
-
SIP を実行している電話の場合、[エンドユーザ] ウィンドウでダイジェスト認証資格情報を指定します。 ユーザを設定した後で電話に資格情報を関連付けるには、[電話の設定] ウィンドウで [ダイジェスト ユーザ] とエンド ユーザを選択します。 電話をリセットすると、TFTP サーバーが電話に提供する電話設定ファイルに認証情報が含まれるようになります。 TFTP ダウンロードでダイジェスト認証情報が平文で送信されないようにするには、暗号化された電話設定ファイルのセットアップに関するトピックを参照してください。
-
SIP トランクで受信したチャレンジについては、領域ユーザー名(デバイスまたはアプリケーションユーザー)とダイジェスト認証情報を指定する SIP 領域を設定します。
SIP を実行している外部電話またはトランクのダイジェスト認証を有効にし、ダイジェスト認証情報を設定すると、Unified Communications Manager は、ユーザー名、パスワード、および領域のハッシュ値を含む認証情報のチェックサムを計算します。 システムは MD5 ハッシュを計算するために、乱数であるナンス値を使用します。 Unified Communications Manager は値を暗号化し、ユーザ名とチェックサムをデータベースに保存します。
チャレンジを開始するために、Unified Communications Manager は SIP 401(未承認)メッセージを使用します。このメッセージには、ヘッダーにナンスとレルムが含まれます。 電話またはトランクの SIP デバイス セキュリティ プロファイルで、ナンスの有効時間を設定します。 ナンスの有効時間は、ナンスの値が有効である時間を分単位で指定します。 この時間間隔が終了すると、 Unified Communications Manager は外部デバイスを拒否し、新しい番号を生成します。
(注) |
Unified Communications Manager は、回線側の電話またはデバイスから発信された SIP 通話のユーザー エージェント サーバー(UAS)、SIPトランクへの発信コールのユーザー エージェント クライアント(UAC)、または回線間またはトランク間接続のバックツーバック ユーザー エージェント(B2BUA)として機能します。 ほとんどの環境で、 Unified Communications Manager は主に SCCP と SIP エンドポイントを接続する B2BUA として機能します。 (SIP ユーザ エージェントは SIP メッセージを発信するデバイスまたはアプリケーションを表します。) |
ヒント |
ダイジェスト認証は完全性や機密性を提供しません。 デバイスの整合性と機密性を確保するには、デバイスが TLS をサポートしている場合、デバイスの TLS プロトコルを構成します。 デバイスが暗号化をサポートしている場合、デバイス セキュリティ モードを暗号化として構成します。 デバイスが暗号化された電話構成ファイルをサポートしている場合、ファイルの暗号化を構成します。 |
電話のダイジェスト認証
電話のダイジェスト認証を有効にすると、Unified Communications Manager は、キープアライブメッセージを除く、SIP を実行している電話に対するすべての要求に認証を要求します。 Unified Communications Manager は、回線側の電話からのチャレンジには応答しません。
レスポンスを受信した後、Unified Communications Manager はデータベースに保存されているユーザー名のチェックサムを、レスポンスヘッダーの資格情報と照合します。
SIP を実行する電話機は、Unified Communications Manager 領域にあります。これは、Unified Communications Manager Administration のインストール時に定義されます。 SIP ステーション領域のサービス パラメータを使用して、電話に対するチャレンジのための SIP 領域を設定します。 各ダイジェストユーザーは、領域ごとに 1 セットのダイジェスト資格情報を持つことができます。
ヒント |
エンド ユーザのダイジェスト認証を有効にしているが、ダイジェスト クレデンシャルを設定していない場合、電話は登録に失敗します。 クラスタモードがノンセキュアで、ダイジェスト認証を有効にしてダイジェストクレデンシャルを設定している場合、ダイジェストクレデンシャルが電話に送信され、 Unified Communications Manager は引き続きチャレンジを開始します。 |
トランクのダイジェスト認証
トランクのダイジェスト認証を有効にすると、Unified Communications Manager は、SIP トランク経由で接続する SIP デバイスおよびアプリケーションからの SIP トランクリクエストをチャレンジします。 システムは、チャレンジ メッセージで Cluster ID エンタープライズ パラメータを使用します。 SIP トランクを通じて接続する SIP ユーザーエージェントは、 Unified Communications Manager でデバイスまたはアプリケーションに対して設定した固有のダイジェスト認証情報で応答します。
Unified Communications Manager が SIP トランクリクエストを開始すると、SIP トランクを通して接続する SIP ユーザーエージェントは、 Unified Communications Manager のアイデンティティをチャレンジすることができます。 これらの着信チャレンジの場合、ユーザに要求された資格情報を提供するように SIP レルムを構成します。 Unified Communications Manager が SIP 401(未承認)または SIP 407(プロキシ認証が必要)メッセージを受信すると、 Unified Communications Manager は、トランク経由で接続する領域の暗号化パスワードと、チャレンジメッセージで指定されているユーザー名を検索します。 Unified Communications Manager はパスワードを解読し、ダイジェストを計算してレスポンスメッセージで提示します。
ヒント |
領域は xyz.com などの SIP トランクを介して接続するドメインを表し、リクエストの送信元を特定するのに役立ちます。 |
SIP 領域を設定するには、SIP トランクのダイジェスト認証に関するトピックを参照してください。 Unified Communications Manager でチャレンジする Unified Communications Manager のユーザーエージェントごとに、SIP 領域、ユーザー名とパスワードを設定する必要があります。 各トユーザーエージェントは、領域ごとに 1 セットのダイジェスト資格情報を持つことができます。
認証
Unified Communications Manager は、認可プロセスを使用して、SIP を実行している電話、SIP トランク、SIP トランク上の SIP アプリケーション要求からの特定のカテゴリのメッセージを制限します。
-
SIP INVITE メッセージ、ダイアログ内メッセージ、および SIP を実行している電話の場合、Unified Communications Manager は、コーリングサーチスペースとパーティションを使用した認可を行います。
-
電話からの SIP SUBSCRIBE 要求の場合、 Unified Communications Manager は、ユーザがプレゼンスグループにアクセスするための認証を提供します。
-
SIP トランク Unified Communications Manager は、プレゼンスサブスクリプションと特定の非 INVITE SIP メッセージの認証を行います。たとえば、ダイヤル外の REFER、一方的な通知、replaces ヘッダーを持つ SIP 要求などです。 ウィンドウで許可された SIP リクエストにチェックを入れて、[SIP トランクセキュリティプロファイルの設定(SIP Trunk Security Profile Configuration)] ウィンドウでの権限を指定します。
SIP トランクアプリケーションの認証を有効にするには、[SIP トランクセキュリティプロファイル] ウィンドウで [アプリケーションレベル認証を有効にする] と [ダイジェスト認証] チェックボックスを選択します。次に、[アプリケーションユーザの構成] ウィンドウで、許可された SIP 要求のチェックボックスをオンにします。
SIP トランク認証とアプリケーションレベル認証の両方を有効にした場合、認証はまず SIP トランクに対して行われ、次に SIP アプリケーションユーザに対して行われます。 トランク Unified Communications Manager はトランクのアクセスコントロールリスト (ACL) 情報をダウンロードしてキャッシュします。 ACL 情報が着信 SIP リクエストに適用されます。 ACL が SIP 要求を許可しない場合、通話は 403 Forbidden メッセージで失敗します。
ACL で SIP リクエストが許可されている場合、 Unified Communications Manager は SIP トランクセキュリティプロファイルでダイジェスト認証が有効になっているかどうかを確認します。 ダイジェスト認証およびアプリケーションレベル認証が有効ではない場合、 Unified Communications Manager がリクエストを処理します。 ダイジェスト認証が有効な場合、 Unified Communications Manager は受信リクエストに認証ヘッダーが存在することを確認し、ダイジェスト認証を使用してソースアプリケーションを識別します。 ヘッダーが存在しない場合、 Unified Communications Manager は 401 メッセージでデバイスにチャレンジを行います。
アプリケーションレベルの ACL が適用される前に、 Unified Communications Manager はダイジェスト認証で SIP トランクユーザエージェントを認証します。 そのため、アプリケーションレベルの承認を行う前に、SIP トランク セキュリティ プロファイルでダイジェスト認証を有効にしておく必要があります。
NMAP スキャン操作
脆弱性スキャンを実行するために、Windows または Linux プラットフォームでネットワークマッパー (NMAP) スキャンプログラムを実行できます。 NMAP は、ネットワーク探索またはセキュリティ監査のための無料のオープン ソース ユーティリティです。
(注) |
NMAP DP スキャンは、完了までに最大 18 時間かかる場合があります。 |
構文
nmap -n -vv -sU -p <port_range> <ccm_ip_address>
引数の説明
-n: DNS 解決を行いません。 見つけたアクティブな IP アドレスで逆 DNS 解決を行わないように NMAP に指示します。 DNS は NMAP ビルトイン並列スタブリソルバーを使用しても遅い場合があるため、このオプションによりスキャン時間を大幅に短縮できます。
-v: 冗長レベルを上げます。これにより NMAP は進行中のスキャンに関する詳細情報を出力します。 システムは、開いているポートが見つかると表示し、スキャンに数分以上かかると NMAP が予測した場合は、完了時間の予測を提供します。 このオプションを 2 回以上使用すると、冗長性がさらに高まります。
-sU: UDP ポートスキャンを指定します。
-p: スキャンするポートを指定し、デフォルトを上書きします。 個別のポート番号や、ハイフンで区切られた範囲のポート番号 (たとえば、1-1023) も使用可能であることに注意してください。
ccm_ip_address: Cisco Unified Communications ManagerのIPアドレス
自動登録
システムは、混在モードとノンセキュアモードの両方で自動登録をサポートしています。 既定の構成ファイルも署名されます。 デフォルトでのセキュリティをサポートしない Cisco IP 電話には、署名されていないデフォルトの構成ファイルが提供されます。
Cisco Unified Communications Manager および ITL ファイルを含むクラスタ間で IP 電話を移行する
Unified Communications Manager 8.0 (1) 以降では、新しいデフォルトによるセキュリティと初期信頼リスト (ITL) ファイルの使用が導入されています。 この新機能により、異なる Unified CM クラスタ間で電話を移動する場合は注意が必要です。また、適切な移行手順に従うようにしてください。
注意 |
適切な手順に従わなかった場合、何千という電話の ITL ファイルを手動で削除する必要があります。 |
新しい ITL ファイルをサポートする Cisco IP 電話は、 Unified CM TFTP サーバからこの特別なファイルをダウンロードする必要があります。 ITL ファイルが電話機にインストールされると、以降のすべての構成ファイルと ITL ファイルの更新は、次のいずれかによって署名されなければなりません。
-
現在電話機にインストールされている TFTP サーバ証明書、または
-
クラスターの一つのTVSサービスで検証できるTFTP証明書。 ITL ファイルにリストされているクラスタ内の TVS サービスの証明書を見つけることができます。
この新しいセキュリティ機能を考慮して、電話を 1 つのクラスタから別のクラスタに移動するときに、3 つの問題が発生する可能性があります。
-
新しいクラスタの ITL ファイルは現在の ITL ファイルの署名者によって署名されていないため、電話は新しい ITL ファイルまたは設定ファイルを受け入れることができません。
-
電話の既存の ITL にリストされている TVS サーバは、電話が新しいクラスタに移動されると到達できない場合があります。
-
証明書の検証のために TVS サーバに到達できても、古いクラスタサーバは新しいサーバ証明書を持っていない場合があります。
これら 3 つの問題のうち 1 つ以上が発生した場合、クラスタ間で移動中のすべての電話機から ITL ファイルを手動で削除することが考えられます。 しかし、これは電話の数が増えるにつれて膨大な労力を必要とするため、望ましいソリューションとは言えません。
最も望ましいオプションは、Cisco Unified CM のエンタープライズパラメータ Prepare Cluster for Rollback to pre-8.0. を利用することです。 このパラメータが True に設定されると、電話は空の TVS および TFTP 証明書セクションを含む特別な ITL ファイルをダウンロードします。
電話に空の ITL ファイルがある場合、電話は署名されていない構成ファイルを受け入れ ( Unified CM 8.x 以前のクラスタへの移行用)、新しい ITL ファイルを受け入れます (別の Unified CM 8.x クラスタへの移行用)。
空の ITL ファイルは、電話で [
] をチェックすることで確認できます。 古い TVS および TFTP サーバがあった場所に空のエントリが表示されます。電話は、新しい空の ITL ファイルをダウンロードするためだけに、古い Unified CM サーバにアクセスする必要があります。
古いクラスタをオンラインのままにしておく場合は、[ Prepare Cluster for Rollback to pre-8.0 Enterprise パラメーター] を無効にして、デフォルトでのセキュリティを復元してください。