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

Ao contrário das contas de utilizador, as contas de serviço não têm palavras-passe. Em alternativa, as contas de serviço usam pares de chaves RSA para a autenticação. Se souber a chave privada do par de chaves de uma conta de serviço, pode usar a chave privada para criar um token de portador JWT e usar o token de portador para pedir um token de acesso. A chave de acesso resultante reflete a identidade da conta de serviço e pode usá-la para interagir com as APIs em nome da conta de serviço.Trusted Cloud by S3NS

Uma vez que a chave privada lhe permite autenticar-se como a conta de serviço, ter acesso à chave privada é semelhante a saber a palavra-passe de um utilizador. A chave privada é conhecida como chave de conta de serviço. Os pares de chaves usados pelas contas de serviço dividem-se em duas categorias: geridas pela Google e geridas pelo utilizador.

As chaves de contas de serviço podem tornar-se um risco de segurança se não forem geridas cuidadosamente. Deve escolher uma alternativa de autenticação mais segura sempre que possível. As principais ameaças relacionadas com as chaves de contas de serviço são:

• Roubo de credenciais: as chaves de contas de serviço podem acabar inadvertidamente em locais onde não devem ser armazenadas. Um interveniente malicioso pode usar uma chave de conta de serviço roubada para autenticar e ganhar acesso ao seu ambiente.
• Aumento de privilégios: se um ator malicioso conseguir aceder a uma chave de conta de serviço com pouca segurança, pode usar a chave para aumentar os respetivos privilégios.
• Divulgação de informações: as chaves de contas de serviço podem divulgar inadvertidamente metadados confidenciais.
• Não repúdio: ao autenticar através de uma chave de conta de serviço e permitir que a conta de serviço realize operações em seu nome, um ator malicioso pode ocultar a sua identidade e ações.
• Configurações de credenciais maliciosas: um interveniente prejudicial pode fornecer uma configuração de credenciais maliciosa para contornar as suas defesas de segurança.

A melhor forma de mitigar estas ameaças é evitar chaves de contas de serviço geridas pelo utilizador e usar outros métodos para autenticar contas de serviço sempre que possível. Também pode usar condições do IAM e VPC Service Controls para restringir os recursos que podem ser potencialmente acedidos por uma conta de serviço comprometida.

Para situações em que não pode usar alternativas mais seguras às chaves de contas de serviço, este guia apresenta práticas recomendadas para gerir, usar e proteger chaves de contas de serviço.

Proteção contra roubo de credenciais

Tal como um nome de utilizador e uma palavra-passe, as chaves de contas de serviço são uma forma de credencial. Se um utilizador conseguir aceder a uma chave de conta de serviço válida, pode usá-la para se autenticar e aceder aos recursos aos quais a respetiva conta de serviço lhe concedeu acesso.

Para os intervenientes mal-intencionados, as chaves de conta de serviço podem ser ainda mais valiosas do que uma palavra-passe com fugas de informação. É pouco provável que a tentativa de início de sessão com uma palavra-passe roubada seja bem-sucedida se a conta de utilizador tiver sido configurada para usar a validação em 2 passos e os desafios de início de sessão. Por outro lado, é provável que a autenticação através de uma chave de conta de serviço roubada seja bem-sucedida, uma vez que as contas de serviço não estão sujeitas a validações de início de sessão adicionais.

Os autores de ataques podem procurar chaves de contas de serviço em vários locais, incluindo:

• Repositórios de código-fonte de projetos de código aberto
• Contentores do Cloud Storage públicos
• Roubo de dados públicos de serviços violados

Além das localizações públicas, os autores de ataques podem procurar chaves de contas de serviço em localizações privadas que tenham sido comprometidas. Os exemplos incluem:

• Caixas de entrada de email
• Partilhas de ficheiros
• Armazenamento de cópias de segurança
• Diretórios do sistema de ficheiros temporários

Uma forma eficaz de reduzir o risco de fuga de chaves de contas de serviço é reduzir o número de chaves em circulação e desincentivar a criação de novas chaves. As secções seguintes descrevem como pode limitar o número de chaves de contas de serviço em circulação e que outras medidas podem ajudar a limitar o risco de fugas de contas de serviço.

Ofereça alternativas à criação de chaves de contas de serviço

Certifique-se de que os utilizadores na sua organização estão cientes das alternativas e podem justificar o risco adicional e a sobrecarga de gestão da utilização de uma chave de conta de serviço:

• Informe os seus programadores sobre alternativas mais seguras às chaves de contas de serviço
• Estabeleça um processo para ajudar os programadores a decidir sobre o método de autenticação adequado para o respetivo exemplo de utilização antes de criar uma nova chave de conta de serviço.
• Use restrições da política da organização para impedir a criação de novas chaves de contas de serviço e permitir exceções apenas para projetos que demonstraram não poder usar uma alternativa mais segura.

Use restrições de políticas da organização para limitar os projetos que podem criar chaves de contas de serviço

Dadas as alternativas mais seguras às chaves de contas de serviço, é melhor considerar a utilização de chaves de contas de serviço como uma exceção e não como a norma.

Para evitar a utilização desnecessária de chaves de contas de serviço, use restrições de políticas da organização:

• Na raiz da hierarquia de recursos da sua organização, aplique as restrições Desativar a criação de chaves de contas de serviço e Desativar o carregamento de chaves de contas de serviço para estabelecer uma predefinição em que as chaves de contas de serviço não são permitidas.

• Quando necessário, substitua uma das restrições para os projetos selecionados para voltar a ativar a criação ou o carregamento de chaves da conta de serviço.

A modificação das restrições da política da organização requer a autorização orgpolicy.policy.set. Uma vez que nem a função de proprietário (roles/owner) nem a função de editor (roles/editor) incluem esta autorização, as restrições também podem ser eficazes em ambientes que não sejam de produção, onde alguns responsáveis podem ter acesso de proprietário ou editor a projetos.

Não deixe chaves de contas de serviço em localizações temporárias

Quando cria uma chave de conta de serviço através da Trusted Cloud consola, a maioria dos navegadores transfere imediatamente a nova chave e guarda-a numa pasta de transferências no seu computador. Deve mover imediatamente a chave para a localização onde a quer armazenar. Certifique-se de que não deixa acidentalmente uma cópia na pasta de transferências ou na reciclagem do computador.

Pode reduzir o risco de deixar acidentalmente cópias das chaves de contas de serviço em localizações temporárias usando a CLI do Google Cloud: O comando gcloud iam service-accounts keys create permite-lhe escrever o ficheiro de chave da conta de serviço diretamente na localização onde precisa dele. Além disso, na maioria dos sistemas operativos, a CLI gcloud ajusta automaticamente as autorizações de ficheiros para que o ficheiro só seja acessível por si.

Não transmita chaves de contas de serviço entre utilizadores

Quando implementa uma aplicação que requer uma chave de conta de serviço, pode não ter autorização para criar uma chave de conta de serviço. Em alternativa, pode ter de pedir a outra pessoa que crie uma chave de conta de serviço para si.

Em cenários em que vários utilizadores estão envolvidos na criação e implementação de uma chave de conta de serviço, existe um risco acrescido de que permaneçam cópias da chave em caixas de correio, históricos de chat ou outras localizações. Sempre que for necessária uma transferência entre utilizadores, pode ser mais seguro carregar uma chave de conta de serviço:

1. Enquanto utilizador que implementa a aplicação, crie um certificado autoassinado que use um par de chaves RSA de 2048 bits na máquina de destino. Para criar o certificado, pode usar o openssl, o certutil, o New-SelfSignedCertificate ou outras ferramentas do sistema operativo.
2. Transmita o ficheiro de certificado ao utilizador que tem autorização para carregar o certificado, mantendo a chave privada na máquina de destino. Quando transmitir o certificado, certifique-se de que não pode ser substituído nem adulterado, mas não tem de o manter confidencial.
3. Como o utilizador que tem as autorizações necessárias para gerir chaves de contas de serviço, carregue o certificado para o associar a uma conta de serviço.

Ao seguir este processo, evita a transmissão da chave privada e, em vez disso, apenas troca informações públicas entre os utilizadores.

Não envie chaves de contas de serviço para repositórios de código-fonte

As chaves de contas de serviço são credenciais e têm de ser protegidas contra o acesso não autorizado. Se enviar uma chave de conta de serviço para um repositório de código fonte, existe um risco acrescido de que a chave se torne acessível a utilizadores não autorizados e atores maliciosos:

• Os autores de ataques podem analisar o código-fonte de repositórios de código aberto públicos para encontrar chaves roubadas.
• No futuro, pode decidir transformar um repositório de origem privado num repositório público sem verificar primeiro se existem chaves.
• Outros membros da equipa podem armazenar cópias do código fonte na respetiva estação de trabalho.

Quando trabalha em código que usa uma chave de conta de serviço, armazene sempre a chave de conta de serviço separadamente do código fonte para reduzir o risco de enviar acidentalmente a chave para o repositório de origem. Em muitos casos, pode reduzir ainda mais este risco se não usar chaves de contas de serviço durante o desenvolvimento e usar as suas credenciais pessoais em vez de chaves de contas de serviço.

Além disso, configure o seu sistema de controlo de origem para que detete envios acidentais de chaves de contas de serviço:

• Se usar o Cloud Source Repositories, ative a deteção de chaves para bloquear git operações push que contenham chaves privadas e para notificar os utilizadores.
• Se usar o GitHub, ative a análise de segredos para os seus repositórios.
• Se o seu sistema de gestão de controlo de origem não suportar a análise automática, use uma ferramenta de código aberto como o truffleHog para analisar o seu código-fonte em busca de segredos através de um pre-commit hook, adicionando um passo ao pipeline de integração contínua ou ambos.

Não incorpore chaves de contas de serviço em binários de programas

As chaves de contas de serviço são strings que correspondem a um determinado padrão e podem ser identificadas mesmo que estejam incorporadas noutros ficheiros ou binários. Se um agente malicioso tiver acesso ao ficheiro binário, pode extrair quaisquer chaves de contas de serviço incorporadas no ficheiro binário.

Os ficheiros binários do programa para aplicações do lado do servidor podem ser alojados em repositórios de artefactos ou podem ser copiados para estações de trabalho de programadores para fins de depuração. Manter as chaves da conta de serviço separadas dos ficheiros binários do programa ajuda a garantir que um utilizador que pode aceder ao ficheiro binário não tem acesso implícito às credenciais da conta de serviço.

• Para aplicações do lado do cliente, como ferramentas, programas de computador ou apps para dispositivos móveis, não use contas de serviço. Em alternativa, permita que os utilizadores façam a autenticação com as respetivas credenciais.
• Para aplicações do lado do servidor, não incorpore chaves de contas de serviço no ficheiro binário. Em alternativa, mantenha as chaves separadas do ficheiro binário da aplicação.

Use métricas para identificar chaves de contas de serviço não usadas

Para minimizar o número de chaves de contas de serviço válidas em circulação, é recomendável desativar as chaves assim que deixarem de ser necessárias e, em seguida, eliminá-las quando tiver a certeza de que já não são necessárias.

Se não tiver a certeza de que uma chave ainda está a ser usada, pode verificar a respetiva utilização monitorizando as métricas de autenticação. Ao monitorizar a métrica Eventos de autenticação de chaves, pode saber quando uma chave de conta de serviço foi usada pela última vez e com que frequência foi usada para autenticar uma conta de serviço.

Alterne as chaves das contas de serviço para reduzir o risco de segurança causado por chaves roubadas

Embora possa reduzir a probabilidade de divulgar acidentalmente uma chave da conta de serviço, pode ser difícil eliminar completamente o risco.

A rotação de chaves é o processo de substituição das chaves existentes por novas chaves e, em seguida, de invalidação das chaves substituídas. Recomendamos que rode rotineiramente todas as chaves que gere, incluindo as chaves da conta de serviço.

A rotação das chaves da conta de serviço pode ajudar a reduzir o risco representado por chaves roubadas ou com fugas de informação. Se uma chave for divulgada, os intervenientes mal-intencionados podem demorar dias ou semanas a descobri-la. Se rodar regularmente as chaves da conta de serviço, existe uma maior probabilidade de as chaves roubadas serem inválidas quando um ator malicioso as obtiver.

Ter um processo estabelecido para a rotação das chaves de contas de serviço também ajuda a agir rapidamente se suspeitar que uma chave de conta de serviço foi comprometida.

Se gerou o par de chaves públicas/privadas, armazenou a chave privada num módulo de segurança de hardware (HSM) e carregou a chave pública para Trusted Cloud, pode não precisar de rodar a chave regularmente. Em alternativa, pode alternar para uma chave nova se considerar que a chave atual pode ter sido comprometida.

Use prazos de validade para permitir que as chaves expirem automaticamente

Por predefinição, as chaves de contas de serviço que cria e transfere a partir do IAM não têm um prazo de validade e permanecem válidas até as eliminar. A definição de um prazo de validade para as chaves de contas de serviço pode limitar o risco de segurança, reduzindo o tempo de vida da credencial persistente. No entanto, existem outros riscos associados à definição de horas de validade. Por exemplo, a definição de uma hora de validade pode fazer com que as cargas de trabalho falhem quando as respetivas chaves expiram.

Use prazos de validade quando precisar de acesso temporário a um sistema que requer uma chave de conta de serviço. Por exemplo, use horas de validade quando estiver a fazer o seguinte:

• Desenvolver código num ambiente de não produção para uma aplicação que só pode autenticar com chaves de contas de serviço
• Usar uma ferramenta de terceiros que só pode autenticar com chaves de contas de serviço

Evite usar horas de validade para estes 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 alternativa, use chaves que não expirem e faça a gestão do respetivo ciclo de vida 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 (IC).
• Sistemas de rotação de chaves que impedem a utilização de uma chave após um período especificado. Para saber mais sobre as estratégias de rotação de chaves recomendadas, consulte o artigo Rotação de chaves de contas de serviço.

Para limitar a validade das chaves de contas de serviço, pode configurar um prazo de validade para as chaves criadas recentemente no seu projeto, pasta ou organização. A hora de expiração não se aplica às chaves existentes.

Em alternativa, pode carregar uma chave da conta de serviço e especificar uma data Válido até no ficheiro de certificado X.509. Após a data de validade, não é possível usar a chave para autenticação. No entanto, permanece associado à conta de serviço até o eliminar.

Use restrições de políticas da organização para desativar automaticamente chaves roubadas

Mesmo que siga todas as práticas recomendadas para chaves de contas de serviço, é possível que as suas chaves de contas de serviço sejam divulgadas.

Para ajudar a gerir as credenciais roubadas, certifique-se de que a restrição Service Account Key Exposure Response está definida como DISABLE_KEY. Se definir a restrição para este valor, Trusted Cloud by S3NS desativa automaticamente todas as chaves roubadas que detetar.

Se uma chave for desativada porque foi divulgada, os seguintes campos são adicionados aos metadados da chave:

• "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 foi exposta publicamente. Este valor persiste mesmo se reativar a chave.
• "extended_status_message": "LINK_TO_EXPOSURE": se disponível, os metadados contêm um link para o local onde a chave foi detetada, que pode usar para remediação.

Estas chaves podem ser reativadas se necessário para mitigar uma indisponibilidade. No entanto, recomendamos que as desative novamente assim que possível, uma vez que as chaves expostas publicamente representam um risco de segurança, mesmo que a exposição inicial seja removida.

Para saber mais acerca de outras práticas recomendadas para gerir credenciais comprometidas, consulte o artigo Como processar credenciais Trusted Cloud comprometidas.

Proteção contra o escalamento de privilégios

A utilização de chaves de contas de serviço pode expô-lo a ataques de escalada de privilégios se as chaves estiverem menos bem protegidas do que os recursos aos quais concedem acesso.

Por exemplo, suponha que um interveniente malicioso já ganhou terreno no seu ambiente e tenta aceder a determinados Trusted Cloud recursos. Podem continuar a não ter as autorizações para aceder a estes recursos, mas os respetivos privilégios podem ser suficientes para aceder a uma chave de conta de serviço armazenada numa VM, numa partilha de ficheiros ou noutra localização menos segura. Ao autenticar através da chave da conta de serviço, o autor da ação maliciosa pode assumir a identidade da conta de serviço. A conta de serviço pode permitir que o interveniente prejudicial aceda a recursos aos quais não tinha acesso anteriormente, o que aumenta os privilégios do interveniente prejudicial.

Uma vez que uma chave de conta de serviço concede indiretamente acesso a recursos no Trusted Cloud, tem de considerar a própria chave tão valiosa e digna de proteção quanto os recursos.

As secções seguintes descrevem as práticas recomendadas para proteger as chaves de contas de serviço e reduzir o risco de acesso não autorizado e a consequente elevação de privilégios.

Evite armazenar chaves num sistema de ficheiros

As chaves de contas de serviço criadas através da Trusted Cloud consola ou da CLI gcloud são ficheiros JSON, e pode copiar estes ficheiros para o sistema de ficheiros do computador onde são necessários. No entanto, armazenar chaves de contas de serviço como ficheiros num sistema de ficheiros pode expor a sua empresa a vários riscos, incluindo:

• Alguns sistemas de ficheiros, como o NTFS, usam autorizações herdadas por predefinição. A menos que desativada, uma autorização adicionada a uma pasta principal pode fazer com que, inadvertidamente, um ficheiro de chave se torne mais acessível e visível para utilizadores não autorizados.
• Num ambiente virtualizado, os autores de ataques podem conseguir comprometer a segurança do sistema de ficheiros acedendo ao disco virtual subjacente.
• O acesso ao sistema de ficheiros e as alterações de autorizações não são frequentemente registados em registos de auditoria. Se as autorizações de ficheiros forem alteradas inadvertidamente e a chave ficar visível para utilizadores não autorizados, pode ser difícil analisar quando e por quem estas alterações foram feitas.
• Os ficheiros podem ser facilmente copiados e, por conseguinte, exfiltrados se um interveniente malicioso obtiver acesso.

Sempre que possível, evite armazenar chaves de contas de serviço num sistema de ficheiros. Se não puder evitar armazenar chaves no disco, certifique-se de que restringe o acesso ao ficheiro de chaves, configura a auditoria de acesso a ficheiros e encripta o disco subjacente.

Use um HSM ou um TPM para armazenar chaves

Quando cria uma chave de conta de serviço através da Trusted Cloud consola ou da CLI gcloud, a chave privada é gerada pela Trusted Cloud e, em seguida, revelada ao utilizador. Muitos riscos de segurança associados às chaves de contas de serviço resultam do facto de a chave privada estar, temporária ou permanentemente, disponível em texto não cifrado e, por isso, ser difícil de proteger.

Em vez de permitir que o Trusted Cloud gere um par de chaves, pode usar um módulo de segurança de hardware (HSM) ou um módulo de plataforma fidedigna (TPM) para criar e gerir chaves:

1. Use um HSM ou um TPM para gerar um par de chaves RSA.
2. Use o par de chaves para criar um certificado autoassinado.
3. Carregue o certificado como uma chave de conta de serviço.
4. Permitir que a aplicação use a API de assinatura do HSM ou do TPM para assinar o JWT para autenticar a conta de serviço.

Um HSM ou um TPM permite-lhe usar uma chave privada sem nunca revelar a chave em texto simples. Por conseguinte, a utilização de um HSM ou um TPM para gerir as chaves da conta de serviço ajuda a aplicar o controlo de acesso e a mitigar o risco de as chaves serem copiadas para outros sistemas.

Algumas plataformas oferecem abstrações que lhe permitem tirar partido de um TPM sem ter de interagir diretamente com ele. Por exemplo, o Windows permite-lhe gerir chaves protegidas por TPM através da API CryptoNG em combinação com o Microsoft Platform Crypto Provider.

As chaves de contas de serviço geridas por um TPM são exclusivas de uma máquina física ou virtual. Pode continuar a permitir que vários computadores partilhem uma conta de serviço associando a chave de cada computador a uma conta de serviço comum.

Use um arquivo de chaves baseado em software

Em situações em que a utilização de um arquivo de chaves baseado em hardware não é viável, use um arquivo de chaves baseado em software para gerir as chaves de contas de serviço. Semelhante às opções baseadas em hardware, um repositório de chaves baseado em software permite que os utilizadores ou as aplicações usem chaves de contas de serviço sem revelar a chave privada. As soluções de repositório de chaves baseadas em software podem ajudar a controlar o acesso às chaves de forma detalhada e também podem garantir que cada acesso às chaves é registado.

A segurança de um arquivo de chaves baseado em software depende normalmente da forma como a respetiva chave principal está protegida. Antes de usar um armazenamento de chaves baseado em software, certifique-se de que revê o seguinte:

• Como a chave principal é protegida em repouso,
• Como funciona o processo de anulação da selagem e quem o pode iniciar
• Como as chaves são protegidas contra a extração da memória,
• Como o armazenamento de chaves está protegido contra sabotagem se um interveniente prejudicial obtiver acesso à shell ou ao hipervisor ao sistema subjacente.

Não armazene chaves em repositórios de Secrets baseados na nuvem

Não recomendamos a utilização de serviços de gestão de segredos baseados na nuvem, como o Azure KeyVault e o AWS Secret Manager, para armazenar e alternar chaves de contas de serviço. Isto deve-se ao facto de, para aceder a estes segredos armazenados, a sua aplicação precisar de uma identidade que o fornecedor de nuvem possa reconhecer. Se a sua aplicação já tiver uma identidade que o fornecedor de nuvem possa reconhecer, a aplicação pode usar essa identidade para autenticar em vez de usar uma chave de conta de serviço.

Não use a função Editor em projetos que permitam a criação ou o carregamento de chaves de contas de serviço

Uma das principais diferenças entre as funções básicas de Editor (roles/editor) e Proprietário (roles/owner) é que a função de Editor não lhe permite alterar as políticas nem as funções da IAM. Por conseguinte, com a função de editor, não pode expandir facilmente o seu próprio acesso nem conceder acesso a outros utilizadores aos recursos do projeto.

As limitações da função de editor podem ser comprometidas se um projeto contiver contas de serviço. Uma vez que as funções de editor concedem autorização para criar ou carregar chaves de contas de serviço, um agente malicioso pode criar novas chaves para contas de serviço existentes e usar estas chaves para aumentar o seu próprio acesso ou entregar as chaves a outros utilizadores para obter acesso aos recursos do projeto.

Em vez de usar a função Editor ou qualquer outra função básica, é melhor usar as funções predefinidas definidas de forma mais restrita ou criar funções personalizadas que apenas concedam as autorizações necessárias.

Se precisar de usar a função de editor, desative o carregamento da chave da conta de serviço e a criação de chaves através de restrições da política da organização para ajudar a garantir que a função de editor não pode ser usada indevidamente para a escalada de privilégios.

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

Evite a divulgação de informações confidenciais em certificados X.509 carregados

Para cada chave de conta de serviço, a IAM permite-lhe transferir um certificado X.509 do ponto final https://www.googleapis.com/service_accounts/v1/metadata/x509/ACCOUNT_EMAIL. Este ponto final é público e não requer autenticação.

Para as chaves geradas pela Google Google Cloud-powered keys e geridas pelo utilizador que criou através da consola Trusted Cloud ou da CLI gcloud, os certificados X.509 são criados automaticamente e contêm apenas metadados básicos, como o endereço de email e a data de validade.

Para chaves de contas de serviço carregadas, o certificado X.509 fornecido pelo ponto final público é o mesmo certificado que carregou. Se o certificado que carregou contiver atributos opcionais (como informações de morada ou localização incorporadas no nome comum), estas informações também ficam acessíveis publicamente. Um interveniente malicioso pode usar estas informações para saber mais sobre o seu ambiente.

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

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

Quando deteta atividade suspeita que afeta os seus recursos do Trusted Cloud Google Cloud e quer analisar as respetivas origens, precisa de dados que lhe permitam reconstruir a cadeia de eventos que originaram a atividade suspeita. A origem principal de dados para realizar essa análise são normalmente os registos de auditoria.

A análise dos registos de auditoria pode tornar-se mais difícil quando estão envolvidas contas de serviço. Se uma atividade foi iniciada por uma conta de serviço, a entrada do registo contém o endereço de email da conta de serviço, mas também tem de saber que utilizador ou aplicação estava a usar a conta de serviço nesse momento.

As secções seguintes contêm práticas recomendadas para usar chaves de contas de serviço de forma a ajudar a acompanhar a respetiva utilização.

Use uma conta de serviço dedicada para cada aplicação

Todos os registos do registo de auditoria contêm um campo principalEmail que identifica o principal que iniciou a atividade. Se partilhar uma chave de conta de serviço em várias aplicações, pode ser difícil identificar que aplicação realizou uma atividade, porque os registos do registo de auditoria contêm o mesmo valor principalEmail.

Em vez de partilhar uma chave entre várias aplicações, crie uma conta de serviço dedicada para cada aplicação. Desta forma, o campo principalEmail permite-lhe identificar a aplicação associada a uma conta de serviço, o que pode ajudar a reconstruir a cadeia de eventos que originou uma atividade suspeita.

Use uma chave dedicada para cada máquina que execute uma aplicação

Se executar várias cópias da mesma aplicação em vários computadores, o campo principalEmail pode permitir-lhe identificar a aplicação, mas não o computador de onde uma determinada atividade se originou.

Para ajudar a restringir as potenciais origens de atividade suspeita, crie chaves individuais para cada cópia da aplicação. Desta forma, pode usar o campo serviceAccountKeyName que muitos serviços adicionam aos registos do registo de auditoria para distinguir a máquina de origem de uma atividade.

Proteção contra configurações de credenciais maliciosas

Algumas configurações de credenciais contêm URLs e caminhos de ficheiros que, se não forem validados adequadamente por uma carga de trabalho, podem fazer com que a carga de trabalho use pontos finais maliciosos.

Valide as chaves adquiridas a partir de uma fonte externa antes de as usar para autenticar nas APIs Google

Quando aceita uma chave de conta de serviço de uma origem externa, tem de validar a chave antes de a usar. Se não validar a chave, um interveniente malicioso pode usar a chave para fazer com que a sua carga de trabalho aceda a endpoints maliciosos.

Se o seu sistema esperar apenas chaves de contas de serviço, certifique-se de que o valor do campo type é service_account.

Para mais informações, consulte o artigo Requisitos de segurança quando usa configurações de credenciais de uma origem externa.

O que se segue?

• Leia mais sobre as práticas recomendadas para trabalhar com contas de serviço.
• Reveja as nossas práticas recomendadas para usar contas de serviço em pipelines de implementação.