Responsabilidade compartilhada na nuvem: o que é seu

A frase aparece em reunião de migração, em conversa de corredor e até em contrato: "está na nuvem, então o provedor cuida". Ela soa razoável. O servidor saiu do armário da empresa e foi para um datacenter com guarda, biometria e equipe de segurança de plantão.

O problema é que a frase mistura duas coisas. O provedor cuida do prédio, do hardware e da rede física. Quem deixou um bucket aberto, uma chave num repositório ou a conta raiz sem MFA foi alguém da sua equipe, e o modelo de responsabilidade compartilhada diz com todas as letras que essa parte é sua.

Os três grandes provedores publicam páginas oficiais explicando essa divisão. Quase ninguém lê antes de migrar, e muita gente só descobre que ela existe depois do primeiro incidente.

A nuvem move a infraestrutura para o provedor, mas deixa com você identidade, dado, configuração e acesso. A maioria dos incidentes em cloud acontece nessa metade que continua sua, e a fronteira muda conforme o serviço seja IaaS, PaaS ou SaaS.

O que os provedores dizem, com as palavras deles

A AWS resume o modelo em duas expressões. Ela cuida da segurança "da" nuvem, e o cliente cuida da segurança "na" nuvem. Na página oficial do modelo, a parte da AWS é a infraestrutura que roda os serviços: hardware, software, rede e instalações. A parte do cliente depende dos serviços que ele escolhe, e a própria AWS escreve que essa escolha define quanto trabalho de configuração fica com o cliente.

A Microsoft é mais direta sobre o que nunca sai da sua mão. A documentação do Azure lista quatro áreas que o cliente mantém em qualquer tipo de implantação: dados, endpoints, contas e gestão de acesso. Isso inclui MFA e acesso condicional.

O Google diz o mesmo em uma frase: o cliente sempre responde pelas políticas de acesso e pelos dados. A página do Google Cloud acrescenta a ideia de "destino compartilhado". Nela o provedor se compromete a entregar modelos seguros, landing zones e ferramentas de governança. O conceito ajuda, mas não transfere a sua parte para o Google.

Os três textos descrevem a mesma responsabilidade compartilhada. O provedor garante a base, e o que você configura em cima dela continua sendo decisão sua.

Como a responsabilidade compartilhada muda entre IaaS, PaaS e SaaS

A fronteira não é fixa. Ela anda conforme o nível de abstração do serviço, e quem ainda confunde os três modelos pode revisar o básico em o que é IaaS, PaaS e SaaS.

A tabela abaixo resume a divisão publicada pela Microsoft. AWS e Google descrevem o mesmo desenho com outras palavras.

A primeira linha é a que importa. Dado, identidade e configuração ficam com o cliente nas três colunas. Nenhum modelo de serviço tira essa linha de você.

No IaaS a lista do cliente é longa. A AWS cita, para instâncias EC2, o sistema operacional convidado com atualizações e patches, os softwares instalados e a configuração do firewall que ela fornece. Em serviços mais abstratos, como armazenamento de objetos, ela assume sistema operacional e plataforma, e o cliente continua responsável pelos dados, pela criptografia, pela classificação e pelo uso das ferramentas de identidade.

No SaaS o Google resume assim: ele fica com a maior parte, e o cliente segue responsável pelos controles de acesso e pelos dados que decide guardar. É pouco em volume, mas é justamente onde os incidentes acontecem.

Os erros que mais aparecem

Os erros abaixo têm uma coisa em comum: todos acontecem na metade da responsabilidade compartilhada que os três provedores atribuem ao cliente. Nenhum deles depende de falha do provedor.

Armazenamento público. Um bucket, um blob ou uma pasta compartilhada fica aberto para a internet porque alguém precisava mandar um arquivo para fora e escolheu o caminho mais rápido. O provedor oferece bloqueio de acesso público. Ligar ou desligar essa opção é decisão de configuração, e configuração é do cliente.

Chave de acesso em repositório. Um desenvolvedor coloca a chave da conta no código para testar, e o código vai para um repositório compartilhado ou público. A chave dá o mesmo poder que a conta tem. Esse é o território de identidade de máquina: contas de serviço, tokens e chaves que ninguém revisa e ninguém revoga.

MFA desligado na conta raiz. A conta que criou o ambiente tem poder total e costuma ficar só com senha, às vezes num e-mail pessoal de quem fez a migração. A Microsoft lista MFA dentro da gestão de acesso que é sempre do cliente. Se o conceito ainda não está claro para a equipe, o texto sobre o que é MFA é um bom ponto de partida.

Log desativado. O registro de atividade existe, mas precisa ser ligado, retido e guardado fora do alcance de quem administra a conta. Sem ele, você não sabe quem criou aquele usuário, de onde veio o acesso nem quando o dado saiu.

Backup inexistente de SaaS "porque o provedor tem". O provedor mantém a plataforma disponível. Isso é diferente de guardar uma cópia sua, que você restaura depois de uma exclusão por engano, de um funcionário que apagou a caixa antes de sair ou de um ransomware que cifrou o drive sincronizado. Pela divisão publicada, proteger o dado é tarefa do cliente.

A responsabilidade compartilhada no contrato e na escolha do provedor

A divisão aparece também antes da migração, na hora de escolher fornecedor e de ler contrato. Os três grandes seguem o mesmo princípio, e as diferenças práticas estão nas ferramentas nativas de identidade, de log e de postura. O comparativo de AWS, Azure e Google Cloud para PMEs ajuda nessa parte.

Com parceiro ou revenda no meio, a responsabilidade compartilhada ganha um terceiro participante. O provedor protege a infraestrutura, o parceiro opera parte da configuração e a empresa continua dona do dado. Sem um documento que diga quem revisa acesso, quem liga log e quem testa restauração, cada um supõe que o outro faz.

A pergunta útil para o contrato é simples: para cada item da primeira linha da tabela, quem é o responsável nominal? Se a resposta for "o provedor", o contrato está errado ou foi mal lido.

Roteiro para a PME que acabou de migrar

Para quem migrou há pouco, a sequência abaixo põe a sua parte da responsabilidade compartilhada em ordem e cobre os erros da seção anterior. Nenhum passo exige ferramenta paga além do que o provedor já entrega.

1. Proteja a conta raiz. Ative MFA, troque o e-mail pessoal por um endereço corporativo controlado pela empresa e pare de usar essa conta no dia a dia.
2. Crie contas nominais com MFA. Cada pessoa com sua identidade e com o menor privilégio que resolve o trabalho dela. Sem login compartilhado.
3. Cace chaves de acesso. Procure chaves em repositórios, scripts e planilhas. Revogue as que aparecerem e troque por papéis ou identidades gerenciadas.
4. Revise o armazenamento. Liste buckets, blobs e compartilhamentos com acesso público e ligue o bloqueio padrão da conta.
5. Ligue e guarde os logs. Ative o registro de atividade da conta, defina retenção e mande uma cópia para um local que o administrador comum não consegue apagar.
6. Faça backup do que está em SaaS. E-mail, drive e CRM precisam de cópia independente. A regra do backup 3-2-1 vale também para dado que nunca esteve num servidor seu.
7. Escreva a matriz de responsabilidade compartilhada da empresa. Uma página com cada camada, o responsável nominal e a data da última revisão.

O passo 7 costuma ser o mais ignorado e o mais útil. Ele transforma um modelo genérico do provedor numa lista com nomes de pessoas.

Quando revisar a divisão

A divisão muda sempre que você troca de serviço. Sair de uma máquina virtual para um banco gerenciado muda a lista. Adotar um SaaS novo muda de novo, e o mesmo vale para um parceiro que passa a operar parte do ambiente.

Por isso a revisão entra no calendário da TI, com data fixa. Uma vez por trimestre basta para a maioria das PMEs: conferir quem tem acesso administrativo, quais chaves existem, se os logs continuam ligados e se a última restauração de teste funcionou.

A sua parte da responsabilidade compartilhada cresce toda vez que alguém liga um serviço novo sem avisar a TI.

O ponto que fica

Os três maiores provedores publicam o modelo de responsabilidade compartilhada em páginas abertas, e nas três a primeira linha é igual: dado, acesso e configuração são do cliente, em IaaS, PaaS e SaaS.

Quem migrou achando que o provedor cuidava de tudo tem uma lista curta para fechar, e quase toda ela cabe numa semana. A AWS, a Microsoft e o Google escreveram a mesma coisa: a conta raiz sem MFA é sua, e a chave esquecida no repositório também.