SOAPのセキュリティはどうなっている？：SOAPの仕掛け（2）（2/3 ページ）

SOAPのセキュリティ確保の仕組み

　SOAPのようなXMLによるデータ交換のセキュリティが、普通のHTTPやSMTPのセキュリティと違う点を考えてみよう。

■データ交換時のセキュリティ

　XML文書によってインターネット上でデータ交換を行う場合、やはり気になるのがデータの盗聴と改ざんである。XMLはテキストデータなので、HTTPやSMTPを利用してやりとりされることが多いのはすでにご存じのとおりだ。この場合、HTTPの通信を暗号化するHTTPSや、電子メールの内容を暗号化するS/MIMEといった手段を利用すれば盗聴や改ざん防止になる。こうしたセキュリティの確保は、企業のシステム同士をインターネットで接続する際には必要なことだろう。

HTTPSを利用した通信では、インターネット上で暗号化されたデータとしてやりとりされる

　SOAPで通信を行うときも、もちろんこれらのプロトコルは利用される。しかし、HTTPSやS/MIMEで実現されるセキュリティの範囲を考えると、「XML文書全体を」「ネットワークを通過している間だけ」暗号化できる、ということになる。

■XML文書の部分暗号化

　XML文書を単純なテキストと比較したとき、その内容が構造化されているという特徴がある。この特徴を利用して、XML文書の中から構造に従ってある特定の部分のデータだけを取り出して参照する、といった処理が要求されることもある。

　ショッピングサイトから小売店に出荷指示のXML文書が渡されることを考えてみよう。出荷指示のためのXML文書には、商品の種類や数といった商品の情報、顧客の名前や住所といった届け先、カード番号といった課金情報が含まれているとする。このとき、商品情報や届け先は小売店から見える必要があるが、課金情報は見えないようにしたい。しかし、課金情報はそのままカード会社などに渡ったときには、再び見えなければならない。

BtoBでは、相手に応じてXML文書の一部分だけは見せたくない、といった暗号化のニーズが発生する

　このようなXML文書の部分暗号化のニーズは十分想定される。XML文書の部分暗号化とは、図のようにツリーの一部を暗号化し、後にそれを復号することだ。

　前述したように、暗号化の手法としてよく使われるHTTPSなどは、データ全体を暗号化するのには適しているが、一部のデータだけを暗号化するには不便なものである。そこで、XML文書の部分暗号化を実現するには、別の技術を用いる。それについては後述しよう。

■XMLの正規化は暗号化の前準備

　XML文書の暗号化や署名は、ちょっと考えると「テキストなんだから、署名や暗号化なんて簡単じゃん」と思われがちである。しかし、実はそうもいかない。ここでは、暗号化のために必要な正規化について解説しよう。

　XML文書は（人間が意味を読み取れるという意味で）テキストとして記述されるが、それをバイト列として見ると意味が変わってくる。例えば、次の2つのXMLドキュメントの一部を比較してほしい。

　 <DATA1>AAAA</DATA1>
　 <DATA1 >AAAA</DATA1>

　1行目と2行目を見比べると、2行目の最初のタグには、スペースが含まれている。この2行を比べるとどうだろうか、これは同じものだろうか。XML文書として見たときはスペースがあっても別に誤りではなく、両者は全く同じ意味を持つ。しかし、単なるテキスト、すなわちバイト列として見たときは、両者は違うものになる。

　似たような例をもう1つ紹介しよう。

<null></null>

と記述したものと

<null/>

　と記述したものは、XML文書では同じものを表している。

　XMLではこのように、同じ意味ながら表記の揺れが存在する。しかしXML文書と、電子署名などの暗号化技術を組み合わせて利用した場合、暗号化技術はデータを単にバイト列として見なしてしまうため、XMLの表記の揺れを許容しない。1bitでも変更されていれば「文書が改ざんされた」と見なされてしまう。

　そこで、XMLで暗号化技術を利用するために「正規化（Canonical）XML」という手段を用いる。正規化は表記の揺れを一定のルールに従って統一してくれる。正規化後は同じ意味のXML文書は必ず同じ形式になるため、XML文書を暗号化したり署名したりする場合には、まず正規化する必要がある。

　試しに、以下のドキュメントをXML正規化ライブラリで正規化してみよう。

<?xml version="1.0" encoding="Shift_JIS" ?>
<!DOCTYPE TESTDOC [
<!ELEMENT TESTDOC (DATA*)>
<!ELEMENT DATA (#PCDATA)>
<!ATTLIST DATA attr CDATA #IMPLIED>
]>
<TESTDOC>
  <DATA >AAAA</DATA>
  <DATA>AAAA</DATA>
  <DATA attr = "1"></DATA>
  <DATA attr="1"></DATA>
  <DATA></DATA>
  <DATA/>
</TESTDOC>

結果は以下のようなものが出力される。

<TESTDOC>
  <DATA>AAAA</DATA>
  <DATA>AAAA</DATA>
  <DATA attr="1"></DATA>
  <DATA attr="1"></DATA>
  <DATA></DATA>
  <DATA></DATA>
</TESTDOC>

　最初のリストでは各行ごとに存在していた表記の揺れが吸収されて、「同じ意味のものは同じ表現に」なっているのがお分かりいただけると思う（また、正規化では自動的にXML宣言やDTDの部分なども削除される）。

　ちなみに、Canonical XMLは、W3Cにおいて3月19日に勧告になった。また、Canonicalizationという単語は長いので、C14Nと表記することが多い（CとNの間に14文字あるため）。

■XML文書への署名で改ざん防止

　BtoBシステムにおいて、XML文書はメッセージとして扱われることが多い。この場合、メッセージはWebブラウザに表示されるコンテンツと違い、いったん保存されてから参照されることが多いだろう。

　取引先から注文を受けた企業が、その注文に従って商品を出荷したところ、納入先から「こんなものは注文していない」といわれたとしよう。そのとき受注側は「確かにこのXML文書で受注しています」という証拠を示せるだろうか。XML文書はテキストであるため、個数や商品名などが自由に改ざん可能だ。これでは強力な証拠とは言い難い。また故意に改ざんされなくとも、通信途中で文字化けが発生しないとも言い切れない。つまり、プレーンなXML文書のままでは、信頼のおける取引の基盤にはなりにくいだろう。

　SSLを使えば、インターネットを通過する際の盗聴や改ざんは防止できる。S/MIMEを使えば、サーバ上での盗聴や改ざんはある意味で防止できる。しかしこれらの技術では、XML文書を作成した相手を特定し、受信後においても改ざんされていないことを証明し、送信者が確かにそのデータを送信したことの証拠とはならない。そこで登場するのが電子署名だ。

　実は、XMLに関するセキュリティにおいて急速に仕様策定が進められているのがこのXML文書に対する署名の仕様を策定する「XML署名」であり、W3CとIETFのジョイントワーキンググループでは、「XML-Signature Core Syntax and Processing（以下XML署名）」の仕様を策定している。XML署名は、昨年10月に勧告候補（http://www.w3.org/TR/xmldsig-core/）になっている。

　XML署名にはまず正規化を行う。そして、そこからダイジェスト値を計算する。

　ダイジェスト値というのは、XML文書の内容から計算される小さな値だ。ダイジェストは暗号化や圧縮と違い、逆方向に計算しても元の値に戻るとは限らない。しかし、元のデータが1bitでも違っていれば、大きく異なる結果が出るような計算式によって求められる値だ。内容を改ざんすると、このダイジェスト値が変わってしまうので、電子署名にダイジェスト値を含めておけば、改ざんを発見することができる。

　また、XML文書には、送信者だけが持つ鍵を使って電子署名が行われるため、電子署名付きのXML文書を受け取ったなら、送信者は「そんなデータは送っていない」と否認することはできなくなる。