Header Ads Widget

Ticker

6/recent/ticker-posts

Introducción a la protección de su nueva API

 

Con el rápido crecimiento de la economía de las API , se comparten más datos confidenciales a través de las API que nunca. Como consecuencia natural de esto, hay mucho en juego en torno a la seguridad de la API, y solo están aumentando.

Si bien es fácil pasar por alto la importancia de la seguridad en una API nueva, especialmente si esa API solo se usa internamente o por socios seleccionados, debe proteger todas las API desde el principio . En este artículo, veremos algunos de los conceptos básicos para asegurar sin problemas una nueva API, desde pensar como un chico malo hasta emplear herramientas y estándares establecidos.

Basamos este artículo en una charla de Keith Casey en la Cumbre de la Plataforma 2019 en Estocolmo, Suecia. Mira la charla completa a continuación.

Tres principios rectores para la seguridad de API

La seguridad API efectiva comienza con algunas mejores prácticas axiomáticas , que reducen significativamente el potencial de un ataque con poco esfuerzo. Según Keith, son:

  1. Exponga solo las interfaces que necesita. Una forma sencilla de limitar la superficie de ataque de su API es exponer solo las interfaces que realmente necesita. Cada nuevo punto final que agregue representa un vector de ataque potencial, por lo que siempre evite hacerlo de manera superflua.
  2. Solo recopile y comparta los datos que necesite. Suponiendo que un atacante tenga éxito en descifrar su API, ¿a qué datos obtendrá acceso? La respuesta, por supuesto, son los datos que recopila y / o comparte (según el exploit). Como resultado, solo debe esforzarse por recopilar y compartir datos cuando sea necesario. Keith ofrece un excelente ejemplo: si acepta un número de tarjeta de crédito, hay muy pocas razones para exponer esa información.
  3. Solo conceda acceso a las personas y los sistemas que necesite. Hemos cubierto el qué , pero el quién es igualmente importante en la seguridad de la API. Al compartir datos (y funcionalidad) solo con aquellos que los necesitan, limita drásticamente el número de atacantes potenciales.
Consulte nuestro libro electrónico: Asegurar la fortaleza de las API

Piensa como un chico malo

Otra sugerencia de seguridad que ofrece Keith es pensar como un chico malo . Propone la ingeniería inversa de su API desde la perspectiva de un atacante, en otras palabras, buscando activamente formas de atacarla.

Dado que es probable que haya miles de formas de explotar una API , esto puede requerir mucha creatividad. Como resultado, le recomienda que comience por leer sobre las brechas de seguridad de otros (especialmente las de sus competidores) y ver si los mismos problemas pueden surgir en su propia API.

Otra opción es hablar con sus equipos legales , cuyo objetivo principal es proteger a la organización. Aunque es posible que no sean expertos en seguridad de API, pueden analizar su situación desde una perspectiva de cumplimiento, que siempre es un buen punto de partida, así como una perspectiva de responsabilidad más amplia. Keith bromea diciendo que, como mínimo, deberías llevarlos a almorzar (¡así que te deben uno)!

A continuación, puede hablar con otros desarrolladores de API sobre sus historias de terror de seguridad. Es probable que cada uno de ellos haya experimentado de primera mano una supervisión de seguridad seria. Por último, revise todos los puntos finales de su API uno por uno y pregúntese: "¿Cómo podría usarse esto en nuestra contra?"

Lea también: API de la guerra mundial: ciberataques a escala internacional

Herramientas y estándares

Lo siguiente en su estrategia de seguridad de API son las herramientas y los estándares. Así es: ¡hacer todo usted mismo no es el enfoque correcto! En su lugar, confíe en herramientas y estándares creados por expertos en seguridad dedicados o que se hayan desarrollado en colaboración durante muchos años (o incluso décadas).

Herramientas: API Gateway

No debería sorprender que Keith recomiende utilizar algún tipo de puerta de enlace API o plataforma de gestión . Estas plataformas generalmente cubren una amplia gama de problemas de propiedad de API, desde el desarrollo hasta el rendimiento, pero lo más importante es que lo ayudan a administrar la interfaz (qué recursos / métodos / objetos / campos están expuestos) y el acceso (quién tiene acceso y cómo se autentican).

Estándares: cifrado y autenticación

Del mismo modo, debe confiar en enfoques estandarizados para el cifrado y la autenticación. Existe una gran cantidad de métodos de cifrado a prueba de balas y muy pocos incentivos para crear uno propio. En cuanto a la autenticación, OAuth 2.0 con OpenID Connect es el estándar de facto, y por una buena razón.

La importancia del tiempo

Desde la perspectiva de Keith, el mayor activo que puede tener un atacante es el tiempo. Si un exploit no se detecta en el transcurso de días, semanas, meses o incluso años, el número (y la gravedad) de las posibles consecuencias se multiplican enormemente. Y eso no es solo porque se filtran más datos: un exploit en un sistema puede permitir más ataques en otros lugares.

Para contrarrestar esto, integre controles de seguridad en sus procesos existentes. Asegúrese de que su API se supervise constantemente, con controles automáticos y manuales para detectar actividades sospechosas.

Pensamientos finales

En lugar de resumir sus puntos principales, Keith termina la presentación con algunas preguntas cruciales. Mientras construye su estrategia de seguridad de API, pregúntese:

  • ¿Qué es lo peor que alguien puede hacer con nuestra API?
  • ¿Qué sucede si nuestros competidores obtienen nuestros datos?
  • ¿Qué datos debemos recopilar y qué debemos exponer?
  • ¿Quiénes son sus usuarios ahora y quiénes serán en una semana, mes o año?
  • ¿Cómo monitoreamos cuando las cosas van mal?

Publicar un comentario

0 Comentarios