多過ぎる暗号化規格がセキュアな通信を妨げる：対顧客の暗号化は慎重に

セキュアな通信を実現する暗号化サービスだが、いざ検討をし始めると予想以上に多くの導入問題に直面する。

[Randall Gamby，TechTarget]

　金融機関が取引先やサービス事業者、顧客にもセキュアなインフラを広げようとしている。その実現のために使われている主要技術の1つが暗号化だ。重要情報がインターネットで転送中に傍受されるのを心配するにしても、個人を特定できる情報（PII）など社外秘情報の保護を義務付けた法令に従わなければならないにしても、関係者以外に情報を読めない状態にすることは、それを付け狙う相手から情報を守る唯一の手段だ。しかしセキュアな通信のための暗号化サービスを検討し始めると、予想以上に多くの導入問題に直面する。

　暗号化が機能する仕組みを理解するためには、暗号化サービスが3つの構成要素、すなわち「暗号化を行うシステム」「情報暗号化のために使う暗号標準規格」「その規格で情報の暗号を解読するために使う鍵」──で成り立っていることを理解する必要がある。

　最初の構成要素である暗号化システムは、以下の3種類に分類される。

アプリケーション：電子メールクライアント、プラグイン、ネイティブ暗号化モジュールなど
インフラサービス：メッセージング境界アプライアンス、ポータル、Webサービス、セキュアFTPサーバなど
セキュアな通信：TLS／SSL、Session Initiation Protocol（SIP）など

　問題は、これらの暗号化システムが必ずしも相互運用できるとは限らないということだ。例えばある企業の従業員が個人情報を含む文書を暗号化して取引先に送った場合、受け取った側は、その文書の暗号化に使われたシステムに対応したシステムがない限り、文書を読むことはできない。

　送信側と受信側が互換性のある暗号化システムを持っているだけでは不十分で、受信側は送信側のシステムが使っている暗号化規格にも対応している必要がある。暗号化規格は、Public Key Infrastructure（X.509）、HTML暗号、Identity-Based Encryption（IBE）、S/MIME、SIP、Extensible Messaging and Presence Protocol（XMPP）、OpenPGP、TLSなど幾つもある。アプリケーションやデバイスによっては、対応していない暗号化規格があるかもしれない。例えばBlackBerryでは、デスクトップアプリケーションで暗号化されたファイルを解読できない。単純に、BlackBerryがその暗号化規格をサポートしていないためだ。

　以上のような問題のほかにも、複雑化の要素はまだある。コンテンツの暗号化と暗号解除のためには、受信側が情報解読のための鍵またはパスワードを受け取る必要がある。さらに、それが対称鍵なのか非対称鍵なのかも知らなければならない。場合によっては、例えばトランスポートレベル暗号などの場合、この情報がエンドユーザーには隠されていることもあるが、アプリケーションや電子メールシステムで暗号化した場合には、受信側はその情報にアクセスするために、前もって鍵を生成または入手しておく必要がある。

　いずれにしても、特に取引先や顧客の数が多い企業にとっては、鍵の管理と配布は多大な負担になりかねない。中でも顧客をセキュアなコンテンツにアクセスさせるのは厄介だ。顧客というのは一般的に、企業のリソースへのアクセスは制限されるが、ヘルプデスクへの電話を激増させないためには、鍵を簡単に入手できるような環境が求められる。

　エンタープライズのサービスはどれもそうだが、企業は取引先や顧客との通信に暗号化をどう利用するかについて、念入りに計画・設計する必要がある。これには技術アーキテクチャ、重要情報送信のための新しいプロセス、コンテンツの暗号解除方法に関する受信側との情報共有のための新しい外部通信チャネル構築が含まれる。場合によっては送信側と受信側双方を対象に、暗号化サービスを使った相互通信の方法に関する研修プログラムも必要だ。

　組織は通信したい相手の能力を理解して、その相手が自分たちのためにサービスを管理・運営してくれるかどうかを見極める必要がある。さらに、大人数の顧客といった外部の集団の場合は一般的に、顧客のアプリケーションがメッセージの暗号解除のために必要な鍵を取得できるよう、簡単にアクセスできる登録プロセスが求められる。

　セキュアな通信の管理が複雑なことから、セキュアなコンテンツは自社のインターネット対応ポータルとWebアプリケーションにのみ置くと決めた金融機関も多い。そして取引先や顧客をこうしたサイトに連れてきて受信者認証を行い、自社の重要情報にアクセスさせて自分たちで強力なコントロールがかけられる自社の環境に暗号化アーキテクチャをとどめておく。

　この短期的な「プル型」の暗号化サービスでは、社外の無数の組織に暗号化サービスを導入させる必要性は省けるが、こうしたソリューションを導入するコストに加えて、サービス運営のための顧客の研修、サポート、メンテナンスなどのコストで予算が圧迫されることも多い。しかし、暗号化サービスを構成する3つの要素それぞれにおいて共通の規格が完成するまでは（または少なくとも少数の選択肢に絞られるまでは）これが最も実用的なソリューションかもしれない。

　ところで保険業界は、アメリカ独立保険代理店・ブローカー協会傘下のAgents Council for Technology（ACT）が2006年にまとめた報告書「Independent Agency Preferences for Carrier Electronic Communications」（保険会社の電子通信に関する独立系代理店の要望）でセキュアな通信の問題に対応した。報告書では、代理業務を委託されている保険会社から代理店へのセキュアな通信はどのような形が望ましいかを挙げ、全般的に一致した意見として、顧客の個人情報は保険会社のサイトに置いたポータルに記録し、代理店は電子メールの通知でリンクを受け取ってセキュアなTLS／SSL接続でそれにアクセスする方法が望ましいとした。

　この報告書は1つの団体の希望を述べたにすぎないが、重要情報を送信する方法の標準化へと保険会社を動かすきっかけとなった。金融機関が業界の垣根を越えてセキュアな通信システムを自分たちの業界の外に持ち出せるようにするには、暗号化ニーズの複雑さを解消するため、ほかの業界も同様の作業を行う必要がある。

本稿筆者のランドール・ギャンビー氏はFortune 500社に数えられる保険金融機関のエンタープライズセキュリティアーキテクト。セキュリティ業界で15年以上の経験を持つ。専門分野はセキュリティ／ID管理戦略、方法論、アーキテクチャ。