Usar a hierarquia de recursos para o controlo de acesso

Os recursosGoogle Cloud estão organizados hierarquicamente, em que o nó de organização é o nó de raiz na hierarquia, os projetos são os filhos da organização e os outros recursos são descendentes dos projetos. Pode definir políticas de permissão em diferentes níveis da hierarquia de recursos. Os recursos herdam as políticas de permissão do recurso principal. A política de permissão efetiva para um recurso é a união da política de permissão definida nesse recurso e da política de permissão herdada do respetivo recurso principal.

Esta página descreve alguns exemplos de como funciona a herança de políticas de autorização e explica as práticas recomendadas que tem de ter em consideração quando cria recursos durante a implementação da gestão de identidades e acessos (IAM).

Pré-requisitos

Contexto

O diagrama seguinte mostra um exemplo de uma hierarquia de Google Cloud recursos.

De cima para baixo, a hierarquia inclui organizações, pastas, projetos e recursos específicos do serviço.

A IAM permite-lhe definir políticas de permissão nos seguintes níveis da hierarquia de recursos:

  • Nível da organização. O recurso de organização representa a sua empresa. As funções de IAM concedidas a este nível são herdadas por todos os recursos na organização. Para mais informações, consulte o artigo Controlo de acesso para organizações que usam a IAM.

  • Nível da pasta. As pastas podem conter projetos, outras pastas ou uma combinação de ambos. As funções concedidas ao nível da pasta mais elevado são herdadas pelos projetos ou outras pastas contidos nessa pasta principal. Para mais informações, consulte o artigo Controlo de acesso para pastas através da IAM.

  • Nível do projeto. Os projetos representam um limite de confiança na sua empresa. Os serviços no mesmo projeto têm um nível de confiança predefinido. As funções da IAM concedidas ao nível do projeto são herdadas pelos recursos nesse projeto. Para mais informações, consulte o artigo Controlo de acesso para projetos com a IAM.

  • Nível de recurso. Além dos sistemas de ACLs do Cloud Storage e do BigQuery existentes, os recursos adicionais, como os tópicos do Pub/Sub e as instâncias do Compute Engine, suportam funções de nível inferior para que possa conceder a determinados utilizadores autorização para um único recurso num projeto.

As políticas de permissão são hierárquicas e propagam-se na estrutura. A política de permissão em vigor para um recurso é a união da política de permissão definida nesse recurso e da política de permissão herdada do respetivo recurso principal.

Os exemplos seguintes explicam como funciona na prática a herança de políticas de permissão.

Exemplo: Pub/Sub

No Pub/Sub, os tópicos e as subscrições são recursos que se encontram num projeto. Suponhamos que project_1 tem um tópico topic_a abaixo. Se definir uma política de autorização em project_1 que conceda a função de Editor a Kalani e definir uma política de autorização em topic_a que conceda a função de Publicador a Nur, concede efetivamente a função de Editor a Kalani e a função de Publicador a Nur para topic_a.

O diagrama seguinte ilustra o exemplo anterior.

Exemplo do Pub/Sub.

Se uma função herdada já conceder a um principal todas as autorizações de que precisa, não tem de lhe conceder funções adicionais no próprio recurso. A concessão de outra função que contenha as mesmas autorizações ou menos é redundante e não tem qualquer efeito.

Por exemplo, considere as funções básicas Proprietário, Editor e Leitor. Estas funções são concêntricas, ou seja, a função de proprietário inclui as autorizações da função de editor, e a função de editor inclui as autorizações da função de leitor. Como resultado, se conceder à Kalani a função de editor ao nível do projeto, conceder-lhe a função de leitor no topic_a é redundante. Isto acontece porque Kalani já tem todas as autorizações na função de leitor através da função de editor, que é herdada da política de autorização do projeto.

O diagrama seguinte ilustra o exemplo anterior.

Exemplo do Pub/Sub.

Exemplo: Cloud Storage

No Cloud Storage, os contentores e os objetos são recursos, e os objetos estão localizados em contentores. Um exemplo de utilização do IAM com o Cloud Storage é permitir o acesso de leitura a ficheiros carregados.

Considere um cenário em que muitos utilizadores carregam ficheiros para um contentor, mas não devem poder ler nem eliminar nenhum dos ficheiros carregados por outros utilizadores. O seu especialista em processamento de dados deve conseguir ler e eliminar ficheiros carregados, mas não deve conseguir eliminar contentores, porque outras pessoas estão a usar a localização do contentor para carregar os respetivos ficheiros. Neste cenário, definiria as políticas de autorização no projeto da seguinte forma:

  • Conceda a função de administrador de objetos de armazenamento (roles/storage.objectAdmin) ao seu especialista em processamento de dados, Nur. Esta função permite que Nur leia, adicione e elimine qualquer objeto em qualquer contentor no projeto.
  • Conceda a função Storage Object Creator (roles/storage.objectCreator) ao grupo data-uploaders. Esta função permite que os membros do grupo carreguem ficheiros para o contentor, mas não lhes permite ler nem eliminar ficheiros carregados por outros utilizadores.

O diagrama seguinte ilustra o exemplo anterior.

Exemplo do Cloud Storage.

Exemplo: Compute Engine

Nas empresas maiores, a gestão dos recursos de rede e segurança, como as firewalls, é normalmente gerida por uma equipa dedicada, que é diferente da equipa de desenvolvimento. As equipas de desenvolvimento podem querer a flexibilidade de iniciar instâncias e realizar outras ações relacionadas com instâncias nos respetivos projetos.

Numa situação como esta, pode configurar as políticas de permissão da seguinte forma:

  • Conceda a função Administrador de rede do Compute(roles/compute.networkAdmin) ao administrador de rede e segurança, Kalani, ao nível da organização. Esta função permite que a Kalani faça alterações aos recursos de rede na organização e em quaisquer projetos dessa organização.
  • Conceda a função Administrador de instâncias do Compute (roles/compute.instanceAdmin) a um líder da equipa de desenvolvimento, Nur, no respetivo projeto project_2. Esta função permite que a Nur execute quaisquer ações nas respetivas instâncias, ao mesmo tempo que a impede de fazer alterações aos recursos de rede associados ao respetivo projeto. No entanto, não lhe permite fazer alterações aos recursos de rede noutros projetos.

Exemplo do Compute Engine.

Autorizações para ver políticas herdadas

Para ver as políticas de IAM herdadas de um recurso principal, precisa de autorização para ver a política de IAM do recurso principal. Por exemplo, para ver todas as políticas IAM herdadas de um projeto, precisa de autorização para ver a política IAM da organização principal do projeto e para ver as políticas IAM de todas as pastas principais.

Para receber as autorizações de que precisa para ver as políticas de IAM herdadas de recursos principais, peça ao seu administrador que lhe conceda as seguintes funções de IAM:

Para mais informações sobre a atribuição de funções, consulte o artigo Faça a gestão do acesso a projetos, pastas e organizações.

Estas funções predefinidas contêm as autorizações necessárias para ver as políticas de IAM herdadas dos recursos principais. Para ver as autorizações exatas que são necessárias, expanda a secção Autorizações necessárias:

Autorizações necessárias

São necessárias as seguintes autorizações para ver as políticas IAM herdadas de recursos principais:

  • Ver uma política IAM herdada de uma organização: resourcemanager.organizations.getIamPolicy na organização
  • Veja uma Política IAM herdada de uma pasta: resourcemanager.folders.getIamPolicy na pasta
  • Veja uma política IAM herdada de um projeto: resourcemanager.projects.getIamPolicy no projeto

Também pode conseguir estas autorizações com funções personalizadas ou outras funções predefinidas.

Práticas recomendadas

  • Espelhe a estrutura da hierarquia de recursos na estrutura da organização. Google Cloud A hierarquia de recursos deve refletir a forma como a sua empresa está organizada, quer seja uma startup, uma PME ou uma grande empresa. Google Cloud Uma startup pode começar com uma hierarquia de recursos simples sem um recurso de organização. Quando mais pessoas começam a colaborar em projetos e o número de projetos aumenta, pode fazer sentido obter um recurso de organização. Recomendamos um recurso de organização para empresas maiores com vários departamentos e equipas, em que cada equipa é responsável pelo seu próprio conjunto de aplicações e serviços.

  • Use projetos para agrupar recursos que partilham o mesmo limite de confiança. Por exemplo, os recursos para o mesmo produto ou microsserviço podem pertencer ao mesmo projeto.

  • Conceda funções a um grupo em vez de a utilizadores individuais, sempre que possível. É mais fácil gerir membros num grupo do que atualizar uma política de permissão. Certifique-se de que controla a propriedade do grupo usado nas políticas de permissão.

    Para mais informações sobre como gerir grupos Google, consulte a Ajuda dos Grupos Google.

  • Use o princípio de segurança do privilégio mínimo para conceder funções do IAM, ou seja, conceda apenas a quantidade mínima de acesso necessária aos seus recursos.

    Para encontrar a função predefinida adequada, consulte a referência de funções predefinidas. Se não existirem funções predefinidas adequadas, também pode criar as suas próprias funções personalizadas.

  • Conceda funções no âmbito mais pequeno necessário. Por exemplo, se um utilizador só precisar de acesso para publicar mensagens num tópico do Pub/Sub, conceda-lhe a função de Publicador para esse tópico.

  • Tenha em atenção que as políticas de permissão para recursos secundários são herdadas das políticas de permissão para os respetivos recursos principais. Por exemplo, se a política de autorização de um projeto conceder a um utilizador a capacidade de administrar instâncias de máquinas virtuais (VMs) do Compute Engine, o utilizador pode administrar qualquer VM do Compute Engine nesse projeto, independentemente da política de autorização que definir em cada VM.

  • Em todos os projetos, certifique-se de que, pelo menos, dois responsáveis têm a função de proprietário (roles/owner). Em alternativa, atribua a função de proprietário a um grupo que contenha, pelo menos, dois responsáveis.

    Esta prática ajuda a garantir que, se um dos diretores sair da sua empresa, continua a ter uma forma de gerir o seu projeto.

  • Se precisar de conceder uma função a um utilizador ou um grupo que abranja vários projetos, defina essa função ao nível da pasta em vez de a definir ao nível do projeto.

  • Use etiquetas para anotar, agrupar e filtrar recursos.

  • Audite as suas políticas de autorização para garantir a conformidade. Os registos de auditoria contêm todas as chamadas setIamPolicy(), para que possa determinar quando uma política de permissão foi criada ou modificada.

  • Audite a propriedade e a adesão dos grupos usados nas políticas de permissão.

  • Se quiser limitar a criação de projetos na sua organização, altere a política de acesso da organização para conceder a função de criador de projetos a um grupo que gere.