最小権限の原則

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

詳細

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

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

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

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

  • 知的セキュリティ。コードがシステムに加える変更の範囲が制限されている場合、そのコードの動作や、セキュリティ対象となる他のアプリケーションとの相互作用をテストしやすくなります。例えば、実際には、制限された権限で実行されるアプリケーションは、マシンをクラッシュさせたり、同じシステムで実行されている他のアプリケーションに悪影響を与えたりする可能性のある操作を実行する権限を持ちません。
  • システムセキュリティの向上。コードがシステム全体に影響を与えるアクションを制限すれば、あるアプリケーションの脆弱性を悪用してマシンの残りの部分を攻撃されることがなくなります。例えば、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 がハードリセットせずに回復する方法があったとしても、セキュリティは引き続き適用されますが、障害を検出できなかったため、オペレーティングシステムは障害に適切に対応できません。これは、カーネルの実行が停止したか、プログラムカウンタが無限の (通常は機能しない)ループのどこかから実行を再開したためです。これは、記憶喪失 (カーネル実行障害)を経験するか、常に開始点に戻る閉じた迷路 (閉ループ) に閉じ込められているかのどちらかに似ています。

Intel x86の特権リングによって実証された最小権限の原則

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

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

同様の原則

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

最小権限は、権限のブラケティング（権限の括り付け）と関連付けられることが多い。つまり、必要な権限を可能な限り最後の瞬間に付与し、もはや厳密に必要ではなくなった時点でそれらを破棄することで、意図せず本来の権限よりも多くの権限を悪用する誤ったコードによる影響を軽減する、という考え方である。最小権限は、任意アクセス制御（DAC）権限の配分という文脈でも解釈されてきた。例えば、ユーザーUにファイルFへの読み取り/書き込み権限を与えることは、Uが読み取り権限のみで許可されたタスクを完了できる場合、最小権限に違反する、という主張がある。

参照

参考文献

  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 cited 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 Proceedings, December 5-7, 1972, Part I. pp.  571– 578. doi : 10.1145/1479992.1480073 . S2CID 7371342 . 
  7. ^ Fred B. Schneider. 「最小権限とそれ以上」（PDF） .

参考文献

「 https://en.wikipedia.org/w/index.php?title=Principle_of_least_privilege&oldid=1334228724」より取得