Práticas recomendadas do Secret Manager

Este guia apresenta algumas práticas recomendadas ao usar o Secret Manager. O guia não é uma lista completa de recomendações. Recomendamos consultar a visão geral da plataforma para entender o panorama geral do Google Cloud e a visão geral do Secret Manager antes de ler este guia.

Controle de acesso

O acesso à API Secret Manager é protegido pelo IAM. Siga o princípio do menor privilégio ao conceder permissões a secrets.

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

• Segmente aplicativos e ambientes (preparo ou produção) em projetos separados, conforme descrito em Decidir uma hierarquia de recursos para sua zona de destino do Google Cloud. Isso pode ajudar a isolar ambientes com a vinculação do IAM no nível do projeto e garante que as cotas sejam aplicadas de maneira independente.

• Escolha um papel selecionado com as permissões mínimas necessárias ou crie um papel personalizado, se necessário.

• Quando os secrets de muitos serviços estiverem em um único projeto, use vinculações de IAM de nível secreto ou condições do IAM para limitar o acesso ao subconjunto necessário de secrets.

• O recomendador do IAM pode ajudar ainda mais a identificar vinculações privilegiadas do IAM.

As credenciais são necessárias para a autenticação na API Secret Manager. Todas as bibliotecas de cliente usam uma estratégia semelhante para procurar credenciais chamadas de Application Default Credentials.

• Ao desenvolver localmente, use gcloud auth application-default login. Isso cria um arquivo com credenciais que são coletadas automaticamente pelas bibliotecas de cliente.

• No Compute Engine e em outras plataformas de computação do Google Cloud, como o Cloud Run functions, as bibliotecas de cliente recebem credenciais pelo servidor de metadados da instância.

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

• Em outras plataformas, como a Amazon Web Services ou o Microsoft Azure, configure a federação de identidade da carga de trabalho, que usa mecanismos de identidade atuais para autenticar nas APIs do Google Cloud.

Todos esses métodos são preferenciais para exportar uma credencial da conta de serviço, porque não exigem armazenamento e acesso seguros a um secret extra fora da API Secret Manager.

Práticas de programação

Evite transmitir segredos para seu aplicativo pelo sistema de arquivos ou pelas variáveis de ambiente. Confira alguns motivos para usar outros métodos de processamento de segredos:

• Quando um secret é acessível no sistema de arquivos, as vulnerabilidades do aplicativo, como ataques de transferência de diretórios, podem se tornar de maior gravidade, já que o invasor pode ler o material secreto.

• Quando um secret é consumido por meio de variáveis de ambiente, configurações incorretas, como ativar endpoints de depuração ou incluir dependências que registram detalhes do ambiente de processo, podem vazar secrets.

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

  • O armazenamento de dados expande o acesso do secret?

  • É possível fazer auditoria do acesso ao secret?

  • O repositório de dados atende aos requisitos de criptografia e regionalização de dados em repouso?

Recomendamos usar a API Secret Manager diretamente com uma das bibliotecas de cliente ou seguindo a documentação do REST ou do GRPC.

Administração

Faça referência aos secrets pelo número da versão em vez de usar o alias mais recente. Implante atualizações para números de versão usando os processos de lançamento atuais. Normalmente, isso significa configurar seu aplicativo com uma versão do secret específica que é lida na inicialização. Embora o uso do alias mais recente possa ser conveniente, se houver um problema com a nova versão do secret, a carga de trabalho poderá não ser usada da versão do secret. Ao fixar a um número de versão, a configuração pode ser validada e revertida usando os processos de lançamento atuais.

Desative as versões do secret antes de destruí-las ou excluir segredos. Isso ajuda a evitar interrupções, colocando o secret em um estado que tem a mesma aparência que destruir, mas é reversível. Ou seja, é possível desativar e aguardar uma semana para garantir que não haja dependências restantes antes de excluir dados permanentemente.

Não defina a validade em chaves secretas de produção, a menos que você tenha certeza de que elas devem ser excluídas permanentemente. O recurso de expiração é mais adequado para a limpeza automatizada de ambientes temporários. Considere condições do IAM baseadas em tempo como uma alternativa aos secrets expirados.

Alterne seus secrets periodicamente para fazer o seguinte:

• Limite o impacto em caso de chave secreta vazada.

• Garanta que as pessoas que não precisam mais de acesso a um secret não possam continuar usando um secret acessado anteriormente.

• Reduza a probabilidade de uma interrupção.

Monitore segredos em toda a organização usando o Inventário de recursos do Cloud pelos seguintes motivos:

• Ajude a identificar secrets em toda a organização.

• Identifique a não conformidade com os requisitos da organização, como rotação, configuração de criptografia e local.

Ative os registros de acesso a dados para receber e analisar as informações de solicitação AccessSecretVersion. Ative esse recurso no nível da pasta ou da organização para aplicar a geração de registros sem precisar configurá-lo em cada secret ou projeto.

Além dos controles do IAM, é possível limitar o acesso à API Secret Manager com controles baseados em rede configurando um perímetro do VPC Service Controls para sua organização.

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

Faça uma estimativa do uso máximo do segredo (considerando um rebanho de pedidos de solicitações devido a implantações de aplicativos simultâneas ou escalonamento automático do serviço) e verifique se o projeto tem cota suficiente para processar esse evento. Se for necessário mais cota, solicite um aumento.

Compliance com a residência de dados

Escolha secrets regionais se você tiver requisitos rígidos de residência de dados e soberania. Os segredos regionais permitem armazenar dados confidenciais em um local geográfico específico, oferecendo garantias completas em repouso, em uso e em trânsito, ajudando você a obedecer a requisitos legais, regulamentares ou organizacionais relacionados à residência de dados.