エントラストジャパン株式会社　鈴木優一

■Web サービスとは

　Webサービスは、インターネットを介してWebアプリケーションの連携を行う新しい分散コンピューティングの方式として急速に注目を集めてきている。従来のWeb が静的なページの検索や定められたサーバアプリケーションにアクセスするのと違って、Web サービスはサーバ間のアプリケーションを動的に連携させることを可能にする。また、従来の分散コンピューティングであるCORBA、DCOMなどは、クライアント／サーバ間で使用する言語やプラットフォームに独自の環境を必要としていたのに比べ、Web サービスはXMLメッセージをSOAP プロトコルに包みHTTPのトランスポートに載せることで言語やプラットフォーム（OS）に独立であり、疎結合で柔軟な分散システムを可能にする。HTTPを用いることでファイアウォールにブロックされることなくインターネットが使える。
　Webサービスは、図１に示すようなフレームワークが示されている。パブリックなWeb サービスでは、サービスのプロバイダは、(1)Web サービスの発見を可能にするためプロバイダの情報やサービス内容をUDDI（ Universal Description Discovery and Integration）に登録し、インタフェースをWSDL（Web Services Description Language）で記述する。(2)リクエスタはUDDIを検索しWSDLのインタフェースを取得して簡単にクライアントを作成する。(3)リクエスタはこのクライアントを使ってプロバイダのサービスの提供を受けることができる。


　　　　　　　　図1 Web サービスのフレームワーク

　Web サービスが期待される応用分野は、インターネットのグローバルなサービスであっても、イントラネットの基幹システムやエクストラネットのビジネスシステムでも良い。既存のアプリケーションをWeb サービスのプロトコルにラップすることで、新しいサービスとして速やかに展開することもできる。
　Webサービスのメッセージングは、図２に示すようにリクエスタとプロバイダに常駐するRun Time であるSOAP プロセッサが、XMLプロトコルの解釈とアプリケーションへのデータ引渡しの仲介を行うことで実現される。また、WSDL の取得によってクライアントアプリケーションのインタフェースであるstabを自動生成するToolも利用できる。


　　　　　　　　　　　　　図2 Web サービスの処理

■Web サービスのセキュリティ

　WebサービスのプロトコルであるSOAPは、それ自身はセキュリティ機能を提供しない。Webサービスは、インターネットで利用されるのでセキュリティの確保が必須である。そのため、次の2つの手法がとられる。

（1）ピア・ツー・ピアのセキュリティ：SSL/TLS

（2）エンド・ツー・エンドのセキュリティ： XML 署名、XML暗号

　ピア・ツー・ピアのセキュリティを確保する手段として、Webサービスに限らないがSSL/TLS は最も一般的に用いられる手法である。SSL/TLS による通信路の暗号化は、ネットワークにおける盗聴を防ぎプライバシを確保する。サーバ認証やオプションとしてのクライアント認証によって発信者の確認が可能になる。しかし、この技術はエンド・ツー・エンドのセキュリティを保証しない。中間サーバでメッセージが復号化されてしまうし、発信者の認証がエンド・ツー・エンドで確認できない。
　エンド・ツー・エンドのセキュリティを確保するためにはメッセージ自体にXML 署名、XML暗号を施す必要がある。SOAPメッセージのセキュリティ確保のためのSOAP BodyやHeaderの署名や暗号の方式も標準化がほぼ完了した。
　さらにWeb サービスの認証・認可情報を伝達する方法のSAML（Security Assertion Markup Language）およびアクセスポリシーを定めたXACML（ XML Access Control Markup Language）は、認証、認可の仕組みやIdentity連携の仕組みを定める。
　また、署名検証や暗号化のために必要となる公開鍵証明書の検証をアプリケーションからアウトソースするためのXKMS（XML Key Management Service）がW3Cで標準化された。これらの技術によって図3に示すようなWeb サービスのセキュリティの全体としてのフレームワークが見えてきた。


　　　　　　　　図3 XML セキュリティ・フレームワーク

　図３にある左側のリクエスタは、右側のプロバイダに信頼できるXMLメッセージを要求する。プロバイダはXML文書にXML 署名やXML暗号化を施したメッセージ（TrustedXML Messaging）をSOAPのエンベロープに包みリクエスタに提供する。この際リクエスタは、プロバイダの認証と資格や権限の信頼できる情報（Trusted Context）が必要になる。このような情報はSAMLやXACMLで記述される。一方、XML 署名検証を行うリクエスタやプロバイダは、提示された相手の公開鍵証明書の有効性検証を行わなければならない。この証明書検証処理は、複雑でビジネスアプリケーションが行うには負担が大きい。そこで証明書検証処理を図３の下段に示した外部にある信頼できるサーバにXKISS（XML Key Information Service Specification）プロトコルを用いて委託する（Trusted Services）。このことによってXML ビジネスアプリケーションは、PKI の鍵管理や鍵検証の複雑な操作から開放され容易にアプリケーションが開発できる。

■XML 署名

　XML 署名フォーマットは、W3C（World Wide Web Consortium）の標準で、従来のASN.1を用いたCMS 署名フォーマットに比べ人間から見ての見読性があると同時に、特にXML文書に対して署名領域を指定したり、複数の領域に署名対象を指定できたりする柔軟性がある。従来のCMS 署名フォーマットはバイナリーデータであり人間には読むことができないし、また、コンテンツ全体に署名することしかできない。通常ビジネス文書の場合、署名文書にコメントを加えたりすることがある。CMS署名ではこのような操作は署名文書の改ざんになってしまう。これに対してXML 署名の場合は、署名対象以外なら加筆、訂正が自由に行える。

■XML 暗号

　W3Cで策定したXMLによる暗号の構文と処理方式の標準で、任意のデータの暗号化も含めてXML文書全体の暗号化、XML 文書の特定の要素の暗号化、要素内のコンテンツの暗号化などが可能である。また、暗号化対象は1つだけではなく複数の対象も指定できるなど柔軟な暗号化が可能である。
　CMS による暗号フォーマットは、コンテンツ全体に対する暗号となり、内容は復号しなければ分からないが、XML 暗号を用いると必要な部分のみを暗号化できる特徴がある。
　例えば、ネットワーク注文書に記載するクレジットカード情報についてみると、注文書にはカード番号と有効期限だけを暗号化するなど木目細かな情報の秘匿ができるようになる。

■SOAP メッセージセキュリティ

　OASIS（Organization for the Advancement of Structured Information Standards）のWSS TC（Web Service Security Technical Committee）では、SOAP Body メッセージやHeader の指定要素に対する署名や暗号化の指定をSOAP Header に記述する方式を定める。このときに用いるユーザー名や鍵情報や証明書の指定方式を別途セキュリティトークンとして定めている。セキュリティトークンにはユーザー名トークン、Kerberos トークン、X.509トークンやSAMLアサーションが定められる。SOAP メッセージに対するXML署名やXML 暗号を適用することで、Webサービスにおける汎用的なエンド・ツー・エンドのセキュリティが確保されることになる。

■証明書検証サービス（XKMS）

　PKIのセキュリティの基礎となっているのは公開鍵証明書の信頼である。信頼者（Relying Party）は署名者が送ってきた署名が正しいことを署名者の公開鍵で検証しなければならない。証明書の検証は、署名者の証明書からトラストアンカーCAまでのすべての中間CA の証明書のチェーンをたどって、すべての証明書が有効期間の中にあり、証明書の記載事項の各種制約を満たし、すべての証明書が失効されていないことを検証しなければならない。これを「認証パス検証」という。PKIの中で最も難しいのがこの認証パスの検証である。
　W3CではXKMS2.0（XML Key Management Service）の標準を策定している。X K M S は鍵の登録サービス（ X-KRSS：XML Key Registration Service Specification）に加えて、鍵の検証サービス（X-KISS ： XML Key Information Service Specification）を定める。図４に示すようにリクエスタは署名メッセージに証明書を添付してプロバイダに送ると、プロバイダは証明書検証依頼をX-KISSのValidation サービスに送る。X-KISS は背後にあるPKI のリポジトリを検索して認証パスの検証をプロバイダに代って行う。プロバイダは証明書の信頼を得て、その公開鍵でリクエスタの署名を検証できる。X-KISSサービスを用いると署名検証を行うアプリケーションを容易に開発できるようになる。


　　　　　　　　図4 X-KISS に証明書検証を依頼

■新しいSSO 技術（SAML）

　SAML（Security Assertion Markup Language）は、認証・認可のためのセキュリティ情報（アサーション）を交換する仕組みを提供する。SAMLは要求と応答のプロトコルと応答に含まれるアサーションの構文仕様を定めている。
　図5にSAML のフレームワークを示す。System Entity（クライアントまたはクライアントからアクセス要求を受けたサーバ）は、まずSAML認証オーソリティにSAML認証要求としてクレデンシャル（パスワードや鍵情報など）を示す。
　認証オーソリティはクレデンシャルを検証し、主体の本人性（Identity）を証明する認証アサーションを発行する。次にこの認証アサーションを属性オーソリティまたはPDP（Policy Decision Point）に示して役割や認可権限を問合わせる。属性オーソリティはポリシに沿った主体の資格などの属性アサーションを発行する。PDP（Policy Decision Point）はPEP（Policy Enforcement Point）から認可要求を受け、認可権限をポリシデータベースから検索し認可決定アサーションを発行する。PEP はこの認可決定アサーションによって、アプリケーション要求に沿ったWeb ページや資源へのアクセスを実行させるのである。


　　　　　　　　　　　図5 SAML フレームワーク

■Webサービスの相互運用性　WS-Iプロファイル

　Web サービスがパブリックなサービスとして展開されるためには、Web サービスの相互運用性の確保が重要な課題となる。Web サービスは１つの標準で構成されるのではなく多くの技術要素や標準の組み合わせからなる。また、この技術は発展途上の技術であって新たな要素技術の出現や標準のバージョンアップなどが続いている。WS-I（Web Services Interoperability）は、Webサービスの相互運用性を確保するために設立された業界団体で、現在約170社が参加している。WS-I では2003年8月にBasic Profile 1.0を定めた。Basic Profile 1.0は既に確立されている標準、XML Schema 1.0、SOAP 1.1、WSDL 1.1、UDDI 2.0を用いプロファイルを定めている。
　さらに、このプロファイルを使ったサンプルアプリケーションやUse Caseや実装ガイドラインを示しており、プロファイルに従った実際の実装をテストするツールも用意された。
　ただし、現在のWS-I Basic Profile 1.0にはセキュリティメカニズムの仕様は含まれていない。セキュリティについては最低SSL/TLS のセッションのセキュリティを使うことを推奨しているだけである。

◆　◆　◆

　PKIは今まで証明書をいかに安全に発行するかに注力されてきた。しかしこれからは、PKIはまさにインフラストラクチャとして陰に隠れるようになる。Web サービスによるインターネットの様々なアプリケーションが、バックエンドのPKIで安全を支えられるようになっていくだろう。

執筆者プロフィール 鈴木　優一（すずきゆういち） 　エントラストジャパン株式会社　最高技術責任者1963年、電気通信大学電子工学科を卒業、1965年、東京大学大学院物理学科修士。インターネット、ネットワーク・セキュリティを専門に活動している。 　現在、エントラストジャパン(株)のCTOとしてPKIの普及に努めている。著書に「ネットワークの構築と運用」（光芒社、1998）、訳書に「PKI 公開鍵インフラストラクチャ」（ピアソンエデュケーション、2000）、共著に「情報セキュリティ事典」（共立出版社、2003）があり、数々の雑誌の寄稿がある。