Red de Respuestas Legales - Derecho de patentes - ¿Cómo hacer que el sistema de gestión de permisos del sistema sea más seguro?

¿Cómo hacer que el sistema de gestión de permisos del sistema sea más seguro?

Diseño e implementación de un sistema de gestión de permisos basado en el modelo RBAC

0 Introducción

El sistema de información de gestión es un sistema complejo de interacción persona-computadora, y cada enlace específico que contiene puede estar sujeto a medidas de seguridad. amenazas. Es muy importante establecer un sistema sólido de gestión de autoridades y garantizar la seguridad del sistema de información de gestión. El sistema de gestión de autoridades es uno de los módulos más reutilizables del sistema de información de gestión. Cualquier sistema multiusuario implica inevitablemente los mismos requisitos de permisos y necesita abordar servicios de seguridad como autenticación de entidades, confidencialidad de datos, integridad de datos, no repudio y control de acceso (según ISO7498-2). Por ejemplo, el servicio de control de acceso requiere que el sistema controle a qué recursos puede acceder un operador y determine cómo operar estos recursos en función de los permisos de operación establecidos por el operador.

En la actualidad, el sistema de gestión de permisos es también uno de los módulos con mayor tasa de desarrollo repetido. En las empresas, diferentes sistemas de aplicaciones tienen sistemas de gestión de permisos independientes. Cada sistema de gestión de permisos solo satisface las necesidades de gestión de permisos de su propio sistema y puede ser diferente en términos de almacenamiento de datos, acceso a permisos y mecanismos de control de permisos. Esta inconsistencia tiene las siguientes desventajas:

A. Los administradores del sistema necesitan mantener múltiples sistemas de administración de permisos y duplicar el trabajo.

b La gestión de usuarios, la organización y otros datos se mantienen repetidamente y no se puede garantizar la coherencia e integridad de los datos.

c Debido a los diferentes diseños de sistemas de gestión de permisos, diferentes conceptos y diferentes tecnologías, es muy difícil implementar el inicio de sesión único y también existen problemas con la integración de los sistemas de gestión de permisos, lo que también trae consigo. dificultades para las empresas en la construcción de portales empresariales.

Adopte ideas de diseño de gestión de seguridad unificada, diseño estandarizado y un sistema de arquitectura técnica avanzada para construir un sistema de gestión de permisos universal, completo, seguro, fácil de administrar, portátil y escalable para hacer que el sistema de gestión de permisos sea Es muy necesario para convertirse verdaderamente en el núcleo del control de permisos y desempeñar un papel importante en el mantenimiento de la seguridad del sistema.

Este artículo presenta el diseño e implementación de un sistema de gestión de derechos basado en el modelo RBAC (control de acceso a políticas basado en roles), que se implementa utilizando tecnología de arquitectura J2EE. Y analiza cómo acceder y controlar los permisos del sistema de aplicaciones.

1 Adopta el diseño arquitectónico J2EE.

Utilice la arquitectura de plataforma empresarial J2EE para crear un sistema de gestión de permisos. La arquitectura J2EE integra ideas avanzadas de arquitectura de software y tiene las características de modelos de aplicaciones distribuidas multicapa, componentes reutilizables y en componentes, modelos unificados y completos y control de transacciones flexible.

El sistema se divide lógicamente en cuatro capas: capa de cliente, capa Web, capa de negocio y capa de recursos.

A. La capa de cliente es la principal responsable de la interacción persona-computadora. El administrador del sistema puede acceder a él a través de un navegador web y también puede proporcionar API y llamadas de servicios web para diferentes sistemas comerciales.

b. La capa web encapsula los servicios utilizados para proporcionar lógica de capa de presentación para los clientes que acceden al sistema a través de la web.

C. La capa empresarial proporciona servicios empresariales, incluidos datos empresariales y lógica empresarial, y centraliza el procesamiento empresarial del sistema. Los principales módulos de gestión empresarial incluyen gestión de organizaciones, gestión de usuarios, gestión de recursos, gestión de autoridades y control de acceso.

D. La capa de recursos es la principal responsable del almacenamiento, organización y gestión de los datos. La capa de recursos proporciona dos implementaciones: grandes bases de datos relacionales (como ORACLE) y servidores de directorio LDAP (Protocolo ligero de acceso a directorios) (como Microsoft Active Directory).

2 Modo RBAC

El control de acceso es una medida defensiva para evitar el uso no autorizado de los recursos. El objetivo básico es restringir los derechos de acceso de los sujetos de acceso (usuarios, procesos, servicios, etc.). ) para acceder a objetos (archivos, sistemas, etc.) para que el sistema informático pueda utilizarse dentro del ámbito legal, determina qué pueden hacer los usuarios y qué programas que representan ciertos intereses de los usuarios pueden hacer [1].

Generalmente existen tres estrategias de control de acceso en entornos empresariales: método de control de acceso discrecional, método de control de acceso obligatorio y método de control de acceso basado en roles (RBAC). Entre ellos, la autonomía es demasiado débil y la coerción es demasiado fuerte. Ambos tienen una gran carga de trabajo y son incómodos de gestionar [1]. El método de control de acceso basado en roles se reconoce actualmente como un método eficaz para resolver el control de acceso unificado a recursos en grandes empresas. Sus dos características distintivas son: 1. Reducir la complejidad de la gestión de autorizaciones y reducir los gastos generales de gestión; 2. Respaldar de manera flexible las políticas de seguridad empresarial y brindar una gran flexibilidad para los cambios empresariales.

El modelo RBAC estándar del Instituto Nacional de Estándares y Tecnología (NIST) consta de cuatro modelos de componentes. Los cuatro modelos componentes son el modelo básico RBAC0 (RBAC central), el modelo de clasificación de roles RBAC 1 (RBAC jerárquico), el modelo de restricción de roles RBAC2 (RBAC restringido) y el modelo unificado RBAC3 (RBAC combinado) [1].

A.RBAC0 define el conjunto mínimo de elementos que pueden constituir un sistema de control RBAC. En RBAC, hay cinco elementos de datos básicos: usuarios (users), roles (roles), objetos (OBS), operaciones (OPS) y permisos (PRMS). Los permisos se otorgan a roles, no a usuarios. Cuando se asigna una función a un usuario, el usuario tiene los permisos contenidos en la función. Una sesión es un mapeo entre un usuario y un conjunto de roles activados.

La diferencia entre RBAC0 y el control de acceso tradicional es la flexibilidad que aporta una capa de direccionamiento indirecto. RBAC1, RBAC2 y RBAC3 son extensiones de RBAC0.

B.RBAC1 introduce la relación de herencia entre roles, que se divide en relación de herencia general y relación de herencia restringida. La relación de herencia general solo requiere que la relación de herencia de roles sea una relación de orden parcial absoluta, lo que permite la herencia múltiple entre roles. La herencia restringida requiere además que la relación de herencia de roles sea una estructura de árbol.

El modelo C.RBAC2 añade separación de funciones. Las restricciones de RBAC2 especifican las reglas obligatorias que se deben seguir al otorgar permisos a roles, al otorgar roles a usuarios y cuando los usuarios activan roles en un momento determinado. La separación de responsabilidades incluye la separación estática de responsabilidades y la separación dinámica de responsabilidades. Las restricciones y las relaciones de permisos de rol de usuario determinan conjuntamente los derechos de acceso de los usuarios en el modelo RBAC2.

D.RBAC3 incluye RBAC1 y RBAC2, que no solo proporciona relaciones de herencia entre roles, sino que también proporciona separación de responsabilidades.

3 Diseño del modelo de objetos central

Basado en la idea de diseño de permisos del modelo RBAC, se establece el modelo de objetos central del sistema de gestión de permisos.

Los elementos básicos contenidos en el modelo de objetos incluyen principalmente: usuarios, grupos, roles, objetos, modos de acceso y operadores. La relación principal es: asignación de permisos de roles PA (asignación de autoridad) y asignación de roles de usuario UA (asignación de usuario). La descripción es la siguiente:

Objetos de control: recursos protegidos por el sistema y objetos accesibles. La definición de recursos requiere atención a las dos cuestiones siguientes:

1. Los recursos tienen relaciones jerárquicas y relaciones de inclusión. Por ejemplo, las páginas web son recursos y los objetos como botones y cuadros de texto en las páginas web también son recursos y son nodos secundarios de los nodos de la página web. Si puede acceder al botón, debe poder acceder a la página.

2. El concepto de recurso mencionado aquí se refiere a la clase de recurso, no a la instancia del recurso específico. La distinción entre categorías de recursos e instancias de recursos, así como la subdivisión de la granularidad de los recursos, son útiles para determinar los límites de gestión de los sistemas de gestión de permisos y los sistemas de aplicaciones. El sistema de gestión de permisos necesita gestionar los permisos de categorías de recursos, mientras que el sistema de aplicaciones necesita gestionar los permisos de instancias de recursos específicas. La diferencia entre los dos se basa principalmente en las dos consideraciones siguientes:

Por un lado, los permisos de las instancias de recursos suelen estar relacionados con los recursos. Es decir, en función de la relación entre la instancia del recurso y el sujeto que accede al recurso, se pueden determinar los permisos de la instancia del recurso.

Por ejemplo, en los sistemas de información de gestión, los clientes de diferentes departamentos deben dividirse según áreas de negocio. Las áreas A y B tienen recursos controlados para modificar la información del cliente, entre los cuales los "archivos de clientes" pertenecen a la categoría de recursos. Si se estipula que el área A solo puede modificar los datos del cliente administrados por el área A, es necesario distinguir la propiedad de los datos. Los recursos aquí pertenecen a la categoría de instancias de recursos. El perfil del cliente (recurso) en sí debe tener la información de su usuario (los datos del cliente pueden contener atributos del dominio comercial) para distinguir las operaciones de instancia de recursos específicos y modificar el contenido de la información bajo su jurisdicción.

Por otro lado, los permisos de instancia para recursos a menudo tienen una relevancia considerable en la lógica empresarial. Para diferentes lógicas de negocios, esto a menudo significa principios y estrategias completamente diferentes para determinar los permisos.

B. Permisos: los permisos de acceso para operaciones de recursos protegidos están vinculados a instancias de recursos específicas. En consecuencia, las políticas de acceso están relacionadas con las categorías de recursos, y diferentes categorías de recursos pueden adoptar diferentes métodos de acceso. Por ejemplo, las páginas tienen modos de acceso que se pueden abrir y no se pueden abrir, los botones tienen modos de acceso disponibles y no disponibles, y los cuadros de edición de texto tienen modos de acceso editables y no editables. Pueden existir relaciones de exclusión e inclusión en las políticas de acceso para el mismo recurso. Por ejemplo, los modos de acceso modificables para un conjunto de datos incluyen modos de acceso consultables.

C. Usuario: el titular o sujeto de derechos. Los usuarios y los permisos se separan y vinculan mediante la gestión de autorizaciones.

D. Grupo de usuarios: una colección de usuarios. En términos de juicio de lógica empresarial, puede basarse en la identidad individual o la identidad grupal. El sistema debilita el concepto de grupos de usuarios e implementa principalmente el método del usuario (identidad personal).

E. Función: unidad y transportista de distribución de energía. Los roles admiten la implementación de permisos jerárquicos a través de relaciones de herencia. Por ejemplo, el rol de jefe de sección incluye tanto el rol del jefe de sección como los roles de diferentes miembros del personal comercial del departamento.

F. Operación: Completar la vinculación de categorías de recursos y políticas de acceso.

G. Asignar permisos de roles PA: Realizar el mapeo de asociación entre operaciones y roles.

H. Asignar rol de usuario UA: realizar el mapeo de asociación entre usuarios y roles.

El modelo de objetos finalmente convierte el modelo de control de acceso en una matriz de acceso. Las filas de la matriz de acceso corresponden a los usuarios y las columnas corresponden a las operaciones. Cada elemento de la matriz especifica un rol correspondiente, que corresponde a los derechos de acceso otorgados al objetivo correspondiente y al comportamiento de implementación. Según las filas de la matriz de acceso, es el contenido de CL (Capacidad de acceso); según las columnas de la matriz de acceso, es el contenido de ACL (Lista de control de acceso).

4 Mecanismo de acceso a permisos

Sistema de gestión de permisos: proporciona servicios de gestión de permisos centralizados y es responsable de proporcionar identificación de usuario, información de usuario, información de estructura organizativa y cálculo de tablas de relaciones de permisos.

El sistema calcula los permisos mínimos del usuario en función de la relación entre usuarios, roles, operaciones, políticas de acceso y objetos de control, y considerando el otorgamiento positivo y negativo de permisos.

En la capa de lógica empresarial, el servicio se implementa mediante Session Bean, que también se puede publicar como un servicio web. Utilice el método proxy para controlar centralmente el servicio de cálculo de permisos de acceso al sistema de la aplicación y devolver la tabla de relaciones de permisos, es decir, el grupo binario {ObjectId, operado}.

Lado del sistema de aplicación: puede acceder al sistema de gestión de derechos a través de dos métodos de acceso opcionales: tabla de capacidad de acceso CL y lista de control de acceso ACL.

Tome un sistema de aplicación basado en el marco J2EE como ejemplo para ilustrar el proceso de acceso:

A. por Servlet [2]. Considerando que la entidad a autenticar es el usuario, se adopta el modo de acceso basado en ACL. Cuando un usuario inicia sesión, se llama al servicio de autenticación de usuario del sistema de gestión de derechos. Si la verificación es exitosa, se llama al servicio de cálculo de permisos, se devuelve la tabla de relaciones de permisos y se almacena en la sesión global del usuario que inició sesión en forma de HashMap. Si no hay una sesión global o la sesión ha caducado, se le dirigirá a la página de inicio de sesión para recuperar los permisos.

B. El control de acceso a los recursos URL directos se basa en el acceso CL. Si el usuario ingresa directamente la dirección URL para acceder a la página, existen dos formas de controlar el acceso: 1. Controle leyendo CL desde la etiqueta de permiso; 2. Adopte el modo de filtrado para controlar los permisos. Si no hay permiso, redirija a la página de inicio de sesión.

5 Mecanismo de control de acceso

Las categorías de recursos que se controlarán mediante permisos se definen de acuerdo con las necesidades del sistema de aplicación. Su semántica y reglas de control también las proporciona el sistema de aplicación. son transparentes para el sistema de gestión de permisos. Los permisos tratan los recursos y operaciones de diferentes sistemas de aplicaciones de manera uniforme. La tabla de relaciones de permisos obtenida por el sistema de aplicación que llama al sistema de gestión de permisos también debe ser interpretada por el sistema de aplicación. Según este diseño, el sistema de gestión de permisos es universal y el mecanismo de control de permisos lo maneja el sistema de aplicación.

Dado que el control de acceso del sistema de aplicación está relacionado con el entorno técnico específico, tomando como ejemplo el sistema de aplicación basado en la arquitectura J2EE, el principal componente de visualización del sistema es la página JSP, a través de la etiqueta biblioteca y componente de control de acceso * * *, para lograr.

A. Identificación de permisos: utilice etiquetas para identificar recursos en diferentes niveles, y las etiquetas de permisos de página identificarán los objetos de la página.

B. Registro de permisos: recorra las etiquetas de control de permisos en la página JSP y lea los permisos de control JSP. Registre los objetos y reglas de control de permisos en la página JSP en el sistema de información de administración de permisos a través del componente de registro de permisos.

C. Control de permisos: cuando un usuario del sistema de aplicación inicia sesión en el sistema, por un lado, después de obtener la tabla de relaciones de permisos del sistema de administración de permisos, se muestra la página de control de etiquetas de permisos; Por otro lado, el componente de control de permisos se utiliza para controlar los permisos correspondientes de la lógica empresarial, especialmente el control de permisos de instancias de objetos de control que están estrechamente relacionados con la lógica empresarial.

6 Mecanismo de almacenamiento de permisos

El sistema de gestión de permisos utiliza dos mecanismos de almacenamiento opcionales: la base de datos del servicio de directorio LDAP (Lightweight Directory Access Protocol) y la base de datos relacional. Almacene información del usuario, estructura organizativa, roles, operaciones, métodos de acceso y otra información.

Entre ellos, el sistema de servicio de directorio se basa en el estándar LDAP y tiene amplias capacidades de integración y * * intercambio de datos. La función de metadirectorio permite una integración rápida y sencilla con la infraestructura existente de una empresa, resolviendo problemas de sincronización entre bases de datos de usuarios, como las bases de datos de usuarios tradicionales RDBMS y LDAP.

7 Conclusión

Este artículo analiza una solución técnica para un sistema de gestión de derechos basado en el modelo RBAC. Este sistema de gestión de permisos se ha utilizado con éxito en prácticas de diseño y desarrollo de sistemas y está bien integrado con el sistema de aplicación. La práctica ha demostrado que el uso de permisos basados ​​​​en el modelo RBAC tiene las siguientes ventajas: la distribución de permisos es intuitiva, fácil de entender y fácil de usar, y admite las necesidades cambiantes de puestos y permisos, y es adecuada para estructuras organizativas jerárquicas; ; y gran reutilización.