Práticas recomendadas para gerenciar chaves de contas de serviço

Ao contrário dos usuários normais, as contas de serviço não têm senhas. Elas usam pares de chaves RSA para autenticação: se você souber a chave privada de um par de chaves da conta de serviço, use a chave privada para criar um token do portador JWT e use o token do portador para solicitar um token de acesso. O token de acesso resultante reflete a identidade da conta de serviço, e você pode usá-la para interagir com as APIs do Google Cloud em nome da conta de serviço.

Como a chave privada permite se autenticar como a conta de serviço, ter acesso à chave privada é semelhante a saber qual é a senha de um usuário.

Os pares de chaves usados pelas contas de serviço se enquadram em duas categorias: gerenciadas pelo Google e pelo usuário. Os pares de chaves gerenciados pelo Google e pelo usuário diferem no local em que a chave privada é armazenada, como elas podem ser usados para autenticação e como precisam ser protegidas:

  • Os pares de chaves gerenciados pelo Google são gerados automaticamente e são totalmente gerenciadas pelo gerenciamento de identidade e acesso. O IAM mantém pares de chaves gerenciadas pelo Google para todas as contas de serviço e as rotaciona periodicamente. É possível fazer o download da chave pública de um par de chaves gerenciado pelo Google, mas não é possível acessar a chave privada dele.

    Para usar a chave privada de um par de chaves gerenciado pelo Google, solicite ao IAM que execute operações para você. Por exemplo, é possível invocar as operações signBlob ou signJwt para permitir que o IAM use a chave privada de uma conta de serviço gerenciada pelo Google para assinar um dado para você. Da mesma forma, ao anexar uma conta de serviço a um recurso de computação, você pode autorizar o IAM a usar a chave gerenciada pelo Google sempre que o recurso de computação solicitar credenciais da conta de serviço.

    Solicitar ao IAM para usar a chave privada gerenciada pelo Google de uma conta de serviço requer permissões especiais. Por exemplo, para invocar signBlob, você precisa ter a permissão iam.serviceAccounts.signBlob na respectiva conta de serviço. Da mesma forma, para anexar uma conta de serviço a um recurso de computação, é preciso ter a permissão iam.serviceAccounts.actAs. Para proteger a conta de serviço e proteger contra ameaças de escalonamento de privilégios, você precisa garantir que apenas usuários autorizados recebam papéis que incluam essas permissões.

  • Pares de chaves gerenciadas pelo usuário são pares de chaves adicionais que você pode associar a uma conta de serviço fazendo upload de uma chave pública ou permitindo que o IAM gere uma par de chaves para você. Em ambos os casos, o IAM só armazena a chave pública enquanto você é o proprietário da chave privada.

    A chave privada, com alguns metadados, é chamada de chave da conta de serviço e geralmente é armazenada no formato JSON.

    Como você detém a chave privada, é sua a responsabilidade de mantê-la em sigilo, armazenando-a com segurança, e alterná-la periodicamente. Qualquer pessoa capaz de acessar a chave privada pode usá-la para criar um token do portador JWT e fazer a autenticação como essa conta de serviço.

As chaves da conta de serviço podem se tornar um risco de segurança se não forem gerenciadas com cuidado. As principais ameaças relacionadas às chaves da conta de serviço são:

  • Vazamento de credenciais: as chaves da conta de serviço podem acabar em locais onde não deveriam ser armazenadas. Um usuário mal-intencionado pode usar uma chave de conta de serviço vazada para autenticar e ter acesso ao seu ambiente.
  • Escalonamento de privilégios: se um usuário mal-intencionado tiver acesso a uma chave de conta de serviço protegida insatisfatoriamente, ele poderá usá-la para escalonar privilégios.
  • Divulgação de informações: as chaves da conta de serviço podem divulgar metadados confidenciais acidentalmente.
  • Não repúdio: ao autenticar usando uma chave de conta de serviço e permitir que a conta de serviço realize operações em nome dela, um usuário mal-intencionado pode ocultar a identidade e as ações dele.

A melhor maneira de atenuar essas ameaças é evitar chaves de conta de serviço gerenciadas pelo usuário e usar outros métodos para autenticar contas de serviço sempre que possível. Também é possível usar condições do IAM e o VPC Service Controls para restringir quais recursos podem ser acessados por uma conta de serviço comprometida.

Para situações em que o uso de métodos de autenticação alternativos não é viável, este guia apresenta as práticas recomendadas para gerenciar, usar e proteger chaves de conta de serviço.

Como se proteger contra vazamento de credenciais

Assim como um nome de usuário e uma senha, as chaves de conta de serviço são uma forma de credenciais. Se um usuário puder acessar uma chave de conta de serviço válida, ele poderá usá-la para autenticar e acessar os recursos aos quais a respectiva conta de serviço recebeu acesso.

Para usuários mal-intencionados, as chaves da conta de serviço são ainda mais valiosas do que uma senha vazada: é improvável que a tentativa de login usando uma senha vazada funcione se a conta de usuário tiver sido configurada para usar a verificação em duas etapas e os desafios de login. Por outro lado, a autenticação usando uma chave de conta de serviço vazada provavelmente funcionará, uma vez que as contas de serviço não estão sujeitas a outras verificações de login.

Os usuários mal-intencionados podem procurar chaves de conta de serviço em vários lugares, incluindo:

  • repositórios de código-fonte de projetos de código aberto;
  • buckets públicos do Cloud Storage;
  • despejos de dados públicos de serviços violados.

Além dos locais públicos, os usuários mal-intencionados podem procurar chaves de conta de serviço em locais particulares comprometidos por eles. Por exemplo:

  • caixas de entrada de e-mail;
  • Compartilhamento de arquivos
  • Armazenamento de backup
  • diretórios do sistema de arquivos temporários.

Uma maneira eficaz de reduzir o risco de vazamento de chaves de conta de serviço é reduzir o número de chaves em circulação e desencorajar a criação de novas chaves. As seções a seguir descrevem como limitar o número de chaves de conta de serviço em circulação e quais outras medidas podem ajudar a limitar o risco de vazamentos de contas de serviço.

Oferecer alternativas para criar chaves de conta de serviço

Tentar reduzir o número de chaves de conta de serviço em circulação pode ser um desafio se os usuários da organização acharem mais fácil criar novas chaves de conta de serviço do que usar alternativas mais seguras.

Para evitar que as chaves da conta de serviço sejam criadas por conveniência, certifique-se de que os usuários estejam cientes das alternativas ao uso das chaves da conta de serviço e de que eles consigam usar esses métodos alternativos se precisarem:

Depois de garantir que os usuários podem usar métodos alternativos para autenticar contas de serviço, use as restrições da política da organização para limitar o uso de chaves de conta de serviço a projetos selecionados.

Usar restrições da política da organização para limitar quais projetos podem criar chaves de conta de serviço

Há várias maneiras de evitar a necessidade de criar chaves de conta de serviço, incluindo anexar uma conta de serviço a um recurso, usando a Identidade da carga de trabalho ou a Federação de identidade da carga de trabalho. Considerando essas alternativas, é melhor considerar o uso de chaves de conta de serviço como uma exceção em vez da norma.

Para evitar o uso desnecessário de chaves de conta de serviço, use restrições da política da organização:

A modificação das restrições da política da organização requer a permissão orgpolicy.policy.set. Como o papel de Proprietário (roles/owner) e Editor (roles/editor) não incluem essa permissão, as restrições também podem ser eficazes em ambientes de não produção em que alguns principais podem ter acesso de Proprietário ou Editor aos projetos.

Não deixar chaves de conta de serviço em locais temporários

Quando uma chave de conta de serviço é criada usando o Console do Google Cloud, a maioria dos navegadores faz o download imediato da nova chave e a salva em uma pasta de download no computador. Envie a chave imediatamente para o local onde você quer armazená-la. Confira se você não está deixando acidentalmente uma cópia na pasta de downloads ou na lixeira do computador.

O risco de deixar cópias de chaves da conta de serviço acidentalmente em locais temporários pode ser reduzido usando a ferramenta de linha de comando gcloud: o comando gcloud iam service-accounts keys create permite gravar o arquivo de chave da conta de serviço diretamente no local onde você precisa dele. Além disso, na maioria dos sistemas operacionais, a ferramenta gcloud ajusta automaticamente as permissões de arquivos para que o arquivo só seja acessível por você.

Não transmitir chaves de conta de serviço entre usuários

Ao implantar um aplicativo que requer uma chave de conta de serviço, talvez você não tenha permissão para criar uma chave de conta de serviço, sendo necessário solicitar a uma outra pessoa para criar uma chave de conta de serviço para você.

Em cenários em que vários usuários estão envolvidos na criação e implantação de uma chave de conta de serviço, há um risco maior de as cópias da chave permanecerem em caixas de e-mails, históricos de chat ou outros locais. Sempre que uma transferência entre os usuários for necessária, pode ser mais seguro fazer upload de uma chave de conta de serviço:

  1. Como o usuário que está implantando o aplicativo, crie um certificado autoassinado que usa um par de chaves RSA de 2.048 bits na máquina de destino. Para criar o certificado, use openssl, certutil, New-SelfSignedCertificate ou outras ferramentas do sistema operacional.
  2. Transmita o arquivo de certificado para o usuário que tem a permissão para fazer upload do certificado, mantendo a chave privada na máquina de destino. Ao transmitir o certificado, assegure-se de que ele não possa ser substituído ou adulterado, mas não é necessário mantê-lo em sigilo.
  3. Como o usuário que tem as permissões necessárias para gerenciar chaves de conta de serviço, faça upload do certificado para associá-lo a uma conta de serviço.

Ao seguir esse processo, você evita transmitir a chave privada e só troca informações públicas entre os usuários.

Não enviar chaves de contas de serviço a repositórios de código-fonte

As chaves da conta de serviço são credenciais e precisam ser protegidas contra acesso não autorizado. Quando você envia uma chave de conta de serviço para um repositório de código-fonte, há um risco maior de a chave ficar acessível a usuários não autorizados e usuários mal-intencionados:

  • Usuários mal-intencionados podem verificar o código-fonte dos repositórios de origem pública em busca de chaves vazadas.
  • No futuro, você pode optar por transformar um repositório de origem particular em um repositório público, sem antes verificar se há chaves nele.
  • Outros membros da equipe podem armazenar cópias do código-fonte nas estações de trabalho deles.

Ao trabalhar com código que usa uma chave de conta de serviço, sempre armazene a chave da conta de serviço separada do código-fonte para reduzir o risco de enviar acidentalmente a chave para o repositório de origem. Em muitos casos, é possível reduzir ainda mais esse risco não usando chaves de conta de serviço durante o desenvolvimento e usando as credenciais pessoais em vez de chaves de conta de serviço.

Além disso, configure o sistema de controle de origem para que ele detecte envios acidentais de chaves de conta de serviço:

Não incorporar chaves de conta de serviço em binários do programa

As chaves da conta de serviço são strings que correspondem a um determinado padrão. Elas podem ser identificadas mesmo que estejam incorporadas em outros arquivos ou binários. Se um usuário mal-intencionado tiver acesso ao binário, ele poderá extrair todas as chaves de conta de serviço incorporadas no binário.

Os binários do programa para aplicativos do lado do servidor podem ser hospedados em repositórios de artefatos ou copiados para as estações de trabalho de desenvolvedores para fins de depuração. Manter as chaves da conta de serviço separadas dos binários do programa ajuda a garantir que um usuário com acesso ao binário não consiga acessar implicitamente as credenciais da conta de serviço.

  • Para aplicativos do lado do cliente, como ferramentas, programas para computador ou apps para dispositivos móveis, não use contas de serviço. Deixe que os usuários se autentiquem com as próprias credenciais usando o fluxo de consentimento do OAuth.
  • Para aplicativos do lado do servidor, não incorpore chaves de conta de serviço no binário. Mantenha as chaves separadas do binário do aplicativo.

Usar insights e métricas para identificar chaves de contas de serviço não utilizadas

Para minimizar o número de chaves de conta de serviço válidas em circulação, é melhor desativar as chaves assim que elas não forem mais necessárias e, em seguida, excluí-las quando você tiver certeza de que elas não são mais necessárias. Se você não tiver certeza se uma chave ainda está em uso ou não, use os insights da conta de serviço e as métricas de autenticação:

Como as contas de serviço pertencem a um projeto do Google Cloud, os insights e as métricas precisam ser rastreados individualmente para cada projeto.

Fazer a rotação de chaves da conta de serviço para reduzir os possíveis danos causados pelas chaves vazadas

Embora seja possível reduzir a probabilidade de vazamento acidental de uma chave de conta de serviço, pode ser difícil eliminar o risco completamente.

Se uma chave vazar, os usuários mal-intencionados não conseguirão encontrá-la imediatamente. Talvez leve vários dias ou semanas para que alguém a encontre. Você pode aproveitar esse atraso invalidando periodicamente as chaves da conta de serviço e substituindo-as por novas chaves: quanto mais frequentemente você rotacionar as chaves da conta de serviço, menor será a probabilidade de uma chave de conta de serviço vazada ainda ser válida quando um usuário mal-intencionado encontrá-la.

Para fazer a rotação das chaves, siga um modelo baseado em push ou pull:

  • Em um modelo baseado em push, você usa uma ferramenta ou sistema centralizado que cria periodicamente novas chaves de conta de serviço e as envia aos aplicativos individuais para substituir as chaves existentes. Em seguida, a ferramenta exclui as chaves de conta de serviço obsoletas.

    Neste modelo, somente a ferramenta central requer permissões para criar ou fazer upload de novas chaves de conta de serviço, mas requer essas permissões para todas as contas de serviço que gerencia.

  • Em um modelo baseado em pull, cada aplicativo faz a própria rotação de chaves. Periodicamente, o aplicativo usa a API IAM para criar ou fazer upload de uma nova chave de conta de serviço durante a autenticação com a chave existente. Depois de receber uma nova chave de conta de serviço, o aplicativo exclui a chave anterior.

    Nesse modelo, a conta de serviço de cada aplicativo precisa ter permissão para criar ou fazer upload de novas chaves de conta de serviço, mas apenas para si mesma.

Usar chaves carregadas para permitir que as chaves expirem automaticamente

As chaves da conta de serviço que você cria e faz o download pelo IAM não têm uma data de validade e não perdem a validade até que sejam excluídas.

É possível limitar a validade das chaves da conta de serviço fazendo upload de uma chave de conta de serviço e especificando uma data Válida até no arquivo de certificado X.509. Após a data de validade, a chave não poderá mais ser usada para autenticação, mas permanecerá associada à conta de serviço até que você a exclua.

Limitar a validade das chaves da conta de serviço pode limitar o risco de segurança e funcionar como uma segurança contra falhas se a rotação de chaves falhar. Ao mesmo tempo, limitar a validade das chaves aumenta o risco de falha do aplicativo causada por uma chave que não foi renovada a tempo.

Como se proteger contra o escalonamento de privilégios

O uso de chaves de conta de serviço poderá expor você a ataques de escalonamento de privilégios se as chaves forem menos seguras do que os recursos a que dão acesso.

Por exemplo, suponha que um usuário mal-intencionado já tenha conseguido adentrar o ambiente e agora esteja tentando acessar determinados recursos do Google Cloud. Talvez ele ainda não tenha as permissões para acessar esses recursos, mas com os privilégios que detém consiga acessar uma chave de conta de serviço armazenada em uma VM, compartilhamento de arquivos ou outro local menos seguro. Ao autenticar usando a chave da conta de serviço, o usuário mal-intencionado pode assumir a identidade da conta de serviço. A conta de serviço pode permitir que o usuário mal-intencionado acesse recursos a que não tinha acesso anteriormente e, assim, escalone os privilégios dele.

Como uma chave de conta de serviço concede indiretamente acesso a recursos no Google Cloud, você precisa considerá-la tão valiosa, e digna de proteção, quanto os recursos.

As seções a seguir descrevem as práticas recomendadas para proteger as chaves da conta de serviço e reduzir o risco de acesso não autorizado e o escalonamento de privilégios resultante.

Evitar armazenar chaves em um sistema de arquivos

As chaves de conta de serviço criadas usando o Console do Google Cloud ou a ferramenta gcloud são arquivos JSON. É possível copiar esses arquivos para o sistema de arquivos da máquina em que são necessários. No entanto, armazenar chaves de conta de serviço como arquivos em um sistema de arquivos pode expor você a vários riscos, incluindo:

  • Alguns sistemas de arquivos, como o NTFS, usam permissões herdadas por padrão. A menos que desativada, uma permissão adicionada a uma pasta mãe pode acidentalmente fazer com que um arquivo de chave fique mais amplamente acessível e visível a usuários não autorizados.
  • Em um ambiente virtualizado, os usuários mal-intencionados podem prejudicar a segurança do sistema de arquivos acessando o disco virtual subjacente.
  • As alterações de acesso e permissão do sistema de arquivos geralmente não são registradas em auditoria. Se as permissões do arquivo forem alteradas acidentalmente e a chave ficar visível para usuários não autorizados, pode ser difícil analisar quando e por quem essas alterações foram feitas.
  • Os arquivos podem ser facilmente copiados e, portanto, exfiltrados se um usuário mal-intencionado ganhar acesso.

Sempre que possível, evite armazenar chaves de contas de serviço em um sistema de arquivos. Se não for possível evitar o armazenamento de chaves em disco, restrinja o acesso ao arquivo de chave, configure a auditoria de acesso a arquivos e criptografe o disco subjacente.

Usar um HSM ou TPM para armazenar chaves

Quando você cria uma chave de conta de serviço usando o Console do Google Cloud ou a ferramenta gcloud, a chave privada é gerada pelo Google Cloud e revelada a você. Muitos riscos de segurança associados a chaves de conta de serviço estão relacionados ao fato de que a chave privada está, temporária ou permanentemente, disponível em texto legível, por isso, pode ser difícil de proteger.

Em vez de permitir que o Google Cloud gere um par de chaves, você pode usar um módulo de segurança de hardware (HSM, na sigla em inglês) ou um módulo de plataforma confiável (TPM, na sigla em inglês) para criar e gerenciar chaves:

  1. Use um HSM ou TPM para gerar um par de chaves RSA.
  2. Use o par de chaves para criar um certificado autoassinado.
  3. Faça upload do certificado como uma chave de conta de serviço.
  4. Deixe o aplicativo usar a API de assinatura do HSM ou do TPM para assinar o JWT para autenticar a conta de serviço.

Um HSM ou TPM permite usar uma chave privada sem revelar a chave em texto legível. Portanto, o uso de um HSM ou TPM para gerenciar chaves de contas de serviço ajuda a aplicar o controle de acesso e reduzir o risco de cópias de chaves para outros sistemas.

Algumas plataformas fornecem abstrações que permitem aproveitar um TPM sem precisar interagir diretamente com ele. Por exemplo, o Windows permite gerenciar chaves protegidas por TPM usando a API CryptoNG em combinação com o Microsoft Platform Crypto Provider.

As chaves da conta de serviço gerenciadas por um TPM são exclusivas de uma máquina física ou virtual. Ainda é possível permitir que várias máquinas compartilhem uma conta de serviço associando a chave de cada máquina a uma conta de serviço comum.

Usar um armazenamento de chaves baseado em software

Em situações em que o uso de um armazenamento de chaves baseado em hardware não for viável, use um armazenamento de chaves baseado em software para gerenciar as chaves da conta de serviço. Assim como as opções baseadas em hardware, um armazenamento de chaves baseado em software permite que usuários ou aplicativos usem chaves de conta de serviço sem revelar a chave privada. As soluções de armazenamento de chaves baseadas em software ajudam a controlar o acesso às chaves de maneira detalhada e garantem que cada acesso de chave seja registrado.

A segurança de um armazenamento de chaves baseado em software normalmente depende de como a chave mestra está protegida. Antes de usar um armazenamento de chaves baseado em software, revise:

  • como a chave mestra é protegida em repouso;
  • como funciona o processo de desbloqueio e quem pode iniciá-lo;
  • como as chaves são protegidas contra o ato de serem extraídas da memória;
  • como o armazenamento de chaves é protegido de ficar comprometido se um usuário mal-intencionado ganhar acesso de shell ou hipervisor ao sistema subjacente.

Não armazenar chaves no Secret Manager ou em outros armazenamentos de secrets baseados na nuvem

O Google Cloud e outros provedores de nuvem fornecem armazenamentos de chaves gerenciadas que permitem gerenciar vários tipos de secrets. Os exemplos incluem o Secret Manager, o Azure KeyVault ou o AWS Secret Manager. Se você armazenar uma chave de conta de serviço em um desses armazenamentos de chaves, deverá usar o sistema IAM do provedor de nuvem para controlar o acesso ao secret. Em vez de usar o IAM para controlar o acesso a um secret, que concede acesso aos recursos no Google Cloud, use a federação de Identidade da carga de trabalho para gerenciar o acesso sem criar uma chave de conta de serviço.

Não usar o papel de Editor em projetos que permitem a criação ou o upload de chaves de conta de serviço

Uma diferença fundamental entre os papéis básicos de Editor (roles/editor) e de Proprietário (roles/owner) é que o papel de Editor não permite alterar políticas ou papéis do IAM. Com o papel de Editor, não é possível estender facilmente o próprio acesso ou conceder a outros usuários acesso aos recursos do projeto.

As limitações do papel de Editor podem ser reduzidas se um projeto contiver contas de serviço. Como os papéis de Editor concedem permissão para criar ou fazer upload de chaves de contas de serviço, um usuário mal-intencionado pode criar novas chaves para contas de serviço existentes e usá-las para escalonar o próprio acesso ou passá-las para outros usuários para obter acesso aos recursos do projeto.

Em vez de usar o papel de Editor ou qualquer outro papel básico, é melhor usar os papéis predefinidos mais restritos ou criar papéis personalizados que concedam apenas permissões necessárias.

Se você precisar usar o papel de Editor, desative o upload de chave da conta de serviço e a criação de chaves usando restrições de política da organização para ajudar a garantir que o papel de Editor não possa ser abusado para escalonamento de privilégios.

Evitar o uso de chaves de conta de serviço na delegação em todo o domínio

A delegação em todo o domínio permite personificar um usuário para que você consiga acessar os dados de um usuário sem qualquer autorização manual da parte dele. Embora exemplos que ilustram o uso da delegação em todo o domínio geralmente sugiram o uso de chaves de contas de serviço, este uso não é necessário para realizar a delegação em todo o domínio.

Ao usar a delegação em todo o domínio, evite chaves de conta de serviço e use a API signJwt:

  1. Autentique uma conta de serviço usando uma conta de serviço anexada, Identidade da carga de trabalho ou Federação de identidade da carga de trabalho primeiro.
  2. Crie um JWT e use a declaração sub para especificar o endereço de e-mail do usuário a que você está solicitando acesso delegado.
  3. Use a API signJwt para assinar o JWT.
  4. Transmita o JWT assinado para o recurso de token OAuth2 para conseguir um token de acesso.

Ao seguir essa abordagem, você evita ter que gerenciar uma chave de conta de serviço, resultando em uma configuração que pode ser protegida com mais facilidade.

Proteção contra ameaças de divulgação de informações

Evitar divulgar informações confidenciais em certificados X.509 enviados

Para cada chave de conta de serviço, o IAM permite fazer o download de um certificado X.509 pelo endpoint https://www.googleapis.com/service_accounts/v1/metadata/x509/ACCOUNT_EMAIL. Este endpoint é público e não requer autenticação.

Para chaves gerenciadas pelo Google e pelo usuário que você criou usando o Console do Google Cloud ou a ferramenta gcloud, os certificados X.509 são criados automaticamente e contêm apenas metadados básicos, como o endereço de e-mail e data de validade.

Para chaves de conta de serviço enviadas, o certificado X.509 fornecido pelo endpoint público é o mesmo certificado que você enviou. Se o certificado enviado contiver quaisquer atributos opcionais (como informações de endereço ou local incorporadas no nome comum), essas informações também ficarão publicamente acessíveis. Um usuário mal-intencionado pode usar essas informações para descobrir mais sobre o ambiente.

Para evitar a divulgação de informações confidenciais, não adicione atributos opcionais aos certificados X.509 enviados e use um Subject genérico.

Proteção contra ameaças de não repúdio

Quando você perceber atividades suspeitas que afetam os recursos do Google Cloud e quiser analisar as origens delas, precisará de dados que permitam reconstruir a cadeia de eventos que levaram às atividades suspeitas. A fonte principal de dados para realizar essa análise geralmente são registros de auditoria.

A análise de registros de auditoria pode se tornar mais difícil quando contas de serviço estão envolvidas: se uma atividade foi iniciada por uma conta de serviço, a entrada de registro conterá o endereço de e-mail da conta de serviço, mas você também precisa descobrir qual usuário ou aplicativo estava usando a conta de serviço no momento.

As seções a seguir contêm as práticas recomendadas para o uso das chaves de conta de serviço para ajudar a rastrear o uso delas.

Usar uma conta de serviço dedicada para cada aplicativo

Todos os registros de auditoria contêm um campo principalEmail que identifica o principal que iniciou a atividade. Se você compartilhar uma chave de conta de serviço em vários aplicativos, poderá ser difícil identificar qual aplicativo realizou uma atividade porque os registros de auditoria contêm o mesmo valor principalEmail.

Em vez de compartilhar uma chave entre vários aplicativos, crie uma conta de serviço dedicada para cada aplicativo. Dessa forma, o campo principalEmail permitirá identificar o aplicativo associado a uma conta de serviço, o que pode ajudar a reconstruir a cadeia de eventos que levaram a uma atividade suspeita.

Usar uma chave dedicada para cada máquina que executa um aplicativo

Se você executar várias cópias do mesmo aplicativo em várias máquinas, o campo principalEmail poderá permitir que você identifique o aplicativo, mas não a máquina de origem de uma determinada atividade.

Para ajudar a restringir as possíveis fontes de atividade suspeita, crie chaves individuais para cada cópia do aplicativo. Dessa forma, você poderá usar o campo serviceAccountKeyName que muitos serviços adicionam aos registros de auditoria para distinguir a máquina de origem de uma atividade.

A seguir