Práticas recomendadas para autenticar aplicativos com segurança no Google Cloud

Os documentos do Google Cloud podem ajudar em diferentes partes do seu job. Algumas vezes, você quer aprender um novo serviço ou ver um recurso em ação. Em outra visita aos documentos, talvez você precise desenvolver um aplicativo para uso em produção.

Nossos documentos costumam ser escritos para ajudá-lo a colocar um serviço ou recurso em funcionamento. Em um ambiente de produção ou desenvolvimento, pode haver algumas práticas recomendadas de segurança a serem consideradas para a organização. Pode ser necessário autenticar os aplicativos de maneira diferente da mostrada nos documentos.

Para escolher o método de autenticação correto para seus aplicativos, use a árvore de decisão a seguir. O restante deste artigo explica cada uma das maneiras seguras de autenticar seus aplicativos.

Diagrama de árvore de decisão para ajudar a escolher um modo de autenticar seus aplicativos. As opções estão detalhadas nas seções deste artigo.

Visão geral do Application Default Credentials

Na maioria das vezes, você quer que seu código faça solicitações de API. Use uma estratégia chamada Application Default Credentials (ADC) para encontrar as credenciais necessárias automaticamente e autenticar seu aplicativo. Todas as bibliotecas de cliente do Google Cloud são compatíveis com o ADC.

Com o ADC, você pode desenvolver localmente usando um método de autenticação e, em seguida, autenticar com um método diferente quando implantado para teste ou produção. Nenhuma mudança de código é necessária à medida que você se move entre os diferentes ambientes de implantação e métodos de autenticação compatíveis.

As bibliotecas de cliente determinam quais métodos de autenticação estão disponíveis para uso. O ADC então seleciona o método de autenticação correto para que seu aplicativo faça solicitações de API, independentemente de você estar desenvolvendo localmente ou em produção. Sempre que possível, procure usar o ADC para seus aplicativos.

Para mais informações, consulte a Visão geral das credenciais padrão do aplicativo (ADC, na sigla em inglês) e como o ADC localiza as credenciais automaticamente.

Desenvolvimento local e teste com a ferramenta de linha de comando gcloud

Neste cenário, você usa a ferramenta de linha de comando gcloud para fazer alterações de configuração em seu projeto usando as APIs do Cloud ou pode escrever um código para testar novas integrações com essas APIs. Esse tipo de uso interativo é usado principalmente para desenvolvimento e teste na máquina local. Forneça suas próprias credenciais para fazer login na ferramenta de linha de comando gcloud. Essa abordagem permite acompanhar a identidade que fez a solicitação de API e gerenciar cotas ou fornecer uma trilha de auditoria para fins de segurança.

Para autenticar interativamente com a ferramenta de linha de comando gcloud para emitir seus próprios comandos e fazer alterações de configuração, use o comando gcloud auth login e especifique um usuário um projeto de faturamento de propriedade com a sinalização --billing-project. As chamadas para algumas APIs do Cloud, como a API Cloud Translation ou API Cloud Vision, falham sem o projeto de faturamento do usuário definido.

Para que seu código faça chamadas da API do Cloud a partir do seu ambiente de desenvolvimento local, use as bibliotecas de cliente do Google e o ADC. Para fazer isso, use o comando gcloud auth application-default login e especifique um projeto de faturamento de propriedade de um usuário com --billing-project. Novamente, as chamadas para algumas APIs do Cloud, como a API Cloud Translation ou API Cloud Vision, falham sem o projeto de faturamento definido pelo usuário.

Não atribua um papel que conceda mais permissões do que o necessário para fazer as solicitações de API do Cloud para seu aplicativo. O recomendador de Gerenciamento de identidade e acesso (IAM, na sigla em inglês) pode analisar quais permissões não foram necessárias nos últimos 90 dias para que você possa removê-las.

Dentro dos ambientes do Google Cloud

Nesse cenário, o código do aplicativo é executado no Google Cloud e usa a família de produtos sem servidor ou a computação, como VMs do Compute Engine, Cloud Run, App Engine, Google Kubernetes Engine (GKE) ou Cloud. Funções. Como os aplicativos são executados no ambiente do Google Cloud, use as credenciais padrão.

Com as credenciais padrão, seu aplicativo recupera o token de identidade associado à instância virtual que executa seu código. O token de identidade é recuperado de um servidor de metadados que é executado na instância virtual. Esse token pode ser usado para autenticar e fazer solicitações da API Cloud usando o ADC.

Você não precisa fazer nada para usar as credenciais padrão porque elas fazem parte do ADC. Não é necessário alterar o código, nem criar e gerenciar contas de serviço e rotação de chaves.

Datacenter local ou outro provedor de nuvem

Nesse cenário, o código do aplicativo é executado na própria infraestrutura de data center ou em outro provedor de nuvem, como AWS ou Azure. Se houver suporte para o OpenID Connect (OIDC), use a federação de identidade para cargas de trabalho externas e crie um pool de identidades de carga de trabalho para cada ambiente para fornecer autenticação para seus aplicativos.

A federação de identidade permite usar o gerenciamento de identidade e acesso (IAM) para conceder papéis do IAM a identidades externas, incluindo a capacidade de representar contas de serviço. Essa abordagem permite acessar recursos diretamente usando um token de acesso de curta duração.

Exemplos de provedores de identidade:

  • AWS
  • Azure Active Directory
  • Active Directory local
  • Okta
  • Clusters do Kubernetes

Para saber mais, veja como usar a federação de identidade para cargas de trabalho externas e criar um pool de identidades de carga de trabalho.

Se você não tiver suporte para o OIDC ou não quiser usar a federação de identidade, crie contas de serviço gerenciadas por usuários. Essas contas de serviço serão abordadas na próxima seção. Tenha cuidado para armazenar essas credenciais em um cofre digital que seu provedor possa oferecer, como o AWS Secret Manager ou o Azure Key Vault. Não grave essas credenciais no disco, exceto em um formato criptografado.

Contas de serviço gerenciadas pelo usuário

Nesse cenário, seu código não está sendo executado no Google Cloud ou em um ambiente que aceita o OpenID Connect e a federação de identidade. Desde que o ambiente seja considerado confiável e não haja restrições de serviço de política da organização para impedir o uso, você pode usar contas de serviço para autenticar seus aplicativos. O ADC funciona com contas de serviço, de modo que seus aplicativos podem usar automaticamente diferentes métodos de autenticação em diferentes ambientes de implantação.

Uma conta de serviço é um tipo especial de conta usada por um aplicativo, não uma pessoa. Cada conta de serviço está associada a pares de chave RSA pública/privada que são usados para autenticação. Verifique se há pouco risco de o ambiente ser comprometido e das chaves da conta de serviço que estão sendo expostas. Para proteger as chaves exportadas e minimizar possíveis riscos de segurança, revise as práticas recomendadas de chaves de conta de serviço.

Também é possível usar um token JWT (JSON Web Token) autoassinado ou token OIDC com sua conta de serviço para evitar uma viagem de ida e volta desnecessária para adquirir tokens. Para mais informações, consulte Como fazer uma solicitação autenticada com JWTs para uma API do Cloud Endpoints.

As contas de serviço executam ações em seu nome, mas podem ter permissões excessivas atribuídas e, geralmente, não são excluídas quando não são mais necessárias. O recomendador de gerenciamento de identidade e acesso pode analisar quais permissões não foram necessárias nos últimos 90 dias. É possível identificar contas de serviço não utilizadas. que devem ser removidas.

Ambientes semiconfiança ou restritos

Nesse cenário, o código do seu aplicativo é executado em um ambiente semi-confiável ou tem restrições de política aplicadas que limitam quais ações podem ser executadas. Não use contas de serviço nesses ambientes para autenticar e fazer solicitações da API Cloud.

O serviço de política da organização pode ser usado para aplicar restrições ao projeto, que limita você de se comunicar com recursos executados em outros projetos, especialmente em implantações de produção.

Como cada ambiente é único e pode exigir requisitos de segurança diferentes, revise qualquer orientação específica de serviço que possa afetar você. Trabalhe com suas equipes de operações e segurança para projetar a melhor solução para suas necessidades.

Em geral, é necessário projetar um sistema que permita receber um token de acesso de curta duração com segurança. As seguintes considerações de design se aplicam:

  • O token deve durar o suficiente para que o aplicativo seja executado ou que possa ser atualizado.
  • Restrinja o token aos papéis necessários.
  • Não grave o token no disco.

Algumas soluções de exemplo podem incluir o acesso a um gerenciamento de chaves digitais no local, como: Vault Hashicorp ou limitando o acesso ao Cloud Run erecuperação automática de credenciais do Gerenciador de secrets ou Credenciais criptografadas do Cloud Key Management Service para criar um anexo da VLAN de monitoramento.

Você também pode entrar em contato com o Google Cloud Consulting para receber ajuda no design e na criação de uma solução segura.

Considerações sobre segurança

Se você usar tokens JWT ou OIDC como parte do processo de autenticação do aplicativo, os tokens serão válidos durante o ciclo de vida do projeto. Para reduzir o risco de exposição, configure o ciclo de vida do token para ser um pouco mais longo do que o esperado. Por exemplo, se um token for necessário por 15 minutos durante a execução do job, configure o ciclo de vida dele para 20 minutos.

Só é possível revogar esses tokens além da exclusão da conta de serviço pai. Novamente, tome cuidado ao atribuir políticas de ciclo de vida do token para reduzir o tempo que um token potencialmente comprometido permanecerá utilizável.

As chaves de conta de serviço podem ser roubadas e usadas para gerar credenciais de uma maneira que não pode ser rastreada indefinidamente ou até a próxima rotação de chaves. Para proteger as chaves exportadas e minimizar potenciais riscos de segurança, revise as práticas recomendadas de chaves de conta de serviço como rotação e auditoria de chaves.

Se necessário, exclua as chaves da conta de serviço para que elas não sejam mais usadas.

A seguir

Para mais informações sobre o uso de credenciais em aplicativos, consulte Práticas recomendadas para o gerenciamento de credenciais.