Este documento descreve as práticas recomendadas, os cenários e os procedimentos para revogar o acesso de um utilizador a um projeto. Google Cloud Uma vez que cada empresa tem políticas e cargas de trabalho diferentes, recomendamos que use este documento para criar as suas próprias políticas e procedimentos que lhe permitam revogar o acesso de forma consistente e atempada.
Quando um funcionário sai da sua empresa, a sua interação com um contratante termina ou um colaborador passa a trabalhar noutros projetos, deve fazer algumas coisas para revogar o acesso desnecessário aos seus recursos na nuvem.
Alguns destes processos são opcionais. Deve determinar qual destes passos executar consoante as suas necessidades de segurança, os produtos em utilização e a confiança na pessoa cujo acesso está a ser revogado.
Práticas recomendadas para configurar o seu projeto
Pode melhorar a capacidade do seu projeto de revogar o acesso dos utilizadores de forma eficiente fazendo escolhas ponderadas no momento da configuração.
Federe contas de utilizador com o seu fornecedor de identidade existente
Quando federar contas de utilizadores com o seu fornecedor de identidade existente, certifique-se de que propaga eventos de suspensão e eliminação de utilizadores. Com a propagação, quando suspende ou remove uma conta de utilizador do seu fornecedor de identidade, o utilizador também perde o acesso aos recursos do Google Cloud .
Para mais informações, consulte as práticas recomendadas para a federação Google Cloud com um fornecedor de identidade externo.
Para ver mais práticas recomendadas relacionadas com a identidade, consulte o artigo Práticas recomendadas para planear contas e organizações.
Para informações sobre a federação de identidade da força de trabalho, consulte o artigo Federação de identidade da força de trabalho.
Considere usar os Grupos do Google para gerir o acesso aos recursos do projeto
Os Grupos Google permitem-lhe organizar os utilizadores com base na respetiva associação a equipas, requisitos de acesso ou outros critérios. Depois de criar grupos Google, pode atribuir acesso a Google Cloud projetos e recursos com base na associação a grupos. Quando um utilizador muda para outra equipa ou função, pode mover a conta de utilizador para outro grupo, o que remove automaticamente o acesso concedido pelas políticas de permissão ao grupo anterior.
A utilização dos Grupos Google não é adequada em todas as circunstâncias. Por exemplo, não deve usar grupos baseados apenas na estrutura organizacional da sua empresa para gerir o acesso. Para ver as práticas recomendadas sobre a utilização de grupos, consulte o artigo Práticas recomendadas para usar o Grupos Google.
Para mais informações, consulte os artigos Gerir grupos na Google Cloud consola e Crie um grupo na sua organização
Use o Início de sessão do SO
Use o Início de sessão do SO em vez de chaves SSH baseadas em metadados para que as chaves autorizadas do utilizador estejam associadas à respetiva identidade Google. Quando remove uma conta de utilizador, as chaves autorizadas e o acesso às VMs são revogados automaticamente. Para mais informações, consulte o artigo Use o início de sessão do SO para garantir a avaliação contínua do acesso em relação às políticas da IAM.
Para ver instruções, consulte o artigo Configure o Início de sessão do SO.
Restrinja o acesso de contas de utilizadores externos
Não conceda aos utilizadores externos acesso ao projeto porque não pode controlar o ciclo de vida destas contas de utilizador. Para restringir utilizadores externos, use a restrição de lista
iam.allowedPolicyMemberDomains
Para ver instruções, consulte o artigo Restringir identidades por domínio.
Use proxies de autenticação com bases de dados
Os proxies de autenticação permitem-lhe associar o ciclo de vida das credenciais da base de dados ao ciclo de vida de uma identidade Google. Quando suspende ou elimina uma conta de utilizador no Cloud Identity ou no Google Workspace, o acesso às bases de dados é revogado automaticamente.
Para mais informações, consulte o proxy Auth do Cloud SQL e o proxy Auth do AlloyDB para PostgreSQL.
Prepare-se para a rotação de credenciais
Crie os seus projetos e recursos para permitir a rotação não disruptiva das credenciais ao nível do projeto. Estes são segredos associados ao próprio projeto, como chaves de contas de serviço, segredos de clientes OAuth e segredos específicos da aplicação, como palavras-passe de raiz da base de dados. Para mais informações, consulte o artigo Processe credenciais Google Cloud comprometidas.
Restrinja as chaves da API
Ao criar e gerir chaves de API, restrinja o conjunto de Websites, endereços IP e apps que as podem usar. Uma conta de utilizador com funções como Leitor ou Administrador de chaves de API pode ver as chaves de API do seu projeto, pelo que todas as chaves não restritas têm de ser alteradas ou eliminadas para revogar o acesso à faturação. Para mais informações, consulte o artigo Proteja uma chave de API.
Monitorize as autorizações de acesso
A monitorização cuidadosa do acesso ajuda a mitigar potenciais abusos de acesso. Pode usar o recomendador de funções do IAM para acompanhar a utilização das funções e ajudar a aplicar o princípio do menor privilégio. Além disso, as capacidades de gestão de autorizações da infraestrutura na nuvem (CIEM) do Security Command Center permitem-lhe gerir que identidades têm acesso a que recursos nas suas implementações e mitigar potenciais vulnerabilidades resultantes de configurações incorretas.
Use o acesso de nível de contentor uniforme para o Cloud Storage
O acesso de nível de contentor uniforme permite-lhe usar apenas o IAM para gerir as autorizações dos seus contentores do Cloud Storage. Use o acesso de nível de contentor uniforme juntamente com outras opções de controlo de acesso para refinar quem pode aceder ao conteúdo nos seus contentores.
Práticas recomendadas adicionais
Além das práticas recomendadas descritas neste documento, reveja as seguintes práticas recomendadas:
- Práticas recomendadas para trabalhar com contas de serviço
- Decida a segurança da sua Google Cloud zona de aterragem
- Valide explicitamente todas as tentativas de acesso
Cenários para revogar o acesso a Google Cloud projetos
Se implementou as práticas recomendadas indicadas em Práticas recomendadas para configurar o seu projeto, a tabela seguinte resume como pode revogar o acesso.
| Cenário | Revogar opções de acesso |
|---|---|
| Um funcionário sai da sua empresa. | Se configurar a federação
entre o Cloud ID ou o Google Workspace com o aprovisionamento automático de utilizadores,
a revogação do acesso pode ocorrer automaticamente. Se não seguiu as práticas recomendadas e concedeu acesso às identidades de utilizadores externos aos seus recursos, tem de remover manualmente as identidades dos seus projetos e recursos. |
| Um funcionário muda a sua função. | Remover o funcionário do grupo da equipa. |
| O envolvimento de um contrato termina. | Se configurar a federação
entre o Cloud ID ou o Google Workspace com o aprovisionamento automático de utilizadores,
a revogação do acesso pode ocorrer automaticamente. Se não seguiu as práticas recomendadas e concedeu às identidades de utilizadores externos acesso aos seus recursos, tem de remover manualmente as identidades dos seus projetos e recursos. |
| Uma conta foi comprometida. | Para ver instruções, consulte o artigo Resolva problemas de credenciais Google Cloud comprometidas. |
Revogar acesso
Se fez boas escolhas na configuração do projeto, os processos seguintes são uma forma eficiente de revogar o acesso de uma pessoa.
Para determinar a que recursos uma pessoa tem acesso, use o analisador de políticas. Para ver instruções, consulte o artigo Analise as políticas de IAM.
Elimine a conta de utilizador do seu fornecedor de identidade
Se o utilizador estiver a sair da sua organização e tiver federado o Cloud Identity ou o Google Workspace com o seu fornecedor de identidade, com o aprovisionamento automático de utilizadores, a revogação do acesso pode ocorrer automaticamente.
Para obter informações sobre a eliminação de utilizadores da Workforce Identity Federation, consulte o artigo Elimine utilizadores da Workforce Identity Federation e os respetivos dados.
Mova a conta para outro grupo
Se o utilizador estiver a mudar de funções, remova a conta de utilizador dos respetivos Grupos Google atuais. Se tiver federado o Cloud ID ou o Google Workspace com o seu fornecedor de identidade para gerir a associação a grupos, a revogação do acesso pode ocorrer automaticamente.
Para mais informações, consulte o artigo Ver e editar detalhes do grupo.
Remova a conta de utilizador das políticas de autorização da IAM
Para remover uma conta de utilizador das políticas de autorização ao nível do projeto, faça o seguinte:
Na Google Cloud consola, aceda à página Autorizações IAM.
Selecione o projeto do qual quer remover uma conta de utilizador.
Clique na caixa de verificação junto à linha que contém a conta de utilizador que quer remover da lista de membros e, de seguida, clique em Remover.
Para verificar outras localizações onde a política de permissão pode ser definida, incluindo pastas, a organização ou recursos individuais, consulte o artigo Verifique se as autorizações foram removidas.
Alterne as credenciais do projeto
Alterne as chaves das contas de serviço
Se usar chaves de contas de serviço para fazer a autenticação numa conta de serviço, tem de alternar as chaves. Além disso, pondere se a pessoa pode ter tido acesso às chaves da conta de serviço noutro local fora das ferramentas, como o repositório de código fonte ou as configurações da aplicação. Google Cloud
Na Google Cloud consola, aceda à página Credenciais da API.
Clique no nome da conta de serviço que quer modificar.
No separador Chave, clique em Adicionar chave.
Clique em Criar nova chave.
Escolha o Tipo de chave que quer criar. Na maioria das situações, o formato JSON é recomendado, mas o formato P12 está disponível para compatibilidade com versões anteriores com código que depende dele.
Clique em Criar. É transferido automaticamente um ficheiro com a nova chave através do seu navegador. Implemente esta chave em todas as aplicações que precisam dela.
Depois de confirmar que a nova chave funciona como esperado, regresse à página de credenciais e elimine a chave antiga associada a essa conta de serviço.
Rote os segredos do ID de cliente OAuth
Os segredos do ID de cliente OAuth não fornecem acesso direto ao seu projeto. No entanto, se um atacante souber o segredo do ID do cliente OAuth, pode falsificar a sua aplicação e pedir acesso às Contas Google dos seus utilizadores a partir de uma aplicação maliciosa.
Pode ter de rodar os segredos do ID de cliente OAuth se a pessoa cujo acesso está a ser revogado tiver tido acesso ao segredo, inclusive no repositório do código fonte, nas configurações da aplicação ou através de funções do IAM.
Na Google Cloud consola, aceda à página Credenciais da API.
Clique no nome do ID de cliente OAuth 2.0 que quer modificar.
Na página ID de cliente, clique em Repor segredo.
Clique em Repor na caixa de diálogo de confirmação para revogar imediatamente o segredo antigo e definir um novo. Tenha em atenção que todos os utilizadores ativos têm de se voltar a autenticar no próximo pedido.
Implemente o novo segredo em todas as aplicações que o necessitem.
Alterne as chaves da API
As chaves de API não concedem acesso ao seu projeto nem aos dados dos seus utilizadores, mas controlam a quem a Google fatura os pedidos de API. Uma conta de utilizador com funções como Visualizador ou administrador de chaves de API pode ver as chaves de API do seu projeto. Se tiver chaves não restritas, tem de as eliminar ou regenerar quando revoga o acesso de alguém ao seu projeto.
Na Google Cloud consola, aceda à página Credenciais da API.
Clique no nome da chave da API que quer modificar.
Clique em Gerar chave novamente.
É apresentada uma caixa de diálogo com a chave criada recentemente. Implemente esta chave em todas as aplicações que usam a chave que quer substituir.
Depois de confirmar que as suas aplicações estão a funcionar conforme esperado com a nova chave, regresse à página de credenciais e elimine a chave antiga sem restrições.
Revogue o acesso a VMs
Se a pessoa cujo acesso está a revogar não tiver acesso de início de sessão a nenhuma das VMs do seu projeto, pode ignorar este passo.
Remover todas as chaves SSH ao nível do projeto a que a pessoa tinha acesso.
Em cada VM onde a pessoa tinha acesso SSH, remova todas as chaves ao nível da instância.
Remova a conta da pessoa de todas as VMs às quais tinha acesso de início de sessão.
Verifique se a pessoa instalou aplicações suspeitas para fornecer acesso backdoor à VM. Se não tiver a certeza acerca da segurança de qualquer código em execução na VM, recrie-o e volte a implementar as aplicações de que precisa a partir da origem.
Verifique se as definições da firewall da VM não foram alteradas em relação à configuração planeada ou esperada.
Se criar novas VMs a partir de imagens base personalizadas, verifique se as imagens base não foram modificadas de forma a comprometer a segurança das novas VMs.
Revogue o acesso a bases de dados
Se o seu projeto não usar recursos do Cloud SQL ou do AlloyDB for PostgreSQL, pode ignorar este passo.
Para revogar o acesso a uma base de dados do Cloud SQL, conclua o seguinte:
Na Google Cloud consola, aceda à página Instâncias SQL.
Clique no ID da instância da base de dados à qual quer revogar o acesso.
No menu do lado esquerdo, clique em Associações.
Confirme se a lista de endereços IP em Redes autorizadas e a lista de apps em Autorização do App Engine correspondem ao esperado. Se a pessoa cujo acesso está a tentar revogar tiver acesso a redes ou aplicações indicadas aqui, pode aceder a esta base de dados.
No menu do lado esquerdo, clique em Utilizadores.
Elimine ou altere a palavra-passe de todas as contas de utilizador às quais a pessoa tinha acesso. Certifique-se de que atualiza todas as aplicações que dependem dessas contas de utilizador.
Para revogar o acesso a uma base de dados do AlloyDB for PostgreSQL, consulte o artigo Remova um utilizador do IAM ou uma conta de serviço de um cluster.
Volte a implementar o App Engine
Por predefinição, as apps do App Engine têm acesso a uma conta de serviço que é um editor no projeto associado. Os controladores de pedidos do App Engine podem realizar ações como criar novas VMs e ler ou modificar dados no Cloud Storage. Alguém com a capacidade de implementar código no App Engine pode usar esta conta de serviço para abrir uma porta secreta no seu projeto. Se tiver preocupações acerca da integridade do código das suas apps implementadas, recomendamos que as reimplemente (incluindo todos os módulos) com uma imagem conhecida do seu sistema de controlo de versões.
Verifique se as autorizações foram removidas
Pode validar as autorizações ao nível da organização, ao nível do projeto ou através do Analisador de políticas.
Para encontrar recursos aos quais um determinado utilizador pode ter acesso ao nível da organização, use o método search-all-iam-policies na CLI do Google Cloud. Por exemplo, para determinar se um utilizador tem acesso aos seus recursos, execute o seguinte comando:
gcloud asset search-all-iam-policies --scope='organizations/ORGANIZATION_ID --query='policy:IDENTITY'
Onde:
ORGANIZATION_IDé o número da sua organização.IDENTITYé a identidade do utilizador, como um endereço de email.
Para validar as autorizações num projeto, consulte o artigo Autorizações que um principal tem num projeto.
Para validar as autorizações através do Analisador de políticas, consulte o artigo Determine a que recursos um principal pode aceder.
O que se segue?
Consulte o artigo Trate as credenciais Google Cloud comprometidas.
Saiba mais Práticas recomendadas para mitigar tokens OAuth comprometidos para a CLI do Google Cloud.
Crie uma política de recusa para especificar a que autorizações o utilizador já não pode aceder.