Práticas recomendadas para o planejamento de contas e organizações

Neste documento, apresentamos as práticas recomendadas para decidir quantas contas do Cloud Identity ou do G Suite, 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 G Suite 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 G Suite indica um diretório de usuários, 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 G Suite

O G Suite é um pacote integrado de aplicativos 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 G Suite. Assim como o G Suite, o Cloud Identity permite gerenciar usuários, grupos e autenticação, mas não inclui todos os recursos de colaboração e produtividade do G Suite.

O Cloud Identity e o G Suite 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 G Suite em uma conta

Como o Cloud Identity e o G Suite compartilham uma plataforma comum, é possível combinar o acesso aos produtos em uma conta.

Se você já administra uma conta do G Suite e quer permitir que mais usuários usem o Google Cloud, talvez não queira atribuir uma licença do G Suite a todos os usuários. Nesse caso, adicione o Cloud Identity Free à sua conta atual. É possível integrar mais usuários sem custo extra e decidir quais usuários precisam ter acesso ao G Suite ao atribuir uma licença do G Suite.

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 G Suite. Em vez de criar contas do G Suite separadas para esses usuários, é possível adicionar o G Suite a uma conta do Cloud Identity. Depois de atribuir a licença do G Suite aos usuários selecionados, eles poderão usar os aplicativos 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 G Suite e para minimizar a sobrecarga administrativa, é melhor gerenciar todos os usuários usando uma conta do Cloud Identity ou do G Suite e fornecer uma conta de usuário para cada pessoa. 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.

Há muitos benefícios em usar uma conta do Cloud Identity ou do G Suite, mas é possível ganhar flexibilidade e autonomia administrativa usando várias contas. Ao decidir quantas contas do Cloud Identity ou do G Suite usar, 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 G Suite que atendam 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 G Suite, é possível escolher o escopo em que cada configuração será aplicada. Por exemplo, é possível especificar a localização geográfica dos seus 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 G Suite com um provedor de identidade externo 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 de produção separadas do Cloud Identity ou do G Suite:

  • 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 do Cloud Identity ou do G Suite à instância do IdP de preparo.
  • Integre sua conta de produção do Cloud Identity ou do G Suite à instância do IdP de produção.

Por exemplo, suponha que você planeje configurar a federação com o Active Directory e tenha uma floresta separada do Active Directory para fins de teste. Nesse caso, você integra sua conta de preparo do Cloud Identity ou do G Suite à floresta de preparo e a conta de produção do Cloud Identity ou do G Suite à sua floresta principal. Aplique a mesma abordagem de mapeamento para domínios DNS, usuários e grupos a ambos os pares de floresta/conta, conforme mostrado no diagrama a seguir:

Abordagem de mapeamento do Active Directory para domínios, usuários e grupos de DNS.

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 preparo do Cloud Identity ou do G Suite a um locatário de preparo do Azure Active Directory.
  • Integre a conta de produção do Cloud Identity ou do G Suite 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:

Abordagem de mapeamento do Azure Active Directory para domínios, usuários e grupos de DNS.

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 contas do Cloud Identity e do G Suite

Ao adicionar um domínio, como example.com, à sua conta do Cloud Identity ou do G Suite, você precisa confirmar que é o 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, poderão ocorrer conflitos se você tiver outra conta do Cloud Identity ou do G Suite que já usa esse subdomínio. Para evitar esses conflitos, use domínios separados para cada conta. Por exemplo, se você precisar de duas contas do Cloud Identity ou do G Suite, evite usar dois domínios em que 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 G Suite e o Google Cloud

Se você já usa o G Suite, alguns usuários na sua conta do G Suite podem ter recebido privilégios de superadministrador para realizar tarefas administrativas.

Os usuários com privilégios de superadministrador recebem implicitamente permissão para modificar a política do Cloud Identity and Access Management (Cloud 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 G Suite também permite que um usuário exclua a conta, a organização associada do Google Cloud e todos os recursos. Portanto, você precisa presumir que os superadministradores têm acesso total a todos os recursos de uma organização.

O fato de os superadministradores também serem administradores da organização poderá ser uma preocupação de segurança se os administradores atuais do G Suite forem diferentes dos usuários que serão responsáveis pelo gerenciamento da organização do Google Cloud. Nesse caso, opte por criar uma conta separada do Cloud Identity dedicada ao Google Cloud para limitar o acesso dos superadministradores do G Suite aos recursos do Google Cloud. A separação do G Suite e do Google Cloud pode ter várias consequências indesejadas.

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 permite isolar completamente sua implantação do Google Cloud e o G Suite. No entanto, a duplicação de usuários afeta negativamente 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. O domínio usado pelo Cloud Identity precisa ser diferente do domínio usado no G Suite e, portanto, não é adequado para o roteamento de e-mails.

  • Ao criar usuários separados na conta do Cloud Identity e restringir o acesso dos usuários da organização do Google Cloud à conta do Cloud Identity, você garante que sua implantação do Google Cloud e o G Suite estejam totalmente isolados. No entanto, a duplicação de usuários afeta negativamente 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. O domínio usado pelo Cloud Identity precisa ser diferente do domínio usado no G Suite e, portanto, não é adequado para o roteamento de e-mails.

  • Se você referenciar usuários da conta do G Suite na sua organização do Google Cloud, você minará o isolamento entre o G Suite e o Google Cloud:

    Referenciar usuários da conta do G Suite na sua organização do Google Cloud.

    Os superadministradores do G Suite podem usar a delegação em todo o domínio para representar qualquer usuário na mesma conta do G Suite. 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 G Suite e do Google Cloud para reduzir o número de superadministradores:

Proteger seu IdP externo ao usar o Logon único

O Cloud Identity e o G Suite permitem configurar o Logon único com seu IdP externo, como Active Directory, Azure Active Directory ou Okta, entre outros. Se o Logon único estiver ativado, o Cloud Identity e o G Suite 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 G Suite redireciona o usuário para o 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 G Suite verificar se o IdP toma a decisão de autenticação correta e declara 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 G Suite e todos os recursos que dependem dos usuários gerenciados pela conta estão em risco se alguma das seguintes opções estiver configurada de maneira insegura:

  • 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 aos quais você não concederia privilégios de superadministrador no Cloud Identity ou no G Suite.
  • Não use o Logon único se não tiver certeza sobre os controles de segurança em vigor para seu IdP externo.

Acesso seguro às suas zonas DNS

As contas do Cloud Identity e do G Suite são identificadas por um nome de domínio DNS principal. Ao criar uma nova conta do Cloud Identity ou do G Suite, você precisa verificar 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 G Suite depende de registros MX do DNS para o roteamento de 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 no Cloud Identity ou no G Suite.

  • Não conceda a nenhum usuário acesso administrativo ao servidor DNS ao qual você não concederia privilégios de superadministrador no Cloud Identity ou no G Suite.

  • 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-se em um novo domínio DNS que use servidores DNS separados ou um serviço DNS gerenciado.

Exportar registros de auditoria para o BigQuery

O Cloud Identity e o G Suite mantêm vários registros de auditoria para acompanhar as mudanças na configuração e outras atividades que podem ser relevantes para a segurança da sua conta do Cloud Identity ou do G Suite. 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 G Suite 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 do BigQuery Export requer uma licença do G Suite Enterprise. Depois que você configurar os registros de auditoria principais, eles serão exportados para todos os usuários, incluindo aqueles sem licença do G Suite. Alguns registros, como os registros de auditoria do Drive e do dispositivo móvel, são exportados para usuários que têm pelo menos uma licença do G Suite Business.

Se você usa o Cloud Identity Free para a maioria dos usuários, ainda é possível exportar para o BigQuery adicionando o G Suite Enterprise à sua conta do Cloud Identity e comprando licenças do G Suite 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 G Suite 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 G Suite cria um primeiro projeto.

Cada conta do Cloud Identity ou do G Suite pode ter apenas uma 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:

Conceda aos usuários de várias contas acesso a recursos.

A flexibilidade de referenciar usuários de diferentes contas do Cloud Identity ou do G Suite permite separar a forma como você trata as contas e as organizações. É possível separar a decisão de quantas contas do Cloud Identity ou do G Suite são necessárias para gerenciar os usuários 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

A hierarquia de recursos de uma organização permite reduzir o esforço de gerenciamento de políticas do Cloud IAM e políticas organizacionais aproveitando a herança. 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 pode assumir o controle de qualquer recurso dentro da organização e é livre para 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 sejam coproprietários de uma organização, pode ser difícil manter uma hierarquia de recursos consistente e garantir que as políticas do Cloud IAM e as políticas organizacionais 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 o trabalho de configuração repetitivo, 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, políticas do IAM, políticas organizacionais ou 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, o IAM e as políticas organizacionais de preparo 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.

Como mostra o diagrama a seguir, você usa sua conta de teste do Cloud Identity ou do G Suite como base para a organização de teste. Use a conta de teste (ou o IdP externo a que sua conta de teste está integrada) para criar usuários de teste dedicados e uma estrutura de grupo que espelhe os grupos usados na conta de produção do Cloud Identity ou do G Suite. É possível usar esses usuários e grupos de teste dedicados para testar as políticas do IAM sem afetar os usuários atuais.

Usar sua conta como base para o preparo.

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 seus ambientes de teste podem ser substancialmente mais fracos 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.

Manter ambientes de teste semelhantes aos 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 do IAM ou políticas organizacionais comuns 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 preparo 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 sua organização de preparo para fazer experiências. Seu ambiente de preparo precisa usar políticas de IAM e organização semelhantes à sua organização de produção. Portanto, é provável que o ambiente de preparo esteja sujeito às mesmas limitações do ambiente de produção. Ao mesmo tempo, flexibilizar as políticas para permitir as experiências prejudicarão a finalidade da organização de preparo.

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, conceda aos usuários atuais da sua conta principal do Cloud Identity ou do G Suite acesso à organização experimental.

Organização da experiência.

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 G Suite a que a organização está associada, bem como contas de serviço da mesma organização
  • Usuários de outras contas do Cloud Identity ou do G Suite
  • Contas de serviço de outras organizações
  • Contas de usuário pessoais, incluindo usuários e contas pessoais do gmail.com que 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 restrito ao domínio na definição de um conjunto de contas confiáveis do Cloud Identity ou do G Suite que serão usadas para permitir que os membros sejam adicionados à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 do Cloud Identity ou do G Suite distintas para separar ambientes de preparo, produção e experiência, use políticas de compartilhamento restritas ao domínio para aplicar a segregação, conforme definido na tabela a seguir:

Organização Conta do Cloud Identity ou do G Suite confiável
Preparo Preparo
Produção Produção
Experiência 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 de domínio principal da conta do Cloud Identity ou do G Suite associada.

Se houver um nome de domínio DNS canônico usado em toda a empresa, use esse domínio como o principal na sua conta de produção do Cloud Identity ou do G Suite. 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 do usuário e para 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 as 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 do Cloud IAM de faturamento para definir quais usuários ou grupos têm permissão para 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 certo de contas de faturamento depende exclusivamente dos seus 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