マッシュアップにおけるセキュリティー
マッシュアップでは、Web APIやウィジットとして定義されたコンポーネントを組み合わせることで、複合アプリケーションを構成します。例えば、Google Mapなどの地図と、店舗データをマッシュアップしたり、乗り換え案内と社内の精算システムとを組み合わせたりといった例が典型的です。現在は、Web上のコンポーネントを組み合わせることが多いですが、SaaSやクラウドコンピューティングが注目を集めている今、企業内のコンポーネントとWeb上のコンポーネントを組み合わせるシナリオが増えてくると思われます。社内のコンポーネントと、Web上のコンポーネントでは所属するセキュリティードメインが異なりますし、攻撃されたWeb上のコンポーネントが、マッシュアップされた企業内コンポーネントを攻撃するという危険性も同時に増えてくるでしょう。
マッシュアップの形態には、サーバーサイドマッシュアップ（図4）と、クライアントサイドマッシュアップ（図5）の2種類が考えられます。サーバーサイドマッシュアップは、アプリケーションサーバーがサービスを行うサーバーに接続し、サービスを統合します。この場合、クライアントは、仲介・統合するアプリケーションサーバーに接続するため、もともとのサービスを行うサーバーを関知することができません。言い換えると、あるデータが信頼できるサーバーから来ているのか、そうでないかが、クライアント側ではわからないということになります。
一方、クライアントサイドマッシュアップは、Webページ上で複数のサーバーからのサービスを呼び出し、Webブラウザー上で実行します。そもそも、Webブラウザでは、異なるドメインのサーバーからダウンロードされたJavaScriptは、ダウンロード元のサーバーにしかアクセスすることができないというSame Origin Policyが実装されているのですが、いくつか抜け道があります。例えば、<script>タグのsrc属性に別のサイトのダウンロードページを指定することで、異なるサイトのJavaScriptファイルを読み込むことができます。この場合、異なるメインのコードが混在することになり、悪意を持ったスクリプトを含んだコンポーネントから他のコンポーネントへアクセスし、重要な情報を盗み出すことが可能になります。
IBMでは、日本IBM 東京基礎研究所の筆者らのチームとアメリカにあるワトソン研究所が共同で、Secure Mashupと呼ばれる、コンポーネント同士のセキュアな情報アクセス制御技術を研究開発しています。Secure Mashup技術を用いることで、コンポーネントAからBへのアクセスは許すが、BからAへのアクセスは許さないといった、情報流の制御が可能になります。現在Secure Mashupは、JavaScriptで実装されており、Ajax技術の普及を目指す業界団体であるOpenAjax Allianceに寄贈されています。コンポーネントが直接通信するのではなく、ハブと呼ばれるコミュニケーションコンポーネントを介した通信を行うことで、きめ細やかなアクセス制御を実現しています。
おわりに
Web 2.0技術を用いたWebアプリケーションにまつわるセキュリティの問題をいくつか取り上げ、紹介しました。セキュリティーには100%安全ということはまずありません。いくつかの対策を組み合わせて100%に近づけていくことが必要です。Webアプリケーションの開発者はセキュリティーの専門家ではないことが多いでしょうから、必要最低限の知識と定評のあるセキュリティ製品やツールをうまく使いこなしていくことが重要だと思います。
