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.

No entanto, para algumas integrações de produtos, como integrações sem servidor, pode transmitir segredos através do sistema de ficheiros ou de variáveis de ambiente. Para mais informações, consulte o artigo [Use o Secret Manager com outros produtos](/secret-manager/docs/using-other-products).

Administração

Escolha a política de replicação automática quando criar segredos, a menos que a sua carga de trabalho tenha requisitos de localização específicos (aplicáveis através da restrição constraints/gcp.resourceLocations).

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.