はじめに

各企業は「環境に配慮する」ための取り組みの中で、ビジネスにおける新たな戦略を進めています。一部の企業は、テレコミューティングを推奨することによって、人の行き来を減らすとともに、オフィス空間でのエネルギー使用量を削減しようとしています。また別の企業は、「マッシュアップ」アプリケーションやアウトソースによるホスティングを利用することで、必要とされるシステム・リソースを削減しようとしています。しかしこうした戦略を進める中で、企業の中央で管理していたリソースが分散するにつれ、一定の場所にリスクを封じ込めることが次第に困難になってきています。そのため、セキュリティー手順が一層重要となり、また各コンポーネントを今まで以上に精査する必要があります。

この記事では、地球に優しい環境を作る上で、重要な役割を果たすいくつかの戦略に注目するとともに、対処しなければならない特定の領域のリスクについても見て行きます。具体的には、テレコミューティング、マッシュアップ・アプリケーション、そしてアプリケーションのホスティングについて検証します。

テレコミューティング

テレコミューティングは、オフィスに関する費用を削減する方法として一般的になりつつあります。テレコミューティングによって従業員にもたらされるメリットには、毎日車を運転する必要がなくなったり、柔軟にスケジュールが組めるようになったり、文字どおり家でのあらゆる快適さを享受できるようになったり、といったものがあります。またテレコミューティングによって、地球環境にもさまざまなメリットがもたらされます。テレコミューティングは、交通量を減らすことができる上、交通に関わる問題も減らすことができます。また、オフィス空間が無秩序に広がるのを防ぐことができるとともに、オフィスの暖房や冷房、そしてオフィスを清掃するための人員などに関連するリソースを削減することもできます。

しかしテレコミューティングでは従業員を企業環境の外に配置することになるため、特定のセキュリティー問題が増加します。以前は企業構内にあって、アクセスが制限され、保護されていて、セキュアに保たれていたデータが、突然、人々の家という制御できない環境に出てしまいます。だからと言って、テレコミューティングは危険であり、避けるべきであると言っているわけではありません。単純に、テレコミューティングを利用する従業員は危険を認識する必要があり、また外部から安全に作業を行うためのポリシーや手順を彼らに提供する必要がある、ということです。

ほとんどの企業は既に、VPN 接続を使って社員ユーザーがバックエンド・データにアクセスできるようにしています。しかしテレコミューティングを利用する人達には、さまざまなコラボレーション・ツール (インスタント・メッセージング機能やリモート・ミーティング機能など) が絶対に必要です。皆さんの会社の従業員が使用するツールは、セキュアであり、その環境外に非公開となっているでしょうか。それとも、インターネットを介してオープンに通信する公開ツールを使っているのでしょうか。

セキュアなインスタント・メッセージング機能は、IBM Lotus® Sametime のような商用ツールや Jabber などのオープンソースのツールを使うことで実現することができます。リモート環境にいる従業員が効率的にコミュニケーションを行うためには、ウィキや仮想ミーティング機能など、他のコラボレーション・ツールも必要かもしれません。選択肢としては、そうした機能を社内で VPN を使って提供する方法もあり、あるいはアウトソースする方法もあります。ただし、それによって生じるセキュリティーの問題を検証する必要があり、気付かないうちに機密情報をブロードキャストしてしまうことが絶対にないようにする必要があります。

テレコミューティングによる連携作業に関連するもう 1 つの弱点がユーザーのラップトップです。パワーオン・パスワードの使い方に関して、ポリシーは用意されているでしょうか？ユーザーがラップトップに保存するデータに関して、ルールは決められているでしょうか？アプリケーションが、機密データをローカル・マシンにセキュアでない状態でキャッシュすることはないでしょうか？ローカル・システム上のデータを暗号化する方法がユーザーに提供されているでしょうか？一部の商用 E メール・システム (Lotus Notes など) には、ローカルの E メールを自動的に暗号化する手段が用意されています。他にも、外部システムを扱うツールは豊富にあります (例えばオープンソースの GPG は E メールを暗号化します)。ドライブ・スペースを暗号化する方法は、商用であれオープンソースであれ、数多くあります。

重要なことは、テレコミューティングを行う従業員に対して、機密データをセキュアに保つための明確なポリシーを提供し、指導を行うことです。彼らにはセキュリティー・チェーンでの彼らの役割を明確に理解してもらう必要があり、またツールと教育の面で彼らをサポートしなければなりません。

マッシュアップによるセキュリティー・リスク

マッシュアップはリソースを節約するための優れた方法です。マッシュアップを利用すれば、堅牢なアプリケーションを既存のリソースを利用して作成することができ、独自にアプリケーションを作成する必要がありません。マッシュアップでは、Web サイト、企業のデータベース、あるいは E メールなど複数のソースからの情報を統合し、1 つの統一されたビューを作成します。マッシュアップは多くの場合 Ajax を使って作成され、内部ソースからのデータと外部ソースからのデータとを統合しています。例えば、経路を示すアプリケーションや顧客分析アプリケーションをサポートするために、これらのアプリケーションの情報を Google マップと組み合わせることで、技術者ではないユーザーにも複雑な状況を理解しやすく表現することができます。

ただし、マッシュアップには特有のリスクがあります。皆さんは、自分達が使用するデータのソースを理解しているでしょうか？そのデータは正確でしょうか？そのデータを使用することは合法的でしょうか？他のアプリケーションで定義されているコールバック関数を呼び出すと何が起こるのでしょうか？気付かないうちに第三者と機密データを共有していないでしょうか？これは、皆さんが恐れをなしてマッシュアップ・アプリケーションから遠ざかるようにするための警告ではありませんが、企業用にマッシュアップ・アプリケーションを作成する際には、こうした点を考慮し、またテストしておく必要があります。

こうした例として、MySpace の API で削除されずに非推奨となっているものに関する問題が、開発者達によって見つけられたことがあります。これらの API を使用していたアプリケーションは、非推奨となった API を悪用するハッカー達の攻撃を受けやすかったのです。

セキュアなマッシュアップ

では、どのようにしてマッシュアップをセキュアに保つのでしょう。そのためには、自分達が使用するリソースのセキュリティー上の弱点に関するニュースに注意することです。Google マップなどの機能にセキュリティー上の弱点が発見されると、通常はそのニュースが公開されます。セキュリティー上の弱点をレポートするリソースを見つけ、そうしたリソースを常に注視します。Security Focus (「参考文献」を参照) などのサイトはセキュリティー上の弱点および脆弱性に関する大量の情報を収集しているため、これらのサイトは注意して見ておく価値があります。

脆弱性に対する保護のために最近使われる方法として、危険なリソースや手法を認識するインテリジェントなツールを使う方法があります。こうしたツールについて調べてみると、いくつかの方法があることがわかります。しかしここでは、動的な Web アプリケーションを作成するための開発および実行用プラットフォームである、IBM Research の WebSphere® sMash を紹介します。WebSphere sMash は Project Zero インキュベーション・プロジェクトをベースとしており、無料でダウンロードすることができ、また制限はありますが複数のプラットフォームにデプロイすることができます。

WebSphere sMash は Web 2.0 技術を使用しており、PHP スクリプト機能と REST、そして Dojo が組み合わされ、1 つのランタイムおよびツールのパッケージに統合されています。WebSphere sMash の PHP 5.2 以降のランタイムは Java™ で実装されています。PHP プログラマーは Java ライブラリーを利用できる一方、Java プログラマーは PHP のアプリケーションとライブラリーを利用できるため、Java コードと Groovy コードをマッシュアップすることができます。

WebSphere sMash を利用すると、システム・レベルの認証と承認を実装できるため、悪意のあるコードから保護することができます。アプリケーション開発者は、ACF (Active Content Filtering) と呼ばれる機能を使ってセキュリティー・ルールを定義することができます。このセキュリティー・ルールによって、どのリソースを保護するか、どのような手段でリソースを保護するか、そしてどのユーザーやグループに対してそうしたリソースへのアクセスを許可するか、といったことが決定されます。ACF は特に、CSRF (Cross Site Request Forgery) や XSS (Cross-Site Scripting) から保護するために設計されています。CSRF 攻撃では、Web サイトが信頼するユーザーから、ユーザーが許可したものではないコマンドが送信されます。XSS は Web アプリケーションに対するユーザーの信頼を悪用します。例えば、ユーザーがリンクをクリックして Web アプリケーションを開くと、そのアプリケーションには悪意のある JavaScript が含まれており、そのユーザーのセッションをハイジャックするのです。

マッシュアップが一般的に使われるようになるにつれ、これら以外にもマッシュアップをセキュアにするための戦略やツールがいくつも登場してくると思われます。

既存のマッシュアップ・アプリケーションの例には、顧客の Excel シートを読み取って ERP システムと統合する Jibes のアプリケーションや、従業員間のコラボレーション、情報共有、そして交流を促進する、ZSL による Enterprise 2.0 SocNet などがあります。ZSL はこのツールを拡張してサービス指向のクラウド・コンピューティング・サービスとして提供しており、これは現在 CaaS (Collaboration as a Service) として利用することができます (CaaS は CiC (Collaboration in Cloud) と呼ばれることもあります)。

こうした、あるいは他のマッシュアップ・リソースを利用する際には、皆さん独自のセキュリティー基準を設定する必要があります。

アウトソーシング

最後に、アウトソーシングについて少し説明します。システムやアプリケーションをリモート・ホスティングすることで、エネルギーとリソースを大幅に節約することができます。ただしこの場合も、企業の信頼できるゾーンの外部にリソースを配置することになります。外部の企業と連携する場合、セキュリティーやダウンタイムの問題に遭遇しないためにはどうすればよいのでしょう。それには、事前に適切な質問をして、確実な合意を得ておく必要があります。

サービス・レベル・アグリーメント

どのようなアウトソーシングの場合も、明確で詳細な SLA (Service Level Agreement: サービス・レベル・アグリーメント) が必要です。SLA はサービス・プロバイダーと顧客との間の正式な契約であり、数値化可能なネットワーク・パフォーマンスを規定のレベルで保証します。サービス・プロバイダーとしては、社内の IT 部門や、ASP (Application Service Provider: アプリケーション･サービス･プロバイダー)、NSP (Network Service Provider: ネットワーク･サービス･プロバイダー)、ISP (Internet Service Provider: インターネット･サービス･プロバイダー)、MSP (Managed Service Provider: マネージド･サービス･プロバイダー) など、さまざまな種類が考えられます。

SLA は非常に一般的なものもあれば極めて詳細に記述されたものもあります。通常 SLA には、障害が起きた場合にサービス・プロバイダーと顧客が取るべき手順が含まれています。サービス・プロバイダーは、そのプロバイダーが提供するサービスを利用可能な時間に関して一定の割合 (例えば 99.9% など) で保証します。

プロバイダーはさらに、次の 4 つのことを行うこともできます。第 1 に、Web アプリケーション・サーバーの最大応答時間と平均応答時間を SLA に規定することができます。第 2 に、コンテンツを利用可能な時間やリソースを共有可能な時間の最大値を SLA に規定することができます。第 3 に、同時にサービスを提供可能な最大ユーザー数を SLA に規定することができます。第 4 に、SLA の対象となる顧客に対して、ダウンタイムを通知したり、ネットワーク・インターフェースの変更を事前に通知したりします。

プロバイダーが指定の期間中に規定のパフォーマンス・レベルを満たすことができない場合には、顧客には然るべき権利と賠償等の救済手段が提供されます。こうした権利や救済手段、そして例外は、SLA ごとに異なります。また、SLA の一般条項に対する指定の例外を受け入れることに顧客が合意する場合もあります。

質問をする

問題は、プロバイダーが、開発者やデプロイ担当者の期待どおりのことをするとは限らないことです。皆さんは、プロバイダーがどこでホスティングするのか、そのプロバイダーの脆弱性は何か、等の情報を得た上で判断を下す必要があります。場合によると、そうしたことの一部に関してプロバイダーがリスクや責任を負わない場合に、皆さんがリスクや責任を負う必要があるかもしれません。皆さんは開発者として、リスクを認識する必要があると同時に、プロバイダーがカバーしないことを皆さん自身がカバーする方法を理解しておかなければなりません (セキュリティーの制御を適用することでリスクを軽減する、など)。重要なことは質問をすることです。もしプロバイダーが皆さんの求める答えを提供できない場合には、マッシュアップおよびその他の Web アプリケーションをセキュアにするための準備をする必要があります。

下記の表は、サービス・プロバイダーに確認するとよい質問の例を示したものです。

これらの質問に対する回答が得られたら、高いリスクや中程度のリスクを受け入れ可能なレベルにまで軽減する上で、プロバイダーが提供できないセキュリティー制御はどれかを判断します。コストがセキュリティー制御の利点を上回るようではいけません。コストが高い場合には、もっとコストのかからないセキュリティー制御に変更する必要があるかもしれません。また、セキュリティー制御を適用した後にも、残存リスクと呼ばれるリスクが残ってしまうかもしれません。残存する高いリスクの数を減らすためには、セキュリティー制御を変更するか、あるいはアプリケーションを更新する必要があるかもしれません。

仮想化環境を保護する

セキュリティーの専門家や開発者は、Web アプリケーションを実行する仮想化環境がどのように機能し、取り交わされた SLA をどのように実現するのかについて、仮想化に移行する前に関心を持つ必要があります。テレコミューティングする人のコンピューター上の仮想マシンや、バックエンド・システム上の仮想マシンは、保証されたアップタイム (つまり可用性) に影響を与える可能性のある悪意のある振る舞いから、どのようにして保護されるのでしょう。

仮想化環境にセキュリティーを適切に統合する手段として、VMware の VMsafe などを利用することを検討してください。IBM は VMsafe の開発メンバーであり、他の多くのセキュリティー企業と同様、VMware API を使用してハイパーバイザーを活用することで、セキュリティーが強化された設計の製品を提供し、アップタイム (つまり可用性) を改善することを計画しています (実際に VMware API を使用した製品もあります)。

VMsafe は VMware のハイパーバイザーの内部をある程度まで見られるようにするための API です。セキュリティー・ベンダーはこの API を使用することによって、ウィルスが動作できないようにするためのツールの作成や、ネットワーク・トラフィックの監視、仮想マシンと統合されたファイアーウォールの作成、さらにはパッチ管理や脆弱性評価なども行うことができます。VMsafe は仮想アプライアンスとして実行される仮想シールドの問題をいくつか解決しています (例えば既存のセキュリティー監視システムと部分的に統合することができます)。IBM の研究者達は、ハイパーバイザーを保護し、仮想環境間の通信を監視する新しいセキュリティー技術を開発中です。

まとめ

企業は、ビジネス面および環境面のどちらにおいても、リソースの削減に関するさまざまなプレッシャーにさらされています。実装の詳細を見落とすことでリスクが高まるようなことがあってはなりません。セキュリティーに関する責任について、テレコミューティングする人達に必ず明確に理解させる必要があり、また機密情報をセキュアに扱うために必要なツールを彼らに提供したり、あるいはそうしたツールを使うよう指導したりする必要があります。マッシュアップ・アプリケーションの脆弱性を認識するとともに、許可されていないデータを取得してしまったり、悪意のあるコードを実行してしまったりすることがないように、新たな対策を探し求める必要があります。最後に、ホスティングのアウトソース先やアプリケーション・プロバイダーを探す場合には賢明な判断が必要です。適切な質問をし、皆さんと皆さんの顧客の関心事項が守られるような確実な合意を得る必要があります。

詳細部分にまで注意を払うことによって、技術を使用してビジネスを行うための新たな方法へ、自信を持って、比較的安全に移行することができます。

参考文献

学ぶために

• Secure Focus の Web サイトで悪用と脆弱性に関するニュースを探してください。
  
  
• マッシュアップをセキュアにするための、IBM Research による sMash について、そしてその基礎となったプロジェクトである Project Zero について学んでください。
  
  
• developerWorks の記事「Active Content Filtering で強化する Project Zero および WebSphere sMash アプリケーションのセキュリティー」を読み、ACF について学んでください。
  
  
• VMWare の VMsafe について、その Web サイトから学んでください。
  
  
• Judith M. Myerson によるシリーズ記事、「WebサービスのコンテキストにてSLAを使用する」ではサービス・レベル・アグリーメントを詳細に解説しています。
  
  
• Ajax ツールに関する情報が必要な場合には「Ajax - 困っている人のためのガイド、第 1 回: Ajax のツールと手法の調査」(Gal Shachor、Yoav Rubin、Shmulik London、Shmuel Kallner の共著、developerWorks、2007年7月) を読んでください。
  
  
• 「SOA における密結合の Web サービス」(developerWorks、2008年1月) を読んでください。
  
  
• Judith M. Myerson 著の『The Complete Book of Middleware』を読んでください。システム設計における基本原則と優先順位に焦点を当て、E コマースや分散統合システムの登場による新たな要件を強調しています。
  
  
• ビジネスを洞察し、また技術ノウハウを身に付けてシステム統合を確実に成功させるために、『Enterprise Systems Integration, Second Edition』を読んでください。
  
  
• 『RFID in the Supply Chain』を読み、皆さんの組織を将来に導いてください。この本では、ビジネス・プロセス、オペレーションや実装の問題、リスク、脆弱性、セキュリティーとプライバシーなどを解説しています。
  
  
• developerWorks の Technical events and webcasts で最新情報を入手してください。
  
  
• My developerWorks で developerWorks のエクスペリエンスをパーソナライズしてください。
  
  

製品や技術を入手するために

• Project Zero の Web サイトから WebSphere sMash Developer Edition をダウンロードしてください。
  
  
• アーキテクチャー管理のための IBM Rational Web Developer for WebSphere Software、変更管理とリリース管理のための IBM Rational ClearQuest、そして品質管理のための IBM Rational Functional Tester Plus が Ajax アプリケーションその他のアプリケーション開発にどう役立つかを学んでください。こうした IBM のツールを利用することで、企業内でのテスト時間やテスト・ラボのコストを削減できるため、生産性を高めることができます。
  
  
• developerWorks から直接ダウンロードできる IBM ソフトウェアの試用版を利用して、皆さんの次期プロジェクトを構築してください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• はじめに
• テレコミューティング
• マッシュアップによるセキュリティー・リスク
• セキュアなマッシュアップ
• アウトソーシング
• まとめ
• 参考文献
• 著者について
• コメント