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 que você consulte visão geral da plataforma para entender o cenário geral do Google Cloud e as 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.

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

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 definidos 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 secrets ao aplicativo pelo sistema de arquivos ou pelo ambiente. variáveis. 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 travessia de diretórios, podem se tornar mais graves à medida podem ganhar a capacidade de 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 um material secreto com outro repositório de dados (como o Kubernetes) Secrets), 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 obedece à criptografia de dados em repouso e requisitos de regionalização?

Recomendamos o uso direto da API Secret Manager com um dos bibliotecas de cliente fornecidas ou seguindo a REST ou Documentação de GRPC (em inglês).

Administração

Referenciar secrets pelos respectivos 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 a configuração do aplicativo com uma versão específica do secret que é lida na inicialização. Embora o uso do método o alias mais recente pode ser conveniente. Se houver algum problema com a nova versão do secret, o carga de trabalho pode não conseguir usar a 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 destruindo ou excluindo secrets. 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.

Girar periodicamente seus secrets para fazer o seguinte:

• Limite o impacto em caso de chave secreta vazada.

• Impeça as pessoas que não precisam mais de acesso a um secret usar um secret já acessado.

• Reduza a probabilidade de uma interrupção do serviç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.

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

Ative os registros de acesso a dados para coletar e analisar as informações da solicitação AccessSecretVersion. Ative isso na pasta ou no nível da organização para aplicar a geração de registros sem precisar configurá-la em todos os secrets ou projetos.

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.

Estime seu pico de uso de segredos, considerando um rebanho de trovões. de solicitações devido a implantações simultâneas de aplicativos ou escalonamento automático do seu serviço) e garantir que seu projeto tem cota suficiente para lidar com esse evento. Se for necessário mais cota, solicite um aumento.

Compliance com a residência de dados

Escolha secrets regionais se você tiver uma residência de dados rígida e soberania de dados. Os secrets regionais permitem armazenar dados sensíveis em uma região geográfica específica local, fornecendo garantias completas em repouso, em uso e em trânsito, ajudando você a obedecer a leis, regulatórias ou organizacionais relacionadas à residência de dados.