Diseño del sistema de control de acceso a la aplicación web

2

Tengo problemas para encontrar una manera escalable de crear un sistema de control de acceso que siga las mejores prácticas y pueda escalar bien. He analizado varios enfoques como RBAC y ABAC.

Para los casos de uso que me preocupan, RBAC no parece ser tan detallado como sea necesario. ABAC (y otros métodos similares como CBAC) parecen ser suficientes en cuanto a control, pero parecen introducir una sobrecarga significativa en casos complejos. La mayoría de los ejemplos y descripciones de estos casi siempre parecen aplicarse ampliamente a una actividad. Por ejemplo, alguna actividad (ejemplo: "org: activity") como las acciones basadas en CRUD. Para muchas aplicaciones que he tenido que gestionar a lo largo de los años, esto rara vez parece suficiente.

Un ejemplo podría ser el siguiente:

Resource Type tA:
 - Has fields:
 - fA
 - fB
 - fC - must be valid id of type tB
 - fD
 - fE

Resource Type tB:
 - Has fields:
 - fA - id

Role rA:
 - Can read all fields of tA
 - Can create tA
 - Can write fields tA.fB, tA.fC, tA.fD with any valid value

Role rB:
 - Can read fields fA, fB, fC, fD of tA
 - Can create tA
 - Can write fields tA.fB, tA.fC
 - When writing tA.fC the value must be a value in some subset of all possible values

Role rC:
 - Can read fields fA, fB, fD of tA
 - Can create tA (tA.fC is automatically set to valid value)
 - Can write fields tA.fB, tA.fD
 - When writing tA.fD it must be valid value in a subset of all possible values

En el ejemplo anterior, un tipo de actividad de crear y actualizar no parece proporcionar suficiente control. Solo restringir el acceso a este nivel no proporcionaría las restricciones de campo. Con ABAC parecería que una sola solicitud para realizar una actividad como "crear" o "actualizar" requeriría tanto la definición como la validación de varias políticas. Con múltiples políticas involucradas, ¿debería haber puntos de decisión separados para una sola actividad? Por ejemplo, cuando recibimos una solicitud tendríamos un punto de decisión para la actividad en su conjunto, y luego un punto de decisión que involucraría un Principal, Recurso y el valor individual para el campo en el que se escribirá?

La forma en que lo he visto hacer en el pasado es, por lo general, una lógica codificada que generalmente involucraba la verificación de un rol y luego la ejecución de algunas verificaciones relacionadas. Basándome en todo lo que he visto, estos tipos de decisiones de autorización codificadas de forma rígida se consideran antipatrones, pero no estoy seguro de cómo podría evitar tales controles de manera eficiente. Además, esta lógica se debe duplicar en el acceso a los datos y en la capa de presentación para proporcionar al usuario las opciones adecuadas para la entrada. ¿Hay algo que no entiendo bien para estos tipos de control de acceso? ¿Existe algún método que utilice ABAC, CBAC, PBAC o cualquier otro sistema de tipo de control de acceso que pueda hacer frente a este tipo de restricciones de acceso en un método bien diseñado?

    
pregunta Goblinlord 12.01.2018 - 01:55
fuente

0 respuestas

Lea otras preguntas en las etiquetas