機構と方針の分離
機構と方針の分離[1]とは、計算機科学における設計原則の1つ。機構（操作の認可と資源配分を制御するシステム実装部分）は、どの操作を認可するかやどの資源を割り当てるかといった決定を行う際の方針を表すべきでない（あるいは過度に制限すべきでない）という考え方である。
主にセキュリティ機構（認証と認可）に関して議論されるが、様々な資源配分問題（CPUスケジューリング、メモリ割り当て、Quality of Serviceなど）にも当てはまる考え方であり、オブジェクト抽象化全般に関わる課題でもある。
機構と方針を分離すべきだと主張した計算機科学者として Per Brinch Hansen がいる[2][3]。
1987年の論文で Artsyらは「機構と方針を極端に分離」させたオペレーティングシステムの設計技法を論じた[4][5]。
Chervenakらは2000年の論文で、「機構中立性」と「方針中立性」という原則を提唱した[6]。
原理と意味
[編集]機構と方針の分離は、マイクロカーネルの基礎となる考え方であり、モノリシックカーネルと大きく異なる部分である。マイクロカーネルではオペレーティングシステムのサービスの大部分をユーザレベルのサーバプロセスで提供する[7]。オペレーティングシステムは適切な機構を提供する柔軟性を持ち、実世界の様々なセキュリティ方針をサポート可能なようにするのが重要だとされている[8]。
システムが製品としての寿命を迎えるまでにそれを使うかもしれない様々な種類のユーザーの様々な使い方を全て想定することは、ほとんど不可能である。したがって方針が分離されていないと、一部（またはほとんど）のユーザーにとってその方針が不十分または不適切なものとなる可能性がある。機構の実装と方針の仕様を分離することで、異なるアプリケーションが共通の機構と異なる方針を使用することが可能となる。そうすることで、そういった機構がより多くのユーザーのニーズを満たし、より長期に渡って使われることになる。
機構の実装を変更せずに新たな方針を採用できるなら、そのような方針転換のコストとリスクは大いに低減できる。最初の例は、機構と方針を別々のモジュールとして分離するやり方である。方針を表したモジュール（例えばCPUスケジューリング方針）を置き換えることで、その方針を実行するモジュール（例えばスケジューリング機構）を変更することなくシステムの挙動を変えることができる。さらに、アプリケーションのニーズに従って様々な不定範囲の方針が予想される場合、コーディングしない形で方針を指定できるようにすることも考えられる。その場合、方針は実行コードとして書かれるのではなく、それとは独立した何らかの記述によって指定される。例えば、ファイル保護方針（UNIXのファイルパーミッションなど）はパラメータ化することもできる。その場合、機構側は新たな方針記述言語のインタプリタを含むよう設計される。いずれの場合も、方針の仕様を新たに導入したり置換したりするための結合機構（例えば、設定ファイルやAPI）がシステムに備わっているのが一般的である。
機構と方針の分離の日常的な例として、施錠されたドアを開けるカードキーの使用が挙げられる。その機構（磁気カードリーダ、遠隔操作方式の錠、セキュリティサーバとの接続）は、方針（どういった人がどういう時間にそのドアを開け閉めできるか）に対して何の制限も課していない。方針を決定するのはセキュリティサーバであり、さらに言えば各部屋へのアクセス規則のデータベースを操作することで決定がなされる。すなわち、特定のカードキーで特定のドアを開けられるか否かをデータベースに設定することで方針の変更がなされる。セキュリティ方針が所有者の考えていたものと違う場合、機構（磁気カードリーダ、錠、接続）を変更せずにセキュリティサーバのソフトウェアを更新するだけでよい。
脚注
[編集]- ^ Butler W. Lampson and Howard E. Sturgis. Reflections on an Operating System Design [1] Communications of the ACM 19(5):251-265 (May 1976)
- ^ Wulf 1974, pp. 337–345
- ^ Hansen 1970, pp. 238–241
- ^ Miller, M. S., & Drexler, K. E. (1988). Markets and computation: Agoric open systems. In Huberman (1988), pp. 133{176. (Huberman, B. A. (Ed.). (1988). The Ecology of Computation. North-Holland.)
- ^ Artsy, Yeshayahu & Livny 1987
- ^ Chervenak 2000, p. 2
- ^ Raphael Finkel, Michael L. Scott, Artsy Y. and Chang, H. [www.cs.rochester.edu/u/scott/papers/1989_IEEETSE_Charlotte.pdf Experience with Charlotte: simplicity and function in a distributed operating system]. IEEE Trans. Software Engng 15:676-685; 1989. Extended abstract presented at the IEEE Workshop on Design Principles for Experimental Distributed Systems, Purdue University; 1986.
- ^ R. Spencer, S. Smalley, P. Loscocco, M. Hibler, D. Andersen, and J. Lepreau The Flask Security Architecture: System Support for Diverse Security Policies In Proceedings of the Eighth USENIX Security Symposium, pages 123–139, Aug. 1999.
参考文献
[編集]- Per Brinch Hansen (2001) (pdf). The evolution of operating systems 2006年10月24日閲覧。. included in book: Per Brinch Hansen, ed (2001) [2001]. “1”. Classic operating systems: from batch processing to distributed systems. New York,: Springer-Verlag. pp. 1–36. ISBN 0-387-95113-X (p.18)
- Wulf, W.; E. Cohen, W. Corwin, A. Jones, R. Levin, C. Pierson, F. Pollack (June 1974). “HYDRA: the kernel of a multiprocessor operating system”. Communications of the ACM 17 (6): 337–345. doi:10.1145/355616.364017. ISSN 0001-0782.
- Hansen, Per Brinch (April 1970). “The nucleus of a Multiprogramming System”. Communications of the ACM 13 (4): 238–241. doi:10.1145/362258.362278. ISSN 0001-0782. (pp.238–241)
- Levin, R.; E. Cohen, W. Corwin, F. Pollack, W. Wulf (1975). “Policy/mechanism separation in Hydra”. ACM Symposium on Operating Systems Principles / Proceedings of the fifth ACM symposium on Operating systems principles: 132–140. doi:10.1145/800213.806531.
- Chervenak et al. (July 2000). “The data grid”. Journal of Network and Computer Applications 23 (3): 187-200.
- Artsy; Yeshayahu; Livny (March 1987), “An Approach to the Design of Fully Open Computing Systems”, Computer Sciences Technical Report (Madison: University of Wisconsin) (689)