Práticas recomendadas para usar os Grupos Google

Este documento descreve algumas práticas recomendadas para usar grupos Google para gerir o acesso a recursos com o Identity and Access Management (IAM). Google Cloud

Tipos de grupos

Os tipos de grupos indicados aqui são uma forma de pensar, usar e gerir grupos Google. Estes tipos de grupos não são definidos por nenhum atributo do grupo Google. No entanto, usar estes tipos de grupos na sua abordagem geral à gestão de grupos Google pode ajudar a evitar alguns erros 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 são normalmente provenientes de dados de recursos humanos. Podem basear-se no departamento, na estrutura de relatórios, na localização geográfica ou noutros 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 são normalmente usados para comunicação por email.

  • Grupos de colaboração

    Os grupos de colaboração representam grupos de trabalho, membros de projetos ou utilizadores que querem colaborar num projeto ou debater um tópico específico.

    A estrutura dos grupos de colaboração não está associada a nenhuma estrutura organizacional. São frequentemente criadas de forma autónoma e ad hoc.

    A adesão a grupos de colaboração pode ser ilimitada, permitindo que qualquer pessoa na organização adira. Em alternativa, um grupo de colaboração pode ser autogerido, o que significa que determinados 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 são normalmente usados para comunicação por email.

  • Grupos de acesso

    Os grupos de acesso são usados com o único objetivo de conceder acesso. Representam funções profissionais e são usadas para simplificar a atribuição de funções necessárias para desempenhar estas funções profissionais. Em vez de conceder funções a principais individuais, concede funções ao grupo e, em seguida, gere a associação ao grupo.

    A estrutura dos grupos de acesso é influenciada pela estrutura dos recursos ou das cargas de trabalho na sua organização. A implementaçã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 utilizadores para o grupo ou aprovam os pedidos dos utilizadores para aderir ao grupo.

    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 conceder acesso. Não são usados para fins de comunicação.

  • Grupos de aplicação

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

    Normalmente, a estrutura dos grupos de aplicação é influenciada por uma combinação de requisitos de conformidade e estrutura organizacional.

    Normalmente, a associação a um grupo de aplicação é determinada por um conjunto de regras predefinidas que analisam o nível de autorização, a localização ou a função de um utilizador 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. Não são usados para fins de comunicação.

Atribua nomes aos grupos que reflitam o respetivo tipo

Para ajudar a seguir as práticas recomendadas no resto deste documento, use nomes de grupos que lhe permitam determinar o tipo de um grupo a partir do respetivo nome. Pode usar uma convenção de nomenclatura ou domínios secundários.

Convenção de nomenclatura

Segue-se um exemplo de uma 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 aplicação: enforcement.GROUP_DESCRIPTION@example.com. Por exemplo, enforcement.sso-users@example.com.

Adote a convenção que funciona para a sua organização e é suportada pelo software de gestão de grupos. A utilização de um prefixo organiza os seus grupos por função, mas alguns sistemas de gestão de grupos, como o Groups for Business, suportam apenas sufixos. Se não puder usar prefixos, pode usar sufixos ou domínios secundários.

Domínios secundários

Em alternativa às convenções de nomenclatura, pode usar domínios secundários para incorporar o tipo de grupo no nome, por exemplo, access.example.com. Os domínios secundários que são um subdomínio de um domínio validado não requerem validação e não precisam de existir no DNS. Além disso, ao não criar registos Mail Exchange (MX) de DNS para os domínios secundários, pode bloquear a receção de emails de grupos que não se destinam à comunicação.

Regras de aninhamento

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

Regras de aninhamento para grupos organizacionais

Aninhar grupos organizacionais para refletir o organigrama é uma prática recomendada. Esta abordagem significa que todos os funcionários estão incluídos num grupo e, em seguida, os grupos incluem-se mutuamente. Por exemplo, o grupo org.finance-all pode conter os grupos org.finance-us, org.finance-germany e org.finance-australia como membros.

Pode adicionar grupos organizacionais a qualquer um dos outros tipos de grupos como membros. Isto pode ser muito mais fácil do que ter de adicionar todos os membros de um grupo organizacional a outro grupo.

Não adicione nenhum outro tipo de grupo a um grupo organizacional como membro. 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 deve ter um conjunto bem definido de políticas que determinam como os membros são adicionados. Se dois grupos de colaboração seguirem as mesmas políticas de adesão, podem ser aninhados. No entanto, a aninhagem de grupos de colaboração com políticas de adesão diferentes pode permitir que membros que não cumprem as políticas de adesão de um grupo se tornem membros. Reveja cuidadosamente as políticas de associação 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 deve aninhar grupos de acesso. A aninhagem de grupos de acesso pode dificultar a determinação de quem tem acesso a que recursos. Além disso, a aninhagem de grupos de acesso com políticas de acesso diferentes pode permitir que os principais ignorem as políticas de associação a grupos de acesso rigorosas.

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 aninhagem de grupos de autorização pode dificultar a determinação do motivo pelo qual o acesso de um principal está a ser recusado. Além disso, a aninhagem de grupos de aplicação com políticas de associação diferentes pode fazer com que alguns diretores sejam afetados por restrições não intencionais.

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

Faça a gestão de grupos organizacionais

Use as seguintes práticas recomendadas para gerir os seus grupos organizacionais.

Aprovisione a partir de uma única fonte de informação fidedigna

Uma vez que os grupos organizacionais se baseiam em dados de recursos humanos, é melhor aprovisionar estes grupos exclusivamente a partir de um sistema de informação de recursos humanos ou de uma fonte de verdade externa, por exemplo, um fornecedor de identidade (IdP) externo ou um sistema de governação de identidades, como o Sailpoint, o Okta ou o Entra ID.

Não permitir modificações de grupos

Não adicione nem remova utilizadores de um grupo organizacional manualmente e não permita que os utilizadores se removam de um grupo organizacional.

Evite usar grupos organizacionais para conceder acesso a recursos

Raramente, todos os utilizadores num grupo organizacional precisam do mesmo nível de acesso aos recursos. Por este motivo, a concessão de acesso a um grupo organizacional vai provavelmente resultar em alguns membros do grupo com mais acesso do que realmente precisam.

Além disso, pode haver um atraso entre o momento em que as alterações são feitas num IdP externo e o momento em que são propagadas para o Cloud ID, com base na frequência de sincronização do IdP externo para o Cloud ID. Este atraso pode levar à proliferação de autorizações em excesso. Por exemplo, pode levar os proprietários de recursos a concederem acesso a grupos existentes em vez de criarem um novo grupo, mesmo que esses grupos existentes contenham pessoas que não precisam de aceder ao recurso.

Se tiver de conceder acesso através de um grupo organizacional, adicione o grupo organizacional como membro a um grupo de acesso, em vez de conceder acesso diretamente, e conceda apenas funções com autorizações limitadas, como visualizador da organização. Caso contrário, use grupos de acesso para dar acesso a recursos.

Não permitir contas de serviço nem utilizadores externos em grupos organizacionais

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

Normalmente, os utilizadores externos (utilizadores de uma conta do Google Workspace ou do Cloud Identity diferente) não fazem parte da sua organização. Por isso, não há motivo para serem membros de um grupo organizacional. Se incorporar a sua força de trabalho externa na sua própria conta do Google Workspace ou Cloud ID, esta é considerada utilizadores internos e pode ser incluída nos seus grupos organizacionais.

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

Faça a gestão de grupos de colaboração

Use as seguintes práticas recomendadas para gerir os seus grupos de colaboração.

Use o Groups for Business para gerir grupos de colaboração

Se estiver a usar o Google Workspace, pode usar os Grupos para empresas para gerir grupos de colaboração. Isto permite que os utilizadores usem os Grupos Google para criar, procurar e aderir a grupos. Tem de configurar o Grupos do Google para empresas para permitir que os utilizadores criem novos grupos de colaboração.

Desative o Groups for Business se não o usar

Se estiver a usar o Cloud Identity, mas não o Google Workspace, não existe motivo para ter grupos de colaboração no Cloud Identity. Por isso, é melhor desativar o Grupos para empresas para impedir que os utilizadores criem grupos no Cloud Identity.

Aplique um sufixo para grupos de colaboração

Se estiver a usar o Groups for Business, configure-o para aplicar um sufixo. Isto é especialmente importante se permitir que todos criem novos grupos do Groups for Business.

A aplicação de um sufixo impede que os utilizadores criem um grupo com um nome que entre em conflito intencionalmente com um grupo de acesso ou um grupo organizacional que está prestes a ser aprovisionado a partir de uma origem externa. Este cenário pode permitir que o criador do grupo de colaboração com nome falso aumente os respetivos privilégios.

Não use grupos de colaboração para controlo de acesso

Os grupos de colaboração destinam-se a ter um controlo de acesso flexível e, normalmente, não seguem um ciclo de vida bem definido. Isto torna-os bons para a colaboração, mas maus para o controlo de acesso.

Se seguiu rigorosamente uma convenção de nomenclatura para os seus grupos de colaboração, pode criar uma restrição de política da organização personalizada para impedir que sejam concedidas funções do IAM aos grupos de colaboração.

Da mesma forma, se aprovisionar e gerir os seus grupos de colaboração externamente, não os aprovisione no Cloud ID, o que permitiria que fossem usados indevidamente para fins de controlo de acesso.

Faça a gestão de grupos de acesso

Use as seguintes práticas recomendadas para gerir os seus grupos de acesso.

Selecione a ferramenta certa para gerir os seus grupos de acesso

Uma vez que os grupos de acesso são geridos pelos proprietários das cargas de trabalho, use uma ferramenta adequada para o autosserviço. A sua ferramenta deve permitir que os utilizadores encontrem grupos de acesso existentes e apliquem restrições de segurança que apliquem os seguintes controlos:

  • Quem (membros de que grupo organizacional) é elegível para aderir a um grupo de acesso

  • Que requisitos têm de ser cumpridos para um utilizador aderir a um grupo

    Por exemplo, os utilizadores têm de fornecer uma justificação?

  • Tempo máximo de vida para a adesão ao grupo

  • Se a adesão tem de ser aprovada e por quem

  • Apoio técnico para o registo de auditoria

Uma ferramenta que cumpre estes requisitos são os grupos JIT.

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

Crie um grupo de acesso para cada função profissional e conceda-lhe acesso a todos os recursos de que os utilizadores nessa função profissional precisam. Em seguida, pode adicionar utilizadores nessa função profissional ao grupo para lhes conceder o acesso de que precisam, em vez de conceder as mesmas funções a cada utilizador individual.

Pode usar um único grupo de acesso para conceder acesso a vários recursos ou até a vários projetos. No entanto, certifique-se de que cada membro do grupo precisa do acesso que concede ao grupo. Se alguns utilizadores não precisarem do acesso adicional, crie um novo grupo de acesso e conceda esse acesso adicional ao grupo.

Use os 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 atribuição de autorizações excessiva e a uma complexidade de administração.

Remova barreiras à 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, torne os grupos de acesso fáceis de criar e manter. Os proprietários de cargas de trabalho devem poder criar grupos de acesso de forma autónoma, com suporte para a nomenclatura adequada.

Permitir que os utilizadores encontrem e participem em grupos de acesso

Se os utilizadores puderem descobrir grupos de acesso existentes e aderir aos que precisam, é menos provável que acumulem privilégios desnecessários. Se necessário, pode usar um processo de convite ou aprovação para controlar quem pode aderir ao grupo.

Permitir que as subscrições expirem automaticamente por predefinição

Exigir que os utilizadores voltem a aderir a um grupo de acesso ou prolonguem a respetiva associação após um período. Esta prática adiciona intencionalmente atrito para permanecer membro de um grupo de acesso e cria um incentivo para deixar expirar as associações desnecessárias. Esta prática recomendada é fundamental para alcançar o objetivo de privilégios de acesso nulos (ZSP) e é especialmente importante para utilizadores externos.

No entanto, não aplique esta regra a contas de serviço, uma vez que a remoção de contas de serviço de um grupo de acesso pode resultar em interrupções de serviço.

Atribua proprietários designados a cada grupo

Cada grupo de acesso deve ter um ou mais proprietários designados. Isto incentiva um sentido de responsabilidade pela adesão ao grupo. Os proprietários podem ser a mesma pessoa ou equipa que detém a carga de trabalho associada ao grupo.

Limite a visibilidade dos grupos de acesso

Não tornar os grupos de acesso visíveis no Diretório de grupos. (Devem ser detetáveis na ferramenta de gestão de grupos de acesso.) Além disso, permita que apenas os membros do grupo vejam quem mais é membro. Estas práticas impedem que intervenientes prejudiciais obtenham informações valiosas.

Limite os membros externos

Uma vez que as restrições da política de partilha restrita ao domínio (DRS) se aplicam aos grupos, mas não aos membros do grupo, os grupos de acesso que permitem membros externos podem criar uma brecha que prejudica a DRS.

Use grupos de segurança do Cloud Identity e restrições de grupos 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 permitam membros externos.

Faça a gestão de grupos de aplicação

Use as seguintes práticas recomendadas para gerir os seus grupos de aplicação.

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

Uma vez que a adesã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 desativem ou se removam de um grupo de aplicação.

A utilização de grupos dinâmicos permite-lhe automatizar o aprovisionamento de grupos de aplicação. Se estiver a usar um IdP externo, use os grupos dinâmicos fornecidos pelo IdP e, em seguida, aprovisione-os no Cloud Identity. Tenha em atenção que a utilização de um IdP externo pode introduzir um atraso nas atualizações de políticas.

Se não puder usar grupos dinâmicos, considere usar o Terraform ou outra ferramenta de infraestrutura como código (IaC) para aprovisionar os seus grupos de aplicação. Se usar a IaC para criar grupos de aplicação, certifique-se de que não concede um acesso desnecessariamente amplo ao pipeline.

Use grupos de aplicação para o controlo de acesso obrigatório e os controlos de autenticação

Use grupos de acesso para aplicar o controlo de acesso obrigatório. OGoogle Cloud suporta o controlo de acesso obrigatório com vários serviços e ferramentas, incluindo o seguinte:

Os grupos de aplicação também são usados para aplicar controlos de autenticação, como a atribuição de perfis SAML ou a validação em dois passos (2SV).

Uma vez que estes controlos restringem funcionalidades ou removem o acesso, os grupos de aplicação são a escolha certa.

Não permitir que os utilizadores saiam de um grupo de aplicação

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

Práticas recomendadas para IdPs externos

Se estiver a usar um IdP externo para autenticação, pode ser útil usar também esse IdP para o aprovisionamento de grupos organizacionais e grupos de aplicação.

Evite usar uma origem externa para grupos de acesso

É possível gerir grupos de acesso no IdP externo e aprovisioná-los no Cloud Identity, mas esta abordagem tem várias desvantagens:

  • Atrasos no aprovisionamento

    As alterações feitas no IdP externo podem demorar até várias horas a serem refletidas no grupo de acesso.

  • Risco de divergência

    Alguns IdPs não assumem o controlo autoritário dos grupos. Por exemplo, podem não eliminar um grupo no Cloud ID depois de ser eliminado externamente ou eliminar ativamente membros do grupo que existem no Cloud ID, mas não no IdP.

    A divergência pode fazer com que os utilizadores mantenham o acesso de que não precisam e dá-lhes informações incorretas sobre quem tem acesso. Também pode adicionar atrito à criação de grupos de acesso.

Para evitar estas armadilhas, use IdPs externos para aprovisionar apenas grupos organizacionais e de aplicação, e use uma ferramenta como JIT Groups para gerir grupos de acesso diretamente no Cloud Identity.

Use um domínio secundário se estiver a mapear grupos por nome

O Cloud ID identifica os grupos pelo endereço de email, mas os grupos no seu IdP externo podem não ter um endereço de email.

Muitos IdPs permitem contornar esta situação, permitindo-lhe derivar um pseudo endereço de email do nome do grupo, como usar my-group@example.com. Isto funciona, mas pode originar conflitos quando este endereço de email já é usado por um grupo ou um utilizador diferente. No pior dos casos, esta colisão de nomenclatura pode ser explorada por um ator malicioso para criar grupos de segurança que se fazem passar por outro tipo de grupo menos escrutinado.

Para evitar o risco de colisões, use um domínio secundário dedicado para grupos que aprovisiona a partir da origem externa, como groups.example.com.

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

Se usar a IaC para gerir grupos (por exemplo, o Terraform), o pipeline de implementação tem de ter as autorizações necessárias para realizar a respetiva tarefa. A função de administrador de grupos autoriza a criação de grupos, mas também permite que qualquer principal com essa função faça a gestão de todos os grupos na conta do Cloud Identity.

Pode restringir o acesso concedido a um pipeline criando uma conta de serviço com apenas uma autorização (a capacidade de criar um grupo) e, em seguida, tornando o pipeline o proprietário de qualquer grupo que criar. Isto permite que essa conduta gerencie qualquer grupo que criar e crie mais grupos, sem autorização para gerenciar qualquer grupo que não tiver criado.

Os passos seguintes descrevem esta abordagem:

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

    Atribua um nome descritivo a esta função, como Criador do grupo.

  2. Crie uma conta de serviço e atribua-lhe a função Criador de grupos.

  3. Use a conta de serviço para o seu pipeline e transmita a flag WITH_INITIAL_OWNER no momento da criação do grupo.

Use o Cloud Logging para auditar e monitorizar os seus grupos.

Os registos permitem-lhe recolher, monitorizar e analisar a atividade do grupo.

Audite as alterações de membros

A adição ou a remoção de um membro de um grupo organizacional, um grupo de acesso ou um grupo de aplicação pode afetar os recursos aos quais o membro tem acesso. Por isso, é importante manter uma trilha de auditoria que monitorize estas alterações.

Exija justificações para a adesão a grupos de acesso

Para tornar os seus dados de monitorização mais úteis, exija que os utilizadores forneçam uma justificação quando aderem a um grupo ou pedem para aderir a um grupo, e registe a justificação. Se existir um processo de aprovação, registe os detalhes sobre quem aprovou o pedido.

Estes metadados adicionais podem ajudar posteriormente a analisar o motivo pelo qual alguém foi adicionado a um grupo e, por extensão, o motivo pelo qual lhe foi concedido acesso a determinados recursos.

Ative a partilha de registos de auditoria do Cloud ID

Configure o Cloud ID para encaminhar registos para o Cloud Logging, para que possa processar estes registos de auditoria da mesma forma que outros Google Cloud registos, Google Cloud incluindo a configuração de alertas ou a utilização de um sistema de gestão de informações e eventos de segurança (SIEM) externo.