La principal desventaja de RBAC es lo que más a menudo se llama "explosión de rol": debido al número creciente de roles diferentes (en el mundo real) (a veces las diferencias son solo muy pequeñas), se necesita un número creciente de roles (RBAC) para encapsular correctamente los permisos (un permiso en RBAC es una acción / operación en un objeto / entidad). La gestión de todos esos roles puede convertirse en un asunto complejo.

Debido a las opciones de abstracción que forman la base de RBAC, tampoco es muy adecuado para administrar derechos individuales, pero esto generalmente se considera un problema menor.

La alternativa típicamente propuesta es ABAC (Control de acceso basado en atributos). ABAC no tiene roles, por lo tanto, no hay explosión de roles. Sin embargo, con ABAC, obtienes lo que la gente ahora llama "explosión de atributo". Los dos temas son diferentes en los detalles, pero en gran medida son los mismos en un nivel más abstracto. (Un cínico podría apuntar a la saturación del mercado para las soluciones RBAC y la necesidad resultante de una solución de control de acceso "más nueva" y "mejor", pero esa es otra discusión).

Hay problemas diferentes con RBAC, pero como dice Jacco, todo se reduce a explosiones de roles.

RBAC es:

• centrada en la identidad, es decir, se centra en la identidad del usuario, la función del usuario y, opcionalmente, el grupo de usuarios
• típicamente administrado por completo por el equipo de IAM
• admin-time: los roles y permisos se asignan en el momento de la administración y en vivo durante el tiempo que se prevén.

¿Qué no es tan bueno con RBAC?

• es de grano grueso. Si tiene un rol llamado médico, entonces le dará un permiso al doctor para "ver el historial médico". Eso le daría al médico el derecho de ver todos los registros médicos, incluido el suyo. Esto es lo que lleva a la explosión de roles.
• es estático. RBAC no puede usar información contextual, por ejemplo, hora, ubicación del usuario, tipo de dispositivo ...
• ignora los metadatos de recursos, por ejemplo, propietario de expediente médico.
• es difícil de administrar y mantener. Muy a menudo, los administradores seguirán agregando roles a los usuarios pero nunca los eliminarán. Terminas con usuarios que docenas, si no cientos de roles y permisos
• no puede atender la segregación dinámica del trabajo.
• se basa en código personalizado dentro de las capas de aplicación (API, aplicaciones, DB ...) para implementar controles más precisos.
• Las revisiones de acceso son dolorosas, propensas a errores y largas

¿Es ABAC la solución?

ABAC (Control de acceso basado en atributos) es la siguiente generación en el manejo de autorizaciones. Está dirigido por los gustos de NIST y OASIS , así como las comunidades de código abierto (Apache) y los proveedores de IAM (Oracle, IBM, Axiomatics ).

ABAC se puede ver como una autorización que es:

• Externalizado : el control de acceso se externaliza desde la lógica empresarial
• Centralizado : las políticas de control de acceso se mantienen centralmente
• Estandarizado : las políticas de control de acceso utilizan XACML, el eXtensible Access Control Markup Language, el estándar definido por OASIS e implementado por la mayoría de las soluciones ABAC
• Flexible : ABAC se puede aplicar a API, bases de datos y más
• Dinámico : las decisiones de acceso se toman dinámicamente en tiempo de ejecución
• Basado en contexto / Basado en riesgo: ABAC puede tomar en cuenta el tiempo, la ubicación y otros atributos contextuales al tomar decisiones.

ABAC proporciona:

• una arquitectura con la noción de un punto de decisión de políticas (PDP) y un punto de aplicación de políticas (PEP)
• un lenguaje de política (XACML)
• un esquema de solicitud / respuesta (JSON / XACML)

Use la herramienta adecuada para el trabajo como dicen. RBAC, como cualquier modelo de control de acceso, tiene sus debilidades. Muchos son bien entendidos, incluso discutidos por el equipo original de NIST que enmarcó el modelo.

enlace

Sin embargo, hubo algunas inexactitudes en la respuesta de David Brossard. Por ejemplo ...

  

yo Es estático. RBAC no puede usar información contextual, por ejemplo, hora, ubicación del usuario, tipo de dispositivo ...

Las restricciones se aplican comúnmente durante la activación de usuarios, roles y permisos en RBAC. Por ejemplo, colocar restricciones temporales en la activación de un rol. De hecho, INCITS 494 prescribe su uso:

5.4 RBAC Policy Enhanced Constraints

Las restricciones mejoradas van más allá del estándar INCITS 359 RBAC al incluir tipos adicionales de restricciones. Las restricciones en los roles pueden ser estáticas o dinámicas. Las restricciones estáticas se aplican fuera de línea antes de que el usuario active la función. Las restricciones dinámicas se aplican en línea después de que se activan los roles. Estas restricciones dinámicas mejoradas pueden introducir atributos en el entorno RBAC.

INCITS 494-2012, pág. 8

  

II. No puede atender a la segregación dinámica del trabajo.

RBAC admite restricciones de SoD dinámicas. De la especificación:

Separación dinámica de relaciones de servicio La separación estática de las relaciones de trabajo reduce el número de permisos potenciales que pueden estar disponibles para un usuario al colocar restricciones en los usuarios que pueden asignarse a un conjunto de roles. Las relaciones de separación dinámica de tareas (DSD), como las relaciones SSD, están destinadas a limitar los permisos que están disponibles para un usuario. Sin embargo, las relaciones de DSD difieren de las relaciones de SSD por el contexto en el que se imponen estas limitaciones. Las relaciones SSD definen y colocan restricciones en el espacio total de permisos de un usuario. Este componente del modelo define las propiedades de DSD que limitan la disponibilidad de los permisos sobre el permiso de un usuario espacio al colocar restricciones en los roles que se pueden activar dentro o a través de las sesiones de un usuario.

ANSI INCITS 359-2004, p. 10

  

III. Se basa en código personalizado dentro de las capas de aplicación (API, aplicaciones, DB ...) para implementar controles más precisos.

Esta afirmación confunde un poco porque antes usted declaró que RBAC es de grano grueso.

¿Quiere decir que debe escribirse un código personalizado porque los controles RBAC no satisfacen adecuadamente los requisitos de seguridad para la autorización?

¿Dónde están las especificaciones funcionales publicadas de ABAC? ¿Dónde están el modelo estándar de objeto (datos) y funcional (api) para calcular (y almacenar) sus decisiones?

¿Quizás es mejor usar una implementación ABAC no estándar y comprobada que un widget de aplicación personalizado? Si eso es lo que estás diciendo, entonces estoy de acuerdo, pero ninguno de los dos es ideal.

ABAC tiene su lugar al igual que RBAC. Saber cuándo usar uno, el otro, o ambos, es importante. Comprender las limitaciones y fortalezas de cada uno es crucial antes de abordar adecuadamente los desafíos que enfrentamos como profesionales de la seguridad.