GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。
作者 Abel Avram , 翻訳者 竹中 翔 - (株)ポータルアイランド 投稿日 2009年7月6日
Helen J. Wang氏率いるMicrosoftリサーチチームは、インターネット利用時の堅固なセキュリティを目的としたブラウザベースOS、Gazelle (PDF)を作成した。
GazelleはWindowsライクな新しいオペレーティングシステムではなく、マルチプリンシパルオペレーティングシステムとして動作するカーネルを持った、新しいタイプのブラウザである。このカーネルが、リソース保護と様々なWebサイトプリンシパル間のリソース共有を担当する。セキュリティプリンシパルとは、“コンピュータシステムやネットワークによって認証可能なものであり、認証はこのようなものの身元(アイデンティティ)を検証・確認する処理”である。MicrosoftリサーチチームのメンバーであるJanie Chang氏は、ブラウザプリンシパルが何であるか定義し、なぜセキュリティの問題に適しているかを説明している。
ブラウザ界の用語では、一般的にプリンシパルはWebサイトと同一です。一般的にPC上に一人のユーザが存在する時、リソースの共有とは実質的には異なる起源からアプリケーションにアクセスすることです。Webページの場合、各ページは異なるプリンシパルのコンテンツで構成され、各々がコンピュータリソースの共有を行います。従って、ブラウザがプリンシパルとリソース要求を管理するアプリケーションプラットフォームであるというのは自然なことです。
Webページは他のWebプリンシパルの広告やニュースフィードのようなコンテンツを提供するでしょう。ブラウザは未だ、これらの全てのプリンシパルを同じプロセスや保護ドメイン内に共存させます。広告が悪意のあるコードや出来の悪いコードを含んでいれば、ネットワークを占有したり、パフォーマンスを悪化させたり、ページ全体をフリーズさせたり、或いはブラウザをクラッシュさせたりしてしまいます。ブラウザオペレーティングシステムでは、“不良”プリンシパルが他のプリンシパルやブラウザ、ホストマシンに影響を与えることはできません。
Wang氏らはWebサイトとしてのプリンシパルを、“Webサイトの起源(プロトコル、ドメイン名、ポート)によってラベリングされたサイトオリジンポリシー(SOP)”であると定義する。プリンシパル保護を強制するため、プリンシパルとオペレーティングシステムの間にブラウザカーネルが取り入れられる(図1)。
ブラウザカーネルは分離された保護ドメイン内で動作しており、ブラウザプリンシパルと従来のOSの間のやり取りに介入します。そして、プリンシパルがシステムリソースにアクセスするのを仲介し、ブラウザのセキュリティポリシーを強制するのです。本質的に、ブラウザカーネルはブラウザプリンシパルに対してオペレーティングシステムとして機能し、システムリソースの保護と共有を行います。また、アドレスバーやメニューの管理も行います。ブラウザカーネルはマウスクリックやキータイプのようなユーザイベントを含む、下層のオペレーティングシステムによって発生したイベントを全て受け取り、それらを適切なプリンシパルインスタンスに処理させます。ユーザが異なる起源のURLを指しているハイパーリンクをクリックした場合、ブラウザカーネルは対象ページをレンダリングするために、そのURLのプリンシパルインスタンス用の保護ドメインを(もしまだ存在しなければ)生成し、リンク元ページの保護ドメインは破棄します。さらに、URLのプリンシパルインスタンスのためにウィンドウの再割り当てと再初期化を行います。
Wang氏らはGazelleの実装とGoogle Chromeの現在のセキュリティ方策を比較した。Google Chromeはモノリシックプロセス、ブラウジングインスタンス毎プロセス、サイトインスタンス毎プロセス、サイト毎プロセスのようなプロセスモデルを採用している。ブラウザインスタンスは相互連結されたウィンドウ、フレーム、サブフレームで構成される。一方、サイトインスタンスは同一サイトを起源とし、ブラウジングインスタンス内に存在しているページのコレクションである。サイトは“レジストリ管理されたドメイン名を共有するSOP起源のセット”として定義される。例えば、attackerAd.socialnet.com、alice.profiles.socialnet.com、socialnet.comは同じレジストリ管理されたドメイン名socialnet.comを共有する。これらはChromeによって同じサイト、もしくは同じプリンシパルであるとみなされる。Wang氏らによれば
Chromeはデフォルトでサイトインスタンス毎プロセスモデルを使用します。さらに、… Chromeの現在の実装ではサイトインスタンス毎プロセスモデルやサイト毎プロセスモデルでの完全なサイトの隔離をサポートしません。親ページと異なる起源をソースとするネストされたiframeのような埋め込みプリンシパルは、親ページと同じプロセス内に配置されます。Chromeのモノリシックとブラウジングインスタンス毎プロセスモデルは、モノリシックプロセスやブラウザインスタンス内でのメモリやその他のリソース保護を提供しません。サイト毎プロセスモデルはサイトインスタンスへの障害抑制アクセスを提供しません。Chromeのサイトインスタンス毎モデルがGazelleのプリンシパル・インスタンス毎2プロセスモデルに最も近いモデルですが、極めて重要な違いがいくつかあります。(1) Chromeのプリンシパルはサイトですが(上記参照)、GazelleのプリンシパルはSOPプリンシパルと同じです。(2) Chromeでは同じプロセス内にWebサイトプリンシパルと埋め込みプリンシパルが共存しますが、Gazelleではそれらは分離された保護ドメインに配置されます。このデザインの追及はクロスプリンシパル表示保護を含む新しい研究課題を我々にもたらしました。(3) Chromeでは異なるプリンシパルや異なるサイトのプラグインはプラグインプロセスを共有しますが、Gazelleでは分離された保護ドメインに配置されます。(4) Chromeは同一プロセス内に共存しているプリンシパルにサイトオリジンポリシーを強制するため、レンダリングプロセスに頼っています。これらの違いは、Chromeではクロスプリンシパル(もしくはクロスサイト)保護がブラウザカーネルに加えて、レンダリングプロセスとプラグインプロセスで生じるのに対し、GazelleのブラウザカーネルはOSとして機能し、表示を含む全てのリソースのクロスプリンシパル保護を行うということを意味しています。
GazelleとIE 8を比較し、Wang氏らはこのようなことに気がついた。
IE 8はタブ同士を分離するためにOSプロセスを使用します。ユーザが互いに信頼できない複数のサイトを一つのタブ内でブラウジングしたり、Webページが(例えば広告のような)信頼できないサイトのコンテンツをiframeでホストしている可能性があるので、この粒度では不十分です。
リサーチチームの総体的な結論は
基本的に、Chrome、IE 8とGazelleとは目指しているゴールが違います。これらはセキュリティよりもユーザのブラウジングセッションの障害抑制アクセスのためにマルチプロセスを使用しています。これらのセキュリティ上のゴールは、ブラウザやWebからホストマシンを保護することです。これはプロセスのサンドボックス化によって達成されます。ChromeとIE 8はブラウザアーキテクチャ設計の進化により優れたマイルストーンを達成しました。将来、Webにより多くのデータや機能を持たせ、ブラウザを有力なアプリケーションプラットフォームとして位置付ける際に、ブラウザをオペレーティングシステムとしてとらえ、ホストマシンに加えてWebサイトプリンシパル同士を保護することは、ブラウザの設計者にとって重大です。これがGazelleのゴールです。
GazelleのプロトタイプはIE 7がベースになっており、後方互換パース処理、DOM管理、JavaScriptエンジンを利用している。ブラウザのパフォーマンスはIE 8やGoogle Chromeと同程度と報告されている。クロスオリジンスクリプトソース保護は図2に示されているアーキテクチャによって解決されている。その考え方は悪意のある動作やエラーを発生させるコードを隔離するため、プラグインコードをサンドボックス化することである。
このリサーチプロジェクトは、ブラウザを完全にオペレーティングシステムに組み込む計画を停止していないMicrosoftを驚かせた。このような動きは多くの企業にとって確実に大きな衝撃になるだろう。なぜなら、ブラウザは支配的なデスクトップアプリケーションになりつつある。Microsoftは、これは自分たちの真意ではないがブラウジングのセキュリティを向上させる、と断言している。現在、Gazelleはリサーチプロジェクトだが、時間がたてば製品か、少なくともIEや、他のブラウザやWindows上で動くオンラインアプリケーションのために残されている部分に組み込まれる形で我々の前に姿を現すだろう。
【ネクストスケープ】.NET、C#のアプリケーション開発者募集
世界の先進エンジニアが集結 - QCon TOKYO 2012 早期割引実施中!
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。
Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。
GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式
本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。
前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。
Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。
スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。
No comments
スレッド表示 返信