No início, havia o monólito. Ele atendeu bem aos desenvolvedores de software por muito tempo e ainda atende em alguns casos de uso. Mas, à medida que as aplicações cresceram, os monólitos se tornaram difíceis de desenvolver, proteger e manter. Microsserviços surgiram como uma alternativa: o monólito é dividido em serviços pequenos e autônomos que desempenham uma única função de negócio e se comunicam por uma rede para oferecer todas as funcionalidades da aplicação. Inicialmente, os desenvolvedores web usavam SOAP como protocolo de comunicação e XML para codificar dados, mas muitos consideravam essa combinação complicada e lenta. Isso motivou a migração para arquiteturas baseadas em REST e a ampla adoção de HTTP e JSON como protocolo e método de serialização de dados, respectivamente.
Mas, como costuma acontecer com a tecnologia, os desenvolvedores continuaram buscando maneiras ainda melhores de projetar aplicações, por exemplo, para superar as limitações inerentes à natureza textual do SOAP e do REST. Um desses sistemas é o gRPC, desenvolvido pelo Google para conectar sua vasta gama de serviços independentes e autônomos. O gRPC usa buffers de protocolo (protobufs) como um mecanismo independente de plataforma e linguagem para serializar dados estruturados, e o HTTP/2 como protocolo de comunicação.
Benefícios do gRPC
Entre as vantagens do gRPC em relação a outros frameworks de API estão a alta taxa de transferência com baixa latência, o suporte a várias linguagens, a representação compacta de dados e o streaming em tempo real. Tudo isso o torna especialmente adequado para a comunicação entre microsserviços e em redes de baixo consumo de energia e largura de banda limitada. A popularidade do gRPC aumentou significativamente nos últimos anos porque ele facilita a criação de novos serviços de forma mais rápida e eficiente, com maior confiabilidade e escalabilidade, além de oferecer independência de linguagem tanto para clientes quanto para servidores.
Um exemplo notável dos benefícios do gRPC é o open banking, que usa tecnologias de código aberto para criar e disponibilizar APIs, permitindo que desenvolvedores terceirizados ofereçam serviços adicionais aos clientes de um banco ou de outra instituição financeira. Toda a base do open banking está fundamentada no ideal de fornecer informações financeiras de forma mais eficaz e eficiente. O gRPC ajuda a alcançar esse objetivo porque o formato compacto dos buffers de protocolo e a multiplexação no HTTP/2 tornam a transferência de uma determinada carga útil muito mais rápida do que com APIs REST: cerca de 7 vezes mais rápida no recebimento de dados e 10 vezes mais rápida no envio. Como resultado, as instituições financeiras estão adotando o gRPC para a comunicação entre seus serviços, a fim de oferecer serviços com mais rapidez, eficácia, confiabilidade e escalabilidade.
Um caso de uso específico em que a velocidade do gRPC representa uma grande vantagem é o processo de integração de clientes, que, no open banking, é fundamental para o sucesso. Com outros frameworks de API, a criação de uma nova conta pode ser trabalhosa e demorada tanto para as instituições financeiras quanto para os clientes. Com o gRPC, a rápida transferência de dados permite que os clientes criem uma nova conta em poucos minutos. Isso aumenta significativamente a satisfação dos clientes e, ao mesmo tempo, reduz substancialmente os custos para a instituição financeira.
Protegendo o gRPC
O padrão gRPC e o formato Protocol Buffers são implementados como uma biblioteca de código aberto. O Protocol Buffers é considerado mais seguro contra ataques cibernéticos do que outras representações de dados, pois o analisador da biblioteca rejeita solicitações malformadas e examina com mais cuidado o comportamento da biblioteca.
Mas ainda existem algumas possibilidades preocupantes de ataques contra o gRPC. Por exemplo, o analisador:
- Permite que um fluxo de mensagens seja enviado sem a palavra-chave
stream - Permite várias ocorrências de um campo em uma mensagem, mesmo que o campo não seja declarado como repetível
- Não verifica chaves repetidas em campos de mapa; apenas a última ocorrência da chave é considerada
- Não verifica tipos compostos
oneOfe permite que mais de um campo esteja presente
Um invasor pode explorar essas lacunas no protocolo gRPC para comprometer uma aplicação. Os buffers de protocolo também permitem a criação de campos que não estão definidos nas definições das mensagens. Isso garante a extensibilidade do design — possibilitando a compatibilidade com futuras versões estendidas de uma mensagem —, mas também pode tornar as aplicações vulneráveis a ataques de contrabando, nos quais os invasores incorporam às suas solicitações campos que não estão explicitamente codificados como permitidos na aplicação.
NGINX App Protect protege APIs gRPC
NGINX App Protect foi desenvolvido para proteger aplicações modernas baseadas em gRPC mais perto da aplicação de serviço. Isso permite que as equipes de AppDev, DevOps e DevSecOps gerenciem a segurança das aplicações como código e aproveitem ferramentas nativas.
Por exemplo, o NGINX App Protect garante que as instituições financeiras e seus serviços estejam em conformidade com os padrões de open banking ao implementar o gRPC para suas comunicações entre serviços. O mecanismo do NGINX App Protect realiza uma inspeção profunda das mensagens gRPC nas solicitações transmitidas, analisa mensagens de buffer de protocolo e detecta dados maliciosos nos cabeçalhos e nas cargas úteis das mensagens, inclusive em todas as estruturas de dados aninhadas e complexas. A inspeção é realizada em todas as solicitações e aplica um mecanismo de detecção de ataques a cada parâmetro de chamada de API.
Com as APIs gRPC, você usa a interface gRPC para definir a política de segurança no arquivo da biblioteca de tipos (arquivo IDL) e nos arquivos de definição proto para buffers de protocolo. Quando os arquivos atualizados são carregados, o NGINX App Protect começa imediatamente a aplicar as novas políticas de segurança, sem a necessidade de alterar sua configuração. Os arquivos proto do gRPC são atualizados com frequência como parte dos pipelines de CI/CD. Assim, a atualização das políticas de segurança não interrompe seus processos nem adiciona sobrecarga a eles, e suas aplicações ficam sempre protegidas pela política mais recente e atualizada.
Além de proteger o tráfego leste-oeste entre microsserviços baseados em gRPC, o NGINX App Protect protege o tráfego norte-sul entre seus ativos expostos publicamente.
Embora o gRPC aumente a velocidade, a eficiência e a escalabilidade das comunicações entre serviços, é fundamental proteger os dados de API (URLs, cabeçalhos e cargas úteis) e os serviços de aplicações que expõem APIs gRPC. É por isso que o NGINX App Protect é essencial para a arquitetura moderna das suas aplicações.
Para saber mais sobre o gRPC com o NGINX App Protect, confira nosso vídeo explicativo no quadro:
Experimente o NGINX App Protect gratuitamente
Para obter mais informações sobre o suporte a gRPC no NGINX App Protect, consulte a documentação.
Para experimentar o NGINX Plus e o NGINX App Protect com suas APIs gRPC, inicie uma avaliação gratuita de 30 dias ou entre em contato conosco para conversar sobre seus casos de uso.
Sobre o autor
Publicações relacionadas no blog
Como o F5 NGINX One aprimora o gerenciamento e a observabilidade
Descubra como o F5 NGINX One aprimora o gerenciamento e a observabilidade de ambientes híbridos e multicloud ao oferecer um console web centralizado baseado em SaaS, com insights em tempo real, conformidade automatizada e gerenciamento simplificado de configurações.
Do OpenAPI ao NGINX como gateway de API usando uma API declarativa
Descubra como transformar uma definição de esquema OpenAPI em uma configuração NGINX totalmente funcional, operando como um API Gateway com a segurança de um Web Application Firewall e um Portal do Desenvolvedor, usando uma abordagem declarativa de API.
Como gerenciar picos repentinos de tráfego e sobrecarga do servidor
Picos de tráfego e sobrecarga de servidores são preocupações sérias para varejistas online em qualquer época, mas especialmente durante a “Cyber Season” de compras de fim de ano. Detalhamos como você pode aproveitar as soluções de entrega de aplicações de nível de produção da NGINX para se preparar para aumentos repentinos de tráfego.
Distribuição segura de chaves privadas SSL com o NGINX
Descrevemos três maneiras progressivamente mais seguras de proteger chaves privadas SSL ao configurar o NGINX para processar tráfego HTTPS: permitir acesso de leitura apenas ao usuário root, criptografar as chaves com senhas armazenadas separadamente e distribuir as senhas a partir de um repositório central.
Agrupando solicitações de API em lotes com NGINX Plus e o módulo JavaScript do NGINX
O módulo JavaScript do NGINX lançado com o NGINX Plus R15 oferece suporte a subsolicitações, possibilitando uma classe totalmente nova de casos de uso para o NGINX Plus. Este exemplo completo também usa a API do NGINX Plus e os módulos de chave-valor para converter solicitações de API dos clientes em solicitações separadas para as APIs dos microsserviços que compõem um aplicativo.
Como superar o esgotamento de portas efêmeras no NGINX e no NGINX Plus
Confira dicas para evitar o esgotamento de portas efêmeras com ajustes no kernel do Linux, conexões keepalive e conexões vinculadas dinamicamente a endereços IP locais.