A medida que los monolitos pasan a los microservicios, las aplicações se desarrollan más rápido que nunca. La velocidad es necesaria para seguir siendo competitivo y las API están al frente de estos esfuerzos de rápida modernización. Pero la popularidad de las API para la modernización de aplicação tiene implicaciones significativas para la seguridad de las aplicaciones. Las API son objetivos de ataques vulnerables que exponen la lógica de la aplicação y datos confidenciales a otras aplicaciones o terceros. A medida que crece el uso de API, también crece la necesidad de puertas de enlace de API.
Según el Informe sobre el estado de la estrategia de aplicação de 2021 de F5, las organizaciones están utilizando diversos métodos para modernizarse, y las API encabezan estos esfuerzos de modernización:
A medida que las organizaciones crecen, pueden mitigar los riesgos de las API adoptando una puerta de enlace de API. En el Informe sobre el estado de la estrategia de aplicação de 2022 actualizado de F5, vemos que las puertas de enlace de API funcionan mejor en el borde o cerca de él. Aquí, las puertas de enlace API pueden detener los ataques antes de que afecten a toda la red, proporcionando una protección uniforme y consistente para múltiples API. Las puertas de enlace API encapsulan la estructura interna de una aplicación, optimizando 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 API. Esto proporciona al cliente una API específica, reduce la cantidad de viajes de ida y vuelta entre el cliente y la API y simplifica el código del cliente.
Los clientes de F5 NGINX han implementado con éxito puertas de enlace API en entornos distribuidos. Pero si su puerta de enlace API no es segura, los actores maliciosos aún pueden ingresar. En NGINX, contamos con sólidas herramientas de seguridad para garantizar que sus aplicaciones detrás de puertas de enlace API permanezcan seguras en este panorama en constante cambio.
Las API no son nuevas. Las API basadas en la Web se remontan a la década de 1990, e incluso existían versiones de API antes de Internet como las conocemos hoy, como comunicación entre redes pequeñas y distribuidas. Lo que estamos viendo ahora –lo que ha cambiado el juego– son las arquitecturas modernas que utilizan API.
Si bien las API desempeñan un papel vital en la aceleración de la modernización, al mismo tiempo cada vez son más fáciles de explotar. En las arquitecturas de microservicios, una sola API puede tener cientos de puntos finales y una sola aplicação puede constar de muchos microservicios que usan API para conectarse entre sí. Esto difiere de las aplicaciones monolíticas del pasado, donde solo había un punto de entrada para proteger. Dado que cada microservicio expone múltiples conjuntos de puntos finales de API, la superficie de ataque potencial se ha multiplicado por diez.
El informe de 2022 de F5 también encontró que la mayoría de las organizaciones tienen entre 200 y 1000 aplicaciones y el 77 % ejecuta aplicações en múltiples nubes. Cuanto más aplicaciones y API se agreguen a una cartera en entornos distribuidos, mayor será su posible superficie de ataque.
Característicamente, las API son abiertas y pueden exponer datos confidenciales. El Proyecto de Seguridad de Aplicação Web Abiertas (OWASP) destaca las vulnerabilidades más frecuentes en su proyecto OWASP API Security Top 10 :
Las empresas de hoy requieren agilidad y velocidad a medida que los ciclos de desarrollo se aceleran. Las soluciones de seguridad en este panorama vulnerable impulsado por API deben ser adaptables, livianas e incorporadas como parte de los procesos de implementación automatizada de una API.
Los ataques de API de alto perfil acaparan titulares periódicamente. En 2019, la empresa de viajes compartidos Uber tuvo un error crítico descubierto en su API : un punto final de API vulnerable permitía a actores maliciosos robar datos valiosos, incluidos los tokens de autenticación de los pasajeros. Afortunadamente, este error fue descubierto antes de que ocurriera algún daño. En 2021, LinkedIn no tuvo tanta suerte: debido a una vulnerabilidad de la API, los piratas informáticos violaron los datos de más de 700 millones de usuarios de LinkedIn , que luego se ofrecieron a la venta en la red oscura.
Al implementar F5 NGINX Plus como su puerta de enlace API , puede ingresar a este rápido panorama de API con alto rendimiento al gestionar el enrutamiento y la entrega de API. GigaOm, una empresa independiente de análisis e investigación tecnológica, comparó NGINX con otras soluciones de puerta de enlace API . Los resultados de referencia mostraron que NGINX pudo entregar 30.000 solicitudes por segundo con una latencia de menos de 30 ms, lo que supone una latencia 1000 veces menor que la de las puertas de enlace de API de los hiperescaladores.
NGINX Plus brinda protección inmediata no solo contra vulnerabilidades de la API de OWASP: su protección de seguridad adicional también incluye verificaciones de cookies malformadas, JSON y XML, y valida los tipos de archivos permitidos y los códigos de estado de respuesta. Garantiza el cumplimiento de las RFC HTTP y detecta técnicas de evasión utilizadas para enmascarar ataques.
NGINX Plus enruta las solicitudes de API rápidamente, al mismo tiempo que autentica y autoriza a los clientes de API para proteger sus API y limita la velocidad del tráfico para proteger sus servicios basados en API contra la sobrecarga. Estas herramientas también protegen sus API de las diez principales vulnerabilidades de seguridad de API de OWASP:
Proteger su API gateway con F5 NGINX App Protect WAF brinda seguridad de API adicional y mitiga ataques OWASP como Injection (API8). A diferencia de otros proveedores de gestión y gateway de API que ofrecen lo mínimo indispensable para la protección de la API de OWASP, NGINX App Protect WAF brinda protección adicional contra vulnerabilidades como ejecución remota de código (RCE), secuencias de comandos entre sitios (XSS) y otros vectores de ataque. NGINX App Protect WAF también proporciona la visibilidad de ataque necesaria para registro y monitoreo insuficientes (API10). Estos detalles de ataques registrados se pueden enviar a sistemas de gestión de eventos e información de seguridad (SIEM) u otros lagos de datos de clientes para un análisis adicional.
Si está utilizando NGINX Plus como puerta de enlace de API y balanceador de carga (para enrutar API que necesitan estar expuestas a Internet y para desarrolladores y socios externos), es un lugar privilegiado para implementar NGINX App Protect WAF para su protección. Con un salto menos para el tráfico de API, se puede agregar protección con la menor cantidad de complejidad y la menor latencia.
Según los requisitos de cumplimiento de PCI para el manejo de datos confidenciales (información de identificación personal [PII]) en ciertas industrias, la carga útil debe estar cifrada de extremo a extremo en redes públicas abiertas . Tener NGINX App Protect WAF en la puerta de enlace de API, detrás de un balanceador de carga o CDN, significa que la carga útil permanece completamente cifrada hasta que se descifra en la puerta de enlace de API. De esta forma, sus API pueden permanecer protegidas y al mismo tiempo cumplir con los requisitos de manejo de datos confidenciales.
Es posible que tenga un balanceador de carga y un WAF (como F5 Advanced WAF ) en ese balanceador de carga. Detrás de estos, has implementado una puerta de enlace API. Entonces, ¿por qué necesitas un WAF en tu API Gateway si ya tienes uno en tu balanceador de carga?
Uno de los principales beneficios de pasar de una combinación de balanceador de carga y WAF en el borde a una combinación de API Gateway y WAF dentro de su entorno es un control granular sobre la seguridad. La responsabilidad de la seguridad se puede delegar en un equipo de API para que las políticas sean más específicas de la API.
Con este enfoque de dos niveles, puede garantizar que sus API permanezcan protegidas incluso en los ciclos de desarrollo y lanzamiento de API más rápidos.
Un área clave donde la protección debe ser específica de la API es la validación de la especificación OpenAPI de Swagger. Los esquemas OpenAPI son únicos para cada API y cambian con cada versión de API. 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 en el WAF centralizado que mantiene, lo que requiere aprobación y pruebas cuidadosas para evitar efectos inesperados en otras API y aplicaciones.
NGINX App Protect WAF puede validar esquemas OpenAPI, verificando que las solicitudes cumplan con lo que admite la API (métodos, puntos finales, parámetros, etc.). Por eso es ideal que NGINX App Protect WAF brinde seguridad positiva en la puerta de enlace API detrás de un WAF centralizado en el balanceador de carga.
Los pipelines de CI/CD están diseñados para la velocidad, no para la seguridad. Las API también se publican con mayor frecuencia que las aplicaciones del pasado. Es por esto que estamos viendo un movimiento hacia la izquierda en el panorama impulsado por API. Al desplazarse a la izquierda o aplicar controles de seguridad más temprano en el ciclo de vida del desarrollo de la aplicación, DevOps avanza hacia una cultura DevSecOps donde la seguridad se trata como código.
Ya sea que ubique un WAF en la puerta de enlace de API, el balanceador de carga o ambos, las configuraciones de WAF deben implementarse de manera automatizada para mantenerse al día con los cambios de versión de API. Cuando las organizaciones adoptan una cultura de cambio a la izquierda e integran la “seguridad como código” en el flujo de trabajo de CI/CD, la seguridad se puede incorporar en cada etapa del desarrollo de aplicação y API, en lugar de agregarse como una ocurrencia de último momento.
Existen muchos beneficios al consumir las políticas y configuraciones de seguridad como código:
Al automatizar el esquema de API, cada vez que actualiza una API también necesita actualizar la configuración y el código en ese archivo. Una vez más, la automatización es clave. Una vez que se adopta por completo una filosofía de cambio a la izquierda o de “seguridad primero”, los desarrolladores pueden obtener fácilmente ese código del repositorio, lo que mantiene la agilidad, aumenta la velocidad y acelera el tiempo de comercialización.
Independientemente de dónde coloque un WAF para proteger sus API, el alto rendimiento y la baja latencia son requisitos que permiten que sus API respondan rápidamente a los clientes para una experiencia de usuario más enriquecida. La arquitectura liviana de NGINX App Protect WAF proporciona este alto rendimiento y baja latencia con demandas informáticas extremadamente bajas en la nube.
En su Informe de pruebas de seguridad de aplicação de alto rendimiento , GigaOm informa el resultado de las pruebas de rendimiento para NGINX App Protect WAF, AWS WAF, Azure WAF y ModSecurity Open Source WAF. GigaOm descubrió que NGINX App Protect WAF tiene una latencia 4,7 veces menor que ModSecurity OSS WAF en NGINX, y 128 veces menor que AWS WAF para aplicações que requieren alto rendimiento.
NGINX es el único proveedor que integra un WAF en una puerta de enlace API de NGINX, lo que da como resultado un salto menos para el tráfico API. Menos saltos entre capas reducen la latencia, la complejidad y los puntos de falla. Esto está en marcado contraste con las soluciones de gestión de API típicas que no se integran con un WAF (se debe implementar el WAF por separado y, una vez configurado, el tráfico de API debe atravesar el WAF y la puerta de enlace de API por separado). La estrecha integración de NGINX significa un alto rendimiento sin comprometer la seguridad.
En NGINX, ofrecemos una sólida seguridad de API con NGINX Plus y NGINX App Protect WAF. Con la escalabilidad liviana de NGINX y la robustez del motor Advanced WAF de F5, puede ingresar al mundo impulsado por API con la confianza de que sus aplicaciones modernas son seguras.
Fiel a los valores fundamentales de NGINX, NGINX App Protect WAF es una solución de seguridad de software de aplicação moderna que es independiente de la plataforma y se integra perfectamente con las cadenas de herramientas DevOps comunes para eliminar la fricción y acelerar las implementaciones seguras. Con 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 la velocidad de lanzamiento, sino que también ayuda a las organizaciones a construir API confiables y protegidas al mismo tiempo que cierra las brechas entre los equipos de DevOps y SecOps y permite un cambio cultural hacia DevSecOps.
¿Estás listo para probar NGINX App Protect WAF por ti mismo? Comience hoy una prueba gratuita de 30 días o contáctenos para analizar sus casos de uso .
"Esta publicación de blog puede hacer referencia a productos que ya no están disponibles o que ya no reciben soporte. Para obtener la información más actualizada sobre los productos y soluciones F5 NGINX disponibles, explore nuestra familia de productos NGINX . NGINX ahora es parte de F5. Todos los enlaces anteriores de NGINX.com redirigirán a contenido similar de NGINX en F5.com.