セキュリティ・アーキテクチャの9つの原則
実のところ、ウイルス対策ソフトウェア、ファイアウォール、侵入検知といったものは、セキュリティの上っ面にすぎない。これらはすべて、能動的な脅威への対応を目的とした受動的な対策である。脅威を予期してその害をなくすことを目的とした、主体的・積極的な対策ではないのだ。これらのアプリケーションは、大きな役割を果たすものではあるが、これら単独では不十分なのである。
受動的なセキュリティ対策の背後にある、はるかに広い分野をカバーするのがアーキテクチャ・セキュリティである。この中には、セキュリティが破られないように安全なシステムをセットアップする方法、セキュリティが破られた場合の影響を最小限にとどめる方法、侵入への対処方法とその復旧方法などが含まれる。
アーキテクチャ・セキュリティは、何十冊もの本にわたるほどの大きな話題である。だが、具体的な設定方法を除けば、アーキテクチャ・セキュリティは9つの基本的な原則に集約することができる。いずれも、セキュリティ・アーキテクトたちに広く認められている原則だ。これらは、プログラムを開発するときでも、システムを管理するときでも、デスクトップ・アプリケーションを使用するときでも当てはまるし、家庭のマシン1台を管理するときでも、大規模なネットワークを管理するときでも当てはまる。これらは、厳格な法規というよりは、セキュリティについてこう考えるべきだという方法である。
これらの基本原則を身に付けると、ソフトウェアのインストールや設定を行うときに、情報や知識に基づいた、より適切な選択を行うことでき、さらには、自分の使用しているオペレーティング・システムについて、いっそう深く知ることができる。その副産物として、OpenBSDの方がGNU/Linuxより安全だという主張や、これらはどちらもWindowsより安全だという主張が、どういう理屈によるものかが理解できるはずだ。
システムのセキュリティ・ポリシーを確立し、システムの中身を把握する
アーキテクチャ・セキュリティの第1歩は、強固なセキュリティ・ポリシーを確立することと、システムに何が入っているかを詳細に把握することである。この最初の原則がないと、セキュリティについての決断を下すときに、体系化されていない形で、またセキュリティを確保する対象を理解せずに行うことになる。この原則に従うと、インストール・プログラムのデフォルトのポリシーや選択をそのまま使用しないことや、設定や構成ファイルを掘り下げて、通常のユーザがCDをマウントできるかどうかなどを詳細に制御できる場所を調べたり、個々のパッケージを選択できる場所を調べたりすることが必要である。
また、あらかじめ設定済みのグループのデフォルトのパッケージをチェックして、セキュリティ・ポリシーに適合しないプログラムを削除することが必要になる場合もある。たとえばDebianの場合、インストールでDesktop Environmentプロファイルを選択した場合、インストールCD上のPackages.gzファイルを参照すると、何がインストールされるかを確認できる。それには時間がかかるかもしれないが、その手間をかけないことには、安全なシステムにするという目標は出足からつまずくことになる。
アクションは検証可能であることが必要
検証可能であるとは、アクションが実行されたことをチェックできるということである。これは、プログラミングでは重大な原則である。そして、経験豊富なシステム管理者がコマンドライン・ツールの方を好む理由はここからわかる。すなわち、シェル・コマンドの実行はガラス張りであるため、どんな処理が行われているかをきちんと把握できるのに対し、同様の処理を行うGUIツールでボックスをクリックしたときには、何が行われているかをきちんと把握できないことが多いということだ。たとえば、Sonyのコピー防止対策で生じた、最近の問題で考えてみるとよい。Sonyのインストーラは、ある1つのコンポーネントをインストールしているとユーザに通知していたのに、実際にインストールされたのは、本質的に有害ながら、ユーザがそのことを把握できない、別のソフトウェアだったのだ。
この原則を逆から見ると、フリーおよびオープンソースの開発モデルに対する、強力な後ろ盾となる。ソースコードを入手できるので、プログラミング言語がわかるユーザは、ある処理がコードの特定のブロックの結果によるものだということを確認でき、予期せぬ処理が同時に行われていないということを確かめることができる。もちろん、コードを読めないユーザは、詳しい人の意見を頼りにしなくてはならないが、肝心なのは、検証の可能性があるという点なのだ。
実用上必要な最小権限のみを常に与える
最小権限の原則とは、すべてのプロセス、ユーザ、およびプログラムに対し、それが必要とするシステム・リソースへのアクセス権のみを与え、それ以上は与えないというものである。たとえば、rootとして動作する必要がないプロセスなら、そうできないようにしておくということだ。あるいは、特定のパーティション（/bootなど）への読み書きが必要ないユーザに対しては、そのパーティションへのアクセス許可を与えないということだ。ユーザがもっと強力な権限やアクセス許可を必要とするときには、できるだけ短い時間だけその権限を与えるようにする。
最小権限の原則を理由として、次のようなことも言える。すなわち、理想的には、共通のグループのいくつかにユーザを自動的に追加するのはやめ、必要最小限のグループにのみ追加するのがよい。また、通常のユーザがプログラムをrootとして実行できる方法としてsudoコマンドがあるが、同様の理由から、どのユーザも、どのコマンドに対しても、sudoを使用できないようにしておく必要がある。そのうえで、特定のユーザが特定のコマンドのみをsudoで実行できるようにする。
最小権限の原則が設計思想の基盤となっているのが、Solarisなどのオペレーティング・システムで見られる複数のシステム・アカウントである。単一のrootアカウントがシステム全体に対する完全なアクセス権を持っているのではなく、複数のシステム・アカウントにroot権限が切り分けられており、それぞれは限られた権限のみを持っているのだ。複数のシステム・アカウントに分かれていると、いずれか1つのパスワードをクラッカーに奪われたとしても、システムを完全に制御することは不可能である。
多層防御を実践する
一般的なユーザは、うちのシステムはファイアウォールに守られているから安全だ、と考えることが多い。そして多くの場合、それは正しい。問題は、システムに対する唯一のセキュリティ対策がファイアウォールの場合、そのファイアウォールが破られたら、システム全体が危険にさらされてしまうということだ。多層防御の原則とは、さまざまなレベルのあちこちで多種多様なセキュリティ機能が動作しているソリューションの方が安全だというものだ。
ファイアウォールにのみ頼っているシステムよりも、アクセス許可、認証、ホワイトリスト、ブラックリストなどのセキュリティ機能をフル活用するように設定されているシステムの方が、安全性を維持できる可能性が高くなる。また、この原則に従うと、パスワードにのみ頼る方法は今一つということになるが、その場合でも、デスクトップ・レベルの単一のパスワードにのみ頼るよりも、BIOSやブート・マネージャにもパスワードを設定する方が、セキュリティは強固になる。
加えて、セキュリティの専門家たちは、物理的なセキュリティ対策を活用することで、システムのセキュリティをさらに強固にする。たとえば、サーバ室には、権限のある者以外は入れないようにする必要がある。デスクトップ・システムは、簡単に持ち去れないよう、物理的に保護する必要がある。バックアップは、セキュリティで保護された場所（できれば別の場所）に格納しておく必要がある。
システムの監査：システム・ログの記録と確認
システムの安全を維持するためには、システムに加えられた変更を記録する必要がある。それには、システム独自のユーティリティを使用するか、またはSnortやTripwireなどの侵入検知システムを使用する。一部の変更の記録は手で残すことも可能だが、Unix系のシステムでは、変更やエラーのログは、システム・アプリケーションによって/var/logに保存されるのが慣習だ。このしくみは理想的なものではない。経験豊富なクラッカーにとっては、ログに修正を加えて侵入を隠ぺいするというのは第1歩だからだ。
とは言え、多くの攻撃は、システムについてほとんど理解していないスクリプト・キディによるものであるため、ログに変更が加わっているということが、システムのセキュリティが破られたことを示す最初の兆候となる場合が多い。Tripwireなど、一部の侵入検知プログラムでは、ログなどの主要なファイルのチェックを自動化できる。
侵入を封じ込めるように構築する
封じ込めとは、システムがクラッキングされた場合の影響をできるだけ小さくすることを目的としたものである。この原則を念頭に置いて構築されたシステムは、隔壁を備えている船舶のようなものだ。船体が破損しても、隔壁によってその破損は直ちにカバーされる。それと同じで、封じ込めを念頭に置いて構築されたシステムの場合、クラッカーが侵入に成功した場合でも、そのクラッカーに自由にアクセスさせないようになっている。
毎日の作業で使用する通常のユーザ・アカウントがrootとは別になっている主要な理由の1つは、この原則にある。多くの場合、非特権アカウントをクラッカーが奪ったとしても、システムの設定ファイルやユーティリティにはアクセスできない。当該ユーザのファイルがなくなったりする可能性はあるが、利用可能なグループすべてに対して非特権アカウントを追加するなどの手順によってセキュリティが緩くなっている場合を除き、システム全体に対する影響は限られている。あるいは、もっと高度なレベルで言うと、chroot jailを使用して、未テストのプログラムや危険なプログラムは隔離して動作させるということの基になっている原則の1つが、この封じ込めである。
これとは対照的に、CやC++などの言語の設計方法が原因で生じるバッファ・オーバーフローは、この原則が当てはまらない例である。アプリケーションがrootとして実行されている場合に、バッファ・オーバーフローを利用した攻撃が行われると、root権限が奪われることになる。こうした理由があるからこそ、堅実なプログラマにとっては、このような脆弱性を修正することが優先事項の1つであり、また、パッチをこまめに適用することが重要なのである。
システムの強度は最も弱い部分で決まる
この原則は、多層防御の必要性をさらに強めるものである。システムに施された防御策が多くなるほど、最も弱い防御策によってシステムが脆弱になる可能性は低くなる。「最も弱い部分」とは、システム自体ではなくユーザであることが多い。したがって、この原則は、セキュリティ上の基本的な習慣についてユーザに教育する必要がある、という意味や、ユーザがそれらの習慣にきちんと従っていることを定期的にチェックする必要がある、という意味にもなり得る。
セキュリティ・ポリシーをいくらきちんと設計および実装しても、ユーザが、キーボードの下に自分のパスワードをテープで貼り付けていたり、地下鉄でたまたま質問してきた人に自分のパスワードを教えたりしたら、その努力は台無しである。
馬が逃げた後で馬小屋に鍵をかけても無駄
事が起きた後でセキュリティ対策を講じても、システムがどれだけ安全かについては確信が持てない。ワームやトロイの木馬はウイルス対策プログラムで削除できるかもしれないが、システムが安全な状態に戻ったかどうかは決してわからないのだ。
アーキテクチャ・セキュリティの観点から言うと、攻撃に成功された後でシステムが安全な状態に戻ったことを確信できる方法は1つしかない。すなわち、BIOSを再インストールし、ハード・ドライブを再フォーマットして、システムが攻撃を受ける前にバックアップしておいたファイルを復元するというのが唯一の方法だ。これらの手順は時間がかかり、システムがオフラインになっている時間が、自分の許容範囲をはるかに超えるほどの長さになる。したがって、システムを復元する必要性がそもそも生じないように、他のセキュリティ原則をきちんと適用しておく方がよいだろう。
完全な情報開示を実践する
システムへの攻撃に成功されたり、脆弱性が明らかになった場合は、できるだけ早くユーザに知らせること。この原則は、オペレーティング・システムの脆弱性のレベルではよく知られている。そして、その面においては、MicrosoftとFOSSコミュニティとで、まったく対照的な対応がとられている。Microsoftでは、セキュリティ問題についての情報公開は、パッチをリリースする直前や、攻撃プログラムが登場するまで先延ばしされることが多い。これに対し、FOSSプロジェクトの多くでは、脆弱性についての情報公開（および修正）は、可能な限り早く行われる。
だが、情報公開というものは、個々のシステムのレベルでも同様に当てはまる。情報公開が行われると、脆弱性のあるシステムのユーザは、直ちにログオフしさえすれば、その脆弱性が解消されるまでの間、自分なりの予防策を講じることができる。
まとめ
これらの原則を理解および実践したとしても、システムのセキュリティが絶対破られないとは保証できない。現実には、ユーザの利便性との間でバランスをとる必要が生じる。そして、ユーザの利便性を考えると、システムの全体的なセキュリティを低めることになる場合が多々ある。しかし、これらの原則を知らないと、そのバランスの位置を何も考えずに決めてしまう可能性が高くなる。その場合、大多数の人は、利便性を優先する方に傾いてしまうはずだ。
つまるところ、これらの原則について考えることは、セキュリティの勝算を高めることや、攻撃を受けた場合の復旧の効率を高めることにつながる。そして少なくとも、受動的な対策で十分だという考えから生じる、偽りの安心感はなくなる。
原文
