Header Ads Widget

Ticker

6/recent/ticker-posts

Ocultar y proteger sus claves API

 


Las claves de API son increíblemente poderosas y extremadamente vulnerables. La exposición a la clave API puede resultar en un daño significativo, tanto para una empresa como para los datos que posee. Como tal, ocultar y proteger las claves (así como mitigar la pérdida potencial) es fundamental para cualquier plan de seguridad en el espacio API moderno.

Hoy veremos este problema e identificaremos las preocupaciones centrales. Analizaremos tres formas generales de proteger las claves de API y ofrecer una solución procesable, fácil y eficiente para una implementación práctica.

Definiendo el problema

Las integraciones de terceros, la automatización y el trabajo colaborativo han aportado muchas ventajas a los desarrolladores modernos. Dicho esto, los servicios basados ​​en API conllevan riesgos significativos que eran menos comunes en el modelo de codificación clásico. La principal de estas preocupaciones es la exposición de información sensible debido a un simple error humano.

Si bien muchos tipos de datos pueden dañar su seguridad si se exponen, la divulgación de la clave API es especialmente preocupante debido al poder que tienen. Cuando se usa algo como GitHub, una preocupación importante es la exposición de las claves API utilizadas durante el desarrollo. La sincronización de GitHub necesariamente incluye una gran cantidad de datos y, si está mal configurada, también podría incluir su clave de API.

¿Por qué deben ofuscarse y protegerse las claves de API?

Lo primero es lo primero: las claves API son un método común para controlar el acceso a los servicios web. Durante las pruebas y el desarrollo, es común que los desarrolladores prueben claves y credenciales de administrador dentro de los prototipos. El problema surge cuando los desarrolladores no tratan esta clave con la mentalidad de seguridad que exige.

Si un administrador o desarrollador presiona su clave como parte de una confirmación accidentalmente, cualquiera que agarre esa clave puede actuar esencialmente como si fuera esa persona. Es posible que el daño no sea inmediato; de hecho, puede que no sea evidente de inmediato que la clave se vio comprometida, pero el potencial de daño es extremo.

Lea también: Por qué las claves de API no son suficientes

Lidiando con el Problema

Cuando miramos cómo podríamos resolver este problema, hay esencialmente tres categorías de soluciones. Cabe señalar que ninguna solución única cubrirá todos los casos de uso. Todas las soluciones deben considerarse herramientas dentro de un conjunto de herramientas más amplio, no una solución única.

  1. Ocultar llaves : el primer tipo de solución implica diferentes técnicas para ocultar sus claves. Ocultar sus claves es una buena solución; después de todo, asegurarse de que su clave no quede expuesta en primer lugar es una medida preventiva tan efectiva como podría desear.
  2. Asegurar las llaves : debido a este defecto fundamental, deberíamos considerar proteger nuestras claves. La protección de las claves requiere un conjunto variado de soluciones que protegen las claves en sí mismas y protegen el sistema subyacente.
  3. Mitigación : Por último, podemos implementar soluciones que mitiguen cualquier daño potencial que pueda afrontar una clave expuesta. Esta es una parte proactiva y una parte reactiva. Ciertas opciones solo se pueden tomar después el ataque haya comenzado, pero existen estrategias para garantizar que el daño ocurra de una manera conocida, prevista y canalizada.
Relacionado: ¿OAuth es suficiente para la seguridad de API de grado financiero?

Soluciones para ocultar claves

En primer lugar, garantizar los procesos de control de versiones adecuados es fundamental para ocultar su clave. Con demasiada frecuencia, los empujes de código no se someten a un proceso de revisión adecuado. Al crear versiones, la base de código debe comprobarse, revisarse y autorizarse para su publicación. Las rutinas estandarizadas reducen el riesgo de exposición clave.

Otra buena opción para ocultar sus claves es mover esas claves fuera de la estructura del archivo fuente. En su lugar, haz referencia a ella como una variable. Una variable ambiental hace que sea mucho más fácil hacer referencia a dicha clave en múltiples ubicaciones, lo que ahorra tiempo y aumenta la seguridad.

Soluciones para asegurar llaves

Ocultar claves es solo una parte de la solución. Entonces, ¿qué puede hacer en términos de asegurar las claves? Primero, considere aplicar hash y cifrar su clave tanto en reposo como en tránsito. Si se hace correctamente, esto debería agregar muy poca sobrecarga a sus tiempos de interacción, pero asegura que cualquier ataque de intermediario u otras infracciones sean difíciles de aprovechar para generar daños mayores de inmediato.

En segundo lugar, audite de forma rutinaria sus claves para asegurarse de que no haya claves extra no utilizadas o claves con privilegios excesivos esperando para hacer un desastre en su base de código. La exclusión de las claves antiguas del uso mediante la aplicación de un programa de regeneración automática de claves y un mecanismo de caducidad de claves puede garantizar que, incluso si las claves se exponen accidentalmente, el tiempo durante el cual pueden causar daños sea al menos parcialmente limitado.

Una práctica importante que se debe adoptar como pauta general es la idea de que los roles, y por lo tanto, las claves, deben dividirse y de manera sensata de acuerdo con el mínimo privilegio necesario para llevar a cabo la función esencial. En otras palabras, realmente no hay ninguna razón por la que debería haber una clave ómnibus que haga todo en todas partes; una clave así sería desastrosa si se expone.

Por último, asegúrese de que todos los sistemas instalados tengan métodos para detectar cambios en la actividad de clave a clave. Si su clave interactúa con la API de manera predecible, puede asegurarse de que cualquier cambio en esa actividad pueda, como mínimo, ser marcado para revisión, si no resulta inmediatamente en la revocación de los derechos de esa clave. Este sistema es principalmente reactivo, pero puede hacer maravillas para detener el ataque mientras ocurre.

Soluciones para mitigar la exposición

Planear para el peor escenario es quizás su mejor estrategia. Primero, los desarrolladores deben aplicar las restricciones clave con sensatez. Permitir que solo clientes específicos o aspectos específicos de la API interactúen con una clave limita el daño que la clave puede hacer y, como se indicó anteriormente, no es necesario tener una clave ómnibus que se use continuamente para una sola función.

Otra solución puede ser vincular claves particularmente poderosas a IP o métodos de autenticación. Exigir esfuerzos masivos para tener un segundo factor antes de que se autorice la llamada, vincular las claves de administración a las direcciones IP de administración, etc. puede limitar significativamente los daños a las claves.

Por último, limitar la cantidad de acciones que una clave puede realizar de forma independiente puede ser un gran obstáculo para ciertos tipos de ataques. Tener un límite estricto de lo que se puede hacer en un corto período de tiempo niega muchos ataques de inundación y, por lo tanto, puede limitar tanto la exfiltración de datos, los usos abusivos de API y las conexiones simultáneas.

Relacionado: Principales amenazas de seguridad de API en 2020: Entrevista del panel de expertos

Opción práctica

Echemos un vistazo a una opción práctica para ver cómo sería un enfoque tan cohesivo. Una vez que nos hemos asegurado de que la caducidad de nuestra clave y la separación de funciones sean adecuadas, podemos comenzar a buscar una implementación más técnica.

Esta implementación usa principalmente dotenv . Comienza con una separación bastante sensata de la implementación en sí y la forma fundamental en que interactuamos con nuestra solución colaborativa, GitHub. Primero, necesitamos crear un .gitignorearchivo que apunte específicamente a los archivos que queremos que las sincronizaciones de GitHub ignoren. A medida que creamos un .envarchivo, lo listaremos de forma preventiva como excluido.

Ahora que tenemos las bases de lo que tenemos que hacer, podemos empezar. Primero, instale dotenv(en este caso, con NPM):

npm install dotenv

Ahora creemos el .envarchivo real Podemos hacer esto usando el !touch command, que creará una nueva carpeta en blanco en el mismo directorio que nuestra base de código API:

!touch .env

Dentro de este archivo, debemos insertar nuestra clave API. Podemos hacer esto indicando PROJECT_API_KEY=e insertando la clave como variable. Por ejemplo, el nuestro podría verse de la siguiente manera:

PROJECT_API_KEY=1234567890

Ahora que tenemos el conjunto de variables, podemos utilizarlo load_dotenvpara cargar la variable. Esto se parece a:

import os
from dotenv import load_dotenv load_dotenv() API_KEY = os.getenv('PROJECT_API_KEY')

El aspecto que tendrá en última instancia en términos de uso práctico difiere según el lado de la base de código de la API que esté mirando. Como usuario, solo verá la PROJECT_API_KEYvariable. La clave en sí existirá fuera de estos datos de confirmación y se ofuscará. Para los desarrolladores y el personal interno que tienen acceso a la raíz del proyecto, podrán ver tanto el archivo .env como el código base comprometido. Como tal, aquellos que necesitan utilizar el.env archivo podrán hacerlo.

Conclusión

La sincronización accidental de código seguro no es infrecuente. Afortunadamente, las soluciones para ocultar, proteger y mitigar son muy fáciles de implementar y se pueden realizar de manera generalizada en casi cualquier implementación actual. Garantizar la seguridad de su clave API debe ser un enfoque importante para cualquier organización y es un primer paso importante para cualquier plan de seguridad.

¿Qué opinas de esta implementación? ¿Es exagerado el peligro de la exposición a la clave API? Háganos saber en los comentarios a continuación.

Publicar un comentario

0 Comentarios