筆者は、サービスやソフトウェアだけではなく、世の中に供給されているものの多くに、利用者が維持し、成長させていく側面があると思っている。
身近なものでいうと、スマートフォンで利用できるアプリもそうだろう。いいと思うアプリならば、ユーザーは寄付をしたり有料版を購入したりする。逆に、使いにくい点やバグなどがあれば、レビューに文句を書いたり低い評価を付けるだけではなく、「どう改善してほしいのか」という要望や、バグの現象の説明を建設的に書くべきだ、ということである。
では、アプリではなく、何らかのサービスを利用する立場には何が求められるだろうか。今までもたびたび記事に書いてきたとおり、「単純なパスワードをやめる」「パスワードの使い回しをやめる」ことに取り組んでいただきたい、それに尽きる。加えて、「セキュリティを実現する上で自分たちも一部であり、重要な役割を担っている」という意識も持っていただきたいと、筆者は強く願っている。
一方、サービスを提供する側には、可能な限りセキュリティレベルの向上に努めることが求められるだろう。
可能であれば、多要素、多段階認証やリスクベース認証などを導入するのが望ましい。しかし先にも述べたとおり、時間やコストといったリソース面の兼ね合いで導入できないという場面もあるだろう。
しかし、それ以外にも行えることはあると筆者は考えている。具体的には、
などである。
これらすべてを実現するとなるとハードルが高いかもしれないが、どれか1つからでもいい。サービスの利用者が、セキュリティレベルを向上できる余地を1つでも多く与えられるよう、検討していただきたいと筆者は願っている。事実、被害に遭った組織の中には、この中の文字長と文字種については限定的な設定のままで、褒められた状態ではないものがあった。
もう1つ、サービス提供側にお願いしたいことがある。リスト型攻撃が盛んに行われ、多くの組織が被害に遭っている。そんな中、公表されるリリース文に「他社サイトから流出したと思われるユーザーID・パスワードを利用し、第三者がなりすまし……」といった文面をよく見かけるようになった。
しかし、本当にリスト型攻撃に遭ったのか、その根拠が示されているものは少ないように感じている。
いままで書いてきたように、リスト型攻撃から身を守るためには、サービス提供側だけではなく、サービス利用者にも担うべき部分がある。そのため、もしも被害に遭ってしまった場合、リスト型攻撃を受けたと判断し、発表することで、提供側がある種の「免罪符」的に責任を過小評価する風潮(実際に過小評価かどうかは別として)が生まれかねないと筆者は危惧している。
考えたくもないかもしれないが、もしも被害に遭ってしまった場合は、可能な限り情報を開示した上で結論を述べるというリリースを出すことが、次の被害を最小限にとどめる手だてになるのではないだろうか。
ここまで説明してきたとおり、リスト型攻撃による被害を防ぐためには、サービス提供側と利用者それぞれに担うべき部分がある。これは、車の製造メーカーとドライバーの関係と同じではないだろうか。
車の製造メーカーは、衝突安全ボディやエアバック、車線逸脱防止機構など、さまざまな安全機能の搭載に努めている。しかし、ドライバーが飲酒運転などの危険運転をしてしまえばそれらは水の泡となる。
逆に、ドライバーがどんなに交通ルールを守り、安全な運転を心がけていたとしても、メーカーが製造した車に安全機能が備わっていなかったり、欠陥があった場合には、ドライバーの努力は水の泡となる。
「パスワードのみでの認証については限界である、だから一段上の認証を導入すべし」という言葉をよく聞く。しかしこれから数カ月、いや数年のうちに、多要素、多段階やリスクベース認証、バイオメトリクスなどといった、システムをよりセキュアにするためのソリューションがすべてのシステムに導入され、すべての人が利用できるようになる、と考えるのは現実的ではない。
しかも、パスワード限界説は、パスワードが正しく運用されていないことを前提としている。言い換えれば、正しく運用できれば、セキュリティレベルを向上させる余地がまだまだあるということである。いつ実現できるか分からない対策が広まるのを待つよりも、いま直面している問題に目を向け、いまできることから対策を始めるべきではないか。
使い古された言葉ではあるが、セキュリティは鎖である。どこか1つ弱いところがあれば、そのほかの部分はその弱い部分に引きずられて弱くなる。セキュリティは与え続けられるだけのものでも、与え続けるものでもない。そして、一部の限られた人たちのものでもない。
特にパスワードは、非常に多くの人に関係するセキュリティだ。セキュリティはみんなのものであり、みんなで考え、作っていかなければならないものだと筆者は強く感じている。
注4:ログイン試行が行われてロックされた際に、正規のユーザーもサービスを利用できなくなるため時間によるロック解除を行うなどの工夫が必要である。また、アカウントロックは何度もログイン試行を行う攻撃に対して有効である。しかし、使い回しを狙うリスト型攻撃は、特性上、試行回数が少なくとも不正ログインに成功するため、有効性がほとんどないことは忘れてはならない。
Copyright © ITmedia, Inc. All Rights Reserved.