こんにち、たいていのアプリケーションおよびシステムにおいて、セキュリティ問題に対する懸念が高まっている。小型のマッシュアップ、エンタープライズアプリケーション、またはSOA向けプラットフォームのどれを構築しようが、議論されている問題やアプローチがいくつかある。Erica Naone氏が、マッシュアップ界のセキュリティ(source)の取り扱いについて語った。また、BEAのBob Rhubart氏(ブログ・英語)およびDavid Garrison氏(ブログ・英語)が、デプロイするサービスの保護について討論した。Naone氏は、OpenAjax Alliance(source)、Microsoft Research(サイト・英語)、情報セキュリティ会社のMandiant(サイト・英語)およびマッシュアップ製造業者のJackBe(サイト・英語)の業界専門家と討論し、マッシュアップのセキュリティの現状および今後の問題について検討した。一般に、ブラウザセキュリティモデルはセキュリティマッシュアップにモデルを提供するというタスクには不十分である。
http://www.infoq.com/news/2008/04/security-for-mashups
Webブラウザはマッシュアップを考慮して設計されていない。 それゆえ、「当初から欠点があった」と(OpenAjax Allianceの共同創立者であり、IBMのEmerging Internet TechnologiesのCTOであるDavid Boloker氏は)語る。ブラウザには同一生成元ポリシーと呼ばれるセキュリティ機能があり、あるサイトでホストされている悪質なコードがその他のサイト で格納さている資格情報などのデータを取得することを不可能にする。同一生成元ポリシーは、あるドメインのWebサイトが他のドメインに属 しているデータを要求することを阻止する。
Microsoft ResearchのシステムおよびネットワークグループのHelen Wang氏が、同一生成元ポリシーの短所という突っ込んだところまで話を進めている。
提案されているソリューションの中には、さらなる制御の追加と相まったブラウザにおける同一生成元ポリシーの緩和がある。Wang氏は、外部コードのサン ドボックスという形式で、ブラウザ内で制御が機能するようにし、過剰のアクセスを防止することを提案している。その他に推奨されるものとしては、ブラウザ を変更せずに、外部の第三者のツールが通信およびアプリケーションを保護するというものである。その一例がSMashであるが、それは近ごろIBMによって 発表された「セキュアマッシュアップ」アプリケーション(source)である。同一生成元ポリシーの欠点は、「こんにちのWebアプリケーションがセキュリティか機能のどちらか一方を犠牲にしている」ところにある。マッシュアップなどの多くの素晴らしい機能は、複数のソースのツールを使用することで実現すると語る。問題は、Webサイトの作成者が第三者によって記述されたコードを自 身のサイトに組み込んだ場合、もはや同一生成元ポリシーは保護を提供せず、組み込まれたコードは作成者のサイトに保管されている情報へアクセスする可能性がある。
SMashは、セキュア通信チャネルを通じたデータの共有の制御を可能にしながら、別々のソースからのそれぞれのコードおよびデータを保持することで、ブラウザマッシュアップセキュリティ問題の根源に対処している。マッシュアップセキュリティは未解決であり、Web 2.0アプリケーションがますますユビキタスになるにつれて、さらに懸念が高まるだろう、というのが業界の一致した見解である。すべてのアプリケーションがマッシュアップというわけではないが、BEAはそれぞれの組織にデプロイされる予定のサービスを作成しているデベロッパに焦点を当てている。Bob Rhubart talked氏は、企業での全体的なSOAイニシアチブの一部としてセキュリティ(ブログ・英語)について語った。あらゆるSOAのガバナンス全体にとって、セキュリティ は基本的なものであると述べた。
セキュリティがSOA Goveranceの重要な一部であることを説明することは、水が魚の生活にとって重要な一部であることを説明するようなことであり、つまりそれは明らかな ことである。SOAガバナンスのその他すべてのように、セキュリティは多面的な問題である。しかし、SOAセキュリティは、詰まるところ1つの単純な質問 の答えを知るということになる。それは誰が使うのかということである。SOAにデプロイされている各サービスは、かなりの投資とすばらしいROIの可能性を秘めてい る。SOAガバナンスの基本的な目標の1つは、各サービスを使用することで、つねに期待される成果を生むようにすることである。その成果を実現する要とな るのは、それらのサービスを利用する者の統制で、また実際にそのサービスの使用方法を制御することである。その方法例として、Rhubart氏はDavid Garrison氏およびBEAのSecurity Servicesフレームワーク(ブログ・英語)を指摘した。Garrison氏は、BEAは製品内でSecurity Servicesフレームワークモデルを使用していることを指摘し、それからAquaLogic Enterprise Security (ALES)製品を使用することによる、そのようなフレームワークの設計原理を議論した。Garrison氏は、セキュリティサービスフレームワークには、主に5つのサービス/プロバイダーがあることを確認し、それぞれの役割について説明している。その5項目は以下のとおりである。
- 認証
- ロールマッピング
- 許可
- クレデンシャルマッピング
- 監査
当然、上記の項目は従来のアプリケーションにフォーカスしたセキュリティフレームワークと同様である。
原文はこちらです：