Patrones orientados a aspectos para hacer aplicaciones seguras
Vladimir Emiliano Moreira Rocha Universidade de S˜ao Paulo
Departamento de Ciˆencia da Computac¸˜ao S˜ao Paulo, Brasil
vmoreira@ime.usp.br and
Christian Danniel Paz Trillo Universidade de S˜ao Paulo
Departamento de Ciˆencia da Computac¸˜ao S˜ao Paulo, Brasil
cpaz@ime.usp.br
Abstract
Nowadays, one of the main objectives when developing software systems is to make them secure. Often, systems are designed and implemented without security in mind since initial development phases, producing design changes and bigger costs. There are object-oriented solutions to deal with this problem, but they lead to code reuse problems, because of intruder code inside application classes. This occurs since security is a traversal functionality, which is not effectively handled with object-oriented approaches. Aspect-oriented programming complements object-oriented pro- gramming to treat this kind of problems. This paper presents aspect-oriented patterns focused on secure applications, so its inclusion do not affect the system architecture.
Keywords: Aspect-Oriented Programming, Software Security, Architectural Patterns Resumen
Hoy en d´ıa, uno de los objetivos primordiales al desarrollar sistemas, es que sean seguros. Muchas veces los sistemas son dise˜nados e implementados sin tener en cuenta la seguridad desde las fases iniciales, lo que genera cambios en el dise˜no y mayores costos. Existen soluciones propuestas desde el punto de vista de la orientaci´on a objetos, pero que a´un as´ı conllevan a problemas de reutilizaci´on debido a c´odigo intruso de seguridad, dentro de las clases de la aplicaci´on. Esto se debe a que la seguridad es una funcionalidad transversal con la cual la orientaci´on a objetos no puede lidar eficientemente. La orientaci´on a aspectos surge como complemento a la orientaci´on a objetos para tratar ese tipo de problemas. Este trabajo presenta patrones orientados a aspectos enfocados en dar seguridad a las aplicaciones, tal que su incorporaci´on no influya en la arquitectura del sistema.
Palabras claves: Orientaci´on a aspectos, Seguridad de Software, Patrones Arquitecturales.
1 Introducci´on
En la actualidad, la mayor´ıa de aplicaciones requieren implementar ciertas caracter´ısticas de seguridad, debido a la gran cantidad de intromisiones no intencionales e intencionales. Sin embargo, frecuentemente los sistemas son dise˜nados e implementados, sin tener en mente la seguridad. Dar seguridad a un sistema orientado a objetos, implica modificar las clases a las cuales se desea implementar esta funcionalidad, y con esto, el c´odigo asociado a la seguridad queda disperso en el sistema.
Realizar modificaciones a caracter´ısticas de seguridad por tanto, involucrar´ıa hacer cambios en diversos puntos del c´odigo. En [6] fueron presentados diversos patrones orientados a objetos que tratan un conjunto amplio de problemas de seguridad, que intenta extraer las caracter´ısticas de seguridad a clases especializadas. Sin embargo, el problema de fondo, es que la seguridad comunmente es una funcionalidad transversal a la aplicaci´on.
Cuando una funcionalidad transversal es tratada con programaci´on orientada a objetos, dif´ıcilmente es imple- mentada con una alta cohesi´on. La programaci´on orientada a aspectos propone formas de exponer y desarrollar funcionalidades transversales en las distintas etapas de un proyecto de forma que exista alta cohesi´on en la soluci´on.
En este trabajo presentamos algunos problemas t´ıpicos en seguridad, como los presentados en [6], y las soluciones a los mismos con orientaci´on a aspectos. Para cada patr´on, ser´a presentado el problema a trav´es de un escenario ejemplo, la soluci´on, las consecuencias de la aplicaci´on del patr´on y algunos patrones orientados a objetos relacionados a la soluci´on del problema.
En la Secci´on 2 presentamos la Programaci´on Orientada a Aspectos como un complemento a la Programaci´on Orientada a Objetos y los principales componentes para su implementaci´on. Las siguientes dos secciones muestran un problema de implementaci´on de seguridad en una aplicaci´on y su respectiva soluci´on orientada a aspectos. La Secci´on 3 muestra el patr´on para control de pol´ıticas, que ayuda en el control de acceso a funcionalidades por parte de usuarios y el control de accesos indebidos. El patr´on interfaz segura, que facilita la implementaci´on de interacci´on entre sistemas, es presentado en la Secci´on 4. Finalmente, las conclusiones y trabajos futuros son presentados en la Secci´on 5.
2 Programaci´on Orientada a Aspectos
2.1 Perspectiva General
Los lenguajes de programaci´on han ido evolucionando desde la codificaci´on a nivel de m´aquina (c´odigo Ensamblador) hasta lo m´as com´un hoy en d´ıa que es la orientaci´on a objetos. En cada uno de estos avances se ha tratado de entregar a los desarrolladores una mejoria en la identificaci´on, encapsulamiento y manipulaci´on de entidades que son propias de una funcionalidad del sistema.
Las tecnolog´ıas involucradas en la orientaci´on a objetos, tales como: metodolog´ıas, herramientas de an´alisis y dise˜no, patrones, etc. han reducido en gran medida los problemas de mantenimiento y codificaci´on de sistemas de mediana y gran complejidad. A pesar de estas mejor´ıas, la orientaci´on a objetos tiene algunas limitaciones como el encapsulamiento de una funcionalidad del sistema que est´a dispersa por varias clases. Estas funcionalidades pueden ser de diversos tipos como: seguridad, calidad de servicio, reglas de negocios, sincronizaci´on de m´etodos, etc. Estas funcionalidades son llamadas Funcionalidades Tranversales.
2.2 Funcionalidades Tranversales
Definimos como funcionalidad tranversal a una funcionalidad del sistema (por ejemplo un caso de uso en notaci´on UML) que se interseca con otra funcionalidad y que no puede separarse en unidades modulares. Por ejemplo una funcionalidad transversal es el logging1de todas las operaciones de transacci´on(otra funcionalidad) de un sistema de finanzas de una empresa.
2.3 Programaci´on Orientada a Aspectos
Como sabemos de la orientaci´on a objetos, s´olo una funcionalidad puede estar encapsulada en una clase para que tenga cohesi´on, pero esto es muy dif´ıcil de obtener en la mayor´ıa de los sistemas complejos. La orientaci´on a aspectos[2] es una nueva tecnolog´ıa que trata el problema de las funcionalidades transversales encapsulando el comportamiento que afecta a distintas clases en unidades modulares llamadas Aspectos. Como resultado de esto se tiene un m´odulo coheso con un comportamiento igual al de una clase en la Orientaci´on a objetos, con atributos, procedimientos, funciones, etc.
Es importante destacar que la programaci´on orientada a aspectos es un complemento a la programaci´on orientada a objetos y en ning´un caso la sustituye. En la programaci´on orientada a aspectos, existen cuatro componentes b´asicos e indispensables [3]:
• Join-Point: Es el responsable de definir los puntos de enlace donde ser´a agregado el comportamiento a ser ejecutado. Estos enlaces son puntos bien definidos del programa, como: constructores de clases, m´etodos, llamadas a m´etodos, excepciones, etc.
• Pointcut: Es el que modela la estructura de la funcionalidad transversal. Para esto contiene una selecci´on de Join-Point basados en un criterio de operadores l´ogicos.
• Advice: Responsable de agregar el comportamiento a ser ejecutado cuando se intercepta un punto determinado del programa definido en el Pointcut.
• Aspect: Unidad b´asica de la Programaci´on orientada a Aspectos que contiene las tres construcciones b´asicas antes mencionadas. Tiene el mismo comportamiento que una clase y es encargado de encapsular las funciona- lidades tranversales dispersas en el sistema.
1Logging es la funcionalidad de guardar en alg´un medio, archivos o base de datos, informaci´on sobre lo que est´a sucediendo en el sistema.
2.4 Ejemplo
Veamos ahora un ejemplo que clarifique lo descrito. Supongamos que tenemos un sistema de compras on-line (ver Figura 1) al cu´al se le desea agregar las siguientes funcionalidades:
• Lista de los art´ıculos m´as visitados del sistema.
• Lista de los art´ıculos m´as comprados del sistema.
Figura 1: Ejemplo de Sistema de Compras Online. Diagrama de Clases
Una posible soluci´on orientada a objetos consiste en crear una claseLogque sea la responsable de obtener la informaci´on necesaria para cumplir estos requisitos. Pero esto requerir´a modificaciones en las clasesCarroCompras eItemque tendr´an que hacer referencia a la nueva clase creada. Como vemos, esta funcionalidad de logging se dispersa por diversas clases (CarroCompraseItem) y genera un problema a la reutilizaci´on y encapsulamiento de las mismas.
La soluci´on en orientaci´on a aspectos simplifica este problema. Primero, creamos los puntos de enlace (Join-Point) que tendr´a el aspecto. En este caso ser´an los m´etodos:
CarroCompras.compra() Item.visita(idItem)
Con esto, en cualquier parte del programa en que se haga referencia a estos m´etodos se ejecutar´a el aspecto. Luego generamos el Pointcut para cada funcionalidad.
pointcut visitados() : call(Item Item.visita(idItem)) pointcut comprados() : call(bool CarroCompras.compra()) Ahora insertamos el comportamiento que deben tener las funcionalidades, esto es, elAdvice.
after() : visitados() {
//hacer logging de los items visitados que actualiza los contadores }
after() : comprados() {
//hacer logging de los items comprados que actualiza los contadores }
Finalmente lo encapsulamos todo dentro del aspecto.
aspect Logging {
pointcut visitados() : call(Item Item.visita(idItem)) pointcut comprados() : call(bool CarroCompras.compra()) after() : visitados()
{
//hacer logging de los items visitados que actualiza los contadores }
after() : comprados() {
//hacer logging de los items comprados que actualiza los contadores }
}
Como vemos, ahora cualquier cambio referente a loggingpodr´a hacerse directamente en el aspecto y no se tendr´a que buscar en las clases para verificar si implementan o no dicha funcionalidad. Adem´as, las clasesCarroCompras eItemno son afectadas con comportamientos externos a su funcionalidad y por tanto mantienen su cohesi´on.
3 Patr´on: Control de Pol´ıticas
3.1 Intenci´on
Aplicar las pol´ıticas de seguridad para controlar el acceso a funcionalidades de la aplicaci´on y manipular accesos indebidos.
3.2 Aplicabilidad
Se tiene un Sistema existente de Control de Pacientes en un hospital, al cual se le debe dar seguridad. Algunas de las caracter´ısticas deseadas son:
• Se desea que s´olo el m´edico del paciente pueda ver su historial.
• Las b´usquedas por pacientes inexistentes o pacientes de otros m´edicos deben ser registradas por auditor´ıa.
• En el acceso del m´edico al sistema, no puede equivocarse m´as de 3 veces al poner su contrase˜na.
• S´olo el usuario registrado como contacto del paciente puede accesar a la funcionalidad de ver ubicaci´on del paciente.
Para solucionar estos requerimientos, se propone modificar el sistema colocando funcionalidad transversal en los m´etodos afectados, como se ve en la Figura 2, de forma que:
• El m´etodoverHistorialPacientede la claseMedicoes interceptado en el aspectoControlPoliticas para verificar si el paciente corresponde al m´edico que hace la consulta, o no existe.
• El m´etodoingresaes interceptado en el aspectoControlPoliticaspara realizar el conteo de las veces que el m´edico ingresa una contrase˜na err´onea.
• El m´etodoverUbicacionPacientede la claseContactoes interceptado en el aspectoControlPoliticas para verificar si el contacto est´a registrado como contacto del paciente.
3.3 Estructura de soluci´on
Para permitir un adecuado control de pol´ıticas mediante el uso de un aspecto que intercepte los m´etodos a los que se desea aplicar alguna pol´ıtica, puede usarse una estructura como la mostrada en la Figura 3. Las clases que intervienen en la soluci´on son detalladas a continuaci´on.
• Rol: Representa la funci´on que desempe˜na el usuario dentro del sistema.
• Pol´ıtica: Son reglas de seguridad, como errores de usuario y permisos para acceder a funcionalidades. Las pol´ıticas van de acuerdo al rol.
Figura 2: Escenario de ejemplo. Patr´on de Control de Pol´ıticas.
Figura 3: Estructura de soluci´on. Patr´on de Control de Pol´ıticas.
• Valor: Guarda valores que ser´an usados en el control de seguridad de la aplicaci´on.
• Sesi´on: Mantiene el estado de seguridad general. Es un repositorio de valores y pol´ıticas.
La interacci´on dentro del aspecto de control de pol´ıticas es esquematizado en la Figura 4. Cuando el control de pol´ıticas es llamado, se verifica si el funcionamiento es adecuado al rol obteniendo los valores actuales (n´umero actual de intentos de ingreso) compar´andolo con el valor de la pol´ıtica (n´umero m´aximo de intentos de ingreso permitidos).
En caso de no ser un funcionamiento adecuado se ejecutar´a el efecto de la pol´ıtica(registro en el log).
Figura 4: Interacci´on de las clases de la soluci´on. Patr´on de Control de Pol´ıticas.
3.4 Consecuencias
• Las validaciones de acceso y uso de funcionalidades del sistema quedan encapsulados en el aspecto y no disper- sos en las clases que contienen esas funcionalidades.
• Este patr´on puede ser aplicado en sistemas existente sin un esquema de seguridad apropiado.
• Facilita la incorporaci´on o modificaci´on de pol´ıticas de seguridad debido al encapsulamiento de las mismas en el aspecto.
3.5 Patrones relacionados
• Roles[6]: Este patr´on indica que se debe agrupar a los usuarios seg´un similaridad en los priviliegios de seguridad que tienen. La claseRolimplementada dentro del aspecto, sigue este patr´on, pues en base al rol las pol´ıticas deber´an ser cargadas.
• Check Point[6]: La idea es restringir a los usuarios el acceso s´olo a las funcionalidades del sistema para las que tienen permiso. Esa es exactamente la idea de una pol´ıtica, restringir las acciones del usuario a s´olo aquellas que tiene permiso de ejecutar.
• Role Based Access Control[4]: Describe la relaci´on entre los conceptos de usuario, grupo y rol. Es decir un usuario pertenece a uno o m´as grupos y cumple uno o m´as roles. El rol puede estar asociado tanto al grupo como al usuario directamente.
4 Patr´on: Interfaz Segura
4.1 Intenci´on
Proporcionar seguridad en la comunicaci´on de las interfaces de la aplicaci´on con otros sistemas.
4.2 Aplicabilidad
Existen dos escenarios posibles en que una aplicaci´on puede interactuar con otras, el primer caso se da cuando un sistema ofrece servicios y el otro caso cuando el sistema utiliza servicios de otro sistema.
4.2.1 Escenario 1: La aplicaci´on ofrece servicios
En este escenario la aplicaci´on provee servicios que ser´an accesados por otros sistemas. Tenemos un sistema de cuentas corrientes de un banco que ser´a accesado por un cajero autom´atico. Se desea encapsular las caracter´ısticas propias de la seguridad en la comunicaci´on y encriptar los datos privados de la cuenta a ser enviados por la red. El primer paso para la soluci´on consiste en generar interfaces para los servicios provistos(InterfazCuentaCorriente). Ver Figura 5.
En el segundo paso se coloca la capa de Interfaz Segura en las implementaciones de las interfaces generadas en el paso anterior. En esta capa se interceptan los metodos que implementan la interfaz a˜nadi´endole seguridad a la comunicaci´on (encriptaci´on, auditor´ıa, etc.). Ver Figura 6.
Figura 5: Generaci´on de Interfaces de los servicios provistos. Patr´on de Interfaz Segura.
Figura 6: Capa de Interfaz Segura. Patr´on de Interfaz Segura.
4.2.2 Escenario 2: La aplicaci´on accesa servicios externos
Un sistema externo ofrece servicios a trav´es de una interfaz que, por definici´on, no tiene implementaci´on. En el primer paso se crea una clase por cada interfaz ofrecida que delega las requisiciones al sistema externo. Estas clases se pueden ver en la Figura 7 y tendr´an los mismos m´etodos que la interfaz a la cual delegan sus llamadas.
El segundo paso es equivalente al del escenario 1, interceptando los m´etodos de las clases generadas en el paso anterior.
Figura 7: Clases que delegan las requisiciones a las interfaces del sistema externo. Patr´on de Interfaz Segura.
4.3 Estructura de soluci´on
El aspecto Interfaz Segura ser´a implementado como un patr´on decorator [1]. La inicializaci´on de este patr´on, consiste en asignar a cada m´etodo a ser interceptado los mecanismos de seguridad que le corresponden. En este caso, los mecanismos de seguridad ser´an los decoradores concretos mostrados en la Figura 8. El m´etodo operacionde la clase InterfazSegura iterar´a sobre la lista de decoradores asociados al m´etodo interceptado, llamando al m´etodo ejecutaen cada uno de ellos.
Figura 8: Estructura de Soluci´on. Patr´on de Interfaz Segura.
4.4 Consecuencias
• El aspecto Interfaz Segura puede ser reutilizado para cualquier control adicional en la comunicaci´on con otro sistema.
• Se puede a˜nadir de forma din´amica distintos tipos de controles en la comunicaci´on (Patr´on Decorator), y por tanto es f´acilmente extendible.
• El aspecto de seguridad en la comunicaci´on queda encapsulado, lo que permite identificar f´acilmente los meca- nismos que est´an siendo usados en el control de la comunicaci´on con sistemas externos.
• La forma de aplicar este patr´on para sistemas que usan y/o proveen servicios ser´a similar, pudi´endose aprovechar la estructura interna del aspecto.
• Si el sistema contiene alg´un mecanismo de seguridad implementado, la inserci´on de este patr´on se hace dif´ıcil puesto que tendr´a que extraerse la seguridad para encapsularla en el aspecto. Si el sistema, en cambio, no contiene mecanismos de seguridad en la comunicaci´on, la aplicaci´on del patr´on ser´a relativamente simple.
4.5 Patrones relacionados
• Enterprise Partner Communication[5]: Patr´on gerencial que especifica las caracter´ısticas que deben ser con- templadas para realizar una comunicaci´on con sistemas de otras compa˜n´ıas. Complementa a Interfaz Segura, pues permite seleccionar las caracter´ısticas a implementar como decoradores en el aspecto.
• Secure Access Layer[6]: Consiste en la creaci´on de una capa alrededor de la aplicaci´on que se encarga de la comunicaci´on con aplicaciones externas. El c´odigo de uso de esta capa a´un sigue disperso por la aplicaci´on, pero la funcionalidad propia de comunicaci´on externa est´a en dicha capa.
5 Conclusiones y Trabajos Futuros
• La programaci´on orientada a aspectos permite encapsular las funcionalidades transversales a la aplicaci´on. Esto permite aumentar la cohesi´on en las clases.
• La seguridad de sistemas de software es una funcionalidad transversal. Puede ser extra´ıda de la aplicaci´on hacia un aspecto d´andole cohesi´on al m´odulo de seguridad como tal.
• Frecuentemente las funcionalidades implementadas como aspectos pueden ser f´acilmente habilitadas o desha- bilitadas pues la aplicaci´on no necesita saber que est´a siendo aspectada. Esta propiedad puede ser de ayuda en periodos de prueba, en que algunas caracter´ısticas no est´an disponibles, alg´un servidor de autenticaci´on por ejemplo.
• Hacer implementaciones est´andar para los patrones de modo que puedan convertirse en un framework orientado a aspectos extensible y f´acilmente enlazable a gran variedad de aplicaciones.
Referˆencias
[1] R. Johnson E. Gamma, R. Helm and R. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Adisson Wesley, 1995.
[2] Tzilla Elrad, Robert E. Filman, and Atef Bader. Aspect-oriented programming: Introduction. Commun. ACM, 44(10):29–32, 2001.
[3] Gregor Kiczales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jeffrey Palm, and William Griswold. Getting started with AspectJ. Commun. ACM, 44(10):59–65, 2001.
[4] Razvan Peteanu. Best practices for secure development v4.03. Technical report, Razvan Peteanu, 2001.
[5] S. Romanosky. Enterprise Security Patterns. In Proceedings of the 7th European Conference on Pattern Languages of Programs (EuroPLoP) 2002, Irsee, Germany, 2002.
[6] J. Yoder and J. Barcalow. Architectural patterns for enabling application security. In Proceedings of the 4th Conference on Patterns Language of Programming (PLoP´97), volume 2, 1997.
