Discutimos como as configurações incorretas comuns da nuvem podem levar a problemas de cibersegurança – usando dois temas clássicos que todo mundo ama – e como mitigá-los.

Agora, mais do que nunca, a nuvem é um tema relevante. Por causa da pandemia ou não, empresas, escolas e outras organizações se mudaram para a Internet e, consequentemente, muitos departamentos de TI tiveram que lidar com a transição para a nuvem. E mesmo que essa mudança estivesse no roteiro das organizações afetadas, uma adoção tão rápida de tecnologias de cloud pode ter deixado as organizações expostas a riscos provocados pela falta de familiaridade dos clientes com as especificações de suas configurações.

 

Compreendendo o modelo de responsabilidade compartilhada, com pizza

Para entender como uma mudança não planejada para a nuvem pode colocar as organizações em risco, é importante primeiro entender o modelo de responsabilidade compartilhada. Esse modelo foi adotado pelos principais participantes de empresas em nuvem para definir se é o cliente ou o provedor de serviços de nuvem (cloud service provider ou CSP) o responsável por uma tarefa operacional na nuvem.

No passado, era comum que clientes em potencial evitassem o uso de serviços em nuvem por medo de não saber onde seus dados residiriam e se estariam seguros. Mais recentemente, no entanto, muitas organizações acreditam que a nuvem é completamente segura e que não teriam qualquer responsabilidade com relação à segurança dos dados. Nenhuma das suposições está correta.

A responsabilidade da computação em nuvem é quase igual a comer uma pizza: você, o consumidor da pizza, tem vários métodos de consegui-la, conforme ilustrado na Figura 1. Se você não confia no “chefe que habita em você” ou se está muito ocupado, provavelmente irá a um restaurante e comerá por lá, ou simplesmente pedirá para entregar em sua casa. Mas se você prefere uma pizza personalizada, feita com a receita de sua família, não se importará de se dar ao trabalho de fazer e assar sua própria massa para satisfazer seus desejos.

Figura 1. Uma analogia de pizza (parte superior) para o modelo de responsabilidade compartilhada (parte inferior) usado na computação em nuvem

Você, o cliente do serviço de cloud, também pode ter a computação em nuvem de várias maneiras. Você pode adotar tecnologias de software-as-a-service (SaaS) prontas para uso e depender dos serviços padrão oferecidos (equivalente a comer pizza em um restaurante). Você também pode escolher o modelo de platform-as-a-service (PaaS) ou infrastructure-as-a-service (IaaS) e criar seus próprios serviços em cima dele (entrega em casa ou leve semi-pronta para assar). Ou você pode decidir ter seus serviços totalmente on premises (feita em casa).

CSPs como a Amazon Web Services (AWS) e outros provedores de nuvem fornecem documentação sobre como eles definem a responsabilidade compartilhada e como atendem às necessidades de seus clientes usando o modelo.

 

Noções básicas sobre arquiteturas de nuvem, com Lego

Além de saber que de fato existem responsabilidades do lado do cliente, é importante saber como criar serviços da melhor forma com base em qualquer tipo de computação em nuvem que você escolher usar. E é aí que entra o tópico das arquiteturas de nuvem.

Para tornar mais fácil de entender, agora mudamos nossa analogia para Lego (que é a segunda melhor coisa depois de pizza). Se construir na nuvem é como brincar com peças de Lego, os frameworks de como construir melhor na nuvem — como os fornecidos pela AWS e outros provedores — são semelhantes aos manuais de Lego que vêm com novas caixas de peças. Você pode construir coisas notáveis seguindo as práticas recomendadas, mas pode optar deliberadamente por não segui-las e ainda acabar criando algo ótimo. Se você decidir construir sem um manual, precisa ter em mente que cada tijolo que você escolher para a sua fundação irá influenciar a integridade de toda a construção, mais cedo ou mais tarde, de uma forma ou de outra. Portanto,  é fundamental conhecer cada peça e compreender seus efeitos em cascata — e o mesmo é válido para arquiteturas em nuvem.

 

Configurações incorretas da nuvem

Quando um cliente está usando um dos serviços de seu CSP e acredita que tem uma determinada configuração, mas na verdade não tem, surge uma configuração incorreta da nuvem. Configurações incorretas do cliente, como quando um bucket de armazenamento que deveria ter sido tornado privado e criptografado durante sua criação está, na verdade, público e em texto simples, podem resultar na exposição de dados, entre outras consequências graves.

[Leia: Explorando os perigos mais comuns à segurança em nuvem]

A solução Trend Micro Cloud One™– Conformity executa mais de 490 milhões de verificações de postura de segurança em contas da AWS todos os dias. Isso permite que as organizações obtenham uma visão geral das configurações incorretas de clientes comumente cometidas. Notavelmente, para um número considerável de configurações incorretas, o problema aponta para a falta de criptografia, que é um dos mecanismos de segurança recomendados pelo AWS Well-Architected Framework.

 

Criptografia de volume do Amazon Elastic Block Store

O Amazon Elastic Block Store (EBS) é o serviço de armazenamento em bloco da AWS. A maioria das estruturas e padrões de conformidade exige que as organizações implementem criptografia full-disk em seus discos rígidos, e a AWS também promove essa prática. No entanto, uma porcentagem significativa das detecções de alto risco encontradas pela Trend Micro estavam relacionadas a volumes do Amazon EBS que não são criptografados em repouso.

Os clientes podem estar operando com a suposição de que a AWS criptografa esses volumes por padrão, mas este não é o caso. Felizmente, a AWS torna mais fácil para os clientes criptografar volumes: tudo o que eles precisam fazer é marcar uma caixa de seleção, conforme mostrado na Figura 2. Além disso, a AWS enfatiza que os volumes criptografados têm o mesmo desempenho que os volumes não criptografados.

Figura 2. Habilitando a criptografia para um volume Amazon EBS

 

Criptografia do Amazon Machine Image

O Amazon Machine Image (AMI) funciona como um dispositivo virtual aberto que permite aos clientes girar várias instâncias do Amazon Elastic Compute Cloud (EC2) (“servidores”) com o mesmo sistema operacional, configurações e dados. Ter esses dados criptografados também é uma boa prática. No entanto, uma porcentagem significativa das detecções de alto risco encontradas pela Trend Micro envolveu AMIs não criptografadas. Os clientes podem habilitar a criptografia de AMI com um simples tique de uma caixa de seleção, usando uma interface semelhante àquela para habilitar a criptografia para um volume Amazon EBS.

 

Criptografia de bucket do Amazon Simple Storage Service

O Amazon Simple Storage Service (S3) é um dos serviços mais usados da AWS. Como tal, é também um dos serviços de armazenamento em nuvem frequentemente mencionados quando vazamentos de dados relativos a grandes organizações viram notícia. Isso pode ter resultado na impressão de que o Amazon S3 é um serviço inseguro. No entanto, sob o modelo de responsabilidade compartilhada, a AWS fornece as ferramentas, mas é trabalho da organização garantir que os intervalos sejam configurados corretamente.

É importante observar que, embora cada bucket do Amazon S3 recém-criado seja privado por padrão, ele não é criptografado. Mas criptografar um bucket do Amazon S3 é tão fácil quanto selecionar o botão de opção correspondente ao método de criptografia preferido, conforme mostrado na Figura 3.

Figura 3. Habilitando a criptografia para um bucket do Amazon S3

 

Criptografia de tópicos do Amazon Simple Notification Service

O Amazon Simple Notification Service (SNS) é um serviço central para design nativo da nuvem. Este serviço de mensagens gerenciadas permite a comunicação serviço a serviço, desacoplando aplicações monolíticas e permitindo a adoção de uma arquitetura de microsserviços. Na maioria das vezes, os dados confidenciais são transferidos por meio desse serviço. Mas se agentes mal-intencionados obtiverem acesso aos dados em trânsito ou em repouso, eles não conseguiriam entender se a criptografia estivesse ativada.

O Amazon SNS fornece criptografia em trânsito por padrão, mas a criptografia em repouso do lado do servidor para um tópico é opcional e está desabilitada por padrão. No entanto, habilitar a criptografia para um tópico pode ser feito facilmente com um clique no botão de opção correspondente, conforme mostrado na Figura 4.

Figura 4. Habilitando a criptografia para um tópico do Amazon SNS

 

Tendo a fatia e os tijolos em mente

Para muitas organizações agora, mais do que nunca, a migração de workloads para a nuvem é uma promessa e uma oportunidade. No entanto, elas devem entender o que é exigido delas por sua fatia da torta de responsabilidade compartilhada, por assim dizer, que é adotada por seus CSPs. Da mesma forma, as organizações devem compreender as melhores práticas e as recomendações estabelecidas nas estruturas de seus CSPs, a fim de construir adequadamente por cima de seus tijolos de base. Fazer ambos as ajudará a evitar configurações incorretas da nuvem e as consequências que vêm com essas lacunas de segurança.

Assista: [Cloud misconfiguration causes breaches – how to avoid it]

 

Soluções Trend Micro

A solução Trend Micro Cloud One™ – Conformity fornece segurança, conformidade e governança contínuas em uma plataforma SaaS, projetada para ajudar as organizações a gerenciar configurações incorretas de recursos de nuvem em um ambiente multicloud, ajudando os criadores de nuvem a ter a confiança de que sua infraestrutura cloud está configurada e compatível para expandir e expandir seus negócios. O Conformity faz parte da Trend Micro Cloud One™, uma plataforma de serviços de segurança para organizações que desenvolvem em nuvem. Ela oferece segurança multifuncional flexível e escalonável que ajuda os engenheiros de DevOps a construir e inovar com segurança à medida que migram e constroem em nuvem.