O modelo de segurança perimetral — “tudo dentro do firewall é confiável, tudo fora é inimigo” — morreu quando o primeiro colaborador acessou o sistema corporativo pelo Wi-Fi do Starbucks. Cloud acelerou essa morte. Hoje, o perímetro é a identidade, não o endereço IP.
Por que o modelo tradicional falhou
Por décadas, a arquitetura de segurança corporativa foi um castelo com muralha: firewall no perímetro, tudo dentro considerado seguro, tudo fora bloqueado. Esse modelo tinha uma premissa que não existe mais: usuários, dados e aplicações dentro de uma rede física bem definida.
Hoje:
- Usuários acessam de casa, de hotéis, de co-workings (qualquer IP)
- Dados estão em cloud (fora do datacenter da empresa)
- Aplicações são SaaS (na internet)
- Parceiros e fornecedores precisam de acesso a sistemas internos
O perímetro desapareceu. Continuar investindo em segurança perimetral enquanto ignora identidade, dados e workloads em cloud é como reforçar as portas de um castelo sem teto.
Os 4 pilares de segurança cloud
Pilar 1: Identidade
Se o perímetro é a identidade, então a segurança começa em quem pode acessar o quê.
Componentes essenciais:
- MFA (Multi-Factor Authentication): obrigatório para todos os acessos a sistemas críticos e cloud. Sem exceção — incluindo o CEO e o sysadmin mais experiente
- IAM com menor privilégio: cada usuário, serviço e aplicação tem acesso apenas ao que precisa. Nenhum “admin de tudo” por conveniência
- Contas privilegiadas protegidas: acessos administrativos (raiz de cloud, Domain Admin) devem ter proteção adicional — senha gerenciada em cofre, uso restrito a operações específicas, sessão auditada
- SSO (Single Sign-On): usuário autentica uma vez e acessa múltiplos sistemas. Reduz fadiga de senha e centraliza auditoria de acesso
- Revisão periódica de acessos: usuários que saíram da empresa, mudaram de função, ou têm acessos não utilizados há 90 dias
Pilar 2: Rede
Em cloud, rede não é mais cabo físico — é configuração lógica. A disciplina que antes era de infraestrutura física é agora de código e política.
Componentes essenciais:
- Segmentação: sistemas com diferentes níveis de criticidade em redes separadas. Banco de dados de produção não deve estar na mesma rede que o servidor de desenvolvimento
- Zero Trust Network Access (ZTNA): em vez de VPN que dá acesso a “tudo da rede interna”, ZTNA dá acesso apenas ao sistema específico que o usuário precisa, verificando identidade e postura do dispositivo a cada acesso
- Firewall com inspeção de conteúdo: não apenas controle de porta/IP, mas inspeção de protocolo — identificar e bloquear tráfego malicioso mesmo em portas legítimas (HTTPS na 443)
- Monitoramento de tráfego: detectar comportamentos anômalos — exfiltração de dados em volume, lateral movement, comunicação com IPs maliciosos
Pilar 3: Dados
O dado é o ativo. Proteger servidores sem proteger os dados é a ordem errada.
Componentes essenciais:
- Inventário de dados: saber onde cada tipo de dado sensível está — sem isso, você não sabe o que proteger
- Classificação de dados: público, interno, confidencial, restrito — cada categoria com controles proporcionais
- Criptografia em repouso e em trânsito: padrão mínimo para qualquer dado classificado como confidencial ou superior
- DLP (Data Loss Prevention): ferramentas que detectam e bloqueiam transmissão de dados sensíveis para destinos não autorizados (e-mail pessoal, Google Drive pessoal, pendrives)
- Backup imutável: proteção contra perda acidental e contra ransomware — backup que não pode ser alterado ou deletado
Pilar 4: Workload
A carga de trabalho (VMs, containers, funções serverless) também precisa ser protegida — não apenas a rede ao redor dela.
Componentes essenciais:
- Gestão de vulnerabilidades: scan periódico de sistemas, priorização de remediação por criticidade (CVSS score), SLA de patch por severidade
- Hardening de OS: configurações padrão de SO frequentemente têm serviços desnecessários rodando, portas abertas que não precisam estar abertas. Hardening fecha a superfície de ataque
- EDR (Endpoint Detection & Response): anti-malware moderno com capacidade de detectar comportamento suspeito, não apenas assinaturas conhecidas
- Imagem de SO padrão (Golden Image): em vez de configurar cada VM manualmente, parta sempre de uma imagem pré-configurada e segura. Novos sistemas nascem seguros por design
Construindo o baseline de segurança cloud
O baseline é o conjunto mínimo de controles que todo recurso cloud da empresa precisa ter. Não é o ideal — é o mínimo não negociável.
Baseline essencial:
| Controle | Aplicação | Verificação |
|---|---|---|
| MFA obrigatório | Todos os usuários com acesso a sistemas cloud | Relatório mensal de usuários sem MFA |
| Senhas únicas em cofre | Contas privilegiadas e de serviço | Audit de contas sem cofre de senha |
| Criptografia em repouso | Todos os volumes de dados sensíveis | Verificação de configuração via IaC |
| TLS 1.2+ em trânsito | Todas as APIs e conexões de banco de dados | Scan de configuração de TLS |
| Logging habilitado | Todos os recursos cloud | Dashboard de cobertura de logs |
| Backup configurado | Todos os sistemas classificados como críticos e importantes | Relatório de cobertura de backup |
| Patches em dia | SO de todas as VMs — crítico < 72h, alto < 30 dias | Relatório de vulnerabilidades abertas |
| Acesso por menor privilégio | IAM — sem políticas de admin amplas | Revisão trimestral de IAM |
Priorizando investimentos de segurança pelo risco real
A tendência é investir em tecnologia nova e cara antes de fechar vulnerabilidades básicas. O resultado: empresa com SIEM de última geração mas sem MFA habilitado — exatamente o cenário invertido.
Priorize pela probabilidade e impacto:
Alta probabilidade, alto impacto → aja agora:
- Credenciais comprometidas sem MFA (principal vetor de ataque)
- Sistemas sem patch de vulnerabilidade crítica
- Backup não testado ou inexistente
- Dados sensíveis sem criptografia
Baixa probabilidade, alto impacto → controles básicos são suficientes:
- Ataque físico ao datacenter (o provedor gerencia isso)
- Zero-day em SO atualizado
Alta probabilidade, baixo impacto → automatize e monitore:
- Tentativas de login com força bruta (bloqueio automático)
- Varreduras de porta de bots (denylists automatizadas)
Baixa probabilidade, baixo impacto → não priorize:
- Cenários de ameaça muito sofisticados enquanto vulnerabilidades básicas existem
Modelo de maturidade de segurança cloud (4 níveis)
Nível 1 — Básico: controles mínimos implementados. MFA nos sistemas críticos, patches em dia, backup funcional, logs básicos. Empresa está em risco alto mas tem o mínimo para não ser um alvo fácil.
Nível 2 — Gerenciado: baseline completo implementado. MFA universal, IAM com menor privilégio, criptografia padrão, monitoramento de segurança básico (SIEM ou equivalente), processo de gestão de vulnerabilidades ativo, teste periódico de backup.
Nível 3 — Definido: segurança por design. Novos sistemas nascem seguros (infraestrutura como código com guardrails de segurança). Zero Trust implementado para acesso remoto. DLP ativo para dados sensíveis. Processo de resposta a incidentes testado. Treinamento periódico de segurança para todos os colaboradores.
Nível 4 — Otimizado: segurança contínua e mensurada. Threat hunting proativo. Red team periódico (pentest em profundidade). Automação de resposta a incidentes. Métricas de segurança reportadas ao board com KPIs definidos. Programa de bug bounty ou gestão de divulgação responsável.
A maioria das PMEs brasileiras está entre Nível 1 e Nível 2. O objetivo imediato deve ser Nível 2 sólido — não saltar para Nível 4 sem ter o básico funcionando.
Como medir e reportar segurança para o board
O board precisa de segurança em linguagem de negócio, não de tecnologia. Os KPIs que funcionam:
Exposição a risco:
- Número de sistemas críticos com vulnerabilidades críticas abertas (objetivo: 0)
- Tempo médio de patch de vulnerabilidade crítica (objetivo: < 72h)
- Percentual de usuários com MFA (objetivo: 100%)
Capacidade de resposta:
- Tempo médio de detecção de incidente (MTTD)
- Tempo médio de resposta a incidente (MTTR)
- Número de incidentes de segurança no período (com classificação por severidade)
Prontidão:
- Data do último teste de restore de backup
- Data do último exercício de DR
- Percentual de colaboradores com treinamento de segurança no ano
Como apresentar: uma página de dashboard com 8–10 métricas, código de cores (verde/amarelo/vermelho), e breve narrativa de “o que melhorou, o que está em andamento, o que precisa de decisão”. Não mais que 10 minutos de uma reunião de diretoria.
Quer fazer um assessment de maturidade de segurança do seu ambiente cloud? A Adentro pode ajudar a identificar lacunas prioritárias e estruturar um roadmap de segurança adequado ao seu perfil.