セキュリティ機能のためのエラー メッセージの作成方法

Everett McKay
Microsoft Corporation

May 17, 2002

要約: セキュリティ関連のメッセージの作成、表示、およびテストに関する基本的な情報を提供します。

目次

典型的なセキュリティ メッセージ 情報の開示 インフォームド コンセント 段階的な開示 具体性を持たせる あえて質問をしない セキュリティ メッセージのユーザビリティ テスト 関連情報

優れたエラー メッセージは、何らかの問題が起こったことを通知し、その問題が起こった理由を説明し、ユーザーがその問題を修正するための対処法を提示します。優れたエラー メッセージ テキストは、具体性、ユーザー指向性、明確さ、一貫性、丁寧さといった特徴を持っています。優れたエラー メッセージの作成は面倒な作業ですが、正しく行わなくてはならない作業でもあります。

セキュリティ機能に関するエラー メッセージを見たことのある人ならばわかるでしょうが、このようなエラー メッセージはわかりにくく、セキュリティ上の問題を理解するのに役立たず、適切な対処方法がわからないことがあります。したがって、「セキュリティ関連のエラー メッセージの質が低いことが多いのはなぜか」という疑問をまず立てるべきでしょう。

ここでの「エラー メッセージ」という言葉には、警告、確認、質問、およびステータスを含むあらゆる種類のメッセージ ボックスが含まれています。この記事では、セキュリティ関連の機能についてのメッセージを作成する方法を検討します。優れたセキュリティ メッセージ テキストを設計することの難しさと、優れたセキュリティ メッセージに必要な情報について説明し、セキュリティ関連のメッセージの設計と提示に関するいくつかのヒントを示します。

典型的なセキュリティ メッセージ

まず、悪いセキュリティ確認メッセージの典型的な例を示します。

図 1. 悪いエラー メッセージの例

このメッセージは通知であり、説明に類するような情報をいっさい含んでいません。ユーザーは [Yes] をクリックしてページを見ることもできますし、[No] をクリックしてこの意味不明なセキュリティ リスクを回避することもできます。

このメッセージのどこが悪いのでしょうか? このメッセージは、ユーザーにとってインテリジェントな判断によって答えることができない質問を行っています。ユーザーは Microsoft® Internet Explorer に対してページを表示するように要求したのですが、このメッセージはその言葉遣いと、[No] を既定の選択項目とすることで、ユーザーに対してそのページを表示しないよう暗黙のうちに助言しています。このページに含まれている具体的なセキュリティ リスクについての十分な説明がないため、操作を続行した場合の問題点は不明確です。簡単に述べれば、このメッセージが悪いのは、ユーザーが適切な決定を下すための十分な情報を提供していないからです。そのため、このメッセージは有用性を失っています。

情報の開示

一般論として、エラー メッセージは可能な限り具体的で役立つものにしなくてはなりません。セキュリティ機能に関しては、具体的で役立つ情報は、「情報の開示」という別の言い方がされることがあります。情報の開示は、プライベートな情報が、本来は見ることができないはずのユーザーに対して表示されるときに起こります。これはセキュアなソフトウェアを設計するときに回避しなくてはならない重要な 6 つのセキュリティ上の脅威のうちの 1 つです。

エラー メッセージを慎重に検討すると、驚くべきことに、その中には役立ちすぎるものがあることがわかります。基本的な例を通して考えてみましょう。

コンピュータにログオンするときに、ユーザーが間違ったパスワードを入力したとします。Windows は、そのパスワードのどこが間違っているのかを正確に知っていますが、この具体的な情報を表示すると、パスワードに関する情報が開示されてしまうことになります。パスワードは秘匿性が守られるという前提に立ってのみ安全なので、いかなる形でも漏洩または記述されてはなりません。このため、Windows はパスワードの間違いに関する具体的な情報を示すのではなく、次のようなメッセージを表示します。

図 2. 優れたエラー メッセージの例

このメッセージは、機密性のあるデータを扱うときも含めて、有用なエラー メッセージを与える方法の良いモデルとなっています。このメッセージには次の情報があります。

• 問題が発生したことの通知 (間違ったパスワード)。
• 問題が発生した理由についての説明 (パスワードが間違って入力された)。
• ユーザーが問題を解決するために実行できる対処法 (大文字小文字の区別に特に注意してパスワードを再入力する)。

優れたセキュリティ メッセージは、プライベートな情報を明らかにしないという前提で、これ以外の有用な情報を提供することができます。Microsoft® Windows® とメッセージを表示したアプリケーションについて、またはユーザーが頻繁に犯している間違いについての一般的な情報を開示することには問題はありません。この例のメッセージは、Caps Lock キーのように、パスワードの入力で大文字小文字の区別を間違える原因となりがちなケースを紹介しています。

また、ドキュメントや簡単な実験などの他の手段で簡単に入手できる情報を提供することにも問題はありません。タスクの実行に必要なアクセス許可や権限など、ドキュメントに記されている事実は安全に提供することができます。ユーザーが特定のタスクを実行するための権限を持っていない場合には、そのタスクを実行することができないという事実からこの情報を引き出すことができるので、権限がないという事実をエラー メッセージで説明してもセキュリティは低下しません。

必要ならば、セキュリティ メッセージは 「Need to know の原則 」（訳注: 必要性のある人のみに情報を伝えるという原則）に厳密に従ってプライベートな情報を開示することができます。以前の Microsoft® Internet Information Services (IIS) は、構文エラーを表示する際に、問題の性質と、違反を起こしているソース コードの抜粋を示すエラー ページをすべてのユーザーに対して表示していました。このようなエラー メッセージはむしろハッカー フレンドリーと呼ぶべきです。このような具体的な情報は、知る必要のあるユーザー (この例ではアプリケーション開発者) のみに提供し、他のユーザーに対しては一般的なエラー メッセージを表示するようにするべきです。現在の IIS はこのアプローチを使用しています。

インフォームド コンセント

悪いセキュリティ メッセージは、情報の開示を行わないメッセージだけではありません。次の例を見てください。

図 3. 情報の多すぎるエラー メッセージ

デフォルトの [No] の選択項目を除けば、このメッセージはユーザーが何を行うべきかという点に関して、何の手がかりも与えていません。実際、ユーザーに何が求められているのかも判然とはしません。最初の例と同様に、このメッセージは、ユーザーにとってインテリジェントな判断によって答えることのできない質問を行っています。データは大量にありますが、その意味は不明確です。このメッセージに含まれているどの情報をもとに、ユーザーは [Yes] または [No] を選べばいいのでしょうか?

ユーザーに対してセキュリティ関連の質問を行うメッセージは、少なくとも、状況を理解した上で決定を下せるだけの十分な情報を提供するべきです。この原則は、一般にインフォームド コンセントと呼ばれます。セキュリティ関連の問題について適切な選択を下すためには、ユーザーは以下の質問に答えられるだけの十分な情報を必要とします。

• このメッセージは何を行うように求めているのか。 実行しようとしているタスクとどのような関係があるのか。
• このセキュリティ上の問題は重大なものなのか、些細なものなのか。
• 安全な方の選択肢を選んだ場合には、どのような操作ができなくなるのか。
• 安全でない方の選択肢を選んだとき、最悪のケースでは何が起こるのか。 何が起こる可能性が高いのか。
• 間違った選択を行った場合、後から問題を修正することはできるか もしそうならば、その方法は。
• プログラムはどちらの項目を推奨しているのか。 その理由は。

インフォームド コンセントなしにセキュリティ上の質問を行っても、その答えには価値はありません。ほとんどのユーザーは、セキュリティに関してほとんど何の知識も持っていません。これは、大企業に所属している人を除けば、ほとんどすべてのシステム管理者にも当てはまることです。セキュリティ メッセージの作成にあたっては、セキュリティ専門家をターゲットにしたプログラムでない限り、ユーザーがセキュリティの専門家であると仮定してはなりません。

次に、ユーザーがほとんどの質問に答えられるように改善された Root Certificate Store メッセージのバージョンを示します。

図 4. 結果を説明するエラー メッセージの改善バージョン

これはたしかに大きなメッセージ ボックスですが、質問の内容、アクションのセキュリティ上の結果、および選択の結果として生じる事柄を明確に説明しています。ここから情報を削ることの利点は何もありません。

段階的な開示

インフォームド コンセントの問題は、ユーザーに対して大量の情報を提示しなくてはならないことが多いという点にあります。現実には、情報の量が過剰になることが少なくありません。最後の例は、必要最低限の情報を表示していましたが、依然として重要な情報が欠けています。具体的には、証明書の検証を行う方法が記されておらず、元のメッセージに含まれていた細かい情報もすべて削除されています。

ユーザーを情報量で圧倒せずに、すべての情報を提示するための最適な方法は、段階的な開示です。ベース メッセージは、ユーザーがエラー メッセージの質問に対してインテリジェントに答えるために必要な重要な情報を表示します。それ以外の、ユーザーが必要とするかもしれない補助的な情報は、ハイパーリンクや、[詳細]、[関連情報]、[ヘルプ] などのボタンを通して、オンデマンドで入手できるようにします。

次に、証明書の検証を行おうとするユーザーを、段階的な開示の手法を使ってガイドするバージョンを示します。

図 5. 段階的な開示を使用するエラー メッセージ

具体性を持たせる

ほとんどのメッセージは、より具体的にすることで改善することができます。もちろん、このことはセキュリティ メッセージにも当てはまります。悪いセキュリティ関連のメッセージの最初の例をもう一度見てみましょう。

図 6. 悪いエラー メッセージの例

前に述べたように、このメッセージが悪いのは、問題のセキュリティ リスクに関して曖昧なことしか述べていないからです。これに具体性を持たせて、メッセージを改善してみます。

図 7. 具体的な情報を含んだエラー メッセージ

このバージョンは、このページで生じる可能性の高いセキュリティ リスクの具体的な例、リスクに関する詳しい情報を得るためのハイパーリンク、そして質問に答えるための具体的な助言を含んでいます。

たしかにテキストの量は増えています。また、この内容を読まないユーザーも間違いなくいるでしょう。しかし、テキストの量は過剰ではなく、ユーザーが質問に答えるのに必要な重要な情報は、目立つように太字で示されています。質問で扱っている概念がわからないユーザーは、ハイパーリンクを利用することができます。重要なのは、ユーザーがセキュリティ リスクの内容を明確に理解でき (機密情報の開示)、インテリジェントな決定を下すための単純な基準を知ることができるということです。これで、この質問の意味がようやくはっきりすることになります。

セキュリティ メッセージは、必ずしも 3 つの単純な文で表現することはできません。簡潔であることは重要な目標ですが、セキュリティ メッセージの場合は、第 1 の目標ではありません。

覚えておくべき原則は、セキュリティの問題はすでにユーザーを混乱させており、ユーザーが目にするセキュリティ メッセージの大部分は、「セキュリティ上の問題を検出しました。機能を制限した上で安全に操作を続けますか。 またはここで操作を終了しますか。」という質問のバリエーションであるということです。ユーザーは、操作を中断するまともな理由がない限り、操作を最後まで実行したいと望むものです。曖昧な表現はモティべーションを低下させ、そもそもセキュリティ上の質問を行う意義を損ないます。プライベートな情報を漏洩することなく、可能な限り具体性を持たせてください。

あえて質問をしない

Bruce Schneier は、著書 『Secrets and Lies』 において、ユーザーがセキュリティ上の質問にインテリジェントに答えることを期待するのは無理であると論じています。以下に、その論拠をいくつか示します。

• 人間は、一般にセキュリティ チェーンの中の最も弱い輪である。
• 人間は、特にありそうもない出来事については、リスクを理解することができない。
• ユーザーは、セキュリティ メッセージをわずらわしく感じ、必要に応じてそれを喜んで回避しようとする。
• ユーザーは、一般にセキュリティに関する警告を目を通すことなく消してしまうので、セキュリティ上の警告は役に立たない。
• 人間は、とにかく自分の仕事を終わらせることしか考えていない。
• ユーザーは、セキュリティ上の適切な決定をすることができない。ILOVEYOU と Anna Kournikova ワームの成功は、その明らかな証拠である。

これは、セキュリティ関連の質問をそもそも行わないことの強力な論拠となっています。しかし、代案にはどのようなものがあるのでしょうか。 1 つの明白なアプローチは、質問を行わないということです。これは、ユーザーが行うべき正しい処理がはっきりとわかっている場合には望ましいアプローチです。

たとえば、ユーザーが Internet Explorer の [インターネット オプション] ダイアログ ボックスの [コンテンツ] タブを使って証明書を削除したときに、これに関連するプライベート キーを削除するかどうかを尋ねる確認メッセージを表示することもできました。しかし、Microsoft の Windows セキュリティ チームは、プライベート キーの削除はつねに正しい処理だと考えたので、あえて尋ねるのをやめました。そのおかげで、悪いセキュリティ メッセージが 1 つ減ったことになります。

もう 1 つのアプローチは、低レベルのセキュリティ関連の質問を個別に行う代わりに、高レベルのセキュリティ ポリシーを使用するというものです。このアプローチは、Internet Explorer の [インターネット オプション] ダイアログ ボックスの [セキュリティ] タブで使用されています。

図 8. 高レベルのセキュリティ ポリシーを使用しているメッセージ

このアプローチがうまく行くのは、ユーザーはセキュリティの細部よりも、自分の目的 (安全なブラウジングと正常な機能など) をはるかに良く理解しているからです。ユーザーの目的に焦点を当てることは、すべてのセキュリティ メッセージに適用されるべき重要な原則です。さらに、高レベルのセキュリティ ポリシーを用意しておけば、ユーザーとの対話の量が減るので、ユーザーが不適切な決定を下したり、セキュリティ対策をバイパスしようと試みたりする場面が減ることになります。この目的中心のアプローチは、他のアプリケーションでも実装することができます。

セキュリティ メッセージのユーザービリティ テスト

開発チーム内でセキュリティ メッセージが必要であるという決定が下されたときには、開発サイクルの早い段階で、ターゲット ユーザーを対象にユーザビリティ テストを行うようにしてください。ユーザーのセキュリティのとらえ方は予測しがたいことが多いので、このステップはきわめて重要です。以下にチェックすべき項目をいくつか示します。

• ユーザーはメッセージのコンテキストを理解したか。
• ユーザーはメッセージ テキストを理解したか。
• ユーザーはセキュリティ リスクを理解したか。
• ユーザーはインテリジェントに対応するために必要なすべての情報を入手できたか。 情報は役に立ったか、それともわかりにくかったか。
• ユーザーは補助情報をチェックしたか。
• ユーザーはどのような決定を下したか。 その理由は。
• ユーザーは自分が正しい選択を行ったという自信を持てたか。
• ユーザーは自分の決定の結果を理解したか。
• ユーザーの決定は、その状況に照らして正しかったか。

セキュリティ メッセージを設計するときには、ユーザーがインテリジェントに対応できるだけの十分な情報を提供し、それと同時にメッセージの中で機密情報を明らかにしないよう注意します。ユーザーが情報に圧倒されないように、段階的な開示を使用します。メッセージを完全に削除できるような代替設計を検討します。最後に、セキュリティ メッセージのユーザービリティ テストを行って、適切なメッセージを提供できているかどうかを確認します。

関連情報

『Secrets and Lies: Digital Security in a Networked World』 （邦訳: 暗号の秘密とウソ）。情報セキュリティの専門家 Bruce Schneier が、この業界で仕事をしているすべての人が知っておくべき事柄を解説しています。

『Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0』。このペーパーでは、Alma Whitten と J.D. Tygar が、セキュリティの UI デザインと標準の UI デザインにどのように違いがあるかを検討しています。

執筆者について

Everett McKay は、2000 年 4 月に Microsoft に入社し、現在は Windows Server 2003 管理ツール チームのユーザー インターフェイス プログラム マネージャとして働いています。Everett は MIT で電子工学とコンピュータ科学の学士号と修士号を取得しており、『Developing User Interfaces for Microsoft Windows』 (Microsoft Press) と『Debugging Windows Programs』 (Addison Wesley) の 2 冊の本を執筆しています。