Este documento descreve algumas práticas recomendadas para usar os Grupos do Google e gerenciar o acesso a recursos do Cloud de Confiance by S3NS 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 os Grupos do Google. Esses tipos de grupo não são definidos por nenhum atributo de grupo do Google. No entanto, usar esses tipos de grupos na sua abordagem geral para o 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 geralmente 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 de departamento ou sai dela.
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 dos atuais.
Alguns exemplos de grupos organizacionais incluem
org.marketing-fte,org.finance-all,org.msmith-reports,org.apac-alleorg.summer-interns.Os grupos organizacionais são usados normalmente para comunicação por e-mail.
Grupos de colaboração
Os grupos de colaboração representam grupos de trabalho, membros de projetos 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. Muitas vezes, eles são criados de maneira ad hoc e autossuficiente.
A participação nos grupos de colaboração pode ser irrestrita, permitindo que qualquer pessoa da organização participe. Como alternativa, um grupo de colaboração pode ser autogerenciado, ou seja, alguns participantes podem decidir quem mais incluir no grupo.
Alguns exemplos de grupos de colaboração incluem
collab.security-discussecollab.website-relaunch.Os grupos de colaboração são usados normalmente para comunicação por e-mail.
Grupos de acesso
Os grupos de acesso são usados apenas para conceder 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, você concede papéis ao grupo e gerencia a associação ao grupo.
A estrutura dos grupos de acesso é influenciada pela estrutura dos recursos ou 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, que convidam usuários ou aprovam solicitações de participação.
Alguns exemplos de grupos de acesso incluem
access.prod-firewall-admins,access.finance-datamart-viewerseaccess.billing-dashboard-users.Os grupos de acesso são usados apenas para conceder 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, mas são usados para aplicar políticas de restrição de acesso em vez de conceder 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 é 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-loweenforcement.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 seus grupos para refletir o tipo deles
Para 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 grupos. Usar um prefixo organiza seus grupos por função em ordem alfabética, mas alguns sistemas de gerenciamento de grupos, como o Grupos para empresas, aceitam apenas 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, é possível 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 e-mails recebidos de grupos que não são destinados à comunicação.
Regras de aninhamento
Cada tipo de grupo tem regras diferentes sobre o aninhamento (aceitar um grupo como membro).
Regras de aninhamento para grupos organizacionais
Aninhar grupos organizacionais para refletir seu organograma é uma prática recomendada. Essa abordagem significa que todos os funcionários são incluídos em um grupo, e os grupos se incluem mutuamente. Por exemplo, o grupo org.finance-all pode conter os grupos org.finance-us, org.finance-germany e org.finance-australia como participantes.
É possível adicionar grupos organizacionais a qualquer um dos outros tipos de grupos 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 determinam 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, aninhar grupos de colaboração com políticas de associação diferentes pode permitir que membros que não atendem às políticas de associação de um grupo se tornem membros. Leia as políticas de associação com atençã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 é recomendável aninhar grupos de acesso. O aninhamento de grupos de acesso pode dificultar a determinação de quem tem acesso a quais recursos. Além disso, o aninhamento de grupos de acesso com políticas diferentes pode permitir que os principais ignorem políticas de associação ao grupo estritas.
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. Aninhar grupos de aplicação pode dificultar a determinação do motivo da negação de acesso a um principal. Além disso, o aninhamento de grupos de aplicação com políticas de associação diferentes pode fazer com que alguns principais 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.
Provisionamento de uma única fonte de verdade
Como os grupos organizacionais são baseados em dados de recursos humanos, é melhor provisionar esses grupos exclusivamente de um sistema de informações de recursos humanos ou de uma fonte externa de verdade, por exemplo, 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 nem remova usuários de um grupo organizacional manualmente e não permita que os usuários se removam de um grupo organizacional.
Evite usar grupos organizacionais para conceder acesso a recursos
Raramente todos os usuários em um grupo organizacional precisam do mesmo nível de acesso aos recursos. Por isso, conceder acesso a um grupo organizacional provavelmente vai resultar em alguns membros com 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 quando elas são propagadas para o Cloud Identity, com base na frequência de sincronização do IdP externo para o Cloud Identity. Esse atraso pode levar à proliferação de permissões excessivas. Por exemplo, isso pode levar os proprietários de recursos a conceder acesso a grupos existentes em vez de criar um novo, mesmo que esses grupos tenham pessoas que não precisam acessar o recurso.
Se você precisar conceder acesso usando um grupo organizacional, adicione o grupo como membro de 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 aos 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.
Usuários externos (de outra conta do Google Workspace ou do Cloud Identity) geralmente não fazem parte da sua organização. Portanto, não há motivo para eles serem membros de um grupo organizacional. Se você integrar sua força de trabalho externa à sua conta do Google Workspace ou do Cloud Identity, ela será considerada de usuários internos e poderá ser incluída nos seus 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 os Grupos para empresas e gerenciar grupos de colaboração. Isso permite que os usuários usem os Grupos do Google para criar, navegar e participar de grupos. Você precisa 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 o usa
Se você usa o Cloud Identity, mas não o Google Workspace, não há motivo para ter grupos de colaboração no Cloud Identity. Portanto, é melhor desativar o 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 do Google para empresas.
A imposição de um sufixo impede que os usuários criem um grupo com um nome que entre em conflito intencionalmente com um grupo de acesso ou organizacional que está prestes a ser provisionado de uma fonte externa. Esse cenário pode permitir que o criador do grupo de colaboração com nome falso aumente os privilégios dele.
Não use grupos de colaboração para controle de acesso
Os grupos de colaboração têm controle de acesso flexível e geralmente não seguem um ciclo de vida bem definido. Isso é bom para a colaboração, mas ruim para o controle de acesso.
Se você seguiu uma convenção de nomenclatura estrita para seus grupos de colaboração, crie uma restrição de política da organização personalizada para impedir que os grupos de colaboração recebam papéis do IAM.Da mesma forma, se você provisionar e gerenciar seus grupos de colaboração externamente, não os provisione no 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 das cargas de trabalho, use uma ferramenta adequada para autoatendimento. Sua ferramenta precisa permitir que os usuários encontrem grupos de acesso existentes e aplicar barreiras de proteção de segurança que implementam 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 entre em um grupo
Por exemplo, os usuários precisam apresentar uma justificativa?
Ciclo de vida máximo para associação a um grupo
Se a associação precisa ser aprovada e por quem
Suporte à trilha de auditoria
Uma ferramenta que atende a esses requisitos é o 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 e conceda acesso a todos os recursos que os usuários dessa função precisam. Em seguida, adicione os usuários dessa função ao grupo para dar a eles o acesso necessário, em vez de conceder as mesmas funções a cada usuário individual.
Você pode 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 concedido. Se alguns usuários não precisarem do acesso extra, crie um novo grupo de acesso e conceda a ele o acesso adicional.
Usar seus grupos de acesso para uma carga de trabalho específica
Reutilizar grupos de acesso para várias cargas de trabalho leva a permissões excessivas e complexidade de 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, crie e mantenha grupos de acesso de forma simples. Os proprietários de cargas de trabalho precisam conseguir 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 entrar nos que precisam, será menos provável que acumulem privilégios desnecessários. Se necessário, use um processo de convite ou aprovação para controlar quem pode participar do grupo.
Permitir que as assinaturas expirem automaticamente por padrão
Exigir que os usuários entrem novamente em um grupo de acesso ou renovem a assinatura após um período. Essa prática adiciona propositalmente atrito para permanecer membro de um grupo de acesso e cria um incentivo para deixar expirar as associações desnecessárias. Essa prática recomendada é fundamental para alcançar o objetivo de privilégios permanentes 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 a remoção delas de um grupo de acesso pode resultar em interrupções de serviço.
Atribua proprietários a cada grupo
Cada grupo de acesso precisa ter um ou mais proprietários designados. Isso incentiva um senso de responsabilidade pela associação ao grupo. Os proprietários podem ser a mesma pessoa ou equipe que possui a carga de trabalho associada ao grupo.
Limitar a visibilidade dos grupos de acesso
Não mostre os grupos de acesso no diretório de grupos. Eles precisam estar disponíveis na sua ferramenta de gerenciamento de grupos de acesso. Além disso, permita que apenas os membros do grupo vejam quem mais faz parte dele. Essas práticas impedem que usuários maliciosos obtenham informações valiosas.
Limitar participantes externos
Como as restrições da política de compartilhamento restrito ao domínio (DRS) se aplicam a grupos, mas não aos participantes, os grupos de acesso que permitem participantes externos podem criar uma brecha que prejudica a DRS.
Use os grupos de segurança do Cloud Identity e as restrições de grupo para permitir ou não membros externos nos 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 restrição
Use as práticas recomendadas a seguir para gerenciar seus grupos de aplicação.
Selecione a ferramenta certa para gerenciar seus grupos de restriçã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 desativem ou se removam de um grupo de aplicação.
Com os grupos dinâmicos, é possível automatizar o provisionamento de grupos de aplicação. Se você estiver usando um IdP externo, use os grupos dinâmicos fornecidos pelo IdP e provisione-os no Cloud Identity. Lembre-se de que 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 a IaC para criar grupos de aplicação, não conceda acesso desnecessariamente amplo ao pipeline.
Usar grupos de imposição para controle de acesso obrigatório e controles de autenticação
Use grupos de aplicação para aplicar o controle de acesso obrigatório. OCloud de Confiance oferece suporte ao controle de acesso obrigatório com vários serviços e ferramentas, incluindo:
- Políticas de negação do IAM
- Políticas de limite de acesso de principal do IAM
- Vinculações de acesso do Chrome Enterprise Premium
- Desativação do serviço do Google Workspace
Os grupos de aplicação também são usados para aplicar controles de autenticação, como atribuição de perfil SAML ou verificação em duas etapas (2SV).
Como todos esses controles restringem recursos ou removem o acesso, os grupos de imposição são a escolha certa.
Não permitir que os usuários saiam de um grupo de restrição
Permitir que os usuários saiam de um grupo de aplicação viola 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 IdPs externos
Se você estiver usando um IdP externo para autenticação, também poderá usar esse IdP para provisionar grupos organizacionais e grupos de aplicação.
Evite usar uma fonte externa para grupos de acesso
É possível gerenciar grupos de acesso no IdP externo e provisioná-los no Cloud Identity, mas essa abordagem tem várias desvantagens:
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 autoritário dos grupos. Por exemplo, eles podem não excluir um grupo no Cloud Identity depois que ele é 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 de que não precisam e recebam informações incorretas sobre quem tem acesso. 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 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 seu IdP externo podem não ter um endereço de e-mail.
Muitos IdPs permitem contornar isso, derivando um pseudo endereço de e-mail
do nome do grupo, como my-group@example.com. Isso funciona, mas pode causar conflitos quando o endereço de e-mail já é usado por outro grupo ou usuário. No pior caso, essa colisão de nomes pode ser explorada por um agente malicioso para criar grupos de segurança que se passam por outro tipo de grupo menos analisado.
Para evitar o risco de colisões, use um domínio secundário dedicado para grupos provisionados de uma fonte externa, como groups.example.com.
Evite conceder a função de administrador de grupos aos pipelines de implantação
Se você usa a IaC para gerenciar grupos (por exemplo, Terraform), seu pipeline de implantação precisa ter as permissões necessárias para realizar a 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 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 tornando o pipeline o proprietário de qualquer grupo que ele criar. Isso permite que o pipeline gerencie qualquer grupo que ele criar e crie mais grupos, sem autorizar o gerenciamento de grupos que não foram criados por ele.
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 grupos".
Crie uma conta de serviço e atribua a ela o papel de criador de grupos.
Use a conta de serviço do seu pipeline e transmita a flag
WITH_INITIAL_OWNERno momento da criação do grupo.
Use o Cloud Logging para auditar e monitorar seus grupos.
Com o Logging, é possível coletar, monitorar e analisar a atividade do grupo.
Auditar mudanças de associação
Adicionar ou remover um membro de um grupo organizacional, de acesso ou de aplicação pode afetar os recursos a que ele tem acesso. Por isso, é importante manter um registro de auditoria que rastreie essas mudanças.
Exigir justificativas para entrar em grupos de acesso
Para tornar seus dados de monitoramento mais úteis, exija que os usuários forneçam uma justificativa ao entrar ou solicitar entrada em um grupo e registre essa justificativa. Se houver um processo de aprovação, registre detalhes sobre quem aprovou a solicitação.
Esses metadados extras podem ajudar você a analisar por que alguém foi adicionado a um grupo e, por extensão, por que recebeu acesso a determinados recursos.
Ativar o compartilhamento registro de auditoria do Cloud Identity
Configure o Cloud Identity para rotear registros para o Cloud Logging para que você possa processar esses registros de auditoria da mesma forma que outros registros do Cloud de Confiance , incluindo a configuração de alertas ou o uso de um sistema externo de gerenciamento de informações e eventos de segurança (SIEM, na sigla em inglês).