O que o modelo de responsabilidade compartilhada realmente significa na prática
Ao falar do modelo de responsabilidade compartilhada, a primeira coisa que todo mundo repite é que a nuvem divide a responsabilidade entre o provedor e o cliente. Mas a verdade é que ninguém lê a divisão com atenção até acontecer um vazamento e o suporte do AWS ou Azure responder com o link da documentação que todo mundo já deveria ter lido. O ponto central que todo mundo esquece é simples, mas crucial: no modelo de responsabilidade compartilhada, sabemos que a responsabilidade do provedor é a segurança da nuvem, enquanto a responsabilidade do cliente é a segurança na nuvem. Essa diferença gramatical parece bobagem, mas separa exatamente onde termina a obrigação deles e começa a sua.
no modelo de responsabilidade compartilhada sabemos que a responsabilidade não é 50-50
A maioria dos times entende isso de forma errada. Eles acham que é uma divisão igual, que o provedor cuida de metade e o cliente da outra. Não é assim que funciona. A divisão é dinâmica e muda conforme o serviço que você está usando. Pegue S3, por exemplo. O AWS gerencia a segurança das infraestruturas físicas, os data centers, a redundância elétrica, a proteção contra DDoS em nível de rede. Já cabe a você configurar políticas de bucket, criptografia em repouso, controle de acesso IAM, logging e monitoramento. Se seu bucket fica público porque alguém esqueceu de desmarcar uma checkbox durante o deploy, isso não é problema deles.
Já em um serviço gerenciado como RDS ou Lambda, a coisa muda. O provedor assume mais responsabilidade porque ele gerencia o patch do sistema operacional, a aplicação em si, a configuração do banco. No EC2, onde você tem acesso direto ao SO, a balança pende mais para o lado do cliente. Eu vi isso na prática quando precisei investigar um incidente de credential exposure em um ambiente híbrido. A equipe de segurança apontou para a AWS, argumentando que a infraestrutura era deles. A AWS respondeu com o relatório de responsabilidade compartilhada para aquela região e serviço específicos, mostrando que o erro estava na política IAM que um desenvolvedor tinha criado sem revisar. A configuração era simples demais para passar despercebida, mas nenhum processo de revisão existia. Nosso workaround foi implementar uma validação obrigatória via policy-as-code com AWS Config rules, e todo recurso que não atendia aos critérios de segurança era automaticamente bloqueado durante o provisioning.
Como mapear as divisões na prática
O primeiro passo é parar de tratar o modelo como algo abstrato. Vá para a documentação do seu provedor e abra a seção de responsabilidade compartilhada específica para cada serviço. Não use um resumo genérico. Cada serviço tem uma tabela diferente. AAWS tem uma página dedicada que lista categoria por categoria. O mesmo vale para Azure e GCP. Anote em um spreadsheet quais controles você precisa assumir para cada serviço que planeja usar. O problema é que essa tarefa é chata e ninguém quer fazer, então naturalmente ela não é feita até gerar dor de cabeça.
As categorias principais são consistentes entre os provedores: Identidade e acesso. Gerenciamento de rede e segurança perimetral. Proteção de dados, incluindo criptografia e backup. Patch management e hardening de sistema operacional. Conformidade e governança específicas da sua carga de trabalho. Monitoramento, logging e resposta a incidentes.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Um detalhe que passa despercebido: a responsabilidade de conformidade regulatória é sempre compartilhada, mas de formas diferentes. O provedor fornece certificações para a infraestrutura física e operacional. O cliente é responsável por garantir que o uso daquela infraestrutura esteja em conformidade com as regulamentações que se aplicam ao seu negócio, como LGPD, HIPAA ou PCI-DSS.
Erros comuns que todo time comete
O erro mais frequente que eu vejo é a suposição de que serviços gerenciados tiram o cliente da responsabilidade. Coisas como CloudWatch, Security Hub ou Azure Monitor são ferramentas que ajudam, mas elas não resolvem a responsabilidade. Se você não configurar alertas, não revisar logs e não agir diante de anomalias, o fato de a ferramenta existir não muda nada. O segundo erro é achar que a responsabilidade do provedor cobre tudo que envolve segurança da informação. Ele garante que o disco físico não pode ser acessado por outra pessoa. Ele não garante que seus dados não foram expostos porque um aplicativo seu tinha uma vulnerabilidade de injection que permitiu acesso não autorizado. Essas são camadas diferentes.
Outro ponto cego é a configuração de saída. Muitos time configuram todos os recursos inicialmente com permissões restritas, mas depois criam automações de deploy que sobrescrevem essas configurações. Já vi um pipeline de Terraform que recriava um grupo de segurança com regras abertas toda vez que o stack era atualizado, invalidando meses de trabalho de securitização. A solução foi adicionar uma regra de validação no pipeline que bloqueava qualquer mudança que abrisse portas para 0.0.0.0/0 sem aprovação explícita.
Quando o modelo falha completamente
O modelo de responsabilidade compartilhada funciona bem para infraestrutura padrão. Ele começa a falhar em cenários complexos. Multicloud é um deles. Quando você espalha workloads entre AWS, Azure e GCP, cada um tem uma tabela de responsabilidade compartilhada ligeiramente diferente. Mapear isso manualmente é impraticável em escala e leva a lacunas onde nenhuma ferramenta de governança consegue cobrir. O outro ponto fraco é workloads que misturam muitos serviços nativos com VMs tradicionais. Um architecture que usa Lambda, API Gateway, DynamoDB, ECS e também instâncias EC2 com Windows gera uma fragmentação enorme de responsabilidades. É preciso rastrear cada serviço individualmente, e a documentação não te dá uma visão unificada.
Para esses casos, ferramentas de CSPM (Cloud Security Posture Management) como Cloudflare, Prisma Cloud ou even soluções open source como checkov ajudam a automatizar parte desse mapeamento. Elas escaneiam configurações e comparam contra benchmarks de segurança, identificando onde as responsabilidades estão sendo negligenciadas. Nenhum deles é perfeito, mas reduzem significativamente o esforço manual.
O que fazer antes de provisionar qualquer recurso
Ação mais prática que existe é criar um padrão de segurança mínimo antes de começar a construir. Defina uma política de tagging obrigatório, uma baseline de grupos de segurança, uma regra de criptografia para todos os storage e listas brancas de IAM roles. Se isso não estiver documentado e automatizado desde o início, o modelo de responsabilidade compartilhada vai te atingir da pior forma possível: após um incidente que podia ter sido evitado. Eu recomendo fortemente que você reserve uma sessão com a equipe de infraestrutura, segurança e desenvolvimento para revisar a tabela de responsabilidade compartilhada do serviço principal que vocês vão usar. Essa sessão leva cerca de duas horas e pode evitar semanas de trabalho correctivo depois.
