O modelo de responsabilidade compartilhada
AWS, Azure e Google Cloud publicam modelos de responsabilidade compartilhada. O princípio é constante: o fornecedor cuida da segurança da infraestrutura da nuvem, incluindo a parte física e algumas camadas técnicas de base, enquanto a segurança na nuvem continua do lado do cliente. A divisão exata depende do modelo de serviço: IaaS, PaaS ou SaaS. Continuam sob sua responsabilidade a configuração dos serviços, a gestão dos acessos, a criptografia dos dados dos aplicativos e o comportamento dos usuários.
Na prática, um bucket de armazenamento mal configurado, permissões excessivas em uma conta de serviço ou credenciais comprometidas não transferem a responsabilidade para o fornecedor. São seus dados, sua configuração e sua exposição. Erros de configuração estão entre as causas mais frequentes de exposição na nuvem: o problema costuma vir mais de uma governança incompleta dos acessos, parâmetros e usos do que do fornecedor.
Os vetores reais de risco
Em muitas organizações, os incidentes na nuvem envolvem três grupos de problemas:
- Erros de configuração — armazenamento aberto ao público por descuido, regras de firewall permissivas demais e registros desativados. São frequentes em migrações rápidas ou implantações sem revisão de segurança.
- Acessos não revogados — contas de ex-colaboradores, tokens de API esquecidos e acessos de fornecedores nunca desativados. O princípio do menor privilégio raramente é aplicado com rigor nas pequenas e médias empresas.
- Mobilidade e BYOD — acessar recursos internos por Wi-Fi público sem um caminho controlado amplia a superfície de ataque: sequestro de DNS, portais cativos, exposição de metadados e acesso sem política uniforme. A questão vai além da criptografia do conteúdo, já parcialmente coberta por TLS: inclui a ausência de uma saída controlada e de uma política de acesso homogênea.
O que dizem as regras aplicáveis
Normas de proteção de dados : a LGPD brasileira, especialmente o artigo 46, exige medidas técnicas e administrativas adequadas para proteger dados pessoais. O GDPR europeu, artigo 32, também prevê segurança adequada ao risco e cita explicitamente a criptografia; continua relevante quando seu campo de aplicação é alcançado. Essas obrigações abrangem dados pessoais armazenados ou tratados na nuvem. No Brasil, as medidas devem responder ao risco, sem apresentar a LGPD como uma exigência de tecnologia única nesse contexto.
Diretiva europeia NIS2: amplia as obrigações de cibersegurança de entidades essenciais e importantes em setores definidos, com gestão de riscos, continuidade do negócio e notificação de incidentes. Inclui a segurança da cadeia de fornecimento: as entidades abrangidas precisam controlar os riscos de fornecedores críticos, o que pode repassar obrigações contratuais de segurança aos prestadores, inclusive brasileiros. É uma regra europeia, não uma obrigação geral no Brasil.
Certificações nacionais de serviços na nuvem: conforme o país, qualificações oficiais atestam garantias de localização dos dados, resistência a imposições estrangeiras e práticas de segurança. São relevantes para organizações que tratam dados sensíveis ou estão sujeitas a exigências setoriais, conforme as regras aplicáveis.
O que uma VPN cobre aqui e o que não cobre
Uma VPN empresarial na nuvem protege o tráfego em trânsito: a conexão entre o dispositivo do colaborador e os recursos internos é criptografada, o IP de origem fica oculto e o acesso pode ser condicionado a autenticação forte.
O que uma VPN não cobre. A criptografia dos dados em repouso na nuvem, a gestão de permissões, a configuração dos serviços e a detecção de comportamentos anormais. Uma VPN não substitui uma política rigorosa de IAM, a criptografia em repouso nem um SIEM.
Para ambientes principalmente SaaS, como suítes de escritório on-line, ferramentas colaborativas e CRM na nuvem, a VPN empresarial nem sempre é o controle prioritário. Conforme a arquitetura, acesso condicional, CASB, verificação das condições dos dispositivos ou uma abordagem Zero Trust podem ser mais estruturantes. A VPN continua adequada para recursos internos e ambientes híbridos; sozinha, torna-se insuficiente quando o trabalho passa principalmente por aplicativos de terceiros na nuvem. Seu papel é preciso: exigir um caminho controlado, uma política uniforme de acesso e limites definidos para o tráfego destinado aos recursos internos. É uma medida necessária nesse contexto, não uma resposta universal. Para a parte de rede, veja também como proteger os dispositivos de uma rede empresarial.
As confusões mais frequentes
“Nossos dados estão em um grande fornecedor, então estão seguros.” A infraestrutura pode ser robusta sem dizer nada sobre a qualidade das suas configurações, o rigor das permissões de acesso ou o comportamento dos usuários. São três problemas distintos que o fornecedor não resolve no seu lugar.
“A criptografia nativa do armazenamento basta.” Ela protege os dados em repouso contra acesso físico não autorizado aos discos. Não protege contra uma conta legítima com permissões excessivas, credenciais comprometidas ou acesso de fornecedor nunca revogado. Criptografia em repouso não é uma política de acesso.
“Trabalhamos principalmente com SaaS, uma VPN basta.” Em um ambiente principalmente SaaS, o túnel de rede não é o controle principal. A questão está na identidade, nas condições do dispositivo e nas políticas de acesso condicional. Um colaborador com conta comprometida, aparelho não gerenciado ou permissões excessivas representa um risco que a VPN não reduz.
Priorizar conforme seu ambiente
As medidas adequadas variam conforme a arquitetura real da organização.
| Perfil | O que priorizar |
|---|---|
| Pequena ou média empresa que usa principalmente SaaS | MFA em todas as contas, acesso condicional, gestão de dispositivos por MDM, revisão regular das permissões e registro das conexões. A VPN é secundária quando há poucos recursos internos. |
| Pequena ou média empresa híbrida com recursos internos | VPN ou ZTNA para acesso remoto, segmentação dos acessos, bastion de administração e registros centralizados. O túnel de rede controlado passa a ser estruturante. |
| Dados sensíveis ou exigências setoriais | Localização dos dados, governança das chaves criptográficas, fornecedor certificado, rastreabilidade completa e exigências repassadas aos prestadores. |
As medidas que importam
- Criptografia em trânsito — TLS 1.2 no mínimo, TLS 1.3 assim que possível e VPN ou ZTNA para acesso remoto aos recursos internos.
- Criptografia em repouso — ativar a criptografia nativa dos serviços de armazenamento. Gerenciar as chaves separadamente, por KMS ou HSM, se a sensibilidade justificar.
- IAM rigoroso — menor privilégio de forma sistemática, revisão regular dos acessos, exclusão imediata de contas em desligamentos e MFA obrigatório em todas as contas privilegiadas.
- Registros e detecção — ativar logs de acesso e configuração e definir alertas para comportamentos anormais, como conexões de locais incomuns ou volumes atípicos.
- Backups e restauração — manter cópias separadas do sistema principal, verificar sua integridade e testar de verdade a restauração. Um backup não testado é uma hipótese, não uma garantia.
- Plano de resposta a incidentes — definir antes do incidente quem faz o quê, em quais prazos e com quais procedimentos de comunicação, incluindo a ANPD e os titulares quando os critérios legais da LGPD forem atendidos, nos prazos regulamentares aplicáveis.
O principal risco da nuvem não é a hospedagem terceirizada em si: é acreditar que um fornecedor, por melhor que seja, assume sua responsabilidade pelos acessos, configurações e governança. Em muitas organizações, os incidentes decorrem mais de permissões excessivas, configurações frágeis ou governança incompleta do que de uma falha do fornecedor.