Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Tipos de control de acceso
Puede utilizar dos modelos ampliamente definidos para implementar el control de acceso: el control de acceso basado en roles (RBAC) y el control de acceso basado en atributos (ABAC). Cada modelo tiene ventajas y desventajas, que se analizan brevemente en esta sección. El modelo que debe utilizar depende de su caso de uso específico. La arquitectura que se describe en esta guía es compatible con ambos modelos.
RBAC
El control de acceso basado en roles (RBAC) determina el acceso a los recursos en función de un rol que normalmente se alinea con la lógica empresarial. Los permisos se asocian al rol según corresponda. Por ejemplo, una función de marketing autorizaría a un usuario a realizar actividades de marketing dentro de un sistema restringido. Se trata de un modelo de control de acceso relativamente sencillo de implementar porque se ajusta bien a una lógica empresarial fácilmente reconocible.
El modelo RBAC es menos eficaz cuando:
-
Tiene usuarios únicos cuyas responsabilidades abarcan varias funciones.
-
Tiene una lógica empresarial compleja que dificulta la definición de las funciones.
-
La ampliación hasta alcanzar un tamaño grande requiere una administración y una asignación constantes de los permisos a las funciones nuevas y existentes.
-
Las autorizaciones se basan en parámetros dinámicos.
ABAC
El control de acceso basado en atributos (ABAC) determina el acceso a los recursos en función de los atributos. Los atributos se pueden asociar a un usuario, un recurso, un entorno o incluso al estado de la aplicación. Sus políticas o reglas hacen referencia a los atributos y pueden usar la lógica booleana básica para determinar si un usuario tiene permiso para realizar una acción. Este es un ejemplo básico de permisos:
En el sistema de pagos, todos los usuarios del departamento de finanzas pueden procesar los pagos en el punto final de la API /payments
durante el horario laboral.
La pertenencia al departamento de finanzas es un atributo del usuario que determina el acceso al/payments
. También hay un atributo de recurso asociado al punto final de la /payments
API que permite el acceso solo durante el horario laboral. En ABAC, el hecho de que un usuario pueda o no procesar un pago viene determinado por una política que incluye la pertenencia al departamento de finanzas como atributo de usuario y la hora como atributo de recurso de/payments
.
El modelo ABAC es muy flexible y permite tomar decisiones de autorización dinámicas, contextuales y granulares. Sin embargo, el modelo ABAC es difícil de implementar inicialmente. La definición de reglas y políticas, así como la enumeración de los atributos de todos los vectores de acceso relevantes, requieren una importante inversión inicial para su implementación.
Enfoque híbrido RBAC-ABAC
La combinación de RBAC y ABAC puede proporcionar algunas de las ventajas de ambos modelos. El RBAC, al estar tan alineado con la lógica empresarial, es más fácil de implementar que el ABAC. Para proporcionar un nivel adicional de granularidad a la hora de tomar decisiones de autorización, puede combinar el ABAC con el RBAC. Este enfoque híbrido determina el acceso combinando el rol de un usuario (y sus permisos asignados) con atributos adicionales para tomar decisiones de acceso. El uso de ambos modelos permite una administración y asignación de permisos sencillas y, al mismo tiempo, permite una mayor flexibilidad y granularidad en lo que respecta a las decisiones de autorización.
Comparación de modelos de control de acceso
La siguiente tabla compara los tres modelos de control de acceso analizados anteriormente. Esta comparación pretende ser informativa y de alto nivel. El uso de un modelo de acceso en una situación específica puede no estar necesariamente correlacionado con las comparaciones realizadas en esta tabla.
Factor |
RBAC |
ABAC |
Híbrido |
Flexibilidad |
Medio |
Alta |
Alta |
Simplicidad |
Alta |
Baja |
Medio |
Granularity (Grado de detalle) |
Baja |
Alta |
Medio |
Decisiones y reglas dinámicas |
No |
Sí |
Sí |
Conscientes del contexto |
No |
Sí |
Un poco |
Esfuerzo de implementación |
Baja |
Alta |
Medio |