Todas las empresas modernas conocen la necesidad actual de poder ofrecer servicios y aplicaciones antes que sus competidores. Pero por otra parte, las aplicaciones son el blanco principal de los ciberataques y las rápidas actualizaciones y nuevos desarrollos, necesarias para seguir el ritmo de los servicios y necesidades de los clientes, incrementan los riesgos y vulnerabilidades a los que potencialmente habría que enfrentarse para poder desplegarlas en producción de forma segura.
En estas situaciones, existen muchos factores problemáticos a la hora de aplicar estándares de seguridad muy rígidos. La presión por desplegar código nuevo rápidamente en producción no permite en muchas ocasiones aplicar la seguridad adecuada. Existe además demasiada confianza en el uso de herramientas automatizadas de verificación de vulnerabilidades en contenido. Es un error porque no recogen todos los problemas existentes y además requieren una actualización continua. A esto, se le une el desarrollo distribuido entre diferentes equipos, entre los que nunca queda claro qué parte de la implementación de la seguridad les aplica. Por último, ejecutar múltiples aplicaciones en diferentes releases, multiplica las grietas en la seguridad de nuestras aplicaciones.
Como resultado, se hace cada vez más patente la necesidad de aplicar técnicas de seguridad como los Firewall de Aplicación (WAF). Este tipo de recursos se aplican habitualmente en el borde de nuestras infraestructuras de red, junto a balanceadores, para establecer un perímetro de seguridad de red en nuestro entorno corporativo.
Pero diferentes problemas de seguridad en aplicaciones e infraestructuras modernas revelan que es importante refinar esta aproximación:
- La seguridad en el perímetro no es suficiente. Cada vez es más necesario implementar la seguridad con WAF más cerca de las aplicaciones que queremos proteger.
- La seguridad ya no es una responsabilidad únicamente del CISO y el Grupo de Seguridad. Los equipos de DevOps tienen un rol crítico al desplegar ellos parte de las políticas de seguridad en sus automatizaciones de los pipelines de CI/CD.
NGINX Plus Ingress Controller con NGINX App Protect
Junto con NGINX Plus Ingress Controller for Kubernetes release 1.8.0, podemos desplegar NGINX App Protect WAF:
Para poder implementar NGINX App Protect dentro de Nginx Plus Ingress Controller, necesitamos disponer de una subscripción de ambos productos, NGINX Plus y App Protect. Con unos simples pasos podemos construir una imagen de NGINX Plus Ingress Controller image y luego podemos desplegarla manualmente, con Charts de Helm o incluso con el operador NGINX Ingress Operator en aquellas plataformas que lo soportan, por ejemplo Red Hat OpenShift. Una vez en ejecución, usaremos la API de Kubernetes de la forma habitual para gestionar las configuraciones y políticas de seguridad.
¿Por qué es tan importante poder integrar WAF dentro del propio NGINX Plus Ingress Controller?
Integrar NGINX App Protect WAF dentro de NGINX Plus Ingress Controller nos proporciona los siguientes beneficios:
- Securiza el perímetro de la aplicación – En una arquitectura de Kubernetes, las aplicaciones se publican usando Ingress Controller, y este es el único punto de entrada de tráfico de data-plane para acceder a los servicios publicados, haciéndolo el lugar ideal para establecer un proxy de seguridad.
- Consolidación del data-plane – Al incluir el WAF dentro del propio Ingress Controller se elimina la necesidad de un dispositivo externo; lo que reduce la complejidad, los costes y el número de puntos de fallo.
- Consolidación del control-plane – Las configuraciones de WAF se gestionan desde la API de Kubernetes, haciendo posible su automatización dentro de las cadenas de CI/CD. Si además se aplican roles de control de Kubernetes sobre las configuraciones de Ingress Controller, es posible delegar la configuración de WAF a grupos de seguridad DevSecOps dedicados.
Las configuraciones creadas para App Protect pueden ser usados tanto dentro del Ingress Controller (mediante ficheros YAML) como en NGINX Plus (usando ficheros JSON). La configuración principal puede traducirse y desplegarse en cualquier dispositivo, facilitando la gestión de la configuración de WAF como código y desplegarla dentro del entorno de la aplicación.
Configuración de App Protect en NGINX Plus Ingress Controller
Configuraremos App Protect dentro NGINX Plus Ingress Controller con dos nuevos recursos de Kubernetes (custom resources):
- APPolicy define la política de WAF que debe aplicarse en App Protect. Esta política de WAF es la versión en fichero YAML de la que aplicaríamos si usáramos la versión de App Protect con NGINX Plus, que estaría en formato JSON.
- APLogConf define el comportamiento de logging que aplicará el módulo de App Protect.
La imagen de Ingress Controller también incluye un conjunto de firmas de App Protect que se incluyen en tiempo de construcción.
Una vez hemos desplegado los recursos de APPolicy y APLogConf, los referenciamos en los recursos de Ingress usando anotaciones:
App Protect inspecciona y bloquea las peticiones gestionadas por el Ingress Controller.
Los recursos APPolicy y APLogConf pueden definirse en diferente namespace, por ejemplo para permitir que el equipo DevSecOps los gestione. Esto permite separar diferentes ámbitos de seguridad, permitiendo por ejemplo la delegación de las políticas de seguridad a equipos dedicados en entornos muy extensos.
Las políticas de App Protect protegen nuestras aplicaciones web frente a diferentes tipos de amenazas, incluyendo las 10 más habituales OWASP, cross‑site scripting (XSS), injecciones, técnicas de evasión, fugas de información (con Data Guard), y muchas otras. El siguiente ejemplo de recurso APPolicy habilita el bloqueo de violaciones de Data Guard:
Gestión de Logs
Los logs de App Protect y del NGINX Plus Ingress Controller están separados, para reflejar el uso habitual por diferentes equipos, mostrando información de forma independiente para los responsables de las aplicaciones y los equipos de seguridad. Es posible enviar los logs de App Protect a cualquier entorno syslog disponible desde los Pods desplegados en Kubernetes, configurando el parámetro app-protect-security-log-destination, como anotación, con la IP interna del Pod con Syslog (podemos ver esto en el ejemplo anterior del recurso Ingress). Además, podemos usar el recurso APLogConf para separar los los relevantes de App Protect y también la configuración de envío a un Pod con Syslog. Por su parte, los logs de NGINX Plus Ingress Controller se envían a la salida estándar de igual forma que el resto de contenedores desplegados en Kubernetes.
Límites de Recursos
Por último, podemos configurar NGINX App Protect sobre NGINX Plus Ingress Controller con límites de consumo de CPU y memoria, evitando así que los procesos de App Protect procesos impacten sobre otras aplicaciones. Esto es especialmente importante en entornos multi‑tenant en los que los que pueden verse afectados los recursos compartidos entre diferentes clientes dentro de un cluster de Kubernetes. El siguiente ejemplo muestra la configuración a partir de un ConfigMap de los límites de consumo de los procesos de App Protect.
El límite high indica el porcentaje máximo de consumo a partir del cual App Protect entrará en modo de fallo, y el límite low representa el valor a partir del cual App Protect dejará de estar en el modo de fallo. Para la memoria, se ha usado 100% y 10% respectivamente, mientras que para CPU se usó 100% y 50%. El valor drop en el parámetro app_protect_failure_mode_action indica que App Protect rechaza el tráfico cuando se encuentra en modo de fallo, cerrando las conexiones.
Para obtener información más detallada sobre la configuración y solución de problemas de NGINX App Protect sobre NGINX Plus Ingress Controller, consulte la documentación de Ingress Controller. Para obtener más información sobre App Protect y sus casos de uso, consulte la documentación del producto NGINX App Protect.
Integraciones Futuras
Los recursos Ingress se configuran mediante anotaciones en la release 1.8.0 para hacer referencia a políticas de App Protect, pero esto no es óptimo para proporcionar la granularidad necesaria para conocer qué peticiones serán gestionadas por App Protect y cuáles no.
En las futuras versiones de NGINX Plus Ingress Controller se proporcionará más detalle de las configuraciones integradas dentro de los recursos Ingress de NGINX NGINX. Esto nos permitirá más control sobre el comportamiento de las políticas de WAF sobre las peticiones.
Conclusión
En las aplicaciones modernas, desplegadas sobre contenedores, es habitual asumir que el tráfico de entrada (“norte-sur”) no es seguro, mientras que el tráfico interno (“este‑oeste”) sí es seguro. Este es el caso ideal para aplicar la seguridad mediante un proxy de tipo WAF sobre el Ingress Controller.
NGINX Plus Ingress Controller con NGINX App Protect es el único Ingress Controller que integra una solución completa de WAF. Integrando WAF dentro del Ingress Controller mejoramos de forma eficiente la plataforma unificando los dispositivos de gestión del data‑plane, y delegando las configuraciones sobre la API de Kubernetes, como el resto de componentes de un entorno de estas características.
Para poder probar NGINX App Protect sobre NGINX Plus Ingress Controller, puede comenzar una free 30-day trial hoy o contactar con nosotros para comentar su caso de uso.
