¿Cómo otorgar derechos a un administrador del sistema en una aplicación?

4

Estoy diseñando un modelo de seguridad para una aplicación web que restringe el acceso a ciertas partes de la aplicación en función de los derechos y permisos que tenga el usuario. Estos derechos y permisos se agrupan en roles que cada usuario puede asignar.

Sin embargo, necesito crear una función de administrador del sistema que le dé a un usuario especial acceso completo a todo. Para abordar esto puedo hacerlo de dos maneras:

  1. Crea un rol de administrador del sistema y dale a cada uno permiso / derecho en el sistema (básicamente todos los derechos están almacenados en una tabla DB). A medida que la aplicación evoluciona y se hace más grande, el La función de administrador también debe actualizarse para que tenga acceso a la cosas nuevas.
  2. Dentro de la aplicación en sí, permito el sistema     Rol de administrador para eludir las restricciones de seguridad. Tan esencialmente     comprobará si el usuario tiene un cierto permiso, o si son un     Administrador del sistema, los dejará pasar.

La opción 1 presenta algunos problemas: podría ser tediosa y propensa a la supervisión porque cada área de la aplicación tiene Crear, Leer, Actualizar, Escribir y muchos más permisos. Tengo que incluir todas las combinaciones posibles de área de aplicación a permisos en una tabla para que el rol tenga acceso completo.

La opción 2 presenta sus propios problemas: la omisión del administrador del sistema está codificada en todas las áreas donde se necesita una restricción. Si el nombre de la función de administrador del sistema fuera a cambiar (por ejemplo, Usuario maestro), entonces tendría que actualizar el código en todas partes. Sin embargo, esta opción significa que no tengo que preocuparme por actualizar constantemente la tabla de roles para que el administrador del sistema obtenga permiso para acceder a nuevas cosas.

Estoy creando un software de clase empresarial, por lo que tiene que ser escalable con la opción que elija.

Sí, sé que esto es altamente subjetivo si se lo trata tal como está. Pero creo que debe haber algún patrón de diseño de seguridad de buenas prácticas en el que se recomiende una manera sobre la otra. Hay cosas que no puedo prever ahora que otros pueden haber encontrado. Incluso agradecería algunos enlaces a pensamientos sobre esto y una buena manera de avanzar.

    
pregunta volume one 03.06.2015 - 19:29
fuente

4 respuestas

3

¿Qué hay de usted factorizar la autorización a una sola función que toma todas las decisiones de seguridad. Las llamadas serían algo así como isAccessAllowed(user, FOO_OPERATION, <misc data>) . Luego, su verificación de administrador es un condicional único al inicio de la función isAccessAllowed .

La implementación de dicho sistema también le permite cambiar los backends de seguridad sin tener que volver a escribir su aplicación. También hace un buen trabajo al separar el código de seguridad del código de la aplicación.

    
respondido por el Neil Smithline 03.06.2015 - 20:40
fuente
1

Creo que ambas opciones son una buena manera de avanzar. Sin embargo, creo que consideras este problema del lado equivocado. Los dos inconvenientes que mencionó para usted dos problemas se pueden superar fácilmente:

  1. Para la primera opción: si consideras otorgar todos los derechos al rol de Administrador de sistemas y tienes miedo de las combinaciones, supongo que puedes hacer una doble prueba con dos ciclos, por ejemplo. (pseudo-mushy-code dentro): if($role == "Administrator") { for($i in $rights_array) { $area[$i] = true; }}

Sé que este código es bastante ridículo por el momento pero explica muy bien lo que trato de decir: no tienes que implementar manualmente cada combinación posible (área, derechos). Una vez que sus áreas y derechos se definen por separado en su base de datos, puede establecer sus valores de combinación dinámicamente en variables.

Si realmente desea almacenar sus "combinaciones de derechos" en una base de datos, también puede manejar esto automáticamente de la misma manera que con el pseudocódigo que proporcioné anteriormente. Ya codifiqué la modificación de las entradas de la tabla dinámica en el trabajo para manejar el caso en el que la aplicación evoluciona en una capa superior a la de la base de datos.

  1. Para la segunda pregunta, ¿por qué no solo agrega una columna de ID en la tabla de roles? Una columna para el id y una columna para el nombre. Luego, todo lo que tiene que hacer es modificar el nombre si sucede que es realmente necesario. Y cuando tiene que verificar su rol, solo consulta el id en lugar del nombre, lo que permite modificar el nombre sin introducir inconsistencias.

Mis 0,002 centavos :-)

    
respondido por el Shruikan 03.06.2015 - 20:15
fuente
1

¿No puede tener algo como un desencadenante en la base de datos de su tabla de roles que asegure que los permisos SysAdmin necesarios se agreguen automáticamente cada vez que se agregue una entrada de Crear, Leer, Actualizar, Escribir? es decir, su Opción 1 pero con automatización para asegurarse de que no tiene que recordar agregar manualmente los permisos necesarios. En lugar de un disparador, también podría tener un procedimiento fijo que se ejecute, por ejemplo, cada hora en la base de datos, asegurándose de que el usuario de SysAdmin tenga todos los permisos.

    
respondido por el curious_cat 03.06.2015 - 21:41
fuente
1

Lo que normalmente hago en su escenario (quizás lo llamemos opción 3), es darle acceso al rol de administrador del sistema SOLO a las partes del sistema que son específicas de ese rol. No verifique el rol de administrador del sistema en ningún otro lugar. Luego, si desea que un usuario en particular tenga acceso a todo el sistema, déle a esa persona todos los roles necesarios para un acceso completo. Las ventajas de esto son: no hay actualizaciones tediosas que hacer cada vez que agregue una nueva característica, no tiene que verificar múltiples roles en múltiples lugares, y si alguna vez decide darle acceso a alguien solo a las partes de sysadmin sin el El resto del sitio, usted puede.

Por ejemplo, suponga que tiene 4 secciones diferentes del sitio:

  1. Sección de contador: cree un rol llamado Contador que pueda acceder a esta sección.
  2. Sección ejecutiva: crea un rol llamado Ejecutivo que puede acceder a esta sección.
  3. Sección de empleados: crea una función llamada Empleado que puede acceder a esta sección.
  4. Sección de administración del sistema: cree una función llamada SysAdmin que pueda acceder a esta sección.

Ahora, a cada persona se le asignan 1-4 roles según las partes del sitio a las que se les permite acceder. En su caso, a la persona que actúa como "Administrador del sistema" se le asignarán los 4 roles, para que puedan acceder a todo el sitio.

Este método permite el mayor control sobre quién puede acceder a qué secciones, y no tiene que cambiar ningún código existente cuando agrega nuevos roles o secciones al sitio.

    
respondido por el TTT 03.06.2015 - 20:09
fuente

Lea otras preguntas en las etiquetas