Esta página foi traduzida pela API Cloud Translation.

Práticas recomendadas para usar os Grupos do Google

Este documento descreve algumas práticas recomendadas para usar os Grupos do Google para gerenciar o acesso aos recursos do Google Cloud com o Identity and Access Management (IAM).

Tipos de grupos

Os tipos de grupos listados aqui são uma maneira de pensar, usar e gerenciar grupos do Google. Esses tipos de grupo não são definidos por nenhum atributo do grupo do Google. No entanto, o uso desses tipos de grupo na sua abordagem geral de gerenciamento de grupos do Google pode ajudar a evitar algumas armadilhas de segurança comuns.

Este documento usa os seguintes tipos de grupos:

Grupos organizacionais

Os grupos organizacionais representam subconjuntos da estrutura de uma organização e normalmente são originados de dados de recursos humanos. Eles podem ser baseados em departamento, estrutura de relatórios, localização geográfica ou outros agrupamentos organizacionais.

Os membros de um grupo organizacional mudam quando um funcionário entra na organização, muda para um departamento diferente ou sai da organização.

A estrutura geral dos grupos organizacionais pode mudar quando a empresa se reorganiza. Uma reorganização pode levar à criação de novos grupos ou à desativação de grupos existentes.

Alguns exemplos de grupos organizacionais incluem org.marketing-fte, org.finance-all, org.msmith-reports, org.apac-all e org.summer-interns.

Os grupos organizacionais geralmente são usados para comunicação por e-mail.
Grupos de colaboração

Os grupos de colaboração representam grupos de trabalho, membros do projeto ou usuários que querem colaborar em um projeto ou discutir um tópico específico.

A estrutura dos grupos de colaboração não está vinculada a nenhuma estrutura organizacional. Elas são criadas de forma ad hoc e autoatendimento.

A participação em grupos de colaboração pode ser irrestrita, permitindo que qualquer pessoa na organização participe. Como alternativa, um grupo de colaboração pode ser autogerido, o que significa que alguns membros podem decidir quem mais incluir no grupo.

Alguns exemplos de grupos de colaboração incluem collab.security-discuss e collab.website-relaunch.

Os grupos de colaboração geralmente são usados para comunicação por e-mail.
Grupos de acesso

Os grupos de acesso são usados com o único objetivo de fornecer acesso. Eles representam funções de trabalho e são usados para simplificar a atribuição de papéis necessários para realizar essas funções. Em vez de conceder papéis a principais individuais, conceda papéis ao grupo e gerencie a associação a ele.

A estrutura dos grupos de acesso é influenciada pela estrutura dos recursos ou das cargas de trabalho na sua organização. A implantação de um novo recurso ou carga de trabalho pode exigir a criação de novos grupos de acesso.

A associação a grupos de acesso geralmente é controlada por um ou mais proprietários do grupo, que convidam os usuários ou aprovam as solicitações de adesão.

Alguns exemplos de grupos de acesso incluem access.prod-firewall-admins, access.finance-datamart-viewers e access.billing-dashboard-users.

Os grupos de acesso são usados apenas para fornecer acesso. Eles não são usados para fins de comunicação.
Grupos de restrição

Os grupos de aplicação são semelhantes aos grupos de acesso, exceto que eles são usados para aplicar políticas de restrição de acesso em vez de fornecer acesso.

A estrutura dos grupos de aplicação normalmente é influenciada por uma combinação de requisitos de compliance e estrutura organizacional.

A associação a um grupo de aplicação geralmente é determinada por um conjunto de regras predefinidas que analisam o nível de autorização, o local ou a função de um usuário na organização.

Alguns exemplos de grupos de aplicação incluem enforcement.users-in-restricted-locations, enforcement.fedramp-low e enforcement.sso-users.

Os grupos de aplicação são usados apenas para aplicar políticas de restrição de acesso. Eles não são usados para fins de comunicação.

Nomeie os grupos de acordo com o tipo deles

Para ajudar a seguir as práticas recomendadas no restante deste documento, use nomes de grupo que permitam determinar o tipo de um grupo pelo nome. É possível usar uma convenção de nomenclatura ou domínios secundários.

Convenção de nomenclatura

Confira um exemplo de convenção de nomenclatura para tornar o tipo de grupo visível:

Grupos organizacionais: org.GROUP_NAME@example.com. Por exemplo, org.finance-all@example.com.
Grupos de colaboração: collab.TEAM_NAME@example.com. Por exemplo, collab.msmiths-team@example.com.
Grupos de acesso: access.JOB_FUNCTION@example.com. Por exemplo, access.billing-dashboard-users@example.com.
Grupos de restrição: enforcement.GROUP_DESCRIPTION@example.com. Por exemplo, enforcement.sso-users@example.com.

Adote a convenção que funciona para sua organização e é compatível com o software de gerenciamento de grupo. O uso de um prefixo classifica seus grupos por função, mas alguns sistemas de gerenciamento de grupos, como o Grupos para empresas, só aceitam sufixos. Se não for possível usar prefixos, use sufixos ou domínios secundários.

Domínios secundários

Como alternativa às convenções de nomenclatura, você pode usar domínios secundários para incorporar o tipo de grupo ao nome, por exemplo, access.example.com. Os domínios secundários que são subdomínios de um domínio verificado não precisam de verificação e não precisam existir no DNS. Além disso, ao não criar registros de troca de e-mail (MX) do DNS para os domínios secundários, você pode bloquear o recebimento de e-mails em grupos que não são destinados à comunicação.

Regras de aninhamento

Diferentes tipos de grupos têm regras diferentes para determinar se o aninhamento (aceitar um grupo como membro) é permitido.

Regras de aninhamento para grupos organizacionais

A prática recomendada é aninhar grupos organizacionais para refletir seu organograma. Essa abordagem significa que cada funcionário é incluído em um grupo e os grupos são incluídos uns nos outros. Por exemplo, o grupo org.finance-all pode conter os grupos org.finance-us, org.finance-germany e org.finance-australia como membros.

É possível adicionar grupos organizacionais a qualquer um dos outros tipos de grupo como participantes. Isso pode ser muito mais fácil do que adicionar todos os membros de um grupo organizacional a outro.

Não adicione nenhum outro tipo de grupo a um grupo organizacional como participante. Não use grupos de acesso, aplicação ou colaboração como parte de uma hierarquia organizacional.

Regras de aninhamento para grupos de colaboração

Cada grupo de colaboração precisa ter um conjunto bem definido de políticas que determinem como os membros são adicionados. Se dois grupos de colaboração seguirem as mesmas políticas de associação, eles poderão ser aninhados. No entanto, a aninhação de grupos de colaboração com políticas de associação diferentes pode permitir que membros que não atendam às políticas de associação de um grupo se tornem participantes. Analise as políticas de associação com cuidado antes de aninhar grupos de colaboração.

Os grupos de colaboração podem ter grupos organizacionais como membros.

Regras de aninhamento para grupos de acesso

Normalmente, não é necessário aninhar grupos de acesso. A aninhação de grupos de acesso pode dificultar a determinação de quem tem acesso a quais recursos. Além disso, aninhar grupos de acesso com políticas de acesso diferentes pode permitir que diretores ignorem políticas de associação a grupos de acesso rígidas.

Os grupos de acesso podem ter grupos organizacionais como membros.

Regras de aninhamento para grupos de aplicação

Não aninhe grupos de aplicação. A aninhação de grupos de aplicação pode dificultar a determinação do motivo pelo qual o acesso de um principal está sendo negado. Além disso, o aninhamento de grupos de aplicação de políticas com políticas de associação diferentes pode fazer com que alguns princípios sejam afetados por restrições não intencionais.

Os grupos de aplicação podem ter grupos organizacionais como membros.

Gerenciar grupos organizacionais

Use as práticas recomendadas a seguir para gerenciar seus grupos organizacionais.

Provisionar usando uma única fonte de informações

Como os grupos organizacionais são baseados em dados de recursos humanos, é melhor provisioná-los exclusivamente em um sistema de informações de recursos humanos ou em uma fonte de verdade externa, como um provedor de identidade externo (IdP) ou um sistema de governança de identidade, como Sailpoint, Okta ou Entra ID.

Não permitir modificações de grupo

Não adicione ou remova usuários de um grupo organizacional manualmente e não permita que eles saiam de um grupo organizacional.

Evite usar grupos organizacionais para conceder acesso a recursos

Todos os usuários em um grupo organizacional raramente precisam do mesmo nível de acesso aos recursos. Por esse motivo, é provável que conceder acesso a um grupo organizacional resulte em alguns membros do grupo tendo mais acesso do que realmente precisam.

Além disso, pode haver um atraso entre o momento em que as mudanças são feitas em um IdP externo e o momento em que elas são propagadas para o Cloud Identity, com base na frequência de sincronização do IdP externo com o Cloud Identity. Esse atraso pode levar à proliferação de permissões em excesso. Por exemplo, isso pode levar os proprietários de recursos a conceder acesso a grupos existentes em vez de criar um novo, mesmo se esses grupos tiverem pessoas que não precisam acessar o recurso.

Se você precisar fornecer acesso usando um grupo organizacional, adicione o grupo organizacional como membro a um grupo de acesso, em vez de conceder acesso diretamente, e conceda apenas papéis com permissões limitadas, como "Leitor da organização". Caso contrário, use grupos de acesso para conceder acesso a recursos.

Não permitir contas de serviço e usuários externos em grupos organizacionais

Não inclua contas de serviço em grupos organizacionais, porque elas não representam pessoas.

Os usuários externos, de uma conta diferente do Google Workspace ou do Cloud Identity, geralmente não fazem parte da sua organização. Por isso, não há motivo para que eles sejam membros de um grupo organizacional. Se você integrar a força de trabalho externa à sua conta do Google Workspace ou do Cloud Identity, ela será considerada interna e poderá ser incluída nos grupos organizacionais.

Use grupos de segurança do Cloud Identity e restrições de grupo para aplicar essas regras.

Gerenciar grupos de colaboração

Use as práticas recomendadas a seguir para gerenciar seus grupos de colaboração.

Usar o Grupos para empresas para gerenciar grupos de colaboração

Se você usa o Google Workspace, pode usar o Grupos para empresas para gerenciar grupos de colaboração. Isso permite que os usuários usem os Grupos do Google para criar, procurar e participar de grupos. É necessário configurar o Grupos para empresas para permitir que os usuários criem novos grupos de colaboração.

Desativar o Grupos para empresas se você não usa

Se você estiver usando o Cloud Identity, mas não o Google Workspace, não há motivos para ter grupos de colaboração no Cloud Identity. Portanto, é melhor desativar os Grupos para empresas para impedir que os usuários criem grupos no Cloud Identity.

Forçar um sufixo para grupos de colaboração

Se você estiver usando o Grupos para empresas, configure-o para aplicar um sufixo. Isso é especialmente importante se você permitir que todos criem novos grupos do Grupos para Empresas.

A aplicação de um sufixo impede que os usuários criem um grupo com um nome que se choque intencionalmente com um grupo de acesso ou organizacional que está para ser provisionado de uma fonte externa. Esse cenário pode permitir que o criador do grupo de colaboração com nome incorreto aumente os privilégios.

Não usar grupos de colaboração para controle de acesso

Os grupos de colaboração têm controle de acesso frouxo e geralmente não seguem um ciclo de vida bem definido. Isso é bom para colaboração, mas ruim para o controle de acesso.

Se você seguiu estritamente uma convenção de nomenclatura para seus grupos de colaboração, é possível criar uma restrição de política da organização personalizada para impedir que os grupos de colaboração recebam funções do IAM.

Da mesma forma, se você provisionar e gerenciar seus grupos de colaboração externamente, não os provisione para o Cloud Identity, o que permitiria que eles fossem usados indevidamente para fins de controle de acesso.

Gerenciar grupos de acesso

Use as práticas recomendadas a seguir para gerenciar seus grupos de acesso.

Selecione a ferramenta certa para gerenciar seus grupos de acesso

Como os grupos de acesso são gerenciados pelos proprietários da carga de trabalho, use uma ferramenta adequada para o autoatendimento. Sua ferramenta precisa permitir que os usuários encontrem grupos de acesso e apliquem limites de segurança que usam os seguintes controles:

Quem (membros de qual grupo organizacional) pode participar de um grupo de acesso
Quais requisitos precisam ser atendidos para que um usuário participe de um grupo

Por exemplo, os usuários precisam justificar?
Ciclo de vida máximo para a associação a um grupo
Se a associação precisa ser aprovada e por quem
Suporte para trilha de auditoria

Uma ferramenta que atende a esses requisitos é JIT Groups.

Usar grupos de acesso para modelar funções de trabalho e conceder acesso a recursos

Crie um grupo de acesso para cada função do trabalho e conceda acesso a todos os recursos necessários para os usuários nessa função. Em seguida, adicione usuários com essa função ao grupo para conceder o acesso necessário a eles em vez de conceder as mesmas funções a cada usuário individualmente.

É possível usar um único grupo de acesso para fornecer acesso a vários recursos ou até mesmo a vários projetos. No entanto, verifique se cada membro do grupo precisa do acesso que você concede ao grupo. Se alguns usuários não precisarem do acesso extra, crie um novo grupo de acesso e conceda o acesso extra a ele.

Usar seus grupos de acesso para uma carga de trabalho específica

A reutilização de grupos de acesso para várias cargas de trabalho leva a uma complexidade excessiva de permissões e administração.

Remover barreiras para a criação de grupos de acesso para proprietários de cargas de trabalho

Para reduzir a tentação de reutilizar um grupo de acesso existente, crie e mantenha os grupos de acesso de maneira simples. Os proprietários de carga de trabalho precisam poder criar grupos de acesso por autoatendimento, com suporte para nomenclatura adequada.

Permitir que os usuários encontrem e participem de grupos de acesso

Se os usuários puderem descobrir grupos de acesso e participar dos que precisam, eles terão menos probabilidade de acumular privilégios desnecessários. Se necessário, use um convite ou processo de aprovação para controlar quem pode participar do grupo.

Permitir que as assinaturas expirem automaticamente por padrão

Exija que os usuários voltem a participar de um grupo de acesso ou estenda a associação após um período. Essa prática aumenta intencionalmente a fricção para permanecer membro de um grupo de acesso e cria um incentivo para permitir que as associações desnecessárias expirem. Essa prática recomendada é essencial para alcançar o objetivo de privilégios de acesso zero (ZSP, na sigla em inglês) e é especialmente importante para usuários externos.

No entanto, não aplique essa regra a contas de serviço, porque remover contas de serviço de um grupo de acesso pode resultar em interrupções no serviço.

Atribuir proprietários a cada grupo

Cada grupo de acesso precisa ter um ou mais proprietários designados. Isso incentiva um senso de responsabilidade pela participação no grupo. Os proprietários podem ser a mesma pessoa ou equipe que tem a carga de trabalho associada ao grupo.

Limitar a visibilidade dos grupos de acesso

Não torne os grupos de acesso visíveis no diretório de grupos. Eles devem ser detectáveis na sua ferramenta de gerenciamento de grupos de acesso. Além disso, permita que apenas os participantes do grupo vejam quem mais faz parte dele. Essas práticas impedem que usuários de má-fé tenham acesso a informações valiosas.

Limitar participantes externos

Como as restrições da política de compartilhamento restrito de domínio (DRS, na sigla em inglês) se aplicam a grupos, mas não aos participantes, os grupos de acesso que permitem membros externos podem criar uma brecha que prejudica o DRS.

Use grupos de segurança do Cloud Identity e restrições de grupo para permitir ou não permitir membros externos para grupos de acesso. Além disso, considere usar uma convenção de nomenclatura especial, como external.access.GROUP_NAME@example.com, para grupos de acesso que permitem participantes externos.

Gerenciar grupos de aplicação

Use as práticas recomendadas a seguir para gerenciar seus grupos de aplicação.

Selecione a ferramenta certa para gerenciar seus grupos de aplicação

Como a associação a grupos de aplicação é baseada em regras organizacionais e usada para aplicar restrições de segurança, não permita que os membros se descadastrem ou saiam de um grupo de aplicação.

O uso de grupos dinâmicos permite automatizar o provisionamento de grupos de enforcement. Se você estiver usando um IdP externo, use os grupos dinâmicos fornecidos pelo IdP e provisioneie-os para o Cloud Identity. O uso de um IdP externo pode causar um atraso nas atualizações de políticas.

Se não for possível usar grupos dinâmicos, considere usar o Terraform ou outra ferramenta de infraestrutura como código (IaC) para provisionar seus grupos de aplicação. Se você usa o IaC para criar grupos de aplicação, não dê acesso amplo desnecessário ao pipeline.

Usar grupos de aplicação para controle de acesso obrigatório e controles de autenticação

Use grupos de acesso para aplicar o controle de acesso obrigatório. O Google Cloud oferece suporte ao controle de acesso obrigatório com vários serviços e ferramentas, incluindo:

Os grupos de aplicação também são usados para aplicar controles de autenticação, como a atribuição de perfil SAML ou a verificação em duas etapas.

Como esses controles restringem recursos ou removem o acesso, os grupos de aplicação são a escolha certa.

Não permitir que os usuários saiam de um grupo de aplicação de políticas

Permitir que os usuários saiam de um grupo de aplicação vai contra os princípios do controle de acesso obrigatório. Para impedir que os usuários saiam do grupo, use a API Groups Settings para definir a propriedade whoCanLeaveGroup como NONE_CAN_LEAVE.

Práticas recomendadas para provedores de identidade externos

Se você estiver usando um IdP externo para autenticação, também poderá usá-lo para provisionar grupos organizacionais e grupos de aplicação de políticas.

Evite usar uma fonte externa para grupos de acesso

É possível gerenciar grupos de acesso no IdP externo e provisioná-los para o Cloud Identity, mas há várias desvantagens nessa abordagem:

Atrasos no provisionamento

Pode levar até várias horas para que as mudanças feitas no IdP externo sejam refletidas no grupo de acesso.
Risco de divergência

Alguns IdPs não assumem o controle de grupos. Por exemplo, eles não podem excluir um grupo no Cloud Identity depois que ele for excluído externamente ou excluir ativamente membros do grupo que existem no Cloud Identity, mas não no IdP.

A divergência pode fazer com que os usuários mantenham o acesso que não precisam e recebam informações incorretas sobre quem tem acesso. Isso também pode dificultar a criação de grupos de acesso.

Para evitar esses problemas, use IdPs externos para provisionar apenas grupos organizacionais e de aplicação e use uma ferramenta como os grupos JIT para gerenciar grupos de acesso diretamente no Cloud Identity.

Use um domínio secundário se você estiver mapeando grupos por nome

O Cloud Identity identifica grupos por endereço de e-mail, mas os grupos no IdP externo podem não ter um endereço de e-mail.

Muitos IdPs permitem que você contorne isso, criando um endereço de e-mail pseudônimo com base no nome do grupo, como usando my-group@example.com. Isso funciona, mas pode levar a colisões quando esse endereço de e-mail já é usado por um grupo ou usuário diferente. Na pior das hipóteses, essa colisão de nomes pode ser explorada por um agente malicioso para criar grupos de segurança que se disfarçam de outro tipo de grupo menos analisado.

Para evitar o risco de colisões, use um domínio secundário dedicado para grupos provisionados na fonte externa, como groups.example.com.

Evite conceder a função de administrador de grupos a pipelines de implantação

Se você usa a IaC para gerenciar grupos (por exemplo, o Terraform), o pipeline de implantação precisa ter as permissões necessárias para realizar a tarefa. O papel de administrador de grupos autoriza a criação de grupos, mas também permite que qualquer pessoa com essa função gerencie todos os grupos na conta do Cloud Identity.

É possível restringir o acesso concedido a um pipeline criando uma conta de serviço com apenas uma permissão (a capacidade de criar um grupo) e, em seguida, tornando o pipeline o proprietário de qualquer grupo criado. Isso permite que o pipeline gerencie qualquer grupo que ele crie e crie mais grupos, sem autorizar a gerenciar nenhum grupo que não tenha criado.

As etapas a seguir descrevem essa abordagem:

Crie uma função de administrador personalizada que inclua apenas a permissão de criação de grupo da API Admin.

Dê um nome descritivo a essa função, como "Criador de grupo".
Crie uma conta de serviço e atribua a ela o papel de criador de grupo.
Use a conta de serviço para o pipeline e transmita a flag WITH_INITIAL_OWNER no momento da criação do grupo.

Use o Cloud Logging para auditar e monitorar seus grupos.

O registro permite coletar, monitorar e analisar a atividade do grupo.

Auditar mudanças na lista de participantes

Adicionar ou remover um membro de um grupo organizacional, de acesso ou de aplicação de políticas pode afetar os recursos a que o membro tem acesso. Por isso, é importante manter um rastro de auditoria que rastreie essas mudanças.

Exigir justificativas para participar de grupos de acesso

Para tornar seus dados de monitoramento mais úteis, exija que os usuários forneçam uma justificativa ao entrar em um grupo ou solicitar a entrada em um grupo e registre a justificativa. Se houver um processo de aprovação, registre detalhes sobre quem aprovou a solicitação.

Esses metadados adicionais podem ajudar a analisar por que alguém foi adicionado a um grupo e, por extensão, por que ele recebeu acesso a determinados recursos.

Configure o Cloud Identity para encaminhar registros para o Cloud Logging. Assim, você poderá processar esses registros de auditoria da mesma forma que outros registros do Google Cloud, incluindo a configuração de alertas ou o uso de um sistema externo de informações de segurança e gerenciamento de eventos (SIEM, na sigla em inglês).