Cómo implementar la función de control de permisos de datos en sistemas de aplicacionesDiseño e implementación de un sistema de gestión de permisos basado en el modelo RBAC0 Introducción El sistema de información de gestión es un sistema complejo de interacción persona-computadora, en el que cada específico Los enlaces pueden estar sujetos a amenazas a la seguridad. Establecer un sistema sólido de gestión de autoridades es muy importante para garantizar la seguridad de los sistemas de información de gestión. El sistema de gestión de autoridades es uno de los módulos con mayor reutilización de código en el sistema de información de gestión. Cualquier sistema multiusuario implica inevitablemente los mismos requisitos de permisos y necesita abordar servicios de seguridad como identificació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 el operador y decida cómo operar los 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 un sistema de gestión de permisos independiente. Cada sistema de gestión de permisos solo satisface las necesidades de gestión de permisos de este 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 conjuntos de sistemas de gestión de permisos, lo que duplica el trabajo, la gestión de usuarios, la estructura organizativa y otros datos se mantienen repetidamente y no se puede garantizar la coherencia e integridad de los datos; c. Debido a que cada sistema de gestión de autoridades tiene diferentes diseños, diferentes comprensiones conceptuales y diferentes tecnologías, existen problemas con la integración entre los sistemas de gestión de autoridades. Es difícil implementar el inicio de sesión único y es difícil para las empresas establecer una empresa. portales. 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, haciendo que el sistema de gestión de permisos se convierta realmente en un sistema de control de permisos. un papel importante en el mantenimiento de la seguridad del sistema y es muy necesario. Este artículo presenta el diseño y la implementación de un sistema de gestión de derechos basado en el modelo RBAC (control de acceso a políticas basadas en roles). El sistema se implementa en base a la tecnología de arquitectura J2EE. Y analice cómo controlar el acceso y los permisos a los sistemas de aplicaciones. 1 Diseño de arquitectura J2EE Utilice la arquitectura de plataforma empresarial J2EE para crear un sistema de gestión de permisos. La arquitectura J2EE incorpora ideas avanzadas de arquitectura de software y presenta modelos de aplicaciones distribuidas multicapa, componentes reutilizables y basados en componentes, modelos unificados y completos y control de transacciones flexible. a. La capa de cliente es la principal responsable de la interacción persona-computadora. 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 procesa de forma centralizada el negocio 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 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 Active Directory de Microsoft). Su 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; hacer y representar los intereses de determinados usuarios Qué puede hacer el programa [1]. Generalmente existen tres tipos de políticas de control de acceso en entornos empresariales: métodos de control de acceso discrecional, métodos de control de acceso obligatorio y métodos 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 difíciles 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 notables son: 1. Reduce la complejidad de la gestión de autorizaciones y reduce los gastos generales de gestión; 2. Admite de manera flexible las políticas de seguridad empresarial, tiene una gran escalabilidad y puede adaptarse a los cambios empresariales. El modelo RBAC estándar del NIST (Instituto Nacional de Estándares y Tecnología) consta de cuatro modelos componentes, a saber, el modelo básico RBAC0 (RBAC central), el modelo de jerarquía de roles RBAC1 (RBAC jerárquico), el modelo de restricción de roles RBAC2 (RBAC de restricción) y el modelo unificado Modelo RBAC3 (combinación RBAC) [1]. a. RBAC0 define el conjunto mínimo de elementos que pueden constituir un sistema de control RBAC.
En RBAC, contiene cinco elementos de datos básicos: usuarios (USUARIOS), roles (ROLES), objetos (OBS), operaciones (OPS) y permisos (PRMS). Los permisos se asignan a roles, no a usuarios; usuario, el usuario posee el rol. Cuando se asigna una función a un usuario, el usuario tiene los permisos contenidos en la función. Sesiones Una sesión es un mapeo entre usuarios y conjuntos de roles activados. RBAC0 se diferencia del control de acceso tradicional al agregar una capa de direccionamiento indirecto que brinda flexibilidad. RBAC1, RBAC2 y RBAC3 son extensiones consecutivas de RBAC0. La relación de herencia entre roles se puede dividir 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 absolutamente desordenada y permita la herencia múltiple entre roles. c. La relación de separación de funciones agregada en el modelo RBAC2. Las restricciones RBAC2 especifican las reglas obligatorias que se deben seguir al otorgar permisos de roles, otorgar roles de usuario y cuando los usuarios activan roles en un momento determinado. La separación de funciones incluye la separación de funciones estática y dinámica. d. RBAC3 incluye RBAC1 y RBAC2, que no solo proporciona relaciones de herencia entre roles sino que también proporciona separación de responsabilidades. Los elementos básicos del modelo de objetos incluyen: usuarios, grupos, roles, objetos, modo de acceso y operadores. Las principales relaciones son: asignación de permisos de roles PA (Permission Assignment), asignación de roles de usuario UA (Users Assignmen) se describen a continuación: a Objeto de control: Es un objeto que protege los recursos (Resource) en el sistema y al que se puede acceder. 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, una página web es un recurso, y los objetos como botones y cuadros de texto en la página web también son recursos y son nodos secundarios del nodo de la página web. Si desea acceder al botón, debe poder acceder al. Página web. 2. El concepto de recurso mencionado aquí se refiere a la categoría de recurso (Clase de recurso), no a una determinada instancia de recurso (Instancia de recurso). Distinguir categorías de recursos e instancias de recursos y subdividir la granularidad de los recursos es útil para determinar los límites de gestión del sistema de gestión de permisos y el sistema de aplicación. El sistema de gestión de permisos necesita gestionar los permisos de las categorías de recursos, mientras que el sistema de aplicación necesita gestionar los permisos. permisos de instancias de recursos específicos. La distinción entre los dos se basa principalmente en las dos consideraciones siguientes: por un lado, los permisos de las instancias de recursos suelen tener relevancia para los recursos. Es decir, en función de la asociación entre la instancia de recurso y el sujeto de acceso a recursos, se pueden juzgar los permisos de la instancia de recurso. Por ejemplo, en el sistema de información de gestión, los clientes de diferentes departamentos deben dividirse según las áreas comerciales. Las áreas A y B deben modificar el recurso controlado de datos del cliente, entre los cuales la "información de datos del cliente" pertenece a esta categoría. de recurso. Si se especifica que el área A solo puede modificar los datos del cliente administrados por el área A, entonces es necesario distinguir la propiedad de los datos. Los recursos aquí pertenecen a la clase de instancia de recurso. El perfil del cliente (recurso) en sí debe contener información del usuario (los datos del cliente pueden contener atributos del área comercial) para distinguir las operaciones de una instancia de recurso específica que puede modificar el contenido de la información dentro de su propia jurisdicción. Por otro lado, los permisos de instancias de recursos suelen tener mucho que ver con la lógica empresarial. Una lógica empresarial diferente a menudo significa principios y estrategias de determinación de permisos completamente diferentes: 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 patrones 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. Las políticas de acceso para un mismo recurso pueden tener relaciones de exclusión e inclusión. c. Usuario: es el propietario o sujeto del permiso. 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 el juicio de lógica empresarial, se pueden realizar juicios basados en la identidad personal o la identidad del grupo. e. Rol: la unidad y transportista para la distribución de la autoridad. Los roles apoyan 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 de jefe de sección como los roles de diferentes miembros del personal comercial dentro de la sección. f. Acción: Completar la vinculación de categorías de recursos y políticas de acceso. g. Asignar permisos de roles PA: Realizar el mapeo entre operaciones y roles.