Seguridad no basada en roles?

Question

Esta es una pregunta discutible ya que no estoy en este proyecto más, pero sigue molestando. Me pregunto si alguien tiene una mejor idea para referencias futuras y buenas prácticas generales de programación.

El enfoque del libro de texto para la seguridad es la "seguridad basada en roles". Cada pantalla, informe u otra tarea está asociada a uno o más roles; cada usuario está asignado a uno o más roles; y luego cada usuario puede ejercitar las pantallas, etc. que coinciden con sus roles y nada más. ¿Derecha?

Hace algunos años dirigí un equipo que desarrolló un sistema para administrar manuales técnicos militares. Cada manual tenía un "administrador de contenido técnico", la persona responsable de escribirlo o editarlo; un "gerente de stock", responsable de llevar un registro de las copias y enviarlas; y un "gerente administrativo", responsable del presupuesto y que, por lo tanto, decidió con qué frecuencia se revisaría el libro, cuántas copias se imprimirían, y así sucesivamente. Por supuesto, cada libro tenía un grupo de personas que ordenarían copias y las leerían. (Como este era el ejército, tenía que estar autorizado para tener en sus manos un libro, autorizaciones de seguridad y todo eso.) Normalmente no nos preocupamos por los lectores reales, sino más bien por las personas en cada base que administraban las bibliotecas , pero eso no es realmente relevante aquí.

Entonces ... estos son "roles" obvios, pero un rol estaba ligado a un libro en particular. Una persona podría ser el administrador de contenido técnico para el libro A, el administrador administrativo del libro B y un lector de otros 50 libros. Entonces, realmente no podríamos decir que un usuario tenía "un rol". Cada usuario tenía roles diferentes para cada libro.

Además de esto había más privilegios de rutina a nivel de sistema: Tuvimos un par de administradores de sistemas autorizado para actualizar nada en el systeem, las personas de mesa de ayuda que podían ver casi cualquier dato pero no actualizar, etc.

Terminé creando una base de datos como esta. (Para evitar entrar en algunos de nuestra terminología extraña que voy a cambiar algunos nombres de campo y de mesa aquí, la idea es la misma.)

Persona (person_id, nombre, etc.)

Technical_Manual (manual_id, título, admin_manager_person_id, stock_manager_person_id, content_manager_person_id, etc)

Authorized_Reader (manual_id, person_id, etc)

usuario (user_id, admin_role, etc)

yo no estaba muy contento con este esquema, ya que significaba que la seguridad se dividía en tres tablas: la tabla technical_manual, la tabla authorized_reader y la tabla de usuarios. Pero ... ¿había una manera más limpia de haberlo hecho? Alguna mejor idea?

Answer 1

La forma en que he hecho recientemente algo vagamente similar a esto termina pareciéndose a:

Person (person_id, name, etc) 

Role (role_id, name [admin manager, stock manager, content manager, authorized reader, etc]) 

Technical_Manual (manual_id, title, etc) 

Technical_Manual_Role (manual_id, person_id, role_id) 

Además, en mi sistema, los roles son conjuntos de permisos en su mayoría sólo predeterminados y los permisos de usuario para acciones específicas (Leer , Editar, Mover, Eliminar, etc.) se puede hacer que varíen hacia arriba o hacia abajo desde la línea base para su rol.

Answer 2

Sé que esto puede parecer un poco kludgy, pero que podría ser algo como esto:

Roles(role_id, etc)

Technical_Manual(manual_id, acceptable_roles, etc) donde acceptable_roles es una lista delimitada por

Luego, en su programa, dividir la lista delimitada . No digo que esta sea la MEJOR manera, pero funcionaría. Aunque, no sé si sería lo mejor para una aplicación militar :)

Answer 3

El problema de ajustar todo a la fuerza en el patrón de "roles" es la logística/volúmenes/carga de trabajo para mantener el conjunto completo de las reglas de seguridad en el caso en que esas reglas sean muy "precisas".

Por definición, me refiero al caso en el que hay una gran cantidad de posibles factores discriminatorios en cualquier decisión de autorración, y para cada factor discriminatorio (por ejemplo, "cantidad de crédito solicitada por el cliente"), hay rango potencialmente grande de "valores" (por ejemplo, hay 25 rangos distintos de cantidad de crédito solicitados).

Supongamos que existen tres factores discriminatorios, cada uno con un rango de siete valores posibles (7 intervalos distintos de cantidad de crédito). Entonces tendría que definir 7 * 7 * 7 = 343 roles. Luego, para cada usuario individual de su sistema, debería asignar el subconjunto completo de todas las funciones que ese usuario puede realizar. Si un usuario está autorizado a decidir sobre una solicitud de crédito de 50.000.000, entonces es bastante probable (¡pero no es absolutamente seguro!) Que también esté autorizado a decidir sobre una solicitud de crédito de 5.000.000.

Es por eso que en mi proyecto, las instalaciones relacionadas con la seguridad están limitadas a identificación (userid) y autenticación (usercertificate). No hay disposiciones de ningún tipo para la autorización. Esos deben abordarse a través de restricciones definidas por el usuario.

Answer 4

Puede tomar un enfoque más basado en reclamos a la autorización.

podría haber algunos permisos generales que cada usuario puede o no tener (es decir, administrador) que podrían estar directamente asociados a un rol. y usaríamos su tabla para hacer coincidir un usuario particular con las publicaciones a las que tienen derechos avanzados, y crear reclamos para esas entradas.

por lo que cuando se solicita la autorización de un usuario, se obtiene una colección de reclamos, algunos de alto nivel derivados de los roles, y algunos específicos de la publicación, derivados de sus tablas.

Answer 5

comentario sobre la respuesta del Caos:

Se me ocurre que los papeles "a nivel de sistema" podría caber el mismo esquema, si manual_id para este tipo de cosas se podrían establecer en nulo o algún valor mágico. Sí, lo sé, algunas personas tienen una fuerte aversión a los nulos, pero funciona aquí. Entonces habría una sola mesa de "cosas de seguridad", y está todo limpio.

Me encontré con un montón de problemas con los tres campos de administrador. Tuvimos varias consultas como, "¿De qué libros es responsable Bob?", Que requirieron una consulta con un gran O para ir en contra de los tres campos. Lo que significaba que necesitábamos tres índices. Más tarde me di cuenta de que habría sido mejor dividirlo en una mesa separada. Pero tirando a los lectores autorizados a la misma mesa ... muchas cosas se limpian. Lanza cosas a nivel del sistema también y ... me gusta. Es fácil preguntarse "¿Qué derechos tiene Mary Jones?" así como también "¿Quién tiene los derechos sobre el manual de aviónica F-15?", "¿Quiénes son todos nuestros gerentes de contenido técnico?" etc.

Answer 6

Solo quería agregar más desde la perspectiva del concepto. Aunque RBAC (control de acceso basado en roles) parece estar de moda, hay muchos modelos como DAC, MAC que han estado disponibles para resolver el problema de control de acceso durante más tiempo (el RBAC en realidad se formalizó alrededor de 1995, mientras que otros modelo han existido durante mucho más tiempo y utilizado por el ejército). La forma en que ha explicado los requisitos Veo varios modelos en uso

1. RBAC - se usa en el caso de "roles de sistema" de los que ha hablado.
2. Control de acceso basado en atributos/políticas: se utiliza para todas las piezas relacionadas con el manual.
3. MAC: se utiliza para controlar el acceso a los manuales en la base, es decir, cada manual y usuario tiene un nivel de sensibilidad asociado y deben coincidir según criterios específicos para poder acceder.

Estos modelos se pueden expresar utilizando estándares como XACML (y se evalúan en tiempo de ejecución mediante implementaciones de motor de política) que pueden describir la política. Por ejemplo, en su caso, la política sería algo a lo largo de la línea de

(Atributo basa)

Permitir que "todo el mundo" a "editar" "manual" si userid = manual.technical_content_manager

Permitir " todo el mundo" a "barco" "manual" si userid = manual.stock_manager

(RBAC)

Permitir "HelpDesk" a "vista" "info manual", "manual"

Permitir "Administrador" a "vista", "editar", "barco" "manual"

(MAC)

Permitir "todo el mundo" a "vista" "manual" si userId.level> = manual.level

Basado en el modelo de la política anterior, es claro que se necesita para realizar un seguimiento fácil de papel mapeo que se puede hacer usando la tabla y recuperado en el tiempo de ejecución para alimentar al motor de políticas en tiempo de ejecución.