日経IT Proの「今週のSecurity Check[一般編]」に、「“進化”するシングル・サインオン」という記事が出ている。SAMLとLiberty Allianceのことについて書かれたものだが、Libertyの本質が説明されていない。
この記事は、シングルサインオンの意義について、
利便性が高まる分，1回の認証をくぐり抜けられると，複数のシステムにアクセスされてしまう恐れはある。しかし，ユーザーとしては，1つのパスワードさえ管理すればよいので，複数持っている場合よりも，きちんと管理できるだろう。（中略）
SSOはセキュリティを確保しつつ，利便性を提供できる仕組みといえる。
とした後、現状の問題点として、
しかし，現状では問題がいくつかある。その一つが製品間の相互運用性の問題である。各ベンダーは独自の方法でSSOを実現させているので，異なるベンダーの製品間では，認証の連携を行えない場合がある。このため，閉じた企業内では問題なくSSOを実現できても，複数の企業間あるいは，Webサービスに代表されるビジネス連携フレームワークの中で，SSOを実現することが難しい。
という点を挙げ、それを解決するものとして、
そこで，2002年の後半以降，業界では，SSOの標準化や認証連携の実現へ向けた動きが始まっている。代表的なキーワードは，「SAML（Security Assertion Markup Language）」と「Liberty Alliance Project」である。
と、Libertyのことを挙げている。
この記事はLibertyの意義を過小評価している。Libertyのプライバシー確保の面をまったく説明していない。
まずは、Liberty AllianceのID-Federation Frameworkがどういうものか、Libertyアーキテクチャ概要に掲載されている「ユーザ体験の例」を見るとよい。
ここではまず、Joe Selfという人物が、「Airline.inc」と「CarRental.inc」という2つのサービスプロバイダそれぞれ用に、独立に作成したアカウント「JoeS」と「Joe123」を持つ状況を前提としている。最初に同氏が、Airline.incにJoeSアカウントでログインし、数時間以内にCarRental.incにJoe123でログインすると、「CarRental.incのアイデンティティをAirline.incのアイデンティティと連携させますか？ はい/いいえ」という選択肢が現れる（2.1節）。ここで「はい」を選択したとすると、後日Airline.incかまたはCarRental.incにログインしたときに、もう一方にアクセスするとログイン手続を省略してアクセスできる（シングルサインオンが実現される）というわけだ（2.2節）。
このとき、Airline.incにはJoe Self氏のAirline.inc用のアカウントである「JoeS」というユーザIDしか伝えられず、CarRental.incにはCarRental.inc用の「Joe123」というユーザIDしか伝えられないという点がミソである。アイデンティティ連携を実施するステップで、CarRental.incにアクセスしたとき「あなたはAirline.incにサインオン中です」と表示されるのは、Webブラウザが直接Airline.incにアクセスして認証済みであるという情報だけをCarRental.incに送信しているためであり、連携しますか？に「はい」と答えた際に、Airline.incのアイデンティティ(ID)プロバイダのサービスに、Airline.incの「JoeS」がCarRental.incの「Joe123」と連携するという設定が記録されるが、このとき「Joe123」というユーザIDをそのまま使うのではなく、ランダムに生成した「ハンドル」を使う（図14）。このハンドルは、p.36によると、「ユーザーハンドルは定期的に更新する必要があります」となっている。
そして図15のように、複数のサービスプロバイダのアカウントをひとつのIDプロバイダーに連携させることができる。このとき、ユーザはサービスプロバイダAとBにシングルサインオンできる状態になるが、この仕組みにより、サービスプロバイダAとBが仮に結託したとしても、それが同じユーザのログインだということを判別できないようになる。
この方式が、日本の携帯電話事業者がやろうとしている「モバイルID」のような共通ID方式よりプライバシーの保護レベルが高いことは明らかだろう。
仮にIDプロバイダが悪意を持ち、各サービスプロバイダと結託するとどうしようもないという話は残るように思えるが、これはどうしようもないか。しかし、図16のように複数のIDプロバイダを利用することもできるため、完全にひとつのIDプロバイダに託すのではなく、複数のIDプロバイダにリスクを分散させることができそうだ。この点がMicrosoftの初期のPassportとは異なるように思えるが、Passportもその後進化しているようなので、最近はどうか知らない。
具体的な使い方としてはこんな感じだろうか。ユーザは、航空会社やレンタカー会社に個別にユーザ登録をする。この際、各会社へのユーザ登録に必要な最小限の情報を登録をする。ある日、航空会社Aを利用したときついでにレンタカー会社XとID連携の設定をしておく。別の日、別の航空会社Bを利用したときに同じレンタカー会社Xと連携設定する。さらに別の日、同じBを利用したときに別のレンタカー会社Yと連携させたとしよう。予約開始にあたり航空会社から使い始めるのであれば、航空会社AかBにログインして作業を始めると、そのままシングルサインオンの状態でレンタカー会社XやYを使える（AでログインしたときはYは使えない）。このとき、万が一航空会社Aがレンタカー会社XとYと結託したとしても、Yにおけるユーザのアカウントは、XやAのアカウントと同一人物だということは判別されずにすむ。
このように、Libertyはシステムアーキテクチャとして、ユーザのプライバシーを可能な限り失わせずに済むことを実現している。なのに、IT Proの記事では、この仕組みが「異なるベンダーの製品同士の連携が可能となるのだ」という視点でしか書かれていない。
Libertyのプライバシー面での意義を解説した記事は少ないようだ。プライバシーを無視するのであれば、こんな複雑な仕組みを使うまでもなく、共通ID方式にすればシングルサインオンは簡単に実現できるだろう。複雑にせざるを得ない理由を「異なるベンダーの製品同士の連携」のためだと理解することも可能だが、それは副次的なもので、プライバシー確保のためが第一の目的だろう。
この意義があまり重視されていないようで嫌な予感がするが、共通ID方式のプライバシー上の問題点がセキュリティ技術者たちに理解されていないことの現われではないかと心配だ。
セキュリティ技術者がプライバシーを語るときに、「暗号で保護する」といったように、情報の盗み出しを防止するという観点でしか語られないことが多いように思える。例えば、8月16日の日記に
「e-Japan重点計画-2003」のp.45に次の記述がある。
(2) インターネット端末やインターネット家電が普及し、それらがインターネットに常時接続されることを想定し、十分なアドレス空間を備え、プライバシーとセキュリティの保護がしやすいＩＰv6を備えたインターネット網への移行を推進する。
e-Japan重点計画-2003, III重点政策5分野, 1.世界最高水準の高度情報通信ネットワークの形成
IPv6が「プライバシーの保護がしやすい」ものだというのは、初めて目にした。どういう根拠なのだろうか。ちゃんとわかっている人が書いているのかどうか、不安になる。
ということを書いたが、ひとつの憶測は、IPv6が標準でIPsecを提供するため、暗号による通信のセキュリティの確保ができ、その結果プライバシーが確保されるということを言っているのではないかという解釈だ。日本のIT屋の間ではプライバシーがそういう観点でしか語られていないという疑いがある。
Libertyは、以下の記事にあるように、セキュリティとプライバシーと利便性の3つを同時に実現しようとするものだ。
インターネットが個人の生活に普及しつつある中、さらなる浸透のために解決すべき課題が、アイデンティティ・マネジメントといえる。......
さらには、次世代のアプリケーションであるWebサービス対応のアプリケーションの提供が本格化した場合、認証関連で普及が阻害されるということも考えられる。だが、ユーザーのプライバシー保護懸念の声も考慮しなければならない。この課題には、業界全体、場合によっては政府も巻き込んだ形で取り組み、より良いモデルを見出していかねばならない。 「アイデンティティ・マネジメントはインターネットの次の大きなチャレンジ。ソフトウェア開発者、セキュリティのエキスパート、企業の経営陣、そしてユーザー、すべてが関心を払わなければならない課題だ」とシュネル氏は言う。
ここで言う「プライバシーは」、セキュリティの結果としてのプライバシー（情報の盗難防止）のことではない。安易なシステムアーキテクチャの下では、むしろセキュリティ強化はプライバシーを低下させる（同一性を不必要に記録可能にさせる）ものであり、両者は元々相反する性質のものだ。情報セキュリティに携わる者はこのことを基礎的な素養として心得ておくべきである。Libertyは、工夫されたシステムアーキテクチャによってこれらを可能な限り両立させようという試みだろう。
日経Windowsプロからすばらしい記事が出ていた。
通常，パソコンにプリインストールされるWindows OSへの修正は，Service Pack（SP）のレベルなことが多い。しかし，現在はMS03-026のセキュリティ・ホールを狙ったBlasterワームや，「Nachi（Welchia）」ワームが蔓延しているため，「買ってきたパソコンをインターネットに接続するだけでワームに感染する」という状況になっている。このような状況でも安心して利用するため，NECではWindows XPの新SPの提供を待たずに，自社で修正パッチをあらかじめWindows XPに適用して，新製品を出荷する。出荷開始日はいずれも9月11日である。
同様の取り組みは，富士通やソニーも秋冬モデルの新製品から実施する予定である。ただし，NECのパソコンにしても，現在店頭に並んでいるモデルは，セキュリティ・ホールが無修正のままだ。......
重いPCベンダーの「責任」Microsoftだけでなく，「Windowsプレインストール・パソコン」という最終製品を販売しているPCベンダーにも努力が求められる。PCベンダーは，Microsoftから“調達”したWindows XPに自社でソフトウエアを追加して販売している。それと同じように，MS03-26の修正モジュールもあらかじめ製品にインストールすればよいのだ。
実は，PCベンダーにはそのような修正を加える権利がMicrosoftから与えられている。実際にNECや富士通，ソニーといった大手ベンダーは，9月〜10月に発売する予定の秋冬モデルの新製品から，MS03-26の修正モジュールをあらかじめ追加して製品を販売する予定である。
Windowsパソコンという最終製品を販売しているのは，MicrosoftではなくPCベンダーである。消費者に対する責任を果たすために，一刻も早くセキュリティ修正を施したパソコンを出荷するべきである。
パッチを適用したパソコンを出荷するのは大変よいことだが、Blasterワームが流行していてやむにやまれずといったところだろう。ユーザサポートのコストを下げる意味もあるに違いない。
パッチを事前に適用しておくのが、MS03-026だけなのか、他も全部なのかが興味深いところだ。また、今後も継続して最新パッチを適用した上で出荷するのかも興味深い。
ワームに感染する穴でなければあけたまま出荷してもよいというものではないだろう。個別のターゲットを狙った攻撃による被害の可能性は依然として残る。
パッチが出ているにもかかわらずそれらを適用せずに出荷したパソコンメーカーは、欠陥による損害が予見できたはずであり、損害賠償訴訟を起こされたら負けるのではなかろうか。というか、負けるようでないと世の中、このままではダメなんではないか？ 誰か一度、判例作りのために試したらどうか。あいにく私は損害を被っていないので訴えられないが。
マイクロソフト日本法人は，Blaster対策CD-ROMを20万枚配布するといった対策を発表しているが，年間1000万台パソコンが出荷される日本においては，焼け石に水である（関連記事）
焼け石に水という以前に、そもそも、パソコンメーカーが現在店頭に置いている製品を、修正CDを添付せずに販売し続けることが、違法でないことがおかしい。マイクロソフトの20万枚など、ただのポーズだろう。配布のコストもセキュリティベンダーの宣伝費でまかなったに過ぎない。
ちなみに、2002年にソニーのVAIOにプリインストールされていたソニー製のソフトウェアに任意コマンド実行のセキュリティ欠陥が発覚したときには、
ソニーによると、...... 1月24日にこちらのWebサイトからセキュリティ・プログラムを無償ダウンロードできるようにしたほか、希望するユーザーには、CD-ROMの配布も行う。また、店頭にある在庫については、アップデート用CD-ROMを商品に添付する。
なお、1月26日以降に発売する機種については全モデルに対策用プログラムを付属、またはインストールして販売するとしている。
という極めて適切な対応がとられた。というか、これが当たり前ではないのか？