¿Cuáles son las ventajas / desventajas del control de acceso basado en atributos?

La búsqueda simple en Google te dará la respuesta a esta pregunta.

Los vendedores como Axiomatics están más que dispuestos a responder la pregunta.

El gobierno de los EE. UU. también tiene una opinión

Es posible que te hayas perdido 1 Raindrop a menos que sigas el campo, pero creo que responde a tu pregunta muy bien:

  

Me parece que el valor de XACML y ABAC está realmente en los casos de uso que habilitan. Está enfocado hacia el exterior y desbloquea el valor a través de nuevos tipos de servicios. . . .

El resumen es que ABAC le permite expresar una política de control de acceso rica y compleja de manera más simple. La mayoría de las políticas de control de acceso (le estoy mirando a usted, RBAC) dependen de "alguien" en algún lugar que actualice una política a medida que los empleados pasan de un trabajo a otro o de una responsabilidad a otra. Las personas se agregan para necesidades temporales y nunca se eliminan. Hay un gran back-end para implementar la política.

El ejemplo más simple y genial que puedo citar proviene de un ejemplo del mundo real. Resulta que los porteros / camareros en un bar estaban revisando la identificación y estaban memorizando / copiando la información de mujeres lindas. Luego acosaban a las mujeres o esperaban hasta que las mujeres hubieran bebido lo suficiente para que su juicio se viera afectado y les ofrecieran ir a casa. Esta es una oportunidad para que ocurra una cosa mala . La barra implementó una solución ABAC. Cuando las mujeres ingresaron, enviaron su identificación a una máquina que emitía un brazalete o etiquetaba la tarjeta de crédito como mayor o menor de 21. La única información que tenía el camarero era si la persona era legítima para recibir alcohol; el control de acceso (al alcohol) se decidió basándose en un único atributo (mayor / menor de 21), sin revelar ninguna información adicional.

ABAC, si se implementa como parte de una infraestructura de identidad, significa que cuando Mark Wallace se traslada del grupo de desarrolladores al grupo del administrador del proyecto, sus derechos de control de acceso se actualizarán porque cambió de supervisor, estación de trabajo y título de trabajo, no porque alguien recordó que tenía permisos de administrador y se tomó el tiempo de actualizar un archivo de configuración en algún lugar. El departamento de recursos humanos considera que es muy importante hacer un seguimiento de quién es mi supervisor y tienen un gran interés en mantener esa información actualizada; mis permisos fluyen de ese tipo de decisiones orgánicas.

¿Desventajas? No hay muchas implementaciones porque todavía es algo nuevo y porque solo obtiene los beneficios completos cuando implementa suficiente infraestructura. Los proveedores siguen jugando con la implementación correcta de los protocolos correctos. Queda mucho por resolver.

Como una extensión de la respuesta anterior, quiero agregar que definitivamente hay desventajas ([filosóficamente] no hay nada sin él). Veo lo siguiente:

• Esfuerzo para definir políticas: debe invertir en la identificación de los atributos que son relevantes para tomar decisiones de AuthZ y las políticas de menta de ellos. Esto podría ser mucho más difícil que simplemente definir roles.
• Capacitación del usuario: todos pueden convertirse en administradores de una solución ABAC, al menos para sus propios datos. No solo hay un personal de administración dedicado que se ocupa de los problemas de AuthZ.
• esfuerzos de implementación técnica. No puede comprar una solución ABAC de instalación y ejecución. Los enfoques existentes como LDAP (idealmente) no requieren codificación personalizada en su software o COTS. Esto es diferente con ABAC porque cada PEP necesita pedir un PDP y no conozco ningún software existente que lo admita, ni siquiera con estándares como XACML.

Mark C. Wallace en la otra respuesta ha dado una excelente explicación. Aquí, intentaría dar algo de mi perspectiva personal (y filosófica) al respecto.

• Eliminación de humanos del bucle: Aunque no completamente, ABAC elimina (reduce con más precisión) los humanos del bucle de control de acceso al vincular los atributos del usuario directamente con la política a los permisos. En RBAC, siempre necesitamos un usuario administrativo para agregar / eliminar usuarios regulares de roles. Esta sobrecarga administrativa es posiblemente la mayor penalización que pagamos al adaptar RBAC.

• Establecimiento del enlace faltante: Aunque RBAC no habló sobre ellos, todavía existe una noción implícita de atributos. Los cambios de atributos son la razón detrás de los cambios en la asignación de roles. En RBAC, los administradores mantienen manualmente estos cambios mientras asignan o desasignan usuarios a un rol. ABAC reconoce estos atributos como el enlace faltante y destaca su presencia en la decisión de control de acceso. Por lo tanto, ABAC proporciona más transparencia al razonar sobre el control de acceso.