En el post anterior, hablamos de los elementos básicos con los que poder trabajar la autorizaciones digitales, sujetos, recursos, acciones y atributos, pues leerlo aquí.
Ahora toca hablar de alguna de las estrategias de autorización, llamadas normalmente modelos de control de acceso, y que son patrones muy maduros que nos van a permitir construir soluciones de control de acceso estándar. ¡Sin creatividades raras que nos pueden complicarnos la existencia en el futuro! ?
Recordemos que nuestro objetivo es proteger nuestros recursos u objetos digitales del acceso no deseado por parte de sujetos u otros procesos.
Los tres clásicos son:
ACL – Access Control List
Es el más sencillo, son listas que relacionan sujetos, acciones y el recurso a proteger.
Por ejemplo, David (sujeto) puede LEER (acción) el fichero1 (Recurso) ¿Puede o no puede?
Ventajas y desventajas
Ventajas.
- Si es escenario es sencillo, esto puede servir.
Desventajas.
- La administración en escenarios complejos es impracticable.
- No sabe nada del contexto, de los atributos
- Es una defensa de grano gordo, difícil matizar.
- Normalmente, el modelo sabe poco del negocio.
https://en.wikipedia.org/wiki/Access-control_list
RBAC – Role Based Access Control
El concepto de rol se suele liar mucho en las discusiones, es sencillo, pero reconozco que con tantas combinaciones de elementos atómicos, en cuanto empezamos a agruparlos en conjuntos, es fácil perderse.
Un rol es una agrupación de permisos u operaciones para un grupo de sujetos, al que además, se le suele poner un nombre que describe un papel que jugará esa relación en la organización / empresa sobre los recursos a proteger. ¡Uffff!
De otra manera…
Si tengo grupos de sujetos, por ejemplo ‘gestores de empresas’, donde están todos los empleados que realizarán operaciones de gestión y los permisos que quiero darles son LEER, ESCRIBIR, BORRAR. A esa agrupación, le podría llamar gestor empresarial (rol) y se la podría aplicar a los recursos que tengamos para empresas. De manera, que los usuarios con el rol Gestor de empresas, pueden acceder al recurso empresas con la posibilidad de hacer lecturas, escrituras y borrar recursos. Qué es lo que se espera de ellos en la organización.
Que hemos ganado respecto a los ACL, pues facilitar la administración y acercarnos al vocabulario corporativo. Los roles asignan permisos a operaciones específicas con significado en la organización. Ahora es más sencillo, saber que estamos haciendo y cometer menos errores.
Ventajas y desventajas:
Ventajas:
- Facilita la administración
- Vocabulario más cercano al negocio
- Muy utilizado para grano gordo
Desventajas:
- Depende de la implementación, los roles están hardcodeados en las aplicaciones ya que se suelen recibir en el tiempo de login. Añadir un nuevo rol en una app, implica cambiar el código de la aplicación
- Poca granularidad, intentar hacer más fina la autorización nos lleva al efecto explosión de roles, tan criticado en este modelo.
- No analiza el contexto
- La seguridad está más centrada en lo que puede hacer el sujeto que en el recurso a proteger.
https://en.wikipedia.org/wiki/Role-based_access_control
ABAC – Attribute Based Access Control
También conocida como control de acceso basado en políticas (PBAC), introduce el atributo como elemento clave en la gestión de la seguridad. Las políticas son condicionantes que se deben cumplir mediante la composiciones de atributos.
Así pues, ahora nuestro sujeto tendrá atributos, nombre, documento de identificación, fecha de nacimiento, teléfono… , los recursos tendrán un propietario, un tamaño, una ubicación, etc. Y el contexto, y esta es una gran diferencia respecto a los anteriores, una dirección IP, una hora, una lista de cuentas bancarias, etc Y con todos estos elementos podemos construir conjuntos de políticas, que a su vez tendrán políticas y que a su vez tendrán reglas.
Se considera un modelo de next generation, a pesar de que ya tienes sus añitos, porque está centralizado, es dinámico y provee de un contexto que simplifica el acceso detallado y con facilidad para aportar más inteligencia y reusabilidad.
Además el NIST, definió una arquitectura que ha sido implementada por los fabricantes y definida en estándares. Sus componentes son los siguientes
PEP (Policy Enforcement Point)
Este elemento se ubicará en el software donde queremos implicar el control de acceso, en las API, en un cliente Web…
Le pregunta al PDP, si tiene permitido el acceso o no para un sujeto, recurso, acción y contexto.
PDP (Policy Decision Point)
Es quien determina si una solicitud tendrá acceso o no. Es el motor que evalúa las políticas.
PIP (Policy Information Point)
Cuando una regla necesita enriquecerse con atributos antes de ser evaluada, se utiliza este módulo. El el encargado de agregar la información necesaria. Por ejemplo, si la política necesita comprobar el rol de usuario, irá a preguntar para el sujeto dado sus roles.
PAP (Policy Administration Point)
Es el punto de administración en el se gestionan las políticas.
El diagrama es el siguiente:
https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-162.pdf
Ventajas y desventajas
Ventajas
- La seguridad está centrada en el recurso (información digital), que debe ser el gran objetivo.
- Existe una arquitectura clara que seguir. La autenticación está separada de la autorización.
- Grano muy fino. Muchas posibilidades.
- Alta reutilización con otras aplicaciones. Este modelo es simpre centralizado y dinámico. Zero Trust.
- Es integra de maravilla en el mundo Big Data e IA
Desventajas
- Su implementación es mas costosa, esta formado por múltiples elementos.
- Las posibilidades que abre pueden ser abrumadoras. (Aplica: KISS – Keep it Simple, Stupid!)
https://en.wikipedia.org/wiki/Attribute-based_access_control
Y los matices
Realmente, y a pesar de llevamos muchos años con estos modelos, es un tema complejo y confuso. Ya que muchas veces se cruzan, un ACL puede convertirse en un RBAC básico si podemos agrupar los usuarios y ponerle un nombre de negocio. A un RBAC se le pueden agregar claims, y empieza a tener atributos como un ABAC sencillo… ¡y mil casos!
Cuando se trabaja con estos modelos, es importante, centrar la arquitectura deseada.
Las siguiente clasificación puede ayudar
Será Externa o Interna
Externalizada
- La lógica de autorización está fuera de la aplicación, por lo tanto podrá llevar su propio ciclo de vida (CI / CD).
- Reutilizable entre varias Aplicaciones
- Único punto de auditoria
Interna
- hardcode en la aplicacion, impacta en el codigo base de la app o apps que usen la librería.
Será estático o dinámico
Dinámico
- Las aplicaciones evalúan su acceso en tiempo de ejecución, proveen atributos de contexto que pueden varias.
- Arquitectura confianza cero (Zero Trust), todas las peticiones deben pasar siempre por el servicio de autorización.
Estático
- Los permisos se entregan en tiempo de inicio de sesión y se mantienen durante toda la sesión
Conclusión
Esto son pinceladas, el tema es muy extenso, son muchos los modelos que existen, según ha ido evolucionando el mundo IT se han ido incorporando los modelos.
Hoy el día, el modelo base en entornos corporativos medio y grandes debería ser ABAC, si es posible, ya que se centra en los recursos a proteger, aporta mucho granularidad y todo el contexto. Es muy apropiada sistemas de Big Data y carne de Machine Learning para optimizar la autorización, esto va a evolucionar bastante en los próximos años
Si quieres conocer más modelos, sigue estos enlaces
https://en.wikipedia.org/wiki/Attribute-based_access_control#External_links
En la proxima entrada, me centraré en software y librerias interesantes para aplicar estos modelos y estandars de definición y comunicación.
¡A darle cañaaaaa! ?