分散型情報フロー制御によるWebのセキュア化

作者 Jean-Jacques Dubray , 翻訳者 編集部 投稿日 2008年8月13日

セクション

エンタープライズ・アーキテクチャ,

設計/アーキテクチャ,

デベロップメント

トピック

SaaS ,

REST ,

Architecture ,

クラウドコンピューティング ,

ルールエンジン ,

エンタープライズアーキテクチャ ,

Firewall ,

Wiki ,

クロスサイトスクリプト ,

Facebook

共有 |

ワシントン大学のコンピュータサイエンス学部は、MITのKrohn氏 Krohn氏(リンク)による分散型情報フロー制御によるWebのセキュア化に関する談話(リンク)をこのほど発表した。

この談話の中でKrohn氏はコンピューター業界において、デスクトップ・ソフトウェアからサーバーサイド・ソフトウェア、さらにはクラウドコンピューティングへのシフトが起こりつつあるという意見を披露している。

しかし、彼は以下のように(リンク)述べている。

Webソフトウェアはバグが多く、ハッカーはそのようなバグを見つけ出し、悪用します。その結果、データが盗まれたり改ざんされたりするのです。

大半の人は静的分析を考慮しない動的言語を使用し、安易にサードパーティー製のコードやプラグインを利用します。そして、認めざるを得ないのは、Webサイトというものは素早く稼動させる必要があるため、あちらこちらでその場しのぎが行われているのです。

彼は実際的に、ソフトウェアがどれだけ脆弱であるかを示すために、興味深い評価指標を定義している。彼はコードの行数（LOC）をインストール数で割ってみることを薦めている。ソフトウェア、たとえばLinuxがインストールされればされるほど、脆弱性が発見され、修正される可能性は高まり、その結果、問題点は少なくなる。彼は自分の論点を表すために2つのスライドを見せた。WebアプリをLOCで表したものと、LOCをインストール数で割ったものである。

彼の研究目標は、新しいタイプのアプリケーションやアーキテクチャ向けのセキュリティモデルを定義することだ。問題となるのは、開発者にプラットフォームにコードを挿入させたり、今やサードパーティーのサーバーにプラットフォーム内の機能を持たせたりする、Facebook のようなアプリケーションに即対応することである。

これらの課題に対してKrohn氏とその同僚は、分散型情報フロー制御 (DFIC) モデルに基づいたオープンソースのWebアプリケーションセキュリティインフラであるFlume を開発した。

分散型情報フロー制御 (DIFC)とは、アプリケーションの開発者にアプリケーションと外部との間のデータフローを制御させるというセキュリティアプローチである。

プライバシーに応用される場合、DIFCは信頼できないソフトウェアにプライベートデータを扱わせ、信頼できるセキュリティコードにはそのデータのリリースを制御させる。一方、インテグリティーに応用される場合、DIFCは信頼できるセキュリティコードによって、予期せぬ悪意のある入力から信頼できないソフトウェアを保護するようにする。

彼らはサーバーをブラックボックスとして扱い、リクエストに対するレスポンスが作成されるのに従ってデータをトラックする。セキュリティーアーキテクチャは、セキュリティーゲートウェイとOSライブラリーからなり、Webアプリケーションで使用されるデータにタグ付けを行う。基本的なコンセプトは、すべてのセキュリティ決定をゲートウェイに集中させ、望まないデータアクセスを防ぐことである。

典型的なFlumeアプリケーションは2種類のプロセスから成り立っています。信頼できないプロセスが演算の大半をこなします。これらのプロセスはDIFC 制御の制約を受けますが、恐らくそれが意識されることはないでしょう。それに対して、信頼できるプロセスはDIFCを意識しており、信頼できないプロセスを制約するプライバシー制御およびインテグリティー制御を設定します。信頼できるプロセスはまた、従来型の情報フロー制御を選択的に無視する特権を持っています。たとえば、（システムからエクスポートする目的などで）プライベートの機密解除を行うことや、データの整合性が高いことを保証することができるのです。

タグおよびラベルに基づくデータトラッキングを行うための極めてシンプルないくつかのルールがシステムの核となっている。

タグ t には固有の意味はないけれど、プロセスは各タグを機密性あるいはインテグリティーのカテゴリと緩やかに関連付けています。たとえばタグ bは、ボブのプライベートデータを表しているかもしれません。ラベルはタグセットのサブセットです。

Flumeプロセス p はqのサブセットであるラベルを持っている場合、データをプロセスq に送る。Flumeモデルでは、多くのプロセスが同じマシン上で実行されていて、互いに「フロー」と呼ばれるメッセージによってコミュニケーションを行っていると仮定している。モデルが目指すのは、プロセスコミュニケーションと、プロセスラベルの変更の両方を管理することによってデータフローをトラックすることである。.

図1. コミュニケーション・ルール

Krohn氏はこの概念を新しいものではなく、80年代からあるものだとしている。

このセキュリティーアーキテクチャの鍵となるのがゲートウェイである。まず、ゲートウェイがポリシー決定を行うため、Webアプリケーションはブラウザについて一切関知する必要がない。しかし、この中心的な役割には新しい抽象概念、すなわちエンドポイントの導入を必要とする。ゲートウェイはいくつかのシステム（ブラウザ、認証レポジトリ、Webアプリケーションなど）との対話を司らなくてはならないため、単一のラベルセットをすべてのこれらのプロセスに渡すわけにはいかない。エンドポイントは、ゲートウェイと個々の特定プロセスとのコミュニケーションを強化するようなラベルの組み合わせを定義する助けとなる。

プレゼンテーションの後半は、MoinMoin Wiki (リンク)をユースケースとしたプレゼンテーションである。Krohn氏はこのユースケースにおいて、 Flumeが既知の脆弱性タイプ以上の問題（バッファ・オーバーラン、クロスサイトスクリプティング、SQLインジェクション）に対処する様を示した。MoinMoin Wiki のカレンダー機能にバグがあり、本来であれば特定のグループにのみ閲覧が許可されているはずのカレンダー項目が全ユーザーが閲覧可能な状態にあったという。Flumeは単純に標準ポリシーに従うだけで、カレンダーの内容が表示されるのを防ぐことができた。

図2. システムコール・デリゲーション

Krohn氏はやらなければなけないことはまだまだ沢山ある、と締めくくった。彼らはサードパーティーのソフトウェアをWebアプリケーションにアップロードして使用することができるくらい、システムを柔軟にしたいのだという。また、同じ原則によって、データのシェアができるようにすることにも取り組んでいる。彼らはまた、ブラウザレベルにまで範囲を広げ、JavaScriptをアーキテクチャに取り込もうと計画している。 Krohn氏は金融業界の大量のアプリケーションを視野に入れているのだ。

連結システムの開発においては、安全なアプリケーションコードの外部で、ポリシー強化戦略を使用してデータへの迷惑アクセスを防止するために、ますます徹底したセキュリティーソリューションの必要の度合いを深めている。さて、あなたのご意見は？ このようなセキュリティ問題に直面したことは？そのとき、どのようなソリューションを使用しましたか？

原文はこちらです：http://www.infoq.com/news/2008/08/securing-the-web