Protección de las API gRPC con NGINX App Protect

NGINX | 10 de febrero de 2021

Yaniv SazmanGerente sénior de Gestión de Producto

Al principio estaba el monolito. Durante mucho tiempo, fue una solución eficaz para los desarrolladores de software, y aún lo sigue siendo en algunos casos de uso. Sin embargo, a medida que las aplicaciones crecían, los monolitos se volvían difíciles de desarrollar, proteger y mantener. Los microservicios surgieron como alternativa: el monolito se divide en servicios pequeños y autónomos que realizan una única función empresarial y se comunican a través de una red para ofrecer toda la funcionalidad de la aplicación. Al principio, los desarrolladores web utilizaban SOAP como protocolo de comunicación y XML para codificar los datos, pero muchos consideraban que esta combinación era engorrosa y lenta. Esto impulsó la transición hacia arquitecturas basadas en REST y la adopción generalizada de HTTP y JSON como protocolo y método de serialización de datos, respectivamente.

Pero, como suele ocurrir con la tecnología, los desarrolladores siguieron buscando formas aún mejores de diseñar aplicaciones, por ejemplo, para superar las limitaciones inherentes al enfoque basado en texto de SOAP y REST. Uno de estos sistemas es gRPC, que Google desarrolló para conectar su amplia variedad de servicios independientes y autónomos. gRPC utiliza búferes de protocolo (protobufs) como mecanismo independiente de la plataforma y del lenguaje para serializar datos estructurados, y HTTP/2 como protocolo de comunicación.

Ventajas de gRPC

Entre las ventajas de gRPC frente a otros frameworks de API se encuentran su rendimiento con baja latencia, la compatibilidad con varios lenguajes, la representación compacta de los datos y la transmisión en tiempo real. Todo ello lo hace especialmente adecuado para la comunicación entre microservicios y a través de redes de baja potencia y ancho de banda limitado. La popularidad de gRPC ha aumentado considerablemente en los últimos años porque permite crear nuevos servicios de forma más rápida y eficiente, con mayor fiabilidad y escalabilidad, y con independencia del lenguaje tanto para los clientes como para los servidores.

Un ejemplo destacado de las ventajas de gRPC es la banca abierta, que utiliza tecnologías de código abierto para crear y ofrecer API, lo que permite a desarrolladores externos ofrecer servicios adicionales a los clientes de un banco u otra entidad financiera. La banca abierta se sustenta por completo en el objetivo de proporcionar información financiera de forma más eficaz y eficiente. gRPC ayuda a alcanzar este objetivo porque el formato compacto de los búferes de protocolo y la multiplexación en HTTP/2 permiten transferir una carga útil determinada mucho más rápido que con las API REST: aproximadamente 7 veces más rápido al recibir datos y 10 veces más rápido al enviarlos. Por ello, las entidades financieras están adoptando gRPC para sus comunicaciones entre servicios, con el fin de prestar servicios con mayor rapidez, eficacia, fiabilidad y escalabilidad.

Un caso de uso concreto en el que la velocidad de gRPC supone una gran ventaja es el proceso de incorporación de clientes, que en la banca abierta resulta fundamental para el éxito. Con otros frameworks de API, crear una cuenta nueva puede ser un proceso engorroso y lento tanto para las entidades financieras como para los clientes. Con gRPC, la rápida transferencia de datos permite a los clientes crear una cuenta nueva en cuestión de minutos. Esto aumenta considerablemente la satisfacción del cliente y, al mismo tiempo, reduce de forma sustancial los costes para la entidad financiera.

Protección de gRPC

El estándar gRPC y el formato Protocol Buffers están implementados como una biblioteca de código abierto. Protocol Buffers se considera más seguro frente a ciberataques que otras representaciones de datos, ya que el analizador de la biblioteca rechaza las solicitudes malformadas y examina con mayor detenimiento el comportamiento de la biblioteca.

Sin embargo, siguen existiendo algunas posibilidades preocupantes de ataque contra gRPC. Por ejemplo, el analizador:

Permite enviar un flujo de mensajes sin la palabra clave stream
Permite que un campo aparezca varias veces en un mensaje, aunque no esté declarado como repetible
No comprueba las claves repetidas en los campos de mapa; solo se tiene en cuenta la última aparición de la clave
No comprueba los tipos compuestos oneOf y permite que haya más de un campo presente

Un atacante puede aprovechar estas carencias del protocolo gRPC para comprometer una aplicación. Los búferes de protocolo también permiten crear campos que no están definidos en las definiciones de los mensajes. Esto garantiza la extensibilidad del diseño —lo que permite la compatibilidad con futuras versiones ampliadas de un mensaje—, pero también puede hacer que las aplicaciones sean vulnerables a ataques de contrabando, en los que los atacantes incorporan en sus solicitudes campos que no están codificados explícitamente como permitidos en la aplicación.

NGINX App Protect protege las API de gRPC

NGINX App Protect está diseñado para proteger las aplicaciones modernas basadas en gRPC más cerca de la aplicación de servicio. Esto permite a los equipos de AppDev, DevOps y DevSecOps gestionar la seguridad de las aplicaciones como código y aprovechar las herramientas nativas.

Por ejemplo, NGINX App Protect garantiza que las entidades financieras y sus servicios cumplan los estándares de banca abierta al implementar gRPC para sus comunicaciones entre servicios. El motor de NGINX App Protect realiza una inspección exhaustiva de los mensajes gRPC en las solicitudes transmitidas, analiza los mensajes de búfer de protocolo y detecta datos maliciosos en las cabeceras y las cargas útiles de los mensajes, incluidas todas las estructuras de datos anidadas y complejas. La inspección se realiza en todas las solicitudes y aplica un mecanismo de detección de ataques a cada parámetro de llamada a la API.

Con las API de gRPC, se utiliza la interfaz de gRPC para establecer la política de seguridad en el archivo de la biblioteca de tipos (archivo IDL) y en los archivos de definición proto de los búferes de protocolo. Cuando se cargan los archivos actualizados, NGINX App Protect comienza a aplicar de inmediato las nuevas políticas de seguridad sin necesidad de realizar ningún cambio en su configuración. Los archivos proto de gRPC se actualizan con frecuencia como parte de las canalizaciones de CI/CD, por lo que la actualización de las políticas de seguridad no interrumpe los procesos ni les añade sobrecarga, y las aplicaciones están siempre protegidas por la política más reciente y actualizada.

Además de proteger el tráfico este-oeste entre microservicios basados en gRPC, NGINX App Protect protege el tráfico norte-sur entre sus activos expuestos públicamente.

Aunque gRPC mejora la velocidad, la eficiencia y la escalabilidad de las comunicaciones entre servicios, es fundamental proteger los datos de las API (URL, encabezados y cargas útiles) y los servicios de aplicaciones que exponen API de gRPC. Por eso, NGINX App Protect es esencial para la arquitectura de sus aplicaciones modernas.

Para obtener más información sobre gRPC con NGINX App Protect, vea nuestro vídeo explicativo en pizarra: