La separación de mecanismo y política [1] es un principio de diseño en informática . Establece que los mecanismos (aquellas partes de la implementación de un sistema que controlan la autorización de operaciones y la asignación de recursos ) no deben dictar (o restringir demasiado) las políticas según las cuales se toman decisiones sobre qué operaciones autorizar y qué recursos asignar. .
Si bien se discute más comúnmente en el contexto de los mecanismos de seguridad (autenticación y autorización), la separación del mecanismo y la política es aplicable a una variedad de problemas de asignación de recursos (por ejemplo , programación de CPU , asignación de memoria , calidad de servicio ), así como al diseño de abstracciones de software. . [ cita requerida ]
Per Brinch Hansen introdujo el concepto de separación de política y mecanismo en los sistemas operativos en el sistema de multiprogramación RC 4000 . [2] Artsy y Livny, en un artículo de 1987, discutieron un enfoque para el diseño de un sistema operativo que tiene una "separación extrema de mecanismo y política". [3] [4] En un artículo de 2000, Chervenak et al. describió los principios de neutralidad del mecanismo y neutralidad de las políticas . [5]
Justificación e implicaciones
La separación de mecanismo y política es el enfoque fundamental de un microkernel que lo distingue de uno monolítico . En un micronúcleo, la mayoría de los servicios del sistema operativo son proporcionados por procesos de servidor a nivel de usuario. [6] Es importante que un sistema operativo tenga la flexibilidad de proporcionar mecanismos adecuados para soportar el espectro más amplio posible de políticas de seguridad del mundo real. [7]
Es casi imposible imaginar todas las diferentes formas en que un sistema podría ser utilizado por diferentes tipos de usuarios durante la vida útil del producto. Esto significa que es probable que cualquier política codificada sea inadecuada o inapropiada para algunos (o quizás incluso la mayoría) de los usuarios potenciales. Desacoplar las implementaciones del mecanismo de las especificaciones de la política hace posible que diferentes aplicaciones utilicen las mismas implementaciones del mecanismo con diferentes políticas. Esto significa que es probable que esos mecanismos satisfagan mejor las necesidades de una gama más amplia de usuarios durante un período de tiempo más largo.
Si es posible habilitar nuevas políticas sin cambiar los mecanismos de implementación, los costos y riesgos de tales cambios de política pueden reducirse en gran medida. En el primer caso, esto podría lograrse simplemente segregando los mecanismos y sus políticas en módulos distintos: reemplazando el módulo que dicta una política (por ejemplo, la política de programación de la CPU) sin cambiar el módulo que ejecuta esta política (por ejemplo, el mecanismo de programación), puede cambiar el comportamiento del sistema. Además, en los casos en que se anticipe una amplia o variable gama de políticas en función de las necesidades de las aplicaciones, tiene sentido crear algunos medios sin código para especificar políticas, es decir, las políticas no están codificadas en código ejecutable, sino que pueden especificarse como una descripción independiente. . Por ejemplo, las políticas de protección de archivos (por ejemplo , usuario / grupo / otra lectura / escritura / ejecución de Unix ) pueden estar parametrizadas. Alternativamente, se podría diseñar un mecanismo de implementación para incluir un intérprete para un nuevo lenguaje de especificación de políticas. En ambos casos, los sistemas suelen ir acompañados de un mecanismo de enlace diferido (por ejemplo, enlace tardío de opciones de configuración a través de archivos de configuración o programabilidad en tiempo de ejecución a través de API ) que permite que las especificaciones de políticas se incorporen al sistema o se reemplacen por otras después de que se hayan entregado. al cliente.
Un ejemplo cotidiano de separación entre mecanismos y políticas es el uso de llaves de tarjeta para acceder a puertas cerradas. Los mecanismos (lectores de tarjetas magnéticas, cerraduras por control remoto, conexiones a un servidor de seguridad) no imponen ninguna limitación a la política de entrada (a qué personas se les debe permitir ingresar, qué puertas, en qué horarios). Estas decisiones las toma un servidor de seguridad centralizado, que (a su vez) probablemente toma sus decisiones consultando una base de datos de reglas de acceso a las salas. Las decisiones de autorización específicas se pueden cambiar actualizando una base de datos de acceso a la sala. Si el esquema de reglas de esa base de datos resultara demasiado limitante, se podría reemplazar todo el servidor de seguridad sin modificar los mecanismos fundamentales (lectores, bloqueos y conexiones).
Compare esto con la emisión de llaves físicas: si desea cambiar quién puede abrir una puerta, debe emitir nuevas llaves y cambiar la cerradura. Esto entrelaza los mecanismos de desbloqueo con las políticas de acceso. Para un hotel, esto es significativamente menos efectivo que usar tarjetas de acceso.
Ver también
Notas
- ^ Mayordomo W. Lampson y Howard E. Sturgis. Reflexiones sobre el diseño de un sistema operativo [1] Comunicaciones del ACM 19 (5): 251-265 (mayo de 1976)
- ^ "Per Brinch Hansen • IEEE Computer Society" . www.computer.org . Consultado el 5 de febrero de 2016 .
- ^ Miller, MS y Drexler, KE (1988). "Mercados y computación: sistemas abiertos Agoric" . En Huberman, BA (Ed.). (1988), págs. 133-176. La ecología de la computación . Holanda Septentrional.
- ^ Artístico, Yeshayahu et al. , 1987.
- ^ Chervenak 2000 p.2
- ^ Raphael Finkel , Michael L. Scott , Artsy Y. y Chang, H. [www.cs.rochester.edu/u/scott/papers/1989_IEEETSE_Charlotte.pdf Experiencia con Charlotte: simplicidad y función en un sistema operativo distribuido]. IEEE Trans. Software Engng 15: 676-685; 1989. Resumen extendido presentado en el Taller IEEE sobre Principios de Diseño para Sistemas Experimentales Distribuidos, Universidad de Purdue; 1986.
- ^ R. Spencer, S. Smalley, P. Loscocco, M. Hibler, D. Andersen y J. Lepreau La arquitectura de seguridad del matraz: soporte del sistema para diversas políticas de seguridad en las actas del octavo simposio de seguridad de USENIX, páginas 123-139, Agosto de 1999.
Referencias
- Per Brinch Hansen (2001). "La evolución de los sistemas operativos" (PDF) . Consultado el 24 de octubre de 2006 . Cite journal requiere
|journal=
( ayuda ) incluido en el libro: Per Brinch Hansen, ed. (2001) [2001]. "1" (PDF) . Sistemas operativos clásicos: desde el procesamiento por lotes hasta los sistemas distribuidos . Nueva York: Springer-Verlag. págs. 1-36. ISBN 978-0-387-95113-3. (pág.18) - Wulf, W .; E. Cohen; W. Corwin; A. Jones; R. Levin; C. Pierson; F. Pollack (junio de 1974). "HYDRA: el núcleo de un sistema operativo multiprocesador" . Comunicaciones de la ACM . 17 (6): 337–345. doi : 10.1145 / 355616.364017 . ISSN 0001-0782 .
- Hansen, Per Brinch (abril de 1970). "El núcleo de un sistema de multiprogramación" . Comunicaciones de la ACM . 13 (4): 238–241. CiteSeerX 10.1.1.105.4204 . doi : 10.1145 / 362258.362278 . ISSN 0001-0782 . (págs. 238–241)
- Levin, R .; E. Cohen; W. Corwin; F. Pollack; W. Wulf (1975). "Separación política / mecanismo en Hydra" . Simposio de ACM sobre principios de sistemas operativos / Actas del quinto simposio de ACM sobre principios de sistemas operativos . 9 (5): 132–140. doi : 10.1145 / 800213.806531 .
- Chervenak y col. The data grid [ enlace muerto permanente ] Journal of Network and Computer Applications, volumen 23, número 3, julio de 2000, páginas 187-200
- Artsy, Yeshayahu y Livny, Miron , An Approach to the Design of Fully Open Computing Systems (Universidad de Wisconsin / Madison, marzo de 1987) Informe técnico de ciencias informáticas n. ° 689.
enlaces externos
- " Un sistema operativo Vade Mecum " de Raphael Finkel
- Mecanismo y política para HTC