Seis formas de proteger Kubernetes mediante herramientas de gestión del tráfico

Editor : Esta publicación es parte de una serie de 10 partes:

1. Reduzca la complejidad con Kubernetes de nivel de producción
2. Cómo mejorar la resiliencia en Kubernetes con la gestión avanzada del tráfico
3. Cómo mejorar la visibilidad en Kubernetes
4. Seis maneras de proteger Kubernetes con herramientas de gestión de tráfico (esta publicación)
5. Guía para elegir un controlador de entrada, parte 1: Identifique sus requisitos
6. Guía para elegir un controlador de entrada, parte 2: Riesgos y preparación para el futuro
7. Guía para elegir un controlador de entrada, parte 3: Código abierto vs. Predeterminado vs. Comercial
8. Guía para elegir un controlador de entrada, parte 4: Opciones del controlador de ingreso NGINX
9. Cómo elegir una malla de servicios
10. Pruebas de rendimiento de controladores de ingreso NGINX en un entorno dinámico de nube de Kubernetes

También puede descargar el conjunto completo de blogs como un libro electrónico gratuito: Cómo llevar Kubernetes de la prueba a la producción .

Como se analiza en Cómo proteger aplicaciones nativas de la nube sin perder velocidad , hemos observado tres factores que hacen que las aplicaciones nativas de la nube sean más difíciles de proteger que las aplicaciones tradicionales:

1. La entrega de aplicaciones nativas de la nube provoca una proliferación de herramientas y ofrece servicios inconsistentes de nivel empresarial.
2. Los costos de entrega de aplicaciones nativas de la nube pueden ser impredecibles y altos
3. Los equipos de SecOps tienen dificultades para proteger las aplicaciones nativas de la nube y están en desacuerdo con DevOps

Si bien los tres factores pueden afectar por igual la seguridad, el tercero puede ser el problema más difícil de resolver, quizás porque es el más “humano”. Cuando SecOps no puede o no tiene la capacidad para proteger las aplicaciones nativas de la nube, algunas de las consecuencias son obvias (vulnerabilidades y brechas), pero otras están ocultas, incluida la agilidad reducida y el estancamiento de la transformación digital.

Profundicemos en esos costos ocultos. Las organizaciones eligen Kubernetes por su promesa de agilidad y ahorro de costos. Pero cuando hay incidentes de seguridad en un entorno de Kubernetes, la mayoría de las organizaciones retiran sus implementaciones de Kubernetes de producción . Esto ralentiza las iniciativas de transformación digital que son esenciales para el futuro de la organización, sin mencionar el desperdicio de esfuerzos de ingeniería y dinero. La conclusión lógica es: si vamos a intentar llevar Kubernetes de la prueba a la producción, entonces la seguridad debe considerarse un componente estratégico que es propiedad de todos en la organización.

En esta publicación, cubrimos seis casos de uso de seguridad que puede resolver con herramientas de gestión de tráfico de Kubernetes, lo que permite que SecOps colabore con DevOps y NetOps para proteger mejor sus aplicaciones y API nativas de la nube. A menudo se utiliza una combinación de estas técnicas para crear una estrategia de seguridad integral diseñada para mantener las aplicaciones y las API seguras y minimizar el impacto para los clientes.

1. Resuelva los CVE rápidamente para evitar ciberataques
2. Detener los 10 principales ataques de OWASP y de denegación de servicio
3. Descargue la autenticación y autorización de las aplicaciones
4. Configurar autoservicio con barandillas
5. Implementar el cifrado de extremo a extremo
6. Asegúrese de que los clientes utilicen un cifrado sólido con una implementación confiable

Terminología de seguridad e identidad

Antes de pasar a los casos de uso, aquí hay una descripción general rápida de algunos términos de seguridad e identidad que encontrará a lo largo de esta publicación.

• Autenticación y autorización : funciones necesarias para garantizar que solo los usuarios y servicios “adecuados” puedan acceder a los backends o componentes de la aplicação :

  • Autenticación : verificación de identidad para garantizar que los clientes que realizan solicitudes sean quienes dicen ser. Esto se logra mediante tokens de identificación, como contraseñas o tokens web JSON (JWT).

  • Autorización – Verificación del permiso para acceder a un recurso o función. Se logra a través de tokens de acceso, como atributos de capa 7 como cookies de sesión, ID de sesión, ID de grupo o contenido de token.

• Vulnerabilidades y exposiciones críticas (CVE) : una base de datos de fallas divulgadas públicamente “en un software, firmware, hardware o componente de servicio que resultan de una debilidad que puede explotarse, causando un impacto negativo en la confidencialidad, integridad o disponibilidad de un componente o componentes afectados” ( https://www.cve.org/ ). Los CVE pueden ser descubiertos por los desarrolladores que administran la herramienta, un evaluador de penetración, un usuario o cliente, o alguien de la comunidad (como un “cazador de errores”). Es una práctica común darle tiempo al propietario del software para desarrollar un parche antes de que la vulnerabilidad se divulgue públicamente, para no darles una ventaja a los malos actores.

• Ataque de denegación de servicio (DoS) : un ataque en el que un actor malicioso inunda un sitio web con solicitudes (TCP/UDP o HTTP/HTTPS) con el objetivo de hacer que el sitio falle. Debido a que los ataques DoS afectan la disponibilidad, su resultado principal es dañar la reputación del objetivo. Un ataque de denegación de servicio distribuido (DDoS) , en el que múltiples fuentes apuntan a la misma red o servicio, es más difícil de defender debido a la red potencialmente grande de atacantes. La protección DoS requiere una herramienta que identifique y prevenga los ataques de forma adaptativa. Obtenga más información en ¿Qué es la denegación de servicio distribuida (DDoS)?

• Cifrado de extremo a extremo (E2EE) : la práctica de cifrar completamente los datos a medida que pasan del usuario a la aplicación y viceversa. E2EE requiere certificados SSL y potencialmente mTLS.

• TLS mutuo (mTLS) : la práctica de requerir autenticación (a través de un certificado SSL/TLS) tanto para el cliente como para el host. El uso de mTLS también protege la confidencialidad e integridad de los datos que pasan entre el cliente y el host. mTLS se puede implementar hasta el nivel de pod de Kubernetes, entre dos servicios en el mismo clúster. Para obtener una excelente introducción a SSL/TLS y mTLS, consulte ¿Qué es mTLS? en F5 Labs.

• Inicio de sesión único (SSO) : las tecnologías SSO (incluidas SAML, OAuth y OIDC) facilitan la gestión de la autenticación y la autorización.

  • Autenticación simplificada : SSO elimina la necesidad de que un usuario tenga un token de identificación único para cada recurso o función diferente.

  • Autorización estandarizada : SSO facilita la configuración de los derechos de acceso de los usuarios según el rol, el departamento y el nivel de antigüedad, eliminando la necesidad de configurar permisos para cada usuario individualmente.

• SSL (Secure Sockets Layer)/TLS (Transport Layer Security) : un protocolo para establecer enlaces autenticados y cifrados entre computadoras en red. Los certificados SSL/TLS autentican la identidad de un sitio web y establecen una conexión cifrada. Aunque el protocolo SSL quedó obsoleto en 1999 y fue reemplazado por el protocolo TLS, aún es común referirse a estas tecnologías relacionadas como “SSL” o “SSL/TLS”; por el bien de la coherencia, usaremos SSL/TLS en el resto de esta publicación.

• Firewall de aplicação web (WAF) : un proxy inverso que detecta y bloquea ataques sofisticados contra aplicaciones y API (incluidos OWASP Top 10 y otras amenazas avanzadas) mientras permite el paso del tráfico "seguro". Los WAF se defienden contra ataques que intentan dañar al objetivo robando datos confidenciales o secuestrando el sistema. Algunos proveedores consolidan la protección WAF y DoS en la misma herramienta, mientras que otros ofrecen herramientas WAF y DoS separadas.

• Confianza cero : un concepto de seguridad que se utiliza con frecuencia en organizaciones de mayor seguridad, pero que es relevante para todos, en los que los datos deben protegerse en todas las etapas de almacenamiento y transporte. Esto significa que la organización ha decidido no “confiar” en ningún usuario o dispositivo de forma predeterminada, sino exigir que todo el tráfico sea examinado exhaustivamente. Una arquitectura de confianza cero generalmente incluye una combinación de autenticación, autorización y mTLS con una alta probabilidad de que la organización implemente E2EE.

CASO DE USO:Resuelva los CVE rápidamente para evitar ciberataques

Solución: Utilice herramientas con notificaciones de parches oportunas y proactivas

Según un estudio del Instituto Ponemon , en 2019 hubo un “período de gracia” promedio de 43 días entre el lanzamiento de un parche para una vulnerabilidad crítica o de alta prioridad y el momento en que las organizaciones veían ataques que intentaban explotar la vulnerabilidad. En F5 NGINX, hemos visto que esa ventana se ha reducido significativamente en los años siguientes (incluso hasta el día cero en el caso de Apple iOS 15 en 2021 ), por eso recomendamos aplicar el parche lo antes posible. ¿Pero qué pasa si los parches para sus herramientas de gestión de tráfico no están disponibles durante semanas o incluso meses después de que se anuncia un CVE?

Las herramientas que son desarrolladas y mantenidas por colaboradores de la comunidad (en lugar de un equipo de ingeniería dedicado) tienen el potencial de demorarse semanas o meses con respecto a los anuncios de CVE, lo que hace poco probable que las organizaciones puedan aplicar el parche dentro de ese período de 43 días . En un caso , OpenResty tardó cuatro meses en aplicar un parche de seguridad relacionado con NGINX. Eso dejó a cualquiera que use un controlador Ingress basado en OpenResty vulnerable durante al menos cuatro meses, pero siendo realistas, suele haber un retraso adicional antes de que haya parches disponibles para el software que depende de un proyecto de código abierto.

Para obtener la aplicación de parches CVE más rápida, busque dos características al seleccionar herramientas de administración de tráfico:

• Un equipo de ingeniería dedicado : cuando el desarrollo de herramientas lo gestiona un equipo de ingeniería en lugar de voluntarios de la comunidad, sabes que hay un grupo de personas dedicadas al estado de la herramienta y que pueden priorizar el lanzamiento de un parche lo antes posible.
• Una base de código integrada : sin ninguna dependencia externa (como discutimos con OpenResty), los parches están a solo un sprint ágil de distancia.

Para obtener más información sobre la aplicación de parches CVE, lea Cómo mitigar vulnerabilidades de seguridad de forma rápida y sencilla con NGINX Plus .

CASO DE USO:Detener los 10 principales ataques de OWASP y DoS

Solución: Implemente un WAF flexible y compatible con Kubernetes y protección DoS

La elección del WAF y la protección DoS adecuados para las aplicaciones de Kubernetes depende de dos factores (además de las características):

• Flexibilidad : hay situaciones en las que es mejor implementar herramientas dentro de Kubernetes, por lo que desea herramientas independientes de la infraestructura que puedan ejecutarse dentro o fuera de Kubernetes. Usar la misma herramienta para todas sus implementaciones le permite reutilizar políticas y reduce la curva de aprendizaje para sus equipos de SecOps.
• Huella : las mejores herramientas de Kubernetes tienen una huella pequeña, lo que permite un consumo adecuado de recursos con un impacto mínimo en el rendimiento, las solicitudes por segundo y la latencia. Dado que los equipos de DevOps a menudo se resisten a las herramientas de seguridad debido a la percepción de que ralentizan las aplicaciones, elegir una herramienta de alto rendimiento con un tamaño reducido puede aumentar la probabilidad de adopción.

Si bien una herramienta que consolida la protección WAF y DoS puede parecer más eficiente, en realidad se espera que tenga problemas tanto en el uso de la CPU (debido a una mayor huella) como en la flexibilidad. Estás obligado a implementar la protección WAF y DoS juntas, incluso cuando no necesitas ambas. En última instancia, ambos problemas pueden incrementar el costo total de propiedad de sus implementaciones de Kubernetes y, al mismo tiempo, crear desafíos presupuestarios para otras herramientas y servicios esenciales.

Una vez que haya elegido las herramientas de seguridad adecuadas para su organización, es momento de decidir dónde implementarlas. Hay cuatro ubicaciones donde normalmente se pueden implementar servicios de aplicação para proteger las aplicaciones de Kubernetes:

• En la puerta principal (en un balanceador de carga externo como F5 NGINX Plus o F5 BIG‑IP ): bueno para una protección global de “grano grueso” porque le permite aplicar políticas globales en varios clústeres
• En el borde (en un controlador de Ingress como F5 NGINX Ingress Controller ): ideal para brindar protección “de grano fino” que es estándar en un solo clúster
• En el servicio (en un balanceador de carga liviano como NGINX Plus): puede ser un enfoque necesario cuando hay una pequeña cantidad de servicios dentro de un clúster que tienen una necesidad compartida de políticas únicas.
• En el pod (como parte de la aplicação): un enfoque muy personalizado que podría usarse cuando la política es específica de la aplicación

Entonces, de las cuatro opciones, ¿cuál es la mejor? Bueno…¡eso depende!

Dónde implementar un WAF

Primero, veremos las opciones de implementación de WAF, ya que tiende a ser una elección más matizada.

• Puerta de entrada y borde : si su organización prefiere una estrategia de seguridad de“defensa en profundidad”, le recomendamos implementar un WAF tanto en el balanceador de carga externo como en el controlador de ingreso para brindar un equilibrio eficiente de protecciones globales y personalizadas.
• Puerta de entrada o borde : en ausencia de una estrategia de “defensa en profundidad”, una única ubicación es aceptable y la ubicación del despliegue depende de la propiedad. Cuando un equipo tradicional de NetOps es dueño de la seguridad, es posible que se sienta más cómodo administrándola en un proxy tradicional (el balanceador de carga externo). Sin embargo, los equipos de DevSecOps que se sienten cómodos con Kubernetes (y prefieren tener su configuración de seguridad cerca de las configuraciones de su clúster) pueden optar por implementar un WAF en el nivel de ingreso.
• Por servicio o pod : si sus equipos tienen requisitos específicos para sus servicios o aplicaciones, pueden implementar WAF adicionales a la carta. Pero tenga cuidado: estas ubicaciones tienen costos más altos. Además de un mayor tiempo de desarrollo y un mayor presupuesto de nube, esta elección también puede aumentar los costos operativos relacionados con los esfuerzos de resolución de problemas, como al determinar "¿cuál de nuestros WAF está bloqueando el tráfico involuntariamente?"

Dónde implementar la protección DoS

La protección contra ataques DoS es más sencilla, ya que solo se necesita en un lugar: en la puerta principal o en el controlador de ingreso. Si implementa un WAF tanto en la puerta principal como en el borde, le recomendamos que implemente protección DoS delante del WAF de la puerta principal, ya que es el más global. De esa manera, se puede reducir el tráfico no deseado antes de llegar al WAF, lo que permite hacer un uso más eficiente de los recursos informáticos.

Para obtener más detalles sobre cada uno de estos escenarios de implementación, lea Implementación de servicios de aplicação en Kubernetes, parte 2 .

CASO DE USO:Descargar autenticación y autorización de las aplicaciones

Solución: Centralizar la autenticación y la autorización en el punto de entrada

Un requisito no funcional común que se incorpora a las aplicaciones y los servicios es la autenticación y la autorización. A pequeña escala, esta práctica agrega una cantidad manejable de complejidad que es aceptable cuando la aplicación no requiere actualizaciones frecuentes. Pero con velocidades de lanzamiento más rápidas a mayor escala, integrar la autenticación y la autorización en sus aplicaciones se vuelve insostenible. Asegurarse de que cada aplicación mantenga los protocolos de acceso adecuados puede distraer la atención de la lógica comercial de la aplicación o, peor aún, puede pasarse por alto y generar una violación de información. Si bien el uso de tecnologías SSO puede mejorar la seguridad al eliminar nombres de usuario y contraseñas separados en favor de un conjunto de credenciales, los desarrolladores aún tienen que incluir código en sus aplicaciones para interactuar con el sistema SSO.

Hay una mejor manera: delegar la autenticación y la autorización a un controlador de Ingress.

Debido a que el controlador de ingreso ya está examinando todo el tráfico que ingresa al clúster y lo enruta a los servicios adecuados, es una opción eficiente para la autenticación y autorización centralizadas. Esto elimina la carga de los desarrolladores de crear, mantener y replicar la lógica en el código de la aplicação ; en cambio, pueden aprovechar rápidamente las tecnologías SSO en la capa de ingreso utilizando la API nativa de Kubernetes.

Para obtener más información sobre este tema, lea Implementación de la autenticación OpenID Connect para Kubernetes con Okta y el controlador de ingreso NGINX .

CASO DE USO:Configurar el autoservicio con barandillas

Solución: Implementar el control de acceso basado en roles (RBAC)

Kubernetes utiliza RBAC para controlar los recursos y las operaciones disponibles para diferentes tipos de usuarios. Esta es una medida de seguridad valiosa ya que permite a un administrador o superusuario determinar cómo los usuarios o grupos de usuarios pueden interactuar con cualquier objeto de Kubernetes o espacio de nombres específico en el clúster.

Si bien Kubernetes RBAC está habilitado de forma predeterminada, debe asegurarse de que sus herramientas de administración de tráfico de Kubernetes también estén habilitadas para RBAC y puedan alinearse con las necesidades de seguridad de su organización. Con RBAC implementado, los usuarios obtienen acceso restringido a la funcionalidad que necesitan para hacer su trabajo sin tener que esperar a que se complete un ticket. Pero sin RBAC configurado, los usuarios pueden obtener permisos que no necesitan o a los que no tienen derecho, lo que puede generar vulnerabilidades si los permisos se usan incorrectamente.

Un controlador de Ingress es un excelente ejemplo de una herramienta que puede servir a numerosas personas y equipos cuando se configura con RBAC. Cuando el controlador de Ingress permite una gestión de acceso detallada, incluso a un único espacio de nombres, se puede usar RBAC para optimizar el uso de recursos mediante la multi-inquilino.

A modo de ejemplo, varios equipos podrían utilizar el controlador Ingress de la siguiente manera:

• Equipo de NetOps : configura el punto de entrada externo de la aplicação (como el nombre de host y los certificados TLS) y delega políticas de control de tráfico a varios equipos.
• Equipo A de DevOps : Aprovisiona políticas de enrutamiento y equilibrio de carga TCP/UDP
• Equipo B de DevOps : configura políticas de limitación de velocidad para proteger los servicios de solicitudes excesivas
• Equipo de identidad : administra los componentes de autenticación y autorización mientras configura políticas mTLS como parte de una estrategia de cifrado de extremo a extremo.
• Equipo de DevSecOps : establece políticas de WAF

Para aprender cómo aprovechar RBAC en NGINX Ingress Controller, mire Implementaciones avanzadas de Kubernetes con NGINX Ingress Controller . A partir del minuto 13:50, nuestros expertos explican cómo aprovechar RBAC y la asignación de recursos para la seguridad, el autoservicio y la multitenencia.

CASO DE USO:Implementar el cifrado de extremo a extremo

Solución: Utilice herramientas de gestión del tráfico

El cifrado de extremo a extremo (E2EE) se está convirtiendo en un requisito cada vez más común para las organizaciones que manejan información confidencial o personal. Ya sea que se trate de datos financieros o mensajes en las redes sociales, las expectativas de privacidad del consumidor combinadas con regulaciones como GDPR y HIPAA están impulsando la demanda de este tipo de protección. El primer paso para lograr E2EE es diseñar sus aplicaciones backend para que acepten tráfico SSL/TLS o utilizar una herramienta que descargue la administración de SSL/TLS de sus aplicaciones (la opción preferida para separar la función de seguridad, el rendimiento, la administración de claves, etc.). Luego, configura tus herramientas de gestión de tráfico dependiendo de la complejidad de tu entorno.

Escenario más común: E2EE usando un controlador de entrada

Cuando tienes aplicaciones con un solo punto final (aplicaciones simples o aplicaciones monolíticas que has "elevado y trasladado" a Kubernetes) o no hay comunicación de servicio a servicio , puedes usar un controlador de Ingress para implementar E2EE dentro de Kubernetes.

Paso 1: Asegúrese de que su controlador de ingreso solo permita conexiones SSL/TLS encriptadas usando certificados mTLS o del lado del servicio, idealmente tanto para el tráfico de ingreso como de egreso.

Paso 2: Abordar la configuración predeterminada típica que requiere que el controlador de Ingress descifre y vuelva a cifrar el tráfico antes de enviarlo a las aplicaciones. Esto se puede lograr de un par de maneras: el método que elija dependerá de su controlador Ingress y sus requisitos:

• Si su controlador de Ingress admite el paso a través de SSL/TLS, puede enrutar conexiones cifradas con SSL/TLS según el encabezado de indicación de nombre de servicio (SNI), sin descifrarlas ni requerir acceso a los certificados o claves SSL/TLS.
• Como alternativa, puede configurar la terminación SSL/TLS, donde el controlador de Ingress finaliza el tráfico y luego lo envía a los backends o upstreams, ya sea en texto sin formato o volviendo a cifrar el tráfico con mTLS o SSL/TLS del lado del servicio a sus servicios de Kubernetes.

Escenario menos común: E2EE usando un controlador de ingreso y una malla de servicio

Si hay comunicación de servicio a servicio dentro de su clúster, debe implementar E2EE en dos planos: tráfico de ingreso y egreso con el controlador de ingreso y tráfico de servicio a servicio con una malla de servicios . En E2EE, la función de una malla de servicios es garantizar que solo servicios específicos puedan comunicarse entre sí y que lo hagan de manera segura. Al configurar una malla de servicios para E2EE, debe habilitar un entorno de confianza cero a través de dos factores: mTLS entre servicios (configurado para requerir un certificado) y control de acceso al tráfico entre servicios (que dicta qué servicios están autorizados a comunicarse). Lo ideal es que también implemente mTLS entre las aplicações (administradas por una malla de servicios y el controlador de ingreso y egreso) para lograr una verdadera seguridad E2EE en todo el clúster de Kubernetes.

Para obtener más información sobre el cifrado de datos que han sido expuestos en la red, lea La arquitectura mTLS en NGINX Service Mesh .

CASO DE USO:Asegúrese de que los clientes utilicen un cifrado sólido con una implementación confiable

Solución: Cumplir con los Estándares Federales de Procesamiento de Información (FIPS)

En la industria del software, FIPS generalmente se refiere a la publicación específicamente sobre criptografía, FIPS PUB 140-2 Requisitos de seguridad para módulos criptográficos, que es un esfuerzo conjunto entre Estados Unidos y Canadá. Estandariza las pruebas y certificación de módulos criptográficos que son aceptados por las agencias federales de ambos países para la protección de información sensible. “¡Pero espera!” dices. “No me importa el FIPS porque no trabajo con entidades gubernamentales de América del Norte”. Convertirse en compatible con FIPS puede ser una decisión inteligente independientemente de su industria o geografía, porque FIPS también es la base criptográfica global de facto.

Cumplir con FIPS no tiene por qué ser difícil, pero sí requiere que tanto el sistema operativo como las herramientas de gestión de tráfico pertinentes puedan funcionar en modo FIPS. Existe la idea errónea de que la conformidad con FIPS se logra simplemente ejecutando el sistema operativo en modo FIPS. Incluso con el sistema operativo en modo FIPS, aún es posible que los clientes que se comunican con su controlador Ingress no utilicen un cifrado sólido. Al operar en modo FIPS, su sistema operativo y el controlador de Ingress pueden usar solo un subconjunto de los cifrados SSL/TLS típicos.

La configuración de FIPS para sus implementaciones de Kubernetes es un proceso de cuatro pasos:

• Paso 1: Configure su sistema operativo para el modo FIPS
• Paso 2: Verifique que el sistema operativo y OpenSSL estén en modo FIPS
• Paso 3: Instalar el controlador Ingress
• Paso 4: Verifique el cumplimiento de FIPS 140-2 realizando una verificación del estado de FIPS

En el siguiente ejemplo, cuando el modo FIPS está habilitado tanto para el sistema operativo como para la implementación de OpenSSL utilizada por NGINX Plus, todo el tráfico del usuario final hacia y desde NGINX Plus se descifra y cifra utilizando un motor de cifrado validado y habilitado para FIPS.

Lea más sobre FIPS en Cómo lograr la conformidad con FIPS con NGINX Plus .

Haga que Kubernetes sea más seguro con NGINX

Si está listo para implementar algunos (o todos) de estos métodos de seguridad, debe asegurarse de que sus herramientas tengan las características y capacidades adecuadas para respaldar sus casos de uso. NGINX puede ayudar con nuestro conjunto de herramientas de gestión de tráfico de Kubernetes listas para producción:

• Controlador de ingreso NGINX : controlador de ingreso basado en NGINX Plus para Kubernetes que maneja control y modelado de tráfico avanzado, monitoreo y visibilidad, autenticación y SSO, y actúa como puerta de enlace API.

• F5 NGINX App Protect : protección integral para aplicaciones y API modernas, basada en las tecnologías de seguridad líderes en el mercado de F5, que se integra con NGINX Ingress Controller y NGINX Plus. Utilice un enfoque modular para lograr flexibilidad en los escenarios de implementación y una utilización óptima de los recursos:

  • NGINX App Protect WAF : un WAF ligero y resistente que protege contra OWASP Top 10 y más allá con cumplimiento PCI DDS.

  • NGINX App Protect DoS : detección y mitigación de DoS conductual con protección consistente y adaptativa en diferentes nubes y arquitecturas.

• Malla de servicio F5 NGINX : malla de servicio liviana, llave en mano y fácil de usar para desarrolladores que incluye NGINX Plus como complemento empresarial.

Comience solicitando su prueba gratuita de 30 días de NGINX Ingress Controller con NGINX App Protect WAF y DoS, y descargue NGINX Service Mesh siempre gratuito.