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

アーキテクチャセキュリティは、何十冊もの本にわたるほどの大きな話題である。だが、具体的な設定方法を除けば、それは9つの基本的な原則に集約できる。

[Bruce-Byfield，japan.linux.com]

　多くのユーザーにとって、セキュリティアーキテクチャは新しい概念である。ユーザーたちは、ウイルス、ワーム、スパイウェア、そのほかのマルウェアなどのセキュリティ上の脅威については知っている。ウイルス対策プログラムやファイアウォールについても耳にしたことがあり、実際に使用している人も多い。多くの人は、侵入検知システムも使用している。だが、その一方で、アーキテクチャセキュリティというものは、大半のユーザーにとって、依然として得体の知れない存在である。

　実のところ、ウイルス対策ソフトウェア、ファイアウォール、侵入検知といったものは、セキュリティの上っ面にすぎない。これらはすべて、能動的な脅威への対応を目的とした受動的な対策である。脅威を予期してその害をなくすことを目的とした、主体的積極的な対策ではないのだ。これらのアプリケーションは、大きな役割を果たすものではあるが、これら単独では不十分なのである。

　受動的なセキュリティ対策の背後にある、はるかに広い分野をカバーするのがアーキテクチャセキュリティである。この中には、セキュリティが破られないように安全なシステムをセットアップする方法、セキュリティが破られた場合の影響を最小限にとどめる方法、侵入への対処方法とその復旧方法などが含まれる。

　アーキテクチャセキュリティは、何十冊もの本にわたるほどの大きな話題である。だが、具体的な設定方法を除けば、アーキテクチャセキュリティは9つの基本的な原則に集約できる。いずれも、セキュリティアーキテクトたちに広く認められている原則だ。これらは、プログラムを開発するときでも、システムを管理するときでも、デスクトップアプリケーションを使用するときでも当てはまるし、家庭のマシン一台を管理するときでも、大規模なネットワークを管理するときでも当てはまる。これらは、厳格な法規というよりは、セキュリティについてこう考えるべきだという方法である。

　これらの基本原則を身に付けると、ソフトウェアのインストールや設定を行うときに、情報や知識に基づいた、より適切な選択を行うことができ、さらには、自分の使用しているオペレーティングシステムについて、いっそう深く知ることができる。その副産物として、OpenBSDの方がGNU/Linuxより安全だという主張や、これらはどちらもWindowsより安全だという主張が、どういう理屈によるものかが理解できるはずだ。

システムのセキュリティポリシーを確立し、システムの中身を把握する

　アーキテクチャセキュリティの第一歩は、強固なセキュリティポリシーを確立することと、システムに何が入っているかを詳細に把握することである。この最初の原則がないと、セキュリティについての決断を下すときに、体系化されていない形で、またセキュリティを確保する対象を理解せずに行うことになる。この原則に従うと、インストールプログラムのデフォルトのポリシーや選択をそのまま使用しないことや、設定や構成ファイルを掘り下げて、通常のユーザーがCDをマウントできるかどうかなどを詳細に制御できる場所を調べたり、個々のパッケージを選択できる場所を調べたりすることが必要である。

　また、あらかじめ設定済みのグループのデフォルトのパッケージをチェックして、セキュリティポリシーに適合しないプログラムを削除することが必要になる場合もある。例えばDebianの場合、インストールでDesktop Environmentプロファイルを選択した場合、インストールCD上のPackages.gzファイルを参照すると、何がインストールされるかを確認できる。それには時間がかかるかもしれないが、その手間を掛けないことには、安全なシステムにするという目標は出足からつまずくことになる。

アクションは検証可能であることが必要

　検証可能であるとは、アクションが実行されたことをチェックできるということである。これは、プログラミングでは重大な原則である。そして、経験豊富なシステム管理者がコマンドラインツールの方を好む理由はここから分かる。すなわち、シェルコマンドの実行はガラス張りであるため、どんな処理が行われているかをきちんと把握できるのに対し、同様の処理を行うGUIツールでボックスをクリックしたときには、何が行われているかをきちんと把握できないことが多いということだ。例えば、Sonyのコピー防止対策で生じた、最近の問題で考えてみるとよい。Sonyのインストーラは、ある一つのコンポーネントをインストールしているとユーザーに通知していたのに、実際にインストールされたのは、本質的に有害ながら、ユーザーがそのことを把握できない、別のソフトウェアだったのだ。

　この原則を逆から見ると、フリーおよびオープンソースの開発モデルに対する、強力な後ろ盾となる。ソースコードを入手できるので、プログラミング言語が分かるユーザーは、ある処理がコードの特定のブロックの結果によるものだということを確認でき、予期せぬ処理が同時に行われていないことを確かめることができる。もちろん、コードを読めないユーザーは、詳しい人の意見を頼りにしなくてはならないが、肝心なのは、検証の可能性があるという点なのだ。

実用上必要な最小権限のみを常に与える

　最小権限の原則とは、すべてのプロセス、ユーザー、およびプログラムに対し、それが必要とするシステムリソースへのアクセス権のみを与え、それ以上は与えないというものである。例えば、rootとして動作する必要がないプロセスなら、そうできないようにしておくということだ。あるいは、特定のパーティション（/bootなど）への読み書きが必要ないユーザーに対しては、そのパーティションへのアクセス許可を与えないということだ。ユーザーがもっと強力な権限やアクセス許可を必要とするときには、できるだけ短い時間だけその権限を与えるようにする。

　最小権限の原則を理由として、次のようなことも言える。すなわち、理想的には、共通のグループの幾つかにユーザーを自動的に追加するのはやめ、必要最小限のグループにのみ追加するのがよい。また、通常のユーザーがプログラムをrootとして実行できる方法としてsudoコマンドがあるが、同様の理由から、どのユーザーも、どのコマンドに対しても、sudoを使用できないようにしておく必要がある。その上で、特定のユーザーが特定のコマンドのみをsudo で実行できるようにする。

　最小権限の原則が設計思想の基盤となっているのが、Solarisなどのオペレーティングシステムで見られる複数のシステムアカウントである。単一のrootアカウントがシステム全体に対する完全なアクセス権を持っているのではなく、複数のシステムアカウントにroot権限が切り分けられており、それぞれは限られた権限のみを持っているのだ。複数のシステムアカウントに分かれていると、いずれか1つのパスワードをクラッカーに奪われたとしても、システムを完全に制御することは不可能である。