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. A chave privada é conhecida como chave da conta de serviço. Os pares de chaves usados pelas contas de serviço se enquadram em duas categorias: gerenciadas pelo Google e gerenciadas pelo usuário.

As chaves da conta de serviço podem se tornar um risco de segurança se não forem gerenciadas com cuidado. Você deve escolher uma alternativa mais segura para a autenticação sempre que possível. 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 não é possível usar alternativas mais seguras para as chaves da conta de serviço, este guia apresenta as práticas recomendadas para gerenciar, usar e proteger as chaves da 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.

Práticas recomendadas:

Oferecer alternativas para criar chaves de conta de serviço.
Usar restrições da política da organização para limitar quais projetos podem criar chaves de conta de serviço.
Não deixar chaves de conta de serviço em locais temporários.
Não transmitir chaves de conta de serviço entre usuários.
Não enviar chaves de contas de serviço a repositórios de código-fonte.
Não incorporar chaves de conta de serviço em binários do programa.
Usar insights e métricas para identificar chaves de contas de serviço não utilizadas.
Rotacionar chaves da conta de serviço para reduzir o risco de segurança causado por vazamentos de chaves.
Use prazos de validade para permitir que as chaves expirem automaticamente.
Use as restrições da política da organização para desativar automaticamente chaves vazadas.

Oferecer alternativas para criar chaves de conta de serviço

Verifique se os usuários na sua organização estão cientes de alternativas e podem justificar a sobrecarga adicional de risco e gerenciamento do uso de uma chave de conta de serviço:

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

Considerando as alternativas mais seguras às chaves de contas de serviço, é melhor considerar o uso de chaves de contas 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 iam service-accounts keys create: o comando 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 CLI 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.

Rotacionar chaves da conta de serviço para reduzir o risco de segurança causado por vazamentos de chaves

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.

A rotação de chaves é o processo de substituir as chaves existentes por novas e, em seguida, invalidar as chaves substituídas. Recomendamos que você faça a rotação de todas as chaves que gerencia, incluindo as chaves da conta de serviço.

A rotação de chaves da conta de serviço pode ajudar a reduzir o risco representado por chaves vazadas ou roubadas. Se uma chave vazar, pode levar usuários ou pessoas mal-intencionadas a descobrir a chave. Se você alterna regularmente as chaves da sua conta de serviço, há uma chance maior de que as chaves com vazamento sejam inválidas no momento em que um usuário de má-fé as receber.

Ter um processo estabelecido para alternar as chaves da conta de serviço também ajuda a agir rapidamente caso você suspeite que uma chave da conta de serviço foi comprometida.

Se você gerou o par de chave pública/privada, armazenou a chave privada em um módulo de segurança de hardware (HSM, na sigla em inglês) e fez o upload da chave pública para o Google, talvez não precise fazer a rotação da chave regularmente. Em vez disso, rotacione a chave se acreditar que ela pode ter sido comprometida.

Use prazos de validade para permitir que as chaves expirem automaticamente

Por padrão, as chaves de conta de serviço criadas e transferidas por download do IAM não têm um prazo de validade e permanecem válidas até que você as exclua. Definir um prazo de validade para as chaves da conta de serviço pode limitar o risco de segurança reduzindo o ciclo de vida da credencial persistente. No entanto, há outros riscos associados à definição de prazos de validade. Por exemplo, definir um prazo de validade pode fazer com que as cargas de trabalho falhem quando as chaves expirarem.

Use prazos de validade quando você precisar de acesso temporário a um sistema que exija uma chave de conta de serviço. Por exemplo, use prazos de validade nos seguintes casos:

  • O desenvolvimento de código em um ambiente de não produção para um aplicativo só pode autenticar com chaves de conta de serviço
  • O uso de uma ferramenta de terceiros só pode autenticar com chaves de conta de serviço

Evite usar prazos de validade nestes cenários:

  • Cargas de trabalho de produção. Na produção, uma chave de conta de serviço expirada pode causar uma interrupção acidental. Em vez disso, use chaves que não expirem e gerencie o ciclo de vida delas com a rotação de chaves.
  • Cargas de trabalho de não produção que precisam de acesso permanente, como um pipeline de integração contínua (CI).
  • Sistemas de rotação de chaves que impedem o uso de uma chave após um período especificado. Para saber mais sobre as estratégias recomendadas de rotação de chaves, consulte Rotação de chaves de conta de serviço.

Para limitar a validade das chaves da conta de serviço, configure um prazo de validade para chaves recém-criadas no projeto, na pasta ou na organização. O prazo de validade não se aplica às chaves atuais.

Se preferir, faça upload de uma chave de conta de serviço e especifique uma data de validade no arquivo de certificado X.509. Após a data de validade, a chave não poderá ser usada para autenticação. No entanto, ela permanece associada à conta de serviço até que você a exclua.

Use as restrições da política da organização para desativar automaticamente chaves vazadas

Mesmo que você siga todas as práticas recomendadas para chaves de conta de serviço, é possível que as chaves da conta de serviço vazem.

Para ajudar a gerenciar credenciais vazadas, verifique se a restrição de resposta de exposição da chave da conta de serviço está definida como DISABLE_KEY. Se você definir a restrição para esse valor, o Google Cloud desativará automaticamente todas as chaves vazadas que detectar.

Se uma chave for desativada porque vazou, os seguintes campos serão adicionados aos metadados dela:

  • "disable_reason": "SERVICE_ACCOUNT_KEY_DISABLE_REASON_EXPOSED": indica que a chave foi desativada porque foi exposta.
  • "extended_status": "SERVICE_ACCOUNT_KEY_EXTENDED_STATUS_KEY_EXPOSED"": indica que a chave já foi exposta publicamente. Esse valor persiste mesmo se você reativar a chave.
  • "extended_status_message": "LINK_TO_EXPOSURE": se disponível, os metadados contêm um link para o local em que a chave foi detectada, que pode ser usado para correção.

Essas chaves podem ser reativadas se necessário para mitigar uma interrupção. No entanto, recomendamos desativá-las novamente assim que possível, porque as chaves expostas publicamente apresentam um risco de segurança, mesmo que a exposição inicial seja removida.

Para saber mais sobre outras práticas recomendadas de gerenciamento de credenciais comprometidas, consulte Como processar credenciais comprometidas do Google Cloud.

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.

Práticas recomendadas:

Evitar armazenar chaves em um sistema de arquivos;
Usar um HSM ou TPM para armazenar chaves;
Usar um armazenamento de chaves baseado em software.
Não armazenar chaves no Secret Manager ou em outros armazenamentos de secrets baseados na nuvem.
Não usar o papel "Editor" em projetos que permitem a criação ou o upload de chaves de conta de serviço.
Evitar o uso de chaves de conta de serviço na delegação em todo o domínio.

Evitar armazenar chaves em um sistema de arquivos

As chaves de conta de serviço criadas usando o Console do Google Cloud ou a gcloud CLI 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 gcloud CLI, 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

Não recomendamos o uso do Secret Manager do Google Cloud para armazenar e alternar chaves de conta de serviço. Isso ocorre porque, para acessar os secrets do Secret Manager, seu aplicativo precisa de uma identidade que o Google Cloud possa reconhecer. Se o aplicativo já tiver uma identidade que o Google Cloud possa reconhecer, ele poderá usar essa identidade para se autenticar no Google Cloud em vez de usar uma chave de conta de serviço.

O mesmo conceito se aplica a outros serviços de gerenciamento de chaves secretas baseados na nuvem, como o Azure KeyVault e o Secret Manager da AWS. Se um aplicativo já tiver uma identidade que esses provedores de nuvem possam reconhecer, será possível usá-la para autenticar no Google Cloud em vez de usar 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, uma Federação de Identidade da Carga de Trabalho para GKE 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

Práticas recomendadas:

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

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 gcloud CLI, 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 de ma-fé 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.

Práticas recomendadas:

Usar uma conta de serviço dedicada para cada aplicativo;
Usar uma chave dedicada para cada máquina que executa um aplicativo.

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, pode ser difícil identificar qual aplicativo realizou uma atividade porque os registros de auditoria contêm o mesmo valor de 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