最小権限の原則

情報セキュリティ、コンピュータサイエンス、その他の分野において、最小権限の原則（PoLP ）は、最小限の権限の原則（PoMP）または最小権限の原則（PoLA ）としても知られ、コンピューティング環境の特定の抽象化レイヤーでは、すべてのモジュール（対象に応じてプロセス、ユーザー、プログラムなど）が正当な目的に必要な情報とリソースにのみアクセスできる必要があることを要求しています。^[1]

詳細

この原則は、ユーザーアカウントまたはプロセスに、その目的の機能を実行するために本質的に不可欠な権限のみを与えることを意味します。たとえば、バックアップを作成する目的のみのユーザーアカウントにはソフトウェアをインストールする必要がないため、バックアップおよびバックアップ関連のアプリケーションを実行する権限のみがあります。新しいソフトウェアのインストールなど、その他の権限はブロックされます。この原則は、通常は通常のユーザーアカウントで作業し、状況が絶対に必要な場合にのみ特権付きでパスワードで保護されたアカウントを開くパーソナルコンピューターユーザーにも適用されます。

ユーザーに適用される場合、「最小ユーザーアクセス」または「最小特権ユーザーアカウント(LUA)」という用語も使用され、すべてのユーザーアカウントは可能な限り少ない権限で実行され、アプリケーションも可能な限り少ない権限で起動される必要があるという概念を指します。

最小権限の原則は、障害 (フォールトトレランス) や悪意のある動作からのデータと機能の保護を強化し、必要な「強化」を行うための重要な設計上の考慮事項として広く認識されています。

この原則の利点は次のとおりです。

知的セキュリティ。コードがシステムに加えることができる変更の範囲が制限されている場合、そのコードが行う可能性のあるアクションや、セキュリティを対象とする他のアプリケーションとの相互作用をテストすることが容易になります。たとえば、実際には、制限された権限で実行されるアプリケーションは、マシンをクラッシュさせたり、同じシステムで実行されている他のアプリケーションに悪影響を与えたりする可能性のある操作を実行する権限がありません。
システムセキュリティの向上。コードが実行できるシステム全体のアクションが制限されている場合、1 つのアプリケーションの脆弱性がマシンの残りの部分に悪用されることはありません。たとえば、Microsoft は「標準ユーザーモードで実行すると、ルートキット、スパイウェア、検出不可能なウイルスなどの「シャッター攻撃」やマルウェアによって引き起こされる不注意なシステムレベルの損傷に対する保護が強化されます」と述べています。^[2]
導入の容易さ。一般的に、アプリケーションに必要な権限が少ないほど、大規模な環境内での導入が容易になります。これは通常、最初の 2 つの利点から生じます。デバイスドライバーをインストールするアプリケーションや、高度なセキュリティ権限を必要とするアプリケーションでは、導入時に追加の手順が必要になるのが一般的です。たとえば、Windows では、デバイスドライバーのないソリューションはインストールせずに直接実行できますが、デバイスドライバーは、ドライバーに高度な権限を付与するために、Windows インストーラーサービスを使用して個別にインストールする必要があります。^[3]

実際には、真の (最小権限) の定義は複数存在します。プログラムの複雑さが急速に増すと、潜在的な問題の数も増えるため、予測アプローチは実用的ではありません。例としては、処理する可能性のある変数の値、必要なアドレス、またはそのようなものが必要になる正確な時間などがあります。オブジェクト機能システムでは、たとえば、1 回限りの権限の付与を、それが使用されるまで延期できます。現在、最も実用的なアプローチは、手動で不要と評価できる権限を削除することです。結果として得られる権限セットは、通常、プロセスに必要な真の最小権限を超えます。

もう一つの制限は、オペレーティング環境が個々のプロセスの権限に対して持つ制御の粒度です。^[4]実際には、プロセスが必要とする正確な権限セットのみを可能にするために必要な精度で、プロセスのメモリ、処理時間、I/Oデバイスアドレスまたはモードへのアクセスを制御することはほとんど不可能です。

オリジナルの定式化はジェローム・サルツァーによるものである：^[5]

システムのすべてのプログラムとすべての特権ユーザーは、ジョブを完了するために必要な最小限の権限を使用して動作する必要があります。
— ジェローム・サルツァー、ACMコミュニケーションズ

Peter J. Denning は、論文「フォールトトレラントオペレーティングシステム」で、フォールトトレランスの 4 つの基本原則の中で、より広い視点からフォールトトレランスを説明しています。

「権限の動的割り当て」については、1972年にロジャー・ニーダムによって議論された。 ^[6]^[7]

歴史的に、 (least privilege) の最も古い例はおそらくlogin.cのソースコードです。これはスーパーユーザー権限で実行を開始し、必要がなくなった瞬間に、バージョン 6 Unixソースコードに示されているように、ゼロ以外の引数を指定したsetuid()によってスーパーユーザー権限を解除します。

実装

カーネルはオペレーティングシステムの中核でありハードウェアにアクセスできるため、常に最大限の権限で実行されます。オペレーティングシステム、特にマルチユーザーオペレーティングシステムの主な責任の 1 つは、ハードウェアの可用性と、実行中のプロセスからのハードウェアへのアクセス要求の管理です。カーネルがクラッシュすると、カーネルが状態を維持するメカニズムも機能しなくなります。したがって、 CPU がハードリセットせずに回復する方法があったとしても、セキュリティは引き続き適用されますが、障害を検出できなかったため、オペレーティングシステムは障害に適切に対応できません。これは、カーネルの実行が停止したか、プログラムカウンタが無限の (通常は機能しない) ループのどこかから実行を再開したためです。^{[要出典]これは、}記憶喪失(カーネル実行障害) を経験するか、常に開始点に戻る閉じた迷路 (閉ループ) に閉じ込められることに似ています。

クラッシュ後にトロイの木馬コードをロードして実行することで実行が再開された場合、トロイの木馬コードの作成者はすべてのプロセスの制御を奪取できます。最小権限の原則により、コードは可能な限り低い権限/許可レベルで実行されます。つまり、コード実行を再開するコード (トロイの木馬であれ、予期しない場所から単にコード実行が再開されたものであれ) は、悪意のあるプロセスや望ましくないプロセスを実行することができません。これを実現する方法の 1 つは、マイクロプロセッサハードウェアに実装できます。たとえば、Intel x86アーキテクチャでは、メーカーは段階的なアクセスレベルを持つ 4 つの (リング 0 からリング 3) 実行「モード」を設計しました。これは、防衛機関や諜報機関のセキュリティクリアランスシステムとよく似ています。^{[引用が必要]}

一部のオペレーティングシステムで実装されているように、プロセスは潜在的な特権セットとアクティブな特権セットを使用して実行されます。^{[要出典]このような特権セットは、}fork ()のセマンティクスによって決定され、親から継承されます。特権機能を実行する実行可能ファイル(技術的にはTCBのコンポーネントを構成し、同時に信頼されたプログラムまたは信頼されたプロセスと呼ばれます) にも、特権セットがマークされる場合があります。これは、set user IDとset group IDの概念の論理的な拡張です。^[要出典]プロセスによるファイル特権の継承は、 exec ()ファミリのシステムコールのセマンティクスによって決定されます。潜在的なプロセス特権、実際のプロセス特権、およびファイル特権が相互作用する正確な方法は、複雑になる可能性があります。実際には、タスクに必要な特権のみでプロセスを実行するように強制することで、最小特権が実践されています。このモデルに準拠することは、非常に複雑であるだけでなく、エラーが発生しやすくなります。

同様の原則

信頼できるコンピュータシステム評価基準( TCSEC) の信頼できるコンピューティングベース(TCB) の最小化の概念は、機能的に最も強力な保証クラス (信頼できるコンピュータシステム評価基準のセクションの区分とクラスへのリンク)、つまりクラスB3とA1 (機能的には同じですが、必要な証拠とドキュメントの点で異なります) にのみ適用される、はるかに厳格な要件です。

最小権限は、権限の括弧付けと関連付けられることがよくあります。つまり、必要な権限を可能な限り最後の瞬間に想定し、厳密に必要でなくなったらすぐに却下することで、意図せず必要以上の権限を悪用する誤ったコードによる影響を表面上は軽減します。最小権限は、任意アクセス制御(DAC) 権限の分配のコンテキストでも解釈されてきました。たとえば、ユーザー U が読み取り権限のみで承認されたタスクを完了できる場合、ユーザー U にファイル F への読み取り/書き込みアクセス権を与えることは、最小権限に違反すると主張します。

参照

参考文献

^ Saltzer, Jerome H. ; Schroeder, Michael D. (1975). 「コンピュータシステムにおける情報の保護」。Proceedings of the IEEE . 63 (9). Institute of Electrical and Electronics Engineers (IEEE): 1278–1308. doi :10.1109/proc.1975.9939. ISSN 0018-9219. OCLC 5871551104. S2CID 269166.
^ Jonathan, Clark; DABCC Inc. 「仮想化の第一人者が「ユーザーモードは良いこと - セキュリティ昇格なしでロックダウンされたアカウントに展開」と書く」。 2013 年 2 月 10 日時点のオリジナルよりアーカイブ。 2013 年3 月 15 日閲覧。
^ Aaron Margosis (2006 年 8 月)。「特権の問題: LUA のバグを見つけて修正する」。Microsoft。
^ 「Matt Bishop, Computer Security: Art and Science, Boston, MA: Addison-Wesley, 2003. pp. 343-344 は Barnum & Gegick 2005 を引用」。2007 年 10 月 20 日時点のオリジナルよりアーカイブ。2007年 11 月 17 日閲覧。
^ Saltzer, Jerome H. (1974). 「Multics における情報共有の保護と制御」Communications of the ACM . 17 (7): 388–402. CiteSeerX 10.1.1.226.3939 . doi :10.1145/361011.361067. ISSN 0001-0782. S2CID 326132.
^ Needham, RM (1972)。「保護システムと保護の実装」。AFIPS '72 Fall Joint Computer Conference の議事録、1972 年 12 月 5 ～ 7 日、パート I。pp. 571～ 578。doi :10.1145/1479992.1480073。S2CID 7371342 。
^ Fred B. Schneider. 「最小権限とそれ以上」(PDF)。

文献

ベン・マンキン、「保護システムの形式化」、博士論文、バース大学、2004年
PJ Denning (1976 年 12 月)。「フォールトトレラントオペレーティングシステム」。ACM Computing Surveys。8 ( 4): 359–389。doi : 10.1145 /356678.356680。S2CID 207736773 。
Jerry H. Saltzer 、Mike D. Schroeder ( 1975 年 9 月)。「コンピュータシステムにおける情報の保護」。IEEEの議事録。63 (9): 1278–1308。CiteSeerX 10.1.1.126.9257。doi : 10.1109 /PROC.1975.9939。S2CID 269166 。
Deitel, Harvey M. (1990)。『オペレーティングシステム入門（初版再版）』Addison-Wesley。673 ページ。ISBN 978-0-201-14502-1。31ページ。
ショーン・マーティン (2012 年 4 月)。「クラウドとモバイルの陰でセキュリティの基本が失われつつあるか?」SC Magazine。
SANS Institute (2013 年 5 月)。「20 の重要なセキュリティコントロール」(PDF)。SANS Institute。2013年 11 月 1 日のオリジナル(PDF)からアーカイブ。

外部リンク

参考文献に引用されている Saltzer と Schroeder の論文。
NSA（SELinuxを実装した組織）は最小権限の原則について語っている
Solaris における最小権限の原則の実装に関する議論
「LUA があなたをより安全にする証拠」Dana Epp 著 2010-05-23 にWayback Machineでアーカイブ
Windows XP のユーザーアカウントに最小権限の原則を適用する (Microsoft 著)
「営利企業は私たちの重要なインフラを危険にさらしている」CSO
最小権限の原則をうまく実装する方法

[Saltzer_Schroeder_1975_pp._1278–1308-1] Saltzer, Jerome H. ; Schroeder, Michael D. (1975). 「コンピュータシステムにおける情報の保護」。Proceedings of the IEEE . 63 (9). Institute of Electrical and Electronics Engineers (IEEE): 1278–1308. doi :10.1109/proc.1975.9939. ISSN 0018-9219. OCLC 5871551104. S2CID 269166.

[2] Jonathan, Clark; DABCC Inc. 「仮想化の第一人者が「ユーザーモードは良いこと - セキュリティ昇格なしでロックダウンされたアカウントに展開」と書く」。 2013 年 2 月 10 日時点のオリジナルよりアーカイブ。 2013 年3 月 15 日閲覧。

[3] Aaron Margosis (2006 年 8 月)。「特権の問題: LUA のバグを見つけて修正する」。Microsoft。

[4] 「Matt Bishop, Computer Security: Art and Science, Boston, MA: Addison-Wesley, 2003. pp. 343-344 は Barnum & Gegick 2005 を引用」。2007 年 10 月 20 日時点のオリジナルよりアーカイブ。2007年 11 月 17 日閲覧。

[5] Saltzer, Jerome H. (1974). 「Multics における情報共有の保護と制御」Communications of the ACM . 17 (7): 388–402. CiteSeerX 10.1.1.226.3939 . doi :10.1145/361011.361067. ISSN 0001-0782. S2CID 326132.

[6] Needham, RM (1972)。「保護システムと保護の実装」。AFIPS '72 Fall Joint Computer Conference の議事録、1972 年 12 月 5 ～ 7 日、パート I。pp. 571～ 578。doi :10.1145/1479992.1480073。S2CID 7371342 。

[7] Fred B. Schneider. 「最小権限とそれ以上」(PDF)。