Hace más de dos décadas, Jeff Bezos declaró que todos los equipos de Amazon tendrían que "exponer sus datos y funcionalidades a través de interfaces de servicio", sin excepciones. El memorándum (ahora conocido como el "mandato API ") afirmaba esencialmente que las interfaces de programación de aplicaciones (API) no son opcionales, y ayudó a desatar una carrera para que los desarrolladores de todo el mundo conectaran todo mediante las API. Sin embargo, para muchas organizaciones, la seguridad de las API va a la zaga de la implementación de las API.
El tráfico relacionado con las API constituye ahora la mayor parte (aproximadamente el 57 %) de todo el tráfico dinámico de Internet, según el reciente Informe sobre seguridad y gestión de las API 2024. Sin embargo, las empresas suelen enfrentarse a los siguientes desafíos:
Superficies de ataque ocultas y desprotegidas: los equipos de informática y de seguridad no pueden proteger lo que no pueden ver, y las organizaciones tienen "API paralelas", que sus equipos no están gestionando, lo que se traduce en exposición de datos, movimiento lateral y otros riesgos cibernéticos.
Autorizaciones demasiado permisivas: en las manos equivocadas, el acceso de "escritura" a las API que originalmente estaban destinadas a ser de solo lectura expone los sistemas a ataques y a la posible pérdida de datos. Sin embargo, el 60 % de las organizaciones permite el acceso a operaciones de "escritura" al menos a la mitad de sus API.
Las organizaciones pueden pasar por alto y clasificar erróneamente las causas de los errores relacionados con las API: no todos los errores de las API están causados por ataques, y no todos los ataques a las API pueden mitigarse de la misma manera. Un error o una vulnerabilidad no detectada o mal diagnosticada puede deteriorar la experiencia del usuario final o, lo que es peor, puede abrir la puerta a un ciberataque.
Se calcula que hay 200 millones de API públicas y privadas en uso, y esta cifra sigue en aumento. Para aprovechar con seguridad la eficacia de estas API (y de las futuras), las organizaciones necesitan un enfoque de gestión de API especialmente diseñado que incorpore la siguiente lista de lo que debes y no debes hacer:
Digamos que el hospital Acme ofrece iniciativas digitales que encantan a sus pacientes y proveedores, desde servicios de telemedicina móvil eficaces hasta procesamiento de registros mediante IA. Un día, uno de los desarrolladores de Acme habilita el acceso de "escritura" a la API de un sistema de facturación sin la documentación adecuada. Unos meses más tarde, el proveedor es blanco de un grupo de hackers que, mediante movimiento lateral, pueden explotar la API pública de Acme para acceder a los historiales de los pacientes.
Acme podría haber detectado y mitigado este escenario antes si hubiera tenido una forma de hacerlo automáticamente:
Identificación de todos los puntos finales públicos de la API (incluidas las API no autenticadas) y el tráfico relacionado.
Detección de los esquemas de API, los metadatos que definen las especificaciones de una llamada API/respuesta válida).
Detección de variaciones de ataque en las API.
Incorpora soluciones de seguridad de API que utilicen modelos de aprendizaje automático y no requieran comunicaciones manuales "instantáneas" entre los equipos de seguridad, de informática y los desarrolladores.
Por ejemplo, la identificación de las API basada en el aprendizaje automático y la detección de esquemas de API pueden ofrecer a organizaciones como Acme un inventario más completo de sus API: ¿Cuáles son esas API? ¿A qué datos y sistemas acceden? ¿Cuándo y dónde se accede a ellas? ¿A quién se le ha concedido permiso de "solo lectura" frente a "escritura"?
Este tipo de datos es fundamental para evitar la proliferación de las API paralelas. En el proceso de desarrollo de nuevas funcionalidades para el cliente (que a menudo se exponen primero como API accesibles desde Internet), la documentación y las "prácticas recomendadas" de seguridad de las API suelen dejarse a discreción de los desarrolladores individuales. Muchas veces, no hay tiempo ni recursos suficientes para incorporar a los equipos de seguridad.
Por eso surgen los desafíos de seguridad: las organizaciones no pueden proteger lo que no pueden ver. De hecho, los modelos de aprendizaje automático de Cloudflare identificaron más puntos finales de la API, en concreto un 31 % más, de los que las organizaciones declararon, lo que sugiere que casi un tercio de las API son esencialmente API paralelas.
Las API paralelas (que a menudo se incorporan de manera inofensiva durante cambios frecuentes de código) no son intrínsecamente maliciosas. Pero, si tenemos en cuenta que el 86 % de los desarrolladores no consideran la seguridad de la aplicación como una prioridad máxima, las API paralelas son una amenaza de primer orden. Si se explotan, pueden dar lugar a la exposición de datos, vulnerabilidades sin revisar, incumplimientos de la conformidad de los datos y otros riesgos. El aprendizaje automático ayuda a identificar esas API paralelas.
Las aplicaciones web y las API son fundamentalmente diferentes. Una aplicación para compartir coche es "visible" para sus usuarios, pero la API que le da acceso a los datos de Google Maps está "oculta". Teniendo en cuentas estas (y otras) diferencias, las organizaciones necesitan una seguridad específica para las API, no solo para las aplicaciones web.
Por ejemplo, una firewall de aplicaciones web (WAF) filtra y supervisa el tráfico HTTP entre una aplicación web e Internet basándose en una lista de bloqueo. El WAF busca señales conocidas de un ataque, y luego actúa para detenerlo. El resto del tráfico está permitido. Este es el modelo de seguridad "negativo", que puede ser eficaz para la seguridad de las aplicaciones web, donde es más fácil identificar y bloquear el tráfico web malicioso.
Sin embargo, la protección de las API de los abusos — seguridad de las API — exige una seguridad "positiva". En lugar de buscar solo las solicitudes "malas conocidas", busca las solicitudes "buenas conocidas" y aprueba solo estas últimas, bloquea todo lo demás. (Descubre más información sobre lo que define a estas solicitudes, es decir, las llamadas API — aquí).
¿Por qué?
Consideremos el ejemplo de un proveedor de telecomunicaciones australiano que sufrió una fuga que expuso los datos de casi 10 millones de clientes. El hacker había accedido a una determinada base de datos de clientes a través de una API no autenticada. Aunque se desconocen los detalles del ataque, cabe señalar que un modelo de seguridad de API "positivo" solo habría permitido el tráfico de API que se ajustara a las especificaciones de la API de la empresa.
En otras palabras, recurre a la seguridad "positiva" de las API y permite solo el tráfico de usuarios y redes corporativas autenticadas, que realicen acciones autorizadas. (Las organizaciones también pueden combinar modelos de seguridad, como superponer la seguridad "negativa" de un WAF con la seguridad "positiva" de una puerta de enlace API).
Conclusión: las API requieren un enfoque integral para defenderse de una amplia gama de amenazas, entre las que se incluyen las 6 más importantes:
Fuente: Informe sobre gestión y seguridad de las API 2024
Como se indica en el gráfico anterior, las anomalías HTTP constituyeron la mayoría (60,7 %) de las amenazas a las API mitigadas. Las anomalías HTTP (como la falta de agentes de usuario — el software que recupera el contenido de Internet para los usuarios finales — y otras anomalías) son señales habituales de solicitudes maliciosas.
Con un modelo de seguridad "positivo " (como se ha descrito anteriormente), las organizaciones pueden identificar anomalías HTTP y otras amenazas, y solo permitir el tráfico "legítimo" de cada API a sus servidores API.
Los equipos de informática, de seguridad y los desarrolladores de aplicaciones deben compartir la responsabilidad de proteger la vasta superficie de ataque que supone tener miles de activos basados en API. Sin embargo, las prioridades de estos equipos a menudo entran en conflicto:
El 73 % de los desarrolladores sostiene que el trabajo o las herramientas que su equipo de seguridad les obliga a utilizar "interfiere en su productividad e innovación".
El 87 % de los directores de informática cree que los ingenieros de software y los desarrolladores "transigen con las políticas y los controles de seguridad para sacar más rápidamente al mercado nuevos productos y servicios".
Solo la mitad de los CISO considera que los desarrolladores están "muy familiarizados" con los riesgos de seguridad de las herramientas de desarrollo y flujo de trabajo.
Como resultado, las organizaciones pueden verse obligadas a "elegir" entre innovar más rápido y mejorar la seguridad, exponiendo sus API. Según el informe, casi el 60 % de las organizaciones permiten el acceso de "escritura" al menos a la mitad de sus API, pero ¿quién es el "responsable" en última instancia de garantizar que no se concede acceso de "escritura" al usuario equivocado?
Para la empresa que sigue exponiendo nuevos servicios mediante su API, una conectividad cloud puede servir como ese tejido conectivo entre la implementación de la aplicación y la protección exhaustiva de la API.
Una conectividad cloud es una plataforma unificada de servicios nativos de nube que simplifica la conectividad segura "universal" en todos los entornos informáticos. A su vez, esto ayuda a las organizaciones a recuperar el control y la visibilidad de sus extensos dominios digitales, incluido el tráfico de sus API.
Con una conectividad cloud, las organizaciones pueden abordar las siguientes iniciativas (y más) utilizando un único panel de control:
Automatización de la identificación y la visibilidad de las API para ofrecer a todas las partes interesadas un inventario claro de su patrimonio de API.
Modernización los procesos de autenticación y autorización de las API desde el principio.
Gestión de los puntos finales de las API para supervisar métricas como la latencia, los errores y la tasa de error, así como el tamaño de la respuesta para los dominios impulsados por la API.
Protección contra amenazas a la capa de aplicación API (capa 7) , como los ataques DDoS, intentos de inicio de sesión por fuerza bruta y otros abusos de la API.
La tecnología de las API no es nueva, pero para muchos equipos de AppSec y AppDev es una novedad abordar la seguridad de las API de forma integral. Sin embargo, todo progreso tiene un comienzo, y la seguridad de las API se puede abordar por etapas:
Fase 1 - Visibilidad: empieza por identificar todas las API utilizadas en tu organización. Utiliza herramientas de identificación de API, revisa la documentación técnica y los acuerdos, habla con tus desarrolladores y controla tu tráfico web.
Fase 2 - Protección general contra ataques web: la aplicación web y las API a menudo trabajan juntas (por ejemplo, un sitio web de comercio electrónico que utiliza una API para procesar los pagos). Utiliza e integra herramientas diseñadas directamente para proteger las aplicaciones web (y, en cierta medida, las API que las sustentan) de ataques DoS y DDoS, relleno de credenciales, vulnerabilidades de día cero y otras amenazas.
Fase 3 - Seguridad avanzada consolidada de las API: la cartera de soluciones de protección de aplicaciones web y API (WAAP) de Cloudflare, que cuenta con la tecnología de una conectividad cloud, proporciona seguridad integral y rendimiento en torno a las API accesibles desde Internet sin inhibir la productividad. Con la identificación de las API, la gestión y los análisis integrados de las API, así como la protección por capas, Cloudflare permite a los departamentos de informática y de seguridad obtener visibilidad y control sobre sus API.
Este artículo forma parte de un conjunto de publicaciones sobre las últimas tendencias y temas que afectan a los responsables de la toma de decisiones sobre tecnología en la actualidad.
Consigue el Informe sobre seguridad y gestión de las API 2024 para descubrir las vulnerabilidades más comunes de las API, las predicciones del sector y las recomendaciones más detalladas para proteger las API.
Después de leer este artículo podrás entender:
3 desafíos comunes relacionados con las API
Qué hacer y no hacer respecto a la gestión de una API específica
Cómo mejorar la seguridad de las API gradualmente