Prof.ª Maristela Oliveira
Esta primeira unidade da disciplina de Segurança em Nuvem foi estruturada para construir, passo a passo, a base conceitual que vocês precisam dominar antes de avançar para temas mais avançados como criptografia em nuvem, gestão de identidade e conformidade regulatória. Cada encontro aborda uma camada essencial de conhecimento.
Revisão de Cloud Computing — modelos, serviços e responsabilidades
Modelo de Responsabilidade Compartilhada — quem protege o quê?
Introdução à Segurança em Nuvem — ameaças, Zero Trust e incidentes reais
Antes de proteger a nuvem, é preciso entendê-la profundamente. Vamos revisar os fundamentos de computação em nuvem que servirão de alicerce para todos os temas de segurança que virão a seguir.
A computação em nuvem é oferecida em três modelos de serviço fundamentais, cada um com diferentes níveis de abstração, controle e responsabilidade. Compreender essas diferenças é essencial para mapear onde a segurança precisa ser aplicada.
O provedor fornece a infraestrutura básica: servidores virtuais, armazenamento, redes e virtualização. O cliente é responsável por sistema operacional, middleware, runtime, dados e aplicações. É o modelo que oferece maior controle ao cliente — e, consequentemente, maior responsabilidade de segurança.
Exemplos: Amazon EC2, Google Compute Engine, Azure Virtual Machines.
O provedor gerencia a infraestrutura e o ambiente de execução (runtime, SO, middleware). O cliente foca no desenvolvimento e implantação de aplicações. A segurança da plataforma subjacente fica com o provedor, mas a proteção dos dados e do código é do cliente.
Exemplos: Heroku, Google App Engine, Azure App Services.
O provedor entrega o software completo e gerencia toda a pilha tecnológica. O cliente apenas utiliza a aplicação. A responsabilidade de segurança do cliente se concentra em gestão de identidade, controle de acesso e proteção dos dados inseridos.
Exemplos: Google Workspace, Microsoft 365, Salesforce, Slack.
Além do modelo de serviço, a forma como a nuvem é implantada impacta diretamente as estratégias de segurança. Cada modelo de implantação traz um perfil diferente de risco, custo e governança.
Infraestrutura compartilhada entre múltiplos clientes (multi-tenancy), gerenciada inteiramente pelo provedor. Oferece escalabilidade sob demanda e custos operacionais reduzidos. A segurança depende fortemente das configurações do cliente e dos controles do provedor. Principais riscos: exposição acidental de dados, configurações incorretas de permissões e compliance.
Infraestrutura dedicada a uma única organização, podendo ser on-premises ou hospedada por terceiros. Oferece maior controle e customização das políticas de segurança. Ideal para setores regulados (financeiro, saúde, governo) que exigem isolamento de dados e conformidade rigorosa. Custo mais elevado e necessidade de equipe especializada.
Combina nuvem pública e privada, permitindo que cargas de trabalho transitem entre ambientes conforme necessidade. Oferece flexibilidade estratégica: dados sensíveis permanecem na nuvem privada enquanto cargas variáveis usam a nuvem pública. O grande desafio de segurança está na integração e na gestão unificada de políticas entre ambientes distintos.
Utilização simultânea de dois ou mais provedores de nuvem pública (ex.: AWS + Azure + GCP). Evita o vendor lock-in e permite escolher o melhor serviço de cada provedor. A complexidade de segurança aumenta significativamente: é preciso gerenciar políticas, identidades e compliance em múltiplos ecossistemas com ferramentas diferentes.
A migração para a nuvem traz benefícios significativos que transformaram a forma como as organizações operam:
- Escalabilidade elástica: recursos computacionais aumentam ou diminuem automaticamente conforme a demanda, eliminando superprovisionamento
- Redução de CAPEX: transição de investimentos em capital (hardware) para custos operacionais (OPEX) com modelo pay-as-you-go
- Alta disponibilidade: provedores oferecem SLAs de até 99,99% com infraestrutura distribuída globalmente
- Agilidade e inovação: provisionamento de ambientes em minutos, acelerando ciclos de desenvolvimento e time-to-market
- Atualizações automáticas: patches de segurança e melhorias da infraestrutura são aplicados pelo provedor
- Recuperação de desastres: backups distribuídos geograficamente facilitam a continuidade de negócios
Junto aos benefícios, surgem riscos que exigem governança e atenção contínua:
- Perda de visibilidade: sem acesso físico à infraestrutura, o monitoramento depende das ferramentas do provedor
- Shadow IT: colaboradores adotam serviços cloud sem autorização, criando pontos cegos de segurança
- Vendor lock-in: dependência excessiva de um provedor dificulta migração e negociação
- Compliance e soberania de dados: dados armazenados em regiões diferentes podem violar regulamentações como LGPD e GDPR
- Superfície de ataque ampliada: APIs expostas, consoles de gerenciamento e credenciais comprometidas são vetores frequentes
- Custos ocultos: sem governança financeira (FinOps), gastos com nuvem podem escalar rapidamente
Nesta atividade, vocês vão sintetizar e conectar visualmente os conceitos abordados neste encontro.
Crie um mapa mental que tenha como nó central "Cloud Computing" e ramificações para os modelos de serviço (IaaS, PaaS, SaaS) e modelos de implantação (pública, privada, híbrida, multicloud). Para cada ramificação, inclua: definição resumida, exemplos reais, nível de controle do cliente e principais preocupações de segurança.
Destaque no mapa as intersecções e diferenças entre os modelos. Onde um modelo de serviço se combina melhor com determinado modelo de implantação? Quais combinações apresentam maior risco de segurança? Use cores ou ícones para sinalizar níveis de risco.
Compartilhe seu mapa com a turma em um breve pitch de 3 minutos. Destaque a combinação que você considera mais desafiadora do ponto de vista de segurança e justifique sua escolha com base nos conceitos aprendidos.
Um dos conceitos mais críticos — e mais mal compreendidos — da segurança em nuvem. Quem protege o quê? A resposta pode surpreender muitos profissionais.
O Modelo de Responsabilidade Compartilhada (Shared Responsibility Model) é o framework fundamental que define a divisão de obrigações de segurança entre o provedor de nuvem e o cliente. A premissa é simples, mas a execução é complexa: o provedor protege a segurança da nuvem; o cliente protege a segurança na nuvem.
Observe o padrão: quanto mais alto o nível de abstração do serviço (de IaaS para SaaS), mais responsabilidade migra para o provedor. Porém, a proteção dos dados, identidades e configurações de acesso permanece sempre com o cliente, independentemente do modelo. Este é o ponto que gera a maioria das falhas de segurança em ambientes cloud.
Para entender completamente o Modelo de Responsabilidade Compartilhada, é crucial diferenciar dois componentes-chave que frequentemente causam confusão na segurança em nuvem.
O middleware atua como uma ponte entre aplicações, sistemas operacionais e bancos de dados, facilitando a comunicação e a gestão de dados. Inclui servidores de aplicação, gerenciadores de mensagens e APIs.
Responsabilidade: Em IaaS, o cliente gerencia e protege o middleware. Em PaaS, o provedor cuida do middleware, liberando o cliente para focar no código.
O runtime é o ambiente de execução onde o código da sua aplicação é compilado e executado. Ele fornece os serviços e recursos necessários para o funcionamento do software, como máquinas virtuais Java ou interpretadores Python.
Responsabilidade: Similar ao middleware, em IaaS o cliente é responsável pelo runtime. Em PaaS, o provedor se encarrega de manter e proteger o ambiente de runtime, garantindo que o código do cliente possa ser executado.
A compreensão desses elementos ajuda a discernir onde termina a responsabilidade do provedor e começa a do cliente, especialmente ao configurar ambientes e aplicar patches.
Embora o conceito de responsabilidade compartilhada seja universal, cada grande provedor articula e implementa esse modelo com nuances próprias. Conhecer essas diferenças é fundamental para profissionais que atuam em ambientes multicloud.
A AWS foi pioneira na formalização do Shared Responsibility Model. Sua documentação divide claramente as responsabilidades em "Segurança DA nuvem" (AWS) e "Segurança NA nuvem" (cliente). A AWS oferece ferramentas nativas robustas como AWS Config (auditoria de configurações), GuardDuty (detecção de ameaças), IAM (gestão de identidade granular) e CloudTrail (logging de atividades). Destaque para o AWS Well-Architected Framework, que inclui um pilar dedicado à segurança com checklists práticos.
O Azure adota o mesmo princípio, mas com terminologia ligeiramente diferente e forte integração com o ecossistema Microsoft. Oferece o Microsoft Defender for Cloud como hub central de segurança, com Secure Score — uma pontuação que mede a postura de segurança do cliente. A integração nativa com Azure Active Directory (Entra ID) facilita a gestão de identidade, especialmente para organizações que já usam o ecossistema Microsoft 365. O Azure também se destaca em compliance, com mais de 100 certificações.
O GCP enfatiza o conceito de "destino compartilhado" (shared fate) — indo além da responsabilidade compartilhada ao se posicionar como parceiro ativo na segurança do cliente. Oferece o Security Command Center para visibilidade centralizada, BeyondCorp como implementação nativa de Zero Trust, e Chronicle para análise de segurança em escala. O GCP se diferencia pela ênfase em criptografia por padrão: todos os dados em trânsito e em repouso são criptografados automaticamente.
A maioria esmagadora dos incidentes de segurança em nuvem não se deve a vulnerabilidades do provedor, mas sim a erros de configuração e gestão por parte do cliente. O Gartner estima que até 2025, 99% das falhas de segurança em nuvem serão culpa do cliente. Conhecer esses erros é o primeiro passo para evitá-los.
Deixar buckets S3, Blobs do Azure ou Cloud Storage do GCP com acesso público é um dos erros mais recorrentes e devastadores. Dados sensíveis — desde informações pessoais até backups completos de bancos de dados — ficam expostos para qualquer pessoa na internet. Incidentes célebres incluem vazamentos de milhões de registros por buckets S3 mal configurados.
Embutir access keys, tokens e senhas diretamente no código-fonte ou em repositórios Git é uma prática perigosa e surpreendentemente comum. Bots automatizados escaneiam repositórios públicos no GitHub em tempo real buscando credenciais expostas. A falta de rotação periódica agrava o problema.
Conceder permissões administrativas amplas "para facilitar" viola o princípio do menor privilégio. Usuários e serviços com permissões além do necessário ampliam a superfície de ataque e o raio de impacto em caso de comprometimento. Políticas IAM devem ser revisadas e auditadas regularmente.
Não ativar ou não monitorar logs de atividade (CloudTrail, Azure Monitor, Cloud Audit Logs) equivale a operar às cegas. Sem logging, incidentes podem passar despercebidos por semanas ou meses, aumentando exponencialmente o dano. É essencial configurar alertas automatizados para atividades suspeitas.
Para aprofundar nossa compreensão sobre segurança em nuvem e evitar falhas comuns, é fundamental ter clareza sobre alguns termos técnicos frequentemente citados e suas implicações.
Estes são os nomes dados aos serviços de armazenamento de objetos altamente escaláveis e duráveis oferecidos pelos provedores de nuvem. Permitem guardar grandes volumes de dados não estruturados (arquivos, imagens, backups, logs, etc.).
- AWS S3 Buckets: Amazon Simple Storage Service (S3) é o serviço de armazenamento de objetos da AWS. Um "bucket" é o contêiner onde os objetos são armazenados.
- Azure Blobs: No Microsoft Azure, o armazenamento de objetos é conhecido como Blob Storage, e os dados são organizados em "contêineres de blobs".
- GCP Cloud Storage: No Google Cloud Platform, o serviço é chamado Cloud Storage, e os dados são organizados em "buckets".
A má configuração, permitindo acesso público não intencional, é uma das principais causas de vazamento de dados, como mencionado anteriormente.
IAM é o serviço que permite gerenciar usuários e seu acesso aos recursos da nuvem. As Políticas IAM são os documentos que definem explicitamente quem (usuários, grupos, roles) pode fazer o quê (quais ações) em quais recursos.
- Controle Granular: As políticas permitem um controle de acesso muito detalhado, essencial para implementar o Princípio do Menor Privilégio.
- Prevenção de Sobre-Privilégios: Um erro comum é conceder mais permissões do que o necessário, o que aumenta a superfície de ataque e o risco de um comprometimento resultar em danos maiores. Auditorias regulares das Políticas IAM são cruciais para manter a segurança.
- Exemplos de Ações: "s3:GetObject" (ler um objeto no S3), "ec2:StartInstance" (iniciar uma instância EC2), "iam:CreateUser" (criar um novo usuário IAM).
Gerenciar e auditar políticas IAM é um dos pilares da segurança em qualquer ambiente cloud.
Em julho de 2019, a Capital One sofreu um dos maiores vazamentos de dados da história do setor financeiro, afetando mais de 100 milhões de clientes e solicitantes de crédito nos EUA e Canadá.
O que aconteceu? Uma ex-funcionária da AWS explorou um firewall de aplicação web (WAF) mal configurado em uma instância EC2 da Capital One. A configuração incorreta do WAF, combinada com uma role IAM com permissões excessivas, permitiu que a atacante executasse um ataque SSRF (Server-Side Request Forgery) para acessar metadados da instância e obter credenciais temporárias. Com essas credenciais, ela acessou buckets S3 contendo dados sensíveis.
Dados expostos: nomes, endereços, scores de crédito, limites de crédito, saldos, números de seguridade social e números de contas bancárias.
- A falha foi do cliente, não da AWS — a infraestrutura AWS funcionou como projetada; a configuração é que estava errada
- Princípio do menor privilégio: a role IAM não deveria ter acesso aos buckets S3 com dados sensíveis
- Segmentação e WAF: firewalls devem ser testados e auditados regularmente
- Monitoramento proativo: a atividade anômala poderia ter sido detectada mais cedo com alertas configurados
- Custo: a Capital One pagou mais de US$ 80 milhões em multas e custos de remediação
Reflexão para a turma: Quais controles poderiam ter prevenido ou mitigado este incidente?
Ameaças evoluem, perímetros desaparecem e a confiança se torna um recurso a ser eliminado. Bem-vindos ao paradigma da segurança cloud-native.
A transição para a nuvem não é apenas uma mudança de infraestrutura — é uma transformação fundamental na forma como pensamos segurança. Muitas organizações cometem o erro de tentar replicar suas práticas on-premises na nuvem, ignorando as diferenças estruturais entre os dois ambientes.
O cenário de ameaças em ambientes cloud é dinâmico e em constante evolução. A Cloud Security Alliance (CSA) publica periodicamente os principais riscos, e organizações como OWASP mantêm listas específicas para aplicações cloud. Vamos explorar as ameaças mais relevantes que vocês encontrarão na prática profissional.
Atacantes obtêm credenciais por phishing, credential stuffing ou vazamentos. Com acesso à console de gerenciamento, podem exfiltrar dados, criar recursos para mineração de criptomoedas ou escalar privilégios. A MFA (autenticação multifator) é a principal defesa, mas ainda é surpreendentemente subutilizada.
APIs são a "porta de entrada" dos serviços cloud. APIs mal protegidas — sem autenticação adequada, rate limiting ou validação de entrada — são vetores primários de ataque. O OWASP API Security Top 10 documenta as vulnerabilidades mais exploradas, incluindo BOLA, Broken Authentication e Mass Assignment.
Como vimos no Encontro 2, erros de configuração são a causa #1 de incidentes em nuvem. Security Groups abertos, encryption desabilitada, logging desativado e roles com wildcard permissions (*) são exemplos clássicos que ferramentas de CSPM (Cloud Security Posture Management) ajudam a detectar.
Funcionários maliciosos ou negligentes representam risco significativo, especialmente em ambientes cloud onde um único clique pode expor dados globalmente. Controles como DLP (Data Loss Prevention), logging de atividades, princípio do menor privilégio e revisões periódicas de acesso são essenciais para mitigação.
A concentração de grandes volumes de dados na nuvem torna esses ambientes alvos de alto valor. Vetores incluem buckets expostos, snapshots não criptografados, backups sem proteção e movimentação lateral após comprometimento inicial. A criptografia em repouso e em trânsito, aliada a controles de acesso granulares, é fundamental.
O modelo Zero Trust representa uma mudança paradigmática na segurança: em vez de confiar automaticamente em qualquer entidade dentro do "perímetro", toda requisição de acesso deve ser verificada, independentemente de sua origem. Esse modelo é especialmente relevante para ambientes cloud, onde o conceito de perímetro tradicional não se aplica.
Cada requisição é autenticada e autorizada, mesmo de usuários já logados. Contexto (localização, dispositivo, horário, comportamento) é avaliado continuamente.
Usuários e serviços recebem apenas as permissões mínimas necessárias para executar suas tarefas. Acesso Just-in-Time (JIT) é preferível a permissões permanentes.
A rede é dividida em segmentos granulares. Mesmo que um atacante comprometa um segmento, o movimento lateral é bloqueado por controles entre zonas.
Projeta-se a arquitetura assumindo que uma violação já ocorreu ou ocorrerá. Detecção, resposta e contenção são priorizadas tanto quanto a prevenção.
A implementação de Zero Trust não é uma ferramenta específica, mas uma estratégia arquitetural que envolve IAM robusto, criptografia end-to-end, monitoramento contínuo, microssegmentação de rede e políticas de acesso condicional. Google (BeyondCorp), Microsoft (Zero Trust Architecture) e a NIST (SP 800-207) publicam frameworks de referência para implementação.
Para consolidar os conceitos aprendidos, vamos analisar incidentes reais que ilustram as ameaças e vulnerabilidades discutidas. Cada caso traz lições valiosas para a prática profissional.
Atacantes comprometeram o processo de build do software Orion da SolarWinds, inserindo um backdoor que foi distribuído via atualizações legítimas para mais de 18.000 organizações, incluindo agências governamentais dos EUA. Embora não exclusivamente um ataque cloud, o incidente demonstrou como a confiança implícita na cadeia de suprimentos viola princípios Zero Trust.
Todo o código-fonte da plataforma, incluindo dados de pagamento de streamers, foi vazado após uma configuração incorreta de servidor. O incidente expôs 125 GB de dados internos, incluindo ferramentas proprietárias e projetos não anunciados. Demonstrou como a segurança inadequada de repositórios internos pode ter consequências devastadoras.
Um atacante de 18 anos obteve acesso a sistemas internos críticos da Uber — incluindo Slack, AWS e dashboards de segurança — usando fadiga de MFA (enviando notificações push repetidas até a vítima aceitar). O caso ilustra que mesmo com MFA implementado, a configuração e o tipo de MFA importam: tokens FIDO2/WebAuthn são resistentes a este ataque.
Atividade: Em cada caso, identifique: (1) qual princípio de segurança foi violado, (2) qual controle poderia ter prevenido o incidente e (3) como o modelo de responsabilidade compartilhada se aplica.
Vamos recapitular os pilares conceituais que construímos nesta primeira parte da disciplina. Esses fundamentos serão referenciados e aprofundados ao longo de todos os módulos seguintes.
Esses três encontros formam um tripé de conhecimento: sem compreender a arquitetura cloud (Encontro 1), não é possível mapear responsabilidades (Encontro 2); sem mapear responsabilidades, não se pode implementar segurança efetiva (Encontro 3). Nos próximos encontros, avançaremos para Identity & Access Management (IAM), criptografia, segurança de rede em nuvem e compliance — sempre apoiados nos fundamentos construídos aqui.
Para aprofundamento nos temas abordados, consulte as seguintes referências oficiais e recursos complementares:
- AWS: Well-Architected Framework — Security Pillar; Shared Responsibility Model
- Azure: Microsoft Cloud Security Benchmark; Azure Security Documentation
- GCP: Google Cloud Security Best Practices; BeyondCorp Enterprise
- NIST SP 800-144: Guidelines on Security and Privacy in Public Cloud Computing
- NIST SP 800-207: Zero Trust Architecture
- CSA: Cloud Controls Matrix (CCM) e Top Threats to Cloud Computing
- ISO/IEC 27017: Controles de segurança para serviços em nuvem
- Securing the Cloud — Vic Winkler (Syngress)
- Cloud Security and Privacy — Tim Mather, Subra Kumaraswamy, Shahed Latif (O'Reilly)
- OWASP Cloud Security Testing Guide
- Relatórios anuais da CSA e da Verizon DBIR (seção cloud)