XML暗号化の基礎と実践
前編 XML暗号化と正規化と電子署名 （3/6）
|
3. XML文書のアクセスポリシーとシングル・サインオン |
XML文書のセキュリティに関しては、これまで紹介した以外にもいくつかの仕様が策定されている。
■XACML（XML Access Control Markup Language）
XACMLは、XML文書にエレメント単位のアクセスポリシーを定義するための規約だ。これはW3CではなくOASISで規約が作られている。
XACMLでは「だれが」「何を」「いつ」「どのように」情報にアクセスできるかを定義するための表現方法を決めている。ただしXACMLは表現方法の規約なので、XACMLに対応した実装がないと意味がない。ログインした相手に対して、XACMLで定義されている形式に変形されたXML文書が取り出せる、ということを想定している。また、あるエレメントにアクセスする場合には、監査として記録をとる、ということも指定できる。これによって「許可」「監査」の2つの要件に対する対策が、ある程度できるようになる。
■SAML（Secure Assertion Markup Language）
シングル・サインオン（SSO）とは、「ユーザーが1回のログインで、複数のサーバに認証されアクセスできるようにする機能」だ。SAML（セキュリティ表明マークアップ言語）では、BtoBなどで複数のサーバへXML文書が転送されることを想定して、XML文書のシングル・サインオン的な機能を実現する仕様である。
従来のEDIなどの独自業界の閉じた世界では、EDI内の複数のサーバを経由するXMLデータの伝播に対して、それこそシステム全体が初めから、シングル・サインオン（最初に一度認証が許可されれば、後のサーバ群での認証は、暗黙の了解で必要がない）の状態であった。
しかし、BtoBのような、インターネット上に点在するサーバ間（しかも複数の企業に分散している可能性もある）の認証の問題はそう簡単には解決できない。ベリサインおよびほかのベンダによって開発されていたSAMLは、まさに、この問題を解決する。
このSAMLが登場するまでは、インターネットを複数のサーバにまたがって（もしくは横切って）XML文書のやりとりが企業間で発生するBtoB、BtoCには、買い手、売り手あるいは企業がどの資源をアクセスしてもよいのかを明示する、認可情報用の標準言語が存在しない状態があった。SAMLは2つの先行プロトコル、S2ML（Security Service Markup Language）およびAuthXML（Authentication XML）を組み合わせて、認証、認可情報についての、より安全な電子商取引処理を可能にするXML標準を提示しているといえる。
このSAMLを採用した通信プロトコルは（SAMLは、HTTPとSOAP接続の両者に用意されている）、顧客とパートナーおよびサプライヤ間で、1つの認証スコープでデータを交換することができるようにする。SAMLをHTTP／SOAPメッセージに付加することで、信頼情報をポータブルに持ち回りできるというメリットがあるわけである。
例として、SOAPにSAMLの記述を付加して認証を取っている内容を紹介する。
POST /SamlService HTTP/1.1 |
| 赤い文字が、SAMLによる認証要求部分 |
Content-Type: text/xml |
| SAMLによって認証取得が行われた部分。この認証取得情報を、複数のサーバに持ち回ることになる |
次に最も簡単な認証のパターンを2つ示そう。
図4の例は、あるユーザーがMegaCorpに対して認証されたら、その下請け会社であるMiniCorpに対しては、再度認証行為をしなくてもシングル・サインオンでアクセスできる、という例だ。
 |
| 図4 MegaCorp.で認証されたXML文書なら、MiniCorp.では再度認証の必要なく処理してもらえる |
図5では、いったんユーザーがMegaCorpに認証を許された後、MegaCorpがSAMLによりMiniCorpにサインオンして、なにがしかの処理をする、という例である。
 |
| 図5 MegaCorp.が、ユーザーの指示に従って、直接MiniCorp.に対して処理を要求する |
SAMLの仕様は、OASISのセキュリティ関連のWebページにあるように膨大であり、理解するための日本語文献もまだ乏しいが、将来のWebサービスの複合連携に使われる重要な技術の1つになる。
■XKMS（XML Key Management Service）
XKMSの仕様は米ベリサインや米マイクロソフト、米ウェブメソッドなど複数のベンダが提案したもので、既存のシステムにデジタル署名や、暗号化の技術を簡単に組み込めるような基盤を提供する。
一般に、デジタル鍵のオンライン認証、デジタル署名、そしてデータ暗号化の扱いは、「組み込みが簡単で、ほかのさまざまなエンタープライズアプリケーションと相互接続できた方がよい」ものだ。しかし、得てしてセキュリティの機能は無視されやすい。そうした現状の解決策として、XKMSはどのようなPKI製品、サービスを使っていても、相互に安全に接続できるようなBtoB、BtoCアプリケーションを構築できる材料を提供するのである。下図を見てもらうと分かるように、XKMSは署名サーバ、検証サーバ、XKMS/PKIサーバそれぞれが、XMLでデータ交換することを基本としている。
 |
| 図6 XKMS/PKIサーバによって、Webサービスで署名や検証が提供されるようになる |
このデータ交換を、ＩＢＭの「IBM WebServices Toolkit」の中に含まれている「XKMS/PKIデモ」では、これらをWebサービスとして構成している。
XKMSでは「PKIの隠ぺい」が図られているといえる。図6の署名サーバは公開鍵をXKMS/PKIサーバに登録しておき、検証サーバは復号時に任意に、自分の欲しい公開鍵をXKMS/PKIサーバに問い合わせ、それを取得し、署名文を検証する。従って、署名するための秘密鍵、検証するための公開鍵、証明書、といったPKIに関する情報は隠されることになる。むしろ、第三者が介在したことにより、PKIに関する必要情報は常に管理されるという安心感が生まれる。
もし自分が鍵をなくした場合でもXKMS/PKIサーバに問い合わせて、そこから入手すればいいし、反対に公開鍵自体を署名サーバが取り消し、検証をさせないということも可能になる。
アプリケーションにPKI機能を組み込むには、従来であればPKIベンダからツールキットを購入し、それを用いて組み込むしかなかった。この場合には、ベンダ間の互換性に不安があったが、XKMSでは、企業がどんなPKIツールを使っているかに関係なく、XKMSという鍵管理インフラを簡単にWebサービスとして接続し、使うことができるようになる。
PKIの技術とXMLを組み合わせる動きとしてはほかにもさまざまなものがある。すべてを詳細に解説はできないので、ここで名称だけを挙げておくと、XMLで電子署名を実現するXML Signatureや、XKMS Key Registration Service Specification（XKRSS）、XKMS Key Information Service Specification（XKISS）などがある。
今回は、XMLにまつわるセキュリティ関連の仕様などについて紹介した。次回は、XMLのセキュリティ・ツールである「IBM XMLセキュリティー・スイート」と、XKMSの実装が提供されている「IBM WebServices Toolkit」の具体的な使い方をご紹介する予定である。
後編「XML暗号化と電子署名の実践」へ続く。
 |
3/6 |  |
| Index | |
| XML暗号化の基礎と実践 | |
| 前編〜XML暗号化と正規化と電子署名 | |
| 1. SSLの利用とXML暗号化の違い | |
| 2. 電子署名とXML文書の正規化 | |
 |
3. XML文書のアクセスポリシーとシングル・サインオン |
| 後編〜XML暗号化と電子署名の実践 | |
| 4. XMLセキュリティ・スイートを使う | |
| 5. XML文書に電子署名をしてみる | |
| 6. 署名された文書の改ざんを検証 | |
- QAフレームワーク：仕様ガイドラインが勧告に昇格 （2005/10/21）
データベースの急速なXML対応に後押しされてか、9月に入って「XQuery」や「XPath」に関係したドラフトが一気に11本も更新された - XML勧告を記述するXMLspecとは何か （2005/10/12）
「XML 1.0勧告」はXMLspec DTDで記述され、XSLTによって生成されている。これはXMLが本当に役立っている具体的な証である - 文字符号化方式にまつわるジレンマ （2005/9/13）
文字符号化方式（UTF-8、シフトJISなど）を自動検出するには、ニワトリと卵の関係にあるジレンマを解消する仕組みが必要となる - XMLキー管理仕様（XKMS 2.0）が勧告に昇格 （2005/8/16）
セキュリティ関連のXML仕様に進展あり。また、日本発の新しいXMLソフトウェアアーキテクチャ「xfy technology」の詳細も紹介する
 |
|
|
|
|
