Como a nuvem transforma a segurança de TI em segurança de aplicações

A computação em nuvem representa, sem dúvida, uma mudança sísmica no mundo da tecnologia, abrindo caminho para níveis inéditos de eficiência e inovação. No entanto, ela também provocou outra mudança importante, que nem sempre é discutida: a nuvem tornou a infraestrutura parte da aplicação.

Essa mudança tem implicações significativas para a forma como praticamos segurança. Em geral, as ferramentas e práticas de segurança atuais são projetadas para as equipes centrais de TI e segurança e desenvolvidas para atender às habilidades e aos ambientes dessas equipes. Em aplicações na nuvem, são os desenvolvedores, e não a TI, que tomam decisões sobre acesso à rede, aplicação de patches no sistema operacional, permissões de acesso e muito mais. Essas decisões são tomadas individualmente para cada aplicação, e não de forma centralizada. Além disso, são tomadas continuamente durante o processo de desenvolvimento, e não em etapas específicas de revisão.

Ainda assim, as implicações dessas decisões para a segurança não mudam. Uma porta aberta pode comprometer uma VPC na nuvem, assim como poderia comprometer um segmento de rede de um data center. Um contêiner sem patches pode ser invadido, assim como uma máquina física. Os mesmos riscos se aplicam e, muitas vezes, são ampliados pelo escopo da aplicação.

Por isso, precisamos repensar como lidar com essas ameaças, agora levando em conta o contexto das aplicações — com equipes, processos e habilidades diferentes. Neste artigo, explico como o escopo das aplicações se expandiu para incluir a infraestrutura e analiso as implicações disso para a segurança. Acredito que essa perspectiva pode ajudar você a definir suas práticas de segurança, escolher suas ferramentas e organizar suas equipes.

Nota de estilo: uso a palavra “nuvem” para representar não apenas a computação em nuvem, mas também contêineres, serverless e muitas tecnologias que vieram depois. Também falo sobre o período “antes e depois” da nuvem, embora, na prática, poucas empresas estejam em uma fase intermediária dessa jornada. Essa visão simplificada é intencional: ajuda a mostrar o panorama geral — sei muito bem que este é um tema complexo!

Aplicações na era pré-nuvem

Antes da nuvem, as aplicações eram construídas sobre uma robusta infraestrutura de TI. Vou me referir a esse período no passado, embora, na prática, a maioria das empresas ainda opere principalmente dessa maneira.

As empresas tinham um data center, onde a equipe central de TI gerenciava cuidadosamente a capacidade e alocava recursos. Era preciso administrar o espaço nos racks, comprar servidores e colocá-los em operação, lidar com falhas de hardware e controlar quem usava cada servidor. Se uma aplicação precisasse de um servidor, era necessário preencher documentos e obter aprovação, pois adicionar outro servidor significava gastar mais dinheiro ou deixar de disponibilizá-lo para outra pessoa.

Com a chegada da virtualização, surgiu outra camada de TI, geralmente o vSphere, para gerenciar máquinas virtuais sobre as máquinas físicas. Isso aumentou a eficiência, mas não mudou o processo fundamental: a capacidade continuava limitada e compartilhada. Para conseguir um servidor, era preciso abrir um chamado, e uma equipe central de TI precisava gerenciar tanto a capacidade dos servidores quanto a camada de virtualização.

Além dos servidores, a TI também gerenciava as redes. Elas eram configuradas com switches e roteadores físicos, e o foco não era tanto a capacidade, mas os controles de acesso: quais usuários podiam acessar a rede e quais redes podiam se conectar entre si. As redes costumam ser complexas — por isso, mais uma vez, a equipe central de TI tinha um papel fundamental: gerenciava permissões de comunicação complexas em todo o data center e também alocava a largura de banda.

Além do hardware, a TI também gerenciava recursos centralizados. Um exemplo eram as imagens padrão das máquinas virtuais. Essas VMs padrão continham softwares aprovados, avaliados quanto à conformidade legal, à segurança e à qualidade geral. A equipe central de TI também monitorava essas VMs e as atualizava para corrigir vulnerabilidades ou acompanhar mudanças nas políticas corporativas. As aplicações eram instaladas nessas VMs, muitas vezes manualmente, e reiniciadas quando necessário para acomodar as atualizações. 

Os serviços gerenciados eram outro exemplo de recurso centralizado. Por exemplo, a equipe de TI podia gerenciar um grande banco de dados Oracle central, necessário para o funcionamento das aplicações. Um ou mais DBAs (administradores de banco de dados) gerenciavam índices e tabelas, trabalhando com diferentes equipes de aplicação conforme necessário para ajustá-los às suas necessidades.

No topo de tudo isso estava a própria aplicação. As aplicações eram compostas por código e bibliotecas e precisavam ser implantadas em ambientes muito específicos para funcionar. Qualquer mudança no hardware, nas VMs base, no uso do banco de dados, na CDN ou em qualquer outro aspecto exigia a abertura de um chamado e uma espera.

Naquela época, isso fazia sentido porque os recursos eram limitados e precisavam ser compartilhados. Adicionar capacidade física — fosse de servidores, rede ou armazenamento — exigia muito tempo e dinheiro. Implementar ou ampliar uma aplicação central exigia um esforço considerável da equipe central de TI, outro recurso compartilhado cuja capacidade crescia de forma lenta e cara. Assim, se uma aplicação recebesse uma fatia maior, outra ficava com menos — um jogo de soma zero.

Aplicações na era pós-nuvem

Então, a nuvem chegou e eliminou essas limitações.

A capacidade de hardware deixou de ser um problema. Os desenvolvedores só precisam ter acesso a uma conta na nuvem para provisionar quantos servidores o orçamento permitir. Esses servidores aumentam e diminuem de forma elástica, com controles de autoatendimento e gerenciados por software, sem qualquer envolvimento da equipe central de TI.

As redes deixaram de ser dependentes umas das outras. As equipes de aplicação podem criar sua própria nuvem privada virtual (VPC), que a plataforma de nuvem mantém separada do restante. O acesso a essas redes é configurado de forma granular, de acordo com as necessidades da aplicação, e pode ser gerenciado inteiramente por software, em autoatendimento.

As VMs na nuvem são menos gerenciadas de forma centralizada do que suas antecessoras nos data centers, mas os contêineres romperam de vez esse vínculo. As instruções para criar contêineres geralmente são definidas em um repositório de código-fonte e compiladas junto com a aplicação, o que dificulta a visibilidade da equipe central de TI e, na prática, torna impossível aplicar patches neles. Até as “imagens padrão” gerenciadas centralmente perdem o apelo, pois os patches nessas imagens só se aplicam depois que uma aplicação é recompilada, e os desenvolvedores dependem cada vez mais de imagens base externas.

Aplicações centralizadas deram lugar a serviços fáceis de usar, integrados à plataforma de nuvem, como bancos de dados, autenticação, mensageria e muitos outros. Ao contrário da maioria das aplicações centralizadas, esses serviços são orientados por API e projetados para que as equipes de desenvolvimento possam provisioná-los e consumi-los por conta própria. Contêineres empacotados substituíram aplicações menores e podem ser facilmente obtidos no Docker Hub, tornando-se apenas mais um microsserviço na arquitetura da aplicação. Em ambos os casos, não há mais necessidade de abrir um chamado e esperar que a equipe de TI, com recursos limitados, provisione o que a aplicação precisa.

Por fim, surgiram as equipes de DevOps (às vezes chamadas de SRE ou Platform), que substituíram a TI central por equipes de operações alinhadas. Essas equipes não tentam controlar a infraestrutura usada pelas aplicações. Em vez disso, fornecem ferramentas e serviços, como o Kubernetes, para que os desenvolvedores operem de forma independente as camadas de infraestrutura integradas às suas aplicações.

Protegendo a infraestrutura como parte da aplicação

Com o tempo, a nuvem elimina a necessidade de grande parte da infraestrutura gerenciada centralmente. Em vez disso, essa infraestrutura passa a fazer parte da própria aplicação. Essa tendência deve continuar, à medida que CDNs, gateways de API, middleware e outros componentes se tornam parte da aplicação, aumentando a autonomia e a velocidade da equipe de desenvolvimento. Essa mudança começou na nuvem pública, mas, na prática, também se estendeu à nuvem privada, que adotou as mesmas práticas.

As preocupações com segurança, porém, não desapareceram.

Um contêiner sem patches pode ser invadido com a mesma facilidade que uma VM ou máquina física sem manutenção. Uma porta aberta sem necessidade pode dar acesso a um invasor a dados confidenciais, independentemente de onde estejam hospedados; e dados não criptografados no banco de dados podem ser comprometidos muito rapidamente, especialmente quando armazenados em um serviço compartilhado. Os mesmos vetores de ataque continuam existindo, e devemos ficar atentos a essas questões de segurança e tomar medidas para proteger nossas aplicações.

O que precisa mudar é como nos defendemos contra essas ameaças à infraestrutura.As soluções e práticas atuais foram projetadas para equipes centrais de TI, não para equipes de aplicação independentes. Às vezes, elas são adaptadas para que equipes separadas possam usá-las, mas é raro que realmente atendam a esse caso de uso.

Precisamos adotar uma nova perspectiva, baseada nessa nova realidade da “infraestrutura como parte da aplicação”. Repensar tudo isso é uma tarefa grande, que não dá para resumir em alguns tópicos simples, mas aqui estão algumas mudanças que vale considerar:

• Repense a estrutura da sua área de segurança para proteger produtos na nuvem. A segurança de ambientes de TI foi concebida para trabalhar em parceria com a estrutura organizacional de TI, mas a segurança de aplicações deve ser estruturada para trabalhar com a área de desenvolvimento. Tenho muito mais a dizer sobre esse tema, mas provavelmente vou deixar para outro artigo…

• Entenda as necessidades dos desenvolvedores de aplicações. Dedique tempo para compreender a realidade deles, não apenas a tecnologia que usam, e adapte suas práticas, ferramentas e expectativas para atender a essas necessidades. As melhores práticas do setor muitas vezes se baseiam nas necessidades da TI, não do desenvolvimento, então não confie nelas sem avaliar se fazem sentido.

• Não presuma que suas soluções anteriores à nuvem são adequadas para aplicações na nuvem. Embora seja conveniente usar as mesmas ferramentas nas suas pilhas antigas e novas, é improvável que elas atendam bem a essas duas realidades. Confira outras ferramentas que seu fornecedor oferece — ou as opções de outros fornecedores — e escolha a mais adequada para o ambiente de nuvem.

• Invista em ferramentas de segurança flexíveis, orientadas por API e com autoatendimento. As equipes de TI são uma função central, o que permite investir mais tempo em integrações personalizadas. As equipes e pilhas de desenvolvimento variam muito mais. Invista em ferramentas que se adaptem a diferentes ambientes e, ao mesmo tempo, ofereçam controles de segurança e governança consistentes.

Essa transição não vai acontecer da noite para o dia. Daqui a uma década, as aplicações pré-nuvem serão consideradas legadas, assim como os ambientes de mainframe de hoje, com seus controles de segurança ultrapassados. Este é o momento de começar a construir uma nova geração de segurança.