Webサービス・セキュリティ構築の実践（後編）

事例から読み解くWSセキュリティ最新動向 Page 1

海外ではWebサービスを取り入れた実用システムが次々と立ち上がっている。これを可能にしているのはWebサービス・セキュリティ技術の成熟だ。本稿は前後2回にわたって、実用Webサービス・システムに必要となるセキュリティ構築の実践的な内容を解説する。（編集局）

本記事は、『Security&Trustフォーラム』との連動企画です。

東京エレクトロン
松永 豊
2004/5/7

■WSセキュリティのシステム構築トレンド

主な内容 WSセキュリティのシステム構築トレンド WSセキュリティ構築事例 まとめ 付録：Webサービス・セキュリティの 　 ツール状況

　前編「SOAPの弱点を克服するシステム設計のポイント」では、SOAPプロトコルを利用するWebサービス特有のセキュリティ課題と問題点の切り分け、対処方法の概要を解説しました。後編の本稿では、システム構築の実例をいくつか取り上げ、現時点でのベストプラクティスを考察していきます。

課題を解決するための方策

　前編で指摘した4つの課題に対して、さまざまな解決の試みが行われています。

• 開発負荷：開発ツールの活用、セキュリティ処理の分離・一元化
• 相互接続性（標準規格のサポート）：開発ツールの活用・一元化
• 処理負荷：設備増強／負荷分散、アクセラレータ
• 運用負荷：一元化、集中管理ツール

　開発ツールの利用やアクセラレータなどによる処理性能向上は、さまざまな製品が提供されているので、それぞれの製品を調べて利用するということになります。特に開発ツールに関しては、アプリケーション・サーバなどの製品がWebサービスのセキュリティ機能も包含するようになってきているので、既存で利用しているツールの対応状況によって、そのまま利用できる場合もあります。

本稿の「付録：Webサービス・セキュリティのツール状況」で各種のツールを紹介しています。

　システム構成の面でさまざまな問題を根本的に解決しようとしているのが、セキュリティ処理をアプリケーションから分離し、さらに一元化するやり方です。ファイアウォールやVPNなど、いままでのWebサイトでのセキュリティ管理と同様に、ネットワークの1カ所（入り口に近いところ）にセキュリティ機能を集中して管理しようという発想です。サーバから分離するべきセキュリティ機能はいくつか考えられます。

• 暗号処理（暗号化、電子署名）：開発負荷および処理負荷のオフロード
• 暗号鍵情報の処理：複雑かつ外部への問い合わせも発生する処理の分離
• フィルタリング：メッセージがサーバに到達する前に不正トラフィックを遮断

　実際の構築方法としては、別のサーバを立てて機能を集約する形から、多数のパートナーサイトのセキュリティ機能を一部肩代わりするプロキシサイトを立ち上げる方法まで、さまざまなパターンがあります。

構築パターンの比較

1）アプリケーションでの実装

　いままでのWebサービスの実装では、ほとんどがセキュリティ機能もアプリケーション・サーバで実現していました。取り掛かりやすく敷居は低いのですが、スケーラビリティが問題になりやすい形態です。

• サービスやサーバがごく少数のときに適用可能
• メリット
  • 既存の開発資源を最大限に活用
  • 取り掛かりやすい
• 注意点
  • 性能面・運用面で不利
  • 大規模なシステムには不向き

図1　アプリケーションでのセキュリティ実装

2）ゲートウェイでの実装（サーバ、ネットワーク専用機）

　セキュリティ部分を分離して一元化する場合、ネットワーク上のゲートウェイという形態になります。セキュリティ実装面での課題を多く解決してくれます。こうして機能をモジュール化することにより、セキュリティ機能の処理性能が不足したときにサーバ設備やアプリケーション全体の見直しを迫られる、といった事態を避けられます。従来のファイアウォールと同様の位置付けになるため、セキュリティ管理者が理解しやすくなるというメリットもあります。今後は、ゲートウェイの設置は当たり前になり、サーバとの役割分担でいろいろな構築パターンが生まれてくるでしょう。

• セキュリティ機能を分離・一元化し、各サービスに機能を提供
• 管理の一元化により運用工数を削減し、サーバの負荷をオフロード
• 比較的大規模なシステムに向く
  　
• サーバ利用
  • 各機能は、必要なソフトウェアをインストール・設定して利用
  • メリット：既存資源（サーバ）の活用も可能
  • 注意点：性能、開発工数、管理工数
    　
• 専用機利用
  • 必要な機能はビルトインで提供される
  • 専用エンジンを搭載していれば処理の高速化も提供
  • メリット：性能、開発／管理工数の削減、スケーラビリティ
  • 注意点：初期投資が大きくなる場合もある

図2　ゲートウェイでのセキュリティ実装

3）Webサービス・プロキシ

　ゲートウェイの考え方をさらに推し進め、インターネット上にある程度機能を持たせてしまおう、という提案もされています。ここではプロキシと呼んでいますが、専用のサイトを設けて共通化できる機能を提供します。数多くのパートナーサイトをWebサービスで連結したい場合など、多対多の接続を避けて単純化し、しかも各サイトの実装方法を隠ぺいできます。

• インターネット上に、ハブとなるプロキシサイトを構築
• メリット
  • ほかのサイトへアクセスする前にセキュリティ・チェック
  • 相互接続性の問題をプロキシ部分で吸収
• 注意点
  • 大掛かりな投資が必要

図3　Webサービス・プロキシでのセキュリティ実装

　今後の動向としては、認証情報の利用を簡易化する標準規格の利用が期待されます。暗号処理の鍵情報に関してはXKML、さらにインターネットワイドのシングル・サインオン（SSO）を実現するプロトコルSAMLや、認証情報自体の一元管理を目指すLiberty Allianceなどが有力です。（次ページへ続く）

 

前編

2/4

後編 Page 2

Index
Webサービス・セキュリティ構築の実践
	前編 SOAPの弱点を克服するシステム設計のポイント
	後編　 事例から読み解くWSセキュリティ最新動向 Page 1 WSセキュリティのシステム構築トレンド Page 2 WSセキュリティ構築事例 まとめ Page 3 付録：Webサービス・セキュリティのツール状況

『Security&Trustフォーラム』でも、Webサービスのセキュリティに役立つ記事を掲載しています。 【連載】Webサービスのセキュリティ 第1回 Webサービスのセキュリティ概要 第2回 XMLデジタル署名とXML暗号 第3回 XML鍵管理サービスとXMLプロトコル 第4回 強力なSSOを実現するXML認証・認可サービスSAML 第5回 PKIとPMIを融合させる次世代言語XACML 第6回（最終回） XACMLのアクセス制御ルールとその仕様

■関連記事

　・XML暗号化の基礎と実践
　・ビジネスWebサービス最新事情

 

Webサービス・セキュリティ構築の実践

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）