Faculdade de Tecnologia e Inovação
SENAC DF
Segurança da Informação
Disciplina:
Segurança em Nuvem
Parte 1 — Fundamentos e Contexto
Encontros 1 a 4
Profª Maristela Nunes de Oliveira
Visão Geral
O que vamos explorar nesta primeira parte?
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.
Encontro 1
Revisão de Cloud Computing — modelos, serviços e responsabilidades
Encontro 2
Modelo de Responsabilidade Compartilhada — quem protege o quê?
Encontro 3
Introdução à Segurança em Nuvem — ameaças, Zero Trust e incidentes reais

Ao final desta unidade, você terá um panorama sólido dos fundamentos que sustentam toda a prática de segurança em ambientes cloud — do modelo de serviço à postura de confiança zero.
Encontro 1
Revisão de Cloud Computing
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.
Encontro 1
Modelos de Serviço
IaaS, PaaS e SaaS — Os Três Pilares do Serviço em Nuvem
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.
IaaS — Infraestrutura como Serviço
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.
PaaS — Plataforma como Serviço
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.
SaaS — Software como Serviço
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.
Encontro 1
Modelos de Implantação
Nuvem Pública, Privada, Híbrida e Multicloud
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.
Nuvem Pública
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.
Nuvem Privada
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.
Nuvem Híbrida
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.
Multicloud
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.
Encontro 1
Análise Crítica
Vantagens, Riscos e Responsabilidades da Nuvem
✅ Vantagens Estratégicas
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
⚠️ Riscos e Responsabilidades
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
Encontro 1
Atividade Prática
📌 Atividade: Mapa Mental Comparando Modelos de Nuvem
Nesta atividade, vocês vão sintetizar e conectar visualmente os conceitos abordados neste encontro.
1
Construa o Mapa
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.
2
Compare e Analise
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.
3
Apresente e Discuta
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.
Encontro 2
Modelo de Responsabilidade Compartilhada
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.
Encontro 2
Conceito Central
Responsabilidade do Provedor vs. Responsabilidade do Cliente
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.
Encontro 2
Comparativo
AWS vs. Azure vs. GCP — Como Cada Provedor Aborda a Responsabilidade
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.
Amazon Web Services (AWS)
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.
Microsoft Azure
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.
Google Cloud Platform (GCP)
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.
Encontro 2
Atenção
Erros Comuns de Segurança em Cloud
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.
Buckets e Storage Públicos
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.
Credenciais Hardcoded e Sem Rotação
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.
Permissões Excessivas (Over-Privileging)
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.
Ausência de Monitoramento e Logging
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.
Encontro 2
Estudo de Caso
📌 Estudo de Caso: Falhas por Má Configuração
Capital One — O Breach de 2019
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.
Lições Aprendidas
  • 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?
Encontro 3
Introdução à Segurança em Nuvem
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.
Encontro 3
Comparativo
Segurança On-Premises vs. Segurança em Nuvem
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.

Insight-chave: Na nuvem, a identidade substituiu o perímetro como principal mecanismo de controle de segurança. Se você controla quem pode acessar o quê, controla a segurança.
Encontro 3
Ameaças
Ameaças Comuns em Ambientes Cloud
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.
1
Sequestro de Contas
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.
2
APIs Inseguras
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.
3
Misconfiguration
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.
4
Insider Threats
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.
5
Data Breaches e Exfiltraçã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.
Encontro 3
Zero Trust
Princípios Zero Trust — "Nunca Confie, Sempre Verifique"
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.
Verificação Contínua
Cada requisição é autenticada e autorizada, mesmo de usuários já logados. Contexto (localização, dispositivo, horário, comportamento) é avaliado continuamente.
Menor Privilégio
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.
Microssegmentação
A rede é dividida em segmentos granulares. Mesmo que um atacante comprometa um segmento, o movimento lateral é bloqueado por controles entre zonas.
Assume Breach
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.
Encontro 3
Incidentes Reais
📌 Discussão Guiada: Exemplos Reais de Incidentes em Nuvem
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.
Twitch (2021) — Vazamento Massivo de Código-Fonte
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.
SolarWinds (2020) — Ataque à Cadeia de Suprimentos
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.
Uber (2022) — Comprometimento via Engenharia Social
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.
Para reflexão: 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.
Consolidação
Resumo dos Encontros 1 a 3 — Fundamentos e Contexto
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.
Referências e Recursos Complementares
Para aprofundamento nos temas abordados, consulte as seguintes referências oficiais e recursos complementares:
Documentação dos Provedores
  • 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
Frameworks e Padrões
  • 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
Leitura Recomendada
  • 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)

Profª Maristela: Estas referências serão utilizadas ao longo de toda a disciplina. Mantenha-as acessíveis e consulte-as durante as atividades práticas e estudos de caso.