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

Last reviewed 2024-06-26 UTC

Este documento apresenta práticas recomendadas para decidir quantas contas do Cloud ID ou do Google Workspace organizações e contas de faturação precisa de usar. Google Cloud O documento fornece orientações sobre a identificação de um design que satisfaça os seus requisitos de segurança e organizacionais.

No Google Cloud, a gestão de identidade e de acesso baseia-se em dois pilares:

  • As contas do Cloud ID e do Google Workspace são contentores para utilizadores e grupos. Por conseguinte, estas contas são fundamentais para autenticar os seus utilizadores empresariais e gerir o acesso aos seus recursosGoogle Cloud . Uma conta do Cloud Identity ou do Google Workspace indica um diretório de utilizadores e não uma conta de utilizador individual. As contas de utilizador individuais são denominadas utilizadores ou contas de utilizador.

  • As organizações são contentores para projetos e recursos no Google Cloud. As organizações permitem que os recursos sejam estruturados hierarquicamente e são fundamentais para gerir os recursos de forma centralizada e eficiente.

Este documento destina-se principalmente a clientes que estão a configurar ambientes empresariais.

Contas do Cloud ID e do Google Workspace

O Google Workspace é um conjunto integrado de apps de colaboração e produtividade nativas da nuvem. Inclui ferramentas que lhe permitem gerir utilizadores, grupos e autenticação.

O Cloud Identity oferece um subconjunto das funcionalidades do Google Workspace. Tal como o Google Workspace, o Cloud ID permite-lhe gerir utilizadores, grupos e autenticação, mas não inclui todas as funcionalidades de colaboração e produtividade do Google Workspace.

O Cloud ID e o Google Workspace partilham uma plataforma técnica comum e usam o mesmo conjunto de APIs e ferramentas administrativas. Os produtos partilham o conceito de uma conta como um contentor para utilizadores e grupos. Este contentor é identificado por um nome de domínio, como example.com. Para a gestão de utilizadores, grupos e autenticação, os dois produtos podem ser considerados equivalentes.

Combine o Cloud ID e o Google Workspace numa única conta

Uma vez que o Cloud Identity e o Google Workspace partilham uma plataforma comum, pode combinar o acesso aos produtos numa única conta.

Se já administra uma conta do Google Workspace e quer permitir que mais utilizadores usem o serviço Google Cloud, pode não querer atribuir a todos os utilizadores uma licença do Google Workspace. Neste caso, adicione o Cloud ID Free à sua conta existente. Em seguida, pode integrar mais utilizadores sem custos adicionais e decidir que utilizadores devem ter acesso ao Google Workspace atribuindo-lhes uma licença do Google Workspace.

Da mesma forma, se já administrar uma conta do Cloud ID Free ou Premium, pode querer conceder a determinados utilizadores o direito de usar o Google Workspace. Em vez de criar contas do Google Workspace separadas para esses utilizadores, pode adicionar o Google Workspace a uma conta do Cloud Identity existente. Depois de atribuir a licença do Google Workspace aos utilizadores selecionados, estes podem usar as apps de produtividade e colaboração.

Use o menor número possível de contas, mas o número necessário

Para permitir que os seus utilizadores colaborem através do Google Workspace e minimizar a sobrecarga administrativa, é melhor gerir todos os utilizadores através de uma única conta do Cloud ID ou do Google Workspace e fornecer uma única conta de utilizador a cada indivíduo. Esta abordagem ajuda a garantir que as definições, como as políticas de palavras-passe, o início de sessão único e a validação em dois passos, são aplicadas de forma consistente a todos os utilizadores.

Apesar destas vantagens de usar uma única conta do Cloud ID ou do Google Workspace, pode obter flexibilidade e autonomia administrativa usando várias contas. Quando decidir quantas contas do Cloud ID ou do Google Workspace usar, considere todos os requisitos que sugerem a utilização de várias contas. Em seguida, use o menor número de contas do Cloud ID ou do Google Workspace que satisfaça os seus requisitos.

Use contas separadas para teste e produção

Para a maioria das definições que pode configurar no Cloud ID e no Google Workspace, pode escolher o âmbito em que cada definição deve ser aplicada. Por exemplo, pode especificar a localização geográfica dos seus dados por utilizador, por grupo ou por unidade organizacional. Quando planeia aplicar uma nova configuração, pode escolher inicialmente um âmbito pequeno (por exemplo, por utilizador) e verificar se a configuração cumpre as suas expetativas. Depois de validar a configuração, pode aplicar a mesma definição a um conjunto maior de grupos ou unidades organizacionais.

Ao contrário da maioria das definições, a integração de uma conta do Cloud ID ou do Google Workspace com um fornecedor de identidade (IdP) externo tem um impacto global:

  • Ativar o início de sessão único é uma definição global que se aplica a todos os utilizadores, exceto aos superadministradores.
  • Consoante o seu IdP externo, a configuração do aprovisionamento de utilizadores também pode ter um impacto global. Uma configuração incorreta acidental no IdP externo pode levar à modificação, suspensão ou até eliminação inadvertida de utilizadores.

Para mitigar estes riscos, tenha contas de teste e produção separadas do Cloud Identity ou do Google Workspace:

  • Use a conta de teste para validar quaisquer alterações de configuração arriscadas antes de aplicar a mesma alteração à sua conta de produção.
  • Crie alguns utilizadores de teste nas contas de preparação que você e outros administradores podem usar para validar as alterações de configuração. No entanto, não conceda aos seus utilizadores acesso à conta de teste.

Se tiver instâncias de preparação e produção separadas do seu IdP externo, siga estes passos:

  • Integre a sua conta de teste do Cloud ID ou Google Workspace com a sua instância de teste do IdP.
  • Integre a sua conta de produção do Cloud ID ou do Google Workspace com a sua instância de IdP de produção.

Por exemplo, suponhamos que planeia configurar a federação com o Active Directory e ter uma floresta do Active Directory separada para fins de teste. Neste caso, integra a sua conta de teste do Cloud ID ou Google Workspace com a floresta de teste e a conta de produção do Cloud ID ou Google Workspace com a sua floresta principal. Aplique a mesma abordagem de mapeamento para domínios DNS, utilizadores, e grupos a ambos os pares de florestas/contas, conforme mostrado no diagrama seguinte:

Abordagem de mapeamento do Active Directory para domínios DNS, utilizadores e grupos.

Os seus domínios e florestas do Active Directory de produção e teste podem usar domínios DNS que não lhe permitem aplicar a mesma abordagem de mapeamento de domínios para teste e produção. Neste caso, pondere registar mais domínios de sufixos de nomes principais de utilizadores (UPN) na sua floresta de preparação.

Da mesma forma, se planear configurar a federação com o Microsoft Entra ID, é melhor adotar a seguinte abordagem:

  • Integre a conta de teste do Cloud ID ou do Google Workspace com um inquilino de teste do Entra ID.
  • Integre a conta de produção do Cloud ID ou do Google Workspace com o seu inquilino principal do Entra ID.

Aplique a mesma abordagem de mapeamento para domínios DNS, utilizadores, e grupos a ambos os pares de inquilinos/contas:

Abordagem de mapeamento do Entra ID para domínios DNS, utilizadores e grupos.

Os seus inquilinos do Entra ID de produção e preparação podem usar domínios DNS que não lhe permitem aplicar a mesma abordagem de mapeamento de domínios para preparação e produção. Neste caso, considere adicionar um domínio adicional ao seu inquilino de preparação.

Use domínios DNS disjuntos entre contas do Cloud ID e do Google Workspace

Quando adiciona um domínio, como example.com, à sua conta do Cloud Identity ou do Google Workspace pela primeira vez, tem de validar a propriedade do domínio. Depois de adicionar e validar um domínio, pode adicionar subdomínios, como marketing.example.com e finance.example.com, sem ter de validar cada subdomínio individualmente.

No entanto, se adicionar subdomínios sem validar cada um, podem ocorrer conflitos se tiver outra conta do Cloud ID ou do Google Workspace que já use este subdomínio. Para evitar estes conflitos, é preferível usar domínios disjuntos para cada conta. Por exemplo, se precisar de duas contas do Cloud ID ou do Google Workspace, tente evitar usar dois domínios em que um domínio seja um subdomínio do outro. Em alternativa, use dois domínios que não sejam subdomínios de outro. Esta prática aplica-se ao domínio principal e aos domínios secundários.

Não separe o Google Workspace e o Google Cloud

Se já usa o Google Workspace, alguns utilizadores na sua conta do Google Workspace podem ter-lhes sido concedidos privilégios de superadministrador para que possam realizar tarefas administrativas.

Os utilizadores com privilégios de superadministrador têm implicitamente autorização para modificar a política de gestão de identidade e de acesso (IAM) do nó da organização. Esta autorização permite que os superadministradores atribuam a si próprios a função de administradores organizacionais ou qualquer outra função na Google Cloud organização. Ter acesso de superadministrador a uma conta do Cloud Identity ou do Google Workspace também permite que um utilizador elimine a conta, a respetiva organização Google Cloud associada e todos os respetivos recursos. Por conseguinte, tem de assumir que os superadministradores têm acesso total a todos os recursos numa organização.

O facto de os superadministradores também serem administradores da organização pode ser um problema de segurança se os seus administradores do Google Workspace existentes forem um conjunto de utilizadores diferente dos utilizadores que vão ser responsáveis pela gestão da suaGoogle Cloud organização. Neste caso, pode optar por criar uma conta do Cloud Identity separada dedicada a Google Cloud para limitar o acesso dos superadministradores do Google Workspace aos Google Cloud recursos. A separação do Google Workspace e do Google Cloud pode ter várias consequências não intencionais.

Por exemplo, pode tentar criar utilizadores separados na conta do Cloud Identity e, em seguida, restringir o acesso dos utilizadores da Google Cloud organização à conta do Cloud Identity. Isto garante que a sua Google Cloud implementação e o Google Workspace estão totalmente isolados. No entanto, a duplicação de utilizadores afeta negativamente a experiência do utilizador e os custos administrativos. Além disso, não pode receber emails de notificação enviados por Google Cloud, uma vez que o domínio usado pelo Cloud ID tem de ser diferente do domínio usado para o Google Workspace e, por isso, não é adequado para encaminhar emails.

Se, em vez disso, fizer referência a utilizadores da conta do Google Workspace na sua organização, compromete o isolamento entre o Google Workspace e o Google Cloud Platform:Google Cloud Google Cloud

Fazer referência a utilizadores da conta do Google Workspace na sua organização Google Cloud .

Os superadministradores do Google Workspace têm a capacidade de usar a delegação ao nível do domínio para se fazerem passar por qualquer utilizador na mesma conta do Google Workspace. Um superadministrador malicioso pode usar os respetivos privilégios elevados para recuperar o acesso a Google Cloud.

Uma abordagem mais eficaz do que usar contas separadas é segregar as responsabilidades entre o Google Workspace e os administradores para reduzir o número de superadministradores: Google Cloud

Proteja o seu IdP externo quando usar o início de sessão único

O Cloud ID e o Google Workspace permitem-lhe configurar o Início de sessão único com o seu IdP externo, como o Active Directory, o Entra ID ou o Okta (para mencionar alguns). Se o Início de sessão único estiver ativado, o Cloud Identity e o Google Workspace confiam no IdP externo para autenticar os utilizadores em nome da Google.

A ativação do início de sessão único oferece várias vantagens:

  • Os utilizadores podem usar as respetivas credenciais existentes para iniciar sessão nos serviços Google.
  • Os utilizadores não têm de introduzir novamente as respetivas palavras-passe se já tiverem uma sessão de início de sessão existente.
  • Pode aplicar políticas de autenticação multifator consistentes nas suas aplicações e em todos os serviços Google.

No entanto, a ativação do início de sessão único também o expõe a riscos. Quando o início de sessão único está ativado e um utilizador tem de ser autenticado, o Cloud ID ou o Google Workspace redireciona o utilizador para o seu IdP externo. Após a autenticação do utilizador, o IdP devolve à Google uma declaração SAML que indica a identidade do utilizador. A declaração SAML está assinada. Por conseguinte, a Google pode validar a autenticidade da declaração SAML e verificar se foi usado o fornecedor de identidade correto. No entanto, não existe forma de o Cloud ID ou o Google Workspace validarem se o IdP tomou a decisão de autenticação correta e indicou corretamente a identidade do utilizador.

Se o início de sessão único estiver ativado, a segurança e a integridade gerais da sua implementação do Google dependem da segurança e da integridade do seu IdP. A sua conta do Cloud Identity ou do Google Workspace e todos os recursos que dependem dos utilizadores geridos pela conta estão em risco se qualquer um dos seguintes elementos estiver configurado de forma não segura:

  • O próprio IdP
  • As máquinas nas quais o fornecedor está a ser executado
  • A base de dados de utilizadores a partir da qual o fornecedor está a obter informações dos utilizadores
  • Qualquer outro sistema do qual o fornecedor dependa

Para evitar que o início de sessão único se torne um elo fraco na sua postura de segurança, certifique-se de que o IdP e todos os sistemas dos quais depende estão configurados de forma segura:

  • Limite o número de utilizadores com acesso administrativo ao seu IdP ou a qualquer um dos sistemas nos quais o fornecedor se baseia.
  • Não conceda acesso administrativo a estes sistemas a nenhum utilizador ao qual não concederia também privilégios de superadministrador no Cloud ID ou no Google Workspace.
  • Não use o início de sessão único se não tiver a certeza dos controlos de segurança em vigor para o seu IdP externo.

Acesso seguro às suas zonas de DNS

As contas do Cloud ID e do Google Workspace são identificadas por um nome de domínio DNS principal. Quando cria uma nova conta do Cloud ID ou do Google Workspace, tem de validar a propriedade do domínio DNS criando um registo DNS especial na zona DNS correspondente.

A importância do DNS e o impacto na segurança geral da sua implementação do Google vão além do processo de inscrição:

  • O Google Workspace baseia-se nos registos MX de DNS para encaminhar emails. Ao modificar estes registos MX, um atacante pode conseguir encaminhar emails para um servidor diferente e obter acesso a informações confidenciais.

  • Se um atacante conseguir adicionar registos à zona de DNS, pode conseguir repor a palavra-passe de um utilizador superadministrador e obter acesso à conta.

Para evitar que o DNS se torne um elo fraco na sua postura de segurança, certifique-se de que o servidor DNS está configurado de forma segura:

  • Limite o número de utilizadores com acesso administrativo ao servidor DNS que gere o domínio principal usado para o Cloud Identity ou o Google Workspace.

  • Não conceda a nenhum utilizador acesso administrativo ao seu servidor DNS ao qual também não concederia privilégios de superadministrador no Cloud ID ou Google Workspace.

  • Se planeia implementar uma carga de trabalho que tenha requisitos de segurança que não são cumpridos pela sua infraestrutura DNS existente, considere registar um novo domínio DNS para essa carga de trabalho que use servidores DNS separados ou um serviço DNS gerido. Google Cloud

Exporte registos de auditoria para o BigQuery

O Cloud ID e o Google Workspace mantêm vários registos de auditoria para monitorizar as alterações de configuração e outras atividades que possam ser relevantes para a segurança da sua conta do Cloud ID ou do Google Workspace. A tabela seguinte resume estes registos de auditoria.

Registo Atividades capturadas
Administrador Ações realizadas na consola do administrador Google
Iniciar sessão Tentativas de início de sessão bem-sucedidas, sem êxito e suspeitas no seu domínio
Token Instâncias de autorização ou revogação do acesso a aplicações Web ou para dispositivos móveis de terceiros
Grupos Alterações a grupos e subscrições de grupos

Pode aceder a estes registos de auditoria através da consola do administrador ou através da API Reports. Para a maioria dos registos de auditoria, os dados são retidos durante 6 meses.

Se estiver a operar num setor regulamentado, a retenção de dados de auditoria durante 6 meses pode não ser suficiente. Para reter dados durante um período mais longo, configure os registos de auditoria para serem exportados para o BigQuery.

Para limitar o risco de acesso não autorizado aos registos de auditoria exportados, use um projeto Google Cloud dedicado para o conjunto de dados do BigQuery. Para manter os dados de auditoria protegidos contra adulteração ou eliminação, conceda acesso ao projeto e ao conjunto de dados com base no menor privilégio.

Os registos de auditoria do Cloud ID e do Google Workspace são complementares aos registos de registos de auditoria na nuvem. Se também usar o BigQuery para recolher registos de auditoria na nuvem e outros registos de auditoria específicos da aplicação, pode correlacionar eventos de início de sessão com atividades que um utilizador realizou no Google Cloud ou nas suas aplicações. A capacidade de correlacionar dados de auditoria em várias origens pode ajudar a detetar e analisar atividade suspeita.

A configuração da exportação para o BigQuery requer uma licença do Google Workspace Enterprise. Depois de configurar os registos de auditoria principais, estes são exportados para todos os utilizadores, incluindo os utilizadores sem uma licença do Google Workspace. Determinados registos, como os registos de auditoria do Drive e para dispositivos móveis, são exportados para utilizadores que tenham, pelo menos, uma licença do Google Workspace Business.

Se usar o Cloud Identity Free para a maioria dos seus utilizadores, pode continuar a exportar para o BigQuery adicionando o Google Workspace Enterprise à sua conta do Cloud Identity existente e comprando licenças do Google Workspace para um conjunto selecionado de administradores.

Organizações

As organizações permitem-lhe organizar recursos numa hierarquia de projetos e pastas, com o nó da organização a ser a raiz. As organizações estão associadas a uma conta do Cloud Identity ou do Google Workspace e derivam o respetivo nome do nome do domínio principal da conta associada. Uma organização é criada automaticamente quando um utilizador da conta do Cloud Identity ou do Google Workspace cria um primeiro projeto.

Cada conta do Cloud ID ou do Google Workspace só pode ter uma organização. Na verdade, não é possível criar uma organização sem uma conta correspondente. Apesar desta dependência, pode conceder aos utilizadores de várias contas diferentes acesso a recursos numa única organização:

Conceder aos utilizadores de várias contas acesso a recursos.

A flexibilidade para referenciar utilizadores de diferentes contas do Cloud ID ou do Google Workspace permite-lhe separar a forma como trata as contas e as organizações. Pode separar a decisão de quantas contas do Cloud ID ou do Google Workspace precisa para gerir os seus utilizadores da decisão de quantas organizações precisa para gerir os seus recursos.

O número de organizações que cria e os respetivos objetivos podem ter um impacto profundo na sua postura de segurança, na autonomia das suas equipas e departamentos, bem como na consistência e eficiência da sua administração.

As secções seguintes descrevem as práticas recomendadas para decidir quantas organizações usar.

Use o menor número possível de organizações, mas o número necessário

A hierarquia de recursos de uma organização permite-lhe reduzir o esforço de gestão das políticas IAM e das políticas organizacionais tirando partido da herança. Ao configurar políticas ao nível da pasta ou da organização, garante que as políticas são aplicadas de forma consistente numa subhierarquia de recursos e evita o trabalho de configuração repetitivo. Para minimizar os custos administrativos, é melhor usar o menor número possível de organizações.

Por outro lado, pode obter flexibilidade e autonomia administrativa adicionais usando várias organizações. As secções seguintes descrevem quando pode precisar desta flexibilidade ou autonomia adicional.

Em qualquer caso, quando estiver a decidir quantas organizações usar, considere todos os requisitos que sugerem a utilização de várias organizações. Em seguida, use o menor número de organizações que satisfaça os seus requisitos.

Use organizações para delimitar a autoridade administrativa

Numa hierarquia de recursos, pode conceder autorizações ao nível do recurso, do projeto ou da pasta. O nível máximo no qual pode conceder permissões a um utilizador é a organização.

Um utilizador ao qual foi atribuída a função de administrador da organização ao nível da organização tem controlo total sobre a organização, os respetivos recursos e as respetivas políticas de IAM. Um administrador da organização pode assumir o controlo de qualquer recurso na organização e tem liberdade para delegar o acesso administrativo a qualquer outro utilizador.

No entanto, as capacidades de um administrador da organização estão confinadas à organização, o que faz com que a organização seja o âmbito máximo da autoridade administrativa:

  • Um administrador da organização não pode aceder a recursos noutras organizações, a menos que lhe seja concedida autorização explícita.
  • Nenhum utilizador fora da organização pode retirar o controlo a um administrador da organização dessa organização.

O número certo de organizações a usar depende do número de grupos independentes de utilizadores administrativos na sua empresa:

  • Se a sua empresa estiver organizada por função, pode ter um único departamento responsável por supervisionar todas as implementações. Google Cloud
  • Se a sua empresa estiver organizada por divisões ou for proprietária de várias subsidiárias geridas de forma autónoma, pode não existir um único departamento responsável.

Se um único departamento for responsável pela supervisão das implementações, é melhor usar um único nó da organização. Google CloudGoogle Cloud Na organização, use pastas para estruturar recursos e conceder diferentes níveis de acesso a outras equipas e departamentos.

Se estiver a lidar com vários departamentos independentes, tentar centralizar a administração através de uma única organização pode causar problemas:

  • Se designar um único departamento para gerir a organização, pode encontrar resistência por parte de outros departamentos.
  • Se permitir que várias equipas ou departamentos sejam coproprietários de uma única organização, pode ser difícil manter uma hierarquia de recursos consistente e garantir que as políticas de IAM e as políticas organizacionais são usadas de forma consistente nos seus recursos.

Para evitar este tipo de atrito, use várias organizações e crie estruturas de pastas separadas em cada organização. Ao usar organizações separadas, estabelece limites entre diferentes grupos de utilizadores administrativos, delineando assim a respetiva autoridade administrativa.

Use uma organização de preparação separada

Para ajudar a garantir a consistência e evitar o trabalho de configuração repetitivo, organize os seus projetos numa hierarquia de pastas e aplique políticas IAM e políticas organizacionais ao nível da pasta ou da organização.

Existe uma desvantagem em ter políticas que se aplicam a muitos projetos e recursos. Qualquer alteração à própria política ou à hierarquia de recursos à qual a política se aplica pode ter consequências de grande alcance e não intencionais. Para mitigar este risco, é melhor testar as alterações às políticas antes de as aplicar na sua organização principal.

Recomendamos que crie uma organização de teste separada. Esta organização ajuda a testar alterações à hierarquia de recursos, políticas de IAM, políticas organizacionais ou outra configuração que tenha um potencial impacto ao nível da organização, como níveis de acesso e políticas.

Para garantir que os resultados dos testes ou das experiências realizados na organização de preparação também se aplicam à organização de produção, configure a organização de preparação para usar a mesma estrutura de pastas que a sua organização principal, mas com apenas um pequeno número de projetos. Em qualquer altura, as políticas organizacionais e de IAM na organização de preparação devem corresponder às políticas da sua organização de produção ou refletir a versão seguinte das políticas que pretende aplicar à sua organização de produção.

Conforme mostra o diagrama seguinte, usa a sua conta de teste do Cloud ID ou do Google Workspace como base para a organização de teste. Usa a conta de preparação (ou o IdP externo com o qual a conta de preparação está integrada) para criar utilizadores de teste dedicados e uma estrutura de grupo que reflita os grupos que usa na sua conta de produção do Cloud ID ou Google Workspace. Em seguida, pode usar estes utilizadores e grupos de teste dedicados para testar as políticas de IAM sem afetar os utilizadores existentes.

Usar a sua conta como base para a preparação.

Evite usar uma organização de testes separada

Para cada carga de trabalho de produção que planeia implementar no Google Cloud, provavelmente, precisa de um ou mais ambientes de teste, que as suas equipas de desenvolvimento e DevOps podem usar para validar novos lançamentos.

Do ponto de vista da segurança, para evitar que as versões não testadas afetem acidentalmente as cargas de trabalho de produção, é recomendável separar claramente os ambientes de teste dos ambientes de produção. Da mesma forma, os dois tipos de ambientes têm requisitos diferentes para as políticas de IAM. Por exemplo, para conceder aos programadores e testadores a flexibilidade de que precisam, os requisitos de segurança dos seus ambientes de teste podem ser substancialmente mais flexíveis do que os dos seus ambientes de produção.

Conforme mostra o diagrama seguinte, do ponto de vista da configuração, é recomendável manter os ambientes de teste o mais semelhantes possível aos ambientes de produção. Qualquer divergência aumenta o risco de uma implementação que funcionou corretamente num ambiente de teste falhar quando implementada num ambiente de produção.

Manter os ambientes de teste semelhantes aos ambientes de produção.

Para encontrar um equilíbrio entre manter os ambientes isolados e consistentes, use pastas na mesma organização para gerir os ambientes de teste e de produção:

  • Aplique políticas IAM ou políticas organizacionais que sejam comuns em todos os ambientes ao nível organizacional (ou usando uma pasta principal comum).
  • Use as pastas individuais para gerir as políticas de IAM e as políticas da organização que diferem entre diferentes tipos de ambientes.

Não use a sua organização de preparação para gerir ambientes de teste. Os ambientes de teste são essenciais para a produtividade das equipas de desenvolvimento e DevOps. A gestão destes ambientes no seu ambiente de preparação restringe a sua capacidade de usar a organização de preparação para experimentar e testar alterações às políticas. Qualquer alteração deste tipo pode interromper o trabalho destas equipas. Em resumo, se usar uma organização de preparação para gerir ambientes de teste, compromete o objetivo da sua organização de preparação.

Use uma organização separada para fazer experiências

Para tirar o máximo partido do Google Cloud, permita que as suas equipas de desenvolvimento, DevOps e operações se familiarizem com a plataforma e expandam a respetiva experiência executando tutoriais. Incentive-os a experimentar novas funcionalidades e serviços.

Use uma organização separada como ambiente de teste restrito para suportar estes tipos de atividades experimentais. Ao usar uma organização separada, pode manter as experiências sem restrições de políticas, configuração ou automatização que usa na sua organização de produção.

Evite usar a sua organização de preparação para experiências. O ambiente de testes deve usar políticas de IAM e da organização semelhantes às da sua organização de produção. Por conseguinte, é provável que o ambiente de teste esteja sujeito às mesmas limitações que o ambiente de produção. Ao mesmo tempo, a flexibilização das políticas para permitir experiências comprometeria o objetivo da sua organização de preparação.

Para evitar que a sua organização experimental fique desorganizada, gere custos excessivos ou se torne um risco de segurança, emita diretrizes que definam como as equipas podem usar a organização e quem é responsável pela respetiva manutenção. Além disso, considere configurar a automatização para eliminar automaticamente recursos ou até projetos inteiros após um determinado número de dias.

Conforme mostra o diagrama seguinte, quando cria uma organização para fazer experiências, cria primeiro uma conta do Cloud ID dedicada. Em seguida, use os utilizadores existentes da sua conta principal do Cloud Identity ou do Google Workspace para conceder aos utilizadores acesso à organização experimental.

Organização da experiência.

Para gerir a conta do Cloud ID adicional, precisa de, pelo menos, uma conta de utilizador de superadministrador na conta do Cloud ID. Para informações sobre como proteger estas contas de utilizador de superadministrador, consulte as práticas recomendadas para contas de superadministrador.

Use a partilha restrita ao domínio para aplicar relações de fidedignidade

As políticas de IAM permitem-lhe adicionar qualquer identidade Google válida como membro. Isto significa que, quando edita a política IAM de um recurso, um projeto, uma pasta ou uma organização, pode adicionar membros de diferentes origens, incluindo o seguinte:

  • Utilizadores da conta do Cloud ID ou do Google Workspace à qual a organização está associada, bem como contas de serviço da mesma organização
  • Utilizadores de outras contas do Cloud ID ou do Google Workspace
  • Contas de serviço de outras organizações
  • Contas de utilizador consumidor, incluindo utilizadores do gmail.com e contas de consumidor que usam um endereço de email empresarial

A capacidade de referenciar utilizadores de diferentes origens é útil para cenários e projetos em que precisa de colaborar com afiliados ou outras empresas. Na maioria dos outros casos, é melhor restringir as políticas de IAM para apenas permitir membros de origens fidedignas.

Use a partilha restrita ao domínio para definir um conjunto de contas fidedignas do Cloud ID ou Google Workspace a partir das quais quer permitir que os membros sejam adicionados às políticas do IAM. Defina esta política organizacional ao nível da organização (para que se aplique a todos os projetos) ou numa pasta perto da parte superior da hierarquia de recursos (para permitir a isenção de determinados projetos).

Se usar contas e organizações separadas do Cloud ID ou do Google Workspace para segregar ambientes de preparação, produção e experimentação, use políticas de partilha restritas por domínio para aplicar a segregação, conforme indicado na tabela seguinte:

Organização Conta do Cloud ID ou Google Workspace fidedigna
A testar A testar
Produção Produção
Experiências Produção

Use 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 do domínio é derivado do nome do domínio principal da conta do Cloud ID ou do Google Workspace associada.

Se existir um nome de domínio DNS canónico usado em toda a sua empresa, use esse domínio como domínio principal na sua conta de produção do Cloud ID ou do Google Workspace. Ao usar o nome DNS canónico, garante que os funcionários podem reconhecer facilmente o nome do nó da organização.

Se a sua empresa tiver várias subsidiárias ou for proprietária de várias marcas diferentes, pode não existir um nome de domínio canónico. Em vez de escolher arbitrariamente um dos domínios existentes, considere registar um novo domínio DNS neutro e dedicado para utilização por parte do Google Cloud. Ao usar um nome DNS neutro, 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 os seus outros domínios específicos da marca como domínios secundários para que possam ser usados em IDs de utilizadores e para início de sessão único.

Use contas de faturação em várias Google Cloud organizações

As contas de faturação definem quem paga por um determinado conjunto de Google Cloud recursos. Embora as contas de faturação possam existir fora de uma Google Cloud organização, são mais frequentemente associadas a uma organização.

Quando as contas de faturação estão associadas a uma organização, são consideradas um sub-recurso da organização e estão sujeitas às políticas do IAM definidas na organização. Mais importante ainda, isto significa que pode usar as funções de IAM de faturação para definir que utilizadores ou grupos têm autorização para administrar ou usar uma conta.

Um utilizador ao qual foi concedida a função Billing Account User pode associar um projeto a uma conta de faturação, o que faz com que os recursos sejam faturados a esta conta. A associação de um projeto a uma conta de faturação funciona na mesma organização, mas também entre organizações.

Se usar várias organizações, pode tirar partido do facto de as contas de faturação poderem ser usadas em várias organizações. Isto permite-lhe decidir de quantas contas de faturação precisa, independentemente do número de organizações de que necessita.

O número correto de contas de faturação depende exclusivamente dos seus requisitos comerciais ou contratuais, como a moeda, o perfil de pagamentos e o número de faturas separadas de que precisa. Tal como fez com as contas e as organizações, para minimizar a complexidade, deve usar o menor número de contas de faturação que satisfaça os seus requisitos.

Para discriminar os custos acumulados em várias organizações, configure a sua conta de faturação para exportar dados de faturação para o BigQuery. Cada registo exportado para o BigQuery não só contém o nome e o ID do projeto, como também o ID da organização à qual o projeto está associado (no campo project.ancestry_numbers).

O que se segue?