『セキュリティはなぜやぶられたのか』を読む 4
前回の続き。 また間が空いてしまった。 いや, 仕事が忙しくなったり, 体調を崩したり, 他の本に浮気したり, そんで内容を忘れちゃってまた読み返したり, いろいろ大変だったのよ。
今回は第2部の13章と14章。 量は少ないけど13章は認証の話とかあって個人的にはとても重要だと思っているので重点的に。 14章は実例がたくさん載っていて(思わず笑っちゃうような事例もある)なかなか楽しい。 もし 『セキュリティはなぜやぶられたのか』 をまだ読んでなくて本屋さんでちょっとだけ立ち読みしてみたいなら, 14章を読むことをお薦めする。 14章にはそれまでの章で書かれていることのエッセンスが詰まっている。 ここを読んで面白いと思ったら購入して最初からじっくり読んでいけばいいだろう。
まず14章から軽く言及しておこう。 先ほど書いたように, 14章ではさまざまなセキュリティ戦術が紹介されているが, その中でも特に気になるキーワードが「セキュリティプロトコル」である。
「「セキュリティプロトコル」とは、 信頼を託された人が実行する一連のステップ、 セキュリティルールを適用するための手順や約束事のことだ。」(p.333)
プロトコルと同じように「手続き」も、 普通は、 信頼を託された人が実行する一連のステップを指す。 ただし、セキュリティの世界では、事件が起きたときの対応を手続きという。 (中略) プロトコルとは、 信頼を託された人が毎日行うことであり、 手続きは、 異常時の対応として行うことである。(p.336)
前回 「セキュリティ・リスク・マネジメントというのはやはり「管理」ではなく「経営」だと思う」 と書いたが, これはセキュリティプロトコルという戦術を見ても分かる。 セキュリティプロトコルや「手続き」を円滑に実行するためには「計画」と「試験」が欠かせないが, 試験については以下のように述べられている。
条件と選択肢と順番が増え、 システムが複雑になると、 試験は不可能になる。 試験すべき条件を全部洗い出すことも不可能になるし、 洗い出した条件のすべてを試験するのも無理になる。 こうなると、 試験をしたふりをせざるをえない。(p.340)
一方、 信頼を託す人々については、 試験が不可欠である。 確認するのはセキュリティの有効性ではなく、 手続きやプロトコルが機能するのか、計画、訓練、演習の効果があったかである。 (中略) 受動的失敗は難しいが、能動的失敗なら試験でかなり把握できるのだ。(p.341)
つまりセキュリティ対策は全体最適が不可能である以上どうしても部分最適にならざるを得ないが, それを実行する(信頼を託された)人の側をセキュリティプロトコルで規制することでカバーする(すなわち「運用でかわす」)わけだ。
そこで13章の「識別、認証、許可」の話につながる。 それぞれの違いは p.269 に書かれている。
- 識別:
- あなたは誰?
- 認証:
- 証明しろ
- 許可:
- この範囲のことはしてもよい
そもそも何でセキュリティシステムに識別や認証や許可なんてものが必要かというと, セキュリティシステムは難攻不落の障壁ではなく, 人(=攻撃者)を拒絶するシステムであると同時に人(=正当な利用者)を受け入れるシステムでなければならないからだ。 誰もアクセスできないシステムは(時間が止まった世界と同じで)システムとしての存在理由がない。
ではまず, 識別と認証と許可について気になる記述をピックアップ。
「許可を実現する際によく使われるのが「識別」である。 (中略) 多くのシステムで許可と識別がごっちゃになっていることもあり、 ふたつは同じものだと思われることが多い。 しかし、 ある人物が誰であるかわかることと、 その人物には何が許可されているかがわかることは別である。」(p.271)
「認証には、 基本的に、 その人物が知っていることを使う、 持っているものを使う、 誰であるかを使う、 という三種類の方法がある。」(p.274)
「識別と認証を混同すると、深刻なセキュリティ問題になる。」(p.278)
例えば Twitter アカウントは識別と認証と許可を兼ねている。 ユーザ名で識別しパスワードで認証(「知っていることを使う」記憶認証)し認証後はユーザに許可されている操作の全てを行うことができる。 Twitter には API が用意されているが, それを使うためにはユーザごとにパスワード認証し許可を得る必要がある。 従って Twitter API を使うサービスを利用したければ, そのサービスに秘密情報を渡すしかない。 そしてそのサービスは本来のユーザに許可されている全ての操作(例えばパスワードを書き換えるなど)を行うことができる。
問題は「誰であるかを使う」認証だ。 この認証の典型例がバイオメトリクス認証である。 ここで告白と懺悔。 以前私は「「「バイオメトリクス認証」と呼ぶのは止めよう」キャンペーン」という一人キャンペーンを張ったことがあるが, 完全に識別と認証と許可がとっちらかっている。 すみません。 我ながら困ったもんだ。 なので今後は 『セキュリティはなぜやぶられたのか』 の記述に合わせてちゃんと考えていくことにしよう。 まずはバイオメトリクスに関する記述をひろってみる。
バイオメトリクスは、 忘れないという点がパスワードやトークンよりもすぐれている (事故で指をなくしたり病気で声が出なくなったりと失うことはある)。 変更できないというのも大きな特質だ。 (中略) ここで問題になるのは、 バイオメトリクスが世の中にひとつしかない識別子ではあるが、 秘密ではないということだ。(p.276)
「これ(バイオメトリクス:引用者注)を識別ツールとして使う間違いも見受けられる。 認証システムなら、 「このバイオメトリクスはこの人物のものか」というシンプルな問いに答えればいい。 識別システムでは、 「あまり信頼性の高くないバイオメトリクスを集めた巨大なデータベースの中に登録された人の中に、 このバイオメトリクスの持ち主はいるか」と問いが格段に難しくなるのだ。 バイオメトリクスを識別ツールとして使うと能動的失敗が多くなるし、 最終的には受動的失敗も避けられない。(p.278)
「識別ツールとして使う間違い」というのは, この本の中でたびたび紹介されている「空港などで生体情報を使って大勢の中からテロリストを探し出す」システム事例等を指している。 ところで NIST は各ベンダのバイオメトリクス認証製品を使った性能テストの最新データを今年の3月に公開している。
これによると, 『セキュリティはなぜやぶられたのか』 の原書が出版されるちょっと前の2002年に比べてバイオメトリクスの技術は格段に向上しているが, それでも13章で書かれている試算と同程度の認識率だ。 つまり「生体情報を使って大勢の中からテロリストを探し出す」ような識別システムでは依然としてあまり実用的ではないことになる。
また(本では触れられていないが)バイオメトリクスは別の問題も含んでいる。 いわゆる「固有 ID」の問題だ。 生体情報を識別に使おうとするなら, それをキーにしてドメインを越えた「名寄せ」ができることにすぐ気がつく。 今のところ銀行 ATM の相互運用でもそういった気配はないので杞憂に終わる話かもしれないが, 今後注目してみてもいいかもしれない。
さて, 認証についてもう少し見てみる。
「認証とはシステムであり、 きちんと機能するためには、 認証方式を決めただけでは不足である。」(p.281)
「まずは認証情報の置き場所だ。 今までは認証を受ける人が持ち歩いていたが、 認証する側がもってもいいし、 そのほうがセキュリティが高くなる。」(p.281)
「検討すべきもうひとつの点は、 認証する場所である。 目の前にいる人の認証より、 ネットワーク経由での認証のほうが難しい。 偽造が簡単で検証が難しいからだ。」(p.282)
「認証システムのセキュリティは、 実は、 その登録システムと破棄システムによって決まる。」(p.284)
「トークンは、 識別用であれ、 認証用であれ、 許可用であれ、 それ自体の認証が必要である。」(p.287)
コンピュータ, 特にネットワーク経由での認証が難しいのは, それがトークンによって行われるためであり, トークンを認証するための上位システムが必須になるからだ。 これは PKI を例に考えれば分かりやすい。 『暗号技術入門』 では
「何も信頼できない状態から信頼を作り出す技術はまだ生み出されていません。」(p.263)
とあるが, 全くそのとおりで, あるトークンが正しいと証明するためには最終的に人による判断が必要になる。 裏を返すと, どんな形であれ「人による判断」が全く入らない認証はセキュリティ的に危ういと言える。 しかし, また Twitter を引き合いに出してしまうが, これらのサービスの多くはそこまでの認証を要求していない。 識別トークンとしてのユーザ名と認証トークンとしてのパスワードとの間の整合性が取れていれば十分であり, その背後にいる筈のユーザの整合性については全くスルーである。 これはそのサービス単体で見れば(サービスの社会的・経済的インパクトが強くなければ)問題ないのかもしれないが, 「Web 2.0」と呼ばれコンテンツどころか「機能」すらもマッシュアップされる現状では早晩深刻な問題を抱えることになりそうな気がする。 これが今私が考える「認証預託(仮称)問題」だ。
さぁ, そろそろメインディッシュは終わりかな。 もう少しだ。 続きはそのうち。