レベル: 初級 Abel W. Lin (awlin@ncmir.ucsd.edu), Software Architect, National Center for Microscopy and Imaging Research
Kurt Mueller (kurt@sdsc.edu), Software Engineer, San Diego Supercomputer Center (SDSC)
2006年 1月 31日 エンドツーエンド・プロセスを「グリッド対応」にするとは、どのような意味なのでしょうか。
この連載記事「統合グリッドの構築」
では、National Center for Microscopy and Imaging Research (NCMIR) の Telescience Project のグリッド・アーキテクトが、彼らの開発したようなインフラストラクチャーが、いかにして開発者をより統合されたグリッドへと導くのかを説明しています。第 1 回では、Telescience Project のグリッド・ベース・システムのアーキテクチャーについて説明しました。第 2 回では、統合グリッドが、より大量のデータをより高速に処理してオンデマンドで資源を統合することで、どのように、より質の高いデータをより速く収集するかについて説明しました。この統合化の中核をなすのは、さまざまな分散資源にセキュアに接続する能力です。第 3 回となる今回はこれをテーマに取り上げます。
グリッドにおけるセキュリティー、認証、および認可
グリッド・ベースかどうかにかかわらず、セキュリティーはあらゆる組織にとって重要です。但し、「セキュリティー」という言葉は、、物理的なセキュリティー、認証、および認可といった個別要素を網羅的に表すうたい文句としてよく使われます。全ては重要で明確な要件を持ってます。セキュリティーは、プライバシー、整合性、およびグリッド・ベースの通信の全般的な保護 (たとえば、ネットワーク・スニッフィングや中間者攻撃の防止) に必要です。認証は、ユーザーの身元確認のほか、シングル・サインオン機能や権限委譲機能にも必要です。認可は、認証済みユーザーに許可されるアクションを決定するのに使用されます。
第 1 回では、Telescience Authentication and Authorization (TeleAuth) バンドルについて簡単に説明しました。今回は、ATOMIC の TeleAuth コンポーネントにおける中核機能を提供する Grid Accounts Management Architecture (GAMA) について説明します。
グリッドのセキュリティー ― 単なる証明書の配布以上のもの
グリッドのセキュリティーに関するデファクト・スタンダードは、Grid Security Infrastructure (GSI) です。GSI は、公開鍵ベースの X.509 準拠システムであり、ユーザーおよびホストの証明書に署名する信認された第三者機関に依拠しています。通常の使用ケースでは、一組の公開鍵と秘密鍵のペアからなるユーザー・クレデンシャルを各ユーザーに割り当てることが必要です。これを元に、ユーザーは、短い有効期間の委譲プロキシー証明書を生成します。この証明書がコンポーネント間で受け渡され、それに基づいて認証、アクセス制御、およびロギングが行われます。通常、ユーザーは手動で、またはコマンドライン・ベースのユーティリティーを使って証明書 (およびプロキシー) の管理を行うことができます。
GSI は、広く受け入れられ、長年にわたって利用されていますが、GSI ベースのセキュリティー・システムは、管理者にとっては配備しにくく、ユーザーにとっては使いづらいことで知られています。セキュリティーは、すべてのグリッド・システムの基本的かつ重要な構成要素です。しかし、皮肉にも、すぐに使用できる完全なエンド・ツー・エンドのセキュリティー・システムは、つい最近まで存在しませんでした。従来欠けていたこの機能を、管理者、アプリケーション開発者、およびエンド・ユーザーを含むあらゆるクラスのユーザーに提供するために開発されたのが GAMA です。
GAMA では、エンド・ユーザーはグリッドのセキュリティー、クレデンシャル、プロキシーなどの技術的な事柄については何も知る必要はありません。通常のWeb フォーム・インターフェースを使ってアカウントを要求し、アカウントが作成された後は、お馴染みのユーザー名 / パスワードの組み合わせを使ってポータルにログインするだけです。グリッド証明書の生成からポートレットが使用するグリッド証明書の検索に至るまでの、グリッドに関する操作はすべてバックグラウンドで行われます。
アプリケーション開発者のために、GAMA サーバー・コンポーネントはグリッド・サービスとしてラッピングされ、ポータルだけでなくクライアントからもアクセス可能です。たとえば、グリッド対応の資源へのアクセスを行うために、ユーザーのグリッド証明書を必要とする既存のスタンドアロン・アプリケーションに、簡単なGAMA ログイン機能を容易に追加できます。これは、Python と XUL (JavaScript) によるリッチクライアント・アプリケーションの例で実証済みです。
グリッド管理者のためには、Rocks クラスター・パッケージング・システムを使用した GAMA サーバーのインストーラーがあります。これは、ブート可能 CD を使用して、オペレーティング・システム (Linux®) および必要なグリッド・ミドルウェア・セキュリティー・ソフトウェア・パッケージをすべてインストールするものです。もし、OS とグリッド・セキュリティー・パッケージのインストールと構成をすべて手作業で行った場合には、経験豊かなグリッド管理者でも数時間 (あるいは数日) かかる可能性があります。それに対して、我々のRocks インストーラーを使用すれば、1 時間足らずで稼働可能なGAMA サーバーを構成することができます。
Grid Accounts Management Architecture (GAMA)
Telescience Project は、Geosciences Network (GEON) と共に、GAMA の開発をドライブするアプリケーション環境としての役割を果たしてきました。GAMA は、いくつものグリッド・セキュリティー・コンポーネントを 1 つのツールに統合することで、GSI のセキュリティーおよび権限委譲機能を利用しながらも、商用 Web サイトのような使いやすいグリッド・セキュリティーを実現しています。Application to Middleware Interaction Component (ATOMIC) に含まれる他のツールと同様に、GAMA は、エンド・ユーザーに対してもポータル / アプリケーション開発者に対しても、適切に簡易化されたインターフェースを提供します。
GAMA は、クライアント / サーバー・システムであり、付属するGridSphere ポータルが、GAMA サーバー・バンドルの稼働する専用サーバー・マシンへのアクセスを提供するGAMA クライアント機能を提供します。以下では、サーバーとクライアントの各々について、従来は別々であったグリッドのツール群が、どのように統合され相互に作用しあって、ユーザー管理タスクを実行するのかを見ていきましょう。この記事では、Telescience で使用された GAMA V1.x のアーキテクチャーについて説明しますが、それに加えて、堅牢性とスケーラビリティーを強化するために現在進められているGAMA V2.0 での変更点についても説明します。
図1 は GAMA のアーキテクチャーを示しています。GAMA サーバー・ソフトウェア・スタックは右側に示されています。現在、GAMA には、セキュリティー用に最も広く使用されているいくつかのグリッド・コンポーネント (それぞれは、別個に開発され、互いに独立) が統合されています。
-
CACL - San Diego Supercomputer Center (SDSC) で開発された認証局システムです。ユーザー (およびホスト) の GSI クレデンシャルの生成に使用されます。
-
MyProxy - National Center for Supercomputing Applications (NCSA) で開発されたプロキシー・リポジトリーです。ユーザーの GSI クレデンシャルから派生した有効期間限定のプロキシーの格納および生成に使用されます。
-
Community Authorization Service (CAS) - Globus Project によって開発されたもので、GSI のメカニズムを通してユーザーのコミュニティーにロール・ベースの認可を提供します。
通常は、これらのコンポーネントに、コマンドラインで個々に順次アクセスしますが、GAMA では AxisのWeb サービスをもって統合されています。すなわち、Web サービスをサポートする任意の言語で記述されたクライアントは、洗練されたシンプルな API を通じて、これらのコンポーネントにリモート・アクセスすることが可能です。さらにセキュリティーを強化するために、Axis をApache Tomcat サーブレット・コンテナーの中で動作させて、クライアントとの通信のネゴシエーションに Java™ 鍵ストア・メカニズムを利用しています。
図1. GAMA のアーキテクチャー (左側はクライアント、右側は GAMA サーバー)
GAMA のクライアント (ポータル) 側には、一連のGridSphere ポートレットおよびヘルパー・サービスが組み込まれており、ポートレット開発者は、これらをポータル (Telescience Portal など) に統合します。
- account request ポートレットは、新規ユーザーに対して入力フォームを表示し、個人情報とアカウントに関する各種設定の入力及び送信を要求します。
- ポータル管理者は、account admin ポートレットを使用して、受け取ったユーザー・アカウント要求を表示し、管理できます。
- 管理者は、ローカルのサイトでのポリシーに基づいて新規アカウント要求の承認または拒否を選択します。あるいは、電子メール・アドレスのドメイン名に基づいて自動的に承認または否認するルールを構成することもできます (たとえば、NCMIR のユーザーを自動的に承認するには、電子メール・アドレスに「ncmir.ucsd.edu」を含むユーザーを自動的に承認するルールを追加します)。
- 管理者による承認 (または自動承認ルールによるトリガー処理) に続いて、アカウントが承認されたことを通知し、アカウント・アクティベーション用の Web リンクを URL の形で提供する電子メール・メッセージをユーザーに送信します。
- ユーザーがこのリンクをクリックし、ポータル上でアカウント・アクティベーションを進めると、新規ユーザー・アカウントを作成する以下の一連のステップが実行されます。
- ポータルは、Web サービス経由で、GAMA サーバー上で稼働する CACL サービスを呼び出します。
- CACL サービスは、新規ユーザーに対して GSI 証明書および鍵を生成します。
- ポータルは、作成した新規証明書および鍵を GAMA サーバー上で MyProxy サービスを通じて利用できるようにGAMA サーバーに指示します (これも Web サービス経由で行われます)。
- その後、ポータルは、ローカルの GridSphere ポータルで、ユーザーのアカウントを作成し、そのユーザー・ログイン時の認証に GAMA サーバーを使用するよう構成します。
- この時点で、新規ユーザーは、アカウント要求およびアクティベーション・プロセスで指定したユーザー名とパスワードを使って、ポータルにログインできるようになります。
- ユーザーがユーザー名とパスワードを入力し、「Login」ボタンをクリックすると、GridSphere フレームワークは ユーザーを認証するためにGAMA サーバー上の MyProxy サービスを呼び出します。
- 入力されたユーザー名とパスワードの組合せが有効であれば、MyProxy サービスは、ユーザーの証明書から派生した有効期間限定のプロキシー証明書を返します。
- ユーザーに対するプロキシー証明書が、GridSphere ポータル環境内でアクティブになり、ユーザーはポータルにログインした状態になります。
この後、ポータル (ジョブ実行依頼ポータルやファイル転送ポータルなど) 内のグリッド対応のポートレットやサービスは、ユーザーのグリッド・クレデンシャルに容易にアクセスして、グリッド上の資源やサービスに渡すことができるようになります。
ユーザー名 / パスワードの適切な組み合わせが提示されると、GSI ベースの証明書をポータルまたは他のクライアントに返すという点では、MyProxy サービスも同様の機能を備えてはいますが、CASでは標準の MyProxy クレデンシャルよりもきめ細かい認可の設定が可能です。CAS のクレデンシャルには、コミュニティーにおけるユーザーのロールを記述した認可アサーションを含んでおり、対象となる資源の側でこれを用いて、必要に応じてアクセスを承認することもできます。GAMA サーバーは、すでに実用的な CAS サービスのホストとして機能しています。現在、私たちは、CAS を介してユーザーのロールを管理するためのポータル付随のツール開発に積極的に取り組んでいます。
まとめ
GAMA は、グリッド・コンピューティングへの移行を進めるユーザー・コミュニティーにとって素晴らしいソリューションであり、インストールと保守が比較的容易であると同時に、ユーザーに各自の証明書を管理させる重荷を負わせないという要求に応えるシステムです。また、GAMA は、一般に退屈、かつ複雑でミスしやすいプロセスを統合・簡略化しています。
ただし、現在のGAMA V1.x は、特定のグリッド・ベース・テクノロジー (CACL、MyProxy、および CAS) と結びついており、また、GAMA サービスを拡張または新規に追加する仕組みは限定的です。それに対して、私たちが現在開発を進めている GAMA V2 は、プラグイン・アーキテクチャーに基づいて構築されていますので、カスタマイズや拡張が可能で、簡単な機能をつなぎ合わせてより複雑なワークフロー (完全にはグリッド・ベースのものではないかもしれませんが) を実現することができます。たとえば、GAMA を実装する人の中には、既存の LDAP インフラストラクチャーを使用して認証を行いたい人もいるでしょう。この新しいプラグインのシステムならば、LDAP GAMA モジュールを構築し、他の GAMA モジュール (MyProxy や CAS など) と組み合わせて複数ステップのログイン・シーケンスを実行することも容易に実現できるようになります。さらに、GAMA V2 では複数ポータルのサポートも強化され、複数のローカル・サイト管理者が各自のサイトから GAMA 管理者としての作業を実行することも可能になります-- すべては、同じ GAMA サーバー上で実行されます。
参考文献 学ぶために
製品や技術を入手するために
著者について  | | | Abel W. Lin is the architect and technical lead for the Telescience Project at the National Center for Microscopy and Imaging Research. He has more than five years' experience applying grid and other computer science technologies to scientific processes. He designed and led the implementation of the first-generation proof-of-concept systems for the Telescience Portal and ATOMIC components of the Telescience Project, and is an interdisciplinary scientist with published research in biology and computer science. His interests include distributed systems architecture, software project management, and structural biology. Outside of the office, he is an avid reader, golfer, and bodysurfer.
|
| | | Kurt Mueller is a researcher at the San Diego Supercomputer Center (SDSC) at the University of California, San Diego. He is the lead developer on the GAMA project. Kurt was involved in influential early Grid portal projects, including the GridPort toolkit and the NPACI and PACI HotPages, and he has collaborated with the Telescience team at NCMIR for many years. A cognitive scientist by training, Kurt's research interests include human-computer interaction, Grid security, and portal technologies. |
記事の評価
| 
