seguridad del sitio basada en roles: la condición del misil nuclear

7

Así que estoy en el proceso de trabajar en parte de nuestro nuevo sistema de seguridad de sitio basado en roles y he llegado a la condición de "misil nuclear".

El sistema se basa en la idea de agrupación, con la posibilidad de que los usuarios estén implicados en grupos basados en grupos actuales, como por ejemplo:

  • Tom es un maestro pastelero

  • al ponerlo en el grupo de Cake Maker, también implica que él está en el grupo de panaderos, por lo que no necesita estar físicamente en ese grupo.

  • Por implicación de estar en el grupo de panaderos, podría ser puesto en cualquier otro subgrupo de horneado.

  • Si tom se convirtió en el CEO de su panadería, se lo sacaría del grupo de horneado y se lo asignaría al grupo de CEO, lo que implica que tiene acceso a todos los grupos (horneado, pastelería, etc.). / p>

La condición del "misil nuclear" es la siguiente: soy un desarrollador web, por lo que necesito tener acceso a todos los grupos para poder probar varias condiciones y errores que pueden ocurrir durante el ciclo de vida. Pero también podría haber datos confidenciales que no debería estar viendo, esto podría pertenecer al grupo de Recursos Humanos o al grupo de Finanzas. Al implementar el sistema de misiles nucleares, significaría para mí tener acceso a las páginas en vivo, alguien del grupo de Recursos Humanos o del grupo de Finanzas tendría que proporcionar su contraseña al mismo tiempo que la mía. 2 campos de contraseña en una página.

Esta es una solución bastante divertida, pero no estoy del todo convencido de que sea práctico. ¿Cómo protege generalmente a los desarrolladores de sistemas falsos contra datos confidenciales? hash algo sensible y solo revela si la persona es en realidad un miembro del grupo que pertenece a los datos.

¿te importa?

    
pregunta Jarede 24.01.2012 - 10:38
fuente

2 respuestas

5

Una solución similar se usa para casos de emergencia, a menudo llamada solución de "rompeolas" y por lo general requiere una cuenta de nivel de administrador por separado, con una contraseña dividida en dos mitades, y documentación sobre estas contraseñas guardadas en cajas fuertes (generalmente y una caja fuerte ejecutiva)

No creo que su caso de uso califique como de emergencia, ya que podría ocurrir con bastante frecuencia, por lo que lo que encuentra es mucho más común si se implementan controles a nivel de personal, entre ellos:

  • verificación más estricta
  • el registro de todo lo que hacen los usuarios privilegiados

Esto permite que el trabajo continúe de manera normal sin verse afectado por los controles de seguridad intrusivos, a la vez que protege a la empresa.

Por supuesto, lo anterior se aplica a los desarrolladores con acceso a live. Para los desarrolladores que ejecutan tareas de BAU, el método preferido es que solo tengan datos desinfectados. Tomarían la base de datos de la cuenta del cliente, generarían nombres y direcciones de reemplazo y los utilizarían en los entornos Dev, UAT, OAT y Pre-Prod para que Devs nunca tuviera acceso al entorno en vivo.

En los últimos 16 años, probablemente pueda contar la cantidad de organizaciones que hacen eso con los dedos de una mano, así que vuelva a subir y use la investigación y el registro. Lo siento, pero esa es la forma en que tiende a funcionar.

    
respondido por el Rory Alsop 24.01.2012 - 13:04
fuente
3

La solución que más encontré consistía en una sola capa de grupos, y como tal, sin herencia de grupo. El problema surge cuando una persona pertenece a dos o más grupos con derechos en conflicto. Entonces tiene la opción de ir en una dirección (ejemplo: acceso concedido > acceso denegado) o en la dirección opuesta.

Creo que es la forma más fácil porque, de lo contrario, podría tener problemas con la herencia de grupo (y sospecho que tendría que proporcionar una interfaz compleja para los grupos de usuarios de maming, ¿no?)

Ahora, una cosa me llamó la atención en tu pregunta:

  

Pero también podría haber datos confidenciales que no debería estar viendo,   esto podría pertenecer al grupo de Recursos Humanos o al grupo de Finanzas

Independientemente de su solución, debe trabajar con datos anónimos, no con datos reales. Si está trabajando en una copia exacta de una base de datos de producción, el primer paso para usted o (si tiene la suerte de tener una) para que el administrador de su base de datos le proporcione una copia anónima de la base de datos. Los números pueden ser aleatorios, los nombres también (hay bases de datos de nombres disponibles en línea de forma gratuita), etc.

De esa manera, no debe preocuparse por el grupo en el que se encuentra, puede estar en todos los grupos posibles o en un súper grupo heredado de todos los grupos, puede probar su aplicación web de manera segura sabiendo que no será posible aprender cuánto se le paga a tu jefe ;-)

    
respondido por el Jalayn 24.01.2012 - 10:53
fuente

Lea otras preguntas en las etiquetas