Conceptos que utiliza sin saberlo: Control de acceso basado en roles

Bienvenido a nuestra nueva serie sobre conceptos y funciones técnicas que probablemente utilizas a diario sin saberlo. Con esta serie queremos que entiendas mejor cómo afectan estos conceptos a tu día a día y cómo sacar el máximo partido a las herramientas que tienes a tu disposición.

Nuestro primer artículo trata sobre el control de acceso basado en roles, una forma comúnmente utilizada para gestionar los permisos de las aplicaciones y el acceso a los recursos de red en función del rol asignado a un usuario. También se conoce como seguridad basada en roles y es un concepto que todo administrador de sistemas debería comprender.

¿Qué es el control de acceso basado en funciones?

El control de acceso basado en roles surgió de la necesidad de gestionar listas de control de acceso cada vez más complejas entre un gran número de usuarios y recursos. Demos un paso atrás y veamos primero el control de acceso.

Por qué necesitamos el control de acceso

Por razones bastante obvias, los administradores de sistemas querrán limitar la capacidad de los usuarios de un sistema para realizar acciones en ese sistema. Cuando usamos la palabra usuarios, nos referimos tanto a usuarios humanos como a aplicaciones que actúan como usuarios de servicios.

El control de acceso actúa como una capa entre los usuarios y los sistemas, garantizando que los administradores de sistemas puedan establecer límites, sin restringir completamente la funcionalidad.

El control de acceso abarca toda una gama de sistemas: desde el acceso al sistema operativo y las aplicaciones hasta el acceso a redes específicas, tanto internas como externas. Y sí, como primer paso, el control de acceso nos dice si un usuario puede acceder a una aplicación, sistema o red - o si el acceso no está permitido para ese usuario.

El control de acceso también tiene que ver con el grado de acceso que se concede. En otras palabras, un usuario puede tener acceso completo a un sistema (lectura y escritura, por ejemplo), mientras que otro puede tener acceso restringido (sólo lectura, por ejemplo).

Todas estas preocupaciones son transversales al sistema operativo y al espacio de aplicación. Una aplicación individual que admita múltiples usuarios probablemente requerirá algún tipo de control sobre qué usuarios pueden realizar qué actividades (o dejará de ser útil muy rápidamente).

Necesidad de una gestión avanzada de los accesos

En los sistemas sencillos, una lista de control de acceso simple hará el trabajo, enumerando qué usuarios tienen qué tipo de acceso y dónde. Pero en el complejo entorno informático empresarial de hoy en día, las largas listas de criterios de control de acceso no funcionan, sobre todo teniendo en cuenta la naturaleza integrada de los sistemas y la forma en que los permisos en un lugar también requieren permiso para propagarse a otros lugares.

En esencia, RBAC es una capa de abstracción que separa los permisos de los usuarios introduciendo el concepto de "roles", que también se conocen como "grupos". Este cambio aparentemente pequeño permite una mayor flexibilidad y un control granular de los permisos. En cierto modo, el control de acceso basado en roles añade cierta sobrecarga administrativa, pero si se observa el panorama en su conjunto, RBAC simplifica mucho la gestión de accesos, sobre todo en entornos más complejos.

¿Qué es un papel?

Los roles son fundamentales en RBAC. Al igual que los usuarios, un rol puede referirse a la función de un individuo en la organización y, por lo tanto, a los permisos de sistemas necesarios para desempeñar esa función. Los roles también pueden asignarse a objetos inanimados, como aplicaciones o servicios que se ejecutan en un servidor.

En lo que respecta al control de acceso, un rol específico definirá un conjunto concreto de permisos. Por ejemplo, un "editor" podrá leer y editar artículos en un sitio web, pero no podrá cambiar la configuración del sitio ni eliminar artículos, para lo que necesitará un rol de "administrador".

Mediante el uso de roles, los administradores de sistemas pueden garantizar que las personas que necesitan derechos de acceso específicos para hacer su trabajo tengan esos derechos de acuerdo con una plantilla establecida, según lo definido por el rol. Cuando un nuevo redactor se incorpora a la empresa, por ejemplo, un administrador de sistemas puede simplemente asignarle el rol estándar de redactor sin necesidad de configurar manualmente los permisos del nuevo miembro del personal.

Visto de otro modo, los empleados junior -incluidos, por ejemplo, los administradores de sistemas junior- tendrían menos derechos de acceso a los sistemas de una empresa. Los empleados junior sólo tendrán acceso a un subconjunto de la información de una empresa, y los administradores de sistemas junior tendrán permiso para hacer algunos cambios en los sistemas, pero no todos.

Además, los roles relacionan los permisos con los recursos. Así, un rol puede vincular ciertos permisos a recursos específicos. Por ejemplo, alguien que trabaja en la oficina de Nueva York puede acceder a los recursos basados en la nube relacionados con la oficina de Nueva York en función de su rol de Nueva York. La misma persona no puede acceder a los recursos de San Francisco a menos que su rol se amplíe debido a su implicación en un proyecto en San Francisco.

Los roles pueden utilizarse de formas increíblemente flexibles. Por ejemplo, la composición de roles es cuando a un individuo se le asignan múltiples roles, heredando los permisos de todos los roles. La composición puede producirse de forma bastante natural, ya que a los usuarios se les asignan funciones que coinciden con su posición, a veces compleja, dentro de una organización.

RBAC: control de acceso mediante roles

Así pues, como sugiere el acrónimo, RBAC aplica un control de acceso basado en el rol o, de hecho, en múltiples roles asignados a un usuario. Es una mejora de las listas de control de acceso estándar y, por supuesto, RBAC es sólo un modelo de control de acceso.

Existe una alternativa en el llamado control de acceso basado en atributos (ABAC), que evolucionó a partir del RBAC. El ABAC concede el acceso en función de los atributos del sujeto (usuario) y del recurso al que se accede, así como de algunos otros elementos, como la acción requerida y el entorno en el que se realiza la solicitud.

Cómo determinar si su sistema utiliza RBAC

La mayoría de las aplicaciones que admiten múltiples usuarios tendrán algún tipo de control para especificar qué usuarios pueden hacer qué. Si una aplicación o sistema hace referencia a grupos y si los usuarios se añaden a un grupo en lugar de asignárseles permisos individualmente, entonces esa aplicación o sistema utiliza RBAC. Esencialmente, busca palabras como grupos y roles y probablemente estés en tecnología RBAC.

Ejemplos prácticos de control de acceso basado en funciones

El control de acceso basado en roles es increíblemente común. Es fácil de usar y fácil de implementar, y lo encontrarás integrado en tus soluciones tecnológicas, desde el nivel de sistema operativo hasta las aplicaciones y servicios cotidianos que utilizas. En esta sección veremos algunos ejemplos comunes de RBAC.

A un nivel sencillo, consideremos un sistema de gestión de contenidos. En este caso, los usuarios deben poder gestionar el contenido: crear y editar artículos, borrar artículos y editar la estructura del sitio. El rol de autor, por ejemplo, podría incluir la capacidad de crear y editar artículos, pero no de borrarlos.

Los trabajadores con un rol de editor podrían editar y borrar artículos - pero no modificar la estructura del sitio. El rol de administrador, por su parte, tendría todos los permisos: crear, editar y borrar artículos, así como la capacidad de modificar la estructura y la configuración del sitio.

El RBAC también se utiliza habitualmente como control de acceso a los datos. Pensemos, por ejemplo, en los datos médicos, donde determinados miembros del personal médico con funciones específicas tienen acceso a los datos de los pacientes, mientras que otros miembros del personal sólo pueden ver un subconjunto de los datos o sólo los datos de los pacientes que están consultando.

Pasando al mundo de la tecnología, Kubernetes, la solución de contenedorización más utilizada, utiliza RBAC para garantizar que tanto los usuarios humanos como las aplicaciones tengan el nivel adecuado de acceso a contenedores individuales y grupos de contenedores.

RBAC también desempeña un papel muy importante en plataformas en la nube como Azure de Microsoft, donde RBAC regula el acceso a los recursos de Azure y a las aplicaciones que se ejecutan en esos recursos.

Ventajas de utilizar RBAC

¿Por qué utilizar RBAC en lugar de una simple ACL? Hemos insinuado algunas de las ventajas, pero echemos un vistazo más de cerca a las ventajas que hacen de RBAC una forma tan común de hacer cumplir los permisos.

Eficacia operativa

Aunque técnicamente las ACL pueden hacer el trabajo, las ACL rápidamente se vuelven engorrosas y eventualmente inviables a medida que aumenta la complejidad de los permisos. Sin embargo, incluso con cargas de trabajo más simples, RBAC simplemente hace un mejor trabajo de gestión de permisos, ya que las reglas no necesitan establecerse usuario por usuario.

Por ejemplo, con una ACL, si quieres permitir que todos los usuarios impriman en una impresora específica, este cambio tendría que hacerse en cada usuario individual. Con RBAC, basta con añadir la impresora al grupo correspondiente.

Lo anterior es sólo un ejemplo sencillo: cuando se implanta RBAC en grandes sistemas complejos, la eficacia operativa aumenta realmente. De hecho, las organizaciones muy grandes simplemente no pueden funcionar sin RBAC - depender de ACLs sería simplemente inviable.

Integración con otros servicios

RBAC, con su catálogo de usuarios, roles y permisos, también puede actuar como plataforma para una base de datos de permisos, o servicio de directorio. Esto significa que un sistema de control de acceso basado en RBAC puede integrarse fácilmente en diferentes servicios.

En otras palabras, las funciones y los permisos de los usuarios pueden recuperarse uno a uno o incluso exportarse al por mayor para luego aplicarse a un sistema completamente independiente, lo que significa que RBAC ofrece muchas oportunidades de integración entre sistemas.

Mayor control y cumplimiento

Cuando se utiliza RBAC, el administrador puede aplicar un control más granular y frecuente sobre los permisos. Los permisos también pueden gestionarse de forma más flexible, lo que significa que la administración puede ejercer un control más estricto sobre los permisos.

Especialmente en las implantaciones a gran escala, los permisos pueden volverse bastante "laxos" y "excesivos" con el tiempo. RBAC, por lo tanto, ayuda a restringir el acceso, lo que mejora el cumplimiento tanto de las normas y políticas de la organización como del entorno de cumplimiento más amplio. Las normas pueden ajustarse estrechamente a los requisitos de cumplimiento y son más fáciles de modificar en caso de que cambie la normativa.

Auditoría y visibilidad

En el caso de las aplicaciones a escala empresarial, lo más probable es que RBAC también mantenga sofisticados registros de acceso para ayudar a los administradores a entender qué acceso se concedió a quién, por quién fue concedido y cuándo se concedió.

Proporciona una visibilidad significativamente mayor de cómo se accede a los sistemas y quién accede a ellos. Además, las soluciones que utilizan RBAC también deben ser capaces de exportar informes que ofrezcan a los administradores de sistemas una visión clara de qué usuarios tienen qué tipo de permisos.

Desventajas del uso de RBAC

Como ocurre con cualquier enfoque en tecnología de la información, el uso de RBAC presenta algunas desventajas. En primer lugar, existe el "coste" inicial de tener que seleccionar roles para los usuarios cuando se añade un usuario. Sin embargo, dada la facilidad con la que RBAC permite propagar permisos basados en roles para ese usuario en el futuro, puede considerarse un coste relativamente mínimo. Por lo general, esto se soluciona mediante algún tipo de integración con una lista empresarial ya establecida o un servicio centralizado de gestión de identidades.

Un problema con RBAC puede ser algo llamado explosión de roles - a medida que se crean más y más roles para acomodar un número creciente de roles en la organización y para dar cuenta de roles cada vez más complejos dentro de la organización. Esto puede conducir a una gran complejidad que puede ser difícil de gestionar.

Establecer estructuras de roles RBAC también puede llevar bastante tiempo y ser complejo. Además, a medida que una organización cambia, esta estructura también cambiará, lo que puede significar que la estructura de roles deba revisarse cada pocos años.

Por estas razones, algunas personas ven ABAC como una alternativa mejorada que se adapta mejor a entornos de acceso y permisos muy complejos.

Configuración de RBAC

Una forma de superar algunos de los inconvenientes de RBAC es comenzar con una configuración RBAC bien estructurada. Aquí tienes algunos consejos que te ayudarán en el camino:

• Empiece por catalogar a fondo. Antes de empezar a pensar en las funciones, asegúrate de saber exactamente para qué sistemas estás intentando establecer permisos. Piensa desde las redes hasta las distintas bases de datos de tu organización. Es importante saber a qué se intenta controlar el acceso antes de diseñar el sistema de control de acceso.
• Analice su plantilla. Examine detenidamente su plantilla e intente identificar funciones claras, e incluso funciones que se solapen. Al hacerlo, debe equilibrar cuidadosamente la creación de suficientes funciones para que su estructura de permisos sea lo suficientemente granular, pero no tantas que anule los beneficios de RBAC mediante el uso de demasiadas funciones.
• Haz que tus compañeros se impliquen. A continuación, establezca el acceso de sus trabajadores en función de sus responsabilidades cotidianas, asociando estas responsabilidades a las funciones. También merece la pena impartir cierta formación a tus compañeros, sobre todo a los que desempeñan funciones tecnológicas, para que comprendan los conceptos básicos de RBAC.
• Gestión del cambio. Hacer frente a los cambios de funciones es uno de los aspectos más difíciles de RBAC. Cuando planifique su sistema RBAC, prevea cómo pueden cambiar las funciones en el futuro y realice auditorías periódicas para asegurarse de que las funciones y los permisos que ha configurado siguen ajustándose a la realidad sobre el terreno.

En esencia, un poco de previsión le ayudará a sacar el máximo partido de RBAC y minimizar los cambios y el mantenimiento que tenga que hacer en el futuro.

Conclusión

RBAC es una de las formas de gestionar usuarios y permisos en sus aplicaciones y sistemas. Los conceptos de alto nivel implicados en RBAC, incluidos los usuarios y grupos, así como las reglas y políticas, son transversales a los temas tecnológicos.

Merece la pena entender cuál es el propósito de cada uno de estos conceptos transversales y cómo funcionan en otras áreas del campo de las TI. Como profesionales de las TI, comprender los fundamentos nos ayuda a tratar de forma más competente los temas más complejos.