メカニズムとポリシーの分離

メカニズムとポリシーの分離[ ^1]は、コンピュータサイエンスにおける設計原則です。メカニズム（操作の承認とリソースの割り当てを制御するシステム実装の部分）は、どの操作を承認し、どのリソースを割り当てるかを決定するポリシーを指示（または過度に制限）すべきではないと述べています。

メカニズムとポリシーの分離は、セキュリティメカニズム (認証と承認) のコンテキストで最も一般的に議論されていますが、さまざまなリソース割り当ての問題 ( CPU スケジューリング、メモリ割り当て、サービス品質など) やソフトウェア抽象化の設計にも適用できます。^[要出典]

Per Brinch Hansen は、RC 4000 マルチプログラミングシステムで、オペレーティングシステムにおけるポリシーとメカニズムの分離の概念を導入しました。^[2] Artsy と Livny は、1987 年の論文で、「メカニズムとポリシーの極端な分離」を備えたオペレーティングシステム設計のアプローチについて説明しました。^[3]^{[4] Chervenak らは、2000 年の論文で、}メカニズム中立性とポリシー中立性の原則について説明しました。^[5]

根拠と意味

メカニズムとポリシーの分離は、モノリシックカーネルとマイクロカーネルを区別する基本的なアプローチです。マイクロカーネルでは、オペレーティングシステムサービスの大部分はユーザーレベルのサーバープロセスによって提供されます。^[6]オペレーティングシステムにとって、可能な限り幅広い現実世界のセキュリティポリシーをサポートするために適切なメカニズムを提供する柔軟性を持つことが重要です。^[7]

製品の寿命を通じて、システムがさまざまなタイプのユーザーによって使用される可能性のあるさまざまな方法をすべて想定することはほぼ不可能です。つまり、ハードコードされたポリシーは、一部の (またはおそらくほとんどの) 潜在的なユーザーにとって不十分または不適切である可能性があります。メカニズムの実装をポリシー仕様から切り離すと、さまざまなアプリケーションで同じメカニズムの実装をさまざまなポリシーで使用できるようになります。つまり、これらのメカニズムは、より長い期間にわたって、より広範囲のユーザーのニーズをより適切に満たす可能性が高くなります。

実装メカニズムを変更せずに新しいポリシーを有効にできる場合、そのようなポリシー変更のコストとリスクを大幅に削減できます。まず、メカニズムとそのポリシーを個別のモジュールに分離するだけでこれを実現できます。つまり、ポリシーを指示するモジュール (CPU スケジューリングポリシーなど) を、このポリシーを実行するモジュール (スケジューリングメカニズムなど) を変更せずに置き換えることで、システムの動作を変更できます。さらに、アプリケーションのニーズに応じて幅広いポリシーやさまざまなポリシーが予想される場合は、ポリシーを指定するための非コード手段を作成することが合理的です。つまり、ポリシーは実行可能コードにハードコードされるのではなく、独立した記述として指定できます。たとえば、ファイル保護ポリシー ( Unix のユーザー/グループ/その他の読み取り/書き込み/実行など) はパラメーター化される可能性があります。あるいは、実装メカニズムを設計して、新しいポリシー仕様言語のインタープリターを含めることもできます。どちらの場合も、システムには通常、遅延バインディングメカニズム (構成ファイルによる構成オプションの遅延バインディング、またはAPIによる実行時プログラミングなど) が付属しており、ポリシー仕様をシステムに組み込んだり、顧客に提供された後に別のポリシー仕様に置き換えたりすることができます。

メカニズムとポリシーの分離の日常的な例としては、カードキーを使用して施錠されたドアにアクセスすることが挙げられます。メカニズム (磁気カードリーダー、リモートコントロールロック、セキュリティサーバーへの接続) は、入場ポリシー (どの人がどのドアにいつ入場できるか) に制限を課しません。これらの決定は、集中型セキュリティサーバーによって行われます。セキュリティサーバーは、(今度は) おそらく、部屋のアクセスルールのデータベースを参照して決定を下します。特定の承認決定は、部屋のアクセスデータベースを更新することで変更できます。そのデータベースのルールスキーマが制限的すぎることが判明した場合、基本的なメカニズム (リーダー、ロック、接続) を変更せずに、セキュリティサーバー全体を置き換えることができます。

これを物理的な鍵の発行と比較してみましょう。ドアを開けられる人を変更したい場合、新しい鍵を発行してロックを変更する必要があります。これにより、ロック解除メカニズムとアクセスポリシーが絡み合います。ホテルの場合、これはキーカードを使用するよりも大幅に効果が低くなります。

参照

注記

^ バトラー・W・ランプソンとハワード・E・スタージス。オペレーティングシステム設計に関する考察[1] Communications of the ACM 19(5):251-265 (1976年5月)
^ “ブリンチ・ハンセン氏による • IEEE Computer Society”. www.computer.org 。2016 年 2 月 5 日に取得。
^ Miller, MS, & Drexler, KE (1988)。「市場と計算: Agoric オープンシステム」。Huberman, BA (編) (1988)、pp. 133–176。計算のエコロジー。ノースホランド。
^ アーシー、イェシャヤフら。、1987年。
^ チェルベナック 2000 p.2
^ Raphael Finkel、Michael L. Scott、Artsy Y.、Chang, H. [www.cs.rochester.edu/u/scott/papers/1989_IEEETSE_Charlotte.pdf Charlotte の経験: 分散オペレーティングシステムにおけるシンプルさと機能]。IEEE Trans. Software Engng 15:676-685; 1989。拡張概要は、1986 年に Purdue 大学で開催された実験的分散システムの設計原則に関する IEEE ワークショップで発表されました。
^ R. Spencer、S. Smalley、P. Loscocco、M. Hibler、D. Andersen、J. Lepreau 「Flask セキュリティアーキテクチャ: 多様なセキュリティポリシーに対するシステムサポート」第 8 回 USENIX セキュリティシンポジウムの議事録、123 ～ 139 ページ、1999 年 8 月。

参考文献

Per Brinch Hansen (2001) 「オペレーティングシステムの進化」(PDF) 。2006 年 10 月 24 日閲覧。書籍に収録：Per Brinch Hansen 編 (2001) [2001]。「1」(PDF)。クラシックオペレーティングシステム: バッチ処理から分散システムまで。ニューヨーク: Springer-Verlag。pp. 1–36。ISBN 978-0-387-95113-3。（18ページ）
Wulf, W. ; E. Cohen; W. Corwin; A. Jones; R. Levin; C. Pierson; F. Pollack (1974 年 6 月)。「HYDRA: マルチプロセッサオペレーティングシステムのカーネル」。Communications of the ACM。17 ( 6): 337–345。doi : 10.1145 / 355616.364017。ISSN 0001-0782。S2CID 8011765 。
Hansen , Per Brinch (1970 年4 月)。「マルチプログラミングシステムの核」。Communications of the ACM。13 ( 4): 238–241。CiteSeerX 10.1.1.105.4204。doi : 10.1145 /362258.362278。ISSN 0001-0782。S2CID 9414037 。（238～241ページ）
Levin, R.; E. Cohen; W. Corwin; F. Pollack; W. Wulf (1975)。「Hydra におけるポリシー/メカニズムの分離」。第 5 回オペレーティングシステム原則シンポジウム議事録 - SOSP '75。第 9 巻。pp. 132–140。doi : 10.1145 /800213.806531。ISBN 9781450378635.S2CID 10524544 。
Chervenak 他「データグリッド」^{[永久リンク切れ‍ ]} Journal of Network and Computer Applications、第 23 巻、第 3 号、2000 年 7 月、187-200 ページ
Artsy, Yeshayahu、および Livny, Miron、「完全にオープンなコンピューティングシステムの設計へのアプローチ」(ウィスコンシン大学 / マディソン校、1987 年 3 月) コンピュータサイエンス技術レポート #689。

外部リンク

ラファエル・フィンケルの「オペレーティングシステム Vade Mecum」
HTCの仕組みとポリシー

[1] バトラー・W・ランプソンとハワード・E・スタージス。オペレーティングシステム設計に関する考察[1] Communications of the ACM 19(5):251-265 (1976年5月)

[2] “ブリンチ・ハンセン氏による • IEEE Computer Society”. www.computer.org 。2016 年 2 月 5 日に取得。

[3] Miller, MS, & Drexler, KE (1988)。「市場と計算: Agoric オープンシステム」。Huberman, BA (編) (1988)、pp. 133–176。計算のエコロジー。ノースホランド。

[4] アーシー、イェシャヤフら。、1987年。

[5] チェルベナック 2000 p.2

[6] Raphael Finkel、Michael L. Scott、Artsy Y.、Chang, H. [www.cs.rochester.edu/u/scott/papers/1989_IEEETSE_Charlotte.pdf Charlotte の経験: 分散オペレーティングシステムにおけるシンプルさと機能]。IEEE Trans. Software Engng 15:676-685; 1989。拡張概要は、1986 年に Purdue 大学で開催された実験的分散システムの設計原則に関する IEEE ワークショップで発表されました。

[7] R. Spencer、S. Smalley、P. Loscocco、M. Hibler、D. Andersen、J. Lepreau 「Flask セキュリティアーキテクチャ: 多様なセキュリティポリシーに対するシステムサポート」第 8 回 USENIX セキュリティシンポジウムの議事録、123 ～ 139 ページ、1999 年 8 月。