Práticas recomendadas do Secret Manager

Este guia apresenta algumas práticas recomendadas ao usar o Secret Manager. Este guia não é uma lista exaustiva de recomendações. Recomendamos que reveja a vista geral da plataforma para compreender o panorama Google Cloud geral e a vista geral do Secret Manager antes de ler este guia.

Controlo de acesso

O acesso à API Secret Manager está protegido pela IAM. Siga o princípio do menor privilégio ao conceder autorizações a segredos.

• Limite a propriedade da organização a uma conta de superadministrador segura.

• Segmente as aplicações e os ambientes (preparação ou produção) em projetos separados, conforme descrito em Decida uma hierarquia de recursos para a sua Google Cloud zona de destino. Isto pode ajudar a isolar ambientes com a associação do IAM ao nível do projeto e garante que as quotas são aplicadas de forma independente.

• Escolha uma função organizada com as autorizações mínimas necessárias ou crie uma função personalizada se necessário.

• Quando os segredos de muitos serviços estão num único projeto, use associações de IAM de nível de segredo ou condições de IAM para limitar o acesso ao subconjunto de segredos necessário.

• O Recomendador de IAM pode ajudar ainda mais na identificação de associações de IAM com privilégios excessivos.

São necessárias credenciais para a autenticação na API Secret Manager. As bibliotecas de cliente usam todas uma estratégia semelhante para procurar credenciais referidas como Credenciais padrão da aplicação.

• Quando desenvolver localmente, use gcloud auth application-default login. Isto cria um ficheiro com credenciais que são automaticamente recolhidas pelas bibliotecas de cliente.

• No Compute Engine e noutras Google Cloud plataformas de computação, como as funções do Cloud Run, as bibliotecas de cliente obtêm credenciais através do servidor de metadados de instâncias.

• No GKE, a identidade da carga de trabalho também fornece credenciais através de um serviço de metadados.

• Noutras plataformas, como o Amazon Web Services ou o Microsoft Azure, considere configurar a federação de identidades da carga de trabalho, que usa mecanismos de identidade existentes para autenticar em Google Cloud APIs.

Todos estes métodos são preferíveis à exportação de uma credencial de conta de serviço, porque não requerem o armazenamento e o acesso seguros a um segredo adicional fora da API Secret Manager.

Práticas de programação

Evite transmitir segredos à sua aplicação através do sistema de ficheiros ou das variáveis de ambiente. Seguem-se alguns motivos para usar outros métodos de processamento de segredos:

• Quando um segredo está acessível no sistema de ficheiros, as vulnerabilidades da aplicação, como ataques de atravessamento de diretórios, podem tornar-se de maior gravidade, uma vez que o atacante pode obter a capacidade de ler o material secreto.

• Quando um segredo é consumido através de variáveis de ambiente, as configurações incorretas, como a ativação de pontos finais de depuração ou a inclusão de dependências que registam detalhes do ambiente de processamento, podem divulgar segredos.

• Quando sincronizar material secreto com outro repositório de dados (como segredos do Kubernetes), avalie os controlos de acesso fornecidos por esse repositório de dados. Considere o seguinte:

  • O armazenamento de dados expande o acesso ao segredo?

  • É possível auditar o acesso ao segredo?

  • O repositório de dados está em conformidade com os seus requisitos de encriptação de dados em repouso e regionalização?

Recomendamos que use a API Secret Manager diretamente através de uma das bibliotecas cliente fornecidas ou seguindo a documentação REST ou GRPC.

Administração

Referencie os segredos pelo respetivo número da versão em vez de usar o alias mais recente. Implemente atualizações aos números de versão através dos seus processos de lançamento existentes. Normalmente, isto significa configurar a sua aplicação com uma versão secreta específica que é lida no arranque. Embora a utilização do alias mais recente possa ser conveniente, se houver um problema com a nova versão do segredo, a sua carga de trabalho pode ficar impossibilitada de usar a versão do segredo. Ao fixar um número de versão, a configuração pode ser validada e revertida através dos seus processos de lançamento existentes.

Desative as versões do Secret antes de as destruir ou eliminar segredos. Isto ajuda a evitar indisponibilidades ao colocar o segredo num estado que parece igual ao de destruição, mas é reversível. Ou seja, pode desativar e aguardar uma semana para se certificar de que não existem dependências pendentes antes de eliminar permanentemente os dados.

Não defina a expiração em segredos de produção, a menos que tenha a certeza de que devem ser eliminados irreversivelmente. A funcionalidade de expiração é mais adequada para a limpeza automática de ambientes temporários. Considere as condições de IAM baseadas no tempo como uma alternativa aos segredos com prazo de validade.

Rode periodicamente os seus segredos para fazer o seguinte:

• Limitar o impacto no caso de um código secreto divulgado.

• Certifique-se de que os indivíduos que já não precisam de acesso a um segredo não podem continuar a usar um segredo acedido anteriormente.

• Reduzir a probabilidade de uma indisponibilidade.

Monitorize segredos na sua organização através do Cloud Asset Inventory pelos seguintes motivos:

• Ajudar a identificar segredos em toda a sua organização.

• Identificar a não conformidade com os requisitos da organização, como a rotação, a configuração de encriptação e a localização.

Ative os registos de acesso a dados para obter e analisar as informações de pedido AccessSecretVersion. Ative esta opção ao nível da pasta ou da organização para aplicar o registo sem ter de o configurar em todos os segredos ou projetos.

Além dos controlos de IAM, pode limitar o acesso à API Secret Manager com controlos baseados na rede configurando um perímetro dos VPC Service Controls para a sua organização.

A política de organização pode ser usada para limitar as identidades que podem ser adicionadas às políticas de IAM para segredos.constraints/iam.allowedPolicyMemberDomains

Estime a sua utilização secreta máxima (considerando uma multidão de pedidos devido a implementações de aplicações simultâneas ou ao escalamento automático do seu serviço) e certifique-se de que o seu projeto tem quota suficiente para processar um evento deste tipo. Se precisar de mais quota, peça um aumento.

Conformidade com a residência dos dados

Escolha segredos regionais se tiver requisitos rigorosos de residência e soberania dos dados. Os segredos regionais permitem-lhe armazenar dados confidenciais numa localização geográfica específica, oferecendo garantias completas em repouso, em utilização e em trânsito, o que ajuda a agir em conformidade com os requisitos legais, regulamentares ou organizacionais relativos à residência dos dados.