Arquitectura de seguridad: configuración para controlar la IU y privilegios (Derechos) - Basado en roles, por cuenta de usuario

5

¿Cómo implementan las grandes empresas sus requisitos de seguridad que están centralizados y se utilizan para impulsar lo que las personas pueden hacer (se les permite llamar a un determinado servicio web, enviar un pedido, etc.), así como para manejar la IU (botones de desactivación, menú opciones, campos de formulario individuales)?

Estoy considerando la arquitectura RBAC: Usuarios - > Roles, Roles - > Privilegios.

Las aplicaciones complejas con permisos basados en muchos campos-cuentas-usuarios-roles-cantidad-cantidad tendrían muchos, muchos "roles" y esto se complica a medida que aumenta el número de roles.

La administración de todas estas opciones posibles parece desalentadora, y mi experiencia previa es codificar esa lógica en la aplicación.

Ej: If (User.Roles("IsAccounting")) { btnEditOrder.enabled = false; }

Tengo la tarea de diseñar / implementar un servicio / arquitectura de seguridad que se usará como punto de autenticación / autorización común para todas / todas las aplicaciones (todas .NET, pero algunas GUI y algunas orientadas a procesos).

Esto no es posible fuera de la caja debido a la organización empresarial que se encuentra alrededor de las cuentas de los clientes y los niveles de permisos basados en montos financieros.

Ejemplo: John es un usuario y puede ver y enviar solicitudes para las cuentas "Microsoft" y "Google". Mike puede ver las solicitudes de "Microsoft" y "Google", pero solo puede enviar solicitudes de "Google".

El número de cuentas / usuarios es grande y variable.

Si sigo RBAC, habrá cientos de "roles" para acomodar todos los derechos (privilegios) requeridos. Esto no ayuda porque el objetivo final es proporcionar una herramienta GUI fácil de administrar para que los gerentes puedan asignar sus informes directos a los roles apropiados.

Estaba pensando en implementar esta pieza de seguridad con la siguiente API (borrador en pseudo-código):

UserContext securityContext = Security.GetContext(userID, userPwd);

Y el uso en la aplicación sería así: if (securityContext.RequestManager.CanSubmitRequest("Google")) {...}

De esta manera, habría miles de estos métodos 'Can (params)' para verificar permisos que no facilitan la administración ni el uso de este patrón.

Cualquier enlace / ideas / punteros son apreciados.

Es una tienda .NET, pero nada de lo que he visto de .NET (Membership / AzMan) nos dará la granularidad y los requisitos de delegación necesarios. La integración de ActiveDirectory / Oracle LDAP sería agradable, pero no necesaria.

El sistema antiguo (actual) utiliza LDAP para autenticar a los usuarios, pero toda la autorización se realiza internamente y se almacena en las tablas clásicas de "Usuarios, roles y derechos".

    
pregunta Leon 07.03.2011 - 15:41
fuente

3 respuestas

5

¿Ha mirado la autenticación basada en reclamaciones? La idea es que adjunta a cada usuario autenticado hay una colección de reclamos, y cada reclamo representa algo acerca del usuario. Cuando se autentica al usuario, se despliega una colección de reclamos para la aplicación en cuestión y puede contener un conjunto arbitrario como "CanSubmitGoogleOrders" o "PurchaseLimit = $ 4000".

La aplicación en sí solo necesita saber qué reclamos potenciales puede recibir y actuar en consecuencia si ve (o no) cualquier reclamo en particular.

    
respondido por el Steve 07.03.2011 - 17:59
fuente
5

Creo que depende mucho del uso final. Desde el principio y sin saber mucho sobre el usuario final de la aplicación, ¿ha pensado en la autenticación basada en sesión? Básicamente, verifique sus permisos y aplique algún tipo de identificador a su sesión. De esa manera, podría otorgar permisos permisibles a las solicitudes, que deberían ser más rápidos que verificar todos los permisos de los usuarios en cada solicitud. Solo tiene una tabla de búsqueda para una acción y qué sesiones se pueden usar, de esa forma podría almacenar todo de forma centralizada, lo que es mucho más fácil de administrar. Solo una nota al margen, esto es puramente una respuesta en cuanto a la facilidad de implementación / administración / velocidad, cuanto más segura quiera que sea su aplicación, obviamente, más sacrificará la velocidad. Lo que realmente impulsará su implementación es determinar el punto de equilibrio razonable entre velocidad y seguridad aceptables.

Publicaré una respuesta más larga cuando tenga más tiempo más tarde hoy.

    
respondido por el mrnap 07.03.2011 - 17:51
fuente
4

Este es realmente un problema bien conocido, y desafortunadamente no existen muchas soluciones empaquetadas todavía, al menos no realmente buenas.

El control de acceso basado en roles es solo un compromiso, entre la administración escalable y la seguridad. A menudo, esta era una buena opción, simplemente porque la alternativa era ... bueno, hasta ahora no ha habido muchas alternativas ... Siempre involucraba cantidades masivas de codificación personalizada compleja. Excepto en el caso de los requisitos de seguridad de grado militar o bancario, ese era el camino a seguir ... pero, siempre fue un compromiso en el interés de hacer que la seguridad sea manejable.

Si bien la sugerencia de autenticación basada en notificaciones de @SteveS es buena (para .NET puede consultar lo que se conoce como el Marco de Ginebra, o Windows Identity Foundation (WIF) ), y es definitivamente una mejora en la dirección de seguridad más granular, realmente no ayuda a resolver el problema de la" administración escalable ".

También puede mirar en la dirección de lo que (desafortunadamente) se conoce como "gestión de derechos", control de acceso basado en atributos / políticas (ABAC / PBAC), control de acceso sensible al contexto, etc ...
Para ese fin, puede consultar XACML - aunque definitivamente tiene defectos no triviales (incluso el próximo v3 pierde la marca ...), definitivamente es un paso sustancial en la dirección conceptual correcta. (Es solo un formato / protocolo, no está familiarizado con las herramientas estándar para hacer cumplir esto ...)

La conclusión es que, lamentablemente, todavía no hay soluciones realmente buenas para la granularidad escalable de la gestión de control de acceso. Hoy en día, aún requiere una pequeña cantidad de personalización, ya sea codificación personalizada en su aplicación o modificaciones extensas en algún producto de administración relacionado pasivamente. Tal vez alguna pequeña empresa emergente encuentre la solución para eso pronto ...
Divulgación: Estoy trabajando con una de esas empresas nuevas, para hacer que la granularidad de acceso escalable sea algo que pueda usar ...

    
respondido por el AviD 16.03.2011 - 16:15
fuente

Lea otras preguntas en las etiquetas