Tema 3.4: Arquitecturas Software para Autorización

Tema 3.4: Arquitecturas Software para Autorización

Tema 3.4: Arquitecturas Software
para Autorización
Autorización (1)
Una aplicación puede manejar múltiples
recursos y permitir su uso por múltiples
usuarios.
Es necesario asegurar que cada usuario sólo
puede utilizar cada recurso de las formas que
le son permitidas.
Autorización (2)
Técnicas basadas en el concepto de usuarios,
grupos de usuarios y permisos.
Los permisos definen qué operaciones
pueden realizarse sobre un recurso.
Aproximaciones clásicas:
Control de Acceso Obligatorio (Mandatory Access
Control: MAC).
Reglas de autorización centralizadas y que no
pueden ser cambiadas por usuarios.
Usuarios no pueden transferir sus permisos a
otros usuarios ni directa no indirectamente.
A menudo el término MAC se utiliza para
identificar aplicaciones con fuertes restricciones
de seguridad (e.g. militares).
Autorización (y 3)
Aproximaciones clásicas:
Control de Acceso Discrecional (Discretionary
Access Control: DAC).
Usuarios pueden transferir sus permisos a otros
usuarios.
Ejemplo típico: permisos en Sistemas
Operativos Unix.
El usuario “dueño” de un recurso puede otorgar
permisos sobre él a otros usuarios.
Más utilizado que MAC en aplicaciones de
negocio, donde la seguridad es importante pero
no tan crítica y se requiere cierta
descentralización.
Puede combinarse con MAC (el SO controla el
acceso a ciertos recursos y no pueden
transferirse permisos para ellos).
RBAC (1)
Control de Acceso Basado en Roles (RBAC).
El control centralizado de reglas de acceso
cuando el número de recursos y usuarios es
grande se vuelve inmanejable.
En aplicaciones de negocio los permisos
deben ser para tareas de más alto nivel:
E.g. ‘Ver saldo de cuenta’ vs ‘Leer
contenido del fichero’.
Agrupar los permisos en “roles” con
significado a nivel de negocio.
RBAC (2)
Los Roles unen los grupos de usuarios y los
permisos en un solo concepto.
Dentro de una organización, se definen una
serie de roles. Un usuario puede jugar uno o
varios roles.
Ejemplo: jefe de proyecto, responsable de
cuenta,…
Los roles que tiene un usuario determinan a
que recursos puede acceder y cómo.
Los roles pueden establecerse en jerarquías.
Los permisos se heredan.
RBAC (3)
Las asignaciones pueden utilizar reglas que
identifican los recursos de forma indirecta:
E.g. Todo usuario puede ver su propia cuenta.
Pueden establecerse restricciones para limitar
las posibles consecuencias de la herencia de
permisos y la asignación de múltiples roles.
Ejemplo:
Posible restricción: “una persona no debería poder
autorizarse un gasto a sí misma”.
Aunque el “jefe de proyecto” sea también
“responsable de cuenta”, no puede autorizarse un
gasto extra en recursos sin que lo apruebe otra
persona con el rol “responsable de cuenta”.
RBAC (y 4)
Problemas en la práctica:
Diversidad de usuarios. Puede haber muchos
usuarios “únicos”.
Según se añaden más sistemas, el número de
roles puede explotar, haciendo el sistema
inmanejable.
Puede ser un modelo demasiado sencillo para
expresar cualquier estructura de autorización (sin
requerir una explosión en el número de permisos
y roles).
Workflows
A menudo, se utilizan workflows para
describir procesos de autorización complejos.
Puede basarse en una infraestructura de
roles, pero evita la proliferación de roles y
permisos mediante la especificación de lógica
para cada proceso de autorización.
Incluyen características tales como:
Identificar usuarios que pueden emitir solicitudes.
Identificar tipos de solicitudes que puede emitir cada
usuario.
Automatizar interfaces de interacción entre los usuarios
y el sistema: formularios web, emails, …
Routing de peticiones para los autorizadores.
Delegaciones de responsabilidad (e.g. vacaciones).
…
¿Dónde autorizar? (1)
En las aplicaciones:
Enfoque dominante.
Puede terminar habiendo tantas infraestructuras
como aplicaciones, escasamente integradas.
El número de combinaciones de autorizaciones
crece.
Las aplicaciones tienen que ocuparse de hacer
cada comprobación.
¿Dónde autorizar? (y 2)
En una capa intermedia independiente de la
aplicación:
Evitan que las aplicaciones tengan que hacer las
comprobaciones.
E.g. base de datos
Mokum.
..pero bases de datos ya no suelen ser compartidas por
las aplicaciones.
¿EII?
A veces (e.g. gestores de contenidos), esta visión
es parcialmente cierta:
Gestores de contenidos intentan ser el frontal para
acceder a todos los contenidos (no estructurados) de
una organización y proporcionan control de acceso
basado en roles y, a veces, en workflows.