プロビジョニング例の概要
この章では、電話機とプロビジョニング サーバの間で設定プロファイルを転送するための手順の例を示します。
設定プロファイルの作成については、プロビジョニング スクリプトを参照してください。
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章では、電話機とプロビジョニング サーバの間で設定プロファイルを転送するための手順の例を示します。
設定プロファイルの作成については、プロビジョニング スクリプトを参照してください。
このセクションでは、電話機の基本の再同期機能をデモンストレーションします。
電話機は、設定プロファイルを取得するための複数のネットワーク プロトコルをサポートします。最も基本的なプロファイル転送プロトコルは、TFTP(RFC1350)です。TFTP は、プライベート LAN ネットワーク内のネットワーク デバイスのプロビジョニングに広く使用されています。TFTP は、インターネット経由のリモート エンドポイントの導入には推奨されませんが、小規模な組織内での導入、社内での事前プロビジョニング、および開発とテストで使用するには便利です。社内での事前プロビジョニングの詳細については、社内デバイスの事前プロビジョニングを参照してください。次の手順では、TFTP サーバからファイルをダウンロードした後、プロファイルを変更します。
ステップ 1 |
LAN 環境内で、PC と電話機をハブ、スイッチ、または小型ルータに接続します。 |
ステップ 2 |
PC に、TFTP サーバをインストールしてアクティブにします。 |
ステップ 3 |
例に示すように、テキスト エディタを使用して、GPP_A の値を 12345678 に設定する設定プロファイルを作成します。
|
ステップ 4 |
プロファイルを basic.txt の名前で TFTP サーバのルート ディレクトリに保存します。 TFTP サーバが正しく設定されていることを確認できます。電話機以外の TFTP クライアントを使用して basic.txt ファイルを要求します。プロビジョニング サーバとは異なるホストで実行されている TFTP クライアントを使用することをお勧めします。 |
ステップ 5 |
PC の Web ブラウザで admin/advanced 設定ページを開きます。たとえば、電話機の IP アドレスが 192.168.1.100 の場合は、次のようになります。
|
ステップ 6 |
タブを選択し、汎用パラメータ GPP_A ~ GPP_P の値を確認します。これらは空でなければなりません。 |
ステップ 7 |
Web ブラウザ ウィンドウで resync URL を開いて、テスト電話機を basic.txt 設定プロファイルと再同期します。 TFTP サーバの IP アドレスが 192.168.1.200 の場合、コマンドは次の例のようになります。
電話機がこのコマンドを受け取ると、アドレス 192.168.1.100 のデバイスは、IP アドレス 192.168.1.200 にある TFTP サーバに basic.txt ファイルを要求します。次に、電話機はダウンロードしたファイルを解析して、GPP_A パラメータを値 12345678 で更新します。 |
ステップ 8 |
パラメータが正しく更新されたことを確認します。PC の Web ブラウザの設定ページを更新し、 タブを選択します。これで、GPP_A パラメータに値 12345678 が含まれます。 |
電話機は、デバイスがプロビジョニング サーバと再同期するときや、再同期が完了または失敗した後に、指定された syslog サーバに syslog メッセージを送信します。このサーバを識別するには、電話機の管理 Web ページにアクセスし(電話機の Web ページへのアクセスを参照)、 を選択して、[オプションのネットワーク構成(Optional Network Configuration)] セクションの [Syslogサーバ(Syslog Server)] パラメータでサーバを識別できます。デバイスに syslog サーバの IP アドレスを設定し、残りの手順の間に生成されるメッセージを確認します。
ステップ 1 |
syslog サーバをローカル PC にインストールし、有効化します。 |
ステップ 2 |
プロファイルの Syslog_Server パラメータに PC の IP アドレスをプログラムし、変更内容を送信します。
|
ステップ 3 |
[システム(System)] タブをクリックし、ローカルの syslog サーバの値を Syslog_Server パラメータに入力します。 |
ステップ 4 |
TFTP 再同期 の説明に従って再同期操作を繰り返します。 デバイスは、再同期中に 2 つの syslog メッセージを生成します。最初のメッセージは、要求が進行中であることを示します。2 番目のメッセージは、再同期の成功または失敗を示します。 |
ステップ 5 |
syslog サーバが次のようなメッセージを受信したことを確認します。
syslog サーバの IP アドレスで(Syslog_Server パラメータではなく)Debug_Server パラメータをプログラミングし、Debug_Level を 0 ~ 3(3 が最も詳細)の値に設定すると、詳細なメッセージを使用できます。
これらのメッセージの内容は、次のパラメータを使用して設定できます。
これらのパラメータのいずれかを無効にすると、対応する syslog メッセージは生成されません。 |
デバイスは、(エンドポイントに明示的な再同期要求を送信するのではなく)定期的にプロビジョニング サーバと再同期することで、サーバ上で行われたすべてのプロファイル変更をエンドポイント デバイスに確実に伝達できます。
電話機をサーバと定期的に再同期させるためには、設定プロファイルの URL を Profile_Rule パラメータを使用して定義し、再同期期間を Resync_Periodic パラメータを使用して定義します。
電話管理の Web ページにアクセスします。電話機の Web ページへのアクセスを参照してください。
ステップ 1 |
を選択します。 |
ステップ 2 |
Profile_Rule パラメータを定義します。この例では、TFTP サーバの IP アドレスを 192.168.1.200 とします。 |
ステップ 3 |
[定期再同期(Resync Periodic)] フィールドに、30 秒など、テスト用の小さい値を入力します。 |
ステップ 4 |
[すべての変更の送信(Submit All Changes)] をクリックします。 新しいパラメータ設定で、電話機は URL で指定された設定ファイルに対して 1 分間に 2 回再同期を行います。 |
ステップ 5 |
syslog トレースで結果のメッセージを確認します(syslog を使用したメッセージの記録セクションを参照)。 |
ステップ 6 |
[リセット時の再同期(Resync On Reset)] フィールドが [はい(Yes)] に設定されます。
|
ステップ 7 |
電源を再投入して、電話機をプロビジョニング サーバと強制的に再同期させます。 サーバが応答していないなど、何らかの理由で再同期操作が失敗する場合、ユニットは([再同期エラー再試行遅延(Resync Error Retry Delay)] で設定された秒数)待機した後、再同期を再試行します。[再同期エラー再試行遅延(Resync Error Retry Delay)] が 0 の場合、電話機は再同期が失敗した後に再同期を試行しません。 |
ステップ 8 |
(オプション)[再同期エラー再試行遅延(Resync Error Retry Delay)] フィールドの値を 30 などの小さい数に設定します。
|
ステップ 9 |
TFTP サーバを無効にして、syslog 出力で結果を確認します。 |
各電話機の User_ID や Display_Name などのパラメータに個別の値を指定する必要がある導入では、サービス プロバイダーが、導入されるデバイスごとに固有のプロファイルを作成し、プロビジョニング サーバでそれらのプロファイルをホストできます。事前に決定されたプロファイルの命名規則に従って、各電話が次々に独自のプロファイルと再同期されるよう設定する必要があります。
組み込み変数のマクロ展開を使用して、プロファイルの URL シンタックスに、MAC アドレスやシリアル番号など、各電話機に固有の識別情報を含めることができます。マクロ展開によって、各プロファイル内の複数の場所でこれらの値を指定する必要がなくなります。
$MA は、ユニットの 12 桁の MAC アドレス(小文字の 16 進を使用して)に展開されます。たとえば、000e08abcdef となります。
$SN はユニットのシリアル番号に展開されます。たとえば、88012BA01234 となります。
すべての汎用パラメータ(GPP_A ~ GPP_P)を含む他の値はこの方法でマクロ展開されます。このプロセスの例については、TFTP 再同期を参照してください。マクロ展開は URL ファイル名に限定されず、プロファイル ルール パラメータの任意の部分にも適用できます。これらのパラメータは、$A ~ $P として参照されます。マクロ展開で使用可能な変数の一覧については、マクロ展開変数を参照してください。
この演習では、電話機に固有のプロファイルが TFTP サーバ上でプロビジョニングされます。
ステップ 1 |
製品ラベルから電話機の MAC アドレスを取得します(MAC アドレスは、000e08aabbcc など、数字と小文字の 16 進数を使用する数値です)。 |
ステップ 2 |
basic.txt 設定ファイル(TFTP 再同期を参照)を CP-xxxx-3PCC macaddress.cfg(xxxx はモデル番号、macaddress は電話機の MAC アドレスに置き換える)という名前の新しいファイルにコピーします。 |
ステップ 3 |
TFTP サーバの仮想ルート ディレクトリに新しいファイルを移動します。 |
ステップ 4 |
電話管理の Web ページにアクセスします。電話機の Web ページへのアクセスを参照してください。 |
ステップ 5 |
を選択します。 |
ステップ 6 |
[プロファイルルール(Profile Rule)] フィールドに
|
ステップ 7 |
[すべての変更の送信(Submit All Changes)] をクリックします。これにより、リブートと再同期がすぐに行われます。 次に再同期が実行されると、電話機は $MA マクロ式をその MAC アドレスに展開して新しいファイルを取得します。 |
HTTP は TCP 接続を確立し、TFTP は信頼性の低い UDP を使用しているため、HTTP は TFTP よりも信頼性の高い非同期メカニズムを提供します。また、HTTP サーバは、TFTP サーバに比べてフィルタリングとロギングの機能が改善されています。
クライアント側では、HTTP を使用して再同期するためにサーバに特別な設定は不要です。GET メソッドで HTTP を使用するための Profile_Rule パラメータ シンタックスは、TFTP に使用するシンタックスに似ています。標準規格の Web ブラウザが HTTP サーバからプロファイルを取得できる場合、電話機も同じ動作を実行できる必要があります。
ステップ 1 |
ローカル PC または他のアクセス可能なホストに HTTP サーバをインストールします。 オープン ソースの Apache サーバをインターネットからダウンロードできます。 |
ステップ 2 |
basic.txt 設定プロファイル(TFTP 再同期を参照)をインストールしたサーバの仮想ルート ディレクトリにコピーします。 |
ステップ 3 |
適切なサーバのインストールと basic.txt へのファイル アクセスを確認するには、Web ブラウザを使用してプロファイルにアクセスします。 |
ステップ 4 |
プロファイルが定期的にダウンロードできるようにするために、テスト用電話機の Profile_Rule を変更して TFTP サーバの代わりに、HTTP サーバを指すようにします。 たとえば、HTTP サーバが 192.168.1.300 とした場合、次の値を入力します。
|
ステップ 5 |
[すべての変更の送信(Submit All Changes)] をクリックします。これにより、リブートと再同期がすぐに行われます。 |
ステップ 6 |
電話機から送信する syslog メッセージを確認します。定期的な再同期で、HTTP サーバからプロファイルが取得されるようになります。 |
ステップ 7 |
HTTP サーバのログで、テスト用電話機を識別する情報がユーザ エージェントのログにどのように表示されるのか確認します。 この情報には、製造者、製品名、現在のファームウェア バージョン、およびシリアル番号を含める必要があります。 |
電話機ごとに(ここでは xxxx と表される)、Cisco XML の機能を介してプロビジョニングされます。
XML オブジェクトを SIP Notify パケットにより電話機に送信するか、HTTP Post を使用して電話機の CGI インターフェイス http://IPAddressPhone/CGI/Execute
に送信できます。
CP-xxxx-3PCC では、Cisco XML 機能が拡張され、XML オブジェクトを介したプロビジョニングがサポートされます。
<CP-xxxx-3PCCExecute>
<ExecuteItem URL=Resync:[profile-rule]/>
</CP-xxxx-3PCCExecute>
電話機は XML オブジェクトを受け取ると、プロビジョニング ファイルを [profile-rule] からダウンロードします。このルールでは、マクロを使用して XML サービス アプリケーションの開発を容易にできます。
複数のプロファイルがあるサーバ上のサブディレクトリは、導入された多数のデバイスを管理するのに便利です。プロファイルの URL には、次を含めることができます。
プロビジョニング サーバ名または明示的な IP アドレス。プロファイルで、プロビジョニング サーバが名前で識別される場合、電話機は DNS ルックアップを使用して名前を解決します。
サーバ名の後に標準シンタックス :port
を使用して、URL で指定される非標準サーバ ポート。
標準 URL 表記を使用して指定され、マクロ展開で管理される、プロファイルが保存されているサーバ仮想ルート ディレクトリのサブディレクトリ。
たとえば、次の Profile_Rule は、ポート 6900 の接続をリスニングしているホスト prov.telco.com で実行中の TFTP サーバに対し、サーバ サブディレクトリ /cisco/config 内のプロファイル ファイル($PN.cfg)を要求します。
<Profile_Rule>
tftp://prov.telco.com:6900/cisco/config/$PN.cfg
</Profile_Rule>
各電話機のプロファイルは汎用パラメータで識別できます。その値は、マクロ展開を使用して共通のプロファイル ルール内で参照されます。
たとえば、GPP_B が Dj6Lmp23Q
として定義されているとします。
Profile_Rule は次の値になります。
tftp://prov.telco.com/cisco/$B/$MA.cfg
デバイスが再同期されて、マクロが展開されると、000e08012345 の MAC アドレスを持つ電話機は、次の URL にデバイスの MAC アドレスを含む名前を持つプロファイルを要求します。
tftp://prov.telco.com/cisco/Dj6Lmp23Q/000e08012345.cfg
安全な通信プロセスを使用して再同期するために、電話機で以下の方法を使用できます。
基本の HTTPS 再同期
クライアント証明書認証を使用した HTTPS
HTTPS クライアントのフィルタリングとダイナミック コンテンツ
HTTPS では、リモート プロビジョニングの HTTP に SSLが追加され、以下が可能になります。
電話機はプロビジョニング サーバを認証できます。
プロビジョニング サーバは電話機を認証できます。
電話機とプロビジョニング サーバ間で交換される情報の機密性が確保されます。
SSL は、電話機とプロビジョニング サーバに事前にインストールされた公開キーと秘密キーのペアを使用して、各接続に対する秘密(対称)キーを生成し、電話機とプロビジョニング サーバ間で交換します。
クライアント側では、HTTPS を使用して再同期を可能にするためにサーバで特別な設定を行う必要はありません。GET メソッドで HTTPS を使用するための Profile_Rule パラメータ シンタックスは、HTTP または TFTP に使用するシンタックスに似ています。標準規格の Web ブラウザが HTTPS サーバからプロファイルを取得できる場合、電話機も同じ動作を実行できる必要があります。
HTTPS サーバのインストールに加えて、シスコが署名する SSL サーバ証明書は、プロビジョニング サーバにインストールする必要があります。デバイスは、サーバがシスコが署名したサーバ証明書を提供していない限り、HTTPS を使用しているサーバに再同期できません。音声製品用の署名付き SSL 証明書を作成する手順は、https://supportforums.cisco.com/docs/DOC-9852を参照してください。
ステップ 1 |
通常のホスト名変換を使って、ネットワーク DNS サーバで IP アドレスが認識されているホストに HTTPS サーバをインストールします。 オープン ソースの Apache サーバは、オープン ソースの mod_ssl パッケージとともにインストールされる際、HTTPS サーバとして動作するように設定できます。 |
ステップ 2 |
サーバ用のサーバ証明書署名要求を生成します。この手順では、オープン ソース OpenSSL パッケージまたは同等なソフトウェアのインストールが必要になる場合があります。OpenSSL を使用している場合、基本の CSR ファイルを生成するコマンドは次のとおりです。
このコマンドは公開キーと秘密キーのペアを生成します。それらのキーは privkey.pem ファイルに保存されます。 |
ステップ 3 |
CSR ファイル(provserver.csr)を署名のためにシスコに提出します。 署名されたサーバ証明書は、Sipura CA クライアント ルート証明書 spacroot.cert とともに返送(provserver.cert)されます。 詳細については、https://supportforums.cisco.com/docs/DOC-9852を参照してください。 |
ステップ 4 |
署名されたサーバ証明書、秘密キーのペア ファイル、およびクライアント ルート証明書をサーバの該当の場所に格納します。 Linux に Apache をインストールする場合、通常これらの場所は次のようになります。
|
ステップ 5 |
サーバを再起動します。 |
ステップ 6 |
basic.txt 設定ファイル(TFTP 再同期を参照)を HTTPS サーバの仮想ルート ディレクトリにコピーします。 |
ステップ 7 |
ローカル PC から標準のブラウザを使用して HTTPS サーバから basic.txt をダウンロードし、サーバの適切な動作を確認します。 |
ステップ 8 |
サーバが提供するサーバ証明書を確認します。 ブラウザがシスコをルート CA として受け入れるように事前に設定されていない限り、ブラウザはおそらく証明書を認識しません。しかしながら、電話機では証明書がこの方法で署名されるものと想定されます。 HTTPS サーバへの参照を含むようにテスト デバイスの Profile_Rule を次の例のように変更します。
この例では、HTTPS サーバの名前を my.server.com とします。 |
ステップ 9 |
[すべての変更の送信(Submit All Changes)] をクリックします。 |
ステップ 10 |
電話機から送信する syslog トレースを確認します。 syslog メッセージには、再同期で HTTPS サーバからプロファイルが取得されることが示される必要があります。 |
ステップ 11 |
(任意) 電話機のサブネットでイーサネット プロトコル アナライザを使用して、パケットが暗号化されていることを確認します。 この演習では、クライアント証明書の検証は有効化されていません。電話機とサーバ間の接続は暗号化されます。ただし、ファイル名とディレクトリの場所を知っている場合、どのクライアントでもサーバに接続してファイルを要求できるため、転送は安全ではありません。安全な再同期を行うため、クライアント証明書認証を使用した HTTPSで説明されている演習に示すように、サーバはクライアントを認証する必要もあります。 |
工場出荷時のデフォルト設定では、サーバはクライアントに SSL クライアント証明書を要求しません。どのクライアントでもサーバに接続してプロファイルを要求できるため、プロファイルの転送は安全ではありません。設定を編集してクライアント認証を有効にすることができます。サーバは接続要求を受け入れる前に電話機を認証するために、クライアント証明書が必要です。
この要件があるため、適切なクレデンシャルがないブラウザを使って再同期操作を個別にテストすることはできません。テスト用電話機とサーバ間での HTTPS 接続内での SSL キー交換は ssldump ユーティリティで確認できます。ユーティリティのトレースには、クライアントとサーバ間の相互通信が示されます。
ステップ 1 |
HTTPS サーバでクライアント証明書認証を有効にします。 |
ステップ 2 |
Apache(v.2)では、サーバ設定ファイルに次を設定します。
また、基本の HTTPS 再同期の演習で示されているように、spacroot.cert が格納されていることを確認します。 |
ステップ 3 |
HTTPS サーバを再起動し、電話機の syslog トレースを確認します。 サーバと再同期するたびに対称認証が実行されるため、サーバ証明書とクライアント証明書の両方が検証されてから、プロファイルが転送されます。 |
ステップ 4 |
ssldump を使用して、電話機と HTTPS サーバ間の再同期接続をキャプチャします。 クライアント証明書の検証がサーバで正しく有効化されている場合、ssldump トレースには、プロファイルを含む暗号化されたパケットの前に証明書が相互に交換されていることが示されます(最初にサーバからクライアントへ、次にクライアントからサーバへ)。 クライアント認証が有効な場合、有効なクライアント証明書と一致する MAC アドレスを持つ電話機のみが、プロビジョニング サーバにプロファイルを要求できます。サーバは、通常のブラウザまたはその他の不正なデバイスからの要求を拒否します。 |
HTTPS サーバがクライアント証明書を要求するよう設定されている場合、証明書の情報によって再同期している電話機を識別し、それに適切な設定情報を提供します。
HTTPS サーバは、証明書情報を、再同期要求の一部として呼び出される CGI スクリプト(またはコンパイルされた CGI プログラム)で利用可能にします。例を示す目的で、この演習ではオープン ソースの Perl スクリプト言語を使用し、Apache(v.2)が HTTPS サーバとして使用されているものとします。
ステップ 1 |
HTTPS サーバを実行しているホストに Perl をインストールします。 |
ステップ 2 |
次の Perl リフレクタ スクリプトを生成します。
|
ステップ 3 |
このファイルを reflect.pl のファイル名で HTTPS サーバの CGI スクリプトのディレクトリに、実行権限(Linux では chmod 755)で保存します。 |
ステップ 4 |
サーバ上の CGI スクリプトのアクセシビリティ(/cgi-bin/...)を確認します。 |
ステップ 5 |
次の例のように、テスト デバイスで Profile_Rule を変更し、リフレクタ スクリプトと再同期させます。
|
ステップ 6 |
[すべての変更の送信(Submit All Changes)] をクリックします。 |
ステップ 7 |
syslog トレースで、再同期が成功していることを確認します。 |
ステップ 8 |
電話管理の Web ページにアクセスします。電話機の Web ページへのアクセスを参照してください。 |
ステップ 9 |
を選択します。 |
ステップ 10 |
GPP_D パラメータに、スクリプトでキャプチャされた情報が含まれているか確認します。 テスト デバイスが製造者からの一意の証明書を保持する場合、この情報には製品名、MAC アドレス、およびシリアル番号が含まれます。ユニットがファームウェア リリース 2.0 より前に製造された場合、この情報には汎用文字列が含まれます。 同様のスクリプトによって、再同期しているデバイスに関する情報を判断してから、適切な設定パラメータ値を持つデバイスを提供できます。 |
電話機は、デバイスからプロビジョニング サーバへの HTTPS リクエストに基づく信頼性の高い安全なプロビジョニング戦略を提供します。サーバ証明書とクライアント証明書の両方が、電話機からサーバ、およびサーバから電話機の認証に使用されます。
電話機で HTTPS を使用するには、証明書署名要求(CSR)を生成して、シスコに提出する必要があります。電話機は、プロビジョニング サーバへのインストール用の証明書を生成します。電話機は、プロビジョニング サーバとの HTTPS 接続を確立しようとするときに、この証明書を受け入れます。
HTTPS は、クライアントとサーバ間の通信を暗号化して、他のネットワーク デバイスからメッセージの内容を保護します。クライアントとサーバ間の通信本文の暗号化方式は、対称キー暗号化に基づいています。対称キー暗号化では、クライアントとサーバが、公開キーまたは秘密キーの暗号化によって保護される安全なチャネルで単一の秘密キーを共有します。
秘密キーで暗号化されたメッセージは、同じキーを使用しないと復号化できません。HTTPS は、幅広い対称暗号化アルゴリズムをサポートしています。電話機には、128 ビットの RC4 に加えて、米国暗号化標準(AES)を使用した最大 256 ビットの対称暗号化が実装されています。
HTTPS では、安全なトランザクションで実行されるサーバとクライアントの認証も提供しています。この機能により、プロビジョニング サーバと各クライアントは、ネットワーク上の他のデバイスによりスプーフィングされることはありません。この機能は、リモート エンドポイントのプロビジョニングでは必須です。
サーバとクライアントの認証は、公開キーを含む証明書を使って、公開キーまたは秘密キーの暗号化により実行されます。公開キーで暗号化されたテキストは、対応する秘密キーでなければ復号化できません(その逆も同じです)。電話機は、公開キーと秘密キーの暗号化で Rivest-Shamir-Adleman(RSA)アルゴリズムをサポートします。
安全な各プロビジョニング サーバには、シスコが直接署名したセキュア ソケット レイヤ(SSL)サーバ証明書が発行されます。電話機で実行されるファームウェアは、シスコの証明書のみ有効な証明書として認識します。クライアントは HTTPS を使用してサーバに接続すると、シスコで署名されていないサーバ証明書を拒否します。
この方法により、電話機への不正アクセスや、プロビジョニング サーバをスプーフィングする試みからサービス プロバイダーを保護します。このような保護を行わないと、攻撃者は電話機を再プロビジョニングして構成情報を取得したり、別の VoIP サービスを使用する可能性があります。有効なサーバ証明書に対応する秘密キーがない場合、攻撃者は電話機との通信を確立できません。
ステップ 1 |
シスコ サポートの証明書プロセス担当者にお問い合わせください。特定のサポート担当者がいない場合は、要求を ciscosb-certadmin@cisco.com 宛てに送信してください。 |
ステップ 2 |
CSR(証明書署名要求)で使用される秘密キーを生成します。このキーは秘密キーであるため、シスコ サポートに提供する必要はありません。オープン ソース「openssl」を使用して、キーを生成します。次に例を示します。
|
ステップ 3 |
組織と場所を識別するフィールドが含まれている CSR を生成します。次に例を示します。
次の情報が必要です。
|
ステップ 4 |
CSR(zip ファイル形式)をシスコのサポート担当者または ciscosb-certadmin@cisco.com 宛てに送信してください。証明書はシスコによって署名されます。シスコは、システムにインストールする証明書を送信します。 |
電話機に対する直接攻撃に加え、攻撃者は標準規格の Web ブラウザまたは別の HTTPS クライアントからプロビジョニング サーバにアクセスを試み、プロビジョニング サーバから設定プロファイルを取得する場合があります。この種の攻撃を防ぐためには、各個々のエンドポイントに関する識別情報を含む、シスコが署名した一意のクライアント証明書を電話機でも伝送します。デバイスのクライアント証明書を認証できる認証局ルート証明書は、各サービス プロバイダに与えられます。この認証パスにより、プロビジョニング サーバは設定プロファイルの不正要求を拒否できます。
サーバ証明書とクライアント証明書を組み合わせると、リモートの電話機とそのプロビジョニング サーバ間のセキュア通信が確保されます。次の図は、シスコ クライアント、プロビジョニング サーバ、認証局における、証明書、公開キーと秘密キーのペア、および署名ルート認証局の関係と配置を示しています。
図の上半分は、個々のプロビジョニング サーバ証明書の署名に使用されるプロビジョニング サーバ ルート認証局を示しています。該当するルート証明書はファームウェアにコンパイルされ、電話機は承認されたプロビジョニング サーバを認証できます。
デジタル証明書は、ネットワーク上のネットワークデバイスとユーザを認証するために使用できます。また、ネットワーク ノード間の IPSec セッションのネゴシエートにも使用できます。
サード パーティは認証局の証明書を使用して、通信しようとしている 2 つ以上のノードを検証して認証します。各ノードが公開鍵と秘密鍵を保持します。公開キーでデータを暗号化します。秘密キーでデータを復号します。これらのノードは同じ発行元から証明書を取得しているため、互いの身元を確認できます。
デバイスは、サード パーティ認証局(CA)によって提供されるデジタル証明書を使用して IPSec 接続を認証できます。
電話機は、ファームウェアに組み込まれて事前にロードされる、次の一連のルート認証局をサポートしています。
Cisco Small Business CA 証明書
CyberTrust CA 証明書
Verisign CA 証明書
Sipura ルート CA 証明書
Linksys ルート CA 証明書
電話管理の Web ページにアクセスします。電話機の Web ページへのアクセスを参照してください。
ステップ 1 |
を選択します。 |
ステップ 2 |
[カスタムCA情報(Custom CA Info)] までスクロールし、次のフィールドを参照します。
|
このセクションでは、ダウンロードの準備として設定プロファイルの構成について説明します。機能を説明するために、ローカル PC からの TFTP を再同期方法として使用しますが、HTTP または HTTPS も使用できます。
プロファイルですべてのパラメータが個別に指定されている場合、XML 形式の設定プロファイルが非常に大きくなる場合があります。プロビジョニング サーバの負荷を減らすために、電話機は、gzip ユーティリティ(RFC 1951)がサポートするデフレート圧縮形式を使用して XML ファイルの圧縮をサポートします。
![]() (注) |
圧縮および暗号化された XML プロファイルを電話機で認識できるように、暗号化の前に圧縮を実行する必要があります。 |
カスタマイズされたバックエンド プロビジョニング サーバ ソリューションに統合するために、オープン ソース zlib 圧縮ライブラリをスタンドアロン gzip ユーティリティの代わりに使用して、プロファイルの圧縮を実行できます。ただし、電話機には有効な gzip ヘッダーを含むファイルが必要です。
ステップ 1 |
ローカル PC に gzip をインストールします。 |
ステップ 2 |
コマンド ラインから gzip を呼び出して、
これにより、デフレートされたファイル |
ステップ 3 |
TFTP サーバの仮想ルート ディレクトリに |
ステップ 4 |
次の例に示すように、テスト デバイスで Profile_Rule を変更して、元の XML ファイルの代わりにデフレートされたファイルと再同期します。
|
ステップ 5 |
[すべての変更の送信(Submit All Changes)] をクリックします。 |
ステップ 6 |
電話機から syslog トレースを確認します。 再同期するときに、電話機は新しいファイルをダウンロードしてパラメータの更新に使用します。 |
圧縮または圧縮解除されたプロファイルを暗号化することができます(ただし、ファイルは暗号化する前に圧縮する必要があります)。暗号化は、電話機とプロビジョニング サーバ間の通信に TFTP または HTTP を使用する場合など、プロファイル情報の機密性が特に重要な場合に役に立ちます。
電話機は、256 ビットの AES アルゴリズムを使用して対称キーの暗号化をサポートします。この暗号化は、オープン ソースの OpenSSL パッケージを使用して実行できます。
ステップ 1 |
ローカル PC に OpenSSL をインストールします。ここで、AES を有効にするために OpenSSL アプリケーションの再コンパイルが必要な場合があります。 |
ステップ 2 |
XML プロファイルは圧縮と暗号化の両方が可能なため、gzip によるオープン プロファイルの圧縮で作成した圧縮済み basic.txt.gz ファイルも使用できます。 |
ステップ 3 |
暗号化された basic.cfg ファイルを TFTP サーバの仮想ルート ディレクトリに保存します。 |
ステップ 4 |
テスト デバイスで Profile_Rule を変更して、元の XML ファイルの代わりに暗号化されたファイルと再同期します。暗号化キーは、次の URL オプションで電話機に認識されます。
|
ステップ 5 |
[すべての変更の送信(Submit All Changes)] をクリックします。 |
ステップ 6 |
電話機から syslog トレースを確認します。 再同期するときに、電話機は新しいファイルをダウンロードしてパラメータの更新に使用します。 |
電話機では、再同期ごとに複数の個別のプロファイルがダウンロードされます。この方法により、個別サーバに関するさまざまな種類のプロファイル情報を管理し、アカウント固有の値とは異なる共通の設定パラメータ値をメンテナンスできます。
ステップ 1 |
以前の演習とは異なる値をパラメータに指定する新しい XML プロファイル basic2.txt を作成します。たとえば、basic.txt プロファイルに次を追加します。
|
ステップ 2 |
TFTP サーバの仮想ルート ディレクトリに basic2.txt プロファイルを保存します。 |
ステップ 3 |
以前の演習で使用した最初のプロファイル ルールはフォルダに残しますが、新しいファイルを指す 2 番目のプロファイル ルール(Profile_Rule_B)を設定します。
|
ステップ 4 |
[すべての変更の送信(Submit All Changes)] をクリックします。 電話は、再同期操作の時間になるたびに、1 番目と 2 番目のプロファイルの両方に、その順序で再同期します。 |
ステップ 5 |
syslog トレースを確認して、予想される動作を確認します。 |
SIP メッセージのユーザ プライバシー ヘッダーにより、信頼されたネットワークからのユーザ プライバシーのニーズが設定されます。
ユーザ プライバシー ヘッダーの値は、config.xml ファイルで XML タグを使用して、回線の内線番号ごとに設定できます。
プライバシー ヘッダーのオプションを次に示します。
[無効(Disabled)](デフォルト)
none:ユーザは、プライバシー サービスがこの SIP メッセージにプライバシー機能を適用しないように要求します。
header:ユーザは識別情報を削除できないヘッダーを隠すためにプライバシー サービスを必要とします。
session:ユーザは、プライバシー サービスがこのセッションに匿名性を提供するように要求します。
user:ユーザは、仲介者によってのみプライバシー レベルを要求します。
id:ユーザは IP アドレスまたはホスト名を明らかにしない ID を代わりに使用するようにシステムに要求します。
ステップ 1 |
テキスト エディタまたは XML エディタで電話機の config.xml ファイルを編集します。 |
ステップ 2 |
<Privacy_Header_N_ ua="na">Value</Privacy_Header_N_> タグ(N は回線の内線番号(1 ~ 10))を挿入し、次のいずれかの値を使用します。
|
ステップ 3 |
(任意) 同じタグを使用する追加の内線を、必要な内線番号を使用してプロビジョニングします。 |
ステップ 4 |
変更内容を config.xml ファイルに保存します。 |