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

Jenn GileResponsable de Marketing de Producto, NGINX

Editor – Esta publicación forma parte de una serie de 10 entregas:

1. Reduzca la complejidad con Kubernetes preparado para producción
2. Cómo mejorar la resiliencia en Kubernetes con una gestión avanzada del tráfico
3. Cómo mejorar la visibilidad en Kubernetes
4. Seis formas de proteger Kubernetes mediante herramientas de gestión del tráfico (esta publicación)
5. Guía para elegir un controlador de Ingress, parte 1: Identifique sus requisitos
6. Guía para elegir un controlador de Ingress, parte 2: riesgos y preparación para el futuro
7. Guía para elegir un controlador de Ingress, parte 3: código abierto frente a opción predeterminada frente a solución comercial
8. Guía para elegir un controlador de Ingress, parte 4: opciones del controlador de Ingress de NGINX
9. Cómo elegir una malla de servicios
10. Pruebas de rendimiento de los controladores de Ingress NGINX en un entorno dinámico de Kubernetes en la nube

También puedes descargar la colección completa de artículos del blog como libro electrónico gratuito : «Cómo llevar Kubernetes de las pruebas a producción».

Como se explica en «Proteja las 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 de nivel empresarial poco uniformes
2. Los costes de entrega de aplicaciones nativas de la nube pueden ser elevados e impredecibles
3. Los equipos de SecOps tienen dificultades para proteger las aplicaciones nativas de la nube y están en conflicto con los equipos de DevOps

Aunque los tres factores pueden afectar por igual a la seguridad, el tercero puede ser el problema más difícil de resolver, quizá porque es el más «humano». Cuando el equipo de SecOps no puede proteger las aplicaciones nativas de la nube o no cuenta con los medios necesarios para hacerlo, algunas de las consecuencias son evidentes (vulnerabilidades y brechas de seguridad), pero otras permanecen ocultas, como la pérdida de agilidad y el estancamiento de la transformación digital.

Analicemos más a fondo esos costes ocultos. Las organizaciones eligen Kubernetes por su promesa de agilidad y ahorro de costes. Sin embargo, cuando se producen incidentes de seguridad en un entorno de Kubernetes, la mayoría de las organizaciones retiran de producción sus implementaciones de Kubernetes. Esto ralentiza las iniciativas de transformación digital que son esenciales para el futuro de la organización, por no hablar del esfuerzo de ingeniería y el dinero desperdiciados. La conclusión lógica es que, si se pretende llevar Kubernetes del entorno de pruebas al de producción, la seguridad debe considerarse un componente estratégico cuya responsabilidad recaiga en toda la organización.

En este artículo, abordamos seis casos de uso de seguridad que puede resolver con herramientas de gestión del tráfico de Kubernetes, lo que permite a los equipos de SecOps colaborar con los de 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 seguras las aplicaciones y las API, al tiempo que se minimiza el impacto en los clientes.

1. Resuelva rápidamente las CVE para evitar ciberataques
2. Detenga las 10 principales amenazas de OWASP y los ataques de denegación de servicio
3. Externaliza la autenticación y la autorización de las aplicaciones
4. Configura el autoservicio con medidas de protección
5. Implementa el cifrado de extremo a extremo
6. Asegúrate de que los clientes utilicen un cifrado robusto con una implementación de confianza

Terminología de seguridad e identidad

Antes de entrar en los casos de uso, veamos brevemente algunos términos relacionados con la seguridad y la identidad que aparecerán a lo largo de este artículo.

• Autenticación y autorización – Funciones necesarias para garantizar que solo los usuarios y servicios «adecuados» puedan acceder a los backends o a los componentes de la aplicación:
  • Autenticación – Verificación de la identidad para garantizar que los clientes que realizan solicitudes sean quienes dicen ser. Se lleva a cabo mediante tokens de identidad, como contraseñas o tokens web JSON (JWT).
  • Autorización – Verificación del permiso para acceder a un recurso o una función. Se lleva a cabo mediante tokens de acceso, como atributos de la capa 7, por ejemplo, cookies de sesión, identificadores de sesión, identificadores de grupo o contenido de tokens.
• Vulnerabilidades y exposiciones críticas (CVE) – Una base de datos de fallos divulgados públicamente «en un componente de software, firmware, hardware o servicio, derivados de una debilidad que puede explotarse y causar un impacto negativo en la confidencialidad, integridad o disponibilidad de uno o varios componentes afectados» (https://www.cve.org/). Las CVE pueden ser descubiertas por los desarrolladores que gestionan la herramienta, un evaluador de penetración, un usuario o cliente, o alguien de la comunidad (como un «cazador de errores»). Es habitual dar al propietario del software tiempo para desarrollar un parche antes de divulgar públicamente la vulnerabilidad, a fin de no dar ventaja a los actores maliciosos.
• 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 provocar su caída. Dado que los ataques DoS afectan a la disponibilidad, su principal consecuencia es el daño a la reputación del objetivo. Un ataque distribuido de denegación de servicio (DDoS), en el que múltiples fuentes atacan la misma red o servicio, es más difícil de contrarrestar debido al tamaño potencialmente grande de la red de atacantes. La protección contra ataques DoS requiere una herramienta que identifique y evite los ataques de forma adaptativa. Más información en ¿Qué es un ataque distribuido de denegación de servicio (DDoS)?
• Cifrado de extremo a extremo (E2EE) – La práctica de cifrar completamente los datos durante su transmisión del usuario a la aplicación y viceversa. El E2EE requiere certificados SSL y, posiblemente, mTLS.
• TLS mutuo (mTLS) – La práctica de exigir autenticación (mediante un certificado SSL/TLS) tanto para el cliente como para el host. El uso de mTLS también protege la confidencialidad y la integridad de los datos que se transmiten entre el cliente y el host. mTLS puede implementarse incluso en el nivel de pod de Kubernetes, entre dos servicios del mismo clúster. Para consultar 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 de SSO (incluidos SAML, OAuth y OIDC) facilitan la gestión de la autenticación y la autorización.
  • Autenticación simplificada – El SSO elimina la necesidad de que un usuario tenga un token de ID único para cada recurso o función.
  • Autorización estandarizada – El SSO facilita la asignación de derechos de acceso a los usuarios en función de su rol, departamento y nivel de antigüedad, lo que elimina la necesidad de configurar los permisos de cada usuario individualmente.
• SSL (capa de sockets seguros)/TLS (seguridad de la capa de transporte) – Protocolo para establecer conexiones autenticadas y cifradas entre ordenadores conectados 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 sustituido por el protocolo TLS, sigue siendo habitual referirse a estas tecnologías relacionadas como «SSL» o «SSL/TLS»; por coherencia, utilizaremos SSL/TLS en el resto de este artículo.
• Firewall de aplicaciones web (WAF) – Un proxy inverso que detecta y bloquea ataques sofisticados contra aplicaciones y API (incluidos los 10 principales riesgos de OWASP y otras amenazas avanzadas), al tiempo que permite el paso del tráfico «seguro». Los WAF protegen frente a ataques que intentan dañar el objetivo mediante el robo de datos confidenciales o el secuestro del sistema. Algunos proveedores integran la protección WAF y contra ataques DoS en una misma herramienta, mientras que otros ofrecen herramientas independientes para WAF y DoS.
• Confianza cero – Un concepto de seguridad que se utiliza con frecuencia en organizaciones con mayores requisitos de seguridad, pero que resulta pertinente para todos, según el cual los datos deben protegerse en todas las fases de almacenamiento y transmisión. Esto significa que la organización ha decidido no «confiar» de forma predeterminada en ningún usuario ni dispositivo, sino exigir que todo el tráfico se someta a una verificación exhaustiva. Una arquitectura de confianza cero suele incluir una combinación de autenticación, autorización y mTLS, y es muy probable que la organización implemente E2EE.

Caso de uso: resuelva rápidamente las CVE para evitar ciberataques

Solución: Utilice herramientas que envíen notificaciones de parches oportunas y proactivas

Según un estudio del Instituto Ponemon, en 2019 hubo un «periodo de gracia» medio de 43 días entre la publicación de un parche para una vulnerabilidad crítica o de alta prioridad y la detección por parte de las organizaciones de ataques que intentaban aprovecharla. En F5 NGINX, hemos observado que ese plazo se ha reducido considerablemente en los años posteriores (incluso hasta el día cero en el caso de Apple iOS 15 en 2021), por lo que recomendamos aplicar los parches lo antes posible. Pero ¿qué ocurre si los parches para sus herramientas de gestión del tráfico no están disponibles hasta semanas, o incluso meses, después de que se anuncie una CVE?

Las herramientas desarrolladas y mantenidas por colaboradores de la comunidad (en lugar de por un equipo de ingeniería dedicado) pueden tardar semanas o meses en ponerse al día tras los anuncios de CVE, por lo que es poco probable que las organizaciones puedan aplicar los parches dentro de ese plazo de 43 días. En un caso, OpenResty tardó cuatro meses en aplicar un parche de seguridad relacionado con NGINX. Esto dejó expuestos durante al menos cuatro meses a todos los usuarios de un controlador Ingress basado en OpenResty, aunque, en la práctica, suele haber un retraso adicional hasta que los parches están disponibles para el software que depende de un proyecto de código abierto.

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

• Un equipo de ingeniería dedicado – Cuando el desarrollo de la herramienta está a cargo de un equipo de ingeniería en lugar de voluntarios de la comunidad, sabes que hay un grupo de personas dedicado a garantizar el buen funcionamiento de la herramienta y que puede dar prioridad a la publicación de un parche lo antes posible.
• Una base de código integrada – Al no haber dependencias externas (como comentamos en el caso de OpenResty), los parches pueden estar listos en tan solo un sprint ágil.

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

Caso de uso: detener los ataques del Top 10 de OWASP y de denegación de servicio (DoS)

Solución: Implemente una protección WAF y contra ataques DoS flexible y compatible con Kubernetes

La elección de la protección WAF y contra ataques DoS adecuada para las aplicaciones de Kubernetes depende de dos factores (además de las funcionalidades):

• Flexibilidad – Hay situaciones en las que es mejor implementar herramientas dentro de Kubernetes, por lo que conviene utilizar herramientas independientes de la infraestructura que puedan ejecutarse tanto dentro como fuera de Kubernetes. Utilizar la misma herramienta en todas las implementaciones permite reutilizar las políticas y reduce la curva de aprendizaje de los equipos de SecOps.
• Huella – Las mejores herramientas de Kubernetes tienen una huella reducida, 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 suelen mostrarse reacios a utilizar herramientas de seguridad porque consideran que ralentizan las aplicaciones, elegir una herramienta de alto rendimiento y huella reducida puede aumentar la probabilidad de adopción.

Aunque una herramienta que combine la protección WAF y contra ataques DoS pueda parecer más eficiente, en realidad es previsible que presente problemas tanto de uso de la CPU (debido a su mayor huella) como de flexibilidad. Te obliga a implementar conjuntamente la protección WAF y contra ataques DoS, incluso cuando no necesitas ambas. En última instancia, estos dos problemas pueden aumentar el coste total de propiedad de tus implementaciones de Kubernetes y, al mismo tiempo, generar restricciones presupuestarias para otras herramientas y servicios esenciales.

Una vez que haya elegido las herramientas de seguridad adecuadas para su organización, deberá decidir dónde implementarlas. Normalmente, los servicios de aplicaciones se pueden implementar en cuatro ubicaciones para proteger las aplicaciones de Kubernetes:

• En el punto de entrada (en un balanceador de carga externo, como F5 NGINX Plus o F5 BIG‑IP) – Adecuado para una protección global «general», ya que permite aplicar políticas globales en varios clústeres
• En el perímetro (en un controlador de Ingress como F5 NGINX Ingress Controller) – Ideal para proporcionar una protección «granular» uniforme en un único clúster
• En el servicio (en un equilibrador de carga ligero como NGINX Plus) – Puede ser un enfoque necesario cuando hay un número reducido de servicios dentro de un clúster que comparten la necesidad de aplicar políticas específicas
• En el pod (como parte de la aplicación) – Un enfoque muy personalizado que puede utilizarse cuando la política es específica de la aplicación

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

Dónde implementar un WAF

En primer lugar, analizaremos las opciones de implementación de un WAF, ya que suelen requerir una elección más meditada.

• Puerta de enlace y perímetro – Si su organización prefiere una estrategia de seguridad de «defensa en profundidad», recomendamos implementar un WAF tanto en el balanceador de carga externo como en el controlador de Ingress para lograr un equilibrio eficaz entre las protecciones globales y personalizadas.
• Puerta de entrada o perímetro – Si no se dispone de una estrategia de «defensa en profundidad», basta con una única ubicación, cuya elección dependerá de quién sea responsable de la seguridad. Si la seguridad está a cargo de un equipo de NetOps tradicional, es posible que este prefiera gestionarla en un proxy tradicional (el balanceador de carga externo). Sin embargo, los equipos de DevSecOps familiarizados con Kubernetes (y que prefieran mantener la configuración de seguridad cerca de las configuraciones de sus clústeres) pueden optar por implementar un WAF en el nivel de entrada.
• Por servicio o pod – Si sus equipos tienen requisitos específicos para sus servicios o aplicaciones, pueden implementar WAF adicionales según sus necesidades. Pero tenga en cuenta que estas ubicaciones conllevan costes más elevados. Además de aumentar el tiempo de desarrollo y el presupuesto destinado a la nube, esta opción también puede incrementar los costes operativos relacionados con la resolución de problemas, como al determinar «¿Cuál de nuestros WAF está bloqueando el tráfico de forma involuntaria?»

Dónde implementar la protección contra ataques DoS

La protección contra ataques DoS es más sencilla, ya que solo se necesita en una ubicación: en el punto de entrada o en el controlador de Ingress. Si implementa un WAF tanto en el punto de entrada como en el perímetro, le recomendamos que implemente la protección contra DoS delante del WAF del punto de entrada, ya que es el más global. De este modo, se puede filtrar el tráfico no deseado antes de que llegue al WAF, lo que permite aprovechar los recursos informáticos de forma más eficiente.

Para obtener más información sobre cada uno de estos escenarios de implementación, consulte «Implementación de servicios de aplicaciones en Kubernetes, parte 2».

Caso de uso: descargar la autenticación y la autorización de las aplicaciones

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

Un requisito no funcional habitual que se incorpora a las aplicaciones y los servicios es la autenticación y la autorización. A pequeña escala, esta práctica añade un nivel de complejidad manejable y aceptable cuando la aplicación no requiere actualizaciones frecuentes. Sin embargo, a mayor escala y con ritmos de publicación más rápidos, integrar la autenticación y la autorización en las aplicaciones resulta insostenible. Garantizar que cada aplicación mantenga los protocolos de acceso adecuados puede desviar la atención de su lógica de negocio o, lo que es peor, pasarse por alto y provocar una filtración de información. Aunque el uso de tecnologías de inicio de sesión único (SSO) puede mejorar la seguridad al sustituir los nombres de usuario y las contraseñas independientes por un único conjunto de credenciales, los desarrolladores siguen teniendo que incluir código en sus aplicaciones para interactuar con el sistema SSO.

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

Dado que el controlador Ingress ya examina todo el tráfico que entra en el clúster y lo dirige a los servicios correspondientes, es una opción eficiente para centralizar la autenticación y la autorización. De este modo, los desarrolladores no tienen que crear, mantener y replicar esta lógica en el código de la aplicación; en su lugar, pueden aprovechar rápidamente las tecnologías de inicio de sesión único (SSO) en la capa de entrada mediante la API nativa de Kubernetes.

Para obtener más información sobre este tema, consulta Implementación de la autenticación OpenID Connect para Kubernetes con Okta y NGINX Ingress Controller.

Caso de uso: Configurar el autoservicio con Guardrails

Solución: Implemente un control de acceso basado en roles (RBAC)

Kubernetes utiliza RBAC para controlar los recursos y las operaciones disponibles para los distintos tipos de usuarios. Se trata de una medida de seguridad muy útil, ya que permite a un administrador o superusuario determinar cómo pueden interactuar los usuarios, o grupos de usuarios, con cualquier objeto de Kubernetes o espacio de nombres específico del clúster.

Aunque el RBAC de Kubernetes está habilitado de forma predeterminada, debe asegurarse de que sus herramientas de gestión del tráfico de Kubernetes también sean compatibles con RBAC y puedan adaptarse a las necesidades de seguridad de su organización. Con RBAC implementado, los usuarios obtienen acceso controlado a las funciones que necesitan para realizar su trabajo sin tener que esperar a que se resuelva una solicitud. Sin embargo, si RBAC no está configurado, los usuarios pueden obtener permisos que no necesitan o que no les corresponden, lo que puede generar vulnerabilidades si se hace un uso indebido de ellos.

Un controlador de Ingress es un excelente ejemplo de una herramienta que, cuando se configura con RBAC, puede prestar servicio a numerosas personas y equipos. Cuando el controlador de Ingress permite gestionar el acceso de forma granular —incluso hasta el nivel de un único espacio de nombres—, puede utilizar RBAC para hacer un uso eficiente de los recursos mediante la tenencia múltiple.

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

• Equipo de NetOps – Configura el punto de entrada externo de la aplicación (como el nombre de host y los certificados TLS) y delega las políticas de control del tráfico en varios equipos
• Equipo de DevOps A – Aprovisiona el balanceo de carga TCP/UDP y las políticas de enrutamiento
• Equipo de DevOps B – Configura políticas de limitación de solicitudes para proteger los servicios frente a un número excesivo de solicitudes
• Equipo de identidad – Gestiona los componentes de autenticación y autorización, a la vez que configura políticas de mTLS como parte de una estrategia de cifrado de extremo a extremo
• Equipo de DevSecOps – Define las políticas del WAF

Para aprender a sacar partido del RBAC en NGINX Ingress Controller, vea Implementaciones avanzadas de Kubernetes con NGINX Ingress Controller. A partir del minuto 13:50, nuestros expertos explican cómo aprovechar el RBAC y la asignación de recursos para mejorar la seguridad, el autoservicio y la tenencia múltiple.

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 habitual para las organizaciones que gestionan información confidencial o personal. Ya se trate de datos financieros o de mensajes en redes sociales, las expectativas de los consumidores en materia de privacidad, junto con normativas como el RGPD y la HIPAA, están impulsando la demanda de este tipo de protección. El primer paso para implementar el E2EE consiste en diseñar las aplicaciones de backend para que acepten tráfico SSL/TLS o utilizar una herramienta que se encargue de la gestión de SSL/TLS en lugar de las aplicaciones (la opción preferida para separar las funciones de seguridad, mejorar el rendimiento, gestionar las claves, etc.). A continuación, se configuran las herramientas de gestión del tráfico en función de la complejidad del entorno.

Escenario más habitual: E2EE mediante un controlador de Ingress

Cuando tienes aplicaciones con un único endpoint (aplicaciones sencillas o monolíticas que has migrado a Kubernetes mediante «lift and shift») o no hay comunicación entre servicios, puedes utilizar un controlador Ingress para implementar el cifrado de extremo a extremo (E2EE) en Kubernetes.

Paso 1: Asegúrese de que su controlador de Ingress solo permita conexiones SSL/TLS cifradas mediante certificados del lado del servicio o certificados mTLS, preferiblemente tanto para el tráfico entrante como para el saliente.

Paso 2: Aborde la configuración predeterminada habitual que obliga al controlador de Ingress a descifrar y volver a cifrar el tráfico antes de enviarlo a las aplicaciones. Esto puede hacerse de dos maneras; el método que elija dependerá de su controlador de Ingress y de sus requisitos:

• Si su controlador de Ingress admite el paso directo de SSL/TLS, puede enrutar conexiones cifradas mediante SSL/TLS basándose en la cabecera de indicación del nombre del servidor (SNI), sin descifrarlas ni necesitar acceso a los certificados o las claves SSL/TLS.
• Como alternativa, puede configurar la terminación SSL/TLS, de modo que el controlador Ingress termine el tráfico y, a continuación, lo reenvíe mediante proxy a los backends o upstreams, ya sea en texto sin cifrar o volviendo a cifrar el tráfico con mTLS o SSL/TLS en el lado del servicio para sus servicios de Kubernetes.

Escenario menos habitual: E2EE mediante un controlador de Ingress y una malla de servicios

Si hay comunicación entre servicios dentro del clúster, debe implementar el cifrado de extremo a extremo (E2EE) en dos planos: el tráfico de entrada y salida mediante el controlador de Ingress y el tráfico entre servicios mediante una malla de servicios. En el E2EE, la función de una malla de servicios es garantizar que solo determinados servicios puedan comunicarse entre sí y que lo hagan de forma segura. Al configurar una malla de servicios para E2EE, debe habilitar un entorno de confianza cero mediante dos factores: mTLS entre servicios (configurado para exigir un certificado) y control de acceso al tráfico entre servicios (que determina qué servicios están autorizados a comunicarse). Lo ideal es implementar también mTLS entre las aplicaciones (gestionado por una malla de servicios y el controlador de entrada y salida) para garantizar una verdadera seguridad E2EE en todo el clúster de Kubernetes.

Para obtener más información sobre cómo cifrar los datos que han quedado expuestos durante la transmisión, consulte «La arquitectura mTLS en NGINX Service Mesh».

Caso de uso: garantizar que los clientes utilicen un cifrado robusto con una implementación de confianza

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

En el sector del software, FIPS suele hacer referencia a la publicación dedicada específicamente a la criptografía, FIPS PUB 140-2 Requisitos de seguridad para módulos criptográficos, fruto de la colaboración entre Estados Unidos y Canadá. Esta norma estandariza las pruebas y la certificación de los módulos criptográficos que aceptan las agencias federales de ambos países para proteger información confidencial. «¡Pero un momento!» dirá. «FIPS no me importa porque no trabajo con organismos gubernamentales norteamericanos». Cumplir con FIPS puede ser una decisión acertada independientemente de su sector o ubicación geográfica, ya que FIPS también es el estándar criptográfico de facto a nivel mundial.

Cumplir con FIPS no tiene por qué ser difícil, pero requiere que tanto el sistema operativo como las herramientas de gestión del tráfico pertinentes puedan funcionar en modo FIPS. Existe la idea errónea generalizada de que basta con ejecutar el sistema operativo en modo FIPS para cumplir con esta norma. Aunque el sistema operativo esté en modo FIPS, es posible que los clientes que se comunican con el controlador de Ingress no utilicen un cifrado robusto. Al funcionar en modo FIPS, el sistema operativo y el controlador de Ingress solo pueden utilizar un subconjunto de los cifrados SSL/TLS habituales.

Configurar FIPS para sus despliegues de Kubernetes es un proceso de cuatro pasos:

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

En el ejemplo siguiente, 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 de los usuarios finales hacia y desde NGINX Plus se descifra y cifra mediante un motor criptográfico validado y compatible con FIPS.

Obtenga más información sobre FIPS en «Cómo lograr el cumplimiento de FIPS con NGINX Plus».

Refuerza la seguridad de Kubernetes con NGINX

Si está listo para implementar algunos de estos métodos de seguridad (o todos), debe asegurarse de que sus herramientas cuenten con las funciones y capacidades adecuadas para sus casos de uso. NGINX puede ayudarle con nuestro conjunto de herramientas de gestión del tráfico de Kubernetes listas para entornos de producción:

• NGINX Ingress Controller – Controlador de Ingress para Kubernetes basado en NGINX Plus que ofrece funciones avanzadas de control y gestión del tráfico, monitorización y visibilidad, autenticación e inicio de sesión único (SSO), y que actúa como puerta de enlace de API.
• F5 NGINX App Protect – Protección integral para aplicaciones y API modernas, basada en las tecnologías de seguridad líderes del mercado de F5, que se integra con NGINX Ingress Controller y NGINX Plus. Utilice un enfoque modular para obtener flexibilidad en los escenarios de implementación y un uso óptimo de los recursos:
  • NGINX App Protect WAF – Un WAF sólido y ligero que protege frente a las 10 principales amenazas de OWASP y muchas más, y que cumple con PCI DDS.
  • NGINX App Protect DoS – Detección y mitigación de ataques DoS basada en el comportamiento, con una protección uniforme y adaptativa en distintas nubes y arquitecturas.
• F5 NGINX Service Mesh – Malla de servicios ligera, lista para usar y fácil de utilizar para los desarrolladores, que incorpora NGINX Plus como sidecar empresarial.

Empieza solicitando tu prueba gratuita de 30 días de NGINX Ingress Controller con NGINX App Protect WAF y DoS, y descarga NGINX Service Mesh, que es gratuito para siempre.

Sobre el autor

Jenn GileResponsable de Marketing de Producto, NGINX

Más artículos de Jenn Gile