アーキテクチャセキュリティの9つの原則：Magi's View（3/3 ページ）

[Bruce-Byfield，japan.linux.com]

システムの強度は最も弱い部分で決まる

　この原則は、多層防御の必要性をさらに強めるものである。システムに施された防御策が多くなるほど、最も弱い防御策によってシステムが脆弱になる可能性は低くなる。「最も弱い部分」とは、システム自体ではなくユーザーであることが多い。したがって、この原則は、セキュリティ上の基本的な習慣についてユーザーに教育する必要がある、という意味や、ユーザーがそれらの習慣にきちんと従っていることを定期的にチェックする必要がある、という意味にもなり得る。

　セキュリティポリシーをいくらきちんと設計および実装しても、ユーザーが、キーボードの下に自分のパスワードをテープで貼りつけていたり、地下鉄でたまたま質問してきた人に自分のパスワードを教えたりしたら、その努力は台なしである。

馬が逃げた後で馬小屋に鍵をかけても無駄

　事が起きた後でセキュリティ対策を講じても、システムがどれだけ安全かについては確信が持てない。ワームやトロイの木馬はウイルス対策プログラムで削除できるかもしれないが、システムが安全な状態に戻ったかどうかは決して分からないのだ。

　アーキテクチャセキュリティの観点から言うと、攻撃に成功された後でシステムが安全な状態に戻ったことを確信できる方法は一つしかない。すなわち、BIOSを再インストールし、HDDを再フォーマットして、システムが攻撃を受ける前にバックアップしておいたファイルを復元するというのが唯一の方法だ。これらの手順は時間がかかり、システムがオフラインになっている時間が、自分の許容範囲をはるかに超えるほどの長さになる。したがって、システムを復元する必要性がそもそも生じないように、ほかのセキュリティ原則をきちんと適用しておく方がよいだろう。

完全な情報開示を実践する

　システムへの攻撃に成功されたり、脆弱性が明らかになった場合は、できるだけ早くユーザーに知らせること。この原則は、オペレーティングシステムの脆弱性のレベルではよく知られている。そして、その面においては、MicrosoftとFOSSコミュニティーとで、まったく対照的な対応がとられている。Microsoftでは、セキュリティ問題についての情報公開は、パッチをリリースする直前や、攻撃プログラムが登場するまで先延ばしされることが多い。これに対し、FOSSプロジェクトの多くでは、脆弱性についての情報公開（および修正）は、可能な限り早く行われる。

　だが、情報公開というものは、個々のシステムのレベルでも同様に当てはまる。情報公開が行われると、脆弱性のあるシステムのユーザーは、ただちにログオフしさえすれば、その脆弱性が解消されるまでの間、自分なりの予防策を講じることができる。

まとめ

　これらの原則を理解および実践したとしても、システムのセキュリティが絶対破られないとは保証できない。現実には、ユーザーの利便性との間でバランスを取る必要が生じる。そして、ユーザーの利便性を考えると、システムの全体的なセキュリティを低めることになる場合が多々ある。しかし、これらの原則を知らないと、そのバランスの位置を何も考えずに決めてしまう可能性が高くなる。その場合、大多数の人は、利便性を優先する方に傾いてしまうはずだ。

　つまるところ、これらの原則について考えることは、セキュリティの勝算を高めることや、攻撃を受けた場合の復旧の効率を高めることにつながる。そして少なくとも、受動的な対策で十分だという考えから生じる、偽りの安心感はなくなる。

原文へのリンク