Sua empresa migra tudo para a nuvem achando que “agora segurança é problema do provedor”. Alguns meses depois, um pentest encontra um bucket de armazenamento configurado como público, expondo dado de cliente para qualquer um que soubesse a URL. O provedor de nuvem fez a parte dele certinho — a infraestrutura física estava segura, os data centers estavam protegidos. O erro estava na configuração que era responsabilidade de quem contratou o serviço.
Essa é a confusão mais cara que existe em segurança de nuvem: achar que migrar significa transferir toda a responsabilidade. Não significa. Significa dividir a responsabilidade — e você precisa saber exatamente qual parte é sua.
Os três modelos e o que muda em cada um
Infraestrutura como Serviço (IaaS)
O provedor entrega recurso de hardware virtualizado — servidor, armazenamento, rede. Você é responsável por gerenciar sistema operacional, aplicação e dado. O provedor garante a segurança física e a integridade do recurso; a configuração segura, manutenção e atualização do que roda em cima disso é com você.
Na prática: mantenha o sistema operacional atualizado com política de patch consistente, configure firewall e monitore o tráfego de rede continuamente. Se você terceirizou o hardware mas não terceirizou o cuidado com o que roda nele, o risco continua todo seu.
Plataforma como Serviço (PaaS)
Aqui o provedor entrega um ambiente de desenvolvimento completo — ferramentas, bibliotecas, infraestrutura pré-configurada — simplificando a criação e gestão de aplicação. O provedor assume mais responsabilidade, garantindo que a infraestrutura e os serviços essenciais estejam seguros, deixando você focado em desenvolver e proteger seu próprio código e dado.
Na prática: avalie se as ferramentas de desenvolvimento e banco de dados oferecidos atendem seus requisitos de compliance, e adote prática de codificação segura com teste regular para eliminar vulnerabilidade no seu próprio código — porque essa parte continua sendo sua, não importa quão gerenciada seja a plataforma.
Software como Serviço (SaaS)
Aplicação totalmente funcional entregue via internet, com o provedor gerenciando praticamente todo aspecto de segurança — da infraestrutura até manutenção e atualização do software. Sua preocupação principal aqui é gestão de acesso e autenticação.
Na prática: use autenticação multifator para reforçar o acesso, e leia com atenção o SLA e os termos de serviço que detalham as medidas de segurança do provedor — porque se o contrato não menciona nada sobre segurança, isso já é um sinal de alerta.
O modelo de responsabilidade compartilhada, resumido
| Modelo | Provedor garante | Você garante |
|---|---|---|
| IaaS | Infraestrutura física e virtual | Sistema operacional e aplicação |
| PaaS | Ambiente de desenvolvimento seguro | Seu código e suas integrações |
| SaaS | Quase tudo, incluindo a aplicação | Gestão de acesso e identidade |
Entender essa divisão evita a lacuna de segurança que mais aparece na prática: achar que “alguém” está cuidando de uma parte que, na verdade, ninguém está cuidando porque cada lado presumiu que era responsabilidade do outro.
Como avaliar a segurança do seu provedor antes de assinar contrato
Antes de migrar, avalie:
- Documentação e boas práticas. O provedor publica guia e recomendação de como proteger o ambiente contratado, ou você tem que descobrir sozinho lendo fórum?
- Compliance e certificação. ISO 27001, SOC 2 e certificações equivalentes não são só selo de marketing — indicam que o provedor passou por auditoria externa de fato.
- Modelo de SLA. Olhe especificamente as cláusulas de segurança e disponibilidade, não só o percentual de uptime prometido.
- Suporte e monitoramento. Prefira provedor com monitoramento ativo e suporte contínuo, capaz de detectar e responder a incidente rapidamente — não só um formulário de contato que demora dias para responder.
Fechando
Segurança em serviço de nuvem não é escolher o provedor mais caro ou a tecnologia mais recente — é entender exatamente onde termina a responsabilidade dele e começa a sua, e não deixar nenhum pedaço dessa fronteira sem dono. O bucket público do exemplo lá em cima não foi falha do provedor de nuvem. Foi falha de alguém do lado do cliente que não sabia que aquela configuração era responsabilidade sua.
Se você já passou por um susto de configuração mal feita em nuvem — bucket público, permissão liberada demais, o que for — compartilha nos comentários. É o tipo de erro que todo mundo comete uma vez, e vale mais aprender com o erro do outro do que com o próprio.
