Seguridad integral para API: desde el desarrollo hasta la retirada

Akamai adquirió Noname Security en junio de 2024. Esta es una entrada de blog archivada que se publicó originalmente el 5 de octubre de 2022.

Proteger correctamente las interfaces de programación de aplicaciones (API) es un proceso que va mucho más allá de la seguridad. En él también se deben abordar problemas operativos y de arquitectura de TI con resultados que impulsan la seguridad. Para que el proceso de protección cumpla su objetivo, la seguridad de las API debe considerarse un proceso integral que abarca todo el ciclo de vida del software. Comienza con el desarrollo, pero continúa durante el tiempo de ejecución para llegar hasta el final del periodo de asistencia.

La seguridad de las API nos obliga a cuestionarnos algunos viejos mitos. Por ejemplo, podríamos asumir que el desarrollo de software termina cuando se implementa el código en producción. Esto ya no es así. El desarrollo de software actualmente se extiende más allá del proceso básico de escritura del código.

El desarrollo es un proceso continuo que se materializa en el concepto de integración e implementación continuas (CI/CD). De forma conjunta, el software nace mediante DevOps, donde se combinan los pasos secuenciales anteriores del desarrollo de software (Dev) y la implementación de este en productos mediante operaciones de TI (Ops).

Actualmente, en cuanto se implementa un fragmento de código en producción, el equipo de DevOps ya está preparado para implementar la siguiente iteración de la aplicación. Puede que esta se produzca dentro de una hora. Con DevOps, parece que desarrollo es igual a operaciones. La parte de las operaciones del proceso ya no se distingue de la parte de desarrollo. Por lo tanto, la seguridad de las aplicaciones debe abarcar todas las etapas relacionadas de desarrollo y operaciones.

Además, el software moderno es mucho más que simple código. También incluye conexiones entre componentes como microservicios, API, bibliotecas de código y elementos similares. Conseguir unas API seguras significa entender cómo funcionan esas conexiones, dónde se encuentran y cómo los agentes maliciosos pueden aprovechar su vulnerabilidad. Este requisito también abarca las prácticas de seguridad habituales para incluir tareas operativas como la creación de inventarios de API y la supervisión del tráfico de estas.

La seguridad de las API debe ser activa durante la etapa de desarrollo del ciclo de vida de una aplicación, en tiempo de ejecución y más allá, para abarcar todo el ciclo de vida del desarrollo de software (SDLC). Ya desde el desarrollo, los responsables de esta fase pueden indicar a las aplicaciones que invoquen la funcionalidad de las API mediante llamadas a API, o bien que creen API que muestren la funcionalidad y los datos de la aplicación a otras aplicaciones de software. Estos dos métodos de funcionamiento de las API suponen riesgos.

Los riesgos de seguridad de las API se producen por varias razones, pero muchas están relacionadas con problemas en la configuración de las API que afectan a los procesos de autenticación y autorización de los usuarios. Una API con una configuración incorrecta podría permitir a un usuario desconocido acceder a datos confidenciales. De esta forma, un error en la configuración podría permitir a un usuario obtener datos para cuyo acceso no tenga autorización. Otros fallos en la configuración pueden permitir que un atacante sobrecargue la API con llamadas y lleve a cabo un ataque de denegación de servicio (DoS). 

Durante el desarrollo

Las pruebas de seguridad de las API pueden mitigar dichos riesgos en la fase de desarrollo. Las pruebas deben ser específicas para las API, ya que con las pruebas de aplicaciones generales no se detectarán problemas como la configuración incorrecta de las API. Por su parte, una serie específica de pruebas de seguridad de API debe identificar las vulnerabilidades de estas y permitir que se corrijan antes de que se implemente el software.

Para ser efectivas, las pruebas de seguridad de las API deben realizarse en las primeras fases del proceso de desarrollo, lo que se conoce como enfoque "shift-left". El conjunto de pruebas también debe estar integrado en el canal de CI/CD, ya que, de lo contrario, el proceso de corrección de los fallos de seguridad será demasiado complejo para los miembros del equipo de DevOps.

En tiempo de ejecución

En tiempo de ejecución, la seguridad de las API incluye el bloqueo de las amenazas en tiempo real, para lo que es necesario supervisar la seguridad de las API. Una solución de seguridad de las API tiene que conocer el tráfico que se produce en estas y avisar a los administradores cuando detecte un comportamiento anómalo o firmas de ataque. Además, la solución puede realizar el paso adicional que conlleva el bloqueo automático de la API cuando detecte una amenaza.

La seguridad de las API en tiempo de ejecución es relativamente sencilla. Sin embargo, solo será efectiva si la solución de seguridad de las API sabe dónde se encuentran todas ellas. Para ser seguras, las API deben gestionarse siguiendo una estrategia, lo que implica el proceso de detección de las interfaces de programación de aplicaciones. No se puede proteger una API si esta pasa desapercibida para la solución de seguridad, por lo que es necesario crear un inventario. También es necesario detectar las API, ya que las puertas de enlace y los firewalls de aplicaciones web (WAF) correspondientes no crean un inventario automático de todas las API de un entorno, a pesar de lo que la gente pueda pensar.

API no autorizadas, zombis y en la sombra

Durante el proceso de detección de las API los administradores de TI siempre se sorprendan al descubrir que sus entornos incluyen numerosas API "no autorizadas", "zombis" y "en la sombra".

• Una API no aprobada es aquella que, de alguna manera, se ha perdido con el tiempo. Puede que se trate de una versión antigua de una API que no se haya desactivado. Podría tratarse de una API expuesta en una aplicación de software empaquetada comercial que nadie sabía que existía. 
• Una API zombi es una API operativa que pasa desapercibida. 
• Una API en la sombra es aquella que crea alguien que se encarga de desarrollar API, pero que no comunica que la ha creado al departamento de TI.

Los tres tipos de API no detectadas generan exposición al riesgo. No se pueden aplicar políticas de seguridad porque son invisibles. Como no están configuradas para ofrecer seguridad, y casi siempre tienen una configuración incorrecta o no tienen aplicados los parches necesarios, permitirán que los atacantes accedan a ellas.

Puede resultar difícil saber qué hacer con API que antes no se sabía que existían. Para seguir utilizándose, deben cumplir las políticas relativas a la configuración, la autenticación, entre otros factores. Desactivar una API recién detectada puede ser la mejor opción, pero esto puede generar problemas.

Por ejemplo, si una versión anterior de una API sigue siendo utilizada, a pesar de haber sido reemplazada por otra, desactivarla podría provocar fallos en las aplicaciones. Alguien podría tener problemas por tomar la decisión de desconectar la API. Lo que se requiere es un conjunto de herramientas que ofrezca a los administradores la información que necesitan para tomar la decisión correcta.

Para una seguridad integral de las API es necesario contar con las herramientas adecuadas. Una solución de seguridad integral de las API eficaz será aquella que pueda gestionar las pruebas de seguridad de las API, la seguridad en tiempo de ejecución de estas, así como la gestión y creación de inventarios de la estrategia de seguridad de las mismas. Es necesario adoptar una postura crítica ante las herramientas existentes, ya que la mayoría de los firewalls de aplicaciones web (WAF) y las puertas de enlace de API no abarcan las fases de desarrollo, pruebas, supervisión en tiempo de ejecución ni inventario.

La solución de seguridad de las API también debería tener un funcionamiento que no afectara al rendimiento de la red o de la API. Por ejemplo, las soluciones de seguridad de la API de Akamai supervisan una copia del tráfico de red. Pueden detectar llamadas a las API en esa copia del tráfico de red, identificando API desconocidas y amenazas de seguridad en el proceso.

La seguridad de las API debe abarcar todas las fases de la vida de una API, desde el desarrollo, pasando por el tiempo de ejecución, y hasta la retirada. La seguridad proviene, en parte, de procesos que técnicamente no abordan la seguridad, como los inventarios de las API. Como las interfaces de programación de aplicaciones desconocidas generan exposición al riesgo, al identificarlas, sus aplicaciones son más seguras. Se trata de una respuesta integral. Cuanto más completas sean las medidas de seguridad de las API, más seguro será todo el entorno.