Este documento apresenta as práticas recomendadas para decidir quantas contas do Cloud Identity ou do Google Workspace, organizações do Google Cloud e contas de faturamento você precisa usar. No documento, fornecemos orientações sobre como identificar um design que atenda aos requisitos organizacionais e de segurança.
No Google Cloud, o gerenciamento de identidade e acesso é baseado em dois princípios básicos:
As contas do Cloud Identity e do Google Workspace são contêineres para usuários e grupos. Portanto, essas contas são essenciais para autenticar seus usuários corporativos e gerenciar o acesso aos recursos do Google Cloud. Uma conta do Cloud Identity ou do Google Workspace indica um diretório de usuários, e não uma conta de usuário individual. Contas de usuário individuais são chamadas de usuários ou contas de usuário.
As organizações são contêineres para projetos e recursos no Google Cloud. As organizações permitem que os recursos sejam estruturados hierarquicamente e são fundamentais para gerenciar recursos de maneira centralizada e eficiente.
Este documento destina-se principalmente a clientes que estão configurando ambientes corporativos.
Contas do Cloud Identity e do Google Workspace
O Google Workspace é um conjunto integrado de apps de colaboração e produtividade nativos da nuvem. Ele inclui ferramentas que permitem gerenciar usuários, grupos e autenticação.
O Cloud Identity fornece um subconjunto dos recursos do Google Workspace. Assim como o Google Workspace, o Cloud Identity permite gerenciar usuários, grupos e autenticação, mas não inclui todos os recursos de colaboração e produtividade do Google Workspace.
O Cloud Identity e o Google Workspace compartilham uma plataforma
técnica comum e usam o mesmo conjunto de APIs e ferramentas administrativas. Os produtos
compartilham o conceito de uma conta como um contêiner para usuários e grupos. Esse
contêiner é identificado por um nome de domínio, como example.com. Para gerenciar
usuários, grupos e autenticação, os dois produtos podem ser considerados
equivalentes.
Combinar o Cloud Identity e o Google Workspace em uma única conta
Como o Cloud Identity e o Google Workspace compartilham uma plataforma comum, é possível combinar o acesso aos produtos em uma única conta.
Se você já administra uma conta do Google Workspace e quer permitir que mais usuários usem o Google Cloud, talvez não queira atribuir a todos os usuários uma licença do Google Workspace. Nesse caso, adicione o Cloud Identity Free à sua conta atual. Em seguida, é possível integrar mais usuários sem cobrança extra e decidir quais usuários terão acesso ao Google Workspace atribuindo a eles uma licença do Google Workspace.
Da mesma forma, se você já administra uma conta do Cloud Identity Free ou Premium, convém conceder a determinados usuários o direito de usar o Google Workspace. Em vez de criar contas separadas do Google Workspace para esses usuários, é possível adicionar o Google Workspace a uma conta do Cloud Identity. Depois que você atribui a licença do Google Workspace aos usuários selecionados, eles podem usar os apps de produtividade e colaboração.
Usar o menor número possível de contas, mas o máximo possível
Para permitir que seus usuários colaborem usando o Google Workspace e minimizem a sobrecarga administrativa, é melhor gerenciar todos os usuários com uma única conta do Cloud Identity ou do Google Workspace e fornecer uma única conta de usuário para cada indivíduo. Isso ajuda a garantir que configurações como políticas de senha, Logon único e verificação em duas etapas sejam aplicadas de maneira consistente a todos os usuários.
Independentemente desses benefícios do uso de uma única conta do Cloud Identity ou do Google Workspace, você consegue flexibilidade e autonomia administrativa usando várias contas. Ao decidir quantas contas do Cloud Identity ou do Google Workspace serão usadas, considere todos os requisitos que sugerem o uso de várias contas. Em seguida, use o menor número de contas do Cloud Identity ou do Google Workspace que atenda aos seus requisitos.
Usar contas separadas para preparo e produção
Para a maioria das configurações que podem ser definidas no Cloud Identity e no Google Workspace, é possível escolher o escopo em que cada uma delas se aplicará. Por exemplo, é possível especificar a localização geográfica dos dados por usuário, grupo ou unidade organizacional. Quando você planeja aplicar uma nova configuração, inicialmente pode escolher um escopo pequeno (por exemplo, por usuário) e verificar se a configuração atende às suas expectativas. Depois de verificar a configuração, será possível aplicá-la a um conjunto maior de grupos ou unidades organizacionais.
Ao contrário da maioria das configurações, a integração de uma conta do Cloud Identity ou do Google Workspace com um provedor de identidade externo (IdP, na sigla em inglês) tem um impacto global:
- A ativação do Logon único é uma configuração global que se aplica a todos os usuários, exceto aos superadministradores.
- Dependendo do seu IdP externo, a configuração do provisionamento de usuários também pode ter impacto global. Uma configuração incorreta acidental no IdP externo pode levar os usuários a serem modificados, suspensos ou até mesmo excluídos acidentalmente.
Para atenuar esses riscos, tenha contas de preparo e produção separadas do Cloud Identity ou do Google Workspace:
- Use a conta de preparo para verificar as alterações de configuração arriscadas antes de aplicar a mesma alteração à sua conta de produção.
- Crie alguns usuários de teste nas contas de preparo que você e outros administradores podem usar para verificar as alterações de configuração. Mas não conceda a seus usuários acesso à conta de preparo.
Se você tiver instâncias de preparo e produção separadas do IdP externo, siga estas etapas:
- Integre sua conta de teste do Cloud Identity ou do Google Workspace à sua instância do IdP de preparo.
- Integre sua conta de produção do Cloud Identity ou do Google Workspace à sua instância do IdP de produção.
Por exemplo, imagine que você planeja configurar a federação com o Active Directory e tem uma floresta separada do Active Directory para fins de teste. Nesse caso, você integra sua conta de preparação do Cloud Identity ou do Google Workspace à floresta de preparo e à conta de produção do Cloud Identity ou Google Workspace à sua floresta principal. Aplique a mesma abordagem de mapeamento para domínios DNS, usuários e grupos aos pares de floresta/conta, conforme mostrado no seguinte diagrama:
Suas florestas e domínios de produção e preparo do Active Directory podem usar domínios DNS que não permitem aplicar a mesma abordagem de mapeamento de domínio para preparo e produção. Nesse caso, considere registrar mais domínios de sufixo de nome principal de usuário (UPN, na sigla em inglês) na floresta de preparo.
Da mesma forma, se você planeja configurar a federação com o Azure Active Directory, é melhor adotar a seguinte abordagem:
- Integre a conta de teste do Cloud Identity ou do Google Workspace a um locatário de preparo do Azure Active Directory.
- Integre a conta de produção do Cloud Identity ou o Google Workspace ao seu locatário principal do Azure Active Directory.
Aplique a mesma abordagem de mapeamento para domínios DNS, usuários e grupos aos pares de locatário/conta:
Seus locatários de produção e preparo do Azure Active Directory podem usar domínios DNS que não permitem aplicar a mesma abordagem de mapeamento de domínio para preparo e produção. Nesse caso, considere adicionar um domínio extra ao seu locatário.
Usar domínios DNS separados entre as contas do Cloud Identity e do Google Workspace
Ao adicionar pela primeira vez um domínio como example.com à sua
conta do Cloud Identity ou do Google Workspace, é necessário
verificar se você é proprietário do domínio.
Depois de adicionar e confirmar um domínio, é possível adicionar subdomínios como
marketing.example.com e finance.example.com sem precisar verificar cada
subdomínio individualmente.
No entanto, se você adicionar subdomínios sem verificar cada um deles, poderá ocorrer conflitos se você tiver outra conta do Cloud Identity ou do Google Workspace que já utilize esse subdomínio. Para evitar esses conflitos, use domínios separados para cada conta. Por exemplo, se você precisa de duas contas do Cloud Identity ou do Google Workspace, tente evitar o uso de dois domínios em que um domínio é um subdomínio do outro. Em vez disso, use dois domínios que não tenham essa relação. Essa prática se aplica ao domínio principal e aos secundários.
Não separar o Google Workspace e o Google Cloud
Se você já usa o Google Workspace, alguns usuários da sua conta do Google Workspace podem ter recebido privilégios de superadministrador para executar tarefas administrativas.
Os usuários com privilégios de superadministrador recebem uma permissão implícita para modificar a política de gerenciamento de identidade e acesso (IAM) do nó da organização. Isso permite que os superadministradores atribuam a si mesmos o papel de administrador da organização ou qualquer outro papel na organização do Google Cloud. Ter acesso de superadministrador a uma conta do Cloud Identity ou do Google Workspace também permite que um usuário exclua a conta, a organização associada do Google Cloud e todos os recursos dela. Portanto, você precisa presumir que os superadministradores têm acesso total a todos os recursos de uma organização.
Os superadministradores também podem ser uma preocupação de segurança se os administradores do Google Workspace forem um conjunto diferente de usuários responsáveis pelo gerenciamento da organização do Google Cloud. Nesse caso, é possível criar uma conta separada do Cloud Identity dedicada ao Google Cloud para limitar o acesso dos superadministradores do Google Workspace aos recursos do Google Cloud. A separação do Google Workspace e do Google Cloud pode ter várias consequências não intencionais.
Por exemplo, tente criar usuários separados na conta do Cloud Identity e restringir o acesso aos usuários da organização do Google Cloud à conta do Cloud Identity. Isso garante que a implantação do Google Cloud e o Google Workspace sejam totalmente isolados. No entanto, a duplicação de usuários prejudica a experiência do usuário e a sobrecarga administrativa. Além disso, não será possível receber e-mails de notificação enviados pelo Google Cloud, porque o domínio usado pelo Cloud Identity precisa ser diferente do domínio usado para o Google Workspace e, portanto, é inadequado para roteamento. e-mail.
Se você, em vez disso, referenciar os usuários da conta do Google Workspace na sua organização do Google Cloud, poderá comprometer o isolamento entre o Google Workspace e o Google Cloud:
Os superadministradores do Google Workspace podem usar a delegação em todo o domínio para representar qualquer usuário na mesma conta do Google Workspace. Um superadministrador não autorizado pode usar os privilégios dele para recuperar o acesso ao Google Cloud.
Uma abordagem mais eficaz do que usar contas separadas é separar as responsabilidades entre os administradores do Google Workspace e do Google Cloud para reduzir o número de superadministradores:
A maioria das tarefas administrativas no Google Workspace não requer privilégios de superadministrador. Use papéis de administrador predefinidos ou papéis de administrador personalizados em vez de privilégios de superadministrador para conceder aos administradores do Google Workspace as permissões necessárias para a realização dessas tarefas.
Retenha apenas um número mínimo de usuários superadministradores e desestimule o uso diário.
Aproveite as vantagens da auditoria para detectar atividades suspeitas entre usuários administrativos.
Proteger seu IdP externo ao usar o Logon único
O Cloud Identity e o Google Workspace permitem configurar o logon único com seu IdP externo, como o Active Directory, o Azure Active Directory ou o Okta, entre outros. Se o logon único estiver ativado, o Cloud Identity e o Google Workspace confiarão no IdP externo para autenticar os usuários em nome do Google.
A ativação do Logon único oferece várias vantagens:
- Os usuários podem usar as credenciais atuais para fazer login nos serviços do Google.
- Os usuários não precisam digitar as senhas novamente se já tiverem uma sessão de login.
- É possível aplicar políticas de autenticação multifator consistentes nos seus aplicativos e em todos os serviços do Google.
Mas ativar o Logon único também expõe você a riscos. Quando o logon único está ativado e um usuário precisa ser autenticado, o Cloud Identity ou o Google Workspace redireciona o usuário para seu IdP externo. Depois de autenticar o usuário, o IdP retorna ao Google uma declaração SAML com a identidade do usuário. A declaração SAML está assinada. Portanto, o Google pode verificar a autenticidade da declaração SAML e verificar se o provedor de identidade correto foi usado. No entanto, não há como o Cloud Identity ou o Google Workspace verificarem se o IdP tomou a decisão de autenticação correta e declarou corretamente a identidade do usuário.
Se o Logon único estiver ativado, a segurança geral e a integridade da implantação do Google dependerão da segurança e da integridade do IdP. Sua conta do Cloud Identity ou do Google Workspace e todos os recursos que dependem dos usuários gerenciados por ela estarão em risco se alguma das seguintes situações estiver configurada de modo não seguro:
- O IdP propriamente dito
- As máquinas em que o provedor está sendo executado
- O banco de dados do usuário do qual o provedor está recebendo informações do usuário
- Qualquer outro sistema do qual o provedor depende
Para evitar que o Logon único se torne um ponto fraco na sua segurança, verifique se o IdP e todos os sistemas de que ele depende estão configurados com segurança:
- Limite o número de usuários com acesso administrativo ao seu IdP ou a qualquer um dos sistemas em que o provedor depende.
- Não conceda acesso administrativo a esses sistemas a nenhum usuário a quem você também não concederia privilégios de superadministrador no Cloud Identity ou no Google Workspace.
- Não use o Logon único se não tiver certeza sobre os controles de segurança em vigor para o IdP externo.
Acesso seguro às suas zonas DNS
As contas do Cloud Identity e do Google Workspace são identificadas por um nome de domínio DNS principal. Ao criar uma nova conta do Cloud Identity ou do Google Workspace, verifique a propriedade do domínio DNS criando um registro DNS especial na zona DNS correspondente.
A importância do DNS e o impacto na segurança geral da implantação do Google vão além do processo de inscrição:
O Google Workspace conta com os registros MX do DNS para rotear e-mails. Ao modificar esses registros MX, um invasor pode rotear e-mails para um servidor diferente e ter acesso a informações confidenciais.
Se um invasor puder adicionar registros à zona DNS, ele poderá redefinir a senha de um usuário superadministrador e conseguir acesso à conta.
Para evitar que o DNS se torne um ponto fraco na sua segurança, verifique se o servidor DNS está configurado com segurança:
Limite o número de usuários que têm acesso administrativo ao servidor DNS que gerencia o domínio principal usado para o Cloud Identity ou o Google Workspace.
Não conceda acesso administrativo ao servidor DNS a nenhum usuário a quem você também não concederia privilégios de superadministrador no Cloud Identity ou no Google Workspace.
Se você planeja implantar uma carga de trabalho no Google Cloud que tenha requisitos de segurança que não sejam atendidos pela infraestrutura de DNS atual, considere registrar um novo domínio DNS que use servidores DNS separados ou um serviço DNS gerenciado para essa carga de trabalho.
Exportar registros de auditoria para o BigQuery
O Cloud Identity e o Google Workspace mantêm vários registros de auditoria para rastrear as alterações de configuração e outras atividades que podem ser relevantes para a segurança da sua conta do Cloud Identity ou do Google Workspace. A tabela a seguir resume esses registros de auditoria.
| Registro | Atividades capturadas |
|---|---|
| Administrador | Ações realizadas no Google Admin Console |
| Login | Tentativas de login bem-sucedidas, malsucedidas e suspeitas no seu domínio |
| Token | Instâncias de autorização ou revogação de acesso a aplicativos da Web ou para dispositivos móveis de terceiros |
| Grupos | Alterações em grupos e associações a grupos |
É possível acessar esses registros de auditoria por meio do Admin Console ou da API Reports. Para a maioria dos registros de auditoria, os dados são retidos por seis meses.
Se você estiver operando em um setor regulamentado, manter os dados de auditoria por seis meses pode não ser suficiente. Para reter dados por um período mais longo, configure os registros de auditoria para serem exportados para o BigQuery.
Para limitar o risco de acesso não autorizado aos registros de auditoria exportados, use um projeto dedicado do Google Cloud para o conjunto de dados do BigQuery. Para manter os dados de auditoria seguros contra adulterações ou exclusões, conceda acesso ao projeto e ao conjunto de dados com base no privilégio mínimo.
Os registros de auditoria do Cloud Identity e do Google Workspace são complementares aos registros de auditoria do Cloud. Se você também usa o BigQuery para coletar registros de auditoria do Cloud e outros registros de auditoria específicos do aplicativo, é possível correlacionar eventos de login a atividades realizadas por um usuário no Google Cloud ou nos aplicativos. Ser capaz de correlacionar dados de auditoria em várias fontes pode ajudar você a detectar e analisar atividades suspeitas.
A configuração da exportação do BigQuery requer uma licença do Google Workspace Enterprise. Depois de configurar os principais registros de auditoria, eles são exportados para todos os usuários, incluindo esses usuários sem uma licença do Google Workspace. Certos registros, como os registros de auditoria do Drive e de dispositivos móveis, são exportados para usuários que têm pelo menos uma licença do Google Workspace Business.
Se você usa o Cloud Identity Free para a maioria dos usuários, ainda pode realizar a exportação para o BigQuery adicionando o Google Workspace Enterprise à conta atual do Cloud Identity e comprando licenças do Google Workspace para um conjunto selecionado de administradores.
Organizações
As organizações permitem que você organize recursos em uma hierarquia de projetos e pastas, com o nó da organização sendo a raiz. As organizações são associadas a uma conta do Cloud Identity ou do Google Workspace e derivam o nome do domínio principal da conta associada. Uma organização é criada automaticamente quando um usuário da conta do Cloud Identity ou do Google Workspace cria um primeiro projeto.
Cada conta do Cloud Identity ou do Google Workspace pode ter apenas uma única organização. Na verdade, não é possível criar uma organização sem uma conta correspondente. Mesmo com essa dependência, é possível conceder aos usuários de várias contas diferentes acesso a recursos em uma organização:
A flexibilidade para referenciar usuários de diferentes contas do Cloud Identity ou do Google Workspace permite separar a forma como você trata as contas e organizações. É possível separar a decisão de quantas contas do Cloud Identity ou do Google Workspace são necessárias para gerenciar seus usuários a partir da decisão de quantas organizações você precisa para gerenciar seus recursos.
O número de organizações que você cria e as respectivas finalidades podem afetar profundamente sua posição de segurança, a autenticidade de suas equipes e departamentos e a consistência e eficiência da administração.
As seções a seguir descrevem as práticas recomendadas para decidir quantas organizações usar.
Usar o menor número possível de organizações, mas o máximo possível
É possível aproveitar a herança com a hierarquia de recursos de uma organização para reduzir o esforço relacionado ao gerenciamento das políticas do IAM e da organização. Ao configurar políticas no nível da pasta ou da organização, você garante que as políticas sejam aplicadas de maneira consistente em uma sub-hierarquia de recursos e evita trabalhos repetitivos de configuração. Para minimizar a sobrecarga administrativa, é melhor usar o menor número possível de organizações.
Por outro lado, é possível ganhar mais flexibilidade e autonomia administrativa usando várias organizações. As seções a seguir descrevem quando é possível exigir mais flexibilidade ou autenticidade.
De qualquer forma, ao decidir quantas organizações usar, considere todos os requisitos que sugerem o uso de várias organizações. Em seguida, use o menor número de organizações que atendem aos seus requisitos.
Usar organizações para delinear a autoridade administrativa
Em uma hierarquia de recursos, é possível conceder permissões no nível do recurso, do projeto ou da pasta. O nível máximo no qual é possível conceder permissões a um usuário é a organização.
Um usuário que tenha o papel de Administrador da organização no nível da organização tem controle total sobre a organização, os recursos e as políticas do IAM. Um administrador da organização pode assumir o controle de qualquer recurso da organização e pode delegar acesso administrativo a qualquer outro usuário.
No entanto, os recursos de um administrador são restritos à organização, tornando-a o escopo final da autoridade administrativa:
- Um administrador não pode acessar recursos em outras organizações, a menos que a permissão seja explicitamente concedida.
- Nenhum usuário fora da organização pode retirar o controle de um Administrador da organização.
O número certo de organizações a serem usadas depende do número de grupos independentes de usuários administrativos na sua empresa:
- Se a empresa estiver organizada por função, talvez você tenha um departamento responsável por supervisionar todas as implantações do Google Cloud.
- Se a empresa for organizada por divisão ou tiver diversas subsidiárias autônomas, talvez não haja um departamento responsável.
Se um departamento for responsável pela supervisão das implantações do Google Cloud, use um nó da organização do Google Cloud. Dentro da organização, use pastas para estruturar recursos e conceder diferentes níveis de acesso a outras equipes e departamentos.
Se você estiver lidando com vários departamentos independentes, a tentativa de centralizar a administração usando uma organização pode causar atritos:
- Se você designar um departamento para gerenciar a organização, talvez enfrente a resistência de outros departamentos.
- Se você permitir que várias equipes ou departamentos compartilhem uma única organização, poderá ser difícil manter uma hierarquia de recursos consistente e garantir que as políticas do IAM e as políticas da organização sejam usadas de maneira consistente nos recursos.
Para evitar esse tipo de atrito, use várias organizações e crie estruturas de pastas separadas em cada uma delas. Ao usar organizações separadas, você estabelece limites entre diferentes grupos de usuários administrativos, delimitando a autoridade deles.
Usar uma organização de preparo separada
Para ajudar a garantir a consistência e evitar trabalhos de configuração repetitivos, organize seus projetos em uma hierarquia de pastas e aplique políticas do IAM e organizacionais no nível da pasta ou da organização.
Há uma desvantagem de ter políticas que se aplicam a muitos projetos e recursos. Qualquer alteração na própria política ou na hierarquia de recursos a que a política se aplica pode ter consequências de longo alcance e não intencionais. Para reduzir esse risco, é melhor testar as alterações na política antes de aplicá-las à organização principal.
Recomendamos que você crie uma organização de teste separada. Essa organização ajuda você a testar mudanças na hierarquia de recursos, nas políticas do IAM, nas políticas organizacionais ou em outras configurações que tenham impacto em toda a organização, como níveis de acesso e políticas.
Para garantir que os resultados dos testes realizados na organização de preparo também se apliquem à organização de produção, configure a organização de preparo para usar a mesma estrutura de pastas da organização principal, mas com apenas um pequeno número de projetos. A qualquer momento, as políticas da organização e do IAM na organização de teste precisam corresponder às políticas da organização de produção ou refletir a próxima versão das políticas que você pretende aplicar à organização de produção.
Conforme mostrado no diagrama a seguir, use a conta de teste do Cloud Identity ou do Google Workspace como base para a organização de teste. Use a conta de teste (ou o IdP externo que sua conta de teste está integrada) para criar usuários de teste dedicados e uma estrutura de grupo que espelha os grupos usados na conta de produção do Cloud Identity ou do Google Workspace. É possível usar esses usuários e grupos de teste dedicados para testar as políticas do IAM sem afetar os usuários atuais.
Evitar usar uma organização de teste separada
Para cada carga de trabalho de produção que você planeja implantar no Google Cloud, você provavelmente precisa de um ou mais ambientes de teste, que as equipes de desenvolvimento e DevOps podem usar para validar novas versões.
Do ponto de vista da segurança, para evitar que versões não testadas afetem acidentalmente as cargas de trabalho de produção, é preciso separar os ambientes de teste dos de produção. Da mesma forma, os dois tipos de ambientes têm requisitos diferentes para as políticas do IAM. Por exemplo, para conceder aos desenvolvedores e testadores a flexibilidade necessária, os requisitos de segurança para os ambientes de teste podem ser substancialmente mais flexíveis do que os de produção.
Como mostra o diagrama a seguir, do ponto de vista da configuração, é útil manter os ambientes de teste o mais semelhantes aos de produção. Qualquer diferença aumenta o risco de uma implantação que funcionou corretamente em um ambiente de teste falhar quando implantada em um ambiente de produção.
Para encontrar um equilíbrio entre manter ambientes isolados e consistentes, use pastas dentro da mesma organização para gerenciar ambientes de teste e produção:
- Aplique políticas comuns do IAM ou da organização em ambientes no nível organizacional (ou usando uma pasta mãe comum).
- Use as pastas individuais para gerenciar políticas do IAM e da organização que diferem de acordo com o tipo de ambiente.
Não use sua organização de teste para gerenciar ambientes de teste. Os ambientes de teste são essenciais para a produtividade das equipes de desenvolvimento e DevOps. Gerenciar esses ambientes no ambiente de preparo restringiria sua capacidade de usar a organização de preparo para testar mudanças na política. Qualquer alteração poderá interromper o trabalho dessas equipes. Em resumo, se você usa uma organização de preparo para gerenciar ambientes de teste, prejudica a finalidade dessa organização.
Usar uma organização separada para fazer experiências
Para aproveitar ao máximo o Google Cloud, permita que suas equipes de desenvolvimento, DevOps e operações se familiarizem com a plataforma e expandam a experiência executando tutoriais. Incentive-os a testar novos recursos e serviços.
Use uma organização separada como o ambiente de sandbox para oferecer suporte a esses tipos de atividades experimentais. Ao usar uma organização separada, é possível manter as experiências livres de qualquer política, configuração ou automação usada na organização de produção.
Evite usar a organização de teste para fazer experimentos. O ambiente de teste precisa usar políticas do IAM e da organização semelhantes às usadas pela organização de produção. Portanto, é provável que o ambiente de teste esteja sujeito às mesmas limitações do ambiente de produção. Ao mesmo tempo, flexibilizar as políticas para permitir a realização de experimentos prejudicaria a finalidade da organização de teste.
Para evitar que sua organização experimental se torne desorganizada, gere custos excessivos ou se torne um risco de segurança, emita diretrizes que definem como as equipes podem usar a organização e quem é responsável pela manutenção dela. Além disso, considere configurar a automação para excluir automaticamente recursos ou até mesmo projetos inteiros após um determinado número de dias.
Como mostra o diagrama a seguir, ao criar uma organização para experiências, primeiro crie uma conta dedicada do Cloud Identity. Em seguida, use os usuários atuais da sua conta principal do Cloud Identity ou do Google Workspace para conceder a eles acesso à organização experimental.
Para gerenciar a conta extra do Cloud Identity, você precisa de pelo menos uma conta de usuário de superadministrador na conta do Cloud Identity. Para informações sobre como proteger essas contas de usuário de superadministrador, consulte Práticas recomendadas para contas de superadministrador.
Usar o compartilhamento restrito ao domínio para impor relações de confiança
As políticas do IAM permitem adicionar qualquer identidade válida do Google como membro. Isso significa que, ao editar a política do IAM de um recurso, projeto, pasta ou organização, é possível adicionar membros de diferentes fontes, como estes:
- Usuários da conta do Cloud Identity ou do Google Workspace à qual a organização está associada, bem como as contas de serviço da mesma organização
- Usuários de outras contas do Cloud Identity ou do Google Workspace
- Contas de serviço de outras organizações
- Contas de usuário pessoais, incluindo usuários e contas
pessoais do
gmail.comque usam um endereço de e-mail corporativo
Ser capaz de referenciar usuários de diferentes fontes é útil para cenários e projetos em que você precisa colaborar com afiliados ou outras empresas. Na maioria dos outros casos, é melhor restringir as políticas do IAM para permitir apenas membros de fontes confiáveis.
Use o compartilhamento com restrição de domínio para definir um conjunto de contas confiáveis do Cloud Identity ou do Google Workspace que terá permissão para adicionar membros às políticas do IAM. Defina essa política no nível da organização (para que ela se aplique a todos os projetos) ou em uma pasta próxima à parte superior da hierarquia de recursos (para permitir que determinados projetos fiquem isentos).
Se você usa contas e organizações separadas do Cloud Identity ou do Google Workspace para separar os ambientes de preparação, produção e experimento, use políticas de compartilhamento restritas ao domínio para aplicar a segregação, conforme listado na tabela a seguir:
| Organização | Conta do Cloud Identity ou do Google Workspace confiável |
|---|---|
| Preparo | Preparo |
| Produção | Produção |
| Experimentos | Produção |
Usar nomes de domínio neutros para organizações
As organizações são identificadas por um nome de domínio DNS, como example.com. O
nome de domínio é derivado do nome do domínio principal da conta
do Cloud Identity ou do Google Workspace associada.
Se houver um nome de domínio DNS canônico que seja usado em toda a empresa, use esse domínio como o domínio principal na conta de produção do Cloud Identity ou do Google Workspace. Ao usar o nome DNS canônico, você garante que os funcionários possam reconhecer facilmente o nome do nó da organização.
Se a empresa tem várias subsidiárias ou uma variedade de marcas diferentes, talvez não haja um nome de domínio canônico. Em vez de escolher arbitrariamente um dos domínios atuais, considere registrar um novo domínio DNS que seja neutro e dedicado para uso pelo Google Cloud. Ao usar um nome DNS neutro, você evita expressar uma preferência por uma marca, uma subsidiária ou um departamento específico na sua empresa, o que pode afetar negativamente a adoção da nuvem. Adicione seus outros domínios específicos da marca como domínios secundários para que possam ser usados em IDs de usuário e no Logon único.
Usar contas de faturamento nas organizações do Google Cloud
As contas de faturamento definem quem paga por um determinado conjunto de recursos do Google Cloud. Mesmo que as contas de faturamento possam existir fora de uma organização do Google Cloud, elas costumam ser associadas a uma organização.
Quando contas de faturamento são associadas a uma organização, elas são consideradas um sub-recurso da organização e estão sujeitas às políticas do IAM definidas nela. Mais importante, isso significa que é possível usar os papéis de faturamento do IAM para definir quais usuários ou grupos podem administrar ou usar uma conta.
Um usuário que tenha o papel Billing Account User pode vincular um projeto
a uma conta de faturamento, fazendo com que os recursos sejam cobrados nessa conta.
Vincular um projeto a uma conta de faturamento funciona dentro da mesma organização, mas
também entre organizações.
Se você usa várias organizações, pode aproveitar o fato de que as contas de faturamento podem ser usadas em várias organizações. Isso permite que você decida quantas contas de faturamento são necessárias, independentemente de quantas organizações forem necessárias.
O número ideal de contas de faturamento depende exclusivamente dos requisitos comerciais ou contratuais, como moeda, perfil de pagamento e número de faturas separadas. Como você fez com contas e organizações, para minimizar a complexidade, use o menor número de contas de faturamento que satisfazem seus requisitos.
Para detalhar os custos acumulados em várias organizações, configure sua
conta de faturamento para
exportar dados de faturamento para o BigQuery.
Cada registro exportado para o BigQuery não contém apenas o nome
e o ID do projeto, mas também o ID da organização a que o projeto está associado
(no campo project.ancestry_numbers).
A seguir
- Criar uma nova conta do Cloud Identity
- Saiba como o Google Cloud permite a autenticação de usuários corporativos em um ambiente híbrido e conheça os padrões comuns.
- Consulte nossas práticas recomendadas para federar o Google Cloud com um provedor de identidade externo.
- Saiba como realizar a federação do Google Cloud com o Active Directory ou com o Azure Active Directory.
- Consulte as práticas recomendadas para gerenciar identidade e acesso.