O caso
Quem apagou a pasta de notas fiscais? O log só mostrava uma conta de serviço.
A loja do Isaac descobriu, numa segunda de manhã, que faltavam arquivos de notas fiscais no armazenamento. A equipe precisava saber quem tinha feito aquilo, e de onde. Sem um registro das ações, a resposta era um palpite.
Este post parte de Segurança e Responsabilidade Compartilhada, que explica quem responde pelo quê e os conceitos de identidade e papel. Também depende da hierarquia de recursos, porque as permissões seguem a árvore de pastas e projetos.
O problema
Permissão demais e registro de menos
Quando todos têm acesso de administrador ao projeto, qualquer erro pode apagar tudo, e ninguém sabe quem fez o quê. O problema não é só a permissão excessiva: é também não ter um registro confiável das ações.
Políticas de IAM
Quem pode fazer o quê, e onde
No Google Cloud, o IAM funciona com uma política (IAM policy) presa a um recurso. A política é uma lista de vínculos: um membro (usuário, grupo ou conta de serviço) recebe um papel naquele recurso.
As políticas são herdadas de cima para baixo. Um papel dado na pasta vale para todos os projetos dentro dela, e um papel dado no projeto vale para todos os recursos dele. Por isso, dar acesso no nível mais alto pode abrir mais do que se pretendia.
Papéis
Três tipos de papel
Básicos (basic roles)
Owner, Editor e Viewer. São amplos demais para produção: um Editor pode alterar quase tudo no projeto.
Predefinidos (predefined roles)
Criados por serviço, com as permissões de uma tarefa. Por exemplo, um papel que só lê objetos do Cloud Storage.
Personalizados (custom roles)
Você monta o papel com as permissões exatas. Dá mais controle, mas exige manutenção quando o serviço muda.
Na loja, o time de atendimento recebe um papel predefinido de leitura no bucket das notas, e nada além disso.
Contas de serviço
Identidade para aplicações
Uma aplicação não é uma pessoa, então ela não usa login de usuário. No Google Cloud, ela recebe uma conta de serviço (service account), uma identidade própria que recebe papéis como qualquer membro.
O erro mais comum é baixar uma chave da conta de serviço e colocá-la no código. A chave pode vazar, e ela não expira sozinha. O caminho recomendado é anexar a conta de serviço ao recurso que roda a aplicação, sem chave no código.
Criptografia e chaves
Os dados já vêm criptografados
O Google Cloud criptografa os dados em repouso por padrão, sem configuração sua. Quem precisa controlar as chaves pode usar o Cloud KMS para criar e girar chaves próprias (CMEK), e definir quem pode usá-las.
Logs de auditoria
Quem fez o quê, e quando
Os Cloud Audit Logs registram ações nos recursos. Os logs de atividade administrativa (quem criou, alterou ou apagou algo) já vêm ativados e não têm custo extra. Os logs de acesso a dados são opcionais na maioria dos serviços (o BigQuery é a exceção), podem gerar custo e precisam ser ligados de propósito.
A loja já tinha os logs de acesso a dados ligados no bucket das notas fiscais. Por isso, a equipe conseguiu ver que a exclusão veio da conta de serviço do sistema de faturamento, num horário de madrugada, e corrigiu a permissão dela.
Termos-chave
Cinco termos para fixar
Toque no cartão para ver a definição.
Teste rápido
Três perguntas, estilo prova
01
Um sistema de pedidos só precisa ler notas fiscais de um bucket. Qual é a forma mais adequada de dar o acesso?
02
A equipe precisa saber qual conta apagou um arquivo num bucket na semana passada. Qual recurso responde isso?
03
A loja quer controlar as chaves que criptografam os dados, e não só usar a criptografia padrão. Qual recurso usar?
Em qualquer prova de nuvem, a pergunta de segurança costuma ser a mesma: quem tem acesso, com qual papel, em qual nível, e como se sabe o que foi feito. No Google Cloud, a resposta passa pela política de IAM, pela conta de serviço e pelos logs de auditoria.