{"id":2206,"date":"2022-06-10T11:41:11","date_gmt":"2022-06-10T14:41:11","guid":{"rendered":"https:\/\/aiqon.com.br\/blog\/?p=2206"},"modified":"2022-06-10T11:41:11","modified_gmt":"2022-06-10T14:41:11","slug":"seguranca-web-nativo-em-nuvem-beneficios-e-desafios","status":"publish","type":"post","link":"https:\/\/aiqon.com.br\/blog\/seguranca-web-nativo-em-nuvem-beneficios-e-desafios\/","title":{"rendered":"Seguran\u00e7a Web Nativo em Nuvem: Benef\u00edcios e Desafios"},"content":{"rendered":"
<\/div>

Servi\u00e7os de nuvem nativos se tornaram cada vez mais populares no espa\u00e7o de desenvolvimento de software, oferecendo funcionalidades cada vez mais inovadoras para resolver problemas que outrora exigiam recursos significativos no desenvolvimento de software tradicional. H\u00e1 centenas de servi\u00e7os nativo em nuvem dispon\u00edveis hoje em dia para ajudar os desenvolvedores a reduzir suas cargas de trabalho, inclusive na seguran\u00e7a web. Por exemplo, os servi\u00e7os de armazenamento de objetos tornam f\u00e1cil o salvamento de arquivos e outros dados.<\/span><\/p>\n

Com a depend\u00eancia crescente dos softwares em servi\u00e7os de nuvem, o termo \u201cnativo na nuvem\u201d foi criado. Nativo na nuvem se refere a softwares constru\u00eddos ao redor da computa\u00e7\u00e3o na nuvem e ent\u00e3o se beneficiando das funcionalidades da nuvem como escalabilidade e v\u00e1rios servi\u00e7os de implementa\u00e7\u00e3o, nativamente.<\/span><\/p>\n

A Funda\u00e7\u00e3o de Computa\u00e7\u00e3o Nativa na Nuvem <\/a>(CNCF na sigla em ingl\u00eas)<\/em> \u00e9 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\u00fablica. Isso significa que com algumas pequenas altera\u00e7\u00f5es nas suas configura\u00e7\u00f5es, voc\u00ea pode executar essas ferramentas em qualquer uma das principais plataformas de nuvem, seja AWS<\/a>, Azure<\/a>, Google Cloud Platform (GCP)<\/a>, Digital Ocean<\/strong> ou outras.<\/span><\/p>\n

\"prote\u00e7\u00e3o<\/a><\/p>\n

O CNCF essencialmente combina os conceitos de nativo na nuvem e da nuvem agn\u00f3stica, oferecendo ferramentas que podem ser usadas entre os fabricantes de nuvem e que tem integra\u00e7\u00f5es pr\u00f3ximas com o que a nuvem oferece. Logo, os usu\u00e1rios n\u00e3o s\u00e3o dependentes de um \u00fanico fabricante e podem facilmente trocar de provedor de nuvem sem afetar a compatibilidade da ferramenta.<\/span><\/p>\n

Claro, junto com os benef\u00edcios, a nuvem vem com alguns riscos. O principal deles \u00e9 a seguran\u00e7a.<\/span><\/p>\n

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\u00e7a na web.<\/span><\/p>\n

As vantagens do desenvolvimento movido pela CNCF ao inv\u00e9s do desenvolvimento de software tradicional<\/span><\/h2>\n

H\u00e1 diversos benef\u00edcios da computa\u00e7\u00e3o na nuvem. Diversas tarefas de implementa\u00e7\u00e3o e gerenciamento que eram previamente manuseadas por desenvolvedores agora est\u00e3o se tornando responsabilidade dos fabricantes da nuvem.<\/span><\/p>\n

Por exemplo, voc\u00ea 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\u00e2ncia a falhas, replica\u00e7\u00e3o, entre outras. Similarmente, usar o cache-as-a-service significa que voc\u00ea n\u00e3o precisa lidar com servidores de cache. Esses servi\u00e7os geralmente s\u00e3o f\u00e1ceis de se usar, na maior parte do tempo, tudo o que precisa ser feito \u00e9 alimentar as suas aplica\u00e7\u00f5es com as credenciais apropriadas e deixar o servi\u00e7o fazer o resto.<\/span><\/p>\n

De forma parecida, quando se trata da camada de infraestrutura, deixar a implementa\u00e7\u00e3o para os fabricantes da nuvem tornou mais f\u00e1cil as vidas dos desenvolvedores ao lidar com algumas de suas responsabilidades. Em troca, isso levou a um desenvolvimento e uma entrega mais r\u00e1pida.<\/span><\/p>\n

Os desenvolvedores que adotaram (parcialmente ou por completo) o ecossistema Open Source da CNCF t\u00eam ainda mais benef\u00edcios. Diversas ferramentas CNCF s\u00e3o maduras e poderosas e oferecem diversas funcionalidades para pronta utiliza\u00e7\u00e3o. Os desenvolvedores n\u00e3o tem mais que alocar os seus esfor\u00e7os em implementar essas capacidades, podendo assim focar em outras coisas.<\/span><\/p>\n

Por exemplo, uma ferramenta como o Envoy economiza bastante tempo e esfor\u00e7o ao eliminar a necessidade de lidar com toler\u00e2ncia a falhas, limita\u00e7\u00e3o de taxa, termina\u00e7\u00e3o TLS, etc. O Envoy implementa todas essas funcionalidades, logo, a sua aplica\u00e7\u00e3o n\u00e3o precisa faz\u00ea-la. Enquanto isso, uma ferramenta como o Prometheus permite que voc\u00ea consiga m\u00e9tricas de aplica\u00e7\u00f5es e utilize-as para uma melhor visibilidade.<\/span><\/p>\n

H\u00e1 um aumento na tend\u00eancia de utiliza\u00e7\u00e3o de ferramentas como o Kubernetes, service meshes, Fluentd, FluxCD e o Prometheus na camada de infraestrutura, abstraindo as tarefas de gerenciamento de inst\u00e2ncia de aplica\u00e7\u00e3o dos desenvolvedores. Ferramentas como o containerd oferecem uma forma confi\u00e1vel de criar e executar containers no Kubernetes. Eles tamb\u00e9m permitem que os desenvolvedores lancem toda a sua aplica\u00e7\u00e3o como uma imagem na camada de infraestrutura.<\/span><\/p>\n

A conteineriza\u00e7\u00e3o permite o movimento nativo da nuvem em grande estilo. Com apenas algumas altera\u00e7\u00f5es b\u00e1sicas nas configura\u00e7\u00f5es, a conteineriza\u00e7\u00e3o permite que voc\u00ea execute o mesmo software sem ter que fazer altera\u00e7\u00f5es no c\u00f3digo em qualquer servi\u00e7o de nuvem como EKS, ECS, AKS e o GKE. Os desenvolvedores nem precisam mais pensar em qual nuvem a sua aplica\u00e7\u00e3o ser\u00e1 executada.<\/span><\/p>\n

Todas essas tend\u00eancias combinadas apoiaram uma outra: a popularidade crescente dos microsservi\u00e7os. Gra\u00e7as a abstra\u00e7\u00e3o de infraestrutura, ferramentas open source<\/a> poderosas e outras vantagens inerentes do desenvolvimento nativo em nuvem, os desenvolvedores ficam livres para focar apenas na l\u00f3gica do neg\u00f3cio e podem implementar uma variedade de pequenos servi\u00e7os focados nele.<\/span><\/p>\n

Nativo em Nuvem, Arquitetura e a seguran\u00e7a<\/span><\/h2>\n

Enquanto a computa\u00e7\u00e3o nativa na nuvem oferece v\u00e1rios benef\u00edcios, ela tamb\u00e9m cria alguns desafios. Especialmente para a seguran\u00e7a web. N\u00f3s discutiremos dois aspectos disso: O desafio de manter os containers seguros e proteger as arquiteturas microsservi\u00e7os de atacantes.<\/span><\/p>\n

Mantendo os containers seguros<\/span><\/h3>\n

Em modelos tradicionais, a seguran\u00e7a web depende principalmente de firewalls e da prote\u00e7\u00e3o dos servidores. Entretanto, com os modelos modernos de conteineriza\u00e7\u00e3o, lidando com altera\u00e7\u00f5es no firewall, de melhoria da seguran\u00e7a dos servidores, pol\u00edticas de rede, ACLs, entre outras, fica cada vez mais dif\u00edcil realizar a prote\u00e7\u00e3o dos containers.<\/span><\/p>\n

As melhorias de seguran\u00e7a no servidor podem ser atingidas atrav\u00e9s de altera\u00e7\u00f5es nas imagens do container e da implementa\u00e7\u00e3o do cluster. Por exemplo, ao iniciar o seu cluster Kubernetes, voc\u00ea pode seguir o CIS Benchmark para o kubernetes<\/a>. J\u00e1 a rede, \u00e9 um componente em cont\u00ednuo movimento com a introdu\u00e7\u00e3o de novos servi\u00e7os e implementa\u00e7\u00e3o de novos pods enquanto pods antigos deixam de ser utilizados.<\/span><\/p>\n

Claro, \u00e9 normal para os pods ou VMs deixarem de ser utilizados na nuvem ou no Kubernetes. Isso significa que \u00e9 necess\u00e1rio implementar a seguran\u00e7a de alguma forma para que qualquer altera\u00e7\u00e3o nas suas regras de seguran\u00e7a possam persistir no novo pod ou VM.<\/span><\/p>\n

Se as altera\u00e7\u00f5es de um web firewall application<\/a> podem ser implementadas via comandos, por que isso n\u00e3o pode ser feito nos containers? Os containers s\u00e3o entidades que param de funcionar frequentemente, ent\u00e3o executar comandos de seguran\u00e7a n\u00e3o funcionar\u00e1. Voc\u00ea deve garantir que as altera\u00e7\u00f5es que voc\u00ea far\u00e1 sejam implementadas nas imagens dos containers. Ou, voc\u00ea deve encontrar alguma forma de implementar essas altera\u00e7\u00f5es usando os m\u00e9todos de implementa\u00e7\u00e3o nativos do Kubernetes, como init containers ou operadores.<\/span><\/p>\n

Para manter os containers seguros, o m\u00e9todo moderno de implementar as regras envolve executar comandos na sua inicializa\u00e7\u00e3o. Isso se torna complicado para os desenvolvedores j\u00e1 que o container final deve ser enviado da equipe de seguran\u00e7a. Seria necess\u00e1rio injetar essas regras nos containers durante a sua execu\u00e7\u00e3o.<\/span><\/p>\n

Mantendo a arquitetura dos microsservi\u00e7os segura<\/span><\/h3>\n

Diversas arquiteturas modernas dependem de microsservi\u00e7os que falam uns com os outros e formam um sistema coerente juntos. Entretanto, um grande n\u00famero de microsservi\u00e7os interagindo cria uma superf\u00edcie de ataque ampla e complicada que pode ser dif\u00edcil de manter segura.<\/span><\/p>\n

Tipicamente, v\u00e1rios desses microsservi\u00e7os est\u00e3o virados para a Internet e isso cria diversos problemas:<\/span><\/p>\n