Webサービスのセキュリティ概要：Webサービスのセキュリティ（1）

» 2002年06月19日 00時00分公開

[鈴木優一，エントラストジャパン]

Webサービスセキュリティの技術要素

　最近Webサービスをめぐった業界の動向がにぎわしくなってきた。サン・マイクロシステムズは2001年9月、XMLを使ったWebサービスによる認証などのための技術標準を推進する企業連合Liberty Allianceを設立した。またマイクロソフトは.NET戦略でのWebサービスを強力に推進している。さらにIBMも独自でWebサービスの陣営を固めようとしている。これらのグループに共通するのは認証やセキュリティの強化である。しかし、本稿ではこれらのグループの動向を紹介するのではなく、WebサービスのセキュリティのベースとなるXMLデジタル署名、XML暗号を基本とするWebサービスのフレームワークとその技術要素を述べることにする。

　このようなインターネットによるアプリケーション統合の技術としてのWebサービスは、デジタル署名やプライバシーを強化したセキュリティを備えることで、電子政府への電子申請や各種の電子商取引のツールとして必須のものとなっていくであろう。

　これらのことをふまえ本連載では、Webサービスセキュリティの技術要素とそのフレームワークの最新の動向を紹介していく。

Webサービスセキュリティの必要性

　公開鍵方式をベースとしたPKIは、電子政府の認証基盤として整備されつつあり、また民間での電子商取引のベースとして注目されている。しかしPKIのアプリケーションはまだ広く普及していない。VPNやS/MIME、WebのSSL/TLS認証などはPKIのアプリケーションとして使われつつあるが、各種の業務アプリケーションや電子申請のアプリケーションをPKIでイネーブル（利用可能）するのはまだまだ先の話だ。その理由はPKIアプリケーションを開発する難しさに一因がある。

　PKIの各種プロトコルの多くはASN.1^＊1で定義されており、ASN.1を理解し操作できる人が限られている。一方インターネットを使った多くのアプリケーションはWebブラウザ上に移行してきている。しかしWebブラウザのセキュリティとなるとWebサーバ認証に使われているSSL/TLSがあるが、これはWebブラウザのセッションの認証やプライバシーを守るためのものであり、文書へのデジタル署名やファイルの永続的な暗号化などに使えない。

^＊1 Abstract Syntax Notation：抽象構文表記法、ITU-Tの標準でプレゼンテーション層のデータ構造表記言語

　WebサービスのアプリケーションがPKIベースのセキュリティを備えるには、PKIのインターフェイスの複雑さを隠ぺいし、デジタル署名や署名検証および暗号化や復号を扱いやすいAPIが整備されなければならない。PKIの公開鍵証明書や鍵管理のプロトコル、デジタル署名や暗号のフォーマットの標準はIETFのPKIXワーキンググループやS/MIMEワーキンググループによってASN.1ベースで作られてきた。従ってPKIアプリケーションのAPIは難しいASN.1のデータ構造を用い、C／C++ベースのAPIを用いてきた。

　そこでWebサービスを用いて、もっと柔軟なPKIアプリケーションを構築しようという動きが活発になってきた。XMLは構造化文書を定義する言語であるが、データ構文を定義する記述言語としても有用である。XML文書はHTMLに変換してブラウザに表現できるため、Webとも極めて親和性が高いし、またビジネス文書管理、メッセージング、データベースとの融合などとの親和性も高く、電子商取引や電子政府への電子申請様式に必須のツールとなっている。

　デジタル署名や暗号を扱うWebサービスでのセキュリティ標準をXMLベースで提供する活動が精力的に進められている。現在XMLセキュリティ標準は2つの団体、W3C^＊2とOASIS^＊3で検討されている。

^＊2 World Wide Web Consortium：WWWコンソーシアム、WebやXMLに関連する標準化団体

^＊3Organization for the Advancement of Structured Information Standards：XMLベースの業界標準化団体

　W3Cの扱っている標準には、XMLを用いたWebサービスの記述言語のWSDL（Web Services Description Language）、XMLセキュリティの基礎となるXMLデジタル署名(RFC 3075)やXML暗号、またXMLを使った鍵管理のXKMS（XML Key Management Services）やXMLメッセージングのSOAP（Simple Object Access Protocol）などがある。

　OASISでは、Webサービスの相互運用性を高めるための活動が主であるが、W3Cの標準を使ったビジネスメッセージング標準も検討しており、これらには認証、認可情報を伝達する方法のSAML（Security Assertion Markup Language）、アクセス制御管理のXACML（Extensible Access Control Markup Language）、SOAPを使ったメッセージングebXML（Electronic Business XML）などがある。

　これらXMLセキュリティ標準のそれぞれの技術について今回はその概要を述べることにし、第3回以降でそれぞれの技術要素を詳しく述べることにする。

Webサービスセキュリティの基本技術
−XMLデジタル署名とメッセージング

　XMLは、Webサービスと連携し、ビジネス文書管理、メッセージング、データベースなどとの親和性が高く、電子商取引や電子政府への電子申請様式に必須の技術となってきた。そこで、Webサービスでのセキュリティ標準をXMLベースで提供する活動が活発になってきている。

　多くのビジネスアプリケーションはメッセージの授受をベースとしている。SOAPはこれ自体としてはセキュリティ標準ではないが、これらメッセージのエンベロープ（付加情報）としてXMLセキュリティの媒体の役割を果たす。エンベロープはヘッダとメッセージ本体（Body）から構成され、ヘッダ部分にデジタル署名や暗号を指定できるようにする。SOAPメッセージの実際のトランスポートプロトコルとしてはWebサービスへのバインディング（接続）としてHTTPを用いることになる。詳しくは次回以降で述べることにする。

　デジタル署名や暗号のフォーマットの標準は通常CMS（Cryptographic Message Syntax：RFC2630）が用いられるが、このフォーマットはASN.1で定義されており、署名や暗号の対象は任意のコンテントとして通常はファイルを指定して用いる。

　これに対してXMLデジタル署名やXML暗号は、ファイル内の任意の部分を指定することができる。特にXML文書に対しては指定したエレメントやエレメント内の文字列だけに署名したり、暗号化できる柔軟性がある。例えば注文書に対して自分のコミットする範囲に署名したり、クレジット番号の入力部分のみを暗号化できるのである。この特性は特にビジネス文書にとって極めて有用である。

　ワークフローなどで用いる文書に全体として署名されていると、文書の受信者がコメントを追記した場合でも、文書は改ざんされたことになり、署名は無効になってしまう。指定個所のみに署名されている場合には、それ以外の部分にコメントを追記しても署名部分さえ改変しなければ署名は有効の状態を保てる。またファイル全体が暗号化されている場合には内容は復号しなければ分からないが、指定部分のみが暗号化された文書は、そのままでは本当に秘匿すべき部分は読めないが、ほかのオープンな内容は誰にでも読むことができるのである（図1）。

図1　一定領域へのデジタル署名と暗号化

　PKIを使うアプリケーションでは、公開鍵証明書を用いて署名検証を行う場合、署名者の証明書の有効性検証を行わなければならない。すなわち証明書が失効されていないか、有効期限内か、証明書記載内容が正しいかなどの検証を行う必要がある。

　また相手の証明書を発行したCAの証明書も、その有効性検証のため同様のチェックを行う必要がある。このCAの証明書が検証者の信頼点でなければ、信頼点までのCA証明書チェーン（認証パス）上のすべての証明書についても同様な検証が必要になる。大規模な相互認証を伴ったPKIでは、認証パスの構築から検証まで行って、相手の公開鍵証明書の有効性が確認できて初めて相手の信頼できる公開鍵を入手したことになる。

　この信頼できる公開鍵を使って、相手のデジタル署名の検証が可能となるのである。相手に対して相手の公開鍵で暗号文を送る場合にも同様な操作を行い、相手の公開鍵証明書の有効性確認を事前に行わなければならない。

　信頼できる相手の公開鍵を入手するには上記のような複雑な証明書の有効性確認を行わなければならないが、PKIのアプリケーションですべてこの手順を組み込もうとするとPKIアプリケーションが複雑になる。XKMSはXMLのセキュリティで用いる複雑なPKIの証明書や鍵管理を別のサーバにアウトソースし、XMLアプリケーションを容易にPKIに統合させる機能を提供する。

　Webサービスのセキュリティを考えるとき、上記のXML署名やXML暗号のほかに、セッション時の認証（本人確認）に伴って相手の資格や権限にそったセキュリティ制御が必要になる。このサービスは権限管理やアクセス制御として知られるものである。このメカニズムをXMLベースのビジネスアプリケーションに導入するために、いくつかの手順が開発されてきた。SAMLは認証、認可の情報を異なるドメインに伝達するためのプロトコルを定めている。またXACMLはアプリケーションから利用者のアクセス権限情報を定義し、その情報をアクセス制御エンジンに伝える機能を有する。これからのビジネスアプリケーションは、これらのXMLセキュリティ標準を使った柔軟で拡張性のある仕組みが利用可能になるであろう。

Webサービスセキュリティのフレームワーク

　いままで述べたXMLセキュリティの技術要素である——XMLデジタル署名(RFC 3075)、XML暗号、XMLを使った鍵管理のXKMSやXMLメッセージングのSOAPは、PKIベースのセキュリティの基礎を支えるものである。さらにWebサービスのセキュリティに必要になる資格、権限管理のための認証、認可情報を伝達する方法のSAMLやアクセス制御管理のXACMLを融合させた、XMLセキュリティの全体としてのフレームワークが見えてきた。このようなXMLセキュリティのフレームワークを図2に示す。

図2 ビジネスアプリケーションでのXMLセキュリティのフレームワーク

　ビジネスアプリケーションでは互いにメッセージの交換が必要になる。図2に示すようにセキュリティを要求する左側のリクエスタ（サービス利用者）は、右側のプロバイダ（サービス提供者）に信頼できるXMLメッセージを要求する。プロバイダはXML文書にXML署名を付け、またXML暗号化を施したメッセージ（Trusted XML Messaging）をSOAPのエンベロープに包みリクエスタに提供する。その際リクエスタは、プロバイダの認証と資格や権限の信頼できる情報（Trusted Context）が必要になる。このような情報はSAMLやXACMLで記述され、しかるべき権限管理やアクセス制御を行うセキュリティエンジンで処理される。一方、XML署名検証を行うリクエスタや暗号文を送付するプロバイダは、使用する相手の証明書の公開鍵の有効性検証を行わなければならない。この証明書検証処理は複雑でビジネスアプリケーションが行うには負担が大きい。そこで証明書検証処理を図2の下段に示した外部にある鍵管理証明書管理の信頼できるサーバに、XKMSプロトコルを用いて委託する（Trusted Services）。

　このことによってXMLビジネスアプリケーションは、PKIの鍵管理や鍵検証の複雑な操作から開放され容易にアプリケーションが開発できるようになる。SAMLは標準として確定した。XACMLはまだ最終的な標準となっていないが、ほぼドラフトの全容は固まってきている。ここで用いる各種の標準はW3CまたはOASISのページから参照できる。

　XMLを用いたビジネスアプリケーションは、Webサービスのセキュリティを以上のフレームワークで容易に構築できるようになる。

　ここに述べた各プロトコルはXMLスキーマを用いて定義される。WebサービスセキュリティはXML署名やXML暗号を基本としている。さらにセキュリティの拡張として、認証や認可の情報を異なるドメインに伝達させるSAMLやアクセス制御を指定するXACMLが用いられ、これらを含むメッセージはSOAPエンベロープに包まれる。これらのプロトコルの実際のトランスポートはWebサービスとしてHTTPに載せて（SOAP over HTTP）通信されることになる。

　次回からはこのフレームワークで使われる各プロトコルやエンベロープを詳しく見て行く予定である。XML署名とXML暗号は第2回で解説する。XMLメッセージングSOAPやXMLの鍵管理プロトコルXKMSについては第3回で述べる。認証、認可情報の伝達手段であるSAMLやXACMLについては第4回以降で詳しく述べることにする。

「第2回」へ

「Webサービスのセキュリティ」バックナンバー