Sistema de gestión de derechos de rol de usuario backend
RBAC (Role-Based Access Control, control de acceso basado en roles) significa que los usuarios asocian roles con permisos para obtener permisos para utilizar determinadas funciones. Los permisos se otorgan a roles, no a usuarios, pero un usuario puede tener varios roles. Cuando se asigna un rol a un usuario, el usuario tiene los permisos funcionales incluidos en el rol.
En pocas palabras, un usuario tiene varios roles y cada rol tiene varios permisos funcionales. De esta manera, se construye un modelo de autorización de "permiso de rol de usuario". En este modelo, generalmente existe una relación de muchos a muchos entre usuarios y roles, y entre roles y permisos. Como se muestra a continuación:
Un sistema de permisos de roles de usuario backend siempre se puede dividir aproximadamente en tres módulos: administración de usuarios, administración de roles y administración de permisos.
El sistema de permiso de roles pertenece a la categoría de diseño estratégico. Su diseño pone a prueba la comprensión del negocio por parte del PM y su familiaridad con todas las funciones de su backend. Antes de crear un sistema de permisos de roles, primero debe tener un conocimiento profundo del proceso comercial y todos los módulos funcionales del backend. Si no lo comprende, solicite asesoramiento a colegas relevantes para evitar errores y lagunas lógicas en el proceso de diseño. sistema de permisos de roles.
Los usuarios en la gestión de usuarios son principalmente usuarios de sistemas funcionales. Estos usuarios son empleados individuales. Estos individuos a menudo se dividen en dos dimensiones: relaciones administrativas (estructura de departamentos), departamentos comerciales (estructura comercial). La gestión de usuarios consiste en realizar una agrupación preliminar o una agrupación de empleados individuales en función de estas dos dimensiones. Después de dividirse según departamentos administrativos o departamentos de línea de negocio, los usuarios de los departamentos o grupos correspondientes tienen requisitos de uso de funciones del sistema y niveles de permisos básicamente similares.
Nota: La ilustración anterior muestra el modelo de gestión de usuarios dividido según; relaciones administrativas.
Nota: El ejemplo anterior muestra el modelo de gestión de usuarios dividido según las relaciones de línea de negocio.
Los roles suelen ser etiquetas fijas preestablecidas en el sistema en función de las necesidades de gestión empresarial. Cada rol correspondiente a los permisos claros del sistema, los permisos del sistema que posee generalmente no se cambiarán a voluntad y los roles no cambiarán a medida que se agreguen y eliminen usuarios, lo cual es más estable que la administración de usuarios. Si una función está vinculada a un departamento de la organización bajo una relación administrativa, entonces, si un usuario ingresa al departamento de la organización, el usuario se agregará automáticamente a la función correspondiente y tendrá todos los permisos del sistema de la función.
Por ejemplo, después de que un funcionario financiero, Xiao Zhang, se une al departamento de finanzas, el usuario puede ver los informes de datos financieros y los permisos de operación correspondientes que pueden ser vistos por los empleados del departamento en el sistema de estados financieros correspondiente sin necesidad de información adicional. autorización (como aprobación financiera operativa, etc.);
El negocio está en constante innovación y desarrollo. A medida que el negocio se desarrolla, se establecerán y crearán más y más roles nuevos.
Por ejemplo, la empresa ha lanzado recientemente un proyecto de comida grupal corporativa. El departamento de proyectos ha reclutado horizontalmente a varios empleados de varios departamentos para formar un equipo de proyecto, y los permisos comerciales del proyecto solo están autorizados para ellos. empleados para ver y operar, luego, en este proyecto, se generará una nueva función "Finanzas 1". El administrador senior del sistema agregará el Zhang financiero seleccionado del departamento financiero a la función de "Finanzas 1", luego Xiao Zhang podrá obtenerlo. Permiso para ver operaciones e informes de datos comerciales del proyecto de comidas grupales corporativas. La concesión de este tipo de permiso no se puede realizar mediante la vinculación automática de las relaciones administrativas del usuario;
Los permisos pueden ser únicos o heredados.
Cada rol tiene su propio conjunto de permisos. La herencia de roles en realidad significa heredar los permisos del rol principal. Generalmente, un rol hereda todos los permisos de su rol principal y agrega algunos de sus propios permisos. La herencia de roles del sistema a menudo existe en equipos o empresas con una gestión jerárquica de usuarios clara.
Antecedentes comerciales de roles mutuamente excluyentes: cuando un proceso de negocio necesita dividirse en operaciones separadas debido a razones de control de riesgos Cuando hay varios pasos; , se deben autorizar diferentes roles para estos diferentes pasos, y estos roles deben ser mutuamente excluyentes.
Por ejemplo, en el proceso de aprobación de reembolsos financieros de grandes cantidades, después de que el oficial financiero Xiao Zhang tiene la autoridad del aprobador, no puede otorgar la autoridad de revisión y confirmación a Xiao Zhang nuevamente, para evite el riesgo de que una persona complete un reembolso de una gran cantidad.
Los roles temporales a menudo se configuran para grupos especiales. Por ejemplo, cuando una empresa tiene un equipo de acceso especial, es necesario asignar estos clientes especiales. identidades temporales para experimentar ciertas operaciones funcionales. Entonces, obviamente es inapropiado agregar a estas personas a la estructura organizacional del departamento, porque estas personas son solo colocaciones temporales, no empleados corporativos.
En segundo lugar, las operaciones funcionales que estos clientes necesitan experimentar son a menudo horizontales. Múltiples módulos comerciales y líneas de productos (complejos), las empresas generalmente no tienen roles fijos listos para usar que tengan todos los permisos operativos requeridos por los clientes, por lo que necesitan configurar roles temporales para estos clientes y admitir la selección máxima de permisos para roles temporales. Espacio;
Como sugiere el nombre, la lista negra no puede tener ningún permiso, mientras que la lista blanca puede tener los permisos correspondientes. Esto debe configurarse especialmente según las necesidades del negocio.
La gestión de permisos se considera desde tres niveles diferentes de granularidad: menú de funciones, operación de funciones y parámetros de datos. La granularidad específica depende de la estructura de la empresa y el tamaño del equipo. Si los atributos comerciales no requieren que los permisos se controlen a un nivel muy fino, en realidad no es necesario dividir la granularidad de los permisos en una operación o botón específico. , el núcleo del producto backend es la plataforma de gestión empresarial y el objetivo principal es ayudar a la gestión y promoción del negocio.
Nota: La imagen muestra una captura de pantalla parcial de un producto backend, en la que la página del menú de funciones, los botones de operación de funciones y los campos de datos son visibles.
Para los productos back-end, dividir los permisos de usuario para los menús de funciones es en realidad un método de administración relativamente general. En este modo, una vez que el usuario está autorizado, puede usar todos los datos del menú. barra de visualización de permisos y permisos de operación de funciones;
Los permisos en el nivel de operación de funciones serán más profundos que el menú de funciones. En este caso, los usuarios con diferentes roles pueden ingresar a la misma página de menú para ver los mismos datos. información de campo en segundo plano, sin embargo, las operaciones funcionales que pueden realizar son diferentes;
El nivel del campo de datos es una división más detallada, lo que se dará cuenta cuando usuarios con diferentes roles ingresen al fondo del mismo. página del menú, los campos de datos visibles serán diferentes. Por ejemplo, cuando el personal de ventas ingresa a un determinado backend de gestión del desempeño de ventas, puede ver sus propios datos de mejora del desempeño, pero el personal financiero ve los campos de gastos de las órdenes de trabajo comerciales. Estos campos solo existen en una página de menú, pero están limitados por diferentes únicamente. los permisos de rol.
Los datos se refieren a ciertas categorías de datos en el sistema que requieren permiso antes de poder operar. Por ejemplo, también son datos de clientes, pero los clientes de diferentes canales deben dividirse y asignarse a diferentes administradores. gestión. Por ejemplo, un empleado tiene permiso para editar la información del cliente, pero los datos del cliente editados correspondientes no se pueden utilizar sin permiso.
Tome como ejemplo el backend de una determinada actividad promocional, desde no tener restricciones de permisos hasta acceder al sistema de administración de derechos de rol del usuario. Los detalles son los siguientes:
Nota: lo anterior es. Captura de pantalla del backend de la gestión de la actividad promocional de un determinado producto
Antes de que el backend de la promoción acceda al sistema de permisos, casi todos los permisos del sistema están en estado de rayas. Todos los miembros de la línea de negocios pueden ver el contenido de la actividad operativa del backend. y datos de resultados de operaciones, y puede realizar operaciones relativamente sensibles.
Esta situación obviamente implica ciertos riesgos de gestión, por lo que el sistema backend debe estar conectado al sistema de gestión de autoridades para una gestión sistemática y control de riesgos.
Las actividades promocionales deben desmantelarse durante el proceso de acceso al sistema de gestión de autoridades; Los elementos de permiso de este módulo funcional (hasta una cierta granularidad) deben juzgarse en función de las características comerciales para determinar la granularidad que debe dividirse, ya sea al nivel de menús funcionales, operaciones funcionales o campos de datos. la granularidad está claramente dividida, el sistema de gestión de permisos Solo entonces se pueden otorgar permisos a diferentes roles según la granularidad
Después de que la promoción se conecta al sistema de gestión de permisos, cuando el usuario del rol correspondiente inicia sesión; al backend nuevamente, el backend primero verificará si el rol del usuario es Con los permisos del módulo funcional, así como los permisos de operación y los permisos de campo de datos correspondientes a los permisos del rol, los resultados de la verificación se mostrarán al usuario en el lado del producto después de ser procesado por el servidor. En este momento, las operaciones visibles y ejecutables del mismo usuario en segundo plano pueden ser muy diferentes de las que tenía antes de acceder al sistema de administración de permisos. Este es el cambio provocado por el sistema de administración de permisos según los roles de los usuarios.
1. Un usuario tiene múltiples roles. ¿Cómo lidiar con la relación mutuamente excluyente entre múltiples roles?
Si un usuario ha sido agregado a un determinado alcance de función, al agregar al usuario una función que tiene una relación mutuamente excluyente con la función actual, el sistema emitirá un juicio de exclusión mutua. agregarse con éxito al usuario
2. En el proceso de desarrollo empresarial, ¿cómo garantizar que los permisos entre diferentes roles estén claramente separados?
Con el rápido desarrollo del negocio, se seguirán agregando diferentes roles y más módulos funcionales, y la relación entre estos roles y los permisos funcionales será cada vez más confusa. En este momento, los gerentes de producto y Junto con el. Desde el lado comercial, debemos enfrentar el desarrollo y los cambios del negocio de manera oportuna, resolver el alcance de los ajustes comerciales de manera oportuna y realizar los cambios correspondientes.
3. Es la dificultad central del usuario; sistema de gestión de derechos el diseño inicial del producto?
Lo más difícil del sistema de gestión de derechos de usuario no es el diseño inicial del producto, sino la operación y el mantenimiento posteriores, porque la estructura del sistema de derechos a menudo no cambia a voluntad, pero surgen roles y funciones. rápidamente con el módulo de desarrollo empresarial, para evitar que la relación entre roles y permisos funcionales se vuelva confusa, se requiere pensamiento claro y ajustes cuidadosos al establecer nuevos roles y asignar permisos.