ABAC no RBAC: Bienvenido al mundo de la seguridad contextual (IoT)
Hay muchos más atributos que se pueden obtener de una solicitud de aplicação aparentemente simple de lo que parece a primera vista. Por supuesto, existe una dirección IP. A partir del cual se puede determinar la ubicación de uno. Eso es geolocalización y, hoy en día, es una práctica bastante estándar obtener esa información. Pero de ahí también se pueden inferir otros atributos, como por ejemplo “dentro de una propiedad corporativa”. También se puede utilizar una minería de datos un poco más avanzada y determinar si la ubicación es o no típica para el usuario que intenta acceder a la aplicação.
Y eso es sólo desde una dirección IP. Los parámetros del sistema operativo y del dispositivo se pueden obtener fácilmente examinando los encabezados de la solicitud HTTP enviada para acceder a la aplicação. Cuando se trata de un navegador web, se pueden lograr huellas digitales aún más específicas y, posteriormente, compararlas con comunicaciones anteriores para determinar si "Jim" es en realidad el mismo "Jim" al que se le ha permitido el acceso en el pasado.
Toda esta información, las variables extraídas e inferidas, conforman lo que la industria de los controladores de entrega de aplicação (ADC) ha llamado “contexto” desde hace muchos años. Ese contexto es lo que informa las decisiones de seguridad, permite la innovación en la entrega y ayuda a aplicar técnicas de aceleración que mejoran la experiencia de la aplicação .
Por eso no fue sorprendente leer este artículo que declaraba la muerte de RBAC y la introducción de ABAC (Control de acceso basado en atributos). Se basa en el contexto, simplemente se describe con un acrónimo mucho más atractivo que se pronuncia un poco mejor (y suena como algo mucho más formal). El objetivo del artículo (sigue adelante y léelo, estaré aquí cuando regreses...) es realmente eliminar el rol como medio principal de autorización y reemplazo con atributos y habla más de un mecanismo de control de acceso interno o de empresa a empresa, pero el concepto es ampliamente aplicable. Se utiliza ampliamente en soluciones antifraude , por ejemplo, en las industrias bancarias y financieras. Probablemente haya interactuado con uno en el pasado cuando inicia sesión para realizar operaciones bancarias o verificar sus acciones y durante el proceso la aplicación procede a molestarlo con una de sus preguntas de seguridad, porque está iniciando sesión desde una ubicación que no es típica para usted, o está usando un nuevo dispositivo o un navegador diferente.
Dado que un porcentaje significativo de los ataques en los últimos 15 años se han atribuido a problemas de acceso a aplicação (credenciales robadas, principalmente) que resultaron en millones de dólares en fraudes y pérdida de información personal, este tipo de técnicas son cada vez más importantes para proteger los datos corporativos y de los consumidores por igual. Según el Informe sobre fraude de identidad de 2014 de Javelin Strategy & Research: Las violaciones de datos de tarjetas y los hábitos inadecuados de los consumidores en materia de contraseñas alimentan tendencias de fraude preocupantes El 61 % de las violaciones en general son el resultado de credenciales robadas.
Y ahora, dado el número cada vez mayor de “cosas” que se comunicarán con aplicaciones en todo el mundo, la necesidad de proporcionar a las “cosas” acceso a las aplicaciones es existencial.
Y eso tradicionalmente significa algún tipo de credenciales. Credenciales que pueden ser robadas y (a)utilizadas para causar estragos en sistemas, redes y datos internos.
Ahora bien, no conozco ninguna organización que esté considerando seriamente asignar todo lo que pueda ser necesario para permitir el acceso a un rol. La escala necesaria para lograrlo es posible, pero no práctica. Además, asignar identidades individuales a todas y cada una de las “cosas” parece un desafío insuperable; matemáticamente un límite* que nunca se podrá alcanzar. Pero el hecho es que esas cosas (y sus propietarios) necesitarán acceso a las aplicaciones, al menos algunas de las cuales pueden estar en su centro de datos. Aplicaciones que lo activan, lo controlan y lo informan.
Es importante tener esto en cuenta antes de la implementación. Antes de la disponibilidad general. Antes de que millones de consumidores tengan su “cosa” intentando acceder a esas aplicaciones.
Piense en cómo va a proporcionar acceso seguro ahora, antes de que se convierta en un problema. Diseñe una solución que se base en el contexto, en los atributos, antes de que requiera actualizaciones de firmware o software para miles de dispositivos.
El proveedor de una interfaz de red (Ethernet, Bluetooth, etc.) puede identificarse mediante las direcciones MAC . Esa es una información muy pertinente a la hora de solucionar problemas en una red local, especialmente si el ingeniero u operador puede identificarla fácilmente en una captura de paquetes. Habrá oportunidades con “cosas” que ofrezcan el mismo tipo de identificación basada en atributos que puedan ayudar a diseñar e implementar un sistema ABAC. No se trata de direcciones MAC, que no persisten fuera del dominio local, sino de otros atributos de identificación de dispositivos que pueden integrarse en el intercambio de comunicaciones y ser utilizados por los guardianes de acceso para determinar la legitimidad.
Y dada la cantidad de cosas que tendrás que identificar si estás jugando en el juego de IoT, querrás diseñar e implementar uno.
Entonces, si está incursionando en IoT (y los datos de nuestro próximo informe State of Aplicação Delivery 2016 indican que muchos de ustedes lo están haciendo), realmente no es demasiado pronto para comenzar a considerar cómo va a administrar el acceso de manera segura. Llámalo contexto, llámalo ABAC, llámalo de otra manera. Pero como sea que lo llames, no lo llames algo que olvidaste considerar y poner en práctica.
*Está bien, lo admito. De hecho, mi especialización universitaria fue en matemáticas. Allá. Ya lo he dicho.