A medida que las arquitecturas monolíticas migran a los microservicios, las aplicaciones se desarrollan más rápido que nunca. La velocidad es esencial para mantener la competitividad, y las API están a la vanguardia de estos rápidos esfuerzos de modernización. Sin embargo, la popularidad de las API para modernizar aplicaciones tiene importantes implicaciones para la seguridad de estas. Las API son objetivos vulnerables a los ataques, ya que exponen la lógica de las aplicaciones y los datos confidenciales a otras aplicaciones o a terceros. A medida que aumenta el uso de las API, también crece la necesidad de contar con puertas de enlace de API.
Según el informe State of Application Strategy 2021 de F5, las organizaciones utilizan diversos métodos para modernizarse, y las API encabezan estos esfuerzos de modernización:
- El 58 % está añadiendo una capa de API para habilitar interfaces de usuario modernas
- El 51 % está añadiendo componentes de aplicaciones modernas (por ejemplo, Kubernetes)
- El 47 % está refactorizando (modificando el propio código de la aplicación)
- El 40 % está migrando a la nube pública (lift and shift) sin modernizar
A medida que las organizaciones crecen, pueden mitigar los riesgos de las API mediante la adopción de una puerta de enlace de API. En la versión actualizada de F5 del Informe sobre el estado de la estrategia de aplicaciones de 2022, observamos que las puertas de enlace de API ofrecen un mejor rendimiento en el perímetro o cerca de él. Allí, pueden detener los ataques antes de que afecten a toda la red, proporcionando una protección uniforme y coherente para varias API. Las puertas de enlace de API encapsulan la estructura interna de una aplicación, lo que agiliza la comunicación entre el cliente y la API. En lugar de invocar servicios específicos, los clientes simplemente se conectan a la puerta de enlace de API. De este modo, el cliente dispone de una API específica, se reduce el número de intercambios entre el cliente y la API y se simplifica el código del cliente.
Los clientes de F5 NGINX han implementado con éxito gateways de API en entornos distribuidos. Sin embargo, si su gateway de API no es seguro, los actores maliciosos aún pueden infiltrarse. En NGINX, contamos con sólidas herramientas de seguridad para garantizar que sus aplicaciones situadas detrás de gateways de API permanezcan protegidas en este panorama en constante evolución.
Más API implican una mayor superficie de ataque
Las API no son algo nuevo. Las API basadas en la web se remontan a la década de 1990, e incluso existían versiones de API antes de la aparición de Internet tal y como la conocemos hoy, como medio de comunicación entre redes pequeñas y distribuidas. Lo que estamos viendo ahora —lo que ha cambiado las reglas del juego— son las arquitecturas modernas que utilizan API.
Aunque las API desempeñan un papel fundamental a la hora de acelerar la modernización, también son cada vez más fáciles de explotar. En las arquitecturas de microservicios, una sola API puede tener cientos de puntos de conexión, y una única aplicación puede estar formada por numerosos microservicios que utilizan API para conectarse entre sí. Esto difiere de las aplicaciones monolíticas del pasado, en las que solo había un punto de entrada que proteger. Dado que cada microservicio expone varios conjuntos de puntos de conexión de API, la superficie de ataque potencial se ha multiplicado por diez.
El informe de F5 de 2022 también reveló que la mayoría de las organizaciones tienen entre 200 y 1.000 aplicaciones, y que el 77 % ejecuta aplicaciones en varias nubes. Cuantas más aplicaciones y API se añadan a una cartera en entornos distribuidos, mayor será la superficie de ataque potencial.
Las 10 principales vulnerabilidades de seguridad de las API según OWASP
Por lo general, las API son abiertas y pueden exponer datos confidenciales. El Proyecto Abierto de Seguridad de Aplicaciones Web (OWASP) destaca las vulnerabilidades más frecuentes en su proyecto «OWASP API Security Top 10:
API1. Autorización de nivel de objeto defectuosa
API2. Autenticación de usuario defectuosa
API3. Exposición excesiva de datos
API4. Falta de recursos y limitación de solicitudes
API5. Autorización de nivel de función defectuosa
API6. Asignación masiva
API7. Configuración de seguridad incorrecta
API8. Inyección
API9. Gestión inadecuada de activos
API10. Registro y supervisión insuficientes
Las empresas actuales necesitan agilidad y rapidez a medida que se aceleran los ciclos de desarrollo. En este entorno vulnerable e impulsado por las API, las soluciones de seguridad deben ser adaptables, ligeras e integrarse en los procesos de despliegue automatizado de las API.
Empiece a proteger sus API con F5 NGINX Plus
Los ataques de gran repercusión contra las API suelen acaparar titulares. En 2019, a la empresa de transporte compartido Uber le descubrieron un fallo crítico en su API : un endpoint vulnerable de la API permitía a los ciberdelincuentes robar datos valiosos, incluidos los tokens de autenticación de los pasajeros. Afortunadamente, este fallo se descubrió antes de que causara daños. En 2021, LinkedIn no tuvo tanta suerte: debido a una vulnerabilidad en una API, los hackers accedieron a datos de más de 700 millones de usuarios de LinkedIn, que posteriormente se pusieron a la venta en la web oscura.
Al implementar F5 NGINX Plus como gateway de API, puede adentrarse en este dinámico panorama de las API con un alto rendimiento en el enrutamiento y la entrega de API. GigaOm, una empresa independiente de investigación y análisis tecnológico, comparó el rendimiento de NGINX con el de otras soluciones de gateway de API. Los resultados de la comparativa mostraron que NGINX era capaz de procesar 30.000 solicitudes por segundo con una latencia inferior a 30 ms, una latencia 1000 veces menor que la de los gateways de API de los hiperescaladores.
NGINX Plus ofrece protección inmediata no solo contra las vulnerabilidades de las API recogidas por OWASP, sino que su protección de seguridad adicional también incluye comprobaciones de cookies, JSON y XML con formato incorrecto, y valida los tipos de archivo permitidos y los códigos de estado de respuesta. Garantiza el cumplimiento de las RFC de HTTP y detecta las técnicas de evasión utilizadas para ocultar ataques.
NGINX Plus enruta rápidamente las solicitudes de API, al tiempo que autentica y autoriza a los clientes de API para proteger sus API y limita la tasa de tráfico para evitar que sus servicios basados en API se sobrecarguen. Estas herramientas también protegen sus API frente a las diez principales vulnerabilidades de seguridad de API de OWASP:
- Mecanismos de autenticación y autorización – Garantizan que solo los clientes con los privilegios de acceso adecuados puedan utilizar sus API. Uno de estos mecanismos son las declaraciones de los tokens web JSON (JWT). Esto permite abordar varias vulnerabilidades del Top 10 de seguridad de API de OWASP: Autorización de nivel de objeto rota (API1), Autenticación de usuario rota (API2), Autorización de nivel de función rota (API5) y Registro y supervisión insuficientes (API10).
- Políticas de limitación de solicitudes – Proteja sus API frente a la sobrecarga y mitigue los ataques DDoS estableciendo un límite en el número de solicitudes que la puerta de enlace de API acepta de cada cliente de API durante un periodo de tiempo determinado. Con NGINX Plus, los límites de solicitudes pueden ser específicos para cada origen (por ejemplo, en función del valor de una declaración JWT), de modo que los usuarios legítimos no se vean afectados. Esto ayuda a abordar la vulnerabilidad de Falta de recursos y limitación de solicitudes (API4).
Refuerce sus API con F5 NGINX App Protect WAF
Proteger su puerta de enlace de API con F5 NGINX App Protect WAF proporciona seguridad adicional para las API y mitiga ataques de OWASP como la inyección (API8). A diferencia de otros proveedores de puertas de enlace y gestión de API que ofrecen la protección mínima de OWASP para las API, NGINX App Protect WAF proporciona protección adicional frente a vulnerabilidades como la ejecución remota de código (RCE), el scripting entre sitios (XSS) y otros vectores de ataque. NGINX App Protect WAF también proporciona la visibilidad necesaria de los ataques para abordar la insuficiencia de registros y supervisión (API10). Los detalles registrados de estos ataques pueden enviarse a sistemas de gestión de eventos e información de seguridad (SIEM) o a otros lagos de datos del cliente para su posterior análisis.
Si utiliza NGINX Plus como puerta de enlace de API y equilibrador de carga (para enrutar las API que deben estar expuestas a Internet y destinadas a desarrolladores y socios externos), es el lugar idóneo para implementar NGINX App Protect WAF como medida de protección. Al eliminar un salto del tráfico de las API, la protección puede añadirse con la mínima complejidad y la menor latencia posibles.
Según los requisitos de cumplimiento de PCI para el tratamiento de datos sensibles (información de identificación personal [PII]) en determinados sectores, la carga útil debe estar cifrada de extremo a extremo a través de redes públicas y abiertas. Tener NGINX App Protect WAF en la puerta de enlace de API, detrás de un equilibrador de carga o una CDN, significa que la carga útil permanece totalmente cifrada hasta que se descifra en la puerta de enlace de API. De este modo, sus API pueden seguir protegidas y, al mismo tiempo, cumplir los requisitos para el tratamiento de datos sensibles.
Protección multicapa con F5 NGINX App Protect WAF
Puede que tenga un equilibrador de carga y que este cuente con un WAF, como F5 Advanced WAF. Detrás de ellos, ha implementado una puerta de enlace de API. Entonces, ¿por qué necesita un WAF en su puerta de enlace de API si ya tiene uno en el equilibrador de carga?
Una de las principales ventajas de pasar de una combinación de balanceador de carga y WAF en el perímetro a una combinación de puerta de enlace de API y WAF dentro de su entorno es que permite ejercer un control más estricto y granular sobre la seguridad. La responsabilidad de la seguridad puede delegarse en un equipo de API para que las políticas sean más específicas para las API.
Con este enfoque de dos niveles, puede garantizar que sus API permanezcan protegidas incluso durante los ciclos más rápidos de desarrollo y lanzamiento de API.
Añadir seguridad positiva mediante la validación de esquemas OpenAPI
Un aspecto clave en el que la protección debe ser específica para cada API es la validación de la especificación OpenAPI de Swagger. Los esquemas OpenAPI son exclusivos de cada API y cambian con cada versión. La protección basada en el esquema OpenAPI de una API no puede esperar a que un equipo de TI actualice los controles de seguridad del WAF centralizado que mantiene, ya que esto requiere aprobación y pruebas exhaustivas para evitar efectos inesperados en otras API y aplicaciones.
NGINX App Protect WAF puede validar los esquemas de OpenAPI y comprobar que las solicitudes se ajusten a lo que admite la API (métodos, endpoints, parámetros, etc.). Por eso, lo ideal es que NGINX App Protect WAF proporcione seguridad positiva en la puerta de enlace de API, detrás de un WAF centralizado en el balanceador de carga.
«Seguridad como código» para seguir el ritmo de las implementaciones de API
Los pipelines de CI/CD están diseñados para ofrecer velocidad, no seguridad. Además, las API se publican con más frecuencia que las aplicaciones de antes. Por eso estamos observando un movimiento de desplazamiento a la izquierda en el panorama impulsado por las API. Al desplazar la seguridad a la izquierda, es decir, al aplicar controles de seguridad en fases más tempranas del ciclo de vida del desarrollo de aplicaciones, DevOps evoluciona hacia una cultura DevSecOps en la que la seguridad se trata como código.
Tanto si se ubica un WAF en la puerta de enlace de API como en el equilibrador de carga o en ambos, las configuraciones del WAF deben implementarse de forma automatizada para adaptarse a los cambios de versión de las API. Cuando las organizaciones adoptan una cultura de desplazamiento a la izquierda e integran la «seguridad como código» en el proceso de CI/CD, la seguridad puede incorporarse en cada etapa del desarrollo de aplicaciones y API, en lugar de añadirse a posteriori.
El uso de políticas y configuraciones de seguridad como código ofrece numerosas ventajas:
- El código se puede obtener fácilmente de un repositorio de código fuente.
- Su equipo de SecOps puede crear y mantener políticas de seguridad declarativas para garantizar que se implementen los controles necesarios para proteger la empresa.
- Las políticas declarativas pueden incorporarse mediante código de forma reiterada en nuevas aplicaciones y API.
- La seguridad se automatiza dentro del pipeline de CI/CD.
Al automatizar el esquema de la API, cada vez que se actualiza una API también es necesario actualizar la configuración y el código de ese archivo. Una vez más, la automatización es clave. Cuando se adopta plenamente una filosofía de desplazamiento a la izquierda o de «seguridad ante todo», los desarrolladores pueden obtener fácilmente ese código del repositorio, lo que permite mantener la agilidad, aumentar la velocidad y acelerar la comercialización.
Protección de alto rendimiento para tus API
Independientemente de dónde implemente un WAF para proteger sus API, un alto rendimiento y una baja latencia son requisitos que permiten que sus API respondan rápidamente a los clientes y ofrezcan una experiencia de usuario más completa. La arquitectura ligera del WAF de NGINX App Protect proporciona este alto rendimiento y esta baja latencia con unos requisitos de computación en la nube extremadamente bajos.
En su informe «Pruebas de seguridad de aplicaciones de alto rendimiento», GigaOm presenta los resultados de las pruebas de rendimiento de NGINX App Protect WAF, AWS WAF, Azure WAF y ModSecurity Open Source WAF. GigaOm constató que NGINX App Protect WAF ofrece una latencia 4,7 veces menor que ModSecurity OSS WAF en NGINX y 128 veces menor que AWS WAF para aplicaciones que requieren un alto rendimiento.
NGINX es el único proveedor que integra un WAF en una puerta de enlace de API de NGINX, lo que elimina un salto en el tráfico de la API. Reducir el número de saltos entre capas disminuye la latencia, la complejidad y los puntos de fallo. Esto contrasta claramente con las soluciones habituales de gestión de API que no se integran con un WAF (es necesario implementar el WAF por separado y, una vez configurado, el tráfico de la API debe atravesar por separado el WAF y la puerta de enlace de API). La estrecha integración de NGINX ofrece un alto rendimiento sin comprometer la seguridad.
Conclusión
En NGINX, ofrecemos una sólida seguridad para las API con NGINX Plus y NGINX App Protect WAF. Gracias a la escalabilidad ligera de NGINX y a la solidez del motor Advanced WAF de F5, puede adentrarse en el mundo impulsado por las API con la confianza de que sus aplicaciones modernas están protegidas.
En consonancia con los valores fundamentales de NGINX, NGINX App Protect WAF es una moderna solución de seguridad de software para aplicaciones, independiente de la plataforma y que se integra a la perfección con las cadenas de herramientas habituales de DevOps para eliminar obstáculos y agilizar las implementaciones seguras. Gracias a sus capacidades de configuración declarativa, la seguridad puede automatizarse como parte del proceso de CI/CD y de todo el ciclo de vida del desarrollo de software (SDLC). Esto no solo ayuda a acelerar el ritmo de los lanzamientos, sino que también permite a las organizaciones crear API fiables y protegidas, reducir las brechas entre los equipos de DevOps y SecOps y facilitar un cambio cultural hacia DevSecOps.
¿Quieres probar NGINX App Protect WAF? Empieza hoy mismo una prueba gratuita de 30 días o ponte en contacto con nosotros para hablar sobre tus casos de uso.
Sobre los autores
Artículos relacionados del blog
Únete a F5 NGINX en AppWorld 2024
Descubre las numerosas razones para asistir al evento insignia de F5, que incluirá un emocionante anuncio sobre la cartera de productos NGINX.
Rotación de certificados SSL/TLS sin reinicios en NGINX Open Source
La función de diccionario compartido permite configurar NGINX sin necesidad de reiniciarlo al renovar los certificados SSL/TLS.
Exposición de APIs en Kubernetes
La unidad 2 de Microservices March 2022 se centra en cómo exponer tus API en Kubernetes. Aquí tienes enlaces a los recursos que necesitas: la retransmisión en directo del 14 de marzo, artículos de blog y otros recursos de preparación, y el laboratorio práctico «Protege las API de Kubernetes mediante la limitación de solicitudes».
NGINX Sprint 2.0: visión clara, código renovado y nuevos compromisos con el código abierto
Hoy, en NGINX Sprint 2.0, anunciamos cómo respaldaremos nuestra visión del futuro de las aplicaciones modernas con una mayor presencia en la comunidad de código abierto, incluida la participación en el proyecto comunitario Kubernetes, nuevos proyectos de software de código abierto y la arquitectura de referencia para aplicaciones modernas.
Presentamos NGINX Plus R22
NGINX Plus R22 incorpora nuevas funcionalidades, como la compatibilidad con OCSP para verificar la revocación de certificados en TLS mutuo, el uso de varios proveedores de identidad OIDC en una configuración, el seguimiento en tiempo real de la limitación de solicitudes y conexiones en el panel de NGINX Plus y mejoras en NGINX JavaScript.
Presentamos NGINX Plus R17
NGINX Plus R17 incorpora compatibilidad con la limitación de velocidad en dos fases y con TLS 1.3, la versión más reciente del protocolo Transport Layer Security. La configuración de OpenID Connect es más sencilla y NGINX ModSecurity WAF es el doble de rápido que antes. También se ha actualizado el módulo JavaScript de NGINX.