[25/03/2022] El control de acceso basado en roles (o RBAC, por sus siglas en inglés) es un enfoque para restringir el acceso a los recursos digitales según el rol de un usuario en una organización. Por ejemplo, con el RBAC, el contador de una empresa podría acceder a los registros financieros corporativos, pero no al sistema de administración de contenidos utilizado para actualizar la página web de la empresa, mientras que esos permisos se invertirían para el equipo de desarrollo web de esa empresa.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
Prácticamente todas las organizaciones imponen algún tipo de control de acceso a sus activos digitales; de hecho, hoy en día todos los sistemas operativos en uso tienen controles de acceso integrados. Los controles de acceso generalmente otorgan permisos específicos (e imponen restricciones) a usuarios o grupos individuales a los que esos usuarios podrían pertenecer. Lo que distingue al modelo RBAC de otras formas de control de acceso es que los usuarios se agrupan en función de los roles que desempeñan y los permisos se determinan principalmente por esos roles, en lugar de adaptarse a cada usuario individual. En este artículo, aprenderá cómo funciona el RBAC y verá las ventajas y desventajas de este enfoque.
Cómo funciona el RBAC
El RBAC se basa, fundamentalmente, en lo que se conoce como el principio de privilegio mínimo, que esencialmente afirma que cualquier usuario debe tener acceso a los datos y la funcionalidad que necesita y nada más. Esto suena razonable en teoría, pero uno de los dilemas centrales cuando se implementan controles de acceso es cómo hacer que funcionen en la práctica: ¿cómo determina lo que los usuarios deberán hacer, y cómo aplica permisos y restricciones a todos sus usuarios de una manera que no implique una carga para los administradores?
El RBAC resuelve estos problemas en base a lo que hacen los usuarios en lugar de quiénes son. En lugar de establecer un conjunto de permisos a medida para cada usuario, en RBAC hay un conjunto limitado de roles predefinidos dentro de una organización, y cada usuario cumple uno (o más) de esos roles. Se adapta un conjunto de permisos para que cada rol satisfaga sus necesidades particulares y lo heredan todos los usuarios que cumplen ese rol. Si es necesario cambiar los permisos para un rol, esos cambios se transmiten de manera similar a los usuarios, lo que facilita la administración del sistema.
Los roles del RBAC
Los roles son, obviamente, el corazón de un control de acceso basado en roles. Pero es importante tener en cuenta que la definición de roles es un ejercicio administrativo y conceptual, no técnico. En lo que respecta a los sistemas subyacentes, cada uno de estos roles es solo un grupo de usuarios; depende de su organización definir cuál es la división lógica de roles para su personal y quién cae en cada categoría, y esta es una de las partes más importantes del proceso de implementación del RBAC.
Como tal, los roles pueden diferir mucho de una organización a otra. Dicho esto, la mayoría de las empresas establecerán roles basados de una forma u otra en su propia estructura organizativa interna. En su blog, UpGuard, firma proveedora de seguridad, brinda algunos ejemplos de roles desglosados de esta manera y las aplicaciones para las que tendrían permisos de acceso:
- Ingeniería de software: GCP, AWS y GitHub
- Marketing: HubSpot, Google Analytics, Facebook Ads y Google Ads
- Finanzas: Xero y ADP
- Recursos humanos: Lever y BambooHR
También es clave tener en cuenta que un usuario puede ser asignado a más de un rol. Por ejemplo, podría haber un rol de "empleado” de nivel básico al que todos en su organización estén asignados y que otorgue permiso para servicios de toda la organización, como aplicaciones de correo electrónico y calendario, además de los roles más especializados que ofrecen acceso a datos departamentales y aplicaciones. También puede haber un rol de "administrador” que brinde a ciertos usuarios un mayor acceso a algunos datos dentro de cada departamento.
La matriz RBAC
Una vez que haya definido sus roles, el siguiente paso en el proceso de planificación es averiguar qué derechos y restricciones se aplican a cada uno de esos roles. Una forma de planificar el juego es usar una matriz RBAC, que es una tabla en la que los roles forman las filas y varios objetos o acciones forman las columnas.
El método de arquitectura unificada de David W. Enstrom tiene un par de excelentes ejemplos de cómo podría verse una matriz RBAC. El primero es para un objeto de datos específico en su infraestructura. Las filas representan algunos roles abstractos que los usuarios pueden tener dentro de una organización, y las columnas representan las acciones que un usuario podría realizar potencialmente en ese objeto protegido. Si un rol tiene derecho a realizar una de las acciones, la celda donde se cruzan la columna y la fila se marca con una X.
| | Crear | Leer | Actualizar | Borrar | Ejecutar |
| Gerente | X | | | X | |
| Autor | X | X | X | X | |
| Editor | | X | X | | |
| Publicar | | X | X | | X |
Como puede ver, puede ser bastante granular en términos de lo que los usuarios con diferentes roles pueden y no pueden hacer con diferentes objetos. La siguiente tabla es quizás un poco menos abstracta. Las filas son roles definidos por títulos de trabajo, mientras que las columnas son objetos específicos con los que los usuarios con estos roles pueden interactuar. Cada celda incluye las letras de las acciones CLABE de la primera tabla: crear, leer, actualizar, eliminar, ejecutar (o CRUDE, por sus siglas en inglés), que describen lo que cada función puede hacer con cada objeto.
| | Pedido | Factura | Cliente | Empleado | Producto |
| Vicepresidente de ventas | CLAB | CLAB | CLAB | CLAB | CLAB |
| Gestión de ventas | CLABE | CLAB | LA | L | L |
| Representante de ventas | CLAB | L | LA | L | L |
| Gerente de stock | | | | L | LA |
Esto le da una idea de cómo el RBAC realmente puede ayudar a definir las capacidades de los usuarios individuales en la práctica. Los empleados de ventas de nivel superior pueden crear nuevas facturas, mientras que los de nivel inferior solo pueden leerlas. Un gerente de inventario especializado y el gerente general del departamento pueden actualizar los registros de productos, mientras que los empleados de nivel medio solo pueden leerlos.
Una vez más, la creación de estas matrices es un ejercicio que realizará independientemente de cualquier implementación técnica. El objetivo es capturar su estructura organizativa y las necesidades de acceso a los datos, que su RBAC terminará concretando.
Mejores prácticas de RBAC
Si desea profundizar en las mejores prácticas para implementar RBAC, puede consultar INCITS 359-2012, el estándar RBAC establecido por ANSI. Para una lectura más breve, MorganFranklin Consulting tiene una buena lista de mejores prácticas para considerar al iniciar su viaje. Algunos de sus consejos clave incluyen:
- Piense en el RBAC como un programa continuo, no como un proyecto. No espere que el conjunto inicial de roles y permisos que establezca sean inamovibles. Deberá modificarlos a medida que vea cómo funciona el RBAC en la práctica y a medida que su organización crezca y cambie.
- Limpiar datos incorrectos. Es difícil saber qué roles deberían tener acceso a qué datos si su estructura de datos en sí es confusa. Los datos limpios son un ingrediente principal de la receta para una implementación exitosa del programa RBAC.
- Asigne un propietario de rol para representar cada área desde el lado comercial. ¿Quién tiene el mejor "conocimiento interno” sobre cada departamento? Estas personas deben estar en el equipo que define los roles de su organización.
- Hacer que los papeles sean reutilizables. Si solo una persona en toda la organización tiene un rol particular, tal vez ese acceso no deba administrarse a través del RBAC. Una de las mayores trampas en RBAC es la "explosión de roles”, en la que se crean muchos roles cada vez más granulares para capturar todos los matices de las descripciones de trabajo de los diferentes empleados. Ir demasiado lejos en este camino conduce a un lugar donde termina con roles únicos para casi todos los empleados, lo que obviamente elimina muchos de los beneficios de RBAC. Desea mantener las cosas lo más simples posible para reducir la carga administrativa de TI.
Beneficios y desventajas del RBAC
Con suerte, en este punto, muchos de los beneficios del RBAC son claros. El modelo RBAC proporciona una manera para que las empresas apliquen el principio de privilegios mínimos, al tiempo que reducen la carga administrativa y el potencial de error que surgiría al personalizar los permisos para cada usuario individual. Restringir los permisos de esta manera puede evitar ataques internos y bloquear las cuentas comprometidas por atacantes externos para que no aumenten los privilegios.
Además, muchas normas de seguridad y protección de datos especifican qué puestos de trabajo dentro de una empresa deben y no deben tener acceso a datos confidenciales. Un programa RBAC documentado puede ayudar a las organizaciones a cumplir con estas leyes.
Dicho esto, el RBAC no es una panacea. Al leer la sección anterior sobre las matrices del RBAC, es posible que haya pensado que juntarlas sonaba como mucho trabajo, y estaría en lo cierto. Si bien el RBAC puede ahorrar una gran cantidad de trabajo administrativo, requiere bastante trabajo para aumentarlo, lo que puede no ser rentable a largo plazo, especialmente para las empresas más pequeñas. Por su parte, las grandes empresas con muchos departamentos separados pueden tener que establecer muchos roles diferentes, lo que significa que la complejidad del RBAC puede aumentar con el número de empleados.
El RBAC frente a ACL, ABAC e IAM
Teniendo en cuenta las desventajas del RBAC, es posible que desee contemplar un par de alternativas. Una de las más comunes son las listas de control de acceso o ACL. Si una mentalidad de RBAC piensa en los permisos desde la perspectiva del usuario y los roles que desempeñan, el enfoque de ACL lo hace desde la perspectiva de los datos o la funcionalidad con la que los usuarios interactuarán. Una ACL es simplemente una lista para cada objeto de datos que detalla quién puede realizar qué operaciones en ese objeto. Esto es conceptualmente más simple y puede implicar menos trabajo que configurar RBAC, si no tiene tantos objetos de datos con los que lidiar, pero puede ver cómo no podría adaptar su escala a una empresa grande.
Mientras tanto, el control de acceso basado en atributos (ABAC, por sus siglas en inglés) es un paradigma que, de alguna manera, se basa en el RBAC. ABAC quita el énfasis a los usuarios y, en cambio, como su nombre lo indica, se enfoca en los atributos de todos los elementos en su sistema, combinándolos en conjuntos de reglas booleanas. Por ejemplo, bajo un paradigma ABAC, si un determinado tipo de usuario realiza un determinado tipo de acción en un determinado tipo de objeto, a una determinada hora del día, todos esos atributos pueden tenerse en cuenta a la hora de determinar si está permitido otorgarle el permiso. Tal vez cualquiera pueda leer y actualizar los registros financieros durante la jornada laboral, pero solo los gerentes del departamento de contabilidad pueden hacerlo fuera del horario laboral. ABAC es obviamente más granular que RBAC, pero también requiere mucho más soporte administrativo.
Hay un acrónimo más que puede escuchar cuando la gente habla de RBAC y paradigmas similares: IAM, o administración de acceso e identidad. Sin embargo, RBAC e IAM no se oponen. IAM define y administra las funciones y los privilegios de acceso de entidades de red individuales a una variedad de aplicaciones on premises y en la nube.
En otras palabras, el RBAC representa una forma de implementar IAM (y ABAC y ACL representan otras formas). Eso nos lleva a nuestra pregunta final: ¿cómo, desde una perspectiva técnica, se implementa el RBAC?
Herramientas, soluciones y ejemplos de RBAC
La buena noticia es que no tiene que preparar una solución RBAC desde cero: puede usar una de las muchas ofertas de IAM en el mercado para implementar una solución RBAC para su negocio. Existen varias suites de IAM: consulte la lista de los principales proveedores de eSecurity Planet y Toolbox -y casi todos le permiten establecer RBAC para sus usuarios. Los principales servicios en la nube como Amazon AWS y Microsoft Azure también ofrecen capacidades de RBAC.
Si desea ver un ejemplo de cómo se desarrolla todo esto en la práctica, puede consultar este caso de uso de muestra del proveedor de IAM Auth0. Ese documento lo guía a través de un ejemplo de implementación de RBAC con su plataforma y le muestra cómo personalizarlo para sus necesidades. Mudarse a RBAC puede considerarse como una travesía, pero las recompensas pueden ser excelentes.
Basado en el artículo de Josh Fruhlinger (CSO) y editado por CIO Perú
Puede ver también: