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

Fabrizio FiorucciArquitecto de soluciones NGINX | F5 (EMEA)

Thelen BlumResponsable sénior de marketing de producto, NGINX App Protect | F5

Según el informe El estado de la estrategia de aplicaciones en 2022 de F5, la transformación digital en las empresas sigue acelerándose a escala mundial. La mayoría de las empresas implementan entre 200 y 1.000 aplicaciones distribuidas en varias zonas de nube, mientras que las aplicaciones actuales están pasando de arquitecturas monolíticas a arquitecturas distribuidas modernas.

Kubernetes irrumpió por primera vez en el panorama tecnológico para su uso generalizado en 2016, hace apenas seis años. Sin embargo, hoy en día más del 75 % de las organizaciones de todo el mundo ejecutan aplicaciones en contenedores en producción, un 30 % más que en 2019. Uno de los problemas críticos en los entornos de Kubernetes, incluido Amazon Elastic Kubernetes Service (EKS), es la seguridad. Con demasiada frecuencia, la seguridad se «añade» al final del proceso de desarrollo de la aplicación y, en ocasiones, ni siquiera se incorpora hasta que una aplicación en contenedores ya está en funcionamiento.

La actual ola de transformación digital, acelerada por la pandemia de COVID‑19, ha obligado a muchas empresas a adoptar un enfoque más integral de la seguridad y a plantearse una estrategia de «desplazamiento a la izquierda». Desplazar la seguridad a la izquierda significa introducir medidas de seguridad en las primeras fases 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 aplicaciones, contenedores, microservicios y API. Supone adoptar un nuevo paradigma denominado DevSecOps, en el que la seguridad se incorpora a los procesos de DevOps y se integra en los rápidos ciclos de lanzamiento propios 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 objetivo común: lanzar al mercado productos de alta calidad de forma rápida y segura. Los desarrolladores ya no se sienten obstaculizados constantemente por procedimientos de seguridad que interrumpen su flujo de trabajo. Los equipos de seguridad ya no tienen que solucionar los mismos problemas una y otra vez. Esto permite a la organización mantener una postura de seguridad sólida, detectando y evitando vulnerabilidades, errores de configuración e incumplimientos normativos o de las políticas a medida que se producen.

Desplazar la seguridad a las primeras fases del desarrollo y automatizarla como código protege su entorno de Amazon EKS desde el principio. Aprender a estar preparado para la producción a gran escala es una parte fundamental de la creación de una base de Kubernetes. Una gobernanza adecuada de Amazon EKS ayuda a impulsar la eficiencia, la transparencia y la rendición de cuentas en toda la empresa, al tiempo que permite controlar los costes. Una gobernanza sólida y unas medidas de protección de seguridad establecen un marco que mejora la visibilidad y el control de sus clústeres. Sin ellas, su organización queda expuesta a un mayor riesgo de brechas de seguridad y a los costes a largo plazo derivados del perjuicio para los ingresos y la reputación.

Para obtener más información sobre los aspectos que se deben tener en cuenta al adoptar una estrategia que priorice la seguridad, consulte este reciente informe de O’Reilly, «Adelantar la seguridad de las aplicaciones».

Automatización de la seguridad de Amazon EKS con GitOps

La automatización es un factor clave para DevSecOps, ya que ayuda a mantener la coherencia incluso cuando el desarrollo y el despliegue avanzan a un ritmo acelerado. Al igual que ocurre con la infraestructura como código, automatizar mediante un enfoque de seguridad como código implica utilizar políticas declarativas para mantener el estado de seguridad deseado.

GitOps es un marco operativo que facilita la automatización para agilizar y simplificar la entrega de aplicaciones y la gestión de clústeres. La idea principal de GitOps consiste en disponer de un repositorio Git que almacene, como código, las políticas declarativas de los objetos de Kubernetes y de las aplicaciones que se ejecutan en Kubernetes. Un proceso automatizado completa el paradigma de GitOps haciendo que el entorno de producción coincida con todas las descripciones de estado almacenadas.

El repositorio actúa como fuente de referencia en forma de políticas de seguridad, a las que posteriormente hacen referencia las descripciones declarativas de configuración como código como parte del proceso de la canalización de CI/CD. Por ejemplo, NGINX mantiene un repositorio de GitHub con un rol de Ansible para F5 NGINX App Protect, que esperamos que resulte útil para ayudar a los equipos que desean integrar la seguridad en las primeras fases del desarrollo.

Con un repositorio de este tipo, para implementar una nueva aplicación o actualizar una existente basta con actualizar el repositorio. El proceso automatizado se encarga de todo lo demás, incluida la aplicación de las configuraciones y la comprobación de que las actualizaciones se hayan realizado correctamente. Esto garantiza que todo se lleve a cabo en el sistema de control de versiones para los desarrolladores y se sincronice para aplicar medidas de seguridad en las aplicaciones críticas para el negocio.

Al ejecutarse en Amazon EKS, GitOps proporciona una seguridad sólida y sin complicaciones, al tiempo que elimina prácticamente los errores humanos y mantiene un registro de todos los cambios de versión aplicados 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 de las políticas de seguridad de Kubernetes debe satisfacer las necesidades tanto de SecOps como de DevOps e incluir medidas que permitan adaptarse a medida que el entorno crece. Los clústeres de Kubernetes se pueden compartir de muchas formas. Por ejemplo, un clúster puede ejecutar varias aplicaciones que compartan sus recursos, mientras que, en otro caso, puede haber varias instancias de una misma aplicación, cada una destinada a 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 granulares.

El diseño general de seguridad debe ser lo suficientemente flexible como para admitir excepciones, integrarse fácilmente en el flujo de CI/CD y ser compatible con la tenencia múltiple. En el contexto de Kubernetes, un inquilino es una agrupación lógica de objetos y aplicaciones de Kubernetes asociados a una unidad de negocio, un equipo, un caso de uso o un entorno específicos. Por tanto, la tenencia múltiple implica que varios inquilinos compartan de forma segura el mismo clúster, con límites entre ellos aplicados en función de requisitos técnicos de seguridad estrechamente vinculados a las necesidades empresariales.

Una forma sencilla de implementar una seguridad de alto rendimiento y baja latencia en Amazon EKS consiste en integrar los módulos NGINX App Protect WAF and DoS con NGINX Ingress Controller. Ninguno de nuestros competidores ofrece este tipo de solución integrada. Utilizar un único producto con tecnología sincronizada aporta varias ventajas, como la reducción del tiempo de procesamiento, los costes y la proliferación de herramientas. Estas son algunas ventajas adicionales.

• Protección del perímetro de la aplicación – 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 dirigido a los servicios que se ejecutan en Kubernetes, por lo que constituye una ubicación ideal para implementar protección mediante WAF y contra ataques DoS.
• Consolidación del plano de datos – Integrar el WAF en NGINX Ingress Controller elimina la necesidad de disponer de un dispositivo WAF independiente. Esto reduce la complejidad, el coste y el número de puntos de fallo.
• Consolidación del plano de control – La configuración del WAF y de la protección contra ataques DoS se puede gestionar mediante la API de Kubernetes, lo que facilita considerablemente la automatización de los procesos de CI/CD. La configuración de NGINX Ingress Controller cumple las prácticas de control de acceso basado en roles (RBAC) de Kubernetes, por lo que puede delegar de forma segura las configuraciones del WAF y de la protección contra ataques DoS en un equipo de DevSecOps específico.

Los objetos de configuración de NGINX App Protect WAF y DoS son coherentes tanto en NGINX Ingress Controller como en NGINX Plus. Una configuración maestra se puede convertir y desplegar fácilmente en cualquiera de los dos dispositivos, lo que facilita aún más la gestión de la configuración del WAF como código y su despliegue en cualquier entorno de aplicaciones

Para integrar NGINX App Protect WAF y DoS en NGINX Ingress Controller, debe disponer de suscripciones tanto a NGINX Plus como a NGINX App Protect WAF o DoS. Solo se necesitan unos sencillos pasos para crear la imagen de NGINX Ingress Controller (contenedor Docker). Después de implementar la imagen (manualmente o, por ejemplo, mediante gráficos de Helm), puede gestionar las políticas y la configuración de seguridad mediante la conocida API de Kubernetes.

NGINX Ingress Controller, basado en NGINX Plus, proporciona un control y una gestión pormenorizados de la autenticación, la autorización basada en RBAC y las interacciones externas con los pods. Cuando el cliente utiliza HTTPS, NGINX Ingress Controller puede finalizar TLS y descifrar el tráfico para aplicar el enrutamiento de capa 7 y reforzar la seguridad.

NGINX App Protect WAF y NGINX App Protect DoS pueden implementarse para aplicar políticas de seguridad y proteger frente a ataques específicos en la capa 7 mediante una solución de seguridad de software ligera. NGINX App Protect WAF protege las aplicaciones de Kubernetes frente a los ataques del Top 10 de OWASP y ofrece firmas avanzadas y protección contra amenazas, defensa frente a 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 sofisticados ataques DoS en la capa de aplicación mediante el análisis del comportamiento de los usuarios y comprobaciones del estado de las aplicaciones, y proteger frente a ataques como Slow POST, Slowloris, ataques de inundación y Challenger Collapsar.

Estas medidas de seguridad protegen tanto las API REST como las aplicaciones a las que se accede mediante navegadores web. La seguridad de las API también se aplica en el nivel de Ingress, siguiendo el flujo de tráfico norte-sur.

NGINX Ingress Controller con NGINX App Protect WAF y DoS puede proteger el tráfico de Amazon EKS por solicitud en lugar de por servicio: esto ofrece una visión más útil del tráfico de capa 7 y una forma mucho mejor de aplicar los SLA y la seguridad WAF del tráfico norte-sur.

El último informe de GigaOm, «Pruebas de firewalls de aplicaciones web de alto rendimiento», muestra cómo NGINX App Protect WAF ofrece sistemáticamente una sólida seguridad para aplicaciones y API, al tiempo que mantiene un alto rendimiento y una baja latencia, superando a los otros tres WAF evaluados —AWS WAF, Azure WAF y Cloudflare WAF— con 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), de las cuales el 95 % (475 RPS) eran solicitudes válidas y el 5 % (25 RPS), solicitudes «maliciosas» (simulando una inyección de scripts). 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 mayor rendimiento que alcanzó cada WAF con un 100 % de solicitudes procesadas correctamente (sin errores 5xx ni 429) y una latencia inferior a 30 milisegundos por solicitud. NGINX App Protect WAF gestionó 19.000 RPS, frente a las 14.000 RPS de Cloudflare WAF, las 6.000 RPS de AWS WAF y las apenas 2.000 RPS de Azure WAF.

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

NGINX App Protect WAF y DoS adoptan 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 el pipeline de CI/CD durante todo el ciclo de vida de las aplicaciones en Amazon EKS.

NGINX Ingress Controller proporciona varias definiciones de recursos personalizados (CRD) para gestionar todos los aspectos de la seguridad de las aplicaciones web y admitir un modelo multiinquilino y de responsabilidad compartida. Los manifiestos de CRD pueden aplicarse siguiendo la agrupación de espacios de nombres utilizada por la organización, lo que permite que más de un grupo de operaciones asuma su gestión.

Al publicar una aplicación en Amazon EKS, puede integrar la seguridad aprovechando el proceso de automatización que ya utiliza y añadiendo la política de seguridad del WAF.

Además, con NGINX App Protect en NGINX Ingress Controller, puede configurar umbrales de uso de recursos tanto para la utilización de la CPU como de la memoria, a fin de evitar que NGINX App Protect prive de recursos a otros procesos. Esto es especialmente importante en entornos multiinquilino como Kubernetes, que dependen del uso compartido de recursos y pueden verse afectados por 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 el hecho de que los equipos de seguridad suelen trabajar de forma independiente de los equipos de DevOps y de los propietarios de las aplicaciones. Puede enviar los registros de NGINX App Protect a cualquier destino syslog accesible desde los pods de Kubernetes configurando el parámetro de la anotación app-protect-security-log-destination con 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 tanto, cuáles se envían al pod de syslog. Los registros de NGINX Ingress Controller se reenvían a la salida estándar local, como ocurre con todos los contenedores de Kubernetes.

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

apiVersion: appprotect.f5.com/v1beta1 kind: APLogConf 
metadata: 
 name: logconf 
 namespace: dvwa 
spec: 
 content: 
   format: default 
   max_message_size: 64k 
   max_request_size: any 
 filter: 
   request_type: all

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

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

apiVersion: appprotect.f5.com/v1beta1 kind: APPolicy 
metadata: 
  name: sample-policy
spec: 
  policy: 
    name: sample-policy 
    template: 
      name: POLICY_TEMPLATE_NGINX_BASE 
    applicationLanguage: utf-8 
    enforcementMode: blocking 
    signature-sets: 
    - name: Command Execution Signatures 
      alarm: true 
      block: true
[...]

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

apiVersion: appprotect.f5.com/v1beta1 kind: APLogConf 
metadata: 
  name: log-violations
spec: 
  content: 
    format: default 
    max_message_size: 64k 
    max_request_size: any 
  filter: 
    request_type: illegal

A continuación, el objeto Policy waf-policy hace referencia a sample-policy para que NGINX App Protect WAF la aplique al tráfico entrante cuando la aplicación se exponga mediante NGINX Ingress Controller. También hace referencia a log-violations para definir el formato de las entradas de registro enviadas al servidor syslog especificado en el campo logDest.

apiVersion: k8s.nginx.org/v1 kind: Policy 
metadata: 
  name: waf-policy 
spec: 
  waf: 
    enable: true 
    apPolicy: "default/sample-policy" 
    securityLog: 
      enable: true 
      apLogConf: "default/log-violations" 
      logDest: "syslog:server=10.105.238.128:5144"

El despliegue se completa cuando DevOps publica un objeto VirtualServer que configura NGINX Ingress Controller para exponer la aplicación en Amazon EKS:

apiVersion: k8s.nginx.org/v1kind: VirtualServer
metadata:
  name: eshop-vs
spec:
  host: eshop.lab.local
  policies:
  - name: default/waf-policy
  upstreams:
  - name: eshop-upstream
    service: eshop-service
    port: 80
  routes:
  - path: /
    action:
      pass: eshop-upstream

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

Conclusión

Para las empresas con aplicaciones heredadas y soluciones de seguridad desarrolladas a lo largo de los años, desplazar la seguridad a las primeras fases del ciclo de desarrollo en Amazon EKS probablemente sea un proceso gradual. Sin embargo, replantear la seguridad como código gestionado y mantenido por el equipo de seguridad y utilizado por DevOps ayuda a prestar servicios con mayor rapidez y a prepararlos para su puesta en producción.

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

Para probar NGINX Ingress Controller con NGINX App Protect WAF, inicie una prueba gratuita de 30 días en AWS Marketplace o póngase en contacto con nosotros para hablar sobre sus casos de uso.

Para descubrir cómo puede evitar brechas de seguridad y proteger sus aplicaciones de Kubernetes a gran escala mediante NGINX Ingress Controller y NGINX App Protect WAF y DoS en Amazon EKS, descargue nuestro libro electrónico, «Añada 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 de AWS, Azure y Cloudflare, descargue el informe «Pruebas de firewalls de aplicaciones web de alto rendimiento» de GigaOm e inscríbase en el seminario web del 6 de diciembre, en el que el analista de GigaOm Jake Dolezal analizará los resultados.

Sobre los autores

Fabrizio FiorucciArquitecto de soluciones NGINX | F5 (EMEA)

Más artículos de Fabrizio Fiorucci

Thelen BlumResponsable sénior de marketing de producto, NGINX App Protect | F5

Más artículos de Thelen Blum