最小権限の原則

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動: 案内検索

最小権限の原則とは、情報セキュリティ計算機科学などの分野において、コンピューティング環境の特定の抽象化レイヤー内で全てのモジュール(主題によっては、プロセス、ユーザー、プログラム)がその正当な目的に必要とされる情報計算資源のみにアクセスできるように制限する設計原則である[1][2]

詳細[編集]

この原則は、ユーザーアカウントに対してそのユーザーにとって必須な権限のみを与えることを意味する。例えば、バックアップ用ユーザーアカウントではソフトウェアをインストールする必要がなく、バックアップ関連のアプリケーションのみを実行できればよい。新規ソフトウェアをインストールできる権限などはブロックされる。この原則は普通のユーザーアカウントで作業しているパーソナルコンピュータのユーザーにも当てはまり、事態が完全に特権を要求する場合に限って管理者権限を与えられ、パスワードで保護されたアカウント(すなわちスーパーユーザー)を開く。

ユーザーに対して適用する場合は、「最低限のユーザーアクセス (least user access)」や「最小権限のユーザーアカウント (least-privileged user account)」と呼ばれ、LUAと略記される。その場合、全てのユーザーアカウントは常に必要最小限の権限を伴って実行されるべきとされ、アプリケーションソフトウェアも必要最小限の権限を伴って起動されるべきとされる。権限を加えないと正しく動作できないアプリケーションは、バグをはらんでいる可能性がある。

最小権限の原則は、障害(フォールトトレラント設計の場合)や悪意ある挙動(コンピュータセキュリティの場合)からデータと機能を保護する際に考慮すべき重要な設計観点として広く認識されている。

この原則には次のような利点がある。

システム安定性の向上
コードがシステムを変化させる範囲が制限されていると、考えられる動作や他のアプリケーションとのやりとりを試験するのが容易になる。実際、制限された権限で動作するアプリケーションは、マシンをクラッシュさせるような操作にアクセスできないし、同一システム上の他のアプリケーションに悪影響を与えることもできない。
システムセキュリティの向上
コードがシステム全体に影響するような動作を制限されている場合、あるアプリケーションの脆弱性を悪用してもマシンの残りの部分に影響を及ぼせない。マイクロソフトは「標準ユーザーモードで動作中の場合、シャッター攻撃英語版や(ルートキットや検出できないコンピュータウイルスなどの)マルウェアによるシステムレベルのダメージに対して防護を向上させる」としている[要出典]
ソフトウェアデプロイメントの容易化
一般に、アプリケーションが必要とする権限が少ないほど、より大きな環境での配備が容易になる。これは先述の2つの利点によるもので、デバイスドライバをインストールするアプリケーションや特権レベルを上げる必要があるアプリケーションは、デプロイメントに際して追加の工程を必要とすることが多い。例えば Microsoft Windows ではデバイスドライバのインストールには特権レベルを高くする必要があるので、アプリケーションとは別のインストール工程が必要となる[3]

実際には、真の最小権限の原則を適用することはほとんど不可能に近い。今のところ、あるプロセスの実行に必要とされる最小権限を求める方法が確立されていない。それは、全ての変数のとりうる値の範囲、必要とされるアドレス、必要とされる精密な時間などを完全に把握できないためである。現状で最も現実的なアプローチは、人間が不要だと確認できる権限を取り除いていく方法である。結果として得られる権限群は、そのプロセスの真の最小権限よりも幅広いものとなる。

もう1つの制限として、オペレーティング環境がどこまで細かく権限を制御できるかという問題がある[4]。実際、メモリアクセス範囲、処理時間、I/Oデバイスのアドレスやモードなどを必要な権限だけを正確に与えるほど精密に制御できることは滅多にない。

歴史[編集]

ジェローム・サルツァー英語版が最初にこの原則を次のように明文化した。

システムにおける全てのプログラムと全てのユーザーは、そのジョブを完遂するのに必要な最小の権限を使って動作すべきである。

[5]

ピーター・J・デニングは "Fault Tolerant Operating Systems" と題した論文で、それをより広い観点でフォールトトレラント性の4つの基本原則に仕立て上げた[2]

権限の動的割り当てについては、1972年にロジャー・ニーダム英語版が論じている[6][7]

実装[編集]

カーネルオペレーティングシステム (OS) の中核であり、ハードウェアにアクセスするので、常に最大権限で動作する。特にマルチユーザーOSは、ハードウェアがプロセスから使用可能かどうかを管理し、動作中のプロセス群からのアクセス要求を管理する責任を負っている。カーネルがクラッシュすると、カーネルが状態を維持していた機構が使えなくなる。CPUリセットすることなく復旧する手段が備わっていたとしても、実行中だったコードの実行を再開できるとは限らない。セキュリティは施行され続けるとしても、障害を検出できなければOSが障害に適切に対応することもできない。それは例えば、カーネルが実行を停止した場合や、アイドルループなどで実行再開した場合である。

トロイの木馬をロードし実行したことでシステムがクラッシュし、その後実行再開した場合、トロイの木馬が全プロセスの制御を強奪することができる。最小権限の原則は常に権限を最小にして実行されることをコードに強制するので、そのような場合でもその原則が適用されれば、たとえ予期しない位置から回復したとしても、悪いことができないように再開させることができる。これをマイクロプロセッサで実現できる方法もある。x86アーキテクチャでは、4つのリングによる特権レベルを採用している。

一部OSの実装に見られるように、潜在的な権限セットとアクティブな権限セットを伴ってプロセスを実行する方式もある。それら権限セットは fork() の意味論で決定され、親から継承される。権限の必要な機能(従って技術的にはTCB英語版の一部を構成するコンポーネント)を実行する実行ファイルの場合、setuidsetgidの考え方を論理的に拡張した権限セットが付与される。ファイルに付与された権限をプロセスが継承することは、exec() 系システムコールの意味論で決定される。潜在的プロセス権限、実際のプロセス権限、ファイル権限が具体的にそう相互作用するかはかなり複雑である。実際には、タスクが要求している権限のみをプロセス実行時に強制することで最小権限の原則に近づけようとしている。このモデルに固執することは、複雑というだけでなく、間違いやすい。

類似の原則[編集]

Trusted Computer System Evaluation Criteria (TCSEC) ではトラステッド・コンピューティング・ベース英語版 (TCB) 最小化の概念は非常に厳格な要件であり、機能的に最も強い保証クラスである B3 および A1(機能的にはこの2つは同等である)でのみ適用可能である。

最小権限の原則は、しばしば特権の囲い込み英語版と結び付けられる。すなわち、権限が必要になったときだけそれを得て、必要なくなったら即座に権限を放棄するという考え方で、必要以上の権限を得て意図せずともそれら権限を利用している間違ったコードを表面上避けるものである。最小権限の原則は、任意アクセス制御 (DAC) における許可の文脈で解釈されることもある。例えば、あるユーザーがあるファイルのリードおよびライトのアクセス権を要求したとき、そのユーザーがリードのアクセス権だけでタスクを実行可能(と設定されている)なら、要求を許可しないという方式である。

脚注[編集]

  1. ^ Saltzer 1975
  2. ^ a b Denning 1976
  3. ^ Aaron Margosis (2006年8月). “Problems of Privilege: Find and Fix LUA Bugs”. Microsoft. 2012年11月7日閲覧。
  4. ^ Matt Bishop, Computer Security: Art and Science, Boston, MA: Addison-Wesley, 2003. pp. 343-344 cited Barnum & Gegick 2005
  5. ^ Saltzer, Jerome H. (1974). “Protection and the control of information sharing in multics”. Communications of the ACM 17 (7): 389. doi:10.1145/361011.361067. ISSN 00010782. 
  6. ^ Roger Needham, Protection systems and protection implementations, Proc. 1972 Fall Joint Computer Conference, AFIPS Conf. Proc., vol. 41, pt. 1, pp. 571-578
  7. ^ Schneider, Least Privilege and More

参考文献[編集]

関連項目[編集]

外部リンク[編集]