この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
音声およびビデオ コールの完全性と機密を保護するために、Cisco Collaboration ソリューションのさまざまなコンポーネントを保護する必要があります。
この章では、特にコラボレーション アプリケーションと音声およびビデオ ネットワークに関連したセキュリティ ガイドラインを示します。データ ネットワーク セキュリティの詳細については、次の URL で入手可能な Cisco SAFE Blueprint に関するマニュアルを参照してください。
https://www.cisco.com/c/en/us/solutions/enterprise/design-zone-security/index.html
この章のガイドラインに従うことは、安全な環境を保証するものではなく、ネットワーク上のすべての侵入攻撃を防止するものではありません。適切なセキュリティを達成するには、適切なセキュリティ ポリシーを確立し、そのセキュリティ ポリシーを適用する必要があります。また、ハッカーおよびセキュリティ コミュニティでの最新の動向を常に把握し、信頼性の高いシステム管理プラクティスにより、すべてのシステムを保守およびモニタする必要があります。
この章では、WAN 経由のクラスタリングを含む集中型呼処理と分散型呼処理について説明します。この章では、ヘッドエンド障害が発生したときに、すべてのリモート サイトが、ヘッドエンドまたはローカル呼処理バックアップへの冗長リンクを使用できることを前提としています。基本的にここでは、ネットワーク アドレス変換(NAT)と IP テレフォニーの間の対話については説明しません。この章では、すべてのネットワーク プライベート アドレスが指定されており、重複する IP アドレスが含まれていないことも前提としています。
表 4-1 に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。
|
|
|
---|---|---|
Cisco Unified Communications Manager(Unified CM)のセキュリティに関する考慮事項 |
||
この項では、ネットワーク内の音声データを保護するために使用できる、一般的なセキュリティ機能とセキュリティ プラクティスについて説明します。
シスコは、自社内に導入されている各ネットワーク テクノロジーに関連付けられたセキュリティ ポリシーを作成することを推奨します。セキュリティ ポリシーは、ネットワーク内の機密データを特定し、ネットワーク内で転送する際にはデータを適切に保護します。セキュリティ ポリシーを配置すると、ネットワーク上のデータ トラフィックのタイプで要求されているセキュリティ レベルを定義するのに役立ちます。各データ タイプで独自のセキュリティ ポリシーが必要な場合もあれば、必要でない場合もあります。
企業ネットワークにデータ用のセキュリティ ポリシーが存在しない場合、この章で任意のセキュリティ推奨事項を有効にする前に、セキュリティ ポリシーを作成する必要があります。セキュリティ ポリシーがないと、ネットワークで有効なセキュリティ機能が設計どおりに動作しているかどうかを確認することが困難になります。またセキュリティ ポリシーがないと、ネットワーク内で実行されるすべてのアプリケーションやデータ タイプに対してセキュリティを有効にする、体系的な方法がありません。
(注) この章で説明するセキュリティに関するガイドラインと推奨事項に従うのは重要ですが、実際の企業のセキュリティ ポリシーを制定するには、この章のガイドラインと推奨事項だけでは不十分です。任意のセキュリティ テクノロジーを実装する前に、社内セキュリティ ポリシーを定義する必要があります。
この章では、ネットワーク上の Unified Communications データを保護するために使用可能な、シスコ ネットワークの特徴と機能性について詳しく説明します。保護する対象のデータ、そのデータ タイプで必要な保護の程度、およびその保護を提供するのに使用するセキュリティ技法をどのように定義するかは、セキュリティ ポリシーによって異なります。
音声およびビデオ トラフィックが含まれるセキュリティ ポリシーで困難な問題の 1 つは、通常、データ ネットワークと従来の音声ネットワークの両方に存在するセキュリティ ポリシーの結合です。ネットワークへのメディア統合のすべての側面が、導入済みのセキュリティ ポリシーまたは社内環境の適切なレベルで保護されていることを確認してください。
適正なセキュリティ ポリシーの基本は、ネットワーク内でデータの重要度を定義することです。重要度に応じてデータをランク付けしたら、データ タイプごとに、セキュリティ レベルを確立する方法を決定できます。それから、ネットワークとアプリケーション機能の両方を使用して、適切なレベルのセキュリティを達成できます。
この章では最初に、Cisco Unified Communications ソリューションにおける IP Phone エンドポイントの強化を示し、電話機からアクセス スイッチ、ディストリビューション レイヤ、コア、およびデータセンターへのネットワークについて説明します。(図 4-1 を参照)。シスコは、アクセス ポートからネットワーク自体に至るまで、何層ものセキュリティを構築することを推奨します。このデザイン アプローチにより、ネットワーク アーキテクトはデバイスを配置して、そこに Cisco Unified Communications アプリケーションを物理的にも論理的にも簡単に導入できます。しかし、簡単に導入できるということは、セキュリティがより複雑になることを意味します。接続性があるところであればネットワーク内のどの場所にでも、デバイスを配置できるからです。
IP テレフォニー データがネットワークを横断するときのデータの安全性とセキュリティは、データを転送するデバイスと同程度にしかすぎません。導入済みのセキュリティ ポリシーで定義されているセキュリティ レベルによっては、ネットワーク デバイスのセキュリティを向上させる必要がある場合もあれば、IP テレフォニー トラフィックを転送するのにすでに十分に安全な場合もあります。
ネットワーク全体のセキュリティを向上させるためにデータ ネットワークで実行できる、多くのベストプラクティスがあります。たとえば、攻撃者がパスワードをクリア テキスト形式で見ることができないように、Telnet(パスワードをクリア テキスト形式で送信します)を使用して任意のネットワーク デバイスに接続する代わりに、Secure Shell(SSH、Telnet の安全な形式)を使用できます。
これらのデバイスを不正アクセスから保護するには、ファイアウォール、アクセス コントロール リスト、認証サービス、およびその他の Cisco セキュリティ ツールも使用する必要があります。
従来の PBX は、通常、安全な環境にロックされますが、IP ネットワークも同じように扱う必要があります。メディア トラフィックを伝送する各デバイスは実際には IP PBX の一部です。通常の一般的なセキュリティ プラクティスを使用して、これらのデバイスへのアクセスを制御する必要があります。ユーザまたは攻撃者が、ネットワーク内のデバイスの 1 つに物理的にアクセスできる場合、あらゆる種類の問題が発生します。強力なパスワード セキュリティがあり、ユーザまたは攻撃者がネットワーク デバイスに侵入できない場合でも、それらのユーザや攻撃者がデバイスを切断してすべてのトラフィックを停止することにより、ネットワークの大破壊を引き起こす可能性はあります。
論理的に分離された IP テレフォニー ネットワークに流入および流出するデータを制御するうえで、IP アドレッシングが重要になる場合があります。ネットワーク内で IP アドレッシングを適切に定義するほど、ネットワーク上のデバイスの制御は簡単になります。
このマニュアルの他の項で説明されているとおり(キャンパス アクセス レイヤを参照)、RFC 1918 に基づいた IP アドレッシングを使用する必要があります。このアドレッシング方式では、ネットワークの IP アドレッシングをやり直すことなく、IP テレフォニー システムをネットワークに配置できます。音声エンドポイントの IP アドレスは適切に定義されていて理解しやすいので、RFC 1918 を使用すると、ネットワーク内の制御をより適切に実行できます。音声およびビデオのエンドポイントがすべて 10.x.x.x. ネットワーク内にアドレス指定されている場合は、アクセス コントロール リスト(ACL)とこれらのデバイスが受信または送信するデータのトラックは単純になります。
音声配置のために適切に定義された IP アドレッシング プランがあると、IP テレフォニー トラフィックを制御するための ACL の書き込みが簡単になり、ファイアウォールの配置に役立ちます。
RFC 1918 を使用すると、スイッチごとに 1 つの VLAN を簡単に配置でき、Voice VLAN をスパニングツリー プロトコル(STP)ループから保護できます。スイッチごとに 1 つの VLAN を配置するのは、キャンパスの設計におけるベスト プラクティスです。
ルート集約を正しく導入すると、ルーティング テーブルを、音声およびビデオ エンドポイントの導入の前と同じ大きさか、それよりわずかに大きい程度に保つことができます。
IPv6 アドレッシングの導入により、ネットワーク アドレス空間が拡張され、エンドポイントのプライバシーとセキュリティのためのオプションが増えました。IPv4 と IPv6 の両方にセキュリティに関する同様の問題がありますが、IPv6 にはいくつかの利点があります。たとえば、IPv6 の主な利点の 1 つはサブネットのサイズが非常に大きいことであり、自動スキャンおよび偵察攻撃を阻止します。
IP アドレッシングの方式として IPv6 を検討する際は、次のキャンパスおよび支社の設計ガイドに記載されているベスト プラクティスに従ってください。
https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Campus/CampIPv6.html
https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Branch/BrchIPv6.html
この項では、ネットワーク内の音声およびデータを保護するために使用できる、アクセス レベルのセキュリティ機能について説明します。
電話機に IP アドレスが与えられる前に、電話機は、電話機とスイッチの間で実行される Cisco Discovery Protocol(CDP)ネゴシエーションを使用して、配置先として適切な VLAN を判別します。このネゴシエーションにより、電話機は「Voice VLAN」内のスイッチに対して 802.1q タグ付きのパケットを送信でき、音声データと、電話機の背後にある PC から送られる他のすべてのデータはレイヤ 2 で分離されます。Voice VLAN は電話機が動作するための要件ではありませんが、ネットワーク上の他のデータからの追加の分離を提供します。
Voice VLAN は、スイッチから電話機に自動的に割り当てることができます。これにより、レイヤ 2 およびレイヤ 3 で、音声データと、ネットワーク上の他のすべてのデータが分離されます。分離した VLAN には Dynamic Host Configuration Protocol(DHCP)サーバで別個の IP スコープを与えることができるので、Voice VLAN を使用すると、異なる IP アドレッシング スキームを実行できます。
アプリケーションは、電話機からの CDP メッセージを使用して、緊急コール中に電話機のロケーションを判別するのを支援します。電話機が接続されているアクセス ポートで CDP が有効でない場合、電話機のロケーションを判別するのは特に困難です。
通常は電話機に送られる CDP メッセージから情報が収集され、その情報が一部のネットワークを検出するために使用される可能性があります。Unified CM で音声またはビデオ用に使用可能なすべてのデバイスが、音声 VLAN の検出に CDP を使用できるわけではありません。
サードパーティ製のエンドポイントは、Cisco Discovery Protocol(CDP)または 802.1Q VLAN ID タギングをサポートしません。サードパーティ製デバイスが含まれる場合にデバイス検出を可能にするには、リンク層検出プロトコル(LLDP)を使用します。LLDP for Media Endpoint Devices(LLDP-MED)は、音声エンドポイントのサポートを向上させる LLDP の拡張です。LLDP-MED では、LLDP-MED 対応エンドポイントを検出したときに、スイッチ ポートが LLDP から LLDP-MED へどのように移行するかが定義されています。IP Phone および LAN スイッチでの LLDP と LLDP-MED 両方のサポートは、ファームウェアおよびデバイス モデルに依存します。特定の電話機またはスイッチ モデルで LLDP-MED がサポートされているかどうかを判断するには、特定の製品のマニュアル、リリース ノート、または速報を確認してください。
(注) LLDP-MED 対応の IP Phone が、LLDP をサポートしない以前の Cisco IOS リリースを実行している Cisco Catalyst スイッチに接続されると、スイッチは、余計なデバイスがスイッチ ポートに接続されていることを示す場合があります。これは、Cisco Catalyst スイッチがポート セキュリティを使用して接続デバイス数をカウントしている場合に発生します。LLDP パケットの発生により、ポート カウントが増え、スイッチがポートを無効にする場合があります。LLDP-MED リンク層プロトコルをサポートするファームウェアを持つ Cisco IP Phone を配置する前に、Cisco Catalyst スイッチが LLDP をサポートしていることを確認するか、ポート カウントを最低でも 3 に増やしてください。
サーバやクライアントがファイアウォールで分断されている場合は、それらのエンドポイントとサーバ間で TCP ポートと UDP ポートを広範囲に許可する必要があります。各製品のポート利用ガイドを参照してください。詳細については、次の Web サイトで入手可能な『 System Configuration Guide for Cisco Unified Communications Manager 』の最新版を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-installation-and-configuration-guides-list.html
ゲートウェイとサーバはインフラストラクチャ デバイスと見なされ、通常は、データセンター内で Unified CM サーバに隣接して配置されます。一方、クライアントは、データ VLAN 上に配置されるのが一般的です。
Cisco スイッチ インフラストラクチャには、データ ネットワークを保護するために使用できる多くのセキュリティ機能があります。この項では、ネットワーク内の IP テレフォニー データを保護するため、Cisco Access Switch で使用できるいくつかの機能について説明します(図 4-2 を参照)。この項では、現在のすべての Cisco スイッチで使用可能なすべてのセキュリティ機能について説明するのではなく、シスコが製造する多くのスイッチで使用されている一般的なセキュリティ機能を示します。ネットワーク内に配置された特定のシスコ デバイスで使用可能なセキュリティ機能の追加情報については、次の Web サイトで入手可能な適切な製品マニュアルを参照してください。
スイッチ ネットワークに対する典型的な攻撃は、MAC 連想メモリ(CAM)フラッディング攻撃です。このタイプの攻撃では、スイッチに対して大量の MAC アドレスによるフラッディングが実行され、スイッチは、エンド ステーションまたはデバイスが接続されているポートを判別できなくなります。デバイスが接続されているポートを判別できない場合、スイッチは、そのデバイスが宛先になっているトラフィックを VLAN 全体にブロードキャストします。これにより、攻撃者は、VLAN 内のすべてのユーザに到達するすべてのトラフィックを見ることができます。
macof などのハッカー ツールを使用した悪意のある MAC フラッディング攻撃を許可しないようにするには、それらのポートの接続性要件に基づいて、個々のポートへのアクセスを許可されている MAC アドレスの数を制限します。悪意のあるエンド ユーザ ステーションは、macof を使用して、ランダムに生成された送信元 MAC アドレスからランダムに生成された宛先 MAC アドレスへの MAC フラッディングを発信できます。送信元と宛先の両方がスイッチ ポートに直接接続されている場合もあれば、送信元と宛先が IP Phone を経由して接続する場合もあります。macof ツールは非常にアグレッシブなツールで、通常は、Cisco Catalyst スイッチの連想メモリ(CAM)テーブルを 10 秒未満でいっぱいにできます。CAM テーブルがいっぱいなので、後続のパケットは取得されないまま残され、フラッディングが発生します。これは、攻撃先の VLAN の共有イーサネット ハブ上のパケットと同じほど破壊的で危険です。
MAC フラッディング攻撃を抑制するには、ポート セキュリティまたはダイナミック ポート セキュリティのいずれかを使用できます。許可メカニズムとしてポート セキュリティを使用する必要がないカスタマーの場合、特定のポートに接続する機能に対応する数の MAC アドレスを持つダイナミック ポート セキュリティを使用できます。たとえば、1 台のワークステーションが接続されているポートの場合、取得する MAC アドレスの数を 1 に制限できます。1 台の Cisco Unified IP Phone と、その背後に 1 台のワークステーションが接続されているポートの場合、電話機の PC ポートに 1 台のワークステーションを接続するには、取得する MAC アドレスの数を 2 に設定できます(1 つは IP Phone 用、1 つは電話機の背後にあるワークステーション用)。以前であれば、トランク モードでポートを設定する旧来の方法により、この場合の設定は 3 つの MAC アドレスになります。電話機ポートの設定でマルチ VLAN アクセス モードを使用する場合、この場合の設定は 2 つの MAC アドレスになります。1 つは電話機用、1 つは電話機に接続された PC 用です。PC ポートに接続するワークステーションがない場合、そのポートの MAC アドレスの数は 1 に設定する必要があります。これらの設定は、スイッチ上のマルチ VLAN アクセス ポート用です。トランク モードに設定されているポート(電話機と PC が接続されているアクセス ポートでは推奨されていない配置)では、設定が異なる場合があります。
MAC アドレスによりポートで指定されているデバイスからのアクセスを除く、すべてのポート アクセスを防止します。これは、デバイスレベルのセキュリティ許可の 1 つの形式です。この要件は、デバイス MAC アドレスの単一のクレデンシャルを使用してネットワークへのアクセスを許可するときに使用します。ポート セキュリティ(非動的形式)を使用する場合、ネットワーク管理者は、すべてのポートに MAC アドレスを静的に関連付ける必要があります。これに対して、ダイナミック ポート セキュリティを使用する場合、ネットワーク管理者は、スイッチで取得する MAC アドレスの数を指定するだけです。その後、ポートに最初に接続するデバイスが適切なデバイスであるとの前提に基づき、一定期間、それらのデバイスにのみポートへのアクセスを許可します。
この期間は、固定タイマーまたは非活動タイマー(非持続アクセス)のいずれかで決定するか、永続的に割り当てることができます。後者の場合、スイッチのリロードまたはリブートが発生しても、取得された MAC アドレスはポートで保持されます。
デバイス モビリティに対し、スタティック ポート セキュリティまたは持続性のあるダイナミック ポート セキュリティによるプロビジョニングは行われません。最重要の要件ではありませんが、MAC フラッディング攻撃は、特定の MAC アドレスへのアクセスを制限することを目的としているポート セキュリティにより暗黙的に防止されます。
セキュリティの観点から、MAC アドレス承認を使用するのではなく、802.1x に基づいてポート アクセスを認証して承認するより強力なメカニズムがあります。MAC アドレスだけでは、ほとんどのオペレーティング システムで簡単にスプーフィングまたは偽造されます。
ポート セキュリティは、攻撃者がスイッチの CAM テーブルに対してフラッディングを実行したり、すべての受信トラフィックをすべてのポートに送信するハブに VLAN を転送したりするのを防止します。また、エンドポイントにハブまたはスイッチを追加することにより、認可されていないネットワークの拡張を防止します。ポート セキュリティは 1 つのポートでの MAC アドレスの数を制限するので、ポート セキュリティを、IT で作成されたネットワークへのユーザ拡張を抑制するためのメカニズムとして使用することもできます。たとえば、ユーザ方向のポート、または単一の MAC アドレス用にポート セキュリティが定義された電話機のデータ ポートに、ユーザがワイヤレス アクセス ポイント(AP)を接続した場合、ワイヤレス AP 自体がその MAC アドレスを占有し、背後にあるデバイスはネットワークにアクセスできません。(図 4-3 を参照)。一般的に、MAC フラッディングを停止するのに適切な設定は、不正アクセスを抑制するためにも適切です。
図 4-3 MAC アドレス数の制限による不良ネットワーク拡張の防止
MAC アドレスの数が正しく定義されていないと、ネットワークへのアクセスが拒否されたり、エラーによりポートが無効化されてすべてのデバイスがネットワークから削除されたりする場合があります。
Dynamic Host Configuration Protocol(DHCP)スヌーピングは、承認されていない DHCP または不正な DHCP サーバがネットワーク上で IP アドレスを分配するのを防止します。具体的には、ポートが応答することが許可されている場合を除き、DHCP 要求へのすべての応答をブロックします。ほとんどの電話機配置では DHCP を使用して複数の電話機に IP アドレスを提供しているので、スイッチで DHCP スヌーピング機能を使用して、DHCP メッセージングを保護する必要があります。不正な DHCP サーバは、クライアントからのブロードキャスト メッセージに応答して不正な IP アドレスを分配したり、IP アドレスを要求しているクライアントを混乱させたりすることを試行できます。
DHCP スヌーピングを有効にすると、デフォルトでは、VLAN のすべてのポートが、信頼されていないポートとして扱われます。信頼されていないポートとは、予約済みの DHCP 応答を行うことが許可されていない、ユーザ方向のポートのことです。信頼されていない DHCP スヌーピング ポートが DHCP サーバ応答を行うと、ブロックされて応答されません。このように、不正な DHCP サーバが応答することが防止されます。ただし、正当に接続された DHCP サーバまたは正当なサーバへのアップリンクは、信頼する必要があります。
図 4-4 は、DHCP サーバに IP アドレスを要求するネットワーク接続デバイスの通常の操作を示しています。
ただし、攻撃者は、単一の IP アドレスではなく、VLAN 内で使用可能なすべての IP アドレスを要求できます(図 4-5 を参照)。これは、ネットワークへのアクセスを試みている正当なデバイスのための IP アドレスが存在しないことを意味します。IP アドレスがないと、電話機は Unified CM に接続できません。
図 4-5 攻撃者は VLAN で使用可能なすべての IP アドレスを取得できる
Gobbler などのツールを使用した DHCP アドレス スコープ スターベーション攻撃は、DHCP サービス拒否(DoS)攻撃を仕掛けるために使用されます。Gobbler ツールは、ランダムに生成される異なる送信元 MAC アドレスから DHCP 要求を実行するので、ポート セキュリティを使用して MAC アドレスの数を制限することにより、Gobbler ツールが DHCP アドレス空間をスタービングするのを防止できます(図 4-6 を参照)。ただし、高度な DHCP スターベーション ツールでは、1 つの送信元 MAC アドレスから DHCP 要求を実行でき、DHCP ペイロード情報も多様です。DHCP スヌーピングを有効にすると、信頼されていないポートで、送信元 MAC アドレスと DHCP ペイロード情報が比較され、それらが一致しない場合は要求が失敗します。
図 4-6 DHCP スヌーピングを使用した DHCP スターベーション攻撃の防止
DHCP スヌーピングにより、任意の単一デバイスが特定範囲内のすべての IP アドレスをキャプチャすることを防止できますが、この機能が正しく設定されていないと、認定ユーザの IP アドレスが拒否される場合があります。
DHCP スヌーピングには、DHCP サーバから正常に IP アドレスを取得する、信頼されていないポートの DHCP バインディング情報を記録するという機能もあります。バインディング情報は、Cisco Catalyst スイッチ上のテーブルに記録されます。DHCP バインディング テーブルには、各バインディング エントリの IP アドレス、MAC アドレス、リース長、ポート、および VLAN 情報が格納されます。DHCP スヌーピングから取得されたバインディング情報は、DHCP サーバで設定された DHCP バインディング期間(つまり、DHCP リース時間)の間、有効です。DHCP バインディング情報は、ARP 応答を、DHCP でバインディングされているアドレスに限定する目的で、ダイナミック ARP インスペクション(DAI)の動的エントリを作成するときに使用されます。DHCP バインディング情報は、IP パケットの送信元を、DHCP でバインディングされたアドレスに限定するために、IP ソース ガードでも使用されます。
DHCP スヌーピングのために各タイプのスイッチに格納できるバインディング テーブル エントリには、最大制限があります(この制限を特定するには、スイッチの製品マニュアルを参照してください)。スイッチのバインディング テーブル内のエントリ数が気になる場合は、バインディング テーブルのエントリがより早くタイムアウトになるように、DHCP 範囲のリース時間を短縮できます。リースが期限切れになるまで、これらのエントリは DHCP バインディング テーブルに残されます。言い換えると、エンド ステーションがそのアドレスを持っていると DHCP サーバが判断する限り、これらのエントリは DHCP スヌーピング バインディング テーブルに残されます。ワークステーションまたは電話機を切断しても、これらのエントリはポートから除去されません。
Cisco Unified IP Phone がポートに接続されており、それを別のポートに移動した場合、DHCP バインディング テーブルには、同じ MAC アドレスと IP アドレスを持つがポートが異なっている 2 つのエントリが含まれることがあります。この動作は、通常の動作と見なされます。
ダイナミック アドレス解決プロトコル(ARP)インスペクション(DAI)は、ルータのスイッチに接続されたデバイスに対する Gratuitous ARP 攻撃を防止するために、スイッチで使用される機能です。ダイナミック ARP はすでに説明した電話機の Gratuitous ARP 機能と似ていますが、LAN 上のすべてのデバイスを保護するので、単なる電話機の機能ではありません。
基本的な機能である Address Resolution Protocol(ARP)を使用すると、ステーションで MAC アドレスを ARP キャッシュ内の IP アドレスにバインドできるようになり、これにより 2 つのステーションが LAN セグメント上で通信可能になります。ステーションは、ARP 要求を 1 つの MAC ブロードキャストとして送出します。要求に含まれる IP アドレスを所有するステーションは、要求元のステーションに、ARP 応答を(IP アドレスと MAC アドレスと共に)送ります。要求元のステーションは、その応答を、ライフタイムの制限がある ARP キャッシュにキャッシュします。ARP キャッシュのデフォルトのライフタイムは、Microsoft Windows では 2 分間、Linux では 30 秒間、Cisco IP Phone では 40 分です。
また ARP は、Gratuitous ARP と呼ばれる機能を提供します。Gratuitous ARP(GARP)は、要求がなくても送信される ARP 応答です。通常の使用法では、MAC ブロードキャストとして送信されます。GARP メッセージを受信する、LAN セグメント上のすべてのステーションは、この非請求 ARP 応答をキャッシュに入れます。この非請求 ARP 応答により、送信者が、GARP メッセージに含まれる IP アドレスのオーナーであることが認定されます。Gratuitous ARP には、障害時に別のステーションのアドレスを引き継ぐ必要があるステーションを正当に使用します。
ただし、Gratuitous ARP は、別のステーションの身分を不正にかたること目的とした悪質なプログラムにより悪用される可能性もあります。悪質なステーションが、相互に通信しているその他の 2 つのステーションのトラフィックを自らにリダイレクトすると、GARP メッセージを送信したハッカーが中間者になります。ettercap などのハッカー プログラムは、このことを精密に行うため、GARP メッセージをブロードキャストするのではなく、「プライベートな」GARP メッセージを特定の MAC アドレスに発行します。これにより、攻撃の犠牲者は、自分のアドレスに対する GARP パケットを見ることができません。Ettercap は、プライベートな GARP メッセージを 30 秒ごとに繰り返し送信することにより、ARP ポイズニングを有効な状態に保持します。
ダイナミック ARP インスペクション(DAI)は、信頼されていない(またはユーザ報告の)ポートからのすべての ARP 要求および応答(Gratuitous または非 Gratuitous)を検査して、それらが ARP オーナーからのものであることを確認するために使用します。ARP オーナーとは、ARP 応答に含まれている IP アドレスに一致する、DHCP バインディングが置かれているポートのことです。DAI 信頼済みポートからの ARP パケットは検査されず、それぞれの VLAN にブリッジされます。
ダイナミック ARP インスペクション(DAI)では、ARP 応答または Gratuitous ARP メッセージを正当化するために、DHCP バインディングが存在している必要があります。ホストで、アドレスを取得するための DHCP が使用されていない場合、そのホストを信頼するか、ホストの IP アドレスと MAC アドレスを対応付けるために ARP インスペクション用のアクセス コントロール リスト(ACL)を作成する必要があります(図 4-7 を参照)。DHCP スヌーピングと同様に、DAI は VLAN ごとに有効化されます。すべてのポートは、デフォルトで、信頼できないポートとして定義されます。DAI で DHCP スヌーピングからのバインディング情報を活用するには、DAI を有効化する前に、VLAN で DHCP スヌーピングを有効化する必要があります。DAI を有効化する前に DHCP スヌーピングを有効化しないと、VLAN 内のいずれのデバイスも、ARP を使用して、デフォルト ゲートウェイを含む VLAN 内の他のデバイスに接続できません。その結果、VLAN 内のすべてにデバイスに対するサービスを、自ら拒否することになります。
図 4-7 DHCP スヌーピングおよび DAI を使用した ARP 攻撃の防止
DAI のユーザにとって DHCP スヌーピング バインディング テーブルは重要なので、バインディング テーブルのバックアップを取ることは重要です。DHCP スヌーピング バインディング テーブルは、ブートフラッシュ、ファイル転送プロトコル(FTP)、リモート コピー プロトコル(RCP)、スロット 0、およびトリビアル ファイル転送プロトコル(TFTP)にバックアップできます。DHCP スヌーピング バインディング テーブルをバックアップしないと、スイッチのリブート中に、Cisco Unified IP Phone でデフォルト ゲートウェイとのコンタクトが失われる場合があります。例として、DHCP スヌーピング バインディング テーブルをバックアップせず、インラインパワーの代わりに電源アダプタを使用して Cisco Unified IP Phone を使用している場合を想定します。この場合、リブートの後にスイッチがバックアップされると、電話機用の DHCP スヌーピング バインディング テーブル エントリが存在しないので、電話機はデフォルト ゲートウェイと通信できません。これを回避するには、DHCP スヌーピング バインディング テーブルのバックアップを取り、電話機からトラフィックが流れはじめる前に古い情報をロードする必要があります。
この機能が正しく設定されていないと、認定ユーザへのネットワーク アクセスが拒否される場合があります。DHCP スヌーピング バインディング テーブルにデバイスのエントリがない場合、そのデバイスでは、ARP を使用してデフォルト ゲートウェイに接続できず、そのためトラフィックを送信できません。固定 IP アドレスを使用する場合、これらのアドレスを DHCP スヌーピング バインディング テーブルに手動で入力する必要があります。リンクがダウンのときに、DHCP を再度使用して IP アドレスを取得することをしないデバイスがある場合(一部の UNIX または Linux マシンはこのように動作します)、DHCP スヌーピング バインディング テーブルをバックアップする必要があります。
802.1X 認証機能は、Cisco Unified IP Phone のデバイス クレデンシャルの、ネットワークへのアクセス権を与える前に行う識別と検証に使用できます。802.1X は、エンド デバイスと RADIUS サーバの間の相互作用を行う MAC 層プロトコルです。このプロトコルは、Extensible Authentication Protocol(EAP)over LAN(EAPOL)をカプセル化し、エンド デバイスとスイッチの間での認証メッセージの転送を行います。802.1X 認証プロセスでは、Cisco Unified IP Phone は、802.1X サプリカントとして機能し、ネットワークにアクセスするための要求を開始します。オーセンティケータとして機能する Cisco Catalyst スイッチは、その要求を認証サーバに渡し、その電話にネットワークへのアクセスを許可するかまたはその電話からのアクセスを制限するかのいずれかを行います。
802.1X は、Cisco Unified IP Phone に接続されているデータ デバイスの認証にも使用できます。Cisco Unified IP Phone では EAPOL パススルー メカニズムが使用され、これによって、ローカルに接続された PC が 802.1X オーセンティケータに EAPOL メッセージを渡すことが可能になります。音声 VLAN 上の 1 つのデバイスとデータ VLAN 上の複数の認証されたデバイスに許可を与えるには、Cisco Catalyst スイッチのポートをマルチ認証モードで設定する必要があります。
(注) 接続されているデータ デバイスを認証するよりも前に IP フォンを認証することを推奨します。
マルチ認証モードでは、アクセスが承認されたときに認証サーバから返された属性に基づいて、認証されたデバイスをデータ VLAN か音声 VLAN のいずれかに割り当てます。802.1X ポートは、データ ドメインと音声ドメインに分けられます。
マルチ認証モードでは、802.1x ポート上でゲスト VLAN を有効にできます。スイッチは、認証サーバがその EAPOL ID フレームへの応答を受信しなかった場合、およびクライアントが EAPOL パケットを送信しなかった場合に、エンド クライアントをゲスト VLAN に割り当てます。これにより、Cisco IP Phone に接続されていて 802.1X をサポートしていないデータ デバイスをネットワークに接続することが可能になります。
スイッチ ポートがマルチ ホスト モードになっている場合は、IP フォン用に音声 VLAN を設定しなければなりません。Cisco 属性-値(AV)ペア属性を device-traffic-class=voice という値で送信するように RADIUS サーバを設定する必要があります。この値がないと、スイッチは、IP フォンをデータ デバイスとして扱います。
RADIUS サーバからのダイナミック VLAN 割り当ては、データ デバイスにしかサポートされません。
ポート上でデータ デバイスまたは音声デバイスが検出されると、その MAC アドレスは認証が成功するまではブロックされます。認証に失敗した場合、その MAC アドレスのブロックは 5 分間継続します。
音声 VLAN が設定されており、すでに Cisco IP Phone が接続されているアクセス ポート上で 802.1x 認証を有効にすると、電話が最大 30 秒間スイッチとの接続を失います。
ほとんどの Cisco IP Phone では、EAP-Transport Layer Security(EAP-TLS)を使用した X.509 証明書による認証方式、または EAP-Flexible Authentication with Secure Tunneling(EAP-FAST)の認証方式をサポートしています。いずれの方式もサポートしていない一部の古いモデルでは、Cisco Catalyst スイッチが接続しているデバイスの MAC アドレスを認証方式として確認できるようにする MAC 認証バイパス(MAB)を使用して認証できます。
802.1X 機能設定のサポートを確認するには、 https://www.cisco.com にある Cisco Unified IP Phone および Cisco Catalyst スイッチの製品ガイドを参照してください。
設定情報については、次の Web サイトで入手可能な『 IP Telephony for 802.1x Design Guide 』を参照してください。
https://www.cisco.com/en/US/docs/solutions/Enterprise/Security/TrustSec_1.99/IP_Tele/IP_Telephony_DIG.html
証明書は、シスコ コラボレーション導入でセキュアな接続を確立するために不可欠です。証明書を使用して、ネットワーク上の個人、コンピュータ、およびその他のサービスを認証することができます。証明書管理を適切に実装することにより、複雑さを軽減しながら、強力な保護を実現できます。
このセクションでは、最初に Public Key Infrastructure(PKI)の概要を示してから、一般的なガイダンスを提供します。
Public Key Infrastructure(PKI)は、通信の安全を確保し、通信する両者の ID を検証するためのメカニズムを提供します。暗号化によって通信が保護され、公開/秘密キー ペアとデジタル アイデンティティ証明書を使用して ID が検証されます。
公開キーと秘密キーのペアは、数学的に相関された、2 つの一意に関連付けられた暗号キーで構成されます。公開キーで暗号化されたデータは、対応する秘密キー(一般に公開されない)でのみ復号化できます(逆も同様です)。
デジタル証明書は、ネットワーク上の個人、コンピュータ、およびその他のサービスの ID を認証するための電子クレデンシャルです。また、公開キーのラッパーでもあります。証明書は、公開キーの所有者に関する情報を提供します。通信相手を認証する TLS ハンドシェイクなどで使用されたり、ファイルにデジタル的に署名するために使用されたりします。シスコ コラボレーション製品と一緒に展開される証明書は、X.509 標準に基づいています。証明書には、次のような情報やその他の情報が含まれています。
証明書は、自分で署名することも、認証局(CA)によって署名することもできます。
クライアントがサーバへの TLS 接続を開始すると、サーバはクライアントがサーバを認証できるように TLS ハンドシェイク中に自分の証明書を送信します。この動作は、管理者またはエンドユーザが Unified CM ページに接続したときに発生します。また、Jabber クライアントが起動して、Unified CM UDS サーバ、IM and Presence サーバ、Unity Connection サーバに接続したときなどに発生します。
サーバがクライアントを認証し、クライアントにその証明書の送信を依頼する場合もあります。これは相互認証(相互 TLS または MTLS)であり、暗号化モード(メディアとシグナリングの暗号化で設定)の Unified CM と Cisco エンドポイント間や、2 つの Unified CM クラスタを接続する SIP トランクや、Unified CM を Cisco Unity Connection、Cisco IOS ゲートウェイ、または Cisco Expressway(Expressway 上で TLS 検証が設定されている場合)に接続する SIP トランクで使用されます。
証明書の受信後の検証は、以下の項目のチェックで構成されます。
Cisco Unified CM and IM and Presence Service などの一部のサーバは、システム サービスごとに異なる証明書を保持することができます。Cisco Expressway などの一部のサーバは、自分が提供しているサービスの証明書しか保持することができません。 表 4-2 に、最も広く展開されている一部の製品のサーバ証明書を示します。ECDSA 証明書は掲載されていません。
他にも ECDSA に基づく証明書があります。詳細については、RSA と ECDSAに関するセクションを参照してください。
通常、シスコ コラボレーション サーバは、デフォルトで自己署名証明書と一緒にインストールされます。ただし、すべての製品に該当するわけではありません。たとえば、Cisco Meeting Server の場合は、デフォルトでは証明書がインストールされません。
Cisco Unified CM 自己署名証明書は 5 年間有効です。ただし、20 年間有効な ITLRecovery 証明書は除きます。この証明書はシステム全体のトラスト アンカーとして機能するため、その有効期間が長く設定されています。
通常、シスコ コラボレーション製品の証明書は、公開/秘密キーとデジタル署名用の RSA(Rivest、Shamir、and Adelman)に基づきます。一部の製品は楕円曲線デジタル署名アルゴリズム(ECDSA)証明書もサポートしており、自己署名証明書と CA 署名証明書の両方で使用できます。ECDSA 証明書と RSA 証明書の両方をサーバ上で共存させることができます。現時点では、エンドポイント上で ECDSA がサポートされていないことと、使いやすさや相互運用性を考慮すると、一般的に RSA 証明書を使用することが推奨されます。
(注) キー交換が ECDHE に基づく暗号化アルゴリズム スイートには、ECDSA に基づく証明書は必要ありません。このスイートは、RSA に基づく証明書とネゴシエートできます。
サーバのインストール時に、デフォルトで、自己署名証明書がほとんどのシスコ コラボレーション製品と一緒にインストールされます。自己署名証明書に基づいてサービスとの信頼性を確立するには、サービスへのセキュアな接続が必要なすべてのエンティティ(クライアント)の信頼できる証明書ストア(またはトラスト ストア)に、サーバの自己署名証明書をインポートする必要があります。インポートしていない場合は、接続を(Unified CM SIP トランクなどを使用して)開始するサーバを使用すると、接続に失敗します。Jabber と Web ブラウザを使用した場合は、警告メッセージが表示されますが、証明書を受け入れて信頼できる証明書ストアに追加することができます。ただし、クライアントの起動中に複数の証明書を受け入れるように何回もプロンプトが表示され、ユーザ エクスペリエンスが低下するため、この方法は使用しないでください。より重要なこととして、実際は、提示された証明書のフィンガープリントをチェックしてその証明書が正しいかどうかを検証することをほとんどのユーザは行わず、どの証明書もそのまま受け入れているのが現状です。これでは、セキュアなセッションを確立するための証明書ベースの認証のセキュリティの概念が成り立たなくなってしまいます。
通信する当事者のセットが少ない場合は自己署名証明書のインポートを処理できますが、通信ピアが多い場合は実用性に欠けます。これが、ほとんどのデフォルト自己署名証明書を CA 署名証明書に置き換えることが推奨されている主な理由です。これにより、証明書の管理が容易になります。CA 署名付き証明書を使用した場合は、クライアント トラスト ストアにそれぞれのサーバの証明書をインポートする必要がありません。代わりに、ルート CA 証明書をクライアント トラスト ストアにインポートするだけです。サーバ側では、通常、ルート CA 証明書もサーバ信頼ストアにインポートする必要があります。また、中間 CA が使用されている場合は、証明書チェーン内のすべての証明書もサーバ信頼ストアにインポートする必要があります。また、CA 署名付き証明書を使用すれば、署名する CA のルート証明書がすべてのクライアントの信頼できる証明書ストアにすでに追加されている限り、すべてのクライアントまたはサーバの信頼できる証明書ストアを更新しなくても、新しいサービス証明書を発行できます。CA 署名付き証明書は、マルチサーバ証明書を使用する場合の要件でもあります。
CA 署名付き証明書を使用するメリットの一例として、Jabber クライアントで自己署名証明書が使用されている場合は、すべてのノードの Unified CM Tomcat 証明書(UDS 用と TFTP 設定ファイルのダウンロード用)、IM and Presence Tomcat 証明書と cup-xmpp 証明書(ログインとセキュアなチャット用)、Unity Connection Tomcat 証明書(ビジュアル ボイス メール用)を Jabber を実行している各クライアントのトラスト ストアにインポートする必要があります。一方、CA 署名付き証明書を使用した場合は、署名する CA のルート証明書をインポートするだけで済みます。
一般に、自己署名証明書の代わりの CA 署名付き証明書の使用は、Tomcat 証明書に最もメリットがあります。これは、この証明書が、広く使用されている、ユーザが直接関わる証明書だからです。CallManager 証明書に CA 署名付き証明書を使用した場合もメリットがあります。これは、マルチサーバ証明書(詳細については、マルチサーバ証明書を参照)を使用することができ、SIP トランク経由で Unified CM サブスクライバに接続するすべてのエンティティのすべての CallManager 証明書をインポートする必要がないためです。
さらに、CA を使用してすべての証明書に署名する必要がありません。一部の証明書は、内部操作にのみ使用され、ユーザの介入なしに、それらを必要とするエンティティに提供されます。たとえば、Trust Verification Service(TVS)証明書は、初期信頼リスト(ITL)ファイルに保存されており、エンドポイントの起動、再起動、またはリセット時に自動的にダウンロードされます。同様に、ITL 回復証明書は、証明書信頼リスト(CTL)と初期信頼リスト(ITL)に含まれています。つまり、外部 CA を使用してこれらの証明書に署名するメリットはありません。また、外部 CA によって CAPF 証明書に署名しても、実質的なメリットはありません。認証局プロキシ機能(CAPF)証明書またはエンドポイントのローカルで有効な証明書(LSC)の失効はサポートされません。また、電話機 VPN または 802.1 x を設定する場合は、ASA または RADIUS サーバのトラスト ストアにルート CA 証明書をインポートするだけでは不十分です。TLS ハンドシェイク中はエンドポイントが証明書チェーンを送信しない(そのため、CAPF 証明書が送信されない)ため、CAPF 証明書も引き続きインポートする必要があります。
表 4-3 に、CA によって署名するように推奨されている証明書を示します。
証明書の管理をさらに容易にするために、マルチサーバ証明書を使用することができます。ノードごとに証明書を使用する代わりに、クラスタ内のすべてのノード全体で 1 つの CA 署名証明書を使用することができます。1 つの対応する秘密キーもすべてのノードで使用され、自動的にノード全体に伝播されます。マルチサーバ証明書でカバーされるサーバは、サブジェクト代行名(SAN)拡張機能で一覧表示されます。マルチサーバ証明書を実装するには、導入でサードパーティ CA を使用する必要があります。
表 4-4 に示すように、可能な場合はマルチサーバ証明書の使用をお勧めします。
|
|
|
---|---|---|
1 つのクラスタ内のすべての Unified CM および IM and Presence ノード全体で 1 つの Tomcat 証明書。証明書署名要求(CSR)を生成し、Unified CM パブリッシャ ノードに CA 発行証明書をアップロードします。 |
||
(注) ワイルドカード証明書は、通常、シスコ コラボレーション製品ではサポートされません。
Expressway-E 証明書にパブリック CA を使用するという要件に加えて、パブリック CA またはエンタープライズ CA(プライベート CA または内部 CA)を使用して、このドキュメント内のシスコ コラボレーション製品のさまざまな証明書に署名することもできます。パブリック CA を使用するメリットには、一部のクライアントとサーバがデフォルトで主要なパブリック CA をすでに信頼しているために、これらのデバイスとパブリック CA 間で信頼を確立する(CA 証明書をクライアント トラスト ストアにインポートする)必要がないという事実が含まれます。パブリック CA を使用すれば、IT 組織も内部 CA サーバを設置して維持する必要がありません。ただし、パブリック CA の主な欠点は、証明書を発行するコストと、一部のパブリック CA で課される制限です。
お勧めは、パブリック CA によって署名される必要がある Expressway-E 証明書と、SIP サービス プロバイダーが暗号化をサポートしている場合の Cisco Unified Border Element 証明書を除いて、 表 4-2 内のすべての証明書に対してエンタープライズ CA を使用することです。詳細については、 https://www.cisco.com/go/pa にある『 Preferred Architecture for Cisco Collaboration Enterprise On-Premises Deployments CVD 』の最新版の「 Security 」の章を参照してください。
内部ネットワークを越えて拡張するサービスが増えていることと、内部ネットワークが内部からの攻撃に晒される場合があることから、暗号化と認証がますます不可欠になりつつあります。
暗号化は、盗聴、改ざん、セッション リプレイなどの攻撃から保護します。権限のないユーザがトラフィックをキャプチャすることができても、暗号化キーを知らなければ、暗号化された通信の内容を復号化したり、変更したりすることができません。また、暗号化は、暗号化された通信のセットアップ時にデジタル証明書経由の認証も提供します。認証は、一方向の認証にすることができます。たとえば、管理者またはエンドユーザが Web ブラウザを使用して Web サービスにアクセスする場合です。この場合は、クライアント(ブラウザ)が Web サーバを認証しますが、サーバはクライアント(ブラウザ)を認証しません。または、相互 TLS(MTLS)を使用して認証を双方向にすることができます。この場合は、サーバもクライアントを認証します。MTLS は、エンドポイントとそれが登録されている Unified CM サーバ間のシグナリングや Unified CM SIP トランクなどで使用されます。
Transport Layer Security(TLS)は、TCP トラフィックを暗号化するための方式で、Web サービス トラフィックや SIP シグナリングに広く使用されています。以下の手順は、TLS セッションの確立方法に関する概要を示しています。
1. TLS 接続が、TLS サーバに接続する TLS クライアントによって開始されます。クライアントは、最初に、乱数とその機能を含む Client Hello を送信して、サーバとの TCP 接続を確立します。これらの機能には、クライアントがサポートしている暗号スイートのリストが含まれます。
2. TLS サーバは、通常、クライアントの暗号スイートの設定を考慮して暗号スイートの 1 つを選択し、Server Hello で応答します。このメッセージには、クライアントが認証できるように、別の乱数とサーバ証明書も含まれています。
図 4-8 に、TLS セッションを確立するためのこの 2 つの手順を示します。簡略化するため、この図には TLS ハンドシェイクのすべてのメッセージと可能性のあるバリエーションが含まれているわけでありません。サーバ証明書は、Server Hello メッセージで送信することも、別に送信することもできます。
相互 TLS(MTLS)を使用すると、サーバもクライアントを認証します。サーバは、CertificateRequest をクライアントに送信し、クライアントからクライアント証明が送信されます。図 4-9 に、このフローの概要を示します。
RSA を使用する場合は、クライアントがプリマスター シークレットをサーバの公開キーで暗号化して、サーバに送信します。Diffie-Hellman(DH)キー合意アルゴリズムを使用する場合は、プリマスター シークレットがネットワーク経由で送信されません。代わりに、クライアントとサーバが自力でプリマスター シークレットを抽出できるように、クライアントとサーバがデータ(乱数から計算され、認証用の秘密キーによって署名された)を交換します。DH と変化する乱数を組み合わせること(Diffie-Hellman Ephemeral)により、Perfect Forward Secrecy(PFS)が可能になります。
そうすれば、マスター シークレットが抽出され、セッション キーがマスター シークレットから計算されます。この時点から、クライアントとサーバが公開/秘密キーのペアの使用(非対称暗号化)を停止して、暗号化用の共有セッション キーの使用(対称暗号化)を開始します。
TLS は、セキュアなさまざまな通信リンクを保護するために使用されます。たとえば、SIP または Skinny Client Control Protocol(SCCP)シグナリングを保護するために使用されます。
現在のシスコ コラボレーション製品の多くが TLS バージョン 1.2 をサポートしています。これらの製品を使用すれば、TLS 1.0 と TLS 1.1 もサポートしていたとしても、TLS バージョン 1.2 が常にネゴシエートされるはずです。セキュリティやコンプライアンスの観点から、管理者は TLS のバージョンを 1.2 に固定し、TLS 1.0 と TLS 1.1 を無効にすることもできます。これは、多くのシスコ コラボレーション製品で行うことができます。この機能を備えた製品の一覧については、次の場所にある『 TLS 1.2 Compatibility Matrix for Cisco Collaboration Products 』を参照してください。
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/uc_system/unified/communications/system/Compatibility/TLS/TLS1-2-Compatibility-Matrix.html
また、TLS 1.2 のサポートと、TLS 1.0 または 1.1 の無効化の詳細については、次の場所にある『 TLS 1.2 for On-Premises Cisco Collaboration Deployments 』の最新版を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-system/products-configuration-examples-list.html
クレジットカード データ保護基準(PCI DSS)にも、TLS のバージョンに関する要件があります。詳細については、 https://www.cisco.com/go/collabpci を参照してください。
Cisco Unified CM と他のシスコ コラボレーション製品は、Linux OS に基づいて強化されたアプライアンスと同じプラットフォーム運用に基づいており、次のようなデフォルトの機能と制限があります。
SELinux ソフトウェアは、サーバとの間のトラフィックの動作と、サーバ上でアプリケーションが実行される方法を調べて、すべてが正常かどうかを判別するポリシーを実行します。異常と見なされるものが見つかった場合、SELinux アクセス ルールは、そのアクティビティが発生するのを防ぎます。
DoS 保護のための接続レート制限、および特定のポートをブロックするネットワーク シールドは、IPTables を使用して設定されます。ホストベースのファイアウォール設定には、Cisco Unified Communications サーバの [Operating System Administration] ページを使用してアクセスできます。
管理者は、SELinux をディセーブルにできませんが、許可モードに設定できます。厳密にトラブルシューティングの目的のためだけに許可モードにする必要があります。SELinux をディセーブルにするにはルート アクセスが必要で、Cisco Technical Assistance Center(TAC)からのリモート サポートによってのみ実行できます。
Unified CM を初めてインストールすると、「非セキュア モード」と呼ばれる状態になります。ほとんどのセキュリティ機能が実際にこのモードで利用可能であっても、そのように呼ばれます。たとえば、署名された TFTP 設定ファイル、暗号化された TFTP 設定ファイル、署名された電話ファームウェア、Web サービスへの HTTPS アクセス、ローカルで有効な証明書(LSC)をインストールするための CAPF 登録、SIP トランク暗号化、電話 VPN、802.1x のすべてをデフォルトで非セキュア モードの Unified CM で使用することができます。欠けている 1 つのセキュリティ機能がエンドポイント用のメディアとシグナリングの暗号化です。これを有効にするには、Unified CM を混合モードに設定する必要があります。そのためには、Unified CM をソフトウェアの米国輸出制限バージョンを使用してインストール(Unified CM の無制限バージョンではメディアとシグナリングの暗号化が使用できない)し、エクスポート制御機能を使用してシスコ スマート ソフトウェア ライセンスの登録トークンを作成する必要があります。
これは、混合モードを有効するための従来の方法です。この方法では、最低でも 2 つのハードウェア USB eToken(KEY-CCM-ADMIN-K9= または新しい KEY-CCM-ADMIN2-K9=)が必要です。1 つの eToken は、証明書信頼リスト(CTL)ファイルの署名に使用されます。もう 1 つの eToken は、最初の eToken が失われたまたは使用できなくなった場合に冗長性を提供します。混合モードを有効にするには、CTL クライアント ソフトウェアを Microsoft Windows デスクトップにインストールする必要があります。この CTL クライアント ソフトウェアの動作中に、USB eToken をデスクトップに挿入する必要があります。混合モードの設定が完了すると、Unified CM クラスタ用の CTL ファイルが作成され、USB eToken が削除され、オフラインにされます。
この方法では、USB トークンや Microsoft Windows デスクトップが必要ありません。混合モードが CLI コマンド utils ctl set-cluster mixed-mode を介して簡単に有効になります。CTL ファイルは、ハードウェア USB eToken によって署名されませんが、Unified CM ITLRecovery 秘密キーによって署名されます。
トークンレス方式は、一般に推奨されており、次のようなメリットがあります。
– 混合モードの有効化と CTL ファイルの更新が容易です。混合モードを有効にするときや CTL ファイルを更新するときに、USB eToken を取得したり、Microsoft Windows デスクトップに CTL クライアントをインストールしたり、CTL クライアントを実行したりする必要がありません。1 つの CLI コマンドを発行する必要があるだけです。
– トークンレス方式では、CTL ファイルを署名するキーが長くなります。
– TLS 1.0 および 1.1 は、トークンレス オプションを使用して Unified CM 上で無効にすることができます。USB ハードウェア eToken を使用した場合は、CTL クライアントが TLS 1.1 または 1.2 をサポートしないため、TLS 1.0 を許可する必要があります。
Cisco Unified CM 12.0 以降では、トークンレス CTL ファイル(および ITL ファイル)が ITLRecovery 秘密キーによって署名されるため、CallManager 証明書の更新がもはや懸案材料ではなく、エンドポイントと Unified CM 間の信頼が失われないことに注意してください。
証明書信頼リスト(CTL)と初期信頼リスト(ITL)は、Unified CM 証明書を含むファイルです。これらのファイルは、Cisco エンドポイントの起動、再起動、リセット時にダウンロードされます。これらの信頼リストを使用して、エンドポイントは、Unified CM サービスに対する信頼を構築するための Unified CM 証明書の最小セットを取得することができます。ITL ファイルは、Unified CM クラスタが非セキュア モードなのか混合モードなのかに関係なく、Unified CM クラスタ内に存在します。ただし、CTL ファイルは、Unified CM が混合モードの場合にのみ存在し、関連付けられます。
CTL ファイルと ITL ファイルは、システム管理者セキュリティ トークン(SAST、 表 4-5 を参照)によって署名され、レコードのリストが保存されます。各レコードには、エンドポイントが容易に検索を行えるように、証明書、証明書の役割または機能、事前に抽出された証明書フィールドが含まれています。 表 4-5 に、証明書の役割を示します。
ITL は ITLRecovery 秘密キーによって署名されます。TFTP サービスを実行している Unified CM ノードごとに、エンドポイントに提供される個別の ITL ファイルが割り当てられます。
CTL ファイルは、システム管理者セキュリティ トークン(SAST)の秘密キーによって署名されます。トークンレス CTL を使用する場合は、SAST が ITLRecovery 秘密キーになります。Unified CM クラスタ全体で共有される CTL ファイルは 1 つだけです。
Unified CM が混合モードの場合は、エンドポイントを起動またはリセットすると、その設定ファイルがダウンロードされる前に、TFTP サーバから証明書信頼リスト(CTL)がダウンロードされます。ITL がエンドポイントによってサポートされている場合は、その後で、TFTP サーバの初期信頼リスト(ITL)がダウンロードされます。ほとんどの Cisco エンドポイントは、いくつかの稀な例外(主な例外は Jabber)を除いて、ITL ファイルをサポートします。エンドポイントが新しく展開され、エンドポイントが初めて Unified CM に接続した場合は、既存の CTL ファイルまたは ITL ファイルが存在しないため、CTL 署名または ITL 署名の検証に使用可能な証明書のリストも存在しません。その場合は、エンドポイントが、根拠はないものの 1 回だけ CTL/ITL ファイルを信用して受け入れ、それらのファイルの一部である証明書を保存します。エンドポイントに証明書の信頼できるリストが存在する場合は、それらを使用して、ダウンロードされる後続の CTL ファイルと ITL ファイルの署名を検証することができます。
エンドポイントが ITL をサポートしている場合または Unified CM が混合モード(エンドポイントによって CTL ファイルがダウンロードされる)の場合は、エンドポイントが ITL/CTL ファイルからの CallManager 証明書を所有しているため、Unified CM TFTP サーバ上で CallManager 秘密キーによって署名された設定ファイルを要求します。そうでない場合(Jabber を使用している場合や Unified CM が混合モードでない場合)は、署名されていない設定ファイルを要求します。その設定ファイルをダウンロードすると、エンドポイントは、正しいファームウェアが含まれているかどうかを確認します。正しいファームウェアが含まれていない場合は、該当するファームウェアをダウンロードして、その署名を検証し、それが改ざんされていないことを確認します。図 4-10 に、エンドポイントの起動時にダウンロードされるファイルを示します。
図 4-10 起動中にエンドポイントによってダウンロードされるファイル
TFTP 設定ファイルの暗号化を使用しない場合は、任意の Unified CM TFTP サーバから TFTP 設定ファイルをプレーン テキスト形式で入手できます。TFTP 設定ファイルから入手可能な情報の種類には、電話ファームウェア情報や Unified CM クラスタに関する情報などが含まれます。さらに重要なことは、Unified CM Administration の電話ページでユーザ名とパスワードがプロビジョニングされた場合は、それらも TFTP 設定ファイルにプレーン テキストで保存されることです。したがって、一般的な推奨事項は、TFTP 設定ファイルの暗号化を有効にすることです。このことは、ユーザ名、パスワード、機密情報が Unified CM Administration の電話ページで設定される場合に特に重要です。
ただし、モバイルおよびリモート アクセス(MRA)エンドポイントを使用し、TFTP 設定ファイルの暗号化が設定されている場合は、MRA エンドポイントが、MIC を所有している場合でも、インターネットに展開されたり MRA 経由で接続されたりする前に、オンプレミスに展開されてから Unified CM に直接登録される必要があります。さらに、Jabber を使用している場合、エンドポイントはリセットされると、暗号化された設定ファイルを取得できなくなり、社内ネットワーク内に戻されるまで登録できなくなります。このような理由で、MRA 経由で接続しているエンドポイントの場合、特に、MRA 経由で接続している Jabber エンドポイントの場合は、TFTP 設定ファイルの暗号化を有効にしない方が簡単です。ただし、このようなエンドポイントに対して機密情報が設定されていないことを確認してください。結論として、このような MRA エンドポイントの場合は TFTP 設定ファイルの暗号化を無効にして(かつパスワードをプロビジョニングせず)、社内ネットワーク内のエンドポイントの場合は TFTP 設定ファイルの暗号化を有効にすることをお勧めします。これは、オンプレミス エンドポイントの場合は TFTP 設定の暗号化が有効になっている電話セキュリティ プロファイルを使用し、モバイルおよびリモート アクセス(MRA)経由で接続しているエンドポイントの場合は TFTP 設定が無効になっている別の電話セキュリティ プロファイルを使用することによって実現されます。
Cisco IOS SRST は、Unified CM クラスタから離れたロケーションにあるエンドポイントに、可用性の高い呼処理サービスを提供します。エンドポイントが Unified CM 呼処理サーバとの通信を確立できない場合は、ローカル SRST ルータに登録されます。SRST は、非セキュアにもセキュアにも設定することができます。SRST がセキュアとして設定されている場合は、Unified CM で暗号化モードに設定されたエンドポイントが SRST ルータに登録したときにメディアとシグナリングが暗号化されます。
セキュア SRST が Unified CM で設定されると、Unified CM がデフォルトでポート 2445 の TLS 接続を介して SRST ルータ内の証明書プロバイダー サービスに接続し、SRST ルータの証明書を取得します。この証明書は、エンドポイントが SRST にフェールオーバーしたときに、SRST ルータを正しく認証できるように、エンドポイント TFTP 設定ファイルに追加されます。SRST ルータもエンドポイントを認証します。そのため、エンドポイント証明書に署名したエンティティの証明書を SRST 信頼ストアにインポートする必要があります。LSC 証明書がエンドポイントにインストールされており、CAPF によって署名されている場合は、CAPF 証明書を SRST 信頼ストアにインポートする必要があります。代わりに、電話機で MIC 証明書が使用されている場合は、Cisco Manufacturing 証明書を SRST 信頼ストアにインポートする必要があります。
詳細については、次の場所にある『 Cisco Unified SCCP and SIP SRST System Administrator Guide 』の最新版を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-survivable-remote-site-telephony/products-installation-and-configuration-guides-list.html
Cisco Unified IP Phone には、IP テレフォニー ネットワーク上のセキュリティを強化するための組み込み型の機能があります。これらの機能を電話機単位で有効または無効にして、IP テレフォニー配置のセキュリティを強化できます。セキュリティ ポリシーは、電話機の配置に応じて、これらの機能を有効にする必要があるかどうか、および有効にする必要がある場所を判別するのに役立ちます(図 4-11 を参照)。
次のセキュリティに関する留意点は IP 電話機に適用されます。
電話機のセキュリティ機能の設定を試みる前に、次のリンクで入手可能なマニュアルを参照して、特定の電話機モデルでそれらの機能が使用可能であることを確認してください。
https://www.cisco.com/c/en/us/support/collaboration-endpoints/index.html
Cisco Unified IP Phone 7800 および 8800 シリーズに関するセキュリティ情報の詳細については、次の場所にある『 Cisco IP Phone 7800 and 8800 Series Security Overview White Paper 』を参照してください。
https://www.cisco.com/c/en/us/products/collaboration-endpoints/unified-ip-phone-8800-series/white-paper-listing.html
電話機は、一般的に PC が接続される電話機背面のポートのオン/オフを切り替えることができます。この機能は、そのタイプの制御が必要な場合に、ネットワークにアクセスするためのコントロール ポイントとして使用できます。
セキュリティ ポリシーおよび電話機の配置状況によっては、特定の電話機の背面にある PC ポートを無効にする必要があります。このポートを無効にすると、電話機の背面にデバイスを接続したり、電話機自体を介してネットワークにアクセスしたりできなくなります。ロビーのような一般的なエリアに設置した電話機の場合、通常はポートを無効にします。ロビーでは物理的なセキュリティが非常に弱いため、ほとんどの企業では、制御されていないポートから不特定のユーザがネットワークにアクセスするのを許可しません。セキュリティ ポリシーで、電話機の PC ポートを経由してデバイスがネットワークにアクセスするのを許可しない場合は、通常の作業エリアに設置した電話機でも、ポートを無効にすることがあります。配置された電話機のモデルによっては、Cisco Unified Communications Manager(Unified CM)は、電話機の背面の PC ポートを無効にできます。この機能の有効化を試みる前に、次のリンクで入手可能なマニュアルを参照して、特定の Cisco Unified IP Phone モデルでこの機能がサポートされていることを確認してください。
https://www.cisco.com/c/en/us/support/collaboration-endpoints/index.html
スイッチから電話機までに 2 つの VLAN が存在するので、電話機は、望まないアクセスから Voice VLAN を保護する必要があります。電話機では、電話機の背面から Voice VLAN に入り込む、望まないアクセスを防止できます。PC Voice VLAN Access 機能は、電話機の背面にある PC ポートから Voice VLAN への任意のアクセスを防止します。この機能を無効にすると、電話機の PC ポートに接続されたデバイスが、電話機の背面の PC ポートに到達する Voice VLAN を宛先とした 802.1q タグ付き情報を送信することにより、VLAN を「ジャンプ」して Voice VLAN にアクセスすることは許可されません。設定している電話機に応じて、この機能は 2 つの方法のいずれかで動作します。高機能の電話機では、電話機の背面の PC ポートに着信する Voice VLAN を宛先とした、すべてのトラフィックをブロックします。図 4-12 に示す例の場合、PC が、電話機の PC ポートに対して Voice VLAN トラフィック(このケースでは 200 の 802.1q タグ付き)の送信を試行すると、そのトラフィックはブロックされます。この機能が動作する他の方法は、電話機の PC ポートに着信する、802.1q タグ付きのすべてのトラフィック(Voice VLAN トラフィックに限らない)をブロックする方法です。
現在、アクセス ポートからの 802.1q タギングは、通常は使用しません。この機能が、電話機のポートに接続された PC の要件に含まれている場合、802.1q タグ付きパケットが電話機を通過するのを許可する電話機を使用する必要があります。
電話機の PC Voice VLAN Access 機能の設定を試みる前に、次のリンクで入手可能なマニュアルを参照して、特定の電話機モデルでそれらの機能が使用可能であることを確認してください。
https://www.cisco.com/c/en/us/support/collaboration-endpoints/index.html
図 4-12 電話機の PC ポートから Voice VLAN へのトラフィックのブロック
各 Cisco Unified IP Phone には、デバッグを実行したり管理目的で電話機のリモート ステータスを確認したりするのに役立つ、Web サーバが組み込まれています。Web サーバは、電話機が、Cisco Unified Communications Manager(Unified CM)から電話機にプッシュされたアプリケーションを受信するのを可能にします。この Web サーバへのアクセスは、Unified CM 設定の Web Access 機能を使用して、電話機で有効または無効にできます。この設定は、グローバルで行うことも、電話機ごとに有効または無効にすることもできます。
Web サーバがグローバルで無効だが、デバッグの参考として必要な場合、Unified CM の管理者は、電話機のこの機能を有効にする必要があります。この Web ページにアクセスする機能は、ネットワークの ACL で制御できます。ネットワーク オペレータは、この機能を使用して、必要なときに Web ページにアクセスできます。
Web アクセス機能を無効にすると、電話機は、Unified CM からプッシュされるアプリケーションを受信できません。
Unified CM は、IP フォンとの間の Web トラフィックに HTTPS のみ、もしくは HTTPS と HTTP の両方を使用するように設定できます。ただし、HTTPS だけが設定されている場合でも、IP フォンの Web サーバのポート 80 は自動的に閉じません。HTTP トラフィックを制限するために ACL を使用することが望ましい場合、Unified CM で HTTPS のみ使用するようにします。
各 Cisco Unified IP Phone にはネットワーク設定ページがあり、そのページには、電話機が動作するのに必要な多くのネットワーク要素や詳細情報がリストされます。攻撃者はこの情報を使用して、電話機の Web ページに表示される情報の一部と共に、ネットワーク上で調査を開始できます。たとえば、攻撃者は設定ページを参照して、デフォルト ゲートウェイ、TFTP サーバ、および Unified CM の IP アドレスを判別できます。これらの断片的な情報が、音声ネットワークにアクセスしたり、音声ネットワーク内のデバイスを攻撃したりするのに使用される場合があります。
このアクセスを個々の電話機ごとに、または一括管理を使用して無効にすることにより、エンド ユーザまたは攻撃者が、Unified CM IP アドレスや TFTP サーバ情報などの追加情報を取得することを防止できます。電話機設定ページへのアクセスを無効にすると、エンド ユーザは、スピーカー ボリューム、連絡先、呼び出しタイプなど、通常は制御可能な多くの電話機設定を変更できなくなります。電話機インターフェイスについてエンド ユーザに課される制限により、このセキュリティ機能を使用することが現実的ではない場合があります。このアクセスは制限付きとして設定することができます。これにより、ネットワーク設定情報へのアクセスはできなくなりますが、音量や呼出音などの設定はできます。
電話設定ページの詳細については、次の場所にある『 Administration Guide for Cisco Unified Communications Manager and IM and Presence Service 』の最新版を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-maintenance-guides-list.html
Cisco TelePresence のエンドポイントには攻撃に対してそれらを保護するための複数の設定オプションがあります。セキュリティ機能はエンドポイント間で異なり、デフォルトですべてが有効になっているわけではありません。これらの機能には、次のものがあります。
Cisco TelePresence のエンドポイントは、Secure Shell(SSH)および Secure Sockets Layer を介したハイパーテキスト転送プロトコル(HTTPS)経由の管理をサポートします。HTTP、HTTPS、SSH、または Telnet を使用したエンドポイントへのアクセスは、エンドポイント自体の [ネットワーク サービス(Network Services)] の設定で設定できます。
エンドポイントはデフォルトの管理パスワード付きで出荷されますが、インストール時にパスワードを変更することを推奨します。管理機能へのアクセスは管理者権限を持つユーザに制限する必要があります。デフォルトの管理パスワードが使用されていると、ビデオ ストリームはこのパスワードで管理ページにアクセスできるすべてのユーザに表示されます。
エンドポイントは、定義済みの役割と権限に基づいてアクセスを提供されたユーザに割り当てることができます。こうしたユーザが SSH または Telnet および Web ベース アクセスを実現できるように、パスワードおよび PIN を指定できます。パスワードを定期的に失効させ、変更するとともに、アイドル状態のときにログインをタイムアウトにするために、クレデンシャル管理ポリシーを実装する必要があります。これは、デバイスへのアクセスを検証済みのユーザに限定するために必要です。
Cisco Collaboration ソリューションは、Transport Layer Security(TLS)および Secure Real-time Transport Protocol(SRTP)を使用し、シグナリングとメディア暗号化を行います。
Transport Layer Security(TLS)プロトコルは、2 つのアプリケーション間の通信の認証、データ整合性、および機密性を提供するように設計されています。TLS はクライアント/サーバ モードで動作し、「サーバ」として動作する側面と「クライアント」として動作する側面を持ちます。TLS には、信頼性の高いトランスポート層プロトコルとして動作する TCP が必要です。
シスコ コラボレーション デバイスは、Unified CM に接続するときに、TLS を使用して SIP または Skinny Client Control Protocol(SCCP)シグナリングを保護します。
Secure Real-Time Transport Protocol(SRTP)
IETF RFC 3711 に定義されている Secure RTP(SRTP)は、Real-time Transport Protocol(RTP)の音声メディアとビデオ メディアの両方と、対応する Real-time Transport Control Protocol(RTCP)ストリームの機密性およびデータの整合性を提供する方法を詳しく説明します。SRTP は、暗号化とメッセージ認証ヘッダーを使用してこれを実現します。
SRTP では、暗号化は RTP パケットのペイロードだけに適用されます。ただし、メッセージ認証は RTP のヘッダーと RTP のペイロードの両方に適用されます。ヘッダー内の RTP シーケンス番号にメッセージの認証が適用されるため、SRTP はリプレイ アタックに対しても間接的に保護を提供します。SRTP 暗号方式には、Advanced Encryption Standards(AES)256 または 128、およびセキュア ハッシュ アルゴリズム(SHA)2 での Encryption with Associated Data(AEAD)が含まれています。AES 128 および SHA-1 でのハッシュベースのメッセージ認証コードに基づく SRTP 暗号方式も、設定で禁止されていない場合は、ネゴシエートできます。
Unified CM では、音声システム内の電話機に対して複数のレベルのセキュリティを実現するように設定できます。ただし、電話機でこれらの機能がサポートされている必要があります。これには、X.509 証明書を使用したデバイス認証およびメディアとシグナリングの暗号化が含まれます。導入済みのセキュリティ ポリシー、電話機の配置、および電話機サポートに応じて、社内の必要に合せてセキュリティを設定できます。
電話機と Unified CM クラスタでセキュリティを有効にするには、次の場所にある『 Security Guide for Cisco Unified Communications Manager 』の最新版を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-maintenance-guides-list.html
Unified CM で公開キー インフラストラクチャ(PKI)セキュリティ機能が正しく設定されている場合、サポートされているすべての電話機で、次の機能を使用できます。
Unified CM は、2 つの Cisco Unified IP Phone の間のコールの、認証、完全性、および暗号化をサポートしていますが、すべてのデバイスまたは電話機についてサポートしているわけではありません。ご使用のデバイスがこれらの機能をサポートしているかどうかを判別するには、次の Web サイトで入手可能なマニュアルを参照してください。
https://www.cisco.com/c/en/us/support/collaboration-endpoints/index.html
Unified CM では ID を保護し、暗号化を有効にするために証明書を使用します。エンドポイント上の証明書は、製造元でインストールされる証明書(MIC)またはローカルで有効な証明書(LSC)のどちらかにすることができます。MIC はほとんどのハードウェア エンドポイント上にプレインストールされており、LSC は Unified CM の Cisco Certificate Authority Proxy Function(CAPF)によってインストールされます。MIC を使用する場合、Cisco CA 証明書および Cisco Manufacturing CA 証明書はルート証明書として機能します。ネイティブで登録されたエンドポイント用の LSC が生成された場合は、通常は CAPF によって署名され、CAPF 証明書がルート証明書になります。サードパーティ認証局(CA)を使用して LSC 証明書に署名することもできます(サードパーティ製の CA 証明書に関するセクションを参照)。
シグナリングとメディアのエンドポイントでの暗号化には Unified CM での混合モードが必要です。Unified CM 混合モードの詳細については、Cisco Unified CM セキュリティに関するセクションを参照してください。
Cisco TelePresence Management Suite(TMS)は TLS 証明書を提供して、アウトバウンド接続を生成するときにその ID を確認します。
IP テレフォニー トラフィックがファイアウォールおよびネットワーク アドレス変換(NAT)を通過するのを可能にするアプリケーション層プロトコル検査およびアプリケーション層ゲートウェイ(ALG)も、シグナリングが暗号化されていると動作しません。暗号化されたメディアでは、一部のゲートウェイ、電話機、または会議はサポートされません。
メディアの暗号化によって、コールのレコーディングとモニタリングはより困難で高価になります。VoIP の問題のトラブルシューティングも難しくなります。
デフォルトで、エンドポイントに発行された LSC 証明書は Unified CM 内の CAPF サービスによって署名されます。ただし、サードパーティ製の CA 署名済み LSC もサポートしています。このようなサポートを実装するには、Unified CM の信頼ストアにサードパーティ製の CA 証明書をインポートし、エンドポイントの証明書発行者としてオフシステム CA を使用するように Unified CM の CAPF サービスを設定します。この方式では、すべての電話機の証明書署名要求(CSR)を処理し、サードパーティ CA でそれらに署名してもらってから、電話機に再びインポートするという手間もかかります。
VPN クライアントが組み込まれた Cisco Unified IP Phone には、ネットワーク外の電話機を企業内の Unified Communications ソリューションに接続するためのセキュアなオプションがあります。この機能では、リモート ロケーションに外部 VPN ルータは必要なく、配置されたロケーションにある電話機と企業ネットワーク間の非信頼ネットワークを経由するレイヤ 3 以上のトラフィックのためのセキュア通信トンネルを提供します。
Cisco Unified IP Phone 内の VPN クライアントは、Cisco SSL VPN テクノロジーを使用しており、Cisco ASA 5500 シリーズ VPN ヘッドエンドと Cisco IOS SSL VPN ソフトウェア機能を備えた Cisco サービス統合型ルータの両方に接続できます。音声トラフィックは VPN トンネルの一部として、UDP および Datagram Transport Layer Security(DTLS)プロトコルによって伝送されます。統合された VPN トンネルは、音声および IP Phone Service だけに適用されます。PC ポートに接続された PC はこのトンネルを使用できず、PC からのトラフィック用に独自の VPN トンネルを確立する必要があります。
VPN クライアントが組み込まれた電話機の場合、最初に、VPN コンセントレータ アドレス、VPN コンセントレータ クレデンシャル、ユーザまたは電話機 ID、クレデンシャル ポリシーなどの VPN 設定パラメータを使用して電話機を設定する必要があります。この情報は機密であるため、電話機が非信頼ネットワーク経由での接続を試行する前に、電話機を企業ネットワーク内でプロビジョニングする必要があります。最初に電話機を企業ネットワーク内でステージングしないで電話機を配置することは、サポートされていません。
ユーザは、電話機のユーザ インターフェイスの設定メニューで、VPN トンネルの確立を有効または無効にできます。VPN トンネルの確立が有効の場合、電話機は VPN トンネルの確立を開始します。電話機は、冗長性を持たせるために最大 3 つの VPN コンセントレータを使用して設定できます。VPN クライアントは、ロード バランシング メカニズムとして、VPN コンセントレータから他の VPN コンセントレータへのリダイレクションをサポートします。
VPN クライアント用の電話機の設定手順については、次の場所にある『 Administration Guide for Cisco Unified Communications Manager and IM and Presence Service 』の最新版を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-maintenance-guides-list.html
(注) テレワーカーおよび小規模オフィスまたはホーム オフィス(SOHO)の場合は、Cisco Expressway を使用した電話機ベースの VPN、ルータベースの VPN、または Mobile and Remote Access の導入を推奨します。
Quality of Service(QoS)は、企業ネットワーク用のすべてのセキュリティ ポリシーで、重要な部分を占めます。一般的に、QoS はネットワーク内のトラフィック重要度の設定と考えられていますが、ネットワークに入ることが許可されるデータの量も制御します。Cisco スイッチの場合、電話機からイーサネット スイッチにデータが送られるときのコントロール ポイントはポート レベルにあります。アクセス ポートでネットワークのエッジに適用される制御が多いほど、ネットワークでデータを集約するときに発生する問題は少なくなります。
QoS を使用すると、ネットワーク内のトラフィックの優先度だけでなく、任意の特定のインターフェイスを通過できるトラフィックの量も制御できます。ネットワーク内の音声 QoS をアクセス ポート レベルで配置するのに役立つ、Cisco Smartports テンプレートが作成されました。
厳しい QoS ポリシーでは、トラフィック レートを制御することによって、ネットワーク内のサービス拒否攻撃を制御および防止できます。
ロビーに設置された電話機の例ですでに説明したとおり、攻撃者がロビー内のそのポートから DoS 攻撃を仕掛けるのを防止するため、アクセス ポート レベルでトラフィックの十分なフロー コントロールを提供することを推奨します。QoS 設定ではポートに送信されたトラフィックが最大レートを超えることが許可されていますが、トラフィックは Scavenger Class にリマークされているので、この例の設定は、それほどアグレッシブではありません。よりアグレッシブな QoS ポリシーを使用すると、ポリシーの最大制限を超える量のトラフィックはポートでドロップされ、その「不明な」トラフィックがネットワークに入ることはありません。IP テレフォニー データにエンドツーエンドで高い優先度を与えるには、ネットワーク全体で QoS を有効にする必要があります。
QoS の詳細については、ネットワーク インフラストラクチャと、次の Web サイトで入手可能な QoS の設計ガイドを参照してください。
https://www.cisco.com/c/en/us/solutions/enterprise/design-zone-ipv6/design-guide-listing.html
この項では、アクセス コントロール リスト(ACL)、および音声データの保護における ACL の使用方法について説明します。
VLAN アクセス コントロール リスト(ACL)を使用すると、ネットワーク上を流れるデータを制御できます。Cisco スイッチには、VLAN ACL 内でレイヤ 2~4 を制御する機能があります。ネットワーク内のスイッチのタイプによっては、VLAN ACL を使用して、特定の VLAN に流入または流出するトラフィックをブロックできます。また、VLAN ACL を使用して VLAN 内のトラフィックをブロックし、VLAN 内のデバイス間で発生する処理を制御することもできます。
VLAN ACL を配置する計画がある場合、IP テレフォニー ネットワーク内で使用される各アプリケーションで電話機が正しく動作するようにするにはどのポートが必要かを検証する必要があります。通常、任意の VLAN ACL は、電話機が使用する VLAN に適用されます。これにより、アクセス ポートで、アクセス ポートに接続されているデバイスにできるだけ近い制御ができるようになります。
ACL は、VLAN に入るまたは VLAN から出るネットワーク トラフィックを制御する機能、および VLAN 内でトラフィックを制御する機能を提供します。
VLAN ACL を、モバイル性の高いアクセスポート レベルで配置および管理するのは非常に困難です。これらの管理上の問題があるので、ネットワークのアクセス ポートに VLAN ACL を配置するときは注意が必要です。
VLAN ACL と同様、ルータにも、ポートごとにインバウンド ACL およびアウトバウンド ACL の両方を処理する機能があります。最初のレイヤ 3 デバイスは、音声およびデータ VLAN を使用するときの音声データと別タイプのデータとの間の境界ポイントです。境界ポイントでは、2 つのタイプのデータが、相互にトラフィックを送信することが許可されます。VLAN ACL とは異なり、ルータ ACL は、ネットワーク内のすべてのアクセス デバイスには配置されません。その代わり、ネットワーク全体にルーティングするすべてのデータを準備する場所である、エッジ ルータで適用されます。これは、各 VLAN のデバイスがネットワーク内でアクセス可能なエリアを制御するために、レイヤ 3 ACL を適用するのに最適な場所です。レイヤ 3 ACL をネットワーク全体に配置することにより、トラフィックが収束する場所で、デバイスを相互に保護できます(図 4-13 を参照)。
レイヤ 3 に配置可能な ACL には、多くのタイプがあります。一般的なタイプの説明と例については、次の Web サイトで入手可能な『 Configuring Commonly Used IP ACLs 』を参照してください(シスコ パートナーとしてのログインが必要)。
https://www.cisco.com/c/en/us/support/docs/ip/access-lists/26448-ACLsamples.html
導入済みのセキュリティ ポリシーに応じて、レイヤ 3 ACL は、非 Voice VLAN からの IP トラフィックがネットワーク内の音声ゲートウェイにアクセスするのを禁止するという単純な設定にも、他のデバイスが IP テレフォニー デバイスと通信するために使用する個別のポートや時間帯を制御するという詳細な設定にもできます。ACL が高精度および詳細になると、ネットワーク内のポート使用法の変更が原因で、音声だけでなく、ネットワーク内の他のアプリケーションも遮断される場合があります。
ネットワークにソフトフォンがある場合、電話機への Web アクセスが許可されている場合、または Attendant Console を使用するか、Voice VLAN サブネットへのアクセスが必要な他のアプリケーションを使用する場合、ACL の配置と制御はさらに難しくなります。
特定のサブネットに制限され、音声 VLAN に限定される IP Phone の場合、Unified CM、音声ゲートウェイ、電話機、および音声のみのサービスに使用されるその他のあらゆる音声アプリケーションへの(IP アドレスまたは IP 範囲による)すべてのトラフィックをブロックするように ACL を記述できます。この方法により、レイヤ 3 ACL を、レイヤ 2 または VLAN ACL よりも簡素化できます。
ファイアウォールを ACL と組み合わせて使用すると、IP テレフォニー デバイスと通信することが許可されていないデバイスから、音声サーバおよび音声ゲートウェイを保護できます。IP テレフォニーで使用するポートには動的な特性があるので、ファイアウォールを配置すると、IP テレフォニー通信で必要な広範囲のポートの開放を制御するのに役立ちます。ファイアウォールを導入するとネットワークの設計が複雑になるので、適正と見なされるトラフィックが通過するのを許可し、ブロックする必要があるトラフィックをブロックするようにファイアウォール、およびファイアウォールの周辺デバイスを配置および設定するときは、細心の注意が必要です。
IP テレフォニー ネットワークには、一意のデータ フローがあります。電話機はクライアント/サーバ モデルを使用してコール セットアップ用のシグナリングを生成し、Unified CM はそのシグナリングを使用して電話機を制御します。IP テレフォニー RTP ストリームのデータ フローは、ピアツーピア ネットワークに似ており、電話機またはゲートウェイは、RTP ストリームを介して相互に直接通信します。ファイアウォールがシグナリング トラフィックを検査できるようシグナリング フローがファイアウォールを経由しないようにする場合、ファイアウォールが、会話用の RTP ストリームを許可するのにどのポートを開放する必要があるかを判別できないので、RTP ストリームがブロックされることがあります。
正しく設計されたネットワークにファイアウォールを配置すると、すべてのデータがそのデバイスを経由するように強制できるので、キャパシティとパフォーマンスについて考慮する必要があります。パフォーマンスには、遅延の量が関係しています。ファイアウォールに高い負荷がかかっている場合やファイアウォールが攻撃されている場合は、1 つのファイアウォールにより遅延の量が増大することがあります。IP テレフォニーの配置に関する原則では、ファイアウォールの通常使用時の CPU 使用率を 60 % 未満に抑えます。CPU の使用率が 60 % を超えると、IP Phone、コール セットアップ、および登録に影響が出る可能性が高まります。CPU の使用率が継続的に 60 % を超えると、登録済みの IP Phone は影響を受け、進行中のコールの品質は低下し、新しいコールのコール セットアップは問題を抱えます。CPU 使用率が 60 % を超えた状態が続くと、最悪の場合、電話機の登録解除が始まります。このことが発生すると、電話機は Unified CM への再登録を試みるようになり、ファイアウォールの負荷はさらに増大します。この状態が発生すると、結果的に、登録解除と Unified CM への再登録の試行を繰り返す電話機の連続ブラックアウトが発生します。ファイアウォールの CPU 使用率が継続的に 60 % 未満に落ち着くまで、この連続ブラックアウトは続き、すべてまたはほとんどの電話機が影響を受けます。現在、ネットワーク内で Cisco ファイアウォールを使用している場合、ネットワークに IP テレフォニー トラフィックを追加するときは、トラフィックが悪影響を受けないように、CPU 使用率を注意深くモニタしてください。
ファイアウォールを配置する方法はいくつもあります。この項では、ルーテッドおよびトランスペアレントの両方のシナリオにおける、アクティブ/スタンバイ モードの Cisco Adaptive Security Appliance(ASA)について集中的に説明します。この項で説明する各設定は、ファイアウォール設定の音声セクション内で、シングル コンテキスト モードで設定されたものです。
すべての Cisco ファイアウォールは、マルチ コンテキスト モードまたはシングル コンテキスト モードのいずれかで実行できます。シングル コンテキスト モードでは、ファイアウォールは、ファイアウォールを通過するすべてのトラフィックを制御する単一のファイアウォールを指します。マルチ コンテキスト モードでは、ファイアウォールは複数の仮想ファイアウォールを指します。これらのコンテキストまたは仮想ファイアウォールにはそれぞれ独自の設定があり、異なるグループまたは管理者が制御できます。ファイアウォールに新しいコンテキストを追加するたびに、ファイアウォールの負荷およびメモリ要件は大きくなります。新しいコンテキストを配置するときは、音声 RTP ストリームが悪影響を受けないように、CPU 要件を満たしていることを確認してください。
Adaptive Security Appliance では、Unified Communications アプリケーション サーバおよびエンドポイントの IPv6 トラフィックのアプリケーション インスペクションのサポートは限定されています。ASA がネットワークに配置されている場合、Unified Communications には IPv6 を使用しないことを推奨します。
(注) ペイロード暗号化モジュールのない ASA は、ユニファイド コミュニケーション機能を無効にします。
ファイアウォールは、ネットワーク上で実行されるアプリケーションのために、ネットワークのセキュリティ コントロール ポイントを提供します。トラフィックがファイアウォールを通過する場合、ファイアウォールは、IP テレフォニー会話用にポートを動的に開く機能も提供します。
アプリケーション インスペクション機能を使用すると、ファイアウォールを通過するトラフィックがファイアウォールで検査され、そのトラフィックが、ファイアウォールで予期されていたタイプのトラフィックかどうかが判別されます。たとえば、HTTP トラフィックが本当に HTTP トラフィックなのか、あるいは攻撃なのかが判別されます。それが攻撃だった場合、ファイアウォールはそのパケットをドロップし、そのパケットがファイアウォールの背後にある HTTP サーバに到達するのを許可しません。
ファイアウォールのアプリケーション層プロトコル検査では、すべての IP テレフォニー アプリケーション サーバまたはアプリケーションがサポートされているわけではありません。そのようなアプリケーションの一部として、Cisco Unity ボイスメール サーバ、Cisco Unified Attendant Console、Cisco Unified Contact Center Enterprise、および Cisco Unified Contact Center Express があります。トラフィックがファイアウォールを経由して流れるのを許可するため、これらのアプリケーション用の ACL を書き込むことができます。
(注) ファイアウォールに備えられたフェールオーバーのタイマーは、デフォルトで高い値が設定されています。フェールオーバー時にファイアウォールを通過する音声 RTP ストリームに影響するのを防ぐため、タイマー設定を 1 秒以下に設定することを推奨します。設定を変更し、フェールオーバーが発生すると、ファイアウォールのフェールオーバーが短縮され RTP ストリームが影響するフェールオーバー時間が削減されるため、RTP ストリームが影響を受ける時間が低減されます。
異なる Unified Communications コンポーネントの間にファイアウォールを設置する場合、コンポーネント間の通信に使用されるすべてのプロトコルについてアプリケーション インスペクションを有効にする必要があります。リモート エージェントの電話とスーパーバイザの電話の間にファイアウォールを設置すると、Unified Communications Manager のサイレント モニタリングなどの機能によって使用されるコール フローのシナリオで、アプリケーション インスペクションが失敗することがあります。
TCP を使用する Unified Communications デバイス(Cisco Unified Communications Manager など)は、パケット損失の場合にデータの転送を高速化するために、TCP SACK オプションをサポートしています。ただし、すべてのファイアウォールが TCP SACK オプションをサポートしているわけではありません。その場合、Unified Communications デバイスが TCP SACK オプションを使用しようとすると、そのようなファイアウォールを経由してデバイス間で確立された TCP セッションに問題が発生し、TCP セッションは失敗する場合があります。そのため、ファイアウォールは TCP SACK オプションを完全にサポートしている必要があります。サポートできない場合、ファイアウォールでは、スリーウェイ ハンドシェイク中に TCP パケットを変更でき、エンドポイントが TCP SACK オプションを使用しないようにこのオプションのサポートを無効にできることが必要です。
ネットワーク上で実行しているアプリケーションがネットワーク内のファイアウォールのバージョンでサポートされているかどうか、および ACL を書き出す必要があるかどうかを判別するには、次の Web サイトで入手可能な適切なアプリケーション マニュアルを参照してください。
ルーテッド モードの ASA ファイアウォールは、接続されているネットワーク間のルータとして機能します。各インターフェイスには、異なるサブセット上の 1 つの IP アドレスが必要です。シングル コンテキスト モードでは、ルーテッド ファイアウォールは Open Shortest Path First(OSPF)およびパッシブ モードの Routing Information Protocol(RIP)をサポートしています。マルチ コンテキスト モードは、静的ルートのみをサポートしています。ASA は、Enhanced Interior Gateway Routing Protocol(EIGRP)もサポートします。拡張するルーティング要件に対するセキュリティ アプライアンスに依存するのではなく、アップストリーム ルータおよびダウンストリーム ルータの拡張ルーティング機能を使用することを推奨します。ルーテッド モードの詳細については、次の場所にある最新の ASA 構成ガイドを参照してください。
https://www.cisco.com/c/en/us/support/security/adaptive-security-appliance-asa-software/products-installation-and-configuration-guides-list.html
ルーテッド ASA ファイアウォールは、QoS、NAT、およびボックスへの VPN 終端をサポートしています。これらの機能は、トランスペアレント モードではサポートされていません(トランスペアレント ASAを参照)。ルーテッド設定では、ASA 上の各インターフェイスに IP アドレスが与えられます。トランスペアレント モードでは、ASA をリモートで管理するための IP アドレスの他には、インターフェイス上に IP アドレスは与えられません。
トランスペアレント モードと比較した場合のこのモードの制限は、デバイスがネットワークで表示されるため、攻撃ポイントになる可能性があることです。また、ルーティングの一部はファイアウォールで実行可能なため、ルーテッド ASA ファイアウォールをネットワークに配置すると、ネットワークのルーティングが変更されます。ファイアウォールに存在する、使用する予定のすべてのインターフェイスでは、IP アドレスも使用可能でなければなりません。そのため、ネットワーク内のルータの IP アドレスを変更する必要が生じる場合もあります。ASA ファイアウォールを経由してルーティング プロトコルまたは RSVP を許可する場合、トラフィックが外側(または信頼性が低い)インターフェイスを通過するのを許可するため、ACL を内側(または最も信頼性が高い)インターフェイス上に配置する必要があります。ACL では、最も信頼性が高いインターフェイスから出るのを許可される、その他のすべてのトラフィックも定義する必要があります。
ASA ファイアウォールは、レイヤ 2 ファイアウォール(「Bump In The Wire」または「ステルス ファイアウォール」とも呼ばれる)として設定できます。この設定では、ファイアウォールに IP アドレス(管理目的のものを除く)は与えられず、すべてのトランザクションはネットワークのレイヤ 2 で行われます。ファイアウォールはブリッジとして動作しますが、レイヤ 3 のトラフィックは、拡張アクセス リストで明示的に許可しない限り、セキュリティ アプライアンスを通過できません。アクセス リストなしで許可されるトラフィックは、Address Resolution Protocol(ARP)トラフィックだけです。
この設定には、ファイアウォールが動的ルーティングを一切行わないため、攻撃者がファイアウォールを見つけることができないという利点があります。ファイアウォールがトランスペアレント モードでも動作するようにするには、静的ルーティングが必要です。
この設定では、ファイアウォールに合せてルーティングを変更する必要がないので、より簡単に既存のネットワークにファイアウォールを配置できます。またこの設定は、ファイアウォール内でいずれのルーティングも行わないため、ファイアウォールの管理やデバッグも簡単に実行できます。ファイアウォールはルーティング要求を処理しないので、通常は、 inspect コマンドと全体のトラフィックを使用したときのファイアウォールのパフォーマンスの方が、同じファイアウォール モデルとソフトウェアがルーティングを実行する場合よりも高くなります。
トランスペアレント モードでは、ルーティングのためにデータを渡す場合、同じファイアウォールをルーテッド モードで使用する場合とは異なり、トラフィックを許可するためにファイアウォールの内側と外側の両方で ACL を定義する必要があります。Cisco Discovery Protocol(CDP)トラフィックは、デバイスが定義済みの場合でも、デバイスを通過することはありません。直接接続される各ネットワークは、同じサブネット上に置かれている必要があります。コンテキスト間でインターフェイスを共有できません。マルチ コンテキスト モードを実行する計画の場合は、追加のインターフェイスを使用する必要があります。そのトラフィックがファイアウォールを通過するのを許可するには、ACL で、ルーティング プロトコルなどのすべての非 IP トラフィックを定義する必要があります。トランスペアレント モードでは QoS はサポートされていません。マルチキャスト トラフィックは、拡張 ACL が設定されているファイアウォールを通過するのを許可されますが、これはマルチキャスト デバイスではありません。トランスペアレント モードでは、VPN 終端はファイアウォールでサポートされていません。ただし、管理インターフェイス用の終端を除きます。
ASA ファイアウォールを経由してルーティング プロトコルまたは RSVP を許可する場合、トラフィックが外側(または信頼性が低い)インターフェイスを通過するのを許可するため、ACL を内側(または最も信頼性が高い)インターフェイス上に配置する必要があります。ACL では、最も信頼性が高いインターフェイスから出るのを許可される、その他のすべてのトラフィックも定義する必要があります。
トランスペアレント モードの詳細については、次の場所にある最新の ASA 構成ガイドを参照してください。
https://www.cisco.com/c/en/us/support/security/adaptive-security-appliance-asa-software/products-installation-and-configuration-guides-list.html
(注) トランスペアレント モードで NAT を使用する場合は、ASA バージョン 8.0(2) 以降が必要です。詳細については、https://www.cisco.com/c/en/us/support/security/asa-5500-series-next-generation-firewalls/products-release-notes-list.html にある『Cisco ASA 5500 Series Release Notes』を参照してください。
ネットワーク アドレス変換(NAT)デバイスは、社内のプライベート IP アドレスをパブリック インターネットで表示されるパブリック IP アドレスに変換します。社内のエンドポイントは内部エンドポイントであり、パブリック インターネットのエンドポイントは外部エンドポイントです。
社内デバイスが NAT 経由で接続する場合、NAT はそのデバイスにパブリック IP アドレスを動的に割り当てます。このパブリック IP アドレスは public mapped address または reflexive transport address とも呼ばれます。NAT がパブリック インターネット上のデバイスにこのパケットを転送すると、パケットはその割り当てられたパブリック アドレスから送信されたように見えます。外部デバイスがパブリック アドレスで NAT にパケットを返送する場合、NAT は、IP アドレスを内部プライベート アドレスに変換し、内部ネットワークにパケットを転送します。
NAT の機能は通常、ファイアウォールの一部であり、したがって、NAT/FW と呼ばれることがあります。NAT は、多数の内部のプライベート IP アドレスを少数の外部のパブリック IP アドレスにマッピングします。現在のパブリック IPv4 アドレス空間は限定的で、ユビキタスなプロトコルとして IPv6 が出現するまで、ほとんどの企業では利用可能なパブリック IPv4 アドレス数が制限されています。NAT により、多数のエンドポイントを持つ企業が少ないパブリック IP アドレスで運用できるようになります。NAT は、外部 IP アドレスに内部 IP アドレスを動的にマッピングすることにより、内部エンドポイントが NAT 経由で接続をするたびにこの機能を実行します。これらのマッピングはそれぞれ、NAT のバインディングと呼ばれます。
音声デバイスおよびビデオ デバイスに対して実行される NAT が複雑化する主な原因は、音声とビデオのシグナリング プロトコルがプロトコル シグナリング メッセージに送信元アドレスおよびポートを含むことにあります。これらの送信元アドレスは、リモート エンドポイントが応答パケットに使用する宛先アドレスを提供します。ただし、内部エンドポイントはプライベート アドレス空間のアドレスを使用し、アプリケーション層ゲートウェイ(ALG)を使用しない NAT はこれらの内部アドレスを変更しません。リモート エンドポイントがメッセージを受信しても、メッセージのプライベート IP アドレスへパケットをルーティングすることはできません。この問題を解決するには、パケットの内容を検査して、シグナリング メッセージにカプセル化されたメディアの IP アドレスとポート番号に対してアドレス変換を実行可能な NAT デバイスで ALG(SIP や SCCP などの「フィックスアップ」)を有効にする必要があります。
NAT ALG はファイアウォール ALG に似ていますが、NAT ALG はシグナリング メッセージのアドレスとポートを実際に変更します。NAT ALG は、暗号化されたシグナリング メッセージの内容は検査できません。
データセンター内では、IP テレフォニー アプリケーション サーバで必要なセキュリティについて、セキュリティ ポリシーを定義する必要があります。Cisco Unified Communications サーバは IP に基づいているので、データセンター内にある、時間に敏感な他のデータに適用するセキュリティを、これらのサーバにも適用できます。
データセンターの間で WAN でのクラスタリングが使用されている場合、データセンター内とデータセンター間の両方に適用されている追加のセキュリティは、クラスタ内のノード間で許可されている最大往復時間に収まる必要があります。WAN を介したクラスタリングを使用するマルチサイトまたは冗長データセンター実装では、アプリケーション サーバに関する現行のセキュリティ ポリシーでデータセンターのファイアウォールをまたぐサーバ間のトラフィックを保護するように要求されている場合は、すでに展開済みのインフラストラクチャ セキュリティ システム間のこのトラフィックに対して IPSec トンネルを使用することを推奨します。
データ アプリケーションに適切なデータセンター セキュリティを設計するには、次の場所にある『 Data Center Technology Design Guide 』に記載されたガイドラインに従うことをお勧めします。
https://www.cisco.com/c/en/us/solutions/enterprise/data-center-designs-data-center-networking/index.html#~designs~tab-designs
ゲートウェイおよびメディア リソースは、IP テレフォニー コールを PSTN コールに変換するデバイスです。外部コールがかけられた場合、ゲートウェイまたはメディア リソースは、IP テレフォニー ネットワークにおいてすべての音声 RTP ストリームが流れる数少ない場所の 1 つです。
IP テレフォニー ゲートウェイおよびメディア リソースは、ネットワーク内のほぼすべての場所に配置できるので、導入済みのセキュリティ ポリシーによっては、IP テレフォニー ゲートウェイまたはメディア リソースを保護することが、他のデバイスを保護することより難しいと見なされる場合があります。しかし、ネットワーク内のどこで信頼が確立されているかによりますが、ゲートウェイおよびメディア リソースを簡単に保護できる場合もあります。ゲートウェイおよびメディア リソースが Unified CM により制御される方法が関係していますが、シグナリングがゲートウェイまたはメディア リソースに到達するために通るパスがネットワーク内で安全と見なされている部分にある場合、単純な ACL を使用して、ゲートウェイまたはメディア リソースに送る、またはそこから戻るシグナリングを制御できます。ゲートウェイ(またはメディア リソース)と Unified CM のロケーションの間のネットワークが安全と見なされない場合は(ゲートウェイがリモートの支店に置かれている場合など)、インフラストラクチャを使用してゲートウェイおよびメディア リソースへの IPSec トンネルを構築することにより、シグナリングを保護できます。ほとんどのネットワークでは、通常、2 つの方式(ACL および IPSec)の組み合わせを使用して、これらのデバイスが保護されています。
ここでは、ネットワークのエッジで QoS を使用しているので、攻撃者が Voice VLAN に侵入してゲートウェイおよびメディア リソースの場所を判別できた場合、ポートの QoS により、攻撃者がゲートウェイまたはメディア リソースに送信できるデータの量が制限されます(図 4-14 を参照)。
図 4-14 IPSec、ACL、および QoS を使用したゲートウェイおよびメディア リソースの保護
電話機で SRTP を有効にしている場合、一部のゲートウェイおよびメディア リソースでは、電話機からのゲートウェイおよびメディア リソースに対する Secure RTP(SRTP)をサポートします。ゲートウェイまたはメディア リソースが SRTP をサポートしているかどうかを判別するには、次の Web サイトで入手可能な適切な製品マニュアルを参照してください。
IPSec トンネルの詳細については、次の場所にある『 IPSec VPN WAN Design Overview 』を参照してください。
https://www.cisco.com/c/en/us/solutions/enterprise/design-zone-ipv6/design-guide-listing.html
コールの送信元である電話機と、PSTN ネットワークへのゲートウェイとの間にファイアウォールを配置する場合、注意が必要な問題が生じます。ステートフル ファイアウォールは、Unified CM、ゲートウェイ、および電話機の間のシグナリング メッセージの内容を参照し、コールの実行を許可するための RTP ストリーム用のピンホールを開けます。通常の ACL で同じことを行うには、RTP ストリームで使用されるポート範囲全体を、ゲートウェイに対して開放する必要があります。
ネットワーク内にゲートウェイを配置する方法は 2 つあります。つまり、ファイアウォールの背後に配置する方法と、ファイアウォールの前面に配置する方法です。ゲートウェイをファイアウォールの背後に配置する場合、そのゲートウェイを使用している電話機からのすべてのメディアは、ファイアウォールを通過する必要があります。また、これらのストリームがファイアウォールを通過するようにするには、追加の CPU リソースが必要です。次に、ファイアウォールでは、これらのストリームの制御が追加され、ゲートウェイが DoS 攻撃から保護されます(図 4-15 を参照)。
図 4-15 ファイアウォールの背後に配置されたゲートウェイ
ゲートウェイを配置する 2 番めの方法は、ファイアウォールの外側に配置する方法です。電話機からゲートウェイに送信される唯一のデータ タイプは RTP ストリームなので、そのゲートウェイに送信可能な RTP トラフィックの量は、アクセス スイッチの QoS 機能により制御されます。Unified CM からゲートウェイに送信されるのは、コールをセットアップするためのシグナリングだけです。ネットワーク内で、信頼できるエリアにゲートウェイが配置されている場合、Unified CM とゲートウェイの間で許可する必要がある唯一の通信は、そのシグナリングです(図 4-15 を参照)。RTP ストリームはファイアウォールを通過しないので、この配置方式では、ファイアウォールの負荷が低下します。
ACL とは異なり、ほとんどのファイアウォール設定では、シグナリングがファイアウォールを経由している限り、Unified CM が電話機とゲートウェイに対して、それらの 2 つのデバイスの間で使用するように指示している RTP ストリーム ポートだけが開放されます。また、ファイアウォールには、DoS 攻撃用の追加機能や、対象トラフィックを参照して、攻撃者が禁止動作を行っていないかどうかを判別するための Cisco 侵入防御システム(IPS)シグニチャがあります。
ファイアウォールの項で説明するように、ファイアウォールが、電話機からゲートウェイへのすべてのシグナリングおよび RTP ストリームを調べる場合、キャパシティが問題になることがあります。また、音声データ以外のデータがファイアウォールを通過する場合、ファイアウォールを通過するコールがファイアウォールにより影響されないように、CPU 使用率をモニタする必要があります。
Cisco IOS Enhanced Conference Bridge と Cisco Meeting Server は、セキュアな会議を提供します。Unified CM、そのエンドポイント、および Cisco Meeting Server ノード間でメディアとシグナリングの暗号化を実装するには、Unified CM サーバと Cisco Meeting Server ノード間に SIP トランクをセキュア SIP トランクとして設定する必要があります。SIP トランク設定は、SRTP を許可するように設定する必要もあります。Cisco Meeting Server 証明書、つまり、CA 署名付き証明書が使用されている場合の CA 証明書は Unified CM CallManager と Tomcat の信頼ストアにアップロードする必要があり、SIP トランク プロファイルで証明書の共通名を X.509 サブジェクト名として設定する必要があります。同様に、CallManager 証明書、つまり、CA 署名付き証明書が使用されている場合の CA 証明書は、Cisco Meeting Server 信頼ストアにアップロードする必要があります。
この設定によって、Cisco Unified CM と Cisco Meeting Server 間の管理トラフィックのセキュアなシグナリングと HTTPS の両方が有効になります。
Unified CM トランクによって、企業ネットワークと外部ネットワークの間に IP 接続ポイントが追加されます。これらの相互接続に追加のセキュリティ対策を適用して、データおよび IP テレフォニー アプリケーションに固有の脅威を軽減する必要があります。Unified CM トランクと外部ネットワークの間に Cisco Unified Border Element を実装することが、より柔軟でセキュアな相互運用性オプションとなります。
Cisco Unified Border Element は、音声アプリケーション境界と音声トラフィックとデータ トラフィックの両方に適用できるセキュリティ脅威軽減技術を提供する Cisco IOS ソフトウェア機能です。Cisco Unified Border Element は、Cisco IOS ファイアウォール、認証、および VPN 機能とともに同じデバイス上で設定でき、サービス プロバイダー ネットワークまたはその他の外部ネットワークと統合された Unified CM トランクのセキュリティを強化できます。これらの Cisco IOS セキュリティ機能は、外部の攻撃に対する防御として、およびルータを通過してサービス プロバイダーのネットワークへ出ていく内部トラフィックのチェックポイントとしての役割を果たします。サービス プロバイダーまたはサービス プロバイダーのネットワークに接続されたネットワークから発生した不正アクセス、DoS 攻撃、または分散型 DoS(DDoS)攻撃を防ぐために、および侵入やデータ盗用を防ぐために、インフラストラクチャ アクセス コントロール リスト(ACL)を使用することもできます。
Cisco Unified Border Element は、シグナリングおよびメディアのネットワーク トポロジを隠蔽する機能を提供するバックツーバック ユーザ エージェント(B2BUA)です。ネットワークのセキュリティと処理上の独立性を有効にし、すべてのトラフィックで Cisco Unified Border Element IP アドレスを置き換えることで NAT サービスを提供します。
Cisco Unified Border Element は、ネットワーク間のメディアおよびシグナリング パケットで DSCP QoS パラメータを再マーキングするために使用できます。これにより、トラフィックはネットワーク内で QoS ポリシーに従うようになります。
Cisco IOS ファイアウォール機能は、Cisco Unified Border Element との組み合わせで使用され、シグナリング メッセージを一致させてトラフィックを管理するために Application Inspection and Control(AIC)を提供します。これは、SIP トランク DoS 攻撃を防ぐのに役立ち、コンテンツおよびレート制限に基づくメッセージ フィルタリングを可能にします。
Cisco Unified Border Element によって SIP トランク登録が可能です。この機能は、Unified CM SIP トランクでは使用できません。
Cisco Unified Border Element は、背後にあるエンドポイントに代わって、企業ネットワークの E.164 DID 番号をサービス プロバイダーの SIP トランクに登録できます。ネットワークの E.164 DID 番号をプロキシするために Cisco Unified Border Element を使用する場合、実際のエンドポイントのステータスはモニタされません。したがって、登録解除されたエンドポイントが引き続き使用可能として表示される場合があります。
Cisco Unified Border Element は、外部ネットワーク経由で SRTP を使用して RTP 企業ネットワークを接続できます。これにより、企業内に SRTP を配置しなくても安全な通信が可能になります。RTP-SRTP インターワーキングもサポートしますが、G.711 mulaw、G.711 alaw、G.729abr8、G.729ar8、G.729br8、G.729r8 など、少数のコーデックに制限されます。
特定の SIP サービス プロバイダーでは、コール サービスが許可される前に、SIP トランクへの登録が必要です。これにより、コールは既知のエンドポイントだけから発生するようになり、企業とサービス プロバイダー間のサービス ネゴシエーションはよりセキュアになります。Unified CM は、SIP トランクでの登録をネイティブにはサポートしませんが、Cisco Unified Border Element を使用することによってこのサポートを実現できます。Cisco Unified Border Element は、Cisco Unified Communications Manager に代わって、企業の電話番号を使用してサービス プロバイダーに登録します。
Cisco Unified Border Element の設定および製品詳細については、次の Web サイトで入手可能なマニュアルを参照してください。
Cisco Expressway は、企業のネットワークの外側にあるデバイスと、Expressway をコラボレーション エッジとして機能させたインターネットを介して、ビデオ コミュニケーション コールを確立できます。外部発信者がデバイスにアクセスできるようにするには、Cisco Expressway-E を Cisco Collaboration ソリューションで使用されるプライベート ネットワークの外側に配置する必要があります。これは、パブリック インターネット上または非武装地帯(DMZ)に配置できます。Expressway-E が DMZ 内に展開されている場合は、インターネットと Expressway-E 間のトラフィックを許可するようにファイアウォールを設定する必要があります。Expressway-C は Expressway-E とペア化され、通常は、データセンター内に展開されます。Expressway-E と組み合わせることにより、コラボレーション用のファイアウォール トラバーサルが容易になります。
Expressway-C は Cisco Unified CM 用の SIP プロキシおよびコミュニケーション ゲートウェイです。これには Expressway-E と通信するトラバーサル クライアント ゾーンが設定されており、NAT デバイスを通過するインバウンドおよびアウトバウンド コールを許可します。Expressway-E はリモート(エンタープライズ ネットワークの外部)に存在するデバイスの SIP プロキシです。これは、パブリック ネットワークのドメイン名で設定されます。
Cisco Expressway は、HTTPS、SIP TLS、ならびに Cisco Unified CM、LDAP、および syslog サーバへの接続に X.509 証明書を使用します。この導入では、信頼された CA 証明書のリストを使用し、サードパーティの CA が署名した証明書の使用が優先されます。これにより、Expressway-C、Expressway-E、および Unified CM との間での証明書の設定と交換が簡略化され、管理のオーバーヘッドが低減されます。物理エンドポイントがモバイルおよびリモート アクセス(MRA)を介して接続されている場合は、Expressway-E 証明書をパブリック サードパーティ CA によって署名する必要があります。これは、これらのエンドポイントがルート CA 証明書の組み込み信頼リストを使用して Expressway-E 証明書を検証するためです。
Unified CM セキュリティ機能のリストとそれらの有効化方法については、次の場所にある『 Security Guide for Cisco Unified Communications Manager 』の最新版を参照してください。
https://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-maintenance-guides-list.html
任意の Unified CM セキュリティ機能を有効にする前に、それらの機能が、ネットワーク内のこれらのタイプのデバイスに関する企業セキュリティ ポリシーで指定されている、セキュリティ要件を満たしていることを確認してください。詳細については、次の Web サイトにある『 Cisco ASA 5500 Series Release Notes 』を参照してください。
https://www.cisco.com/c/en/us/support/security/asa-5500-series-next-generation-firewalls/products-release-notes-list.html
シングル サイン オン(SSO)機能は、より強力な認証とより良いユーザ エクスペリエンスを可能にします。シスコ コラボレーション ソリューションで使用される SSO、SAML 認証、OAUTH プロトコルの詳細については、ディレクトリ統合とアイデンティティ管理に関する章を参照してください。
Unified CM プラットフォームをベースにした Cisco Unified Communications システム アプリケーション サーバは、Security Enhanced Linux(SELinux)をホスト侵入防止ソフトウェアとして使用します。詳細については、Cisco Unified CM セキュリティの項を参照してください。
Cisco Unified CM とその他のコラボレーション アプリケーション サーバは、通常のサーバとして扱わないようにする必要があります。システムの設定時に行う任意の操作が、開始を試みているコール、または進行中のコールに影響する場合があります。他のビジネスクラス アプリケーションと同様、大規模な設定の変更は、電話の会話を遮断することがないようメンテナンス時間帯で行う必要があります。
アプリケーション サーバ用の標準のセキュリティ ポリシーは、コラボレーション サーバには適合しない可能性があります。電子メール サーバや Web サーバとは異なり、音声サーバでは、画面をリフレッシュしたり、メッセージを再送信したりすることは許可されていません。音声通信は、リアルタイムのイベントです。コラボレーション サーバ用のセキュリティ ポリシーでは、音声システムの設定または管理に関連しない作業がコラボレーション サーバで絶対に行われないことを保証する必要があります。ネットワーク内のアプリケーション サーバで通常のアクティビティと見なされるアクティビティ(インターネット サーフィンなど)は、コラボレーション サーバ上で実行しないようにする必要があります。
加えて、シスコはコラボレーション サーバ用に適切に定義されたパッチ システムを提供しています。IT 組織内のパッチ ポリシーに基づいて、このシステムを適用する必要があります。シスコにより承認されている場合を除き、OS ベンダーのパッチ システムを使用する通常の方法でシステムにパッチを適用しないでください。すべてのパッチは、シスコの指示に従ってシスコまたは OS ベンダーからダウンロードし、パッチ インストール プロセスに応じて適用する必要があります。
導入済みのセキュリティ ポリシーで、デフォルト インストールで提供された以上の OS のロック ダウンが要求されている場合は、OS の強化手法を使用する必要があります。
この項では、ロビーに設置された電話機およびファイアウォールの配置について、セキュリティ面を考慮した実施例を示します。このようなタイプと同様の配置を扱うには、適切なセキュリティ ポリシーを適用する必要があります。
この項の例は、物理的なセキュリティが低いロビー エリアのようなエリアで使用する、電話機およびネットワークを設定する 1 つの方法を示しています。この例に出てくる機能は、いずれもロビーに設置する電話機で要求されている機能ではありませんが、導入済みのセキュリティ ポリシーで、より強固なセキュリティが必要とされている場合は、この例でリストされている機能を使用できます。
いずれのユーザも電話機の PC ポートからネットワークにアクセスできないようにするため、電話機の背面の PC ポートを無効にして、ネットワーク アクセスを制限する必要があります(電話機の PC ポートを参照)。また、攻撃を仕掛けようとしている人が、ロビーに設置された電話の接続先ネットワークの IP アドレスを参照できないように、電話機の設定ページも無効にする必要があります(設定へのアクセスを参照)。電話機の設定を変更できないという欠点は、通常、ロビーに設置された電話機では問題になりません。
ロビーに設置された電話機が移動される可能性は非常に低いため、電話機には固定 IP アドレスを使用できます。固定 IP アドレスを使用すると、攻撃者が電話機を切断して接続することにより新しい IP アドレスを取得するのを防止できます(IP アドレッシングを参照)。また、電話機が抜かれると、ポートの状態が変化し、電話機は Unified CM から登録解除されます。ロビーに設置された電話機のポートでこのイベントをトラッキングするだけで、誰かがネットワークへの接続を試行しているかどうかを判別できます。
電話機のスタティック ポート セキュリティを使用し、MAC アドレスを取得することを許可しない場合、攻撃者は、そのアドレスを発見できたときに、自らの MAC アドレスをその電話機の MAC アドレスに変更しなければなりません。ダイナミック ポート セキュリティを無制限タイマーと共に使用して、MAC アドレスを取得する(取得したアドレスは解除しない)場合、MAC アドレスを追加する必要はありません。これにより、電話機を交換しない限り、MAC アドレスをクリアするためにスイッチ ポートを変更せずに済みます。MAC アドレスは、電話機の底面のラベルにリストされています。MAC アドレスをリストすることがセキュリティの問題と見なされる場合は、ラベルを除去し、デバイスを識別するための Lobby Phone というラベルに置き換えることができます(スイッチ ポートを参照)。
ポートまたはポートが接続されているスイッチに関する情報を攻撃者がイーサネット ポートから参照できないように、単一の VLAN を使用し、ポートで Cisco Discovery Protocol(CDP)を無効にできます。この場合、電話機の E911 緊急コール用のスイッチに CDP エントリは与えられません。緊急番号をダイヤルするときは、ロビーに設置された各電話機に、ラベル、またはローカル セキュリティ用の情報メッセージのいずれかが必要です。
ポート上に DHCP は存在しないため、DHCP スヌーピング バインディング テーブルに静的エントリを定義できます(DHCP スヌーピング:不正な DHCP サーバ攻撃の防止を参照)。DHCP スヌーピング バインディング テーブルに静的エントリを定義すると、VLAN でダイナミック ARP インスペクションを有効にして、攻撃者が、ネットワーク上のレイヤ 2 ネイバーの 1 つに関する他の情報を取得するのを防止できます(ダイナミック ARP インスペクションの要件を参照)。
DHCP スヌーピング バインディング テーブルに静的エントリが定義されていると、IP ソース ガードを使用できます。攻撃者が MAC アドレスと IP アドレスを取得でき、パケットの送信を開始した場合、正しい IP アドレスが設定されたパケットだけを送信できます。
電話機が動作するのに必要なポートと IP アドレスのみを許可する、VLAN ACL を書き込むことができます(VLAN アクセス コントロール リストを参照)。次の例には、ネットワークへのアクセスを制御するための、レイヤ 2 または最初のレイヤ 3 デバイスのポートに適用可能な非常に小規模な ACL が含まれています(ルータのアクセス コントロール リストを参照)。この例は、ロビー エリアで使用されている Cisco 7960 IP Phone に基づいています。電話機への保留音または電話機からの HTTP アクセスは使用しません。
この項の例は、データセンター内において、背後に Unified CM を配置するファイアウォールの 1 つの展開方法を示しています(図 4-16 を参照)。この例では、Unified CM は、すべての電話機がファイアウォールの外側から 1 つのクラスタに接続される集中型配置として置かれています。この配置内のネットワークには、社内データセンター内でルーテッド モードで設定されたファイアウォールがすでに含まれているので、ゲートウェイの配置を決定する前に負荷が確認されます。ファイアウォールの平均的な負荷を確認した後、CPU に対するファイアウォールの負荷を 60% 未満に保つため、すべての RTP ストリームがファイアウォールを横断しないようにすることが決定されました(ゲートウェイの周囲へのファイアウォールの配置を参照)。ゲートウェイはファイアウォールの外側に配置されています。Unified CM でゲートウェイとの間の TCP データ フローを制御するため、ネットワーク内の ACL を使用します。電話機の IP アドレスは適切に定義されているので、ACL は、電話機からの RTP ストリームを制御するためネットワークにも書き込まれます(IP アドレッシングを参照)。音声アプリケーション サーバは非武装地帯(DMZ)に配置されています。Unified CM との間のアクセス、およびネットワーク上のユーザへのアクセスを制御するため、ファイアウォールで ACL を使用します。この設定では、インスペクションを使用してファイアウォールを通過する RTP ストリームの量を制限します。これにより、既存のネットワークに新しい音声アプリケーションを追加したときの、ファイアウォールに対する影響を最小限に抑えられます。
この章では、ネットワーク内の音声およびビデオ データを保護するために有効にできるセキュリティのうち、一部のみを取り上げました。ここで取り上げた手法は、ネットワーク内のすべてのデータを保護するためにネットワーク管理者が使用できる、すべてのツールのサブセットにすぎません。逆に、ネットワーク全体のデータで必要なセキュリティのレベルによっては、これらのツールでさえ、ネットワークで有効にする必要がない場合もあります。セキュリティの方法は、注意深く選択してください。ネットワーク内のセキュリティが高くなると、それに応じて、複雑度や問題のトラブルシューティングも増加します。各企業の責任で、リスクと組織の要件の両方を定義し、ネットワークとネットワークに接続されたデバイスに適切なセキュリティを適用する必要があります。