デフォルトのセキュリティの概要
デフォルトのセキュリティ機能は、追加の設定要件なしでサポートされる Cisco Unified IP Phone の基本的なレベルのセキュリティを提供します。
この機能は、サポートされる IP 電話機に対して次のデフォルトのセキュリティを提供します。
-
TFTP のデフォルト認証
-
オプションの暗号化
-
証明書の検証
デフォルトのセキュリティは、次のコンポーネントを使用して非セキュアな環境で基本的なセキュリティを提供します。
-
アイデンティティ信頼リスト(ITL):このファイルは、クラスタのインストール時に TFTP サービスがアクティブ化された後、信頼の確立のために Cisco Unified IP Phone により使用されます。
-
信頼検証サービス:このサービスは、すべての Unified Communications Manager ノードで実行され、Cisco Unified IP Phone の証明書を認証します。TVS 証明書と他のいくつかのキー証明書が ITL ファイルにバンドルされます。
初期信頼リスト
初期信頼リスト(ITL)ファイルは、エンドポイントが Unified Communications Manager を信頼できるよう、最初のセキュリティに使用されます。ITL は明示的に有効にするセキュリティ機能を必要としません。ITL ファイルは、TFTP サービスがアクティブになり、クラスタがインストールされると自動的に作成されます。Unified Communications Manager の TFTP サーバの秘密キーは、ITL ファイルの署名に使用されます。
Unified Communications Manager クラスタまたはサーバが非セキュアモードの場合、ITL ファイルはサポートされている Cisco Unified IP Phone ごとにダウンロードされます。CLI コマンド admin:show itl を使用して、ITL ファイルの内容を表示できます。
Cisco Unified IP Phone は、次のタスクを実行するために ITL ファイルが必要です。
-
CAPF とセキュアに通信する。設定ファイル暗号化をサポートするための前提条件です。
-
設定ファイルの署名を認証する。
-
TVS を使用する EM サービス、ディレクトリ、MIDlet などのアプリケーション サーバを認証します。
Cisco IP 電話 に CTL ファイルがまだ存在していない場合、最初の ITL ファイルが自動的に信頼されます。テレビは、署名者に対応する証明書を返すことができる必要があります。
Cisco IP 電話 に既存の CTL ファイルがある場合、ITL ファイルの署名の認証にその CTL ファイルが使用されます。
(注) |
SHA-1 または MD5 アルゴリズム値は、初期信頼リスト(ITL)ファイルの値に変更があった場合にのみ変更されます。ITL ファイルのチェックサム値を使用すると、Cisco IP 電話 と Unified Communications Manager クラスタの間にある ITL ファイルの差異を特定できます。ITL ファイルのチェックサム値は、ITL ファイルを変更した場合にのみ変更されます。 |
最初の信頼リスト (ITL) ファイルは、CTL ファイルと同じ形式になっています。ただし、これはより小さく、スリムのバージョンです。
ITL ファイルには次の属性が適用されます。
-
TFTP サービスがアクティブ化され、クラスタをインストールすると、システムによって ITL ファイルが自動的に作成されます。内容が変更された場合、ITL ファイルは自動的に更新されます。
-
ITL ファイルは eToken を必要としません。このファイルはソフト eToken(TFTP サーバの CallManager 証明書に関連付けられている秘密キー)を使用します。
-
リセット中、再起動中、または CTL ファイルのダウンロード後に、Cisco Unified IP Phone は ITL ファイルをダウンロードします。
ITL ファイルには次の証明書が含まれています。
-
ITLRecovery 証明書:この証明書は ITL ファイルに署名します。
-
TFTP サーバの CallManager 証明書:この証明書を使用すると、ITL ファイル署名と電話機設定ファイル署名を認証できます。
-
クラスタ上で使用可能なすべての TVS 証明書:これらの証明書を使用すると、電話機は TVS と安全に通信し、証明書認証を要求できます。
-
CAPF 証明書: これらの証明書は、コンフィギュレーションファイルの暗号化をサポートします。CAPF 証明書は必ずしも ITL ファイル内に存在する必要はありません(TVS で認証可能)が、CAPF 証明書によって CAPF への接続が簡易化されます。
ITL ファイルには証明書ごとに 1 つのレコードが含まれます。各レコードの内容は次のとおりです。
-
証明書
-
Cisco IP 電話 によるルックアップを容易にするための、事前に抽出された証明書フィールド。
-
証明書の権限(TFTP、CUCM、TFTP+CCM、CAPF、TV、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 Certificate 機能では、新しい ITL ファイルステータスドロップダウンリストが導入され、管理者は古い ITL を持つ電話機を識別して、それらの電話機に必要なアクションを実行できるようになりました。
一部の電話機は、ITL ファイルが更新されたときに最新の ITL ファイルを取得せず、古いものを保持します(CM 証明書の更新など)。システムは、不一致の ITL ファイルがある電話機の集中型レポートをユーザインターフェイスに表示します。
次に、さまざまな ITLRecovery シナリオを示します。
TFTP Service Activaton:
-
TFTP サービスがアクティブになると、生成された ITL ファイルのハッシュがサーバのホスト名とともに DB に保存されます。ITL が TFTP コードで更新されるたびに更新されます。
-
TFTP ホスト名がすでにテーブルに存在する場合は、生成された ITL ハッシュが保存されている値と比較されます。
-
ITL ハッシュが同じでない場合、新しい ITL ハッシュが DB で更新されます。
-
ITL ハッシュが同じ場合、TFTP ログに「Tftp Itl hash not changed」と表示されます。
-
デバイス登録と ITLFile のダウンロード
-
電話機がUnified Communications Managerに登録されると、サーバに存在する ITLFile の詳細(サーバのホスト名、ハッシュ、タイムスタンプ)が DB に存在しません。
-
電話機がUnified Communications Managerに登録されると、電話機に適用された ITL ファイルの詳細を含む SIP アラームが送信されます。これは、DB に保存されている ITL ファイルのハッシュと比較されます。
-
ITL ハッシュが同じ場合、デバイスハッシュ情報は新しいタイムスタンプで更新されます。
-
ITL ハッシュが同じでない場合、報告された ITL ハッシュとタイムスタンプがデバイスに対して更新されます。
-
-
電話機の登録が解除されると、そのデバイスの信頼ハッシュ情報が削除されます。
連携動作と制限事項
Unified Communications Manager クラスタに 39 を超える証明書がある場合、Cisco IP 電話 上の ITL ファイル サイズが 64 キロバイトを超えます。ITL ファイル サイズが増加すると、電話での ITL の正常なロードに影響し、Unified Communications Manager での電話登録が失敗することになります。
信頼検証サービス
ネットワーク内に多数の電話機があり、Cisco Unified IP Phone のメモリも限られています。したがって、Unified Communications Manager は TVS を介してリモート信頼ストアとして動作するため、各電話機に証明書信頼ストアを配置する必要はありません。Cisco Unified IP Phone は CTL ファイルまたは ITL ファイルを使用して署名または証明書を検証できないため、検証のために TVS サーバに問い合わせることもできます。したがって、中央信頼ストアを持つことは、信頼ストアをすべての Cisco Unified IP Phone に持つよりも管理が簡単です。
TVS を使用すると、HTTPS を確立しているときに、Cisco Unified IP Phone で EM サービス、ディレクトリ、および MIDlet などのアプリケーションサーバを認証できます。
TV には、次の機能があります。
-
拡張性:Cisco Unified IP Phone のリソースは、信頼する証明書の数に影響されません。
-
柔軟性: 信頼証明書の追加または削除は、システムに自動的に反映されます。
-
デフォルトのセキュリティ:非メディアおよびシグナリングセキュリティ機能はデフォルトのインストールに含まれており、ユーザの介入は必要ではありません。
(注) |
セキュアなシグナリングおよびメディアを有効にする場合は、CTL ファイルを作成してから、クラスタを混合モードに設定する必要がありますCTL ファイルを作成し、クラスタを混合モードに設定するには、CLI コマンド utils ctl set-cluster mixed-mode を使用します。 |
TVS を説明する基本的な概念を次に示します。
-
TVS は、Unified Communications Manager サーバ 上で実行され、Cisco IP 電話に代わって証明書を認証します。
-
Cisco Unified IP Phone は、信頼できる証明書をすべてダウンロードするのではなく、TVS を信頼する必要があるだけです。
-
ITL ファイルはユーザの介入なしで自動的に生成されます。ITL ファイルは、Cisco Unified IP Phone によりダウンロードされ、信頼はそこからフローします。
認証、整合性、および許可
整合性と認証は、次の脅威から保護します。
-
TFTP ファイルの操作 (整合性)
-
電話とUnified Communications Managerとの間で行われる呼処理シグナリングの変更(認証)
-
頭字語で定義している中間者攻撃(認証)
-
電話およびサーバの ID 盗難(認証)
-
リプレイ アタック(ダイジェスト認証)
認可は、認証されたユーザ、サービス、またはアプリケーションが実行できることを指定します。1つのセッションで複数の認証方式と許可方式を実装できます。
イメージ認証
このプロセスでは、電話機にロードする前に、ファームウェアロードのバイナリイメージの改ざんを防止します。イメージが改ざんされると、電話の認証プロセスが失敗し、イメージは拒否されます。イメージ認証は、Unified Communications Manager インストール時に自動的にインストールされた署名付きバイナリ ファイルを使用して実行されます。同様に、web からダウンロードしたファームウェアアップデートにも、署名付きバイナリイメージが提供されます。
デバイス認証
このプロセスは、通信デバイスのアイデンティティを検証し、エンティティが正当なものであることを確認します。
デバイス認証は、Unified Communications Manager サーバと、サポート対象の Cisco Unified IP 電話 、SIP トランク、または JTAPI/TAPI/CTI アプリケーション(サポートされている場合)との間で発生します。これらのエンティティ間での認証済み接続は、それぞれのエンティティが相手側エンティティの証明書を受け入れた場合にのみ発生します。相互認証では、相互証明書交換のこのプロセスについて説明します。
デバイス認証は、CiscoCTL ファイルの作成(Unified Communications Manager サーバノードとアプリケーションの認証時)、および Certificate Authority Proxy Function(電話と JTAPI/TAPI/CTI アプリケーションの認証時)に依存します。
ヒント |
SIP トランク経由で接続される SIP ユーザは、CallManager 信頼ストアに SIP ユーザ エージェント証明書が含まれ、SIP ユーザ エージェントの信頼ストアに Cisco Unified Communications Manager 証明書が含まれる場合に、Cisco Unified Communications Manager で認証されます。CallManager 信頼ストアの更新の詳細については、この Unified Communications Manager リリースに対応した『Administration Guide for Cisco Unified Communications Manager』を参照してください。 |
ファイル認証
このプロセスは、電話機がダウンロードするデジタル署名されたファイルを検証します。たとえば、設定、リングリスト、ロケール、および CTL ファイルなどです。ファイルが作成後に改ざんされていないことを確認するため、電話によって署名が検証されます。サポートされるデバイスの一覧については、"電話モデルのサポート"を参照してください。
クラスタを混合モードに設定すると、TFTP サーバは、呼出音リスト、ローカライズされた ca.cnf、およびリングリスト wav ファイル (sgn 形式) などの静的ファイルに署名します。Tftp サーバは、ファイルに対してデータの変更が発生したことを確認するたびに、< デバイス名 > のファイルに署名します。
キャッシュが無効になっている場合、TFTP サーバは署名されたファイルをディスクに書き込みます。保存されたファイルが変更されたことを TFTP サーバが確認すると、TFTP サーバはファイルを再署名します。ディスク上の新しいファイルは、削除された保存済みファイルを上書きします。電話が新しいファイルをダウンロードできるようになる前に、関連するデバイスを管理者が [Unified Communications Manager] で再起動する必要があります。
電話機は、TFTP サーバからファイルを受信すると、ファイルの署名を検証することによってファイルの整合性を検証します。電話機で認証済み接続を確立するには、次の基準が満たされていることを確認します。
-
証明書が電話内に存在していること。
-
CTL ファイルが電話に存在し、そのファイルに Unified Communications Manager エントリと証明書が存在していること。
-
認証または暗号化のためにデバイスを設定しました。
シグナリング認証
シグナリング整合性とも呼ばれるこのプロセスは、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 を実行している電話の場合は、[エンドユーザ (End User)] ウィンドウでダイジェスト認証クレデンシャルを指定します。ユーザを設定した後にクレデンシャルを電話に関連付けるには、[電話の設定 (Phone Configuration)] ウィンドウでダイジェストユーザ (エンドユーザ) を選択します。電話をリセットした後、ログイン情報は TFTP サーバから電話機に提供される電話設定ファイル内に存在します。TFTP ダウンロードでダイジェストクレデンシャルがクリアテキストで送信されないようにするには、暗号化された電話設定ファイルの設定に関連するトピックを参照してください。
-
SIP トランクで受信した課題については、SIP レルムを設定します。これにより、レルムのユーザ名 (デバイスまたはアプリケーションユーザ) とダイジェストクレデンシャルが指定されます。
外部電話や SIP 実行中のトランクに対するダイジェスト認証を有効化してダイジェスト クレデンシャルを設定する場合、Unified Communications Manager によってユーザ名、パスワード、レルムのハッシュを含むクレデンシャルのチェックサムが計算されます。システムでは、MD5 ハッシュの計算に、乱数であるナンス値が使用されます。値は Unified Communications Manager によって暗号化され、ユーザ名とチェックサムがデータベースに保存されます。
チャレンジを開始するために、Unified Communications Manager では SIP 401(Unauthorized)メッセージが使用されます。このメッセージのヘッダーにはナンスとレルムが含まれています。電話またはトランクの SIP デバイスセキュリティプロファイルで、nonce の有効期間を設定します。Nonce の有効期間は、nonce 値が有効なままになる分数を指定します。この時間が経過すると、その外部デバイスは Unified Communications Manager によって拒否され、新しい番号が生成されます。
(注) |
Unified Communications Manager は SIP トランク経由で着信した、回線側の電話やデバイスから発信された SIP コールに対してはユーザ エージェント サーバ(UAS)として動作し、SIP トランクに由来する SIP コールに対してはユーザ エージェント クライアント(UAC)として動作し、回線から回線へ、またはトランクからトランクへの接続に対してはバック ツー バック ユーザ エージェント(B2BUA)として動作します。ほとんどの環境において、Unified Communications Manager は主に SCCP と SIP エンドポイントを接続する B2BUA として動作します。(SIP ユーザエージェントは、SIP メッセージを発信するデバイスまたはアプリケーションを表します)。 |
ヒント |
ダイジェスト認証では、整合性や機密性は提供されません。デバイスの整合性と機密性を確保するには、デバイスが TLS をサポートしている場合は、デバイスの TLS プロトコルを設定します。デバイスが暗号化をサポートしている場合は、デバイスセキュリティモードを暗号化として設定します。デバイスが暗号化された電話設定ファイルをサポートしている場合は、ファイルの暗号化を設定します。 |
電話のダイジェスト認証
電話のダイジェスト認証を有効化すると、キープアライブ メッセージを除き、SIP を実行中の電話に対するすべての要求に対して Unified Communications Manager はチャレンジを実施します。Unified Communications Manager は回線側電話からのチャレンジに応答しません。
応答を受信すると、Unified Communications Manager はデータベースに保存されたユーザ名のチェックサムを、応答ヘッダー内のクレデンシャルに対して検証します。
SIP を実行中の電話は Unified Communications Manager レルムに存在します。このレルムはインストール時に [Unified Communications Manager Administration] で定義されます。SIP レルムは、サービスパラメータ [SIP Station Realm] を使用して電話にチャレンジするように設定します。各ダイジェストユーザは、レルムごとに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(Unauthorized)または SIP 407(Proxy Authentication Required)メッセージを受信した場合、Unified Communications Manager はトランクを介して接続するレルムの暗号化パスワードおよびチャレンジ メッセージに指定されているユーザ名の暗号化されたパスワードをルックアップします。Unified Communications Manager によってパスワードが復号され、ダイジェストが計算され、応答メッセージ内に表現されます。
ヒント |
レルムは、SIP トランクを介して接続するドメイン (xyz.com など) を表します。これは、要求の送信元を識別するのに役に立ちます。 |
SIP レルムを設定するには、SIP トランクのダイジェスト認証に関連するトピックを参照してください。Unified Communications Manager にチャレンジを行うことができる SIP トランク ユーザ エージェントごとに、Unified Communications Manager で SIP レルム、ユーザ名、パスワードを設定する必要があります。各ユーザエージェントは、レルムごとに1セットのダイジェストクレデンシャルを持つことができます。
認証
Unified Communications Manager では、許可プロセスを使用して、SIP が実行されている電話、SIP トランク、および SIP トランクの SIP アプリケーション要求からのメッセージについて、特定のカテゴリを制限します。
-
SIP INVITE メッセージと in-dialog メッセージ、および SIP が実行されている電話の場合、Unified Communications Manager では、コーリング サーチ スペースおよびパーティションによって許可を与えます。
-
電話機からの SIP SUBSCRIBE 要求の場合、Unified Communications Manager では、プレゼンス グループへのユーザ アクセスに許可を与えます。
-
SIP トランクの場合、Unified Communications Manager では、プレゼンス サブスクリプションおよび特定の非 INVITE SIP メッセージ(Out-of-Dialog REFER、Unsolicited NOTIFY、Replaces ヘッダー付き SIP 要求など)の許可を与えます。許可された SIP 要求をウィンドウで確認する場合は、[SIP トランクセキュリティプロファイルの設定 (SIP Trunk Security Profile Configuration)] ウィンドウで承認を指定します。
SIP トランクアプリケーションの許可を有効にするには、[SIP Trunk Security Profile] ウィンドウで [Enable Application Level Authorization] チェックボックスと [Digest Authentication] チェックボックスをオンにします。次に、[Application User Configuration] ウィンドウで [allowed SIP request] チェックボックスをオンにします。
SIP トランク認証とアプリケーションレベル認証の両方をイネーブルにすると、最初に sip トランクに対して認証が行われ、次に SIP アプリケーションユーザに対して許可が行われます。トランクの場合、Unified Communications Manager では、トランクのアクセス コントロール リスト(ACL)情報をダウンロードしてキャッシュします。ACL 情報は、着信 SIP 要求に適用されます。ACL で SIP 要求が許可されていない場合、コールは403禁止メッセージで失敗します。
ACL で SIP 要求が許可されている場合、Unified Communications Manager では、[SIP Trunk Security Profile] でダイジェスト認証が有効になっているかどうかを確認します。ダイジェスト認証が無効でアプリケーションレベルの認証も無効の場合、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 に指示します。NMAP 組み込みパラレル スタブ リゾルバを使用しても DNS の処理は遅くなる可能性があるため、このオプションを使用するとスキャン時間を削減できます。
-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)ファイルが導入されました。この新機能を使用する場合は、異なるユニファイド CMクラスタ間で電話を移動する際には注意が必要です。また、移行のための適切な手順に従っていることを確認してください。
注意 |
正しい手順に従わないと、数千台の電話の ITL ファイルを手動で削除しなければならない状況が発生する可能性があります。 |
新しい ITL ファイルをサポートする Cisco IP 電話 では、Unified CM TFTP サーバからこの特別なファイルをダウンロードする必要があります。ITL ファイルが電話にインストールされると、設定ファイルおよび ITL ファイルの以降の更新では、以下のいずれかによる署名が必要となります。
-
電話機に現在インストールされている TFTP サーバ証明書
-
クラスタのいずれかで TV サービスを検証できる TFTP 証明書。ITL ファイルにリストされているクラスタ内の TV サービスの証明書を確認できます。
この新しいセキュリティ機能により、電話を別のクラスタに移動する場合に、次の 3 つの問題が発生する可能性があります。
-
新しいクラスタの ITL ファイルが現在の ITL ファイルの署名者によって署名されていないため、電話が新しい ITL ファイルや設定ファイルを受け入れることができない問題。
-
電話の既存の ITL にリストされている TVS サーバは、電話が新しいクラスタに移動すると接続できなくなる可能性があるという問題。
-
TVS サーバが証明書の検証のためにアクセス可能でも、古いクラスタ サーバには新しいサーバ証明書がない可能性があるという問題。
この 3 つの問題のうち 1 つ以上が発生した場合、考えられる解決策の 1 つは、クラスタ間を移動中のすべての電話から ITL ファイルを手作業で削除することです。ただし、この解決方法は電話の数が増えるにつれて大変な労力を必要とするため、望ましい解決策ではありません。
最も推奨されるオプションは、Cisco Unified CM エンタープライズ パラメータ [Prepare Cluster for Rollback to pre-8.0] を使用することです。このパラメータを [True] に設定すると、電話は空の TVS および TFTP 証明書セクションを含む特殊な ITL ファイルをダウンロードします。
電話に空の ITL ファイルがあると、(8.x 以前の Unified CM クラスタへの移行の場合)電話は署名のない設定ファイルをすべて受け入れます。また、(異なる Unified CM 8.x クラスタへの移行の場合)新しい ITL ファイルをすべて受け入れます。
空の ITL ファイルは、電話の
をチェックすることで確認できます。古い TVS や TFTP サーバが指定されていた場所には、空のエントリが表示されます。新しい空の ITL ファイルをダウンロードできるまで、電話には古い Unified CM サーバにアクセスできる必要があります。
古いクラスタをオンラインのままにする予定の場合は、[ Prepare cluster For Rollback to pre-8.0 ] エンタープライズパラメータを無効にして、デフォルトでセキュリティを復元します。