A nuvem (cloud) transformou a computação: em vez de comprar e manter servidores físicos, as organizações alugam infraestrutura de provedores como AWS, Azure e Google Cloud, sob demanda. Isso mudou fundamentalmente a segurança — novos modelos, novos vetores, novos erros comuns. Como a maior parte da infraestrutura moderna vive na nuvem, entender sua segurança é indispensável para o pentest atual. Esta aula cobre os fundamentos: o modelo de responsabilidade compartilhada, os serviços principais, e as falhas mais comuns. A próxima aprofunda a cadeia de ataque emblemática da nuvem. Laboratório com contas gratuitas de provedores, sempre — e com cuidado redobrado de escopo, pois a nuvem tem regras próprias de teste.

A segurança da nuvem e a segurança na nuvem

Comece pelo conceito mais importante e frequentemente mal compreendido: o modelo de responsabilidade compartilhada. Na nuvem, a segurança é dividida entre o provedor e o cliente, e entender essa divisão é fundamental. O provedor (AWS, etc.) é responsável pela segurança da nuvem — a infraestrutura física, o hardware, a virtualização subjacente. O cliente é responsável pela segurança na nuvem — suas configurações, seus dados, seu controle de acesso, suas aplicações. A analogia: o provedor garante que o "prédio" é seguro (estrutura, fechaduras nas portas externas); o cliente é responsável por trancar seu próprio "apartamento" e não deixar as chaves na fechadura. A imensa maioria dos incidentes de segurança em nuvem decorre de falhas do cliente (configurações erradas), não do provedor — que tipicamente tem segurança de infraestrutura robusta. Não entender essa divisão leva a um erro perigoso: assumir que "está na nuvem, então o provedor cuida da segurança", deixando as responsabilidades do cliente negligenciadas.

IaaS, PaaS e SaaS

Entenda os tipos de serviço, porque a divisão de responsabilidade varia com eles. IaaS (Infrastructure as a Service) — você aluga infraestrutura (máquinas virtuais, rede, armazenamento) e gerencia tudo acima dela (o SO, as aplicações); mais controle, mais responsabilidade sua. PaaS (Platform as a Service) — você usa uma plataforma para rodar suas aplicações sem gerenciar o SO; o provedor cuida de mais. SaaS (Software as a Service) — você usa um software pronto (como um e-mail na web); o provedor cuida de quase tudo. Quanto mais "as a Service", mais o provedor gerencia e menos você controla — e a linha de responsabilidade se move. Saber onde suas responsabilidades começam em cada modelo é essencial para não deixar lacunas.

Buckets expostos, a falha número um

Agora as falhas de segurança em nuvem mais comuns, que são o pão com manteiga do pentest de nuvem. A número um, disparado, são as configurações incorretas (misconfigurations) — e o exemplo mais notório são os buckets de armazenamento expostos. Serviços de armazenamento (como o S3 da AWS) permitem guardar dados, e uma configuração errada pode torná-los publicamente acessíveis — incontáveis vazamentos massivos de dados ocorreram porque um bucket com dados sensíveis foi acidentalmente deixado público, acessível a qualquer um na internet. É a "security misconfiguration" (aula OWASP Top 10: o mapa das vulnerabilidades web) na escala da nuvem, e uma das causas mais frequentes de vazamento. Outras falhas comuns: gestão de identidade e acesso (IAM) mal configurada (permissões excessivas), credenciais expostas (chaves de acesso à nuvem vazadas em código, repositórios públicos — um erro devastador e comum), serviços expostos desnecessariamente à internet, falta de criptografia, e logging/monitoramento inadequados.

Credenciais de nuvem que vazam

Um vetor específico e crescente é a exposição de credenciais de nuvem. As chaves de acesso que autenticam à API da nuvem são extremamente poderosas — com elas, um atacante controla os recursos de nuvem da vítima. E essas chaves vazam de formas evitáveis: hardcoded em código enviado ao GitHub (bots varrem repositórios públicos em busca de chaves expostas em minutos), em arquivos de configuração, em buckets expostos. Uma chave de nuvem vazada pode levar ao comprometimento de toda a infraestrutura de nuvem — e ao abuso caro (atacantes usam recursos roubados para minerar criptomoedas, o cryptojacking da aula Tipos de malware: o zoológico do código malicioso, gerando contas enormes para a vítima). A gestão de segredos na nuvem é, por isso, crítica.

Não é o computador de outra pessoa

O ponto conceitual: a nuvem não é "o computador de outra pessoa" com a segurança resolvida — ela redistribui as responsabilidades de segurança e introduz novos tipos de erro. A facilidade de provisionar recursos na nuvem (subir um servidor ou um bucket em segundos) significa também a facilidade de configurá-los mal em segundos, em escala. E a natureza programável e baseada em API da nuvem significa que um erro de configuração ou uma credencial vazada pode expor enormes quantidades de dados ou dar controle sobre vastos recursos instantaneamente. A segurança de nuvem é, em grande parte, a disciplina de configurar corretamente e gerenciar identidades e segredos com rigor — as responsabilidades que recaem sobre o cliente.

IAM com menor privilégio

Do lado defensivo, as práticas de segurança de nuvem: entender e cumprir suas responsabilidades no modelo compartilhado; configurar corretamente (especialmente armazenamento — nunca deixar buckets públicos sem intenção explícita; ferramentas de auditoria de configuração ajudam a detectar exposições); IAM com menor privilégio (a defesa mais importante da nuvem); nunca expor credenciais (gestão de segredos adequada, nunca hardcodar chaves, escanear repositórios em busca de segredos vazados, rotacionar chaves); criptografar dados (em repouso e em trânsito, usando os serviços do provedor); habilitar logging e monitoramento (o CloudTrail da AWS e equivalentes, para visibilidade); e usar as ferramentas de segurança do provedor (que oferecem detecção de configuração incorreta, análise de permissões, alertas). A lição: a nuvem é poderosa e a segurança de sua infraestrutura básica é robusta, mas as responsabilidades do cliente — configuração, IAM, segredos — são onde os comprometimentos acontecem, e onde sua atenção deve se concentrar.

Fontes e leituras recomendadas

Exercícios

  1. Explique o modelo de responsabilidade compartilhada, distinguindo segurança "da" nuvem e "na" nuvem.

    ✓ Resposta:

    A segurança é dividida entre provedor e cliente. O provedor é responsável pela segurança "da" nuvem — infraestrutura física, hardware, virtualização subjacente. O cliente é responsável pela segurança "na" nuvem — suas configurações, dados, controle de acesso e aplicações. A maioria dos incidentes decorre de falhas do cliente (configuração), não do provedor.

  2. Como a divisão de responsabilidade varia entre IaaS, PaaS e SaaS?

    ✓ Resposta:

    Quanto mais "as a Service", mais o provedor gerencia e menos o cliente controla. Em IaaS, o cliente gerencia tudo acima da infraestrutura (SO, aplicações — mais responsabilidade sua). Em PaaS, o provedor cuida do SO e da plataforma. Em SaaS, o provedor cuida de quase tudo. A linha de responsabilidade se move conforme o modelo.

  3. Qual é a falha de segurança em nuvem mais comum, e qual seu exemplo mais notório?

    ✓ Resposta:

    As configurações incorretas (misconfigurations). O exemplo mais notório são os buckets de armazenamento expostos — dados sensíveis deixados publicamente acessíveis por configuração errada, causa de incontáveis vazamentos massivos.

  4. Por que a exposição de credenciais de nuvem é tão devastadora, e como essas chaves costumam vazar?

    ✓ Resposta:

    Porque as chaves de acesso à API da nuvem são extremamente poderosas — com elas, o atacante controla os recursos de nuvem da vítima (comprometendo a infraestrutura, gerando abuso caro como cryptojacking). Vazam hardcoded em código enviado a repositórios públicos (varridos por bots em minutos), em arquivos de configuração e em buckets expostos.

  5. Por que se diz que a nuvem "redistribui responsabilidades e introduz novos erros", e onde a atenção defensiva deve se concentrar?

    ✓ Resposta:

    Porque a nuvem divide a segurança entre provedor e cliente (redistribuindo responsabilidades) e sua natureza programável/API introduz novos erros — configurações erradas e credenciais vazadas expõem dados ou dão controle em escala e instantaneamente. A atenção defensiva deve concentrar-se nas responsabilidades do cliente: configuração correta, IAM com menor privilégio, e gestão rigorosa de segredos.