Al leer sobre ACL y RBAC, parece que lo entiendo fácilmente: hay nombres de usuario o roles que tienen acceso a un activo. También puedo ver cómo podría implementarlos.

es decir, esta imagen me da una visión clara de ACL y RBAC (ya que puedo continuar y diseñar tablas de bases de datos basadas en lo anterior): (Imagen cortesía de pressbooks )

Con lo que estoy luchando es con ABAC. Varias imágenes que encontré hasta ahora son onduladas a mano o demasiado complicadas, o sugieren usar una entidad externa de terceros para hacer la Autorización. O dar ejemplos de atributos extraños que no estoy completamente seguro de cómo usar.

Ejemplo de inicio

Así que déjame comenzar con algo en la vida real. Digamos que tengo una empresa con 70-200 personas. Y mi activo para proteger es un sitio web con muchas páginas diferentes. Deseo permitir que ciertas personas accedan a ciertos activos.

Por ejemplo, quiero que una persona Leslietenga acceso a una página web llamada Price Managery le permita administrar solo los precios para el Travelgrupo de precios en esa página, pero no poder administrar los precios para el Productgrupo en la misma página. ¿Cómo implementaría esto usando ABAC?

Revisando hasta ahora, supongo que podría asignar Lesliealgunos atributos (pero ¿cuáles y cuáles son estos atributos?) Y luego tener una tabla de base de datos que los almacene. Luego puedo diseñar un motor que observe esos atributos (pero que no se vea Lesliecomo un "Rol" como se hace en RBAC), y decida a partir de ahí si otorgará o no acceso a la página. ¿Cómo se vería ese motor? ¿Es un simple bloque if / else? ¿Algo más?

¿Qué sucede si Leslie luego cambia su posición y alguien necesita cambiar su acceso? ¿Qué aspecto tendrá si necesita que se le retire Producty revoque el acceso Travel? ¿Cómo va a ser codificado si se necesita tener acceso revocado a la Price Managerpágina por completo y por lo tanto ya no tendrá acceso a ninguna Travel, o Product?

El activo en mi caso, solo para reformularlo, es Price Manager, y un usuario puede acceder a varios grupos de precios en esa página, como Travelprecios, Productprecios, etc.

Lo que estoy buscando es una hoja de ruta razonablemente completa para aclarar los detalles y hacia la implementación a donde podría ir e implementarla sin adivinar. es decir, podría completarse conceptualmente y / o tener un ejemplo específico de dónde puedo visualizar una estructura de base de datos, etc.

Bonificación: ¿Es ABAC una forma adecuada para un permiso relativamente pequeño, es decir, administrar 70-200 personas y acceder a unos 150-450 activos? ¿Será mejor apegarse a ACL / RBAC en su lugar?

Una implementación ABAC es más compleja que ACL / RBAC. Algunos marcos incluso le brindan partes de infraestructura para lidiar con esto último. Si las personas y los activos se pueden agrupar en un número relativamente pequeño y fijo de roles / categorías, entonces probablemente sea mejor quedarse con ACL / RBAC. Si los permisos difieren mucho de una persona a otra, ABAC podría proporcionar una solución mejor y más flexible.

Si elige seguir el camino ABAC, lo primero que debe hacer es pasar un tiempo leyendo y entendiendo el estándar XACML . Los ejemplos proporcionados en el documento usan sintaxis compatible con XACML y al principio son un poco difíciles de masticar. Supongo que no desea implementar una solución compatible estándar, por lo que solo necesita las ideas generales de ella.

Conceptos

XACML gira en torno a 4 conceptos y sus atributos: temas , acciones , recursos y entorno . Hay algunos más, pero estos son los más importantes. Todo lo demás está construido sobre ellos. Si tuviera que hacer una oración con estos conceptos, podría ser algo similar a: los sujetos realizan acciones sobre los recursos en un determinado entorno . Aplicar esto a su escenario se traduciría en algo como:

• Leslie abre la página web del administrador de precios.
• Leslie crea un precio de viaje utilizando la página web del administrador de precios.

Colección de atributos

Lo primero que debemos hacer es reunir los atributos relevantes de los conceptos mencionados anteriormente. Idealmente, no debe asignar ningún atributo específico ya que XACML intenta ser discreto y confiar solo en lo que el sistema proporciona de forma natural. Y entonces tenemos:

Tema

Cualquier actor, ya sea una persona o un servicio, en su sistema. Nuestro tema es Leslie. ¿Qué atributos son necesarios para identificar a Leslie de forma exclusiva? Es probable que algunos de los siguientes: first name, last name, e-mail, ssn, company id, position(s).

Acción

Cualquier acción realizada por los sujetos. Pueden ser las operaciones CRUD estándar o algo más complejo. Nuestras acciones son open/viewy create. Los atributos para estas acciones pueden ser diferentes según el marco de la aplicación web que esté utilizando. Hablaremos más sobre esto cuando lleguemos al recurso.

Recurso

Bastante autoexplicativo. Nuestros recursos son los price manager page, travel pricesy the newly created price. Podría haber más, si realmente quieres. Es posible que desee ocultar acciones que los usuarios no pueden realizar. P.ej. el create price buttonpuede ser un recurso que puede ser mostrado / oculto en función de si el usuario tiene permisos para crear los precios. Dado que la única forma en que un usuario puede ver una lista de precios podría ser a través de esta página, probablemente sería una buena idea hacer cumplir la autorización a este nivel en lugar de más abajo en la pila.

El acceso a los recursos es el más complicado de implementar, especialmente en los que provienen de una base de datos. La opción más fina es la seguridad a nivel de fila. Algunas bases de datos tienen cierto grado de soporte. Algunos implementadores de XACML han ido tan lejos como crear un superconjunto SQL. Esto realmente depende de sus necesidades de autorización, pero lo único que no desea hacer es extraer todo de una tabla y luego decidir qué mostrar. Puede agrupar recursos por conjuntos de permisos, abstraerlos detrás de una API y aplicar la autorización en los puntos finales de la API.

Ambiente

No puedo definirlo correctamente (XACML tampoco tiene una definición adecuada) pero digamos que es la "burbuja" en la que sucede todo esto. Esto incluye: web application, web server, operating system, browser, office. Se podría extraer atributos como: ip address, time of day, user locale, user agent, operating system version. Puede usarlos para bloquear incluso el acceso de usuarios desde entornos que no son compatibles con su aplicación (por ejemplo, navegadores antiguos, sistemas operativos antiguos, computadoras fuera de su red, acceso fuera del horario comercial).

Solicitud de autorización

Una vez que hemos reunido todos los atributos necesarios, los agrupamos en una solicitud de autorización y los reenviamos a una entidad que puede tomar decisiones de autorización basadas en los valores de estos atributos. En XACML lingua, el lugar donde recopila estos atributos y aplica las decisiones tomadas en ese momento se denomina punto de cumplimiento de políticas (PEP) y el punto de toma de decisiones se denomina punto de decisión de políticas (PDP). Las ubicaciones de las que se obtienen los valores de los atributos se denominan puntos de información de política (PIP). Los PEP, PDP y PIP pueden ser parte de su aplicación o pueden ser sistemas externos. Puede encontrar un diagrama de cómo se comunican entre sí en el estándar XACML.

Proceso de decisión

El proceso de toma de decisiones se basa en reglas . Las reglas se pueden agrupar en políticas que se pueden agrupar en conjuntos de políticas . Cada uno de estos tiene un objetivo . El objetivo se utiliza para decidir si alguna de las reglas se aplica a la solicitud de autorización. Piense en ello como un filtro. El objetivo contiene condiciones creadas utilizando nombres y valores de atributos. Por ejemplo, las reglas para su aplicación podrían agruparse en algo como:

Aplicación web (conjunto de políticas)
| - target: nombre-aplicación == "Aplicación web"
`- Versión 1.0 (conjunto de políticas)
    | - target: aplicación-versión == "1.0"
    `- Ver administrador de precios (política)
        | - target: web-page-name == "administrador de precios" && action-name == "view"
        `- Leslie puede ver el gerente de precios (regla)
            | - target: subject-name == "Leslie"
            `- permiso: permitir

El PDP hará coincidir todo en el conjunto anterior con los valores de atributo en la solicitud de autorización. Lo que sucede si no hay reglas que coincidan depende de la implementación de su PDP. Una vez que el PDP ha tomado una decisión ( allow, denyo not-applicable) la envía de vuelta a la PEP, que actúa sobre ella otorgando o denegando el acceso al recurso. Junto con la respuesta, el PDP puede enviar una lista obligationsy advicesla PEP debe o debe cumplir en el proceso de ejecución. Dependiendo de cómo se almacenan las reglas (archivos de texto o base de datos), un administrador puede usar un editor de texto estándar o una aplicación de edición personalizada para cambiarlos como mejor le parezca. Revocar el acceso de Leslie al gerente de precios se reanuda simplemente cambiando el permiso de allowadeny, garantizado que el PEP hace su trabajo.

Aplicación

Esto depende en gran medida de su pila de tecnología. Algunos marcos web tienen puntos de aplicación naturales (por ejemplo, ASP.NET MVC tiene filtros de atributos). Es posible que sus capas empresariales tengan que definir dichos puntos de aplicación. Me resultó más fácil aplicar la aplicación en los puntos finales de servicio (piense en microservicios) o en el nivel de UI.

Otros beneficios

Un buen efecto secundario de implementar esto es que terminas con una pista de auditoría bastante rica que puede usarse para otros fines.