Header Ads Widget

Ticker

6/recent/ticker-posts

Técnicas y tecnologías para aumentar la seguridad de las API


Solemos pasar mucho tiempo hablando de las maravillas que la Interfaz de programación de aplicaciones ( API ) puede hacer para conectar nuestro mundo digital y móvil, pero también debemos hablar sobre el elefante en la habitación: la seguridad de la API es un problema real.

Dado que el método de referencia para crear y conectar aplicaciones de software sigue siendo a través de rutinas, protocolos y herramientas de API, el riesgo de seguridad de las API sigue creciendo junto con la popularidad de las API. Solo en el último año, la vulnerabilidad y el descuido de la API se han atribuido a ataques cibernéticos y riesgos de robo de identidad en aplicaciones sociales populares como Pinterest, Instagram y Snapchat.

Sabemos que la seguridad de la API (seguida de cerca por la usabilidad de la API ) es la máxima prioridad para los profesionales de API . Ahora analizaremos las herramientas y técnicas necesarias para limitar la vulnerabilidad y fortalecer la seguridad a medida que desarrolla y expone su API.


Travis Spencer, fundador de Twobo Technologies Neo-Security Platform , dio una charla sobre este tema en un evento de APIs nórdicas en Estocolmo.

La identidad está a la vanguardia de la seguridad de las API

La seguridad de la API no se trata solo de la API en sí, sino también de la seguridad de organizaciones enteras y productos móviles cuando se cruzan con las API.

Al desarrollar una API, la seguridad del dispositivo móvil es tan importante como la seguridad de la API. ¿Tiene software antivirus instalado? ¿Está inscrito en una solución de administración de dispositivos móviles ( MDM )? ¿Tiene instalado un software de gestión de aplicaciones móviles ( MAM )? También debe preocuparse por la seguridad empresarial . ¿Son seguros los servidores? ¿Tienen sus máquinas detección de intrusos?

En esta unión de API, empresas y dispositivos móviles, se encuentra el individuo. Solo cuando sepa quién está en este núcleo, sabrá a qué deberían acceder y cómo deberían acceder a él.

Presentamos la pila de Neo-Security

Cuando comenzamos a exponer información y recursos de alto valor, necesitamos tener una seguridad de alto nivel de quién está accediendo a ellos. La seguridad de la API se compone de una serie de protocolos, a los que en las API nórdicas nos referimos como la pila Neo-Security . Esta suite de seguridad en la nube basada en estándares generalmente se compone de estos protocolos y tecnologías:

  • OAuth 2 el estándar abierto para acceso delegado seguro
  • OpenID Connect para federación que permite el intercambio seguro de datos de autenticación de usuarios
  • JSON Identity Suite la colección de protocolos basados ​​en JSON para representar la identidad de los usuarios
  • SCIM o sistema para la gestión de identidades entre dominios para el aprovisionamiento y desaprovisionamiento de cuentas de usuario
  • Autenticación U2F o Universal de 2 factores para identificar asimétricamente a los usuarios con un alto grado de confianza de que realmente son quienes dicen ser
  • ALFA para definir reglas de autorización detalladas en un lenguaje de políticas similar a JSON (que se compila en XACML)
oauth-openid-connect-in-depth_neo-security-stack

Si bien la pila de Neo-Security crea una solución de seguridad integral para la movilidad, es un gran desafío para los desarrolladores de API administrar una gran cantidad de especificaciones. Siga leyendo para conocer algunas ideas útiles que harán que estos protocolos sean más accesibles.

Conceptos básicos de OAuth

A medida que aumenta el riesgo asociado con la identidad en línea de un individuo, debemos pedir permiso antes de exponer la identidad y cualquier recurso vulnerable con una API. OAuth 2 es el marco o metaprotocolo bajo el cual creamos otros protocolos para definir cómo se manejan los tokens.

Los siguientes factores conforman los protocolos OAuth2:

  • Cliente: la aplicación web o móvil involucrada
  • Servidor de autorización (AS): el servicio de token de seguridad, que emite credenciales y tokens que representan al propietario del recurso.
  • Propietario del recurso (RO): autoriza o delega el acceso al RS
  • Servidor de recursos (RS): a menudo la propia API, una colección de bibliotecas y aplicaciones web

La forma en que estos cuatro actores de OAuth2 trabajan juntos varía con cada integración. A continuación, profundizaremos en el proceso detrás de un flujo de servidor OAuth común.

Flujo del servidor web OAuth

Un proceso de "OAuth de tres patas" se produce cuando un usuario final especifica que desea delegar el acceso a una aplicación de terceros para su uso dentro de la aplicación cliente. Luego, la aplicación cliente redirige esta solicitud al AS, que requiere autenticación para la identificación. Luego, el AS autoriza a ese cliente y el RO se redirige a la aplicación web con un código de acceso de un solo uso.

El código de acceso de un solo uso se envía de vuelta al AS, que luego lo convierte en un token de acceso que el usuario final puede usar para acceder al servidor. Al mismo tiempo, el AS también puede enviar un token de actualización que permitirá al usuario final usar el mismo OAuth para acceder más de una vez.

Básicamente, el token de acceso permite a un usuario llamar a la API. A cambio, la API obtiene acceso a información sobre el cliente y el propietario del recurso y qué ruta tomaron, qué cliente están usando y quién es ese usuario final. Con esta información, puede crear decisiones de control de acceso web mucho más completas que mejoran la seguridad de la API. Todo está integrado directamente en OAuth2, lo que limita los errores de seguridad diseñados por humanos.

¿Para qué se utiliza OAuth?

  • Delegación: la autorización debe provenir de políticas definidas y delegadas.

¿Para qué NO debe usarse OAuth?

  • Autenticación: el uso de OAuth para la autenticación pone en riesgo a los usuarios finales y a los clientes.
  • Autorización: esto puede parecer contradictorio. Si bien la autoridad está ciertamente en el nombre, la API debería de hecho mantener un control completo y una determinación final sobre si se debe proporcionar o no el recurso solicitado.

Capas más allá de OAuth dentro de la pila de Neo-Security

Buceando en OpenID Connect

OpenID Connect y su predecesor SAML se centran en la autenticación y la federación, identificando a un usuario antes de que la información se envíe a un tercero. Luego, puede otorgar a los socios estratégicos un acceso similar para realizar llamadas a la API.

Incluso hay organizaciones de terceros responsables de determinar la identidad, a menudo llamadas "proveedor de identidad" o IdP . Los desarrolladores pueden usar un IdP y enviar ese acceso a una aplicación de terceros. Esto permite que el IdP actúe como proveedor de identidad y también como proveedor de API, lo que permite al IdP, que actúa como API, intercambiar datos con la aplicación.

OpenID Connect se basa en OAuth2 para definir un protocolo de federación. Optimizado en torno a los flujos de consentimiento del usuario, OpenID agrega información basada en identidad además de OAuth en las entradas y salidas.

SCIM identifica esquemas de usuarios y grupos para desarrolladores

SCIM define el protocolo RESTful API para administrar y especificar esquemas de usuarios y grupos y las propiedades en ellos, incluida la definición del marcado para representar cosas como nombre / apellido, dirección de correo electrónico, dirección real y número de teléfono. Le permite identificar usuarios dentro de grupos para que pueda agregarlos o eliminarlos fácilmente, sin tener que reinventar la API.

Se pueden combinar diferentes capas de la pila de Neo-Security. Por ejemplo, OAuth se utiliza para proteger las llamadas a la API de SCIM para instancias como el acceso delegado para crear y actualizar usuarios. SCIM y SAML u OpenID Connect se pueden vincular para proporcionar aprovisionamiento justo a tiempo ( JIT ), que le permite crear, actualizar y eliminar usuarios sin vincularlo a un evento de autenticación.

¿Qué constituye JSON Identity Suite?

La información basada en identidad proporcionada por OpenID Connect está marcada en algo llamado Jason Web Tokens o JWT (pronunciado "Jots"). Los JWT son parte de JSON Identity Suite que el Grupo de trabajo de ingeniería de Internet ( IETF ) ha definido. Los JWT están diseñados para ser tokens ligeros que se pueden pasar fácilmente en ese encabezado HTTP. Son como tokens SAML, pero son menos expresivos, más compactos, con menos opciones de seguridad, todos codificados en JSON en lugar de XML.

Más allá de JWT, el conjunto de protocolos de identidad JSON incluye:

  • JWK: la clave web JSON es una estructura de datos que configura los protocolos para definir claves asimétricas y simétricas
  • JWE: El cifrado web JSON es un formato de cifrado web compacto, ideal para entornos con limitaciones de espacio
  • JWS: las firmas web JSON permiten aplicar varias firmas al mismo contenido
  • JWA: los algoritmos web JSON registran algoritmos criptográficos
  • ** Bearer Tokens: ** Una especificación auxiliar utilizada para definir cómo usar estos tokens y poner un JWT en un encabezado de autorización HTTP para que una API reciba

Los protocolos de pila de Neo-Security aumentan la seguridad de la API

No hay duda de que el riesgo de seguridad aumenta a medida que se abren más y más API para conectarse y compartir información. Las tecnologías y los procedimientos descritos en este artículo tienen como objetivo reducir la vulnerabilidad. Aunque el IETF ha delineado un conjunto de protocolos para guiar el desarrollo y la exposición de API, los proveedores de API deben informarse sobre el lenguaje de la seguridad para evitar errores humanos y prevenir ataques de API.

Travis Spencer, fundador de Twobo Technologies Neo-Security Platform , dio una charla sobre este tema en un evento de NordicAPIs en Estocolmo. Vea esta charla en Youtube . Vea las diapositivas adjuntas a continuación:

¿Quieren más?

¿No puede esperar para obtener más información sobre la seguridad de la API y otros trucos, herramientas y temas relacionados con la API? Venga a uno de nuestros seminarios sobre el ciclo de vida de las API en mayo mientras reunimos a los desarrolladores, empresarios e ingenieros de API en Londres , Seattle , Copenhague y Múnich para nuestra primera gira mundial. El registro para el Tour API de primavera de 2015 se abrirá pronto, así que estad atentos.

Publicar un comentario

0 Comentarios