La mayoría de nosotros ha visitado (o incluso pernoctado) en un hotel alguna vez en su vida. Llegamos a recepción, si solicitamos habitación nos entregan una llave, si vamos a visitar un huésped nos conducen a la sala de espera como visitante, si vamos a usar su restaurante nos etiquetan como comensal o si asistimos a una conferencia sobre tecnología vamos a su salón principal. No se da el caso que terminemos en la piscina o entremos a la lavandería por una razón muy importante: nos asignaron un rol al llegar.
Las empleadas de un hotel desconocen quién llegará: ya sea el rey de una nación rica en petróleo o un futuro compañero de trabajo, sea quien sea habrá un rol a desempeñar dentro de la empresa una vez ponga un pie dentro de ella. Por supuesto que al menos diferenciamos dos grandes roles: cliente o empleado pero a partir de allí comienzan muchas combinaciones… ¡Puede darse el caso de un empleado a quien se le haya inundado su casa y deba quedarse unos días en su propio lugar de trabajo!
En el campo de la informática también desde sus propios inicios todo esto se ha tenido en cuenta, pero recordemos que las primeras máquinas (¡y que me lo pregunten a mí!) eran sumamente costosas y limitadas en recursos, así que tuvimos que conformarmos con recursos más simples y sencillos antes de llegar al Control de Acceso Basado en Roles (en inglés RBAC).
Lista de control de acceso
En el año 1965, dice la Wikipedia, existió un sistema operativo de tiempo compartido llamado Multics (creación de los Laboratorios Bell y el Instituto Tecnológico de Massachusetts) el cual fue el primero en utilizar access-control list (ACL). Yo ni siquiera había nacido en esa época así que doy un voto de confianza a esta información. Lo que sí conozco de primera mano es la lista de control de acceso a sistema de ficheros (en inglés filesystem ACL) que usaba Netware Novell® a principios de 1990, como os hablé en un anterior artículo en este mismo blog.
Pero bajemos la velocidad un momento y volvamos a la lista de control de acceso, e incluso vayamos más atrás: ¿Qué es un control de acceso (access control)? Esto es lo más sencillo de explicar y es no más que una simple restricción a un usuario para con un recurso, ya sea por medio de una contraseña, una llave física o incluso sus valores biométricos, como la huella digital, por ejemplo.
Una lista de control de acceso entonces es anotar a cada uno de los usuarios que pueden acceder (explícitamente permitido) o no (explícitamente prohibido, bajo ningún aspecto). Como ya imagináis esto, primero, se vuelve tedioso de estar pendiente de anotar uno por uno a los usuarios (por ejemplo a directorios y ficheros, uno por uno también) y, segundo, estar pendientes también de los procesos propios de sistema operativo o de los programas que se ejecuten sobre él. Vaya lío anotar todas las entradas, conocidas en inglés como access-control entries (ACEs) .
Siguiendo el ejemplo de derechos sobre ficheros, directorios y más allá (tales como recursos completos: discos ópticos o «disco duros» enteros) fue que me tocó trabajar el siglo pasado como os dije, con Netware Novell®: esto es un Filesystem ACL (Network File System access-control list).
Luego vino, superado el susto del milenio, el NFS ACL versión 4 que recogió y amplió, de manera normalizada, todo lo que habíamos usado desde 1989 cuando el RFC 1094 estableció el Network File System Protocol Specification. Todo esto lo he resumido muchísimo y debo nombrar, al menos, el uso que le da MS Windows® a las ACL por medio de su Active Directory (AD), las Networking ACL para los casos de hardware de red (enrutadores, concentradores, etc.) y las implementaciones que hacen algunas bases de datos.
Todas estas tecnologías, y más, echan mano del concepto de listas de control de acceso, y como todo en la vida evoluciona pues surgió el concepto de grupos que compartían algunas similitudes y se podía así abreviar trabajo en mantener al día las listas de acceso. Esto no es más que el reflejo de las empresas: así existe el departamento de cobranzas y el departamento de programadores -por ejemplo- pues ya se presupone a cuáles recursos pueden acceder quienes sean asignados a alguno de estos grupos.
Ahora imaginad que tenemos una o más listas de control de acceso que solamente admiten grupos: pues bien, en 1997 un señor llamado John Barkley (muy inteligente él porque yo llevaba varios años trabajando con eso y ni siquiera lo había imaginado) demostró que este tipo de listas equivalen un mínimo Control de Acceso Basado en Roles, pero RBAC al fin y al cabo, lo cual nos lleva al meollo del asunto…
Role-based access control RBAC
Os digo para comenzar que el concepto de rol en la RBAC va más allá de los permisos: también pueden ser unas habilidades bien demarcadas. Además, se pueden tener varios roles asignados, según sea la necesidad del protagonista (usuario, software, hardware…). Volviendo al ejemplo del departamento de cobranzas, a un vendedor (que ya tiene un rol correspondiente como tal) también podría tener un rol en cobranzas para analizar el pago de los clientes y enfocar sus ventas en los solventes. Con los roles esto es relativamente sencillo de hacer.
Beneficios de RBAC
- Primero que nada, RBAC disminuye muchísimo los riesgos de brecha de seguridad y fugas de datos: si los roles fueron creados y asignados con rigor (ver reglas más adelante) está garantizado el retorno de la inversión del trabajo realizado en RBAC.
- Reduce costos al asignar más de un rol a un usuario: es innecesario comprar ordenadores virtuales nuevos si pueden compartir con grupos ya creados. Dejad que Pandora FMS monitorice y os proporcione información para tomar decisiones acerca de redistribuir la carga horaria o, llegado el caso y solo de ser necesario, adquirir más recursos.
- Regulaciones federales, estatales, estadales o locales sobre privacidad o confidencialidad pueden ser exigidas a las empresas y las RBAC pueden ser una gran ayuda para cumplir y hacer cumplir dichas exigencias.
- Las RBAC no solamente ayudan a la eficiencia en las empresas cuando se contratan nuevos empleados: también ayudan cuando terceros realizan trabajos de seguridad, auditorías, etc. porque de antemano y sin conocer realmente quién o quiénes vendrán, ya tendrán su espacio de trabajo bien delimitado en uno o varios roles combinados.
Desventajas de RBAC
- El número de roles pueden crecer de manera vertiginosa: si una empresa tiene 5 departamentos y 20 funciones pudiéramos tener hasta un máximo de 100 roles.
- Complejidad: tal vez sea esto lo más difícil, identificar y asignar todos los mecanismos establecidos en la empresa y traducirlos en RBAC. Esto requiere de mucha labor por hacer.
- Cuando un sujeto necesita ampliar sus permisos de manera temporal, las RABC pueden convertirse en una cadena difícil de romper. Para esto Pandora FMS propone una alternativa que explico en la siguiente sección.
Reglas de RBAC
Para aprovechar al máximo las ventajas del modelo RBAC, el desarrollo del concepto de roles y autorizaciones es siempre lo primero. Es importante que el manejo de identidades para poder asignar estos roles sea hecho también de una manera estandarizada, para ello la norma ISO/IEC 24760-1 del año 2011 intenta lidiar con ello.
Hay tres reglas de oro para las RBAC que deben ser vistas ordenadas en el tiempo y aplicadas en su debido momento:
- Asignación de roles: Una persona puede ejercer un permiso solo si se le ha asignado un rol.
- Autorización de roles: El rol activo de una persona debe estar autorizado para esa persona. Junto con la regla número uno, esta regla garantiza que los usuarios solo pueden asumir los roles para los que están autorizados.
- Autorización de permisos: Una persona puede ejercer un permiso solo si el permiso está autorizado para el rol activo del sujeto. Junto con las reglas uno y dos, esta regla garantiza que los usuarios sólo pueden ejercer los permisos para los que están autorizados.
La versión Enterprise de Pandora FMS dispone de un RBAC ultra completo y de mecanismos de autenticación como LDAP o AD, además de mecanismos de doble autenticación con Google® Auth. Además, con el sistema de etiquetas o tags que maneja Pandora FMS podemos combinar RBAC con ABAC: el attribute-based access control es similar al RBAC pero en vez de roles está basado en atributos del usuario (en este caso, etiquetas asignadas pero pudieran ser otros valores como ubicación o años de experiencia dentro de la empresa, por ejemplo).
Pero eso, eso queda para otro artículo…
Antes de despedirnos, recuerda que Pandora FMS es un software de monitorización flexible, capaz de monitorizar dispositivos, infraestructuras, aplicaciones, servicios y procesos de negocio.
¿Quieres conocer mejor qué es lo que Pandora FMS puede ofrecerte? Descúbrelo entrando aquí: https://pandorafms.com/es
Si cuentas con más de 100 dispositivos para monitorizar puedes contactar con nosotros a través del siguiente formulario: https://pandorafms.com/es/contactar/
Además, recuerda que si tus necesidades de monitorización son más limitadas tienes a tu disposición la versión OpenSource de Pandora FMS. Encuentra más información aquí: https://pandorafms.org/es/
No dudes en enviar tus consultas. ¡El equipazo de Pandora FMS estará encantado de atenderte!