Seis maneiras de proteger o Kubernetes usando ferramentas de gerenciamento de tráfego

Editor – Este post faz parte de uma série de 10 partes:

1. Reduza a complexidade com o Kubernetes de nível de produção
2. Como melhorar a resiliência no Kubernetes com gerenciamento avançado de tráfego
3. Como melhorar a visibilidade no Kubernetes
4. Seis maneiras de proteger o Kubernetes usando ferramentas de gerenciamento de tráfego (esta postagem)
5. Um guia para escolher um controlador Ingress, parte 1: Identifique seus requisitos
6. Um guia para escolher um controlador Ingress, parte 2: Riscos e preparação para o futuro
7. Um guia para escolher um controlador Ingress, parte 3: Código aberto vs. Padrão vs. Comercial
8. Um guia para escolher um controlador Ingress, parte 4: Opções do controlador de entrada NGINX
9. Como escolher uma malha de serviço
10. Teste de desempenho de controladores de entrada NGINX em um ambiente de nuvem Kubernetes dinâmico

Você também pode baixar o conjunto completo de blogs como um e-book gratuito – Levando o Kubernetes do teste à produção .

Conforme discutido em Proteger aplicativos nativos da nuvem sem perder velocidade , observamos três fatores que tornam os aplicativos nativos da nuvem mais difíceis de proteger do que os aplicativos tradicionais:

1. A entrega de aplicativos nativos da nuvem causa proliferação de ferramentas e oferece serviços inconsistentes de nível empresarial
2. Os custos de entrega de aplicativos nativos da nuvem podem ser imprevisíveis e altos
3. As equipes de SecOps lutam para proteger aplicativos nativos da nuvem e estão em desacordo com o DevOps

Embora todos os três fatores possam impactar igualmente a segurança, o terceiro fator pode ser o problema mais difícil de resolver, talvez porque seja o mais “humano”. Quando o SecOps não é capaz ou não tem autonomia para proteger aplicativos nativos da nuvem, algumas das consequências são óbvias (vulnerabilidades e violações), mas outras ficam ocultas, incluindo agilidade reduzida e transformação digital paralisada.

Vamos nos aprofundar nesses custos ocultos. As organizações escolhem o Kubernetes por sua promessa de agilidade e economia de custos. Mas quando há incidentes de segurança em um ambiente Kubernetes, a maioria das organizações retira suas implantações do Kubernetes da produção . Isso retarda as iniciativas de transformação digital que são essenciais para o futuro da organização — sem falar nos esforços de engenharia e dinheiro desperdiçados. A conclusão lógica é: se você vai tentar levar o Kubernetes do teste para a produção, a segurança deve ser considerada um componente estratégico de propriedade de todos na organização.

Nesta postagem, abordamos seis casos de uso de segurança que você pode resolver com ferramentas de gerenciamento de tráfego do Kubernetes, permitindo que o SecOps colabore com o DevOps e o NetOps para proteger melhor seus aplicativos e APIs nativos da nuvem. Uma combinação dessas técnicas é frequentemente usada para criar uma estratégia de segurança abrangente, projetada para manter aplicativos e APIs seguros, minimizando o impacto aos clientes.

1. Resolva CVEs rapidamente para evitar ataques cibernéticos
2. Pare o OWASP Top 10 e os ataques de negação de serviço
3. Descarregue a autenticação e autorização de aplicativos
4. Configurar autoatendimento com guardrails
5. Implementar criptografia de ponta a ponta
6. Garantir que os clientes estejam usando uma cifra forte com uma implementação confiável

Terminologia de Segurança e Identidade

Antes de entrarmos nos casos de uso, aqui está uma rápida visão geral de alguns termos de segurança e identidade que você encontrará ao longo desta postagem.

• Autenticação e autorização – Funções necessárias para garantir que apenas os usuários e serviços “certos” possam obter acesso aos backends ou componentes do aplicativo:

  • Autenticação – Verificação de identidade para garantir que os clientes que fazem solicitações são quem dizem ser. Realizado por meio de tokens de ID, como senhas ou JSON Web Tokens (JWTs).

  • Autorização – Verificação de permissão para acessar um recurso ou função. Realizado por meio de tokens de acesso, como atributos da Camada 7, como cookies de sessão, IDs de sessão, IDs de grupo ou conteúdo de token.

• Vulnerabilidades e Exposições Críticas (CVEs) – Um banco de dados de falhas divulgadas publicamente “em um software, firmware, hardware ou componente de serviço resultante de uma fraqueza que pode ser explorada, causando um impacto negativo na confidencialidade, integridade ou disponibilidade de um componente ou componentes impactados” ( https://www.cve.org/ ). Os CVEs podem ser descobertos pelos desenvolvedores que gerenciam a ferramenta, um testador de penetração, um usuário ou cliente, ou alguém da comunidade (como um “caçador de bugs”). É uma prática comum dar tempo ao proprietário do software para desenvolver um patch antes que a vulnerabilidade seja divulgada publicamente, para não dar vantagem aos malfeitores.

• Ataque de negação de serviço (DoS) – Um ataque no qual um agente malicioso inunda um site com solicitações (TCP/UDP ou HTTP/HTTPS) com o objetivo de fazer o site travar. Como os ataques DoS afetam a disponibilidade, seu principal resultado é o dano à reputação do alvo. Um ataque de negação de serviço distribuído (DDoS) , no qual várias fontes têm como alvo a mesma rede ou serviço, é mais difícil de se defender devido à rede potencialmente grande de invasores. A proteção DoS requer uma ferramenta que identifique e previna ataques de forma adaptável. Saiba mais em O que é Negação de Serviço Distribuída (DDoS)?

• Criptografia de ponta a ponta (E2EE) – A prática de criptografar completamente os dados à medida que eles passam do usuário para o aplicativo e vice-versa. O E2EE requer certificados SSL e potencialmente mTLS.

• TLS mútuo (mTLS) – A prática de exigir autenticação (via certificado SSL/TLS) tanto para o cliente quanto para o host. O uso do mTLS também protege a confidencialidade e a integridade dos dados transmitidos entre o cliente e o host. O mTLS pode ser realizado até o nível do pod do Kubernetes, entre dois serviços no mesmo cluster. Para uma excelente introdução ao SSL/TLS e mTLS, veja O que é mTLS? no F5 Labs.

• Logon único (SSO) – As tecnologias SSO (incluindo SAML, OAuth e OIDC) facilitam o gerenciamento da autenticação e autorização.

  • Autenticação simplificada – O SSO elimina a necessidade de um usuário ter um token de ID exclusivo para cada recurso ou função diferente.

  • Autorização padronizada – O SSO facilita a definição de direitos de acesso do usuário com base na função, departamento e nível de antiguidade, eliminando a necessidade de configurar permissões para cada usuário individualmente.

• SSL (Secure Sockets Layer)/TLS (Transport Layer Security) – Um protocolo para estabelecer links autenticados e criptografados entre computadores em rede. Os certificados SSL/TLS autenticam a identidade de um site e estabelecem uma conexão criptografada. Embora o protocolo SSL tenha sido descontinuado em 1999 e substituído pelo protocolo TLS, ainda é comum se referir a essas tecnologias relacionadas como “SSL” ou “SSL/TLS” – por uma questão de consistência, usaremos SSL/TLS no restante desta postagem.

• Firewall de aplicativo da Web (WAF) – Um proxy reverso que detecta e bloqueia ataques sofisticados contra aplicativos e APIs (incluindo OWASP Top 10 e outras ameaças avançadas), ao mesmo tempo em que permite a passagem de tráfego “seguro”. Os WAFs defendem contra ataques que tentam prejudicar o alvo roubando dados confidenciais ou sequestrando o sistema. Alguns fornecedores consolidam proteção WAF e DoS na mesma ferramenta, enquanto outros oferecem ferramentas WAF e DoS separadas.

• Confiança zero – Um conceito de segurança frequentemente usado em organizações de segurança mais alta, mas relevante para todos, no qual os dados devem ser protegidos em todos os estágios de armazenamento e transporte. Isso significa que a organização decidiu não “confiar” em nenhum usuário ou dispositivo por padrão, mas sim exigir que todo o tráfego seja cuidadosamente examinado. Uma arquitetura de confiança zero normalmente inclui uma combinação de autenticação, autorização e mTLS com alta probabilidade de a organização implementar E2EE.

Caso de uso: Resolva CVEs rapidamente para evitar ataques cibernéticos

Solução: Use ferramentas com notificações de patch oportunas e proativas

De acordo com um estudo do Ponemon Institute , em 2019 houve um “período de carência” médio de 43 dias entre o lançamento de um patch para uma vulnerabilidade crítica ou de alta prioridade e as organizações que presenciaram ataques que tentaram explorar a vulnerabilidade. Na F5 NGINX, vimos essa janela diminuir significativamente nos anos seguintes (até mesmo no dia zero no caso do Apple iOS 15 em 2021 ), e é por isso que recomendamos aplicar o patch o mais rápido possível. Mas e se os patches para suas ferramentas de gerenciamento de tráfego não estiverem disponíveis por semanas, ou até meses, após o anúncio de um CVE?

Ferramentas desenvolvidas e mantidas por colaboradores da comunidade (em vez de uma equipe de engenharia dedicada) têm o potencial de ficar semanas ou meses atrás dos anúncios do CVE, tornando improvável que as organizações consigam aplicar patches dentro desse período de 43 dias . Em um caso , o OpenResty levou quatro meses para aplicar um patch de segurança relacionado ao NGINX. Isso deixou qualquer pessoa que usasse um controlador Ingress baseado em OpenResty vulnerável por pelo menos quatro meses, mas, realisticamente, geralmente há um atraso adicional antes que os patches estejam disponíveis para software que depende de um projeto de código aberto.

Para obter a correção de CVE mais rápida, procure duas características ao selecionar ferramentas de gerenciamento de tráfego:

• Uma equipe de engenharia dedicada – Quando o desenvolvimento da ferramenta é gerenciado por uma equipe de engenharia em vez de voluntários da comunidade, você sabe que há um grupo de pessoas dedicadas à saúde da ferramenta e que podem priorizar o lançamento de um patch o mais rápido possível.
• Uma base de código integrada – Sem nenhuma dependência externa (como discutimos com o OpenResty), os patches estão a apenas um sprint ágil de distância.

Para mais informações sobre patches de CVE, leia Mitigating Security Vulnerabilities Quickly and Easily with NGINX Plus .

Caso de uso: Pare os ataques OWASP Top 10 e DoS

Solução: Implante proteção WAF e DoS flexível e amigável ao Kubernetes

A escolha da proteção WAF e DoS correta para aplicativos Kubernetes depende de dois fatores (além dos recursos):

• Flexibilidade – Há cenários em que é melhor implantar ferramentas dentro do Kubernetes, então você quer ferramentas independentes de infraestrutura que possam ser executadas dentro ou fora do Kubernetes. Usar a mesma ferramenta para todas as suas implantações permite que você reutilize políticas e reduza a curva de aprendizado para suas equipes de SecOps.
• Pegada – As melhores ferramentas do Kubernetes têm uma pegada pequena, o que permite o consumo apropriado de recursos com impacto mínimo na taxa de transferência, solicitações por segundo e latência. Considerando que as equipes de DevOps geralmente resistem às ferramentas de segurança devido à percepção de que elas tornam os aplicativos mais lentos, escolher uma ferramenta de alto desempenho com um tamanho pequeno pode aumentar a probabilidade de adoção.

Embora uma ferramenta que consolide a proteção WAF e DoS possa parecer mais eficiente, na verdade é esperado que ela tenha problemas em relação ao uso da CPU (devido a uma pegada maior) e à flexibilidade. Você é forçado a implantar a proteção WAF e DoS juntas, mesmo quando não precisa de ambas. No final das contas, ambos os problemas podem aumentar o custo total de propriedade das suas implantações do Kubernetes e criar desafios orçamentários para outras ferramentas e serviços essenciais.

Depois de escolher as ferramentas de segurança certas para sua organização, é hora de decidir onde implantá-las. Há quatro locais onde os serviços de aplicativos normalmente podem ser implantados para proteger aplicativos Kubernetes:

• Na porta da frente (em um balanceador de carga externo, como F5 NGINX Plus ou F5 BIG-IP ) – Bom para proteção global “de granulação grossa” porque permite que você aplique políticas globais em vários clusters
• Na borda (em um controlador Ingress como o F5 NGINX Ingress Controller ) – Ideal para fornecer proteção “de granulação fina” que é padrão em um único cluster
• No serviço (em um balanceador de carga leve como o NGINX Plus) – Pode ser uma abordagem necessária quando há um pequeno número de serviços em um cluster que têm uma necessidade compartilhada de políticas exclusivas
• No pod (como parte do aplicativo) – Uma abordagem muito personalizada que pode ser usada quando a política é específica para o aplicativo

Então, das quatro opções, qual é a melhor? Bem...isso depende!

Onde implantar um WAF

Primeiro, veremos as opções de implantação do WAF, pois essa tende a ser uma escolha mais diferenciada.

• Porta frontal e borda – Se sua organização prefere uma estratégia de segurança de “defesa em profundidade”, recomendamos implantar um WAF no balanceador de carga externo e no controlador Ingress para fornecer um equilíbrio eficiente de proteções globais e personalizadas.
• Porta da frente ou borda – Na ausência de uma estratégia de “defesa em profundidade”, um único local é aceitável, e o local de implantação depende da propriedade. Quando uma equipe tradicional de NetOps é responsável pela segurança, ela pode se sentir mais confortável gerenciá-la em um proxy tradicional (o balanceador de carga externo). No entanto, as equipes de DevSecOps que se sentem confortáveis com o Kubernetes (e preferem ter sua configuração de segurança próxima às configurações de cluster) podem optar por implantar um WAF no nível de entrada.
• Por serviço ou pod – Se suas equipes tiverem requisitos específicos para seus serviços ou aplicativos, elas poderão implantar WAFs adicionais de forma à la carte. Mas esteja ciente: esses locais têm custos mais altos. Além do aumento do tempo de desenvolvimento e de um orçamento maior para a nuvem, essa escolha também pode aumentar os custos operacionais relacionados aos esforços de solução de problemas – como ao determinar “Qual dos nossos WAFs está bloqueando o tráfego involuntariamente?”

Onde implementar proteção DoS

A proteção contra ataques DoS é mais direta, pois é necessária apenas em um local: na porta da frente ou no controlador do Ingress. Se você implantar um WAF na porta da frente e na borda, recomendamos que você implante a proteção DoS na frente do WAF da porta da frente, pois ele é o mais global. Dessa forma, o tráfego indesejado pode ser eliminado antes de atingir o WAF, permitindo que você faça uso mais eficiente dos recursos de computação.

Para obter mais detalhes sobre cada um desses cenários de implantação, leia Implantando serviços de aplicativos no Kubernetes, Parte 2 .

Caso de uso: Descarregue a autenticação e autorização de aplicativos

Solução: Centralize a autenticação e a autorização no ponto de entrada

Um requisito não funcional comum que é incorporado em aplicativos e serviços é a autenticação e a autorização. Em pequena escala, essa prática adiciona uma quantidade administrável de complexidade que é aceitável quando o aplicativo não requer atualizações frequentes. Mas com velocidades de lançamento mais rápidas em maior escala, integrar autenticação e autorização em seus aplicativos se torna insustentável. Garantir que cada aplicativo mantenha os protocolos de acesso apropriados pode desviar a atenção da lógica de negócios do aplicativo ou, pior, pode ser esquecido e levar a uma violação de informações. Embora o uso de tecnologias SSO possa melhorar a segurança ao eliminar nomes de usuário e senhas separados em favor de um conjunto de credenciais, os desenvolvedores ainda precisam incluir código em seus aplicativos para interagir com o sistema SSO.

Existe uma maneira melhor: descarregar a autenticação e a autorização para um controlador Ingress.

Como o controlador Ingress já está examinando todo o tráfego que entra no cluster e o roteando para os serviços apropriados, ele é uma escolha eficiente para autenticação e autorização centralizadas. Isso elimina o fardo dos desenvolvedores de criar, manter e replicar a lógica no código do aplicativo; em vez disso, eles podem aproveitar rapidamente as tecnologias SSO na camada de entrada usando a API nativa do Kubernetes.

Para mais informações sobre este tópico, leia Implementando a autenticação OpenID Connect para Kubernetes com Okta e NGINX Ingress Controller .

Caso de uso: Configurar autoatendimento com guardrails

Solução: Implementar controle de acesso baseado em função (RBAC)

O Kubernetes usa o RBAC para controlar os recursos e operações disponíveis para diferentes tipos de usuários. Esta é uma medida de segurança valiosa, pois permite que um administrador ou superusuário determine como usuários, ou grupos de usuários, podem interagir com qualquer objeto do Kubernetes ou namespace específico no cluster.

Embora o RBAC do Kubernetes esteja habilitado por padrão, você precisa tomar cuidado para que suas ferramentas de gerenciamento de tráfego do Kubernetes também estejam habilitadas para RBAC e possam se alinhar às necessidades de segurança da sua organização. Com o RBAC em vigor, os usuários obtêm acesso restrito às funcionalidades necessárias para realizar seu trabalho sem precisar esperar que um tíquete seja atendido. Mas sem o RBAC configurado, os usuários podem obter permissões que não precisam ou às quais não têm direito, o que pode levar a vulnerabilidades se as permissões forem mal utilizadas.

Um controlador Ingress é um excelente exemplo de uma ferramenta que pode servir a várias pessoas e equipes quando configurada com RBAC. Quando o controlador Ingress permite um gerenciamento de acesso refinado – até mesmo para um único namespace – você pode usar RBAC para habilitar o uso eficiente de recursos por meio de multilocação.

Por exemplo, várias equipes podem usar o controlador Ingress da seguinte maneira:

• Equipe NetOps – Configura o ponto de entrada externo do aplicativo (como o nome do host e os certificados TLS) e delega políticas de controle de tráfego para várias equipes
• DevOps Team A – Provisiona políticas de balanceamento de carga e roteamento TCP/UDP
• DevOps Team B – Configura políticas de limitação de taxa para proteger serviços de solicitações excessivas
• Equipe de identidade – gerencia componentes de autenticação e autorização enquanto configura políticas mTLS como parte de uma estratégia de criptografia de ponta a ponta
• Equipe DevSecOps – Define políticas WAF

Para aprender como aproveitar o RBAC no NGINX Ingress Controller, assista a Implantações avançadas do Kubernetes com o NGINX Ingress Controller . A partir das 13h50, nossos especialistas explicam como aproveitar o RBAC e a alocação de recursos para segurança, autoatendimento e multilocação.

Caso de uso: Implementar criptografia de ponta a ponta

Solução: Use ferramentas de gerenciamento de tráfego

A criptografia de ponta a ponta (E2EE) está se tornando um requisito cada vez mais comum para organizações que lidam com informações confidenciais ou pessoais. Sejam dados financeiros ou mensagens de mídia social, as expectativas de privacidade do consumidor combinadas com regulamentações como GDPR e HIPAA estão impulsionando a demanda por esse tipo de proteção. O primeiro passo para atingir a E2EE é arquitetar seus aplicativos de backend para aceitar tráfego SSL/TLS ou usar uma ferramenta que descarregue o gerenciamento de SSL/TLS de seus aplicativos (a opção preferida para separação de função de segurança, desempenho, gerenciamento de chaves, etc.). Em seguida, você configura suas ferramentas de gerenciamento de tráfego dependendo da complexidade do seu ambiente.

Cenário mais comum: E2EE usando um controlador de entrada

Quando você tem aplicativos com apenas um ponto de extremidade (aplicativos simples ou aplicativos monolíticos que você "transferiu e transferiu" para o Kubernetes) ou não há comunicação de serviço para serviço , você pode usar um controlador Ingress para implementar E2EE no Kubernetes.

Passo 1: Certifique-se de que seu controlador Ingress permita somente conexões SSL/TLS criptografadas usando certificados do lado do serviço ou mTLS, idealmente para tráfego de entrada e saída.

Passo 2: Aborde a configuração padrão típica que exige que o controlador Ingress descriptografe e criptografe novamente o tráfego antes de enviá-lo aos aplicativos. Isso pode ser feito de algumas maneiras – o método escolhido depende do seu controlador Ingress e dos requisitos:

• Se o seu controlador Ingress oferecer suporte à passagem SSL/TLS, ele poderá rotear conexões criptografadas SSL/TLS com base no cabeçalho Service Name Indication (SNI), sem descriptografá-las ou exigir acesso aos certificados ou chaves SSL/TLS.
• Como alternativa, você pode configurar a terminação SSL/TLS, onde o controlador Ingress encerra o tráfego e, em seguida, o envia por proxy para os backends ou upstreams, seja em texto simples ou criptografando novamente o tráfego com mTLS ou SSL/TLS do lado do serviço para seus serviços do Kubernetes.

Cenário menos comum: E2EE usando um controlador de entrada e malha de serviço

Se houver comunicação de serviço para serviço dentro do seu cluster, você precisará implementar o E2EE em dois planos: tráfego de entrada e saída com o controlador Ingress e tráfego de serviço para serviço com uma malha de serviço . No E2EE, a função de uma malha de serviços é garantir que apenas serviços específicos tenham permissão para se comunicar entre si e que o façam de maneira segura. Ao configurar uma malha de serviço para E2EE, você precisa habilitar um ambiente de confiança zero por meio de dois fatores: mTLS entre serviços (configurado para exigir um certificado) e controle de acesso de tráfego entre serviços (determinando quais serviços estão autorizados a se comunicar). O ideal é que você também implemente o mTLS entre os aplicativos (gerenciados por uma malha de serviço e o controlador de entrada e saída) para obter verdadeira segurança E2EE em todo o cluster do Kubernetes.

Para saber mais sobre como criptografar dados expostos na rede, leia A arquitetura mTLS no NGINX Service Mesh .

Caso de uso: Garanta que os clientes estejam usando uma cifra forte com uma implementação confiável

Solução: Cumpra com os Padrões Federais de Processamento de Informações (FIPS)

No setor de software, FIPS geralmente se refere à publicação específica sobre criptografia, FIPS PUB 140-2 Requisitos de Segurança para Módulos Criptográficos, que é um esforço conjunto entre os Estados Unidos e o Canadá. Ela padroniza os testes e a certificação de módulos criptográficos aceitos pelas agências federais de ambos os países para a proteção de informações sensíveis. “Mas espere!” você diz. “Não me importo com o FIPS porque não trabalho com entidades governamentais norte-americanas.” Tornar-se compatível com o FIPS pode ser uma decisão inteligente, independentemente do seu setor ou região geográfica, porque o FIPS também é a base criptográfica global de fato.

A conformidade com o FIPS não precisa ser difícil, mas exige que tanto seu sistema operacional quanto as ferramentas de gerenciamento de tráfego relevantes possam operar no modo FIPS. Há um equívoco comum de que a conformidade com o FIPS é alcançada simplesmente executando o sistema operacional no modo FIPS. Mesmo com o sistema operacional no modo FIPS, ainda é possível que os clientes que se comunicam com seu controlador Ingress não estejam usando uma cifra forte. Ao operar no modo FIPS, seu sistema operacional e o controlador Ingress podem usar apenas um subconjunto das cifras SSL/TLS típicas.

A configuração do FIPS para suas implantações do Kubernetes é um processo de quatro etapas:

• Passo 1: Configure seu sistema operacional para o modo FIPS
• Passo 2: Verifique se o sistema operacional e o OpenSSL estão no modo FIPS
• Etapa 3: Instalar o controlador Ingress
• Passo 4: Verifique a conformidade com o FIPS 140-2 executando uma verificação de status do FIPS

No exemplo abaixo, quando o modo FIPS está habilitado para o sistema operacional e a implementação OpenSSL usada pelo NGINX Plus, todo o tráfego do usuário final de e para o NGINX Plus é descriptografado e criptografado usando um mecanismo de criptografia validado e habilitado para FIPS.

Leia mais sobre FIPS em Como obter conformidade com FIPS com NGINX Plus .

Torne o Kubernetes mais seguro com o NGINX

Se você estiver pronto para implementar alguns (ou todos) desses métodos de segurança, precisará garantir que suas ferramentas tenham os recursos e capacidades corretos para dar suporte aos seus casos de uso. O NGINX pode ajudar com nosso conjunto de ferramentas de gerenciamento de tráfego do Kubernetes prontas para produção:

• NGINX Ingress Controller – Controlador Ingress baseado em NGINX Plus para Kubernetes que lida com controle e modelagem de tráfego avançados, monitoramento e visibilidade, autenticação e SSO, e atua como um gateway de API.

• F5 NGINX App Protect – Proteção holística para aplicativos e APIs modernos, desenvolvida com base nas tecnologias de segurança líderes de mercado da F5, que se integra ao NGINX Ingress Controller e ao NGINX Plus. Use uma abordagem modular para flexibilidade em cenários de implantação e utilização ideal de recursos:

  • NGINX App Protect WAF – Um WAF forte e leve que protege contra OWASP Top 10 e além com conformidade com PCI DDS.

  • NGINX App Protect DoS – Detecção e mitigação de DoS comportamental com proteção consistente e adaptável em nuvens e arquiteturas.

• F5 NGINX Service Mesh – Malha de serviço leve, pronta para uso e fácil de usar para desenvolvedores, apresentando o NGINX Plus como um sidecar empresarial.

Comece solicitando sua avaliação gratuita de 30 dias do NGINX Ingress Controller com o NGINX App Protect WAF e DoS e baixe o NGINX Service Mesh, sempre gratuito.