Header Ads Widget

Ticker

6/recent/ticker-posts

Cómo OAuth permite una arquitectura de confianza cero

 


Confianza cero es uno de esos términos que se puede utilizar con precisión y como palabra de moda. Los proveedores de software a menudo se refieren a sus arquitecturas de aplicaciones como "confianza cero", pero ¿qué significa eso realmente? ¿Y la aplicación en cuestión realmente emplea confianza cero? ¿O simplemente aplica los comportamientos aproximados de la confianza cero?

Hoy, vamos a discutir qué es la arquitectura de confianza cero y cómo se relaciona con la seguridad. Veremos cómo OAuth, un sistema omnipresente en el espacio de API, puede habilitar este enfoque arquitectónico. Echaremos un vistazo a dos flujos para ver cómo emplean conceptos de confianza cero para proteger la API y sus usuarios.

¿Qué es la arquitectura de confianza cero?

La confianza en el entorno empresarial gira en torno a si se puede o no confiar intrínsecamente en los elementos de la misma organización. Esta base de la fe proviene de la naturaleza del elemento en sí, no de cualquier cosa que lleve o pueda hacer. Los elementos dentro de la misma empresa a menudo se consideran confiables ya que provienen de la misma organización; por ejemplo, si el personal de la división de ventas necesita tocar los registros de pedidos, en una organización de confianza, los datos se pueden extraer del almacén de datos debido a la naturaleza misma de la solicitud concede el acceso. Después de todo, si la solicitud proviene del interior de la organización, se debe confiar en ella, ¿verdad?

Una arquitectura de confianza asume que cualquier persona que actúa internamente lo hace de buena fe, que las credenciales de sus clientes no se violan, no se utilizan indebidamente y que la solicitud está dentro de los derechos del solicitante. El problema es que esto no siempre es cierto: es más común en el espacio web moderno tener solicitantes que no actúan de buena fe. En respuesta a esto, muchas organizaciones han comenzado a cuestionar la naturaleza de la confianza en sí misma y si alguna vez debería usarse como método para otorgar acceso.

Debido a esto, un concepto conocido como confianza cero está ganando terreno entre los desarrolladores modernos. Acuñado por John Kindervag de Forrester Research , el enfoque de confianza cero supone que un mal actor puede violar cualquier elemento de una organización y, en consecuencia, que no se debe confiar en ningún elemento. De hecho, la confianza cero va un paso más allá, afirmando que la confianza debe eliminarse por completo. Esencialmente, este enfoque puede considerarse como "no confiar en nadie, asumir que todos son actores de mala fe y verificar siempre".

Elementos centrales de la arquitectura de confianza cero

Hay varios elementos comunes a cualquier marco basado en el modelo de confianza cero. En primer lugar, se debe definir la superficie de ataque. La superficie de ataque son todos los puntos potenciales de ataque o entrada que pueden crear diversas amenazas dentro de la red; es importante delimitar y documentar estos. La superficie de ataque se puede clasificar aproximadamente utilizando el concepto DAAS: datos, activos, aplicaciones y servicios. Cada una de estas categorías representa un tipo de superficie que podría amenazar la red y, más específicamente, proporcionar un punto de partida para el siguiente paso de establecer una arquitectura de confianza cero.

Una vez que se han delineado los puntos DAAS que componen la superficie de ataque, es necesario definir el flujo de transacciones. La simple realidad es que el lugar donde el atacante comienza a ingresar a la red rara vez es la ubicación real del objetivo; un punto de ingreso puede ser solo el comienzo de un flujo completo. Comprender el flujo de datos y los recursos que tocan puede ayudarlo a ver dónde pueden comenzar y progresar los flujos de ataques potenciales, lo que le brindará una comprensión integral de los riesgos potenciales.

Ahora que tiene este conocimiento, las políticas en torno a la gestión del tráfico y la comunicación se pueden diseñar con un enfoque en mantener la arquitectura y garantizar que cualquier nuevo desarrollo, interacciones, etc., no infrinja el enfoque de confianza cero. La confianza cero solo es útil si el sistema mantiene el mismo enfoque de confianza en todos los ámbitos.

Autenticación y flujos basados ​​en tokens en un sistema de arquitectura de confianza cero

La utilización de un sistema de autenticación basado en tokens como OAuth puede ayudar a crear una arquitectura de confianza cero. En una arquitectura de este tipo, cada usuario debe ser entendido dentro del contexto de sus solicitudes. En consecuencia, aspectos como si el usuario es interno o externo, dónde se encuentran los datos que se solicitan, qué servicio está solicitando qué a quién, etc., son datos increíblemente importantes que deben rastrearse a lo largo de la totalidad del flujo de solicitudes. . Un token es esencialmente una combinación de marcadores de datos que resumen estos factores de acuerdo con cómo los ve el sistema emisor. Como tal, la confianza cero puede aprovechar estos tokens para hacer cumplir el comportamiento.

En su forma más simple, un sistema basado en tokens otorga tokens diferenciados según el propósito del usuario y su solicitud. Como todos los recursos no son iguales (y, más específicamente, tampoco lo son los solicitantes de esos recursos), los tokens se pueden utilizar mejor para proporcionar acceso diferenciado. Los elementos adicionales en OAuth, incluida la autenticación multifactor y el inicio de sesión único federado, se pueden aprovechar además del sistema de token base para controlar aún más este flujo de solicitud y utilización, creando un entramado de confianza cero.

Hemos analizado varios flujos de OAuth en el pasado ; echemos un vistazo a cómo dos de ellos habilitan una arquitectura de confianza cero.

Flujo implícito

En el flujo implícito, el cliente solicita autorización de un servidor OAuth, donde el usuario se autentica y el token se emite en respuesta. Si bien esto puede parecer un flujo relativamente confiable, la confianza cero existe en un aspecto muy específico de cómo se genera el token y cómo funciona: el redirect_uriparámetro.

Este parámetro es bastante simple, pero indica claramente dónde se enviará la respuesta a las solicitudes. Esto significa que las solicitudes no se envían al cliente que las solicita solo porque es el cliente quien las solicita, sino que se envían al cliente si el cliente es realmente quien dice ser. Para decirlo de otra manera, supongamos que tenemos un cliente que ha sido tomado por un actor malintencionado. Este actor ha utilizado un conjunto de credenciales en un cliente para acceder a los recursos y está intentando exfiltrar datos. Cuando el actor malintencionado intenta acceder a los datos utilizando el flujo implícito, solicita la salida directamente.

El servidor, sabiendo que redirect_uriestá configurado, decide “No voy a reenviar estos datos a este cliente, voy a dirigir estos datos al cliente especificado en el redirect_uri”. Si ese cliente coincide con el cliente solicitante, ¡maravilloso! El sistema ha funcionado según lo previsto. Sin embargo, si el cliente no coincide con la solicitud del cliente (como es el caso de nuestro actor malicioso teórico), la función aún se lleva a cabo, pero la salida nunca se entrega al actor malicioso, ya que no están definidos en el redirect_uriparámetro .

En pocas palabras, este parámetro es un elemento seguro conocido, por lo que no importa lo que suceda con el cliente, la respuesta no se envía al cliente sino a la URL de confianza. De esta manera, si hay una aplicación maliciosa que engaña a un usuario para que inicie la delegación, la respuesta va a la aplicación real y conocida.

Concesión de credenciales de cliente

En este flujo, un cliente puede solicitar un token de acceso utilizando solo sus credenciales de cliente. El cliente se autentica con el servidor de autorización y solicita un token de acceso. El servidor de autorización autentica al cliente y, si es válido, emite un token de acceso. Lo interesante de este flujo es que parece confiar, pero solo confía en algo para acceder a lo que ya puede acceder: un cliente tiene acceso a sus propios recursos, pero solo a sus propios recursos.

De esta forma, el acceso se limita solo al área en la que ya se ha comprobado la confianza. Otra forma de pensar en esto es que, en lugar de confiar en la solicitud del usuario, se confía en las limitaciones del recurso sobre quién puede solicitarlo.

Piénselo de esta manera: imagine que nuestro mismo recurso malicioso teórico está tratando de acceder a un recurso al que no tiene derechos. Según la concesión de credenciales de cliente, se le negaría este acceso independientemente de lo que pueda proporcionar, porque al final del día, su valor conocido no está vinculado a este recurso solicitado, no tiene credenciales para que se le confíe el recurso. Por tanto, no puede tocar el recurso.

La naturaleza de la confianza

Al observar estos flujos, es evidente que permiten la confianza cero, pero no dan como resultado una confianza cero. Esto se debe a que el sistema de tokens es solo la mitad de la solución; no solo importa que un token se emita de una manera específica; También importa cómo se tratan esos tokens en la red y cómo se tratan a medida que se vuelven obsoletos.

Un error común que debe corregirse aquí: un entorno de confianza cero no significa que, literalmente, todos los aspectos de la arquitectura del token en la red deben considerarse no confiables. Significa que, si bien podemos confiar parcialmente en elementos de los sistemas de generación de tokens (mientras verificamos continuamente su precisión y función), podemos cuestionar los tokens en sí mismos y aplicar protecciones específicas contra ellos.

Comportamiento del token

Un método para establecer este enfoque de confianza cero para los tokens es rastrear el comportamiento de los tokens y determinar si confiamos o no en lo que están haciendo (si no en el token en sí). Por ejemplo, se puede confiar más en un token de usuario que accede a sus propios recursos después de pasar por dos etapas de autenticación multifactor que en un token de usuario normal que solicita recursos seguros.

Yendo un paso más allá, el uso de este sistema para detectar un token que se está utilizando para solicitar muchos recursos de usuario diferentes en muchas ubicaciones, escalar el acceso, acceder a recursos que no son de usuario, etc. puede ayudar a establecer un gradiente de accesibilidad mientras se mantiene ese , aunque algunos tokens son menos sospechosos, aún están sujetos a verificación.

Además, la implementación de un seguimiento de tokens en la naturaleza puede ayudar a garantizar que el control de autenticación se mantenga estrictamente. Examinar las versiones de GitHub, los informes de errores, etc., en busca de tokens expuestos puede ayudar a los sistemas automatizados a incluirlos en la lista negra cuando se notan. Esto, en combinación con diferentes gradientes de acceso en un sistema que, por su propia naturaleza, es de confianza cero, puede brindar una mayor seguridad en toda la red.

Revocación y caducidad

Otro método para garantizar que la confianza cero se implemente de manera efectiva es tener patrones predefinidos para la revocación y el vencimiento. Como hemos demostrado aquí, la confianza puede ser un gradiente: podríamos confiar en un token por un tiempo después de que se haya demostrado que es válido, pero eso no significa que debamos confiar en él para siempre. En consecuencia, crear una situación en la que el token se utilice durante un período de tiempo muy corto y luego se invalide automáticamente puede resultar en la revocación de la confianza.

En la práctica, esto es un poco como generar una contraseña de un solo uso, que generalmente se emite solo por un corto tiempo y solo dentro de un parámetro establecido. En este caso, se confía en el token en la medida en que se le permita funcionar mientras dure su utilidad. Esto se puede usar para hacer cumplir el propósito del token; por ejemplo, si se solicita un token por un período breve, el uso de una sola aplicación, como restablecer una credencial u obtener el estado de un recurso, entonces solo debe existir para la duración de esa solicitud.

Una vez cumplida la solicitud, ¿por qué debería seguir existiendo? En ese momento, podemos simplemente revocar el token casi de inmediato para evitar un uso indebido. Dicho de otra manera, este es el desarrollador que le dice al token que "haga lo que dijo que haría y luego salga de la red".

Definición del alcance

Además de limitar la vida útil del token mediante la revocación y el vencimiento, los tokens se pueden restringir aún más mediante el uso de ámbitos establecidos. Un osciloscopio es básicamente una barandilla que permite que un token haga cosas específicas, pero no otras. Los ámbitos establecen cuál es el propósito de ese token y afirman que cualquier otra cosa está prohibida.

En un sistema confiable, si un usuario solicita tocar un recurso específico, podría decir, "ok, aquí está el acceso a ese conjunto de registros"; el problema con esto es que el conjunto de registros en cuestión puede contener un montón de otros registros a los que no desea que se acceda. A primera vista, eso puede parecer tener algún sentido, especialmente si se trata de un conjunto de registros o recursos compartidos; en realidad, sin embargo, todo lo que está haciendo es proporcionar acceso carta blanca, que es propenso al uso indebido.

Sin embargo, en un sistema que no es de confianza, la respuesta a esa solicitud sería, "ok, aquí tienes acceso solo al registro específico y los campos específicos a los que necesitas acceder". Esto es difícil de usar incorrectamente, ya que está muy claro lo que está permitido y cualquier acceso adicional está estrictamente limitado.

Un elemento de alcance adicional interesante proporcionado por la especificación OAuth es la capacidad de cambiar la definición del alcance sobre la marcha. En este método, un cliente puede solicitar un token para acceder a un recurso amplio, pero el servidor puede responder y decir, "desafortunadamente, no confiamos en que lo haga; sin embargo, confiamos en usted para acceder a este recurso específico, aquí está la ficha para eso ”. Este enfoque puede ser muy útil, ya que aplica la confianza cero al permitir que el servidor juzgue el riesgo y permite que el usuario que solicita el token obtenga aproximadamente lo que solicitó.

Conclusión

El concepto de un sistema de arquitectura de confianza cero es sólido, pero su aplicación variará según los sistemas que lo utilicen. En última instancia, el objetivo no es negar la confianza de ningún tipo, sino asumir que cada actor es una posible amenaza y, al hacerlo, verificar cada token desde esa perspectiva de amenaza. Si se implementa correctamente, la arquitectura de confianza cero puede reforzar los servicios, lo que resulta en una oferta más segura y confiable.

¿Cómo crees que OAuth habilita la arquitectura de confianza cero? ¿Perdimos algún aspecto importante? ¡Háganos saber en los comentarios a continuación!

Publicar un comentario

0 Comentarios