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

[Bruce-Byfield，japan.linux.com]

多層防御を実践する

　一般的なユーザーは、うちのシステムはファイアウォールに守られているから安全だ、と考えることが多い。そして多くの場合、それは正しい。問題は、システムに対する唯一のセキュリティ対策がファイアウォールの場合、そのファイアウォールが破られたら、システム全体が危険にさらされてしまうということだ。多層防御の原則とは、さまざまなレベルのあちこちで多種多様なセキュリティ機能が動作しているソリューションの方が安全だというものだ。

　ファイアウォールにのみ頼っているシステムよりも、アクセス許可、認証、ホワイトリスト、ブラックリストなどのセキュリティ機能をフル活用するように設定されているシステムの方が、安全性を維持できる可能性が高くなる。また、この原則に従うと、パスワードにのみ頼る方法はいまひとつということになるが、その場合でも、デスクトップレベルの単一のパスワードにのみ頼るよりも、BIOSやブートマネージャにもパスワードを設定する方が、セキュリティは強固になる。

　加えて、セキュリティの専門家たちは、物理的なセキュリティ対策を活用することで、システムのセキュリティをさらに強固にする。例えば、サーバ室には、権限のある者以外は入れないようにする必要がある。デスクトップシステムは、簡単に持ち去れないよう、物理的に保護する必要がある。バックアップは、セキュリティで保護された場所（できれば別の場所）に格納しておく必要がある。

システムの監査：システムログの記録と確認

　システムの安全を維持するには、システムに加えられた変更を記録する必要がある。それには、システム独自のユーティリティを使用するか、またはSnortやTripwireなどの侵入検知システムを使用する。一部の変更の記録は手で残すことも可能だが、Unix系のシステムでは、変更やエラーのログは、システムアプリケーションによって/var/logに保存されるのが慣習だ。この仕組みは理想的なものではない。経験豊富なクラッカーにとっては、ログに修正を加えて侵入を隠ぺいするというのは第一歩だからだ。

　とはいえ、多くの攻撃は、システムについてほとんど理解していないスクリプトキディによるものであるため、ログに変更が加わっているということが、システムのセキュリティが破られたことを示す最初の兆候となる場合が多い。Tripwireなど、一部の侵入検知プログラムでは、ログなどの主要なファイルのチェックを自動化できる。

侵入を封じ込めるように構築する

　封じ込めとは、システムがクラッキングされた場合の影響をできるだけ小さくすることを目的としたものである。この原則を念頭に置いて構築されたシステムは、隔壁を備えている船舶のようなものだ。船体が破損しても、隔壁によってその破損はただちにカバーされる。それと同じで、封じ込めを念頭に置いて構築されたシステムの場合、クラッカーが侵入に成功した場合でも、そのクラッカーに自由にアクセスさせないようになっている。

　毎日の作業で使用する通常のユーザーアカウントがrootとは別になっている主要な理由の一つは、この原則にある。多くの場合、非特権アカウントをクラッカーが奪ったとしても、システムの設定ファイルやユーティリティにはアクセスできない。当該ユーザーのファイルがなくなったりする可能性はあるが、利用可能なグループすべてに対して非特権アカウントを追加するなどの手順によってセキュリティが緩くなっている場合を除き、システム全体に対する影響は限られている。あるいは、もっと高度なレベルで言うと、chroot jailを使用して、未テストのプログラムや危険なプログラムは隔離して動作させるということの基になっている原則の一つが、この封じ込めである。

　これとは対照的に、CやC++などの言語の設計方法が原因で生じるバッファオーバーフローは、この原則が当てはまらない例である。アプリケーションがrootとして実行されている場合に、バッファオーバーフローを利用した攻撃が行われると、 root権限が奪われることになる。こうした理由があるからこそ、堅実なプログラマーにとっては、このような脆弱性を修正することが優先事項の1つであり、また、パッチをこまめに適用することが重要なのである。