La separación de mecanismos y políticas [1] es un principio de diseño en informática . Afirma 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 excesivamente) las políticas según las cuales se toman decisiones sobre qué operaciones autorizar y qué recursos asignar.
Aunque se analiza más comúnmente en el contexto de los mecanismos de seguridad (autenticación y autorización), la separación de mecanismo y 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íticas y mecanismos en los sistemas operativos en el sistema multiprogramación RC 4000. [2] Artsy y Livny, en un artículo de 1987 , analizaron un enfoque para el diseño de un sistema operativo que tiene una "separación extrema de mecanismos y políticas". [3] [4] En un artículo de 2000, Chervenak et al. describieron los principios de neutralidad de mecanismos y neutralidad de políticas . [5]
La separación de mecanismos y políticas es el enfoque fundamental de un microkernel que lo distingue de uno monolítico . En un microkernel, 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 puede ser utilizado por diferentes tipos de usuarios a lo largo de la vida útil del producto. Esto significa que cualquier política codificada de forma rígida probablemente sea inadecuada o inapropiada para algunos (o quizás incluso la mayoría) de los usuarios potenciales. Desvincular las implementaciones de mecanismos de las especificaciones de políticas permite que diferentes aplicaciones utilicen las mismas implementaciones de mecanismos 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 prolongado.
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 primera instancia, esto podría lograrse simplemente segregando los mecanismos y sus políticas en módulos distintos: al reemplazar el módulo que dicta una política (por ejemplo, la política de programación de CPU) sin cambiar el módulo que ejecuta esta política (por ejemplo, el mecanismo de programación), podemos cambiar el comportamiento del sistema. Además, en los casos en los que se anticipa una amplia o variable gama de políticas según las necesidades de las aplicaciones, tiene sentido crear algunos medios no codificados para especificar políticas, es decir, las políticas no están codificadas en código ejecutable sino que se pueden especificar como una descripción independiente. Por ejemplo, las políticas de protección de archivos (por ejemplo, usuario/grupo/otro de lectura/escritura/ejecución de Unix ) podrían parametrizarse. 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 vinculación diferida (por ejemplo, vinculación tardía 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 incorporar especificaciones de políticas al sistema o reemplazarlas 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 tarjetas para acceder a puertas cerradas. Los mecanismos (lectores de tarjetas magnéticas, cerraduras controladas a distancia, conexiones a un servidor de seguridad) no imponen ninguna limitación en cuanto a las políticas de entrada (qué personas pueden entrar en qué puertas y 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 específicas sobre autorizaciones se pueden cambiar actualizando una base de datos de acceso a las salas. Si el esquema de reglas de esa base de datos resulta demasiado restrictivo, se puede reemplazar todo el servidor de seguridad dejando intactos los mecanismos fundamentales (lectores, cerraduras y conexiones).
Comparemos esto con la emisión de llaves físicas: si queremos cambiar quién puede abrir una puerta, tenemos que emitir llaves nuevas 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 llave.