Header Ads Widget

Ticker

6/recent/ticker-posts

Presentamos el modelo de madurez de seguridad de API

 



Cuando un usuario utiliza un servicio, ese usuario primero debe dar fe de que es quien dice ser. En la mayoría de los casos de uso, deben confirmar que pueden hacer lo que están tratando de hacer. Para muchos usuarios, este es un proceso relativamente poco transparente y puede parecer que sucede mágicamente detrás de escena. Sin embargo, la realidad de implementar este sistema ha dado como resultado un panorama de seguridad en constante cambio y evolución que requiere modos específicos de autenticación y autorización .

Entonces, la pregunta se hace evidente: ¿cómo podemos encapsular información sobre el usuario, sus derechos o su origen de una manera útil? ¿No sería genial si una API pudiera saber quién es usted, si puede confiar en usted y si puede hacer lo que dice poder hacer?

Estas ideas sustentan el Modelo de madurez de seguridad de API , una nueva forma de medir la seguridad de su API. Hoy, exploraremos cada capa de este modelo para ver cómo y por qué los expertos en seguridad abogan por una mejor plataforma API basada en identidad.

Jacob Ideskog , vicepresidente de Curity , presentó el modelo de madurez de seguridad API en la cumbre de la plataforma 2019 . Mira su presentación completa aquí:

Revisión: Modelo de madurez de Richardson

Jacob Ideskog, vicepresidente de Curity, inventó el modelo de madurez de seguridad de API. La idea surgió como corolario del Modelo de Madurez de Richardson . Como tal, antes de sumergirnos en el modelo de madurez de seguridad de API, primero echemos un vistazo a su inspiración.

Leonard Richardson creó el modelo de madurez de Richardson para reflejar y describir la realidad del espacio de la API RESTful . Una API puede ser similar a REST sin ser realmente RESTful. En consecuencia, el cumplimiento de REST no es una dualidad, sino más bien una serie de niveles de cumplimiento creciente.

  • Nivel 0 : El modelo de Richardson tiene cuatro niveles, aunque el primer nivel se considera "nivel cero", ya que no refleja absolutamente ningún cumplimiento de REST. Este nivel de madurez representa una API que no utiliza URI de hipermedia, a menudo tiene un único URI y un método para llamar a ese URI.
  • Nivel 1 : A medida que nos complicamos, ingresamos al Nivel uno, donde comenzamos a ver el uso de múltiples URI con interacciones simples. El punto crítico para recordar aquí es que estos múltiples URI todavía tienen un uso simple de verborrea.
  • Nivel 2 : el nivel dos es una evolución significativa, ya que cuenta con múltiples URI y múltiples formas de interactuar con esos datos. Este nivel ve API mucho más complejas que los niveles anteriores debido a la naturaleza de la verborrea utilizada para exponer los recursos, lo que permite una manipulación compleja.
  • Nivel 3 : El nivel más alto de madurez, las API en esta etapa son de hecho "REST" en el sentido de que emplean hipermedia como el motor del estado de la aplicación ( HATEOAS ). Esto da como resultado una API altamente compleja y poderosa, que cuenta con múltiples URI y la verborrea para interactuar con ellos, así como el poder detrás de los hipermedia.

Lea nuestra cobertura sobre El modelo de madurez de Richardson aquí .

El modelo de madurez de seguridad de API

Lo interesante del modelo de madurez de Richardson es que no se trata simplemente de diferentes estados de cumplimiento: representa actualizaciones acumulativas de un nivel a otro. Cada nuevo paso aprovecha las nuevas incorporaciones e incluye las ganancias anteriores. De la misma manera, el modelo de seguridad de API intenta describir la seguridad de API en niveles cada vez mayores de seguridad, complejidad y eficiencia. El modelo, como el modelo de Richardson, se mueve desde la madurez más baja hasta la más alta. Considérelo un libro de jugadas sobre cómo progresar hacia una implementación segura.

Con esto en mente, echemos un vistazo a los modelos específicos del modelo de madurez de seguridad de API, comenzando con el nivel de madurez más bajo y avanzando hacia el más alto.

Nivel 0: claves de API y autenticación básica

Este nivel es el punto de partida para la mayor parte de la seguridad, donde las API utilizan claves API y autenticación básica. Esta etapa es bastante básica. La autenticación en este nivel se basa en la noción de que quien tenga la clave debe tenerla porque es su clave y, por lo tanto, su actividad es válida. Esta “autenticación” luego se traslada a otros puntos finales y API en una red confiable, con los datos vitales transportados a lo largo de esa ruta.

Como hemos descrito anteriormente, claves API ≠ seguridad . Este tipo de protección es posiblemente un método fundamentalmente inseguro . Todo lo que hace una clave API es confirmar que quienquiera que tenga esa clave puede hacer lo que esa clave permite. No hace nada para garantizar que la persona que tiene la clave esté destinada a tenerla, la esté usando con precisión o incluso que la clave esté legítimamente autorizada y siga siendo válida. También existen preocupaciones adicionales en el sentido de que el usuario no está vinculado al recurso solicitado. La clave provendría de casi cualquier lugar siempre que sea de confianza, y esa cadena de autenticación podría, en teoría, ir a cualquier lugar dentro de la red de confianza.

Existe un problema aún más grave con este nivel de madurez; solo proporciona autenticación . La autenticación dice que eres quien dices ser (o, al menos, tienes algo que significa que eres quien dices ser). Sin embargo, lo que no hace es demostrar que usted tiene derecho a hacer esa afirmación y acceder a los recursos a los que esa persona tiene derecho. Esa sería la autorización , que es fundamentalmente diferente de la autenticación. Para tener autorización, necesitamos un sistema más complejo.

Comprenda las diferencias entre autenticación, autorización, federación y delegación .

Nivel 1: autenticación basada en token

La autenticación basada en tokens es un sistema más complejo y representa un nivel diferente de madurez de seguridad. Los tokens se utilizan en este caso para establecer que quienquiera que tenga ese token es quien dice ser. En la naturaleza, esto a menudo se construye en una especie de sistema de cuasi-autorización, ya que la posesión de un token puede verse como una autenticación de quién es la persona y cuál es su intención al tener ese token. Los tokens son como una tarjeta de identificación. Puede que no diga necesariamente que puede hacer algo, pero como tiene esa tarjeta, algunos infieren que, por lo tanto, es lo suficientemente confiable; después de todo, se ha identificado a través de un medio seguro, ¡así que debe ser confiable!

Una buena forma práctica de pensar en este nivel de madurez es enmarcarlo en términos de un flujo de trabajo de transporte realista. Digamos que es un editor de noticias. Tiene una organización interna de escritores, editores, etc. que escriben artículos, trabajan en informes, etc. Estos autores inician sesión en sus estaciones de trabajo y comienzan a enviar su contenido a una aplicación, que luego presenta el contenido a la audiencia externa.

En este caso, tienes varios tokens trabajando en conjunto. Los autores están usando sus tokens para impulsar el contenido y atribuirse ese contenido a sí mismos. Los lectores también cuentan con sus tokens, que les permiten acceder a la aplicación y dejar comentarios, que a su vez son atribuidos a su perfil. Si son suscriptores premium, incluso pueden tener tokens únicos y diferentes que les permitan diferentes patrones de acceso a través de un esquema de cuasi autenticación.

Este nivel tiene sus problemas, por supuesto. Los tokens de autenticación, aunque a menudo se usan como una especie de esquema de autorización en la naturaleza, solo deben usarse para autenticación. Por eso, la cuasi-autenticación proviene tanto de una suposición de intención (¡guau, esta persona tiene este token, debe ser lo suficientemente confiable para hacer esto!) Como de una combinación compleja de declaraciones condicionales y lógica difusa.

También debe tenerse en cuenta que el uso de tokens de autenticación como forma de autorización suele ser muy inseguro debido a la naturaleza de cómo se distribuyen los tokens. Las máquinas pueden obtener tokens con mucha facilidad, y si una computadora puede hacerlo, cualquier actor malintencionado puede hacerlo. Cuando los tokens son fáciles de obtener, su esquema de autorización depende casi por completo de un sistema que es falsificable, corruptible y, francamente, se usa para el propósito exactamente opuesto al que se pretendía.

Lea también:  Flujo de token asistido: la respuesta a la integración de OAuth en aplicaciones de una sola página

Nivel 2: autorización basada en token

La autorización basada en tokens es un poco como nuestro nivel anterior, pero el enfoque se desplaza a la autorización. En este nivel, ya no respondemos a la pregunta "¿quién eres tú?" sino más bien "¿qué puedes hacer?". Una excelente manera de pensar en esto es imaginar un gran castillo con puertas cerradas. Para ingresar al castillo, puede proporcionar su identidad; en otras palabras, puede autenticar que es quien dice ser. Si bien eso podría llevarlo a las puertas, ¿cómo sabe alguien que tiene derecho a vender productos? Para vender productos, es posible que necesite un sello del rey que diga que puede participar en el comercio; en otras palabras; necesitaría una autorización que indique que puede hacer algo. Su primera ficha decía quién es usted y la segunda ficha decía lo que podía hacer.

Para llevar nuestro ejemplo de autores y lectores a otro nivel, podemos mirar la capacidad de consumir y la capacidad de publicar. Si bien los tokens de autenticación nos permitieron atribuir contenido a un usuario específico, también necesitaríamos un mecanismo para garantizar que solo los autores puedan publicar contenido. Aquí es donde entra la autorización: cuando los autores envían su contenido a la aplicación para su consumo, el sistema debe poder garantizar que el contenido provenga de una fuente confiable y que haya sido creado por alguien que tenga derecho a cargar el contenido.

Este acceso se puede controlar de forma bastante granular mediante una solución como OAuth: la implementación de alcances puede regir los permisos a lo largo de la vida útil y el propósito de un token, la caducidad se puede configurar para garantizar que los tokens puedan dejar de usarse, etc. De esta manera, mientras la autenticación está En gran parte una proposición de “sí o no” (específicamente, usted es quien dice ser o no es), la autorización puede ser una escala móvil de aplicabilidad mucho más variable.

Si bien esto puede parecer una solución perfecta para nuestras preocupaciones de seguridad en niveles anteriores, existen algunas razones importantes por las que esto aún no es suficiente. En primer lugar, debemos hacernos una pregunta: ¿en quién confiamos? Estos sistemas están diseñados para ser autorizados y, como tales, los sistemas de tokens que provienen de ellos deben ser impermeables y confiables para que podamos considerar sus tokens como evidencia.

Además, debemos preguntarnos cómo se manejan los datos en tránsito. Estos tokens se transmiten y, a medida que lo hacen, recopilan más y más datos. En consecuencia, debemos preguntarnos qué datos se están agregando y por quién. Si no podemos saber con certeza que la información que manejamos es, de hecho, la misma que cuando se emitió, perdemos una cantidad significativa de confianza en los datos como valor central.

Lea más en el blog de Curity: Modelo de madurez de seguridad de API

Nivel 3: confianza centralizada mediante reclamaciones

Las reclamaciones son una pieza importante que falta en todas nuestras capas de seguridad, principalmente porque estamos tratando de agregar seguridad en el lugar equivocado. Una cosa es que un usuario afirme ser quien es, o afirme tener ciertos derechos: ¿cómo podemos confiar en que lo que está diciendo es verdad? Más importante aún, ¿cómo confiamos en aquellos que dieron la evidencia de que están usando?

Esa es la pregunta fundamental aquí: ¿en quién confiamos? ¿Confiamos en la persona que llama? ¿Confiamos en API Gateway? ¿Qué tal el emisor del token? La confianza nos asegura, pero también nos abre a posibles ataques. ¿Qué podemos hacer para solucionar este problema?

Las afirmaciones son la solución porque no simplemente le dicen algo sobre el tema; le dan contexto y la capacidad de verificar esa información. Hay dos tipos básicos de atributos a los que puede hacer referencia una reclamación: los atributos de contexto nos informan sobre la situación en la que se emite un token y los atributos de sujeto nos informan sobre la cosa que recibió el token. Para verificar que esto sea cierto, confiamos en una Parte que afirma. Como ejemplo, digamos que queremos obtener un token que demuestre que las API nórdicas han publicado una publicación. Podemos mirar los atributos:

Attribute:
	publisher: Nordic_APIs_Author1
	publish_Date: 12/1/2019

Para inculcar una mejor seguridad, podemos expresar esta información en un token de reclamaciones como tal:

Claim:
Nordic APIs say: The publisher is Nordic_APIs_Author1.

De esta manera, no solo decimos la información que necesitamos decir, también especificamos quién está dando fe de que la información es, de hecho, verdadera. En un formato práctico, el flujo de trabajo depende en gran medida de la firma y la verificación. Cuando una Parte Solicitante solicita un token de la Autoridad Emisora, esa Autoridad devuelve la información solicitada. Esta información se firma con una clave privada; cuando la parte solicitante desea verificar esta información, puede simplemente usar la clave pública para asegurarse de que se firmó antes de entregarla.

Más concretamente, codificar y encapsular datos de esta manera también nos permite agregar la funcionalidad de cada capa en una fuente singular con información contextualizada. Si bien al token se le otorga una confianza significativa debido a su naturaleza firmada, la información meta contextual (y las atestaciones de la autoridad emisora) nos permite saber quién ha solicitado la información y qué se le permite ver.

Las reclamaciones también resuelven la preocupación de que se agreguen datos en tránsito. Debido a que la información codificada está firmada y controlada por la Autoridad Emisora, no se agrega nada en tránsito a menos que la Autoridad Emisora ​​esté involucrada; de esta manera, la fuente de información se puede controlar directamente.

Lea también: Explorando OAuth.tools, el primer parque infantil OAuth del mundo

Conclusión

La seguridad no es una ecuación de "talla única", pero los requisitos fundamentales del sistema son, sin embargo, bastante universales. La necesidad de demostrar que las personas son quienes dicen ser, la necesidad de controlar el acceso, etc., son fundamentales para la web moderna y los sistemas que la impulsan. En consecuencia, elegir el enfoque correcto para su flujo de seguridad dado es fundamental para una comunicación exitosa.

¿Qué opinas de este enfoque? ¿Considera que las afirmaciones son la solución de seguridad prometida que estábamos esperando? ¡Háganos saber en los comentarios a continuación!

Publicar un comentario

0 Comentarios