Diseño de la función de permisos del sistema
Modelo RBAC
Actualmente, el modelo RBAC (Control de acceso basado en roles) es un modelo de permisos funcional ampliamente aceptado. En RBAC, los permisos están asociados con roles y los usuarios obtienen permisos de esos roles al convertirse en miembros de los roles apropiados. Esto simplifica enormemente la gestión de permisos. En una organización, se crean roles para realizar diversas tareas y a los usuarios se les asignan los roles correspondientes según sus responsabilidades y calificaciones. Los usuarios pueden asignarse fácilmente de un rol a otro. Se pueden otorgar nuevos permisos a roles según los nuevos requisitos y la fusión del sistema, y se pueden reclamar permisos de un rol según sea necesario.
1. Roles de roles
Si no existe el concepto de roles, será más flexible para los usuarios corresponder directamente a los permisos, pero el diseño de la tabla de datos del backend se volverá complicado. con altos costos de funcionamiento y tolerancia a fallas empeoran.
Después de la introducción del concepto de "rol", la relación entre usuarios y roles puede ser de muchos a uno o de muchos a muchos. Cuando el rol del usuario es de muchos a muchos, los permisos del usuario actual son la unión de múltiples roles. En este momento, solo necesita otorgar permisos a la función, lo que puede reducir en gran medida la carga de administración. Al mismo tiempo, desacopla a los usuarios de los permisos, proporciona mayor flexibilidad y mejora la tolerancia a fallas de todo el diseño.
2. Introducción de grupos de usuarios
En algunas plataformas grandes, si hay una gran cantidad de usuarios, al agregar roles, es necesario asignar nuevos roles a una gran cantidad de usuarios. , lo que supone una enorme carga de trabajo. En este momento, podemos introducir el concepto de grupos de usuarios, reunir a estos usuarios en el mismo grupo de usuarios y luego asignar roles a todo el grupo de usuarios, lo que reduce en gran medida la carga de trabajo de la asignación de roles.
Del mismo modo, si tiene demasiados permisos, tendrá el mismo problema. Configurar permisos para un rol requiere muchas operaciones. En este momento, puede considerar introducir el concepto de grupos de permisos para agrupar permisos que están estrechamente relacionados con roles, reduciendo así la carga de trabajo durante la asignación. En realidad, los grupos de permisos se utilizan relativamente raramente porque los permisos en el sistema generalmente son limitados. Es importante tener en cuenta que incluso si existen grupos de usuarios o grupos de permisos, se puede permitir que los usuarios o permisos se asocien directamente con roles, lo que puede depender de la situación empresarial específica.
La siguiente figura muestra cómo agregar un grupo de usuarios que se ejecuta en el sistema mac y configurar los permisos según el grupo de usuarios.
3. Modelo RBAC de herencia de roles
En un escenario empresarial, si es necesario distinguir roles: director de diseño, líder del equipo de diseño y miembros de diseño, y el modelo de gestión está al revés. compatible, entonces se debe utilizar el modelo RBAC de herencia de roles. Un rol superior hereda todos los derechos de un rol subordinado y se le pueden otorgar derechos adicionales.
En este momento, además de definir roles, también necesita administrar las relaciones entre roles y utilizar las relaciones para reflejar las relaciones jerárquicas de los roles, a fin de lograr el efecto de heredar permisos. Hay dos tipos principales de relaciones de herencia de roles: diagramas de árbol y gráficos acíclicos dirigidos.
La herencia muchas veces proviene de la estructura organizativa del equipo de la empresa. En este momento, los roles a menudo se asocian con la estructura organizacional para lograr el efecto de heredar el modelo a seguir. Como se muestra en la figura siguiente, el papel de Zhao es el de "líder de equipo de tercer nivel". Hay varios "líderes de equipo de tercer nivel" en el grupo junto a él, pero todos están adjuntos al árbol de estructura organizacional de la izquierda. en todos los niveles solo pueden ver y operar los permisos de sus nodos secundarios.
4. Modelo RBAC restringido
En un producto o sistema, es posible que sea necesario aislar algunos roles y no permitir que se asignen a una persona al mismo tiempo. Como todos sabemos, "no se puede ser jugador y árbitro al mismo tiempo".
Por lo tanto, para un conjunto de roles múltiples, solo pueden existir relaciones de selección única, pero pueden coexistir múltiples conjuntos de roles. Como se muestra en la figura siguiente, un usuario puede ser diseñador o administrador, pero solo se le puede asignar una función en el grupo de funciones de diseñador y una función en el grupo de funciones de administrador.
Además, estas limitaciones pueden ser cuantitativas.
Por ejemplo, debe haber un solo administrador en un grupo de productos, y no se permite eliminar ni reasignar roles de administrador, solo se puede cambiar el rol de la persona a cargo.
El modelo restringido no solo afecta el proceso de asignación, a veces incluso si hay múltiples roles, el uso debe restringirse porque diferentes roles entrarán en conflicto con el uso de la misma función o datos. Como se muestra en la imagen a continuación, solo se permite un inicio de sesión a la vez.
Existen varios tipos de restricciones según las diferentes necesidades empresariales. Es importante tener en cuenta que no debemos confiar únicamente en las limitaciones del backend, sino que debemos mostrar reglas claras y limitaciones apropiadas en el frontend para evitar errores y frustraciones del usuario.
En tercer lugar, la división y diseño de permisos
La relación entre usuarios, roles y permisos está bien establecida a través del modelo RBAC. Pero, ¿qué tipo de relación es y cómo planificar el concepto abstracto de "autoridad"?
Estos deben analizarse claramente antes de que se pueda seguir diseñando un sistema de permisos completo.
En primer lugar, debes saber que los permisos de los productos generales se componen de páginas, operaciones y datos. Las páginas y las operaciones están relacionadas entre sí y debe tener permisos de página para asignar los permisos de operación correspondientes en la página. Los datos se pueden agregar, eliminar e inspeccionar.
La relación general se muestra en la siguiente figura:
Entonces, al comienzo del diseño, es necesario considerar las posibles distinciones entre roles en el futuro e intentar desacoplarlas. y modularizar tanto como sea posible. Técnicamente, es mejor utilizar interfaces independientes para cada módulo de página y cada operación. Para el diseño, es necesario garantizar que todos los roles puedan seguir experimentando una experiencia fluida incluso después de que algunas operaciones y datos estén bloqueados debido a permisos.
Después de garantizar la compatibilidad con el diseño inicial, debe prestar atención a los siguientes puntos al configurar los permisos:
(1) Determine si se admite la configuración de front-end.
Si los roles y permisos son relativamente fijos, generalmente puede escribir la relación entre roles y permisos en el backend, pero debe modificarla en el backend y volver a conectarse. Esta situación se aplica a sistemas con un solo usuario, como los sistemas internos de la empresa.
Si necesita personalizar roles o cada rol tiene diferentes permisos en diferentes escenarios de usuario, la definición del rol y la configuración entre roles y permisos deben reflejarse en la "Página de configuración del usuario front-end" . Esta situación se aplica a sistemas y sistemas arrendatarios donde los permisos de roles definidos por el usuario cambian con frecuencia.
(2) Dividido según unidades básicas y configurado según lógica de negocio.
Generalmente, "agregar, eliminar, modificar, consultar" de cada objeto puede considerarse como una unidad de permiso básica. Por ejemplo, en "Gestión de personal", ver la lista de personal, agregar personal, eliminar personal y editar información del personal se debe dividir en cuatro unidades de permiso. En términos de tecnología y diseño, esperamos ser lo más desacoplados y modulares posible.
Pero a nivel empresarial, algunas operaciones están integradas. Se recomienda empaquetar estos permisos indivisibles como un todo para proporcionar configuración en la "página de configuración del usuario front-end". Por ejemplo, determinamos que en el negocio actual y futuro del sistema, solo los miembros ordinarios tienen permiso para ver la gestión de personal y los administradores tienen permiso para operar. Podemos combinar los tres permisos básicos de agregar, eliminar y modificar empresas. en la configuración de permisos.
(3) Los permisos de página tienen prioridad sobre los permisos de operación y datos.
Los permisos del módulo de página deben configurarse para configurar los permisos de operación específicos en el módulo de página actual y los permisos de visualización de datos del módulo de página.
(4) Los permisos de visualización tienen prioridad sobre los permisos de agregar, eliminar y modificar.
En circunstancias normales, primero debe poder ver un determinado módulo u operación antes de que otras operaciones de adición, eliminación y modificación sean significativas. Por lo tanto, durante el diseño, debe restringir la configuración de otros permisos antes de obtener permisos de visualización, o otorgar permisos de visualización de forma predeterminada al configurar otros permisos.
(5) Varias relaciones entre roles y permisos
La relación entre roles y permisos no es solo una simple "relación sí/no", sino que también incluye ciertas operaciones restringidas y algunas. nivel de acceso a los datos.
Por ejemplo, en la gestión de personal:
Alcance de los datos: los usuarios tienen derecho a ver la lista de personal, pero solo pueden ver las restricciones de los límites de datos de su propio equipo (límite superior, etc.); .): no puede exceder de 20 personas.
Campos de datos: RR.HH. puede ver campos como rango y salario en la lista de personal, mientras que otros roles solo pueden ver campos como nombre, correo electrónico, etc.;
(6) Diseñar expresión de roles y permisos
Al comunicar las reglas de diseño de permisos de un sistema, los diseñadores a menudo están acostumbrados a expresar sus ideas de la manera más directa y subjetiva, como la oración "Cuando...". Pero una plataforma implica muchas reglas de permisos, y cuando el artículo completo se describe de esta forma, el objeto de expresión será difícil de entender.
Descripción correcta: Más concretamente, se expresa en base a los resultados del lenguaje desarrollado y los modelos técnicos. Cada unidad de rol y permiso se dibuja en una cuadrícula, y cada cuadrícula de intersección describe las relaciones de datos y las restricciones de roles y permisos.
Como se muestra en la siguiente figura:
IV. Consejos a los que prestar atención
1. Administradores invisibles
Los roles y permisos puede ser En un sistema personalizado, generalmente es necesario reservar una función de administrador para la configuración inicial del sistema, que se utiliza para agregar el primer grupo de personal comercial y configurar funciones básicas.
En algunos sistemas, el rol de administrador desde la perspectiva de Dios está permitido, por lo que puede aparecer como "superadministrador" en la lista de configuración de roles. En algunos sistemas, no se permite que exista esta función, por lo que se puede establecer en un estado invisible y otorgarse solo al personal que mantiene el sistema.
2. Otorgar permisos iniciales
Para un sistema que permite a los usuarios unirse por sí mismos, es necesario establecer uno o más roles predeterminados, a veces puede ser el rol de "invitado". que sólo tiene los permisos más básicos.
El permiso inicial también se puede asociar a algunos de los campos de datos existentes del usuario. Por ejemplo, al agregar un usuario, si la posición del usuario es "Diseñador", los permisos del rol "Diseñador" se otorgarán directamente.
3. Concéntrese en la gestión de personal
En la gestión de personal, los roles de administrador deben prestar especial atención al tratar consigo mismos. Porque si modifica o elimina su propia función, es posible que el sistema no tenga funciones administrativas, no pueda agregar otros miembros y no pueda funcionar normalmente. Se pueden agregar opiniones durante el diseño, pero la edición y eliminación solo están prohibidas cuando se administran roles.
4. Sin solicitud de permiso de página
Aunque puede ocultar directamente páginas para las que el usuario actual no tiene permiso mediante restricciones de permiso de página, no puede excluir al usuario de obtener direcciones URL más allá del permisos. Cuando un usuario accede accidentalmente a una página sin permiso, se debe proporcionar un mensaje de "sin permiso" para evitar que el usuario piense que el sistema es un error.
Finalmente
En resumen, todo el diseño del sistema de permisos es el proceso de definir cada nodo y la relación entre los nodos.
Los nodos incluyen:
Usuarios; grupos de usuarios; roles; permisos (páginas, operaciones, datos);
Las relaciones incluyen:
Relación sí/no; relación de restricción (exclusión mutua, restricción de alcance, restricción de límites, restricción de dominio...)