Como respuesta al nivel de complejidad que las organizaciones están adquiriendo en cuanto al control de acceso a los distintos activos de información y en definitiva la gestión de su seguridad, ya hace años que se vienen implantando sistemas de control de acceso basados en roles, también conocidos como RBAC (Role Based Access Control). Estos sistemas cobran su máximo sentido en aplicaciones que sustentan procesos de negocio (ERP, ECM, etc).

RBAC difiere principalmente de los sistemas tradicionales basados en ACL’s –como MAC o DAC- en que su arquitectura está ideada para asignar permisos a operaciones más que a objetos concretos (ficheros, registros, etc). Siendo por tanto su principal ventaja el permitir alinear la infraestructura de seguridad de la información con los objetivos de negocio de una forma natural.

La arquitectura de los sistemas basados en roles se puede representar de la siguiente forma:

La idea consiste en la asignación de permisos (lectura, escritura, etc), sobre objetos o procesos, a los distintos roles ya existentes en la organización (Revisor, Editor, Calidad, Dirección, etc). De forma que posteriormente se asignen estos roles a los distintos usuarios según las responsabilidades que tienen que adoptar en cada momento (sesión).

Un ejemplo puede ser el típico flujo de trabajo –Workflow- que se genera en la aprobación de una factura de un proveedor en cualquier ERP o Sistema de Gestión Documental. En este caso, dicha factura pasará por distintos estados intermedios en los que distintos usuarios (Jefe de compras, Jefe de un departamento, etc.) con rol “Revisor” le darán el visto bueno hasta que finalmente sea aprobada por Dirección. Durante ese flujo dichos usuarios jugarán el Rol “Revisor” de forma consecutiva, pero una vez esté aprobada la factura para su pago, dichos usuarios adquieren el Rol “Lector”, que a diferencia del Rol anterior, solo nos dejará consultar la factura.

Como hemos visto en el ejemplo anterior, un sistema basado en roles nos ofrece muchas ventajas. Más aún si este está comandado por un motor Workflow o BPM.

Una de las ventajas más directas es la rápida asignación de permisos, ya que de forma indirecta cuando le asignas un Rol a un usuario también le estas asignando permisos. Esto facilita mucho la labor con nuevas incorporaciones, cambios estructurales en el organigrama, etc.

En cuanto a la seguridad, RBAC es un arma de doble filo. Si presumimos que la implementación a bajo nivel está bien realizada, la mayoría de los problemas de seguridad vienen dados por:

è  Una arquitectura mal ideada: Normalmente esto se explica por una mala interpretación de la organización, de sus responsabilidades y de sus procesos de negocio (Ej. Permisos de Roles mal establecidos).

è  Pruebas insuficientes o mal realizadas: En la mayoría de estos sistemas resulta muy tediosa la realización de pruebas debido a la gran cobertura de casos existentes (Usuarios – Roles – Permisos – Sesiones). Todo esto se ve además incrementado cuando además se complementa con un sistema Worklow/BPM.

La principal recomendación para la implementación segura de un sistema RBAC es por un lado, el establecimiento de un responsable (arquitecto del sistema) que tenga conocimientos muy amplios de la organización y sus procesos de negocio y por otro, establecer una metodología que nos permita la eficaz realización de pruebas de nuestro sistema (Nunca olvidemos que un rol con un permiso mal asignado se propaga inmediatamente a todos los usuarios de la organización con ese Rol).