Tema 3.4: Arquitecturas Software para Autorización

Transcripción

1 Tema 3.4: Arquitecturas Software para Autorización

2 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.

3 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).

4 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).

5 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.

6 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.

7 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.

8 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).

9 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, s, Routing de peticiones para los autorizadores. Delegaciones de responsabilidad (e.g. vacaciones).

10 En las aplicaciones: Enfoque dominante. Dónde autorizar? (1) 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.

11 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.