最小権限の原則（さいしょうけんげんのげんそく、英:Principle of Least Privilege、略:PoLP）とは、情報セキュリティや計算機科学などの分野において、コンピューティング環境の特定の抽象化レイヤー内で全てのモジュール（主題によっては、プロセス、ユーザー、プログラム）がその正当な目的に必要とされる情報と計算資源のみにアクセスできるように制限する設計原則である。
詳細 最小権限の原則は、ユーザーアカウントに対して、そのユーザーにとって必要な権限だけを与えることを意味する。例えば、バックアップ用ユーザーアカウントでは、ソフトウェアをインストールする必要はなく、バックアップ関連のアプリケーションだけを実行できればよいので、新規ソフトウェアをインストールする権限などは付与されない。この原則は、普通のユーザーアカウントで作業しているパーソナルコンピュータのユーザーにも当てはまる。つまり、事態が完全に特権を要求する場合に限って管理者権限を与えられ、パスワードで保護されたアカウント（すなわちスーパーユーザー）にログインする。
ユーザーに対してこの原則を適用する場合は、「最低限のユーザーアクセス (least user access)」や「最小権限のユーザーアカウント (least-privileged user account)」と呼ばれ、LUAと略記される。その場合、全てのユーザーアカウントは、常に必要最小限の権限で実行されるべきであり、その際にはアプリケーションソフトウェアも必要最小限の権限で起動されるべきとされる。権限を与えないと正しく動作できないアプリケーションは、バグを孕んでいる可能性がある。
最小権限の原則は、障害（フォールトトレラント設計の場合）や悪意ある挙動（コンピュータセキュリティの場合）からデータと機能を保護するうえで、重要な設計観点として、広く認識されている。
この原則には、次のような利点がある。 システム安定性の向上 コードがシステムを変化させる範囲が制限されていると、考えられる動作や他のアプリケーションとのやりとりを試験するのが容易になる。実際、制限された権限で動作するアプリケーションは、マシンをクラッシュさせるような操作にアクセスできないし、同一システム上の他のアプリケーションに悪影響を与えることもできない。 システムセキュリティの向上 コードがシステム全体に影響するような動作を制限されている場合、あるアプリケーションの脆弱性を悪用しても、マシンの残りの部分に影響が及ばない。マイクロソフトは「標準ユーザーモードで動作中の場合、や（ルートキットや検出できないコンピュータウイルスなどの）マルウェアによるシステムレベルのダメージに対して防護を向上させる」としている。 ソフトウェアデプロイメントの容易化 一般に、アプリケーションが必要とする権限が少ないほど、より大きな環境での配備が容易になる。これは先述の2つの利点によるもので、デバイスドライバをインストールするアプリケーションや特権レベルを上げる必要があるアプリケーションは、デプロイメントに際して追加の工程を必要とすることが多い。例えば Microsoft Windows ではデバイスドライバのインストールには特権レベルを高くする必要があるので、アプリケーションとは別のインストール工程が必要となる。
実際には、真の最小権限の原則を適用することはほとんど不可能に近い。今のところ、あるプロセスの実行に必要とされる最小権限を求める方法が確立されていない。それは、全ての変数のとりうる値の範囲、必要とされるアドレス、必要とされる精密な時間などを完全に把握できないためである。現状で最も現実的なアプローチは、人間が不要だと確認できる権限を取り除いていく方法である。結果として得られる権限群は、そのプロセスの真の最小権限よりも幅広いものとなる。
もう1つの制限として、オペレーティング環境がどこまで細かく権限を制御できるかという問題があるMatt Bishop, Computer Security: Art and Science, Boston, MA: Addison-Wesley, 2003. pp. 343-344 cited Barnum & Gegick 2005。実際、メモリアクセス範囲、処理時間、I/Oデバイスのアドレスやモードなどを必要な権限だけを正確に与えるほど精密に制御できることは滅多にない。
歴史 が最初にこの原則を次のように明文化した。
ピーター・J・デニングは "Fault Tolerant Operating Systems" と題した論文で、それをより広い観点でフォールトトレラント性の4つの基本原則に仕立て上げた。
権限の動的割り当てについては、1972年にが論じているRoger Needham, Protection systems and protection implementations, Proc. 1972 Fall Joint Computer Conference, AFIPS Conf. Proc., vol. 41, pt. 1, pp. 571-578Schneider, Least Privilege and More。
実装 カーネルは、オペレーティングシステム (OS) の中核であり、ハードウェアにアクセスするので、常に最大権限で動作する。特にマルチユーザーOSは、ハードウェアがプロセスから使用可能かどうかを管理し、動作中のプロセス群からのアクセス要求を管理する責任を負っている。したがって、カーネルがクラッシュすると、カーネルが状態を維持していた機構が使えなくなる。さらに、CPUにリセットすることなく復旧する手段が備わっていたとしても、実行中だったコードの実行を再開できるとは限らない。セキュリティは施行され続けるとしても、障害を検出できなければOSが障害に適切に対応することもできない。それは例えば、カーネルが実行を停止した場合や、アイドルループなどで実行再開した場合である。
トロイの木馬をロードし実行したことでシステムがクラッシュし、その後実行再開した場合、トロイの木馬が全プロセスの制御を強奪することができる。最小権限の原則は、常に権限を最小にして実行されることをコードに強制する。そのため、その原則が適用されれば、たとえ予期しない位置から回復したとしても、悪いことができないように再開させることができる。これをマイクロプロセッサで実現できる方法もある。x86アーキテクチャでは、4つのリングによる特権レベルを採用している。
一部OSの実装に見られるように、潜在的な権限セットとアクティブな権限セットを伴ってプロセスを実行する方式もある。それら権限セットは fork() の意味論で決定され、親から継承される。権限の必要な機能（従って技術的にはの一部を構成するコンポーネント）を実行する実行ファイルの場合、setuidとsetgidの考え方を論理的に拡張した権限セットが付与される。ファイルに付与された権限をプロセスが継承することは、exec() 系システムコールの意味論で決定される。潜在的プロセス権限、実際のプロセス権限、ファイル権限が具体的にそう相互作用するかはかなり複雑である。実際には、タスクが要求している権限のみをプロセス実行時に強制することで最小権限の原則に近づけようとしている。このモデルに固執することは、複雑というだけでなく、間違いやすい。
類似の原則 Trusted Computer System Evaluation Criteria (TCSEC) では (TCB) 最小化の概念は、非常に厳格な要件であり、機能的に最も強い保証クラスである B3 および A1（機能的にはこの2つは同等である）でのみ適用可能である。
最小権限の原則は、しばしばと結び付けられる。すなわち、権限が必要になったときだけその権限を得て、必要がなくなったら即座にその権限を放棄するという考え方である。これは、必要以上の権限を得て意図せずともそれら権限を利用している間違ったコードを表面上避けるものである。最小権限の原則は、任意アクセス制御 (DAC) における許可の文脈で解釈されることもある。例えば、あるユーザーがあるファイルのリードおよびライトのアクセス権を要求したとき、そのユーザーがリードのアクセス権だけでタスクを実行可能（と設定されている）なら、要求を許可しないという方式である。
脚注
参考文献
Ben Mankin, The Formalisation of Protection Systems, Ph. D thesis, University of Bath, 2004
page 31.
関連項目 ユーザーアカウント制御 Capability-based security Confused deputy problem setuid sudo Polkit
外部リンク Managing least privileges from the cloud by Monique Sendze "Proof that LUA makes you safer" by Dana Epp Applying the Principle of Least Privilege to User Accounts on Windows XP, by Microsoft "Commercial enterprises are putting our critical infrastructure at risk" CSO