Header Ads Widget

Ticker

6/recent/ticker-posts

API Keys ≠ Security: Why API Keys Are Not Enough

 

Por qué-las-claves-API-no-son-suficientes-API-nórdicas

Todos estamos acostumbrados a usar nombres de usuario y contraseñas para cientos de cuentas en línea, pero si no se administran correctamente, el uso de contraseñas puede convertirse en una gran distracción y una potencial vulnerabilidad de seguridad. Lo mismo ocurre en el espacio API. No hay nada intrínsecamente malo con los nombres de usuario, los necesita. Pero si los usa sin tener también algún tipo de credencial que permita al servicio verificar la identidad de la persona que llama, ciertamente lo está haciendo mal.

Desafortunadamente, muchos proveedores de API cometen un error peligroso que expone una gran cantidad de datos y hace que todo un ecosistema sea inseguro. En un lenguaje sencillo: si solo está usando claves API, ¡puede que lo esté haciendo mal!

¿Qué es una clave API?

Una clave de API es un fragmento de código asignado a un programa, desarrollador o usuario específico que se utiliza cada vez que esa entidad realiza una llamada a una API. Esta clave suele ser una larga cadena de caracteres generados que siguen un conjunto de reglas de generación especificadas por la autoridad que las crea:

IP84UTvzJKds1Jomx8gIbTXcEEJSUilGqpxCcmnx

Tras la creación de la cuenta o el registro de la aplicación, muchos proveedores de API asignan claves de API a sus desarrolladores, lo que les permite funcionar de manera similar a un nombre de usuario y contraseña de cuenta. Las claves de API son únicas y, debido a esto, muchos proveedores han optado por utilizar estas claves como un tipo de capa de seguridad , prohibiendo la entrada y otros derechos a cualquier persona que no pueda proporcionar la clave para el servicio que se solicita.

A pesar de la atractiva simplicidad y facilidad de utilizar claves API en este método, el cambio de responsabilidad de seguridad, la falta de control granular y la falta de comprensión del propósito y el uso entre la mayoría de los desarrolladores hacen que depender únicamente de las claves API sea una mala decisión. Más que proteger las claves de API , necesitamos programar funciones sólidas de control de identidad y administración de acceso para salvaguardar toda la plataforma de API.

Cambio de responsabilidad

En las implementaciones más comunes del proceso de clave API, la seguridad del sistema en su conjunto depende completamente de la capacidad del consumidor desarrollador para proteger sus claves API y mantener la seguridad. Sin embargo, esto no siempre es estable. Tomemos el error de Amazon EC2 de $ 2375 de Andrew Hoffman que involucró un empuje de clave API por casualidad a GitHub. Dado que los desarrolladores confían en herramientas de desarrollo basadas en la nube, la exposición pública accidental o malintencionada de las claves API puede ser una preocupación real.

Desde el momento en que se genera una clave, se pasa a través de la red al usuario a través de una conexión con opciones limitadas de cifrado y seguridad. Una vez que el usuario recibe la clave, que en muchas implementaciones comunes se proporciona en texto sin formato, el usuario debe guardar la clave usando un administrador de contraseñas, escribirla o guardarla en un archivo en el escritorio. Otro método común para el almacenamiento de claves API es el almacenamiento del dispositivo, que toma la clave generada y la guarda en el dispositivo en el que se solicitó.

Cuando se utiliza una clave, el proveedor de API debe confiar en el desarrollador para cifrar su tráfico, proteger su red y cumplir con su parte del trato de seguridad. Hay muchas vulnerabilidades en juego aquí: las aplicaciones que contienen claves se pueden descompilar para extraer claves, o desofuscar del almacenamiento en el dispositivo, los archivos de texto sin formato pueden ser robados para uso no aprobado y los administradores de contraseñas son susceptibles a riesgos de seguridad como con cualquier aplicación.

Debido a su relativa simplicidad, las implementaciones más comunes del método API Key proporcionan una sensación de falsa seguridad . Los desarrolladores insertan las claves en los empujes de Github , las utilizan en llamadas de API de terceros o incluso las comparten entre varios servicios, cada uno con sus propias advertencias de seguridad. En una situación tan vulnerable, la seguridad es un gran problema, pero es uno que realmente no se menciona con las claves API porque "son muy simples, ¡y el usuario las mantendrá seguras!"

Este es un punto de vista imprudente. Las claves de API solo son seguras cuando se utilizan con SSL , lo que ni siquiera es un requisito en la implementación básica de la metodología. Otros sistemas, como OAuth 2 , Amazon Auth y más, requieren el uso de SSL por esta misma razón. Pasar la responsabilidad del proveedor de servicios al consumidor desarrollador también es una decisión negligente desde la perspectiva de UX .


Vea a Travis Spencer dar una sesión sobre los aspectos prácticos de la seguridad API

Falta de control granular

Algunas personas perdonan la falta de seguridad. Después de todo, depende del desarrollador asegurarse de que se implementen soluciones como SSL. Sin embargo, incluso si garantiza la seguridad, sus problemas no se detienen ahí: las claves de API por diseño carecen de control granular .

Irónicamente, antes de que se usaran las claves API con los servicios RESTful, teníamos tokens WS-Security para los servicios SOAP que nos permitían realizar muchas cosas con un control más detallado. Mientras que otras soluciones pueden ser delimitadas, dirigidas a la audiencia, controladas y administradas hasta la más mínima minucia, las claves de API, la mayoría de las veces, solo brindan acceso hasta que se revocan. No se pueden controlar específicamente de forma dinámica.

Eso no quiere decir que las claves API carezcan de control: un control de lectura / escritura / lectura-escritura relativamente útil es definitivamente posible en una aplicación de clave API. Sin embargo, las necesidades del desarrollador de API promedio a menudo garantizan opciones más completas.

Este tampoco es un problema localizado. A medida que se integran más y más dispositivos en el Internet de las cosas , este control se volverá más importante que nunca, magnificando las decisiones tomadas en las primeras etapas de desarrollo a proporciones gigantescas más adelante en el ciclo de vida de la API .

Clavija cuadrada en un agujero redondo

Todo esto se reduce a un solo hecho: las claves de API nunca fueron diseñadas para usarse como una característica de seguridad . La mayoría de los desarrolladores utilizan claves de API como método de autenticación o autorización, pero la clave de API solo fue pensada para servir como identificación.

Las claves de API son mejores para dos cosas: identificación y análisis . Si bien el seguimiento analítico (y específicamente las métricas API ) pueden hacer o deshacer un sistema, otras soluciones implementan esta función de una manera más rica en funciones. Del mismo modo, mientras que las claves de API hacen un gran trabajo identificando a un usuario, otras alternativas, como el cifrado de clave pública, los tokens HoK , etc., hacen un trabajo mucho mejor y brindan más seguridad.

Ventajas de las claves API

Definitivamente, existen algunas razones válidas para usar claves API. En primer lugar, las claves API son simples . El uso de un único identificador es simple y, para algunos casos de uso, es la mejor solución. Por ejemplo, si una API está limitada específicamente en la funcionalidad donde "leer" es el único comando posible, una clave API puede ser una solución adecuada. Sin la necesidad de editar, modificar o eliminar, la seguridad es una preocupación menor.

En segundo lugar, las claves de API pueden ayudar a reducir los problemas relacionados con la entropía dentro de un servicio autenticado. La entropía , la cantidad de energía o potencial dentro de un sistema que se gasta constantemente durante su uso, dicta que hay una cantidad limitada de pares de autenticación. Si la entropía dicta que solo puede tener 6.5 millones de pares únicos cuando está limitado dentro de un determinado conjunto de caracteres y estilo, entonces solo puede tener 6.5 millones de dispositivos, usuarios o cuentas antes de tener un problema con la nomenclatura. Por el contrario, el establecimiento de una clave API con una gran cantidad de variables aceptables resuelve en gran medida esto, aumentando la entropía teórica a un nivel mucho más alto.

Finalmente, la autonomía dentro de un sistema de clave API es extremadamente alta. Debido a que una clave de API es independiente de un servidor de nombres y de las credenciales maestras, se pueden crear de forma autónoma. Si bien esto viene con la advertencia de posibles ataques de denegación de servicio, la autonomía creada es maravillosa para los sistemas que están diseñados para aprovecharla.

Al desarrollar una API, se debe cumplir un principio de privilegio mínimo: permitir que solo aquellos que requieren recursos accedan a esos recursos específicos . Este principio depende del concepto de CIA en la seguridad del sistema: confidencialidad, integridad y disponibilidad. Si su API no trata con información confidencial (por ejemplo, una API que sirve tickers bursátiles), no ofrece información privada o de misión crítica (como una API de noticias / RSS), o exige disponibilidad constante (en otras palabras, puede funcionar de forma intermitente), las claves API pueden ser suficientes.

Además, las claves de API son una buena opción para usos de API específicos para desarrolladores. Cuando los desarrolladores están configurando clientes API en el momento de la operación y usan claves cambiantes para diferentes servicios, esto es aceptable.

De vuelta a la realidad

Los beneficios de usar claves de API descritos anteriormente aún son débiles en el escenario de caso de uso general. Si bien las claves de API son simples , la limitación de "solo lectura" dificulta más que libera. Aunque proporcionan niveles más altos de entropía , esta solución no se limita a las claves API y también es inherente a otras soluciones de autenticación / autorización. Asimismo, la autonomía se puede implementar a través de una gestión de servidor innovadora y sistemas de delegación modernos.

Conclusión: las claves de API no son una solución completa

Los grandes problemas con las claves de API surgen cuando los usuarios finales, no los desarrolladores, comienzan a realizar llamadas a la API con estas claves, que a menudo exponen su API a riesgos de seguridad y administración. Todo se reduce a que , por naturaleza, las claves API no son una solución completa . Si bien pueden estar perfectamente bien para fines de solo lectura, son una solución demasiado débil para igualar la complejidad de un sistema API de uso elevado. Siempre que comience a integrar otras funcionalidades como escritura, modificación, eliminación y más, necesariamente ingresará al ámbito de Identificación, Autenticación y Autorización .

La implementación de la clave API básica no admite la autenticación sin código o servicios adicionales, no admite la autenticación sin un sistema de terceros compatible o una aplicación secundaria, y no admite la autorización sin algunos "trucos" serios para extender el uso más allá de lo que originalmente estaban destinados.

Si bien se podría argumentar a favor de expandir el método API Keys para respaldar mejor estas soluciones, ese argumento abogaría por reinventar la rueda. Ya hay tantas soluciones mejoradas disponibles que agregar funcionalidad a un sistema de clave API no tiene sentido. Incluso si agregó algo como autenticación, especialmente autenticación federada, al sistema que usa Shibboleth, OpenID, etc., hay un montón de sistemas que ya tienen soporte para esto.

Más sobre seguridad de API del equipo de API nórdicas:

security_ebook_final-01

Claves API ≠ Seguridad. Consulte "Asegurar la fortaleza API" para obtener más información.

Una de las facetas más importantes del desarrollo de API es la creación de una solución de seguridad completa y eficaz . Decidir las técnicas y los métodos utilizados para proteger su información es, con mucho, el paso más importante en el ciclo de vida del desarrollo de la API, ya que un solo paso en falso en esta área puede provocar brechas de seguridad devastadoras.

Escribimos sobre seguridad de API a menudo, ¡no es tan seco como parece! Consulte los siguientes artículos para obtener más consejos de expertos o descargue nuestra guía completa sobre seguridad de API: Asegurar la fortaleza de API .

  • Profundización en OAuth y OpenID Connect
  • Cómo controlar la identidad del usuario dentro de los microservicios
  • Equipar su API con la armadura adecuada
  • Las cuatro defensas de la fortaleza API
  • 3 aplicaciones de autorización únicas de OpenID Connect
  • Instrucciones sobre cómo purgar archivos de GitHub

Publicar un comentario

0 Comentarios