パスワードの定期変更という“不自然なルール”：セキュリティ・ダークナイト（6）（3/4 ページ）

[辻 伸弘（ソフトバンク・テクノロジー株式会社），＠IT]

2つのパターンに分けて考える「定期的な変更」

　パスワードの定期的な変更に有効性を持たせるならば、短期的な場合と長期的な場合、2パターンに分けて考えるとよいだろう。

　短期的に変更されるパスワードの例としては、オンラインバンキングなどが挙げられる。こうしたサービスでは、ほんの少ない金額でも預金を操作した場合、ログインの日時や明細などの履歴（中には、操作しただけであらかじめ設定したメールアドレスに通知が届くものもある）から不正に気付く可能性が高い。従って、悪意のあるユーザーは、パスワードをクラックしたら短期間にことをすませようとするだろう。

　ただ、オンラインバンキングでは、一般に思われているほどパスワード単体の実質的な意味は重くはない（もちろん、決してパスワードが無意味なものというわけではない）。だが、最近のオンラインバンキングサービスのほとんどは、ワンタイムトークンやマトリックス表などを組み合わせた多要素認証を採用している。

　別の例として、サーバへの侵入を考えてみよう。もしクラックされ侵入されてしまい、その後数時間もあれば、情報の窃取、rootkitの設置、バックドアアカウントの作成、ボットネットへの参加など、ありとあらゆる被害を受ける可能性が考えられる。決して傷は浅くなく、「食い止められた」などといえるレベルではない。

　つまり、パスワードをクラックされた後、短期間のうちに被害を受ける可能性が高いシステムで被害範囲を最小限に抑えるには、パスワードの定期的な変更よりもむしろ、改ざん検知やIDSといった早期発見のシステムや、アウトバウンドパケットの制限などといった、アクセスコントロールの方が重要だと筆者は考える。

　次に、長期的に被害を受ける恐れがあるケースを見てみよう。社内ネットワークなどで用いられる機密情報の閲覧権限のパスワードが破られた、というような場合である。

　例えば、ある企業では、ファイルサーバに機密情報が保存されている。そしてその情報は、役員以上のアカウントしか閲覧できないよう設定されているとする。もし筆者が、その役員アカウントのクラックに成功し、なりすましを行ったと考えてみてほしい。

　パスワードが変更されるまでの間、機密情報は筆者に筒抜けになるが、変更された後は、情報を盗み出すことはできなくなる。このように、社内情報のように継続的に更新・追加されていく情報に対するなりすまし被害の範囲を抑える役には立つ。効果は限定的ではあるが、定期的な変更はしないよりはする方がよい、といえるだろう。

　ただそれでも、パスワードが変更されるまでの間にクリティカルな情報を閲覧されたり、場合によっては持ち出される可能性は残る。こう考えると、定期的な変更に力を注ぐよりも、堅牢なパスワードを設定してクラックされないようにすることにエネルギーを注ぐ方が合理的だ。

【関連記事】
セキュリティ対策の「ある視点」
第8回 魂、奪われた後――弱いパスワードの罪と罰
http://www.atmarkit.co.jp/fsecurity/rensai/view08/view01.html
セキュリティ対策の「ある視点」
第9回 人の造りしもの――“パスワード”の破られ方と守り方
http://www.atmarkit.co.jp/fsecurity/rensai/view09/view01.html

「定期的な変更」神話が生まれた経緯

　パスワードを定期的に変更すべき根拠と思われる理由を見てきたわけだが、こう検討してみると、意味がないとまではいかないものの、あまり有効性はあるとは考えられない。しかし「パスワードの定期的な変更」は、長年、セキュリティ対策の1つとして伝統的に言われ続けている。これはなぜだろうか。筆者が考えるに、原因は、UNIX系システムの「/etc/passwd」ファイルではないだろうか。

　現在、多くの（注4）UNIX系システムでは、「/etc/shadow」がデフォルトで導入されており、各ユーザーのパスワードハッシュは、一般ユーザーには読めないようパーミッションが設定されている。

　しかし昔のUNIX系システムでは、ほとんどの場合、「/etc/passwd」にパスワードハッシュが格納されており、一般ユーザーでも他のユーザーのパスワードハッシュを読み取ることができていた。「John The Ripper」などのクラックツールを使い、時間をかければ、パスワードがクラックされる危険性は常について回っていた。この危険を避けるために、「パスワードには定期的な変更が必要だ」と言われるようになったのだろう。その言い伝えが、システム側の設定が変わったいまでも語り継がれているのではないだろうか。

　昨今のセキュリティ事情を考慮すると、「パスワードの定期な変更」は、いまやあまり意味をなさなくなってきている。にもかかわらず、守るべき情報資産の質（＝前述の短期的か、長期的か）を考慮せず、おまじないのように定期的なパスワード変更を要求するシステムは少なくない。

　しかし、この無批判な運用がかえって、パスワードの質を低下させる危険性を含んでいるのだ。

【注4】
HP-UXなどではインストール方法によっては、「/etc/shadow」が導入されず、一般ユーザーでも読み取りが可能な「/etc/passwd」に各ユーザーのパスワードハッシュが格納されているものもある。ペネトレーションテストの現場ではSSHやchrootされていないFTPから一般ユーザーで侵入に成功し、「/etc/passwd」に記述されているパスワードハッシュをクラッキングし管理者権限の奪取に成功することも珍しくない。

「定期的な変更をしない」よりも危ないこと

　セキュリティ対策と運用負荷との兼ね合いは切っても切れない関係である。

　パスワードの定期的な変更によって生じる運用負荷について考えてみよう。「パスワードを忘れてしまったので情報システム室に問い合わせる」「リセットして再設定を行う」といった作業がすぐに思いつくのではないか。読者の中にも、パスワードに関する問い合わせで担当者の手を煩わせた（あるいは煩わされた）記憶がある方は少なくないはずだ。

　運用担当者には申し訳ない言い方になるが、負荷が増えるだけならばセキュリティ事故にはならない。しかし、パスワードの定期的な変更によって陥いる穴はもう1つある。そしてそれは、パスワードを定期的に変更せず使い続ける場合よりも大きな脅威を招いてしまうのだ。

　一言で「パスワードを定期的に変更する」といっても、1人のユーザーが使うパスワードは1つではない。

　皆さんもこの機会に、自分が扱うパスワードを数えてみてほしい。きっと、1つや2つではないはずだ。筆者もざっと数えただけでも軽く10は超えてしまっている。システム管理を担当していれば、さらにサーバ、ネットワーク機器などのパスワードまで加わることになる。

　こんな状況で、「これら複数のパスワードをすべて定期的に変更しろ」と言われたらどうするだろうか？

　おそらくセキュリティに関心を持ち、意識の高い方であれば、自分なりの命名規則に基づいて個別のパスワードを設定し、運用していることだろう。しかし、それをすべての人に求めるのは酷な話である。そのような状況を考慮すると、パスワードの定期的な変更を行うことで、どうしても自身が「覚えやすい」パスワード、つまりは「クラックされやすい」パスワードを設定してしまいがちではないだろうか。その上、30日や60日といった期間で定期変更を求められれば、複数のシステムで同一パスワードの使い回しが発生してしまう可能性も高い。

　筆者は、定期的にパスワードを変更しないということよりも、このパスワードの使い回しのほうが非常に危険であると考えている。ここからは、その危険な一例をペネトレーションテストの現場からお届けしたいと思う。