Escolha uma hierarquia de recursos para sua zona de destino do Google Cloud

Last reviewed 2023-08-31 UTC

Uma hierarquia de recursos ajuda a organizar seus recursos no Google Cloud. Este documento descreve como escolher a hierarquia de recursos como parte do design da zona de destino. Ele é destinado a administradores, arquitetos e profissionais técnicos de sistema em nuvem envolvidos em projetar a hierarquia de recursos. Este documento faz parte de uma série sobre zonas de destino. Ele inclui amostras de hierarquias que demonstram maneiras comuns de as empresas estruturarem recursos no Google Cloud.

Fatores de design para a hierarquia de recursos

Ao definir a hierarquia de recursos no Google Cloud, é preciso considerar como sua organização funciona atualmente e o estado final ideal da transformação da nuvem. A melhor maneira de gerenciar recursos é baseada na maneira pretendida da sua organização de trabalhar na nuvem. Cada organização é diferente, e não existe uma abordagem única e melhor para a hierarquia de recursos.

No entanto, recomendamos que você evite mapear a estrutura organizacional da organização para a hierarquia de recursos. Em vez disso, concentre-se nas necessidades e operações do seu negócio no Google Cloud.

Hierarquia de recursos do Google Cloud

A hierarquia de recursos no Google Cloud começa no nó raiz, chamado de organização. Recomendamos que as empresas tenham apenas um nó raiz, exceto em situações específicas. Você define níveis mais baixos na hierarquia usando pastas e projetos e criar pastas nas pastas para criar sua hierarquia. É possível criar os projetos que hospedam as cargas de trabalho em qualquer nível da hierarquia.

O diagrama a seguir mostra um nó raiz chamado Organization e as pastas nos níveis um, dois e três. Os projetos e subpastas são criados nas pastas do nível 2.

Exemplo de hierarquia com nó raiz, pastas e projetos.

Fatores da hierarquia de recursos

Ao decidir a hierarquia de recursos, considere os seguintes fatores:

  • Quem é responsável pelos recursos da nuvem? São seus departamentos, subsidiárias, equipes técnicas ou entidades legais?
  • Quais são suas necessidades de conformidade?
  • Você tem eventos futuros sobre a empresa, como fusões, aquisições e lançamentos?

Entender as interações de recursos em toda a hierarquia

As políticas da organização são herdadas pelos descendentes na hierarquia de recursos, mas podem ser substituídas pelas políticas definidas em um nível inferior. Para mais informações, consulte Noções básicas sobre a avaliação da hierarquia. As restrições de política da organização são usadas para definir diretrizes em toda a organização ou partes significativas dela e ainda permitir exceções.

As políticas de permissão, anteriormente conhecidas como políticas de IAM, são herdadas pelos descendentes e as permissões em níveis mais baixos são aditivas. No entanto, as políticas de permissão podem ser substituídas por políticas de negação, que permitem restringir permissões no nível do projeto, da pasta e da organização. As políticas de negação são aplicadas antes das políticas de permissão.

Você também precisa considerar o seguinte:

Pontos de decisão para o design da hierarquia de recursos

O fluxograma a seguir mostra o que você precisa considerar para escolher a melhor hierarquia de recursos para sua organização.

Decisões para hierarquias de recursos

O diagrama anterior descreve os seguintes pontos de decisão:

  1. Subsidiárias, grupos regionais ou unidades de negócios diferentes têm requisitos de política muito diferentes?
    1. Em caso afirmativo, siga o design com base na região ou nas subsidiárias.
    2. Em caso negativo, vá para o próximo ponto de decisão.

  2. Suas cargas de trabalho ou equipes de produtos exigem muita autonomia sobre as políticas? Por exemplo, você não tem uma equipe de segurança central que determina as políticas para todas as equipes de carga de trabalho ou produto.

    1. Se for o caso, consulte o design baseado no framework de responsabilidade.

    2. Caso contrário, consulte o design baseado no ambiente do aplicativo.

Seu caso de uso específico pode levar a outro projeto de hierarquia de recursos do que o gráfico de decisão sugere. A maioria das organizações escolhe uma abordagem híbrida e seleciona diferentes designs em diferentes níveis da hierarquia de recursos, começando com o design que mais afeta políticas e acesso.

Opção 1: hierarquia baseada em ambientes de aplicativos

Em muitas organizações, você define políticas e controles de acesso diferentes para diferentes ambientes de aplicativos, como desenvolvimento, produção e testes. Ter políticas separadas que sejam padronizadas em cada ambiente facilita o gerenciamento e a configuração. Por exemplo, você pode ter políticas de segurança mais rigorosas em ambientes de produção do que em ambientes de teste.

Use uma hierarquia baseada em ambientes de aplicativo se o seguinte for verdadeiro:

  • Você tem ambientes de aplicativos separados que têm requisitos de política e administração diferentes.
  • Você tem requisitos centralizados de segurança ou auditoria que uma equipe de segurança central precisa aplicar de maneira consistente em todas as cargas de trabalho e dados de produção.
  • É necessário ter diferentes papéis do Identity and Access Management (IAM) para acessar seus recursos do Google Cloud em diferentes ambientes.

Evite essa hierarquia se o seguinte for verdadeiro:

  • Você não executa vários ambientes de aplicativos.
  • Você não tem dependências de aplicativos e processos de negócios variados em vários ambientes.
  • Você tem grandes diferenças de política para diferentes regiões, equipes ou aplicativos.

O diagrama a seguir mostra uma hierarquia para o example.com, que é uma empresa de tecnologia financeira fictícia.

Diagrama da opção 1.

Conforme mostrado no diagrama anterior, o example.com tem três ambientes de aplicativo com diferentes políticas, controles de acesso, requisitos regulamentares e processos. Os ambientes são os seguintes:

  • Ambiente de desenvolvimento e controle de qualidade: gerenciado por desenvolvedores que são funcionários internos e consultores da empresa. Ele envia push de código continuamente e é responsável pelo controle de qualidade. Esse ambiente nunca está disponível para os consumidores da sua empresa. O ambiente tem requisitos de integração e autenticação menos rigorosos que o ambiente de produção, e os desenvolvedores recebem papéis aprovados com permissões adequadas. Os ambientes de desenvolvimento e controle de qualidade foram criados apenas para ofertas padrão de aplicativos em example.com.

  • Ambiente de teste: esse ambiente é usado para testes de regressão e aplicativo e é compatível com as ofertas entre empresas (B2B) de clientes example.com que usam APIs example.com. Para essa finalidade, o example.com cria dois tipos de projetos:

    • Projetos de teste interno para concluir a regressão, o desempenho e a configuração internos de ofertas B2B.
    • Projetos de UAT de clientes com suporte multilocatário para que os clientes B2B possam validar as configurações e se alinhar aos requisitos de example.com para experiência do usuário, branding, fluxos de trabalho, relatórios etc.

  • Ambiente de produção: esse ambiente hospeda todas as ofertas de produtos validadas, aceitas e lançadas. Esse ambiente está sujeito às regulamentações do Padrão de Segurança de Dados do Setor de Cartões de Pagamento (PCI DSS), usa módulos de segurança de hardware (HSMs, na sigla em inglês) e se integra a processadores terceirizados para itens como autenticação e liquidações de pagamento. As equipes de auditoria e conformidade são partes interessadas fundamentais desse ambiente. O acesso a esse ambiente é altamente controlado e limitado principalmente aos processos automatizados de implantação.

Para mais informações sobre como desenvolver uma hierarquia baseada em ambientes de aplicativos, consulte Estrutura organizacional no blueprint de fundação empresarial.

Opção 2: hierarquia baseada em regiões ou subsidiárias

Algumas organizações operam em várias regiões e têm subsidiárias que atuam em diferentes localidades ou são resultado de fusões e aquisições. Essas organizações exigem uma hierarquia de recursos que usa as opções de escalonabilidade e gerenciamento no Google Cloud e mantêm a independência para diferentes processos e políticas que existem entre as regiões ou subsidiárias. Essa hierarquia usa subsidiárias ou regiões como o nível mais alto da pasta na hierarquia de recursos. Os procedimentos de implantação normalmente são focados nas regiões.

Use essa hierarquia se o seguinte for verdadeiro:

  • Diferentes regiões ou subsidiárias operam de forma independente.
  • As regiões ou subsidiárias têm diferentes backbones operacionais, ofertas de plataformas digitais e processos.
  • Sua empresa tem diferentes padrões regulatórios e de conformidade para regiões ou subsidiárias.

O diagrama a seguir mostra um exemplo de hierarquia de uma organização global com duas subsidiárias e um grupo de controle com uma estrutura regionalizada.

Diagrama da opção 2.

O diagrama anterior tem a seguinte estrutura hierárquica:

  • As seguintes pastas estão no primeiro nível:
    • As pastas Subsidiary 1 e Subsidiary 2 representam as duas subsidiárias da empresa que têm diferentes permissões de acesso e políticas do restante da organização. Cada subsidiária usa o IAM para restringir o acesso aos projetos e recursos do Google Cloud.
    • A pasta Holding group representa os grupos com políticas comuns de alto nível entre regiões.
    • A pasta Bootstrap representa os recursos comuns necessários para implantar a infraestrutura do Google Cloud, conforme descrito no blueprint de fundação empresarial.
  • No segundo nível, na pasta Group Holding, há as seguintes pastas:
    • As pastas APAC, EMEA e Americas representam as várias regiões no grupo que têm diferentes governanças, permissões de acesso e políticas.
    • A pasta Shared infrastructure representa recursos usados globalmente em todas as regiões.
  • Em cada pasta, há vários projetos que contêm os recursos pelos quais essas subsidiárias ou regiões são responsáveis.

É possível adicionar mais pastas para separar entidades, departamentos e equipes legais na sua empresa.

Opção 3: hierarquia baseada em um framework de responsabilidade

Uma hierarquia baseada em um framework de responsabilidade funciona melhor quando seus produtos são executados de maneira independente ou as unidades organizacionais têm equipes claramente definidas que têm o ciclo de vida dos produtos. Nessas organizações, os proprietários de produtos são responsáveis por todo o ciclo de vida do produto, incluindo os processos, o suporte, as políticas e os direitos de acesso. Os produtos são independentes uns dos outros, as diretrizes e os controles para toda a organização são incomuns.

Use essa hierarquia quando o seguinte for verdadeiro:

  • Você administra uma organização que tem propriedade clara e responsabilidade de cada produto.
  • As cargas de trabalho são independentes e não compartilham muitas políticas comuns.
  • Seus processos e plataformas de desenvolvedores externas são oferecidas como ofertas de serviços ou produtos.

O diagrama a seguir mostra um exemplo de hierarquia para um provedor de plataforma de comércio eletrônico.

Diagrama da opção 3.

O diagrama anterior tem a seguinte estrutura hierárquica:

  • As seguintes pastas estão no primeiro nível:
    • As pastas chamadas Ecommerce Modules e Logistics and Warehousing Modules representam os módulos na plataforma da plataforma que exigem as mesmas permissões de acesso e políticas durante o ciclo de vida do produto.
    • A pasta Reconciliation and Billing representa as equipes de produtos responsáveis pelos módulos de ponta a ponta para componentes de negócios específicos na oferta da plataforma.
    • A pasta Bootstrap representa os recursos comuns necessários para implantar a infraestrutura do Google Cloud, conforme descrito no blueprint de fundação empresarial.
  • Em cada pasta, há vários projetos que contêm os módulos independentes pelos quais as diferentes equipes de produto são responsáveis.

Para mais informações, consulte Hierarquia de recursos do framework FAST Terraform do Fabric.

Práticas recomendadas para hierarquia de recursos

As seções a seguir descrevem as práticas recomendadas para projetar a hierarquia de recursos que recomendamos, independentemente da hierarquia de recursos escolhida.

Para mais práticas recomendadas sobre como configurar contas e organizações do Cloud Identity e do Google Workspace, consulte Práticas recomendadas para o planejamento de contas e organizações.

Usar um único nó da organização

Para evitar sobrecarga no gerenciamento, use um único nó da organização sempre que possível. No entanto, considere o uso de vários nós da organização para abordar os seguintes casos de uso:

  • Você quer testar grandes mudanças nos níveis do IAM ou na hierarquia de recursos.
  • Você quer fazer experimentos em um ambiente sandbox que não tenha as mesmas políticas da organização.
  • Sua organização inclui subempresas que provavelmente serão vendidas ou executadas como entidades completamente separadas no futuro.

Usar convenções de nomenclatura padronizadas

Use uma convenção de nomenclatura padronizada em toda a organização. O blueprint de bases de segurança tem uma convenção de nomenclatura de amostra que pode ser adaptada aos seus requisitos.

Mantenha recursos de inicialização independente e serviços comuns separados.

Mantenha pastas separadas para inicializar o ambiente do Google Cloud usando infraestrutura como código (IaC) e para serviços comuns compartilhados entre ambientes ou aplicativos. Coloque a pasta de inicialização abaixo do nó da organização na hierarquia de recursos.

Coloque as pastas dos serviços comuns em diferentes níveis da hierarquia, dependendo da estrutura escolhida.

Coloque a pasta de serviços comuns abaixo do nó da organização quando o seguinte for verdadeiro:

  • Sua hierarquia usa ambientes de aplicativos no nível mais alto e equipes ou aplicativos na segunda camada.
  • Você tem serviços compartilhados, como monitoramento, que são comuns entre ambientes.

Coloque a pasta de serviços comuns em um nível inferior, abaixo das pastas do aplicativo, quando as condições a seguir forem atendidas:

  • Você tem serviços compartilhados entre aplicativos e implanta uma instância separada para cada ambiente de implantação.

  • Os aplicativos compartilham microsserviços que exigem desenvolvimento e teste para cada ambiente de implantação.

O diagrama a seguir mostra um exemplo de hierarquia em que há uma pasta de infraestrutura compartilhada usada por todos os ambientes e as pastas de serviços compartilhados para cada ambiente de aplicativo em um nível inferior na hierarquia:

Exemplo de hierarquia com a pasta de infraestrutura compartilhada.

O diagrama anterior tem a seguinte estrutura hierárquica:

  • As pastas no primeiro nível são as seguintes:
    • As pastas Development environment e Production environment contêm os ambientes do aplicativo.
    • A pasta Shared infrastructure contém recursos comuns que são compartilhados entre ambientes, como o monitoramento.
    • A pasta Bootstrap contém os recursos comuns necessários para implantar a infraestrutura do Google Cloud, conforme descrito no blueprint de fundação empresarial.
  • No segundo nível, há as seguintes pastas:
    • Uma pasta em cada ambiente para cada aplicativo (App 1 e App 2) que contém os recursos desses aplicativos.
    • Uma pasta Shared para os dois ambientes de aplicativos que contém serviços compartilhados entre os aplicativos, mas são independentes para cada ambiente. Por exemplo, é possível ter um projeto de secrets no nível da pasta para aplicar diferentes políticas de permissão aos secrets de produção e de não produção.
  • Em cada pasta do aplicativo, há vários projetos que contêm os módulos independentes que fazem parte de cada aplicativo.

A seguir