Serviços de nuvem nativos se tornaram cada vez mais populares no espaço de desenvolvimento de software, oferecendo funcionalidades cada vez mais inovadoras para resolver problemas que outrora exigiam recursos significativos no desenvolvimento de software tradicional. Há centenas de serviços nativo em nuvem disponíveis hoje em dia para ajudar os desenvolvedores a reduzir suas cargas de trabalho, inclusive na segurança web. Por exemplo, os serviços de armazenamento de objetos tornam fácil o salvamento de arquivos e outros dados.
Com a dependência crescente dos softwares em serviços de nuvem, o termo “nativo na nuvem” foi criado. Nativo na nuvem se refere a softwares construídos ao redor da computação na nuvem e então se beneficiando das funcionalidades da nuvem como escalabilidade e vários serviços de implementação, nativamente.
A Fundação de Computação Nativa na Nuvem (CNCF na sigla em inglês) é a casa de diversas ferramentas open-source e de fabricantes de softwares e ferramentas neutras que podem ser usadas de forma inovadora em qualquer plataforma de nuvem pública. Isso significa que com algumas pequenas alterações nas suas configurações, você pode executar essas ferramentas em qualquer uma das principais plataformas de nuvem, seja AWS, Azure, Google Cloud Platform (GCP), Digital Ocean ou outras.
O CNCF essencialmente combina os conceitos de nativo na nuvem e da nuvem agnóstica, oferecendo ferramentas que podem ser usadas entre os fabricantes de nuvem e que tem integrações próximas com o que a nuvem oferece. Logo, os usuários não são dependentes de um único fabricante e podem facilmente trocar de provedor de nuvem sem afetar a compatibilidade da ferramenta.
Claro, junto com os benefícios, a nuvem vem com alguns riscos. O principal deles é a segurança.
Neste artigo, discutiremos como o movimento de nativo na nuvem (especialmente como apresentado pelo CNCF) mudou o panorama do desenvolvedor e como isso impacta as necessidades de segurança na web.
As vantagens do desenvolvimento movido pela CNCF ao invés do desenvolvimento de software tradicional
Há diversos benefícios da computação na nuvem. Diversas tarefas de implementação e gerenciamento que eram previamente manuseadas por desenvolvedores agora estão se tornando responsabilidade dos fabricantes da nuvem.
Por exemplo, você pode usar o database-as-a-service sem ter que se preocupar com os servidores do banco de dados ou lidar com a complexidade que envolve tolerância a falhas, replicação, entre outras. Similarmente, usar o cache-as-a-service significa que você não precisa lidar com servidores de cache. Esses serviços geralmente são fáceis de se usar, na maior parte do tempo, tudo o que precisa ser feito é alimentar as suas aplicações com as credenciais apropriadas e deixar o serviço fazer o resto.
De forma parecida, quando se trata da camada de infraestrutura, deixar a implementação para os fabricantes da nuvem tornou mais fácil as vidas dos desenvolvedores ao lidar com algumas de suas responsabilidades. Em troca, isso levou a um desenvolvimento e uma entrega mais rápida.
Os desenvolvedores que adotaram (parcialmente ou por completo) o ecossistema Open Source da CNCF têm ainda mais benefícios. Diversas ferramentas CNCF são maduras e poderosas e oferecem diversas funcionalidades para pronta utilização. Os desenvolvedores não tem mais que alocar os seus esforços em implementar essas capacidades, podendo assim focar em outras coisas.
Por exemplo, uma ferramenta como o Envoy economiza bastante tempo e esforço ao eliminar a necessidade de lidar com tolerância a falhas, limitação de taxa, terminação TLS, etc. O Envoy implementa todas essas funcionalidades, logo, a sua aplicação não precisa fazê-la. Enquanto isso, uma ferramenta como o Prometheus permite que você consiga métricas de aplicações e utilize-as para uma melhor visibilidade.
Há um aumento na tendência de utilização de ferramentas como o Kubernetes, service meshes, Fluentd, FluxCD e o Prometheus na camada de infraestrutura, abstraindo as tarefas de gerenciamento de instância de aplicação dos desenvolvedores. Ferramentas como o containerd oferecem uma forma confiável de criar e executar containers no Kubernetes. Eles também permitem que os desenvolvedores lancem toda a sua aplicação como uma imagem na camada de infraestrutura.
A conteinerização permite o movimento nativo da nuvem em grande estilo. Com apenas algumas alterações básicas nas configurações, a conteinerização permite que você execute o mesmo software sem ter que fazer alterações no código em qualquer serviço de nuvem como EKS, ECS, AKS e o GKE. Os desenvolvedores nem precisam mais pensar em qual nuvem a sua aplicação será executada.
Todas essas tendências combinadas apoiaram uma outra: a popularidade crescente dos microsserviços. Graças a abstração de infraestrutura, ferramentas open source poderosas e outras vantagens inerentes do desenvolvimento nativo em nuvem, os desenvolvedores ficam livres para focar apenas na lógica do negócio e podem implementar uma variedade de pequenos serviços focados nele.
Nativo em Nuvem, Arquitetura e a segurança
Enquanto a computação nativa na nuvem oferece vários benefícios, ela também cria alguns desafios. Especialmente para a segurança web. Nós discutiremos dois aspectos disso: O desafio de manter os containers seguros e proteger as arquiteturas microsserviços de atacantes.
Mantendo os containers seguros
Em modelos tradicionais, a segurança web depende principalmente de firewalls e da proteção dos servidores. Entretanto, com os modelos modernos de conteinerização, lidando com alterações no firewall, de melhoria da segurança dos servidores, políticas de rede, ACLs, entre outras, fica cada vez mais difícil realizar a proteção dos containers.
As melhorias de segurança no servidor podem ser atingidas através de alterações nas imagens do container e da implementação do cluster. Por exemplo, ao iniciar o seu cluster Kubernetes, você pode seguir o CIS Benchmark para o kubernetes. Já a rede, é um componente em contínuo movimento com a introdução de novos serviços e implementação de novos pods enquanto pods antigos deixam de ser utilizados.
Claro, é normal para os pods ou VMs deixarem de ser utilizados na nuvem ou no Kubernetes. Isso significa que é necessário implementar a segurança de alguma forma para que qualquer alteração nas suas regras de segurança possam persistir no novo pod ou VM.
Se as alterações de um web firewall application podem ser implementadas via comandos, por que isso não pode ser feito nos containers? Os containers são entidades que param de funcionar frequentemente, então executar comandos de segurança não funcionará. Você deve garantir que as alterações que você fará sejam implementadas nas imagens dos containers. Ou, você deve encontrar alguma forma de implementar essas alterações usando os métodos de implementação nativos do Kubernetes, como init containers ou operadores.
Para manter os containers seguros, o método moderno de implementar as regras envolve executar comandos na sua inicialização. Isso se torna complicado para os desenvolvedores já que o container final deve ser enviado da equipe de segurança. Seria necessário injetar essas regras nos containers durante a sua execução.
Mantendo a arquitetura dos microsserviços segura
Diversas arquiteturas modernas dependem de microsserviços que falam uns com os outros e formam um sistema coerente juntos. Entretanto, um grande número de microsserviços interagindo cria uma superfície de ataque ampla e complicada que pode ser difícil de manter segura.
Tipicamente, vários desses microsserviços estão virados para a Internet e isso cria diversos problemas:
- Ao invés de ter um perímetro fechado e defensível, muito da infraestrutura “interior” do sistema é exposta a potenciais atacantes.
- Além disso, muito da exposição consiste em endpoints de API. Isso torna a segurança mais difícil porque a maioria das soluções de segurança dependem de tecnologias legado (como o reCAPTCHA) que não podem ser usadas para filtrar chamadas de API hostis.
- O potencial grande número de APIs que podem tornar a criação de políticas de segurança e de conjuntos de regras desafiadoras que permitam todas as permutações da utilização legítima enquanto bloqueia todas as formas de tráfego malicioso.
- Práticas modernas de CI/CD normalmente resultam nas APIs evoluindo rapidamente, tornando novamente difícil de criar e manter políticas de segurança robustas.
- A administração em geral pode se tornar bem complicada ao lidar com microsserviços. Já que cada um é uma entidade separada, podendo ser entediante incluir em uma whitelist cada serviço, por exemplo.
Como se isso já não fosse o suficiente, as arquiteturas de microsserviços nem sempre respondem a ataques da mesma forma que as aplicações. Por exemplo, ataques de DDoS podem causar estragos, especialmente quando as requisições de entrada engatilham outros intra serviços de comunicação, que amplificam os efeitos dos ataques.
Resolvendo os desafios
Nós vemos que o desenvolvimento nativo na nuvem oferece um grande número de benefícios. Não é uma surpresa que diversas organizações estão fazendo parte do ecossistema CNCF.
Há sempre um meio de melhorar as aplicações desenvolvidas, e quando se trata de aplicações web, APIs, microsserviços, o Reblaze é a melhor opção.
Desde a sua criação, a Reblaze usou uma abordagem multicamada para a segurança da Web, submetendo as fontes de tráfego a várias formas de verificação. Estes incluem atualmente:
- Filtragem de conteúdo e detecção de assinatura (disponível através do WAF de última geração da Reblaze)
- Bloqueio de fontes de tráfego que enviam grandes volumes de solicitações (Proteção DDoS)
- Bloqueio de fontes de tráfego que enviam volumes de solicitações menores, mas ainda anômalos (limitação de taxa)
- Bloqueando fontes de tráfego indesejáveis que não são humanas (Gerenciamento de Bots)
- Proibição de solicitantes que exibem padrões de atividade hostis (por exemplo, prevenção de account Takeover)
- Usando técnicas especializadas adicionais para tráfego de API (segurança de API)
- Detectar e bloquear fontes de tráfego maliciosas com base em suas ações (Machine Learning e Análise Comportamental)
