Sistema de gestión de usuarios: diseño de permisos de usuario (modelo RBAC)

El control de permisos puede entenderse generalmente como una restricción de poder, es decir, debido a que diferentes personas tienen diferentes poderes, lo que pueden ver y usar puede ser diferente. En correspondencia con un sistema de aplicación, un usuario puede tener diferentes permisos de datos (vistos) y permisos de operación (usados).

Lista de control de acceso, ACL es el mecanismo de control de acceso más antiguo y básico. Es un modelo de control basado en objetos que también se encuentra en otros modelos. Para solucionar el problema de configurar usuarios con los mismos permisos uno por uno, posteriormente se adoptaron grupos de usuarios.

Principio: Cada objeto tiene una lista. La lista registra qué sujetos pueden realizar qué acciones con el objeto.

Por ejemplo: cuando el usuario A quiere editar un artículo, ACL primero verificará si hay un usuario A en la lista de control de la función de edición de artículos. Si lo hay, puede editarlo, si no, puede editarlo. no se puede editar. Otro ejemplo: los miembros de diferentes niveles tienen diferentes rangos de funciones disponibles en el producto.

Desventajas: cuando el número de entidades es grande, el trabajo de configuración y mantenimiento será costoso y propenso a errores.

Control de Acceso Discrecional, DAC es una extensión de ACL.

Principio: basado en el modelo ACL, los sujetos pueden otorgar de forma autónoma sus propios permisos a otros sujetos, por lo que los permisos se pueden transferir arbitrariamente.

Por ejemplo: los sistemas operativos LINUX, UNIX y Windows NT, que se encuentran comúnmente en los sistemas de archivos, brindan soporte DAC.

Desventajas: el control de permisos está relativamente descentralizado. Por ejemplo, no es posible simplemente establecer permisos unificados para un grupo de archivos y abrirlos a un grupo designado de usuarios. Si la autoridad del sujeto es demasiado grande, se puede filtrar información sin querer.

Control de Acceso Obligatorio, principal mecanismo de autenticación bidireccional en el modelo MAC. Se encuentra comúnmente en agencias clasificadas u otras industrias con fuertes jerarquías, como el software en los campos de seguridad militar y municipal.

Principio: el sujeto tiene un identificador de permiso y el objeto también tiene un identificador de permiso, y si el sujeto puede operar el objeto depende de la relación entre los identificadores de permiso de ambas partes.

Por ejemplo: los generales se dividen en generales > tenientes generales > generales de división, y el nivel de confidencialidad de los documentos militares se divide en alto secreto > secreto > secreto. Se estipula que diferentes rangos militares solo pueden acceder a archivos. con diferentes niveles de confidencialidad, por ejemplo, los generales de división solo pueden acceder a archivos secretos; cuando una determinada cuenta accede a un determinado archivo, el sistema verificará el rango militar de la cuenta y también verificará el nivel de confidencialidad del archivo. se efectuará cuando el rango militar y el nivel de confidencialidad correspondan entre sí.

Desventajas: Control demasiado estricto, gran carga de trabajo de implementación, falta de flexibilidad.

(Control de acceso basado en atributos), que puede resolver las deficiencias de RBAC y es fácil de mantener al agregar nuevos recursos.

Principio: la autorización se logra calculando dinámicamente si un atributo o un grupo de atributos satisface un determinado mecanismo. Es un modelo de permiso muy flexible que puede lograr diferente granularidad de control de permisos según sea necesario.

Suele haber cuatro categorías de atributos:

Por ejemplo: los departamentos A y B realizan los exámenes juntos como candidatos entre las 9:00 y las 11:00 de la mañana, y a las 14:00: 00 y 17:00 de la tarde Durante este período, los departamentos A y B calificarán los exámenes de cada uno.

Desventajas: las reglas son complejas, es difícil ver la relación entre el sujeto y el objeto y es muy difícil de implementar. Rara vez se usa ahora.

El núcleo de RBAC es que los usuarios solo están asociados con roles, y los roles representan permisos y son una colección de una serie de permisos.

Tres elementos de RBAC:

En RBAC, los permisos están asociados con roles y los usuarios obtienen los permisos de estos roles al convertirse en miembros de los roles apropiados. Los roles se crean para completar 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. A los roles se les pueden otorgar nuevos permisos según los nuevos requisitos y la integración del sistema, y ​​también se pueden reclamar permisos de un rol según sea necesario.

También existe una relación de herencia entre roles para evitar el exceso de autoridad.

El modelo RBAC se puede dividir en cuatro etapas: RBAC 0, RBAC 1, RBAC 2 y RBAC 3. Generalmente, las empresas pueden utilizar el modelo RBAC0. Además, RBAC 0 es equivalente a la lógica subyacente, y los tres últimos son mejoras en el modelo RBAC 0.

Permítanme primero presentarles brevemente estos cuatro modelos RBAC:

Modelo RBAC 0: relaciones de muchos a muchos entre usuarios y roles, roles y permisos.

En pocas palabras, un usuario tiene múltiples roles y un rol puede ser propiedad de varios usuarios. Esta es una relación de muchos a muchos entre usuarios y roles; lo mismo ocurre con los roles y permisos.

El modelo RBAC 0 es como se muestra a continuación: no se dibujan muchas líneas, pero ya se puede ver la relación de muchos a muchos.

Modelo RBAC 1: en comparación con el modelo RBAC 0, se agrega la lógica de clasificación de roles, que es similar a una estructura de árbol. El siguiente nodo hereda todos los permisos del nodo anterior, como role1. 1 bajo el nodo raíz y dos nodos secundarios de role1.2.

La lógica de clasificación de roles puede estandarizar efectivamente la creación de roles (principalmente debido a la lógica de herencia de permisos. He trabajado en herramientas de BD (como CRM) y existen clasificaciones entre BD (gerente, administrador). supervisor, especialista), si se utiliza el modelo RBAC 0 como sistema de permisos, es posible que necesite crear un rol para el administrador, supervisor y especialista (no hay herencia de permisos entre roles, es muy probable que). Surgirá un problema. Debido a una configuración de permisos incorrecta, el supervisor tiene el permiso denegado.

El modelo RBAC 1 resuelve muy bien este problema. Una vez que se crea la función de administrador y se configuran los permisos, los permisos de la función de supervisor heredan los permisos de la función de administrador y admiten la eliminación selectiva de permisos de supervisor. .

El modelo RBAC 1 es como se muestra a continuación: la relación de muchos a muchos permanece sin cambios, solo se agrega la lógica de clasificación de roles.

[Carga de imagen...(-95cc0-1640060170347-0)]

Modelo RBAC 2: basado en el modelo RBAC 0, se agregan más restricciones al rol.

Si los roles son mutuamente excluyentes, un caso clásico es que al cajero en el sistema financiero no se le permite estar a cargo de la auditoría al mismo tiempo, entonces al asignar roles a los operadores del sistema financiero, lo mismo El operador no puede tener las funciones de cajero y auditoría al mismo tiempo.

Por ejemplo, si hay un límite en el número de roles, por ejemplo: se crea un rol específicamente para el CEO de la empresa, pero finalmente se descubre que 10 personas en la empresa tienen el rol de CEO, y hay 10 CEOs en una empresa?

Este es el límite en el número de roles, que se refiere a cuántos usuarios pueden tener este rol.

El modelo RBAC 2 tiene como objetivo principal aumentar las restricciones impuestas a los roles, lo que también está en línea con los objetivos del sistema de permisos: derechos y responsabilidades claros, uso seguro y confidencial del sistema.

Modelo RBAC 3: También está basado en el modelo RBAC0, pero combina todas las características de RBAC 1 y RBAC 2. No habrá más descripciones aquí. Los lectores pueden simplemente regresar y leer la descripción de los modelos RBAC 1 y RBAC 2.

El modelo de permisos RBAC consta de tres partes: gestión de usuarios, gestión de roles y gestión de permisos. La gestión de usuarios se divide según la arquitectura empresarial o la arquitectura de línea de negocio. Estas estructuras en sí son relativamente claras y tienen muy buena escalabilidad y legibilidad. La gestión de roles debe diseñarse después de una comprensión profunda de la lógica empresarial. Generalmente, los roles reales de cada departamento se utilizan como base y luego se amplían de acuerdo con la lógica empresarial. La gestión de permisos es un refuerzo de los dos primeros tipos de gestión. Si es demasiado detallada, estará demasiado fragmentada y si es demasiado tosca, no será lo suficientemente segura. Aquí debemos diseñar en función de la experiencia y las condiciones reales. .

Los usuarios en la gestión de usuarios son todos los empleados de la empresa. Tienen su propia estructura organizativa. Podemos utilizar directamente la estructura del departamento empresarial o la estructura de la línea de negocio como pistas para construir un sistema de gestión de usuarios.

Se requiere atención especial:

La estructura organizativa en el negocio real puede ser diferente de la estructura del departamento empresarial y la estructura de la línea comercial. Se debe considerar el mecanismo de intercambio de datos. es autorizar a ciertos individuos y a un determinado grupo de roles a compartir los datos de un determinado grupo de objetos en un determinado nivel organizativo.

Al diseñar roles del sistema, debemos tener una comprensión profunda de la estructura de la empresa y la estructura comercial, y luego diseñar los roles y niveles dentro de los roles de acuerdo con las necesidades. En términos generales, los roles son fijos en relación con los usuarios. Cada rol tiene sus propios permisos y restricciones claros. Estos permisos se determinan en el diseño del sistema y no se cambiarán fácilmente más adelante.

(1) Obtener roles básicos automáticamente

Cuando un empleado se une a un determinado departamento, la cuenta del empleado debe agregarse automáticamente al rol básico correspondiente del departamento y tener los permisos básicos correspondientes. . Esta operación es para garantizar la seguridad del sistema y reducir muchas operaciones manuales por parte del administrador. Permita que los nuevos empleados utilicen rápidamente el sistema y mejoren la eficiencia del trabajo.

(2) Roles temporales y tiempo de vencimiento.

El negocio de la empresa en ocasiones requiere de apoyo externo. No son empleados de la empresa y solo brindan apoyo en la empresa durante un período de tiempo determinado. . En este punto, necesitamos configurar roles temporales para tratar con empleados temporales que pueden colaborar en varios departamentos.

Si el nivel de seguridad de la empresa es alto, dichas cuentas tendrán un tiempo de vencimiento fijo por defecto. Una vez alcanzado el tiempo de vencimiento, deberán revisarse nuevamente antes de poder reabrirse. Evite el olvido de cuentas temporales en el sistema debido a procesos imperfectos, generando riesgos de seguridad.

(3) Roles virtuales

Los niveles en los roles de departamento pueden autorizar a los empleados del mismo nivel a tener los mismos permisos, pero algunos empleados necesitan llamar a roles fuera del nivel de rol debido al trabajo. razones. Diferentes empleados en el mismo nivel necesitan permisos diferentes. Para este tipo de concesión de permiso razonable que va más allá del nivel de rol, podemos configurar roles virtuales. Este rol virtual consolida todos los permisos necesarios para el trabajo y luego los asigna a empleados específicos. De esta manera, no es necesario ajustar la estructura organizacional y los roles correspondientes, y también puede cumplir con los requisitos de permisos de situaciones especiales en el trabajo.

(4) Lista blanca y negra

Lista blanca: algunos usuarios no tienen roles de nivel superior en un determinado departamento, pero debido a las necesidades comerciales, es necesario darles funciones avanzadas. permisos fuera de sus roles. Luego podemos diseñar una lista blanca con alcance limitado y agregarle los usuarios necesarios. En el proceso de seguridad, solo necesitamos diseñar un proceso de seguridad para la lista blanca para revisar los usuarios especiales en la lista blanca, monitorear a los usuarios con permisos especiales y reducir los riesgos de seguridad.

Lista negra: un escenario de lista negra más común es que algunos empleados que han cometido errores todavía están trabajando, pero ya no se les puede otorgar ningún permiso de la empresa. En esta situación en la que ni la asociación de roles ni la cuenta se pueden desactivar por completo, se puede configurar una lista negra para que dichos usuarios puedan iniciar sesión en la cuenta y ver información básica, pero la lista negra ha restringido la mayoría de los permisos clave.

La gestión de permisos generalmente está restringida desde tres aspectos. Permisos de página/menú, permisos de operación, permisos de datos.

(1) Permisos de página/menú

Para los usuarios que no tienen permiso para operar, oculte directamente la entrada de la página correspondiente o las opciones del menú. Este método es sencillo, rápido y directo, y resulta muy eficaz para algunos permisos poco sensibles a la seguridad.

(2) Permisos de operación

Los permisos de operación generalmente se refieren a si diferentes usuarios pueden agregar, eliminar, modificar y verificar el mismo conjunto de datos. Para algunos usuarios, son datos de navegación de solo lectura y, para otros, son datos editables.

(3) Permisos de datos

Para la gestión de permisos con altos requisitos de seguridad, no es suficiente restringir los menús ocultos y los botones de edición desde la interfaz. también es necesario.

Si un usuario intenta editar datos que no pertenecen a su autoridad a través de medios ilegales, el servidor identificará, registrará y restringirá el acceso.

Cómo controlar los permisos de datos

Los permisos de datos se pueden dividir en permisos de fila y permisos de columna. Control de permisos de fila: cuántos datos ver. Control de permisos de columna: vea cuántos campos tiene un dato

En un sistema simple, los permisos de fila se pueden controlar a través de la estructura organizativa y los permisos de columna se pueden configurar según los roles. Sin embargo, en situaciones complejas. , la estructura organizativa no puede contener filas complejas y los roles no pueden contener una visualización especializada de columnas.

La práctica actual de la industria es proporcionar una configuración de reglas de derechos de datos a nivel de columna y tratar las reglas como configuraciones de puntos de permiso similares que se asignarán a una determinada función o a un determinado usuario.

NetEase tiene varias prácticas:

/index/manual/o/6System_management/data_role.html

1. Superadministrador

Super El administrador es la cuenta utilizada para iniciar el sistema y configurarlo. Esta cuenta debe ocultarse después de configurar el sistema y crear un administrador. La cuenta de superadministrador tiene todos los permisos en el sistema y puede desplazarse y ver los datos de varios departamentos. Si se usa incorrectamente, es un riesgo de seguridad para la administración del sistema.

2. Cómo lidiar con roles mutuamente excluyentes

Cuando el rol que ya es útil para el usuario y el rol que está a punto de agregarse son mutuamente excluyentes, el administrador debe ser Aparece un mensaje al agregar un nuevo rol porque los roles son mutuamente excluyentes. Debido al rechazo, no se pueden agregar nuevos personajes. Si necesita agregar, primero debe cancelar el rol anterior y luego agregar un nuevo rol.

3. El diseño del sistema de permisos de gestión de usuarios debe ser sencillo y claro

A la hora de diseñar el sistema de permisos es necesario aclarar las ideas, mantener todo sencillo y evitar añadir funciones redundantes y lógica de permisos, no se debe aumentar. Porque a medida que el negocio de la empresa se expande, los permisos y los roles también aumentarán. Si las ideas de diseño iniciales no son rigurosas, el sistema de permisos se volverá infinitamente caótico a medida que el negocio se expanda. En este momento, será demasiado tarde para resolver los permisos. Por tanto, el diseño inicial debe ser claro, sencillo y claro para evitar muchos problemas innecesarios en el futuro.

4. Página de aviso no autorizada

A veces, el empleado A comparte directamente la página en la que está trabajando actualmente con el empleado B, pero es posible que el empleado B no tenga permiso para verla. En este momento, deberíamos considerar agregar una "página de aviso no autorizada" aquí para evitar la tosca página 404 que hace que el empleado B piense que hay un error del sistema.