Develop and Download Open Source Software

OpenSource Downloads

7-Zip  (4,208)  
HandBrake Japanese Language Version  (3,353)  
CrystalDiskInfo  (1,743)  
CotEditor  (1,120)  
CrystalDiskMark  (866)  
Boookends  (788)  
SMPlayer  (642)  
えこでこツール  (599)  
Tera Term  (595)  
10  FFFTP  (579)  
11  Cabos  (530)  
12  BathyScaphe  (494)  
13  ffdshow  (481)  
14  MergeDoc  (464)  
15  ギコナビ  (438)  
More >>

最近ブックマークされた記事

セキュリティの基本原則:最小権限という概念とその実装

2008年02月01日 12:06 Bruce-Byfield(2008年1月25日(金)) 1 2 3
 最小権限の原則とはコンピュータセキュリティにおける基本概念の1つだが、今日その重要性は通常のシステム管理だけでなく、ソフトウェアの設計段階においてもより大きな意味を有するようになっている。この原則の骨子は、プロセスやシステムおよびソフトウェアコンポーネントに関して与えるアクセス権限は必要最小限のものだけにしておけ、という意味である。そしてセキュリティの専門家であり、EnGardeというセキュリティ強化型GNU/Linuxディストリビューションを開発しているGuardian DigitalのCEOでもあるDave Wreski氏によると、この原則はフリー/オープンソース系セキュリティソリューションと組み合わせることで特に有用に機能するはずだということになる。実際この原則は、ソフトウェア設計者の間で再び注目を浴びつつあるのだ。この原則を正しく理解しておくことは、各自が管理するネットワークのセキュリティ強化に役立つだけでなく、絶えず進化を続けるコンピュータ世界におけるニーズの変化を補足していく上でも有用に寄与するはずなのである。

 そもそも最小権限の原則とは、1975年に「The Protection of Information in Computer Systems」(コンピュータシステムにおける情報保護)と題された論文にて、Jerome SaltzerおよびMichael Schroederの両氏により提唱された概念である。ごく単純に考えた場合、ユーザレベルにおける最小権限の原則の具体例としては、一般的なコンピュータ作業を行うためのユーザアカウントと、システム全体のフルアクセス権を有すrootアカウントという使い分けを考えてもいいだろう。平均的なユーザであればシステムレベルのファイルや設定を変更する必要はないはずなので、そうしたユーザ用のアカウントは最初からこれらの操作を許可しないようにしておくのである。そして管理者にとって最もなじみ深い原則は、特定のタスクを実施する場合のみroot権限でログインするという基本ポリシーだろう。特にUbuntuなど一部のディストリビューションでは、sudoの使用を強制することにより特定のプロセスやプログラムの実行権限はrootのみに制限した上で、実行可能時間も最小化するという措置が施されている。

 最小権限の原則をより高位レベルで実装する場合に推奨されているのが、管理アカウントを複数に分割しておくという方式である。この説明において先のWreski氏が用いているのが、Apache Webサーバのプロセスを(Apache専用の)個別のアカウントで実行させるという設定である。「例えば管理者パスワードを突破したクラッカーがApacheを介した電子メールサーバの盗み読みを試みるとしましょう。そうした場合もこのサーバの運用側が最小権限の原則に従って、Apacheには必要以外の機能を扱えないようにしておくという多層防御態勢をとっていれば、このクラッカーによる攻撃を切り離せるはずです。クラッカーが管理者アカウントで不正アクセスしようとしても、目的とするソフトウェアはその権限では実行できないようにしてあるのですから。こうしてセキュリティ突破の成果は“封じ込め”られ、その被害は最小限に局限化されて終わるという訳です」

 Wreski氏の説明は更に続き、最小権限の原則の重要性は理論上セキュリティの基本原則における最上位に位置するともしている。ただしこれを実際に適用するには、個々のシステムで使用されるタスクおよびその利用者のすべてを把握した上で、どこまで制限すれば充分なセキュリティを確立できるかを見極める入念な計画が必要となる。

 こうした最小権限の原則の有効性を損なう要因は大きく2つに分けることができる。その1つ目をWreski氏は「この原則自体が非常に漠然とした概念という点です」と説明している。「そもそも“最小”とは主観的なものであり、特に企業環境では多種多様な利害関係とニーズがそこに関わってきます。」例えばユーザが使うラップトップとネットワークアカウントとの同期などは、システム管理者の観点からするとセキュリティ上の悪夢でしかないが、一般ユーザの利便性という観点からは、こうした操作は許可せざるを得ないのが実状である。

 2つ目の問題点としてWreski氏が指摘しているのが、「ニーズとは変化するものであり、上手くすればいい方向への進化を促しますが、下手をすると完全に破綻への道をたどることもあります」という点である。つまりシステムのセキュリティとは一度確立してしまえば終わりというものではなく、臨機応変的な各種の変更がその後加えられて行くものであり、セキュリティポリシーはそうした変化によって損なわれないように絶えず保守していく必要があるのである。

 こうした2つの要因を踏まえた上でWreski氏が提唱しているのが、システムレベルでより細かな“セキュリティの粒状化”を施して最小権限の原則が機能しやすくしておくことである。「ネットワークセキュリティはグローバルレベルの包括的な対策だけでは充分とは限りません」と同氏は語り、その代わりに必要となるのが、「個々のプロセスおよびアプリケーション単位でロックを施せる機能です」としている。

 もっともこうした機能は、その実装自体が困難だという側面も有している。Wreski氏の言葉を借りれば、「セキュリティのために生産性を犠牲にはできないという実務の現場において運用可能なレベルに簡単化することが課題です。現実問題として、プロセスやアプリケーションを1つずつ個別にロックをすることなどは不可能でしょう。とは言うものの、外部ネットワークへのチャンネルを有すといった危険度の高いアプリケーションを特定して囲い込んでおくだけでも有効に寄与するはずです」ということになる。これはつまり、外部のシステムと接触するものには目を光らせておけということに他ならない。

 Wreski氏は、「最小権限の原則はすべてのアプリケーションプロセスに逐一適用するというものではないでしょうが、使い方次第でトータルなセキュリティレベルを格段に向上させることができるはずです」としている。

最終更新:2008年04月02日 17:07