Desplazamiento de la seguridad hacia la izquierda con F5 NGINX App Protect en Amazon EKS

Según el informe The State of Aplicação Strategy in 2022 de F5, la transformación digital en la empresa continúa acelerándose a nivel mundial. La mayoría de las empresas implementan entre 200 y 1000 aplicaciones distribuidas en múltiples zonas de nube, y las aplicaciones actuales están pasando de arquitecturas monolíticas a arquitecturas distribuidas modernas.

Kubernetes llegó por primera vez a la escena tecnológica para su uso generalizado en 2016, hace apenas seis años. Sin embargo, hoy en día más del 75% de las organizaciones en todo el mundo ejecutan aplicações en contenedores en producción, un 30% más que en 2019. Un problema crítico en los entornos de Kubernetes, incluido Amazon Elastic Kubernetes Service (EKS), es la seguridad. Con demasiada frecuencia, la seguridad se “agrega” al final del proceso de desarrollo de la aplicación y, a veces, ni siquiera hasta que la aplicacion contenerizada ya está en funcionamiento.

La ola actual de transformación digital, acelerada por la pandemia de COVID-19, ha obligado a muchas empresas a adoptar un enfoque más holístico en materia de seguridad y considerar una estrategia de “desplazamiento a la izquierda”. Desplazar la seguridad hacia la izquierda significa introducir medidas de seguridad en las primeras etapas del ciclo de vida del desarrollo de software (SDLC) y utilizar herramientas y controles de seguridad en cada etapa del proceso de CI/CD para aplicações, contenedores, microservicios y API. Representa un paso hacia un nuevo paradigma llamado DevSecOps, donde la seguridad se agrega a los procesos de DevOps y se integra en los ciclos de lanzamiento rápido típicos del desarrollo y la entrega de aplicaciones de software modernas.

DevSecOps representa un cambio cultural significativo. Los equipos de seguridad y DevOps trabajan con un propósito común: llevar productos de alta calidad al mercado de forma rápida y segura. Los desarrolladores ya no se sienten obstaculizados a cada paso por los procedimientos de seguridad que detienen su flujo de trabajo. Los equipos de seguridad ya no tienen que solucionar los mismos problemas una y otra vez. Esto permite que la organización mantenga una postura de seguridad sólida, detectando y previniendo vulnerabilidades, configuraciones incorrectas y violaciones de cumplimiento o políticas a medida que ocurren.

Desplazar la seguridad a la izquierda y automatizar la seguridad como código protege su entorno de Amazon EKS desde el principio. Aprender cómo estar listo para la producción a gran escala es una parte importante de la construcción de una base de Kubernetes. Una gobernanza adecuada de Amazon EKS ayuda a impulsar la eficiencia, la transparencia y la responsabilidad en toda la empresa y, al mismo tiempo, a controlar los costos. Una gobernanza sólida y barreras de seguridad crean un marco para una mejor visibilidad y control de sus clústeres. Sin ellos, su organización está expuesta a un mayor riesgo de violaciones de seguridad y a los consiguientes costos a largo plazo asociados con daños a los ingresos y la reputación.

Para obtener más información sobre lo que se debe tener en cuenta al adoptar una estrategia que priorice la seguridad, consulte este informe reciente de O'Reilly, Shifting Left for Aplicação Security .

Automatización de la seguridad para Amazon EKS con GitOps

La automatización es un facilitador importante para DevSecOps, ya que ayuda a mantener la coherencia incluso a un ritmo rápido de desarrollo e implementación. Al igual que la infraestructura como código, la automatización con un enfoque de seguridad como código implica el uso de políticas declarativas para mantener el estado de seguridad deseado.

GitOps es un marco operativo que facilita la automatización para respaldar y simplificar la entrega de aplicação y la gestión de clústeres. La idea principal de GitOps es tener un repositorio Git que almacene políticas declarativas de objetos de Kubernetes y las aplicações que se ejecutan en Kubernetes, definidas como código. Un proceso automatizado completa el paradigma GitOps para hacer que el entorno de producción coincida con todas las descripciones de estados almacenados.

El repositorio actúa como una fuente de verdad en forma de políticas de seguridad, a las que luego se hace referencia mediante descripciones declarativas de configuración como código como parte del proceso de canalización de CI/CD. A modo de ejemplo, NGINX mantiene un repositorio de GitHub con un rol Ansible para F5 NGINX App Protect que esperamos sea útil para ayudar a los equipos que desean trasladar la seguridad a la izquierda.

Con un repositorio de este tipo, todo lo que se necesita para implementar una nueva aplicação o actualizar una existente es actualizar el repositorio. El proceso automatizado gestiona todo lo demás, incluida la aplicación de configuraciones y asegurarse de que las actualizaciones se realicen correctamente. Esto garantiza que todo suceda en el sistema de control de versiones para los desarrolladores y esté sincronizado para reforzar la seguridad en las aplicações críticas para el negocio.

Cuando se ejecuta en Amazon EKS, GitOps hace que la seguridad sea perfecta y sólida, al tiempo que elimina virtualmente los errores humanos y realiza un seguimiento de todos los cambios de versiones que se aplican a lo largo del tiempo.

NGINX App Protect y NGINX Ingress Controller protegen sus aplicaciones y API en Amazon EKS

Un diseño sólido para la política de seguridad de Kubernetes debe satisfacer las necesidades tanto de SecOps como de DevOps e incluir disposiciones para adaptarse a medida que el entorno escala. Los clústeres de Kubernetes se pueden compartir de muchas maneras. Por ejemplo, un clúster puede tener múltiples aplicações ejecutándose en él y compartiendo sus recursos, mientras que en otro caso hay múltiples instancias de una aplicação, cada una para un usuario final o grupo diferente. Esto implica que los límites de seguridad no siempre están claramente definidos y que se necesitan políticas de seguridad flexibles y detalladas.

El diseño de seguridad general debe ser lo suficientemente flexible para acomodar excepciones, debe integrarse fácilmente en el flujo de trabajo de CI/CD y debe soportar múltiples inquilinos. En el contexto de Kubernetes, un inquilino es una agrupación lógica de objetos y aplicações de Kubernetes que están asociados con una unidad de negocio, un equipo, un caso de uso o un entorno específico. Por lo tanto, la multitenencia significa que varios inquilinos comparten de forma segura el mismo clúster y que los límites entre ellos se aplican en función de requisitos técnicos de seguridad que están estrechamente vinculados a las necesidades del negocio.

Una forma sencilla de implementar seguridad de alto rendimiento y baja latencia en Amazon EKS es integrar los módulos NGINX App Protect WAF y DoS con NGINX Ingress Controller . Ninguno de nuestros otros competidores ofrece este tipo de solución en línea. El uso de un producto con tecnología sincronizada proporciona varias ventajas, entre ellas una reducción del tiempo de cálculo, de los costos y de la proliferación de herramientas. A continuación se muestran algunos beneficios adicionales.

• Protección del perímetro de la aplicação : en una implementación de Kubernetes bien diseñada, NGINX Ingress Controller es el único punto de entrada para el tráfico del plano de datos que fluye hacia los servicios que se ejecutan dentro de Kubernetes, lo que lo convierte en una ubicación ideal para un WAF y protección DoS.
• Consolidación del plano de datos : la integración del WAF en NGINX Ingress Controller elimina la necesidad de un dispositivo WAF separado. Esto reduce la complejidad, el costo y la cantidad de puntos de falla.
• Consolidación del plano de control : la configuración de WAF y DoS se puede gestionar con la API de Kubernetes, lo que hace que sea significativamente más fácil automatizar los procesos de CI/CD. La configuración del controlador de ingreso NGINX cumple con las prácticas de control de acceso basado en roles (RBAC) de Kubernetes, por lo que puede delegar de forma segura las configuraciones de WAF y DoS a un equipo de DevSecOps dedicado.

Los objetos de configuración para NGINX App Protect WAF y DoS son consistentes tanto en NGINX Ingress Controller como en NGINX Plus . Una configuración maestra se puede traducir e implementar fácilmente en cualquier dispositivo, lo que hace que sea aún más fácil administrar la configuración de WAF como código e implementarla en cualquier entorno de aplicação.

Para integrar NGINX App Protect WAF y DoS en NGINX Ingress Controller, debe tener suscripciones tanto para NGINX Plus como para NGINX App Protect WAF o DoS. Bastan unos pocos pasos sencillos para crear la imagen del controlador de ingreso NGINX integrado (contenedor Docker). Después de implementar la imagen ( manualmente o con gráficos de Helm , por ejemplo), puede administrar las políticas de seguridad y la configuración utilizando la API familiar de Kubernetes.

El controlador de ingreso NGINX basado en NGINX Plus proporciona control granular de la autenticación, autorización basada en RBAC e interacciones externas con pods. Cuando el cliente usa HTTPS, el controlador de ingreso NGINX puede finalizar TLS y descifrar el tráfico para aplicar el enrutamiento de capa 7 y reforzar la seguridad.

Luego, NGINX App Protect WAF y NGINX App Protect DoS se pueden implementar para aplicar políticas de seguridad para proteger contra ataques puntuales en la capa 7 como una solución de seguridad de software liviana. NGINX App Protect WAF protege las aplicaciones de Kubernetes contra los 10 principales ataques de OWASP, y brinda firmas avanzadas y protección contra amenazas, defensa contra bots y protección Dataguard contra la explotación de información de identificación personal (PII). NGINX App Protect DoS proporciona una línea de defensa adicional en las capas 4 y 7 para mitigar ataques DoS sofisticados en la capa de aplicação con análisis del comportamiento del usuario y controles del estado de la aplicación para proteger contra ataques que incluyen Slow POST , Slowloris, ataques de inundación y Challenger Collapsar.

Estas medidas de seguridad protegen tanto las API REST como las aplicações a las que se accede mediante navegadores web. La seguridad de la API también se aplica en el nivel de ingreso siguiendo el flujo de tráfico de norte a sur.

El controlador de ingreso NGINX con NGINX App Protect WAF y DoS puede proteger el tráfico de Amazon EKS por solicitud en lugar de por servicio: esta es una vista más útil del tráfico de capa 7 y una forma mucho mejor de aplicar los SLA y la seguridad WAF de norte a sur.

El último informe de pruebas de firewall de aplicação web de alto rendimiento de GigaOm muestra cómo NGINX App Protect WAF brinda constantemente una sólida seguridad de aplicaciones y API al tiempo que mantiene un alto rendimiento y una baja latencia, superando a los otros tres WAF probados (AWS WAF, Azure WAF y Cloudflare WAF) en todas las tasas de ataque probadas.

A modo de ejemplo, la Figura 4 muestra los resultados de una prueba en la que el WAF tuvo que gestionar 500 solicitudes por segundo (RPS), con un 95 % (475 RPS) de solicitudes válidas y un 5 % de solicitudes (25 RPS) “malas” (simulando una inyección de script). En el percentil 99, la latencia de NGINX App Protect WAF fue 10 veces menor que la de AWS WAF, 60 veces menor que la de Cloudflare WAF y 120 veces menor que la de Azure WAF.

La figura 5 muestra el rendimiento más alto que cada WAF logró con un éxito del 100 % (sin 5xx o429 errores) con una latencia de menos de 30 milisegundos para cada solicitud. NGINX App Protect WAF manejó 19 000 RPS contra Cloudflare WAF con 14 000 RPS, AWS WAF con 6000 RPS y Azure WAF con solo 2000 RPS.

Cómo implementar NGINX App Protect y NGINX Ingress Controller en Amazon EKS

NGINX App Protect WAF y DoS aprovechan un enfoque de seguridad centrado en las aplicaciones con configuraciones y políticas de seguridad totalmente declarativas, lo que facilita la integración de la seguridad en su canalización de CI/CD para el ciclo de vida de las aplicaciones en Amazon EKS.

NGINX Ingress Controller proporciona varias definiciones de recursos personalizadas (CRD) para administrar cada aspecto de la seguridad de las aplicação web y respaldar un modelo de responsabilidad compartida y de múltiples inquilinos. Los manifiestos CRD se pueden aplicar siguiendo la agrupación de espacios de nombres utilizada por la organización, para admitir la propiedad de más de un grupo de operaciones.

Al publicar una aplicação en Amazon EKS, puede incorporar seguridad aprovechando el flujo de automatización que ya está en uso y superponiendo la política de seguridad de WAF.

Además, con NGINX App Protect en NGINX Ingress Controller, puede configurar umbrales de uso de recursos tanto para la CPU como para la memoria, para evitar que NGINX App Protect deje sin recursos a otros procesos. Esto es particularmente importante en entornos de múltiples inquilinos como Kubernetes, que dependen del uso compartido de recursos y potencialmente pueden sufrir el problema del "vecino ruidoso".

Configuración del registro con CRD de NGINX

Los registros de NGINX App Protect y NGINX Ingress Controller están separados por diseño, para reflejar cómo los equipos de seguridad suelen operar independientemente de DevOps y los propietarios de las aplicação . Puede enviar registros de NGINX App Protect a cualquier destino de syslog al que se pueda acceder desde los pods de Kubernetes, configurando el parámetro en la anotación app-protect-security-log-destination en la dirección IP del clúster del pod de syslog. Además, puede utilizar el recurso APLogConf para especificar qué registros de NGINX App Protect le interesan y, por implicación, qué registros se envían al pod syslog. Los registros del controlador de ingreso NGINX se envían a la salida estándar local, como para todos los contenedores de Kubernetes.

Este recurso APLogConf de muestra especifica que se registran todas las solicitudes (no solo las maliciosas) y establece los tamaños máximos de mensajes y solicitudes que se pueden registrar.

apiVersion: appprotect.f5.com/v1beta1 tipo: APLogConf
Metadatos:
Nombre: logconf
Espacio de nombres: dvwa
Especificación:
Contenido:
Formato: predeterminado
Tamaño máximo del mensaje: 64k
Tamaño máximo de solicitud: cualquiera
Filtro:
Tipo de solicitud: todos

Definición de una política WAF con CRD de NGINX

El objeto de política APPolicy es un CRD que define una política de seguridad WAF con conjuntos de firmas y reglas de seguridad basadas en un enfoque declarativo. Este enfoque se aplica tanto a NGINX App Protect WAF como a DoS, mientras que el siguiente ejemplo se centra en WAF. Las definiciones de políticas generalmente se almacenan en la fuente de verdad de la organización como parte del catálogo de SecOps.

apiVersion: appprotect.f5.com/v1beta1 tipo: Política de aplicación
Metadatos:
Nombre: política de ejemplo
Especificación:
Política:
Nombre: política de ejemplo
Plantilla:
Nombre: POLICY_TEMPLATE_NGINX_BASE
Lenguaje de la aplicación: utf-8
Modo de aplicación: bloqueo
Conjuntos de firmas:
- nombre: Firmas de ejecución de comandos
Alarma: verdadera
Bloque: verdadera
[...]

Una vez aplicado el manifiesto de política de seguridad en el clúster de Amazon EKS, cree un objeto APLogConf llamado log-violations para definir el tipo y formato de las entradas escritas en el registro cuando una solicitud infringe una política de WAF:

apiVersion: appprotect.f5.com/v1beta1 tipo: APLogConf
Metadatos:
Nombre: infracciones de registro
Especificación:
Contenido:
Formato: predeterminado
Tamaño máximo del mensaje: 64k
Tamaño máximo de solicitud: cualquiera
Filtro:
Tipo de solicitud: ilegal

Luego, el objeto de política waf-policy hace referencia a sample-policy para que NGINX App Protect WAF la aplique en el tráfico entrante cuando la aplicação se expone mediante NGINX Ingress Controller. Hace referencia a las violaciones de registro para definir el formato de las entradas de registro enviadas al servidor syslog especificado en el campo logDest .

apiVersion: k8s.nginx.org/v1 tipo: Política
Metadatos:
Nombre: waf-policy
Especificación:
waf:
Habilitar: verdadero
ApPolicy: "default/sample-policy"
SecurityLog:
Habilitar: verdadero
ApLogConf: "default/log-violations"
LogDest: "syslog:server=10.105.238.128:5144"

La implementación se completa cuando DevOps publica un objeto VirtualServer que configura NGINX Ingress Controller para exponer la aplicação en Amazon EKS:

Versión de API: k8s.nginx.org/v1kind: Servidor virtual
Metadatos:
Nombre: eshop-vs
Especificaciones:
Host: eshop.lab.local
Políticas:
Nombre: default/waf-policy
Upstreams:
Nombre: eshop-upstream
Servicio: eshop-service
Puerto: 80
Rutas:
- Ruta: /
Acción:
Contraseña: eshop-upstream

El objeto VirtualServer facilita la publicación y protección de aplicaciones en contenedores que se ejecutan en Amazon EKS y al mismo tiempo mantiene el modelo de responsabilidad compartida, donde SecOps proporciona un catálogo integral de políticas de seguridad y DevOps confía en él para trasladar la seguridad a la izquierda desde el primer día. Esto permite a las organizaciones realizar la transición a una estrategia DevSecOps.

CONCLUSIÓN

Para las empresas que tienen aplicaciones heredadas y soluciones de seguridad desarrolladas a lo largo de los años, trasladar la seguridad a Amazon EKS probablemente sea un proceso gradual. Pero redefinir la seguridad como un código administrado y mantenido por el equipo de seguridad y consumido por DevOps ayuda a entregar servicios más rápido y prepararlos para producción.

Para proteger el tráfico norte-sur en Amazon EKS, puede aprovechar NGINX Ingress Controller integrado con NGINX App Protect WAF para protegerse contra ataques puntuales en la capa 7 y NGINX App Protect DoS para mitigar DoS en las capas 4 y 7 .

Para probar NGINX Ingress Controller con NGINX App Protect WAF, comience una prueba gratuita de 30 días en AWS Marketplace o contáctenos para analizar sus casos de uso .

Para descubrir cómo puede prevenir violaciones de seguridad y proteger sus aplicaciones de Kubernetes a escala utilizando NGINX Ingress Controller y NGINX App Protect WAF y DoS en Amazon EKS, descargue nuestro libro electrónico, Agregue seguridad a su Amazon EKS con F5 NGINX .

Para obtener más información sobre cómo NGINX App Protect WAF supera a los WAF nativos para AWS, Azure y Cloudflare, descargue el informe de pruebas de firewall de aplicação web de alto rendimiento de GigaOm y regístrese para el seminario web el 6 de diciembre, donde el analista de GigaOm, Jake Dolezal, analiza los resultados.