三つめの記事が公開されている。前に述べたとおり、武田さんが「定期的な変更」を「n 日以内で好きなときに変更する」という意味で使っているなら、パスワード管理のポリシーとしては expiration が決まっているだけの「不定期な変更」と同じであって、リスクマネジメントとしては n 日(つまり最大の日数)のあいだ同じパスワードを使い続けているものと想定してリスク分析しなければならない。

よって、「知らない間にパスワードが漏洩していても n 日で変更すれば被害を防げる」というポリシー、とりわけ n 日という具体的な数字に根拠がない限り、このようなポリシーは n > m であるような数字を幾らでも当てはめてもっと安全にできるので、更に上位のポリシー、つまり 90 日なら 90 日のあいだに漏洩していたら、運用側の責任として過失がないと認められるほど十分に短い値でなくてはいけないだろう。恐らく、そうであれば n = 90 というのは、いまどきあまりにも長すぎると思う。また、顧客台帳の Excel ファイルが一つだけ盗まれても当該の会社にとって重大なのであれば、n = 7(毎週変更)であろうと n = 1(毎日変更)であろうと、そのファイルが一つ盗まれたら終わりなので、パスワードの変更という手立てには「被害の拡大を防ぐ」という実質的な効果はない。

すると、一定の日数で変更すれば被害の拡大を防げると想定されている情報資産は、たとえば継続的に変化する内容を含むもの、例えば、どんどん増えていく顧客データを全て横取りするとか、漏洩している最中の会社で運用されている財務データや事業戦略の議事録などを盗み見したとか、そういったものになる。これだと、確かに継続してデータを盗まれることが被害の拡大となるので、そうした漏洩を任意のタイミングで防ぐような措置は必要だろう。

ただ、これは「たまたま(最大) n 日後にパスワードを変更して外部からのアクセスや外部への漏洩を遮断した」というだけのことであって、当該の情報漏洩に使われているマシンがバックドアに感染している場合には、ふたたび攻撃者に変更後のパスワードを通知してしまう可能性が高いと思う。あるいは、オンラインサービスのパスワードであれば、最初にそれが漏洩した原因を放置したままなら、変更しようとも、まさにパスワードを変更するときに再び漏洩するだけの話ではないか。要するに、パスワードの変更によって漏洩してしまっている原因を解消できない場合には、パスワードの変更という操作そのものに殆ど対策としての意味はないのではないかと思える。

>> Webアプリケーションの場合は新しいバックドアのようなソフトウェアをインストールすることはできませんから一般的な意味でいうバックドアが仕込まれることは考えにくいでしょう。 <<

オンラインサービスの場合はサービス提供側のサーバに脆弱性があると、バックドアを仕込まれるリスクがある。クライアント側のマシンに脆弱性があっても、drive-by-download によってマルウェアがインストールされるリスクがある。よって、僕らは武田さんが言うような意味で、オンラインサービスと OS とを「混同」しているわけではない。寧ろ、どちらにも同じようなリスクがあるという意味で「同じ」だと言っているのである。

あと雑感として思うには、武田さんに限らず、パスワードの運用ポリシー(作成、実装、管理など)について、暗号学からマネジメントまで見通した文献というものを国内で見たことがない。NIST の SP シリーズとまではいかなくても、国内のブログ記事や些末な事案を場当たり的にリンクするだけではなく情報セキュリティの体系立った論説として展開してもらいたいものだと思う。
Shared publicly