PART4 Skypeといかに付き合うか：特集：Skypeは企業IP電話を変えるか（2/3 ページ）

[岩田 真一（アリエル・ネットワーク），N+I NETWORK Guide]

●サーバ、交換機は「関所」

　クライアント／サーバ型のシステムでは、ユーザーがやり取りする情報はすべてサーバを経由する。サーバが、いわゆる関所の役割を果たす。社内のシステムでいえば、インターネットへ出ていく（もしくは入ってくる）データは、すべてサーバを介す必要がある。PBXでも同様だ。内線と外線を区切っているのはサーバにあたる交換機であり、つまり関所である。P2Pのシステムを社内に導入するということは、今まで関所を経由する必要があったインターネット越しの情報共有を、各クライアント（ノード）が直接行う可能性が出てくるということだ（図1）。

図1●クライアント／サーバ型とP2Pにおけるデータのやり取り Skypeは各PCが直接インターネット経由での通信を行う

●PBXレベルのaudit機能は必要か

　Skypeの導入で問題となってくるのは、現在の社内電話で社員の通話記録や発着信履歴を利用している場合だ。Skypeでは各クライアントに通話履歴が残るものの、経由する交換機やサーバがないため、管理者が一元的に通話履歴を記録・監視することはできない。Skype for Businessでは、エンタープライズ導入に向けてaudit（監査）機能を実装することも考えられる。

　一方、これまで社内電話の通話履歴を使用していない組織ではそのような心配がないため、状況はシンプルだ。その場合、単純にSkypeがもたらすコスト効果や、ほかのソフトウェアとの連携にメリットを見いだせる。

ピア発の情報漏えいへの対応

　情報漏えいという観点からP2Pアプリケーションを見た場合、管理者としてはネガティブな反応を示すことになりそうだ。というのも、これまでのサーバ経由と異なり、P2PアプリケーションではPC（ピア）から直接インターネット経由で情報が発信されていくからである。Skypeの音声通話に限定すれば、秘密裏に情報が漏えいしていくリスクは電話の場合と変わらないが、社内情報が含まれたファイルの流出などには神経を使わざるを得ないだろう。ピアから直接インターネット経由でデータがやり取りされることを考えると、P2Pアプリケーション側の対応も求められる。

●対応（1）：匿名性の排除と電子署名

　まず基本となるのは、匿名性の排除だ。具体的には、全ユーザーに対して信頼された機関からのPKI証明書を発行し、証明書を使用した認証を行う仕組みとなる。

　次に必要となるのは、公開するデータと公開したユーザーのひもづけである。そのためには、ユーザーがデータをP2Pアプリケーションに登録する際（共有状態になる際）に、それぞれのPKIの鍵で電子署名を行うようにする。また、他人が共有したデータを受信する際に電子署名を検証することで、データそのものが第三者によって改ざんがされていないかをチェックすることができる。

●対応（2）：「うっかりミス」を防ぐルールファイルの実装

　悪意あるユーザーによる情報漏えいを防ぐ上記のような仕組みのほかに、善意のユーザーの「うっかりミス」に配慮することもまた、P2Pアプリケーションには必要だ。たとえば、「マル秘」などのキーワードを含むデータを誤って社外に漏えいしないように、P2Pアプリケーションに登録する際にアラートを上げたり、登録を拒否するなどである。その際に適用されるポリシーは組織によって異なるため、システム管理者がルールを決められる仕組みが必要となる。管理サーバによって設定されたルールファイルが、P2Pネットワークによって各ノードに流通（*2）するような仕組みだ。各ノードはローカルに取得したそのルールに従う（図2）。これで、データのやり取りはP2Pで行いつつ、ルールファイルだけは一元的に更新することができるようになる。

図2●ルールファイルで情報漏えいを防ぐ ルールファイルは管理者が一元管理し、各ノードに配布される。実際のチェックは、そのルールに基づいて各ノード上で行われる

●対応（3）：ピアのログ管理

　サーバのあるシステムでは、ユーザーのログイン状況、データの操作などの情報がすべてサーバのログに記録される（*3）。ところがP2Pでは、ログファイルは分散配置された各ピアに生成される。たとえば、Skypeではテキストチャットのログなどがそうだ。ログファイルは、システムに問題や障害があった場合、過去をさかのぼる唯一の手がかりである。そのため、P2Pアプリケーションには、各ピアのログファイルを後から回収する仕組み（図3）と、集めたログを解析する管理サーバが必要となるだろう。

図3●P2Pアプリケーションでログを管理する方法 集計サーバを設置し、各ノードのログを収集／解析。リアルタイム性は弱いが、オフライン状態で行われた処理のログも取ることができる

　これらのリスクをそれほど懸念せず、サーバやメンテナンスがいらない手軽さ、つまり「縛りよりも効率」を重視する組織であれば、P2Pアプリケーションから十分にメリットを享受できるだろう。

P2Pネットワークをいかに管理するか

　これまでは主にシステム管理者の立場でP2Pアプリケーションを見てきたが、ここでは企業のネットワーク管理者の立場から考えてみよう。

●ネットワーク帯域への影響

　WinnyなどのP2Pファイル交換ソフトによるトラフィックの増大が、ネットワーク帯域の圧迫を招いていることは事実だ。特にIXやISPの接点などでは、深刻な事態としてしばしば取り上げられる。そのような背景もあり、P2Pアプリケーションを社内システムとして導入する際、ネットワーク管理者がまずその帯域消費を懸念するのは当然である。

　これまでも、メールサーバやグループウェアサーバの応答遅延、Webの閲覧に時間がかかるなど、既存のネットワークアプリケーションでも帯域制御は必要だったが、P2Pアプリケーションでは特別な注意が必要になるのだろうか。その違いを見ていこう。

---

*2　ただし、ルールファイルの流通状況には気をつけなければいけない。1つでもルールの更新が行き届かないノードがあると、一時的とはいえ、セキュリティホールになるからだ。この即時性に対する弱点は、遊休資源を使用できるP2Pの非同期性というメリットの裏返しである。

*3　裏を返せば、サーバアプリケーションは、サーバと接続しているとき（ログイン時）しか、ユーザーの操作を記録できないということである。これはP2Pアプリケーションにかぎった話ではないが、ローカルでログを取るという仕組みは、（リアルタイムではないにしろ）これまで不可能だった「オフライン時のユーザー操作」のログ取得を可能にする。