La mayoría de nosotros ha visitado 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 de que terminemos en la piscina o entremos a la lavandería por una razón muy importante: nos asignaron un rol al llegar.
¿Sabes qué es el Control de Acceso Basado en Roles o RBAC?
En el campo de la informática también, desde sus inicios, todo esto se ha tenido en cuenta, pero recordemos que las primeras máquinas eran sumamente costosas y limitadas, así que tuvimos que conformarnos con recursos más simples y sencillos antes de que llegara el Control de Acceso Basado en Roles (en inglés RBAC).
Lista de control de acceso
En el año 1965 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 Wikipedia por 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 y de la que ya os hablé en un anterior artículo en este mismo blog.
Pero volvamos a la lista de control de acceso: ¿Qué es un control de acceso (access control)? Esto es lo más sencillo de explicar, es, nada más y nada menos, que una simple restricción a un usuario respecto a 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, se vuelve tedioso, estar pendiente de anotar uno por uno a los usuarios y también de los procesos propios de sistema operativo o de los programas que se ejecuten sobre él… Ya veis, 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 llegué a trabajar, el siglo pasado, 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. Considero que he resumido muchísimo y debería 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í ahorrar trabajo manteniendo al día las listas de acceso. Ahora imaginad que tenemos una, o más listas de control de acceso, que sólo admiten grupos. Pues bien, en 1997 un señor llamado John Barkley demostró que este tipo de listas equivale a 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
El concepto de rol en la RBAC va más allá de los permisos, también pueden ser unas habilidades bien delimitadas. Además, se pueden tener varios roles asignados, según sea la necesidad del protagonista (usuario, software, hardware…). Volviendo al ejemplo del departamento de cobro. Un vendedor, que ya tiene un rol correspondiente como tal, también podría tener un rol en cobro 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, 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, adquirid más recursos.
• Regulaciones federales, estatales, 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 puede crecer de manera vertiginosa. Si una empresa tiene 5 departamentos y 20 funciones podemos 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.
• 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:
1. Asignación de roles: Una persona puede ejercer un permiso sólo si se le ha asignado un rol.
2. 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.
3. Autorización de permisos: Una persona puede ejercer un permiso sólo 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, aunque 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!
Programmer since 1993 at KS7000.net.ve (since 2014 free software solutions for commercial pharmacies in Venezuela). He writes regularly for Pandora FMS and offers advice on the forum . He is also an enthusiastic contributor to Wikipedia and Wikidata. He crushes iron in gyms and when he can, he also exercises cycling. Science fiction fan. Programmer since 1993 in KS7000.net.ve (since 2014 free software solutions for commercial pharmacies in Venezuela). He writes regularly for Pandora FMS and offers advice in the forum. Also an enthusiastic contributor to Wikipedia and Wikidata. He crusher of irons in gyms and when he can he exercises in cycling as well. Science fiction fan.