Durante los últimos meses he estado trabajando mucho en la generación de un framework de uso no controlado. Es decir un framework que será utilizado por un conjunto variado de desarrolladores con los cuales no habrá una interacción. Esto no es una novedad para quienes desarrollan frameworks opens-source o redistribuibles, sin embargo a diferencia de ellos este framework es de uso corporativo y con un foco muy alto en la seguridad y restricción en lo que los usuarios del mismo pueden realizar. Para ser más claros la idea no es solo proveer piezas reutilizables de código y lógica sino asegurar que dichas piezas sean utilizadas obligatoriamente y limitar el código desarrollado en lo que puede realizar directamente.
Duante el desarrollo de dicho framework utilizamos muchos, sino todos, de los recursos disponibles en lo que se refiere a diseño de frameworks y librerias base pero llegó un punto donde la información disponible no era suficiente para poder lograr nuestro objetivo. Esto tenía que ver con el uso de CAS (Code Access Security). Ha sido establecido por más de uno que la documentación relacionado con el tema es bastante críptica por lo que luego de una breve investigación logramos establecer un mecanismo para lograr nuestro objetivo. Así que creo que vale la pena resumir el resultado del análisis.
CAS es un mecanismo que permite controlar la ejecución de porciones de código limitando de esta forma el acceso a operaciones y recursos protegidos. En el caso de un framework empresarial el uso de CAS es muy importante pues permite que los administradores puedan limitar el acceso de las aplicaciones a los recursos declarados. Algunos de los elementos que son controlados a traves de CAS son:
CAS ha sido muy poco utilizado en general debido a que la mayoria de las aplicaciones se ejecutan en FullTrust.
Si bien el escenario ideal permite que una aplicación pueda estar limitado a acceder a los recursos exclusivos a través de CAS esto implica que toda aplicación deberia tener un inventario de los recursos utilizados (el escenario ideal incluso para un modelo de amenazas) pero esto no es posible cuando se habla de cientos de aplicaciones modificadas varias veces por año. Por esto es que en el escenario en el que estuvimos trabajando se planteó utilizar el framework de desarrollo como proxy es decir, todo acceso a un recurso sensible es realizado por el framework y las aplicación solo tienen permiso de invocar al framework.
En este caso se da un cambio en las premisas de administración donde en lugar de buscar la mayor restricción en el acceso a recursos se favorece el control y auditoria de acceso. Con el escenario propuesto si bien las aplicaciones podrán acceder a todos los recursos el framework genera toda la información de auditoria necesaria y puede brindar mecanismos de restricción de acceso que sea configurable de manera más simple que la consola y herramientas de CAS.
En próximos posts haré un análisis básico del uso de CAS en una configuración de permisos delegados.
Recursos para el diseño de frameworks
Design Guidelines for Developing Class Libraries
