Decida uma hierarquia de recursos para a sua zona de destino do Google Cloud

Last reviewed 2024-10-31 UTC

Uma hierarquia de recursos ajuda a organizar os seus recursos no Google Cloud. Este documento descreve como escolher a hierarquia de recursos como parte da conceção da zona de destino. Destina-se a administradores de sistemas na nuvem, arquitetos e profissionais técnicos envolvidos na criação da hierarquia de recursos. Este documento faz parte de uma série sobre zonas de destino. Inclui hierarquias de exemplo que demonstram formas comuns de as empresas estruturarem recursos no Google Cloud.

Fatores de design para a hierarquia de recursos

Quando define a hierarquia de recursos no Google Cloud, tem de considerar como a sua organização funciona atualmente e o estado final ideal da sua transformação na nuvem. A melhor forma de gerir recursos baseia-se na forma de trabalhar pretendida da sua organização na nuvem. Como cada organização é diferente, não existe uma única abordagem ideal para a hierarquia de recursos.

No entanto, recomendamos que evite mapear a estrutura da sua organização empresarial para a hierarquia de recursos. Em alternativa, concentre-se nas necessidades e nas operações da sua empresa em Google Cloud.

Google Cloud hierarquia de recursos

A hierarquia de recursos começa no nó raiz, que se denomina organização. Google Cloud Recomendamos que as empresas tenham apenas um nó raiz, exceto em situações específicas. Define níveis inferiores da hierarquia através de pastas e projetos, e cria pastas dentro de pastas para criar a hierarquia. Pode criar os projetos que alojam as suas cargas de trabalho em qualquer nível da hierarquia.

O diagrama seguinte mostra um nó raiz denominado Organização e pastas nos níveis um, dois e três. Os projetos e as subpastas são criados nas pastas no nível dois.

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

Fatores da hierarquia de recursos

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

  • Quem é responsável pelos recursos na nuvem? São os seus departamentos, subsidiárias, equipas técnicas ou entidades legais?
  • Quais são as suas necessidades de conformidade?
  • Tem eventos empresariais futuros, como fusões, aquisições e cisões?

Compreenda 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 por políticas definidas a um nível inferior. Para mais informações, consulte o artigo Compreender a avaliação da hierarquia. Use restrições de políticas de organização para definir diretrizes em torno de toda a organização ou de partes significativas da mesma e, ainda assim, permitir exceções.

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

Também tem de considerar o seguinte:

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

O fluxograma seguinte mostra os aspetos que tem de considerar para escolher a melhor hierarquia de recursos para a sua organização.

Decisões para hierarquias de recursos.

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

  1. As diferentes subsidiárias, grupos regionais ou unidades de negócio têm requisitos de políticas muito diferentes?
    1. Se sim, siga o design baseado na região ou nas subsidiárias.
    2. Em caso negativo, avance para o ponto de decisão seguinte.

  2. As suas equipas de produtos ou de carga de trabalho requerem uma forte autonomia sobre as respetivas políticas? Por exemplo, não tem uma equipa de segurança central que determine as políticas para todas as equipas de produtos ou cargas de trabalho.

    1. Em caso afirmativo, consulte o design baseado na estrutura de responsabilidade.

    2. Caso contrário, consulte o design baseado no ambiente da aplicação.

O seu exemplo de utilização específico pode levar a um design de hierarquia de recursos diferente do que o fluxograma sugere. A maioria das organizações escolhe uma abordagem híbrida e seleciona designs diferentes em diferentes níveis da hierarquia de recursos, começando pelo design que mais afeta as políticas e o acesso.

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

Em muitas organizações, define políticas e controlos de acesso diferentes para diferentes ambientes de aplicações, como desenvolvimento, produção e testes. Ter políticas separadas que são padronizadas em cada ambiente facilita a gestão e a configuração. Por exemplo, 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 aplicação se o seguinte for verdadeiro:

  • Tem ambientes de aplicação separados com diferentes requisitos de políticas e administração.
  • Tem requisitos de segurança ou auditoria centralizados que uma equipa de segurança central tem de poder aplicar de forma consistente a todas as cargas de trabalho e dados de produção.
  • Precisa de diferentes funções de gestão de identidade e de acesso (IAM) para aceder aos seus Google Cloud recursos em diferentes ambientes.

Evite esta hierarquia se o seguinte for verdadeiro:

  • Não executa vários ambientes de aplicações.
  • Não tem dependências de aplicações nem processos empresariais variáveis em diferentes ambientes.
  • Tem diferenças de políticas significativas para diferentes regiões, equipas ou aplicações.

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

Diagrama da opção 1.

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

  • Ambiente de desenvolvimento e controlo de qualidade: este ambiente é gerido por programadores que são funcionários internos e consultores. Enviarem código continuamente e forem responsáveis pelo controlo de qualidade. Este ambiente nunca está disponível para os consumidores da sua empresa. O ambiente tem requisitos de integração e autenticação menos rigorosos do que o ambiente de produção, e os programadores têm funções aprovadas com permissões adequadas. O ambiente de desenvolvimento e controlo de qualidade foi concebido apenas para ofertas de aplicações padrão de example.com.

  • Ambiente de teste: este ambiente é usado para testes de regressão e de aplicações, e suporta as ofertas business-to-business (B2B) de clientes example.com que usam as APIs example.com. Para este efeito, example.com cria dois tipos de projetos:

    • Projetos de testes internos para concluir a regressão interna, o desempenho e a configuração para ofertas B2B.
    • Projetos de TUA de clientes com suporte multi-inquilino para que os clientes B2B possam validar as respetivas configurações e alinhar-se com os requisitos de example.com para experiência do utilizador, branding, fluxos de trabalho, relatórios, etc.

  • Ambiente de produção: este ambiente aloja todas as ofertas de produtos que são validadas, aceites e lançadas. Este ambiente está sujeito aos regulamentos da Norma de Segurança de Dados do Setor de Cartões de Pagamento (PCI DSS), usa módulos de segurança de hardware (HSMs) e integra-se com processadores de terceiros para itens como autenticação e liquidações de pagamentos. As equipas de auditoria e conformidade são partes interessadas essenciais deste ambiente. O acesso a este ambiente é rigorosamente controlado e limitado principalmente a processos de implementação automatizados.

Para mais informações sobre a conceção de uma hierarquia baseada em ambientes de aplicação, consulte a secção Estrutura organizacional no esquema de bases empresariais.

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 fazem negócios em diferentes geografias ou são o resultado de fusões e aquisições. Estas organizações requerem uma hierarquia de recursos que use as opções de escalabilidade e gestão no Google Cloude mantenha a independência para diferentes processos e políticas existentes entre as regiões ou as subsidiárias. Esta hierarquia usa subsidiárias ou regiões como o nível de pasta mais elevado na hierarquia de recursos. Normalmente, os procedimentos de implementação são focados nas regiões.

Use esta hierarquia se o seguinte for verdadeiro:

  • As diferentes regiões ou subsidiárias operam de forma independente.
  • As regiões ou as subsidiárias têm diferentes bases operacionais, ofertas de plataformas digitais e processos.
  • A sua empresa tem diferentes normas regulamentares e de conformidade para regiões ou subsidiárias.

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

Diagrama da opção 2.

O diagrama anterior tem a seguinte estrutura de hierarquia:

  • 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 autorizações de acesso e políticas do resto da organização. Cada subsidiária usa o IAM para restringir o acesso aos respetivos projetos e Google Cloud recursos.
    • A pasta Holding group representa os grupos que têm políticas comuns de nível superior em todas as regiões.
    • A pasta Bootstrap representa os recursos comuns necessários para implementar a sua infraestrutura, conforme descrito no projeto de base empresarial. Google Cloud
  • No segundo nível, na pasta Group Holding, existem as seguintes pastas:
    • As pastas APAC, EMEA e Americas representam as várias regiões no grupo que têm diferentes políticas, autorizações de acesso e políticas de governação.
    • A pasta Shared infrastructure representa recursos que são usados globalmente em todas as regiões.
  • Dentro de cada pasta, existem vários projetos que contêm os recursos pelos quais estas subsidiárias ou regiões são responsáveis.

Pode adicionar mais pastas para separar diferentes entidades legais, departamentos e equipas na sua empresa.

Opção 3: hierarquia baseada numa estrutura de responsabilidade

Uma hierarquia baseada numa estrutura de responsabilidade funciona melhor quando os seus produtos são geridos de forma independente ou as unidades organizacionais têm equipas claramente definidas que são responsáveis pelo ciclo de vida dos produtos. Nestas organizações, os proprietários dos produtos são responsáveis por todo o ciclo de vida do produto, incluindo os respetivos processos, apoio técnico, políticas, segurança e direitos de acesso. Os seus produtos são independentes uns dos outros e as diretrizes e os controlos ao nível da organização são pouco comuns.

Use esta hierarquia quando o seguinte for verdadeiro:

  • Gerir uma organização com propriedade e responsabilidade claras por cada produto.
  • As suas cargas de trabalho são independentes e não partilham muitas políticas comuns.
  • Os seus processos e plataformas de programadores externos são oferecidos como ofertas de serviços ou produtos.

O diagrama seguinte mostra um exemplo de hierarquia para um fornecedor de plataforma de comércio eletrónico.

Diagrama da opção 3.

O diagrama anterior tem a seguinte estrutura de hierarquia:

  • As seguintes pastas estão no primeiro nível:
    • As pastas com os nomes Ecommerce Modules e Logistics and Warehousing Modules representam os módulos na oferta da plataforma que requerem as mesmas autorizações de acesso e políticas durante o ciclo de vida do produto.
    • A pasta Reconciliation and Billing representa as equipas de produtos responsáveis pelos módulos integrais de componentes empresariais específicos na oferta da plataforma.
    • A pasta Bootstrap representa os recursos comuns necessários para implementar a sua infraestrutura, conforme descrito no projeto de base empresarial. Google Cloud
  • Dentro de cada pasta, existem vários projetos que contêm os módulos independentes dos quais diferentes equipas de produtos são responsáveis.

Para mais informações, consulte o artigo Hierarquia de recursos da estrutura do Terraform do Fabric FAST.

Práticas recomendadas para a hierarquia de recursos

As secções seguintes descrevem as práticas recomendadas para conceber a hierarquia de recursos, independentemente da hierarquia de recursos que escolher.

Para ver mais práticas recomendadas sobre como configurar as suas contas e organizações do Cloud ID e do Google Workspace, consulte o artigo Práticas recomendadas para planear contas e organizações.

Use um único nó da organização

Para evitar custos gerais de gestão, use um único nó da organização sempre que possível. No entanto, considere usar vários nós da organização para abordar os seguintes exemplos de utilização:

  • Quiser testar alterações importantes aos seus níveis de IAM ou à hierarquia de recursos.
  • Quiser fazer experiências num ambiente de sandbox que não tenha as mesmas políticas organizacionais.
  • A sua organização inclui subempresas que provavelmente vão ser vendidas ou geridas como entidades completamente separadas no futuro.

Use convenções de nomenclatura padronizadas

Use uma convenção de nomenclatura padronizada em toda a sua organização. O projeto de base de segurança tem uma convenção de nomenclatura de exemplo que pode adaptar aos seus requisitos.

Mantenha os recursos de arranque e os serviços comuns separados

Mantenha pastas separadas para o arranque do Google Cloud ambiente com infraestrutura como código (IaC) e para serviços comuns que são partilhados entre ambientes ou aplicações. Coloque a pasta de arranque imediatamente abaixo do nó da organização na hierarquia de recursos.

Coloque as pastas para serviços comuns em diferentes níveis da hierarquia, consoante a estrutura que escolher.

Coloque a pasta para serviços comuns imediatamente abaixo do nó da organização quando se verificar o seguinte:

  • A sua hierarquia usa ambientes de aplicações ao nível mais elevado e equipas ou aplicações na segunda camada.
  • Tem serviços partilhados, como a monitorização, que são comuns entre os ambientes.

Coloque a pasta para serviços comuns num nível inferior, abaixo das pastas de aplicações, quando se verificar o seguinte:

  • Tem serviços partilhados entre aplicações e implementa uma instância separada para cada ambiente de implementação.

  • As aplicações partilham microsserviços que requerem desenvolvimento e testes para cada ambiente de implementação.

O diagrama seguinte mostra um exemplo de hierarquia em que existe uma pasta de infraestrutura partilhada que é usada por todos os ambientes e pastas de serviços partilhados para cada ambiente de aplicação a um nível inferior na hierarquia:

Exemplo de hierarquia com pasta de infraestrutura partilhada.

O diagrama anterior tem a seguinte estrutura de hierarquia:

  • As pastas no primeiro nível são as seguintes:
    • As pastas Development environment e Production environment contêm os ambientes da aplicação.
    • A pasta Shared infrastructure contém recursos comuns que são partilhados entre ambientes, como a monitorização.
    • A pasta Bootstrap contém os recursos comuns necessários para implementar a sua infraestrutura, conforme descrito no projeto de base empresarial. Google Cloud
  • No segundo nível, existem as seguintes pastas:
    • Uma pasta em cada ambiente para cada aplicação (App 1 e App 2) que contém os recursos para estas aplicações.
    • Uma pasta Shared para ambos os ambientes de aplicação que contém serviços partilhados entre as aplicações, mas que são independentes para cada ambiente. Por exemplo, pode ter um projeto de segredos ao nível da pasta para poder aplicar políticas de autorização diferentes aos segredos de produção e aos segredos de não produção.
  • Dentro de cada pasta de aplicação, existem vários projetos que contêm os módulos independentes que fazem parte de cada aplicação.

O que se segue?