¿Qué es el control de acceso basado en roles (RBAC)?

El ataque a Uber en 2022, en el que un ciberdelincuente accedió a la red interna de la empresa y a sus herramientas, deja una lección muy importante para el sector: las brechas de seguridad no son algo a lo que puedas reaccionar, sino algo que tienes que prevenir. Algo muy importante que las organizaciones pueden hacer en este sentido es mantener su software bajo unas estrictas directivas de control de acceso y auditar continuamente los accesos y las acciones que se realizan.

En la actualidad, hay disponibles diferentes mecanismos de control de acceso en el mercado, incluido el llamado control de acceso basado en roles (RBAC). En este artículo, vamos a examinar las ventajas del RBAC en términos de operabilidad y seguridad, y veremos cómo implementarlo con un esquema y cómo te puede ayudar en tareas de cumplimiento. También hablaremos de otra serie de mecanismos de control de acceso para comprender cómo funcionan.

Conceptos básicos de RBAC

El control de acceso basado en roles es un mecanismo por el que das acceso a los usuarios a determinados recursos de acuerdo con permisos definidos para los roles que tienen asignados. El RBAC tiene tres componentes principales:

• Roles
• Permisos
• Usuarios

Cada rol tiene unos permisos específicos para acceder a determinados recursos, y cada usuario tiene un rol concreto. Una vez que recibe un rol, el usuario puede ver y usar todos los elementos que se han asignado a dicho rol.

Esquema de RBAC

Las organizaciones implementan RBAC con la ayuda de un esquema. En este esquema basado parcialmente en SQL, veremos cómo asignar roles, usuarios y permisos. Los esquemas de base de datos contienen tablas y sus relaciones. Hay cinco tablas principales necesarias para implementar un esquema de RBAC:

• Users: mantiene un registro de todos los usuarios y de sus datos básicos
• Permissions: muestra los permisos definidos en el sistema, que se pueden seguir dividiendo según los recursos y las acciones permitidas para ese recurso
• Roles: roles definidos en el sistema
• User_Roles: asignación de los roles por usuario para ver todos los roles que tiene un usuario en una relación de muchos a muchos
• Role_Permissions: muestra la asociación entre roles y permisos

Con unos pocos requisitos únicos, puedes asignar directamente permisos a un usuario. Es algo que no se recomienda en absoluto porque, una vez que lo hagas, abrirás una vía de agua para que tu equipo cree potencialmente un montón de permisos asignados directamente a un usuario. Si, para algunos casos de uso específicos quieres que sea así, puedes crear otra tabla User_Permissions para asociar usuarios y permisos.

Con estas cinco o seis tablas podrás crear una función que realice las comprobaciones de autorización para ti. Abajo tienes una pseudofunción para comprobar los permisos:

function check_permissions(user, permissions):
user_role = get_role(user)
user_permissions = user_role.get_permissions()
if permissions in user_permissions:
Return “allowed”
else:
Return “Not allowed”

Aquí la definición de los permisos puede variar de una implementación a otra. Una puede ser del tipo objeto-permiso, como “profile-edit,” que significa que el usuario puede editar el perfil.

También quizás quieras implementar una jerarquía de roles, que significa que un rol puede tener diferentes roles, y los permisos se asignarán de acuerdo con esos roles. En esos casos, la implementación puede ser un poco complicada. Necesitarás dos nombres de campo: is_parent_role y child_roles. También puedes crear otra tabla para esta asignación.

Importancia del control de acceso basado en roles

El control de acceso basado en roles estandariza el proceso de conceder permisos a los usuarios para ejecutar o realizar tareas de operaciones. Las ventajas del RBAC incluyen:

• Menos trabajo redundante: como tienes roles definidos, solo tienes que asignar un rol a un usuario para que reciba los permisos adecuados. De lo contrario, tendrías que agregar cada permiso manualmente para cada usuario.
• Mayor seguridad: puesto que estos roles los define un equipo centralizado, RBAC es menos propenso a errores y más fácil de gestionar. La definición de roles también implica que hay menos posibilidades de que se otorguen permisos incorrectos por error.
• Auditoría sencilla: los roles predefinidos hacen que haya menos cambios en las definiciones y asignaciones de roles, y permiten que las auditorías sean más sencillas en comparación con la asignación de permisos a cada usuario.
• Requisitos de cumplimiento: la implementación de un control de acceso te permitirá cumplir con las normativas de cumplimiento, algo que siempre es un aspecto importante de la seguridad.

Prácticas recomendadas para RBAC

Una sola mala implementación puede menoscabar el sistema más seguro. Por eso, es de vital importancia que se sigan las prácticas recomendadas.

Redacta información detallada para cada rol y su cometido. Incluye una columna de anotaciones en la tabla de roles para definir cada uso y el motivo por el que se creó. No crees roles a ciegas; en lugar de ello, intenta encontrar los roles más adecuados que ya existan y asígnalos.

No des permisos explícitos a nivel de usuario, ya que esto puede generar confusión y provocar que se otorguen permisos indebidos.

Asegúrate de que todas las tablas tienen una columna created_by, updated_by, updated_at y created_at. Además, todos los cambios en las tablas deben transmitirse a un sistema de auditoría centralizado para identificar si se han asignado permisos incorrectamente o si alguien ha recibido un permiso escalado que no era necesario.

No todo el mundo debe poder controlar quién puede cambiar roles. Es una operación muy importante, y cada cambio debe pasar por una canalización basada en una aprobación correctamente auditada.

Además, el equipo que gestiona el control de acceso debe publicar una serie de normas sobre cómo crear permisos para los roles.

Otros mecanismos de control de acceso

En la actualidad se utilizan varios mecanismos de control de acceso. A continuación veremos algunos de los más importantes.

Control de acceso basado en atributos

En este mecanismo de control de acceso, se dan permisos a los recursos en función de los atributos de dichos recursos. Uno de los mejores ejemplos de esto es AWS, donde puedes dar acceso a recursos mediante etiquetas.

Pros: es un método muy flexible y permite realizar cambios en los atributos para que un usuario reciba un permiso

Contras: los permisos no deseados pueden propagarse si el atributo está asociado con otra entidad. La implementación necesita más tiempo, ya que cada recurso tiene que estar asociado a un atributo y el equipo debe definir esos atributos y planificarlos.

Control de acceso a nivel de usuario

En este mecanismo, a un usuario se le permite acceder a los recursos en función del permiso asignado directamente al usuario.

Pros: es muy sencillo al principio y es el mecanismo más fácil de implementar.

Contras: es difícil de gestionar porque puede volverse muy complejo a medida que aumentan los usuarios y los permisos.

Control de acceso basado en directivas

En este caso, se da acceso a los usuarios según una directiva definida para el usuario a nivel empresarial. La directiva evalúa el sujeto, el objeto, la acción y el contexto. El sujeto puede ser un departamento como ingeniería; el objeto puede ser una herramienta como SonarQube; la acción puede ser la actividad que quieres realizar como, por ejemplo, ver informes; y el contexto es el entorno en el que se realiza, como un entorno de pruebas o de producción.

Pros: las directivas legibles por humanos tienen más sentido y tienen control a nivel de contexto.

Contras: la implementación es compleja, ya que la ejecución puede involucrar diferentes verticales y sus herramientas.

Conclusión

Hay muchas formas de implementar un control de acceso. Un método de uso común consiste en combinar RBAC y ABAC. AWS ha aplicado lo que parece ser una de las mejores combinaciones de estos dos enfoques.

Además de elegir entre los mecanismos de control, hay que asegurarse de que se auditan todos y cada uno de los eventos, y de que se generan alertas en caso de que se creen permisos incorrectos.

Es realmente complicado cumplir todos estos requisitos sin problemas, ya que aparecerán múltiples impedimentos. Por ejemplo, la herramienta centralizada que utilices tiene que estar integrada con numerosas herramientas internas; algunas pueden estar restringidas y admitir solo unos pocos protocolos.

Problemas aparte, tienes que implementar control de acceso en todos tus sistemas para sentirte seguro en escenarios en los que tus sistemas puedan verse comprometidos.