Uso da hierarquia de recursos para controle de acesso

Os recursos doGoogle Cloud são organizados hierarquicamente. O nó da organização é o nó raiz na hierarquia, os projetos são os filhos da organização e os outros recursos são descendentes de projetos. É possível definir políticas do IAM em diferentes níveis da hierarquia de recursos. Os recursos herdam as políticas do recurso pai. A política de permissão efetiva de um recurso é a união da política de permissão definida nesse recurso com a política de permissão herdada do recurso pai.

Nesta página, você verá alguns exemplos de como a herança de políticas de permissão funciona e as práticas recomendadas que precisam ser consideradas ao criar recursos durante a implantação do Identity and Access Management (IAM).

Pré-requisitos

Contexto

O diagrama a seguir mostra um exemplo de hierarquia de recursos do Google Cloud .

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

O IAM permite definir políticas nos seguintes níveis da hierarquia de recursos:

  • Nível da organização. O recurso da organização representa a empresa. Os papéis de IAM concedidos nesse nível são herdados por todos os recursos dessa organização. Para mais informações, consulte Controle de acesso para organizações que usam o IAM.

  • Nível da pasta. Pastas podem conter projetos, outras pastas ou uma combinação de ambos. Os papéis concedidos no nível mais alto de pasta serão herdados por projetos ou outras pastas contidas nessa pasta pai. Para mais informações, consulte Controle de acesso para pastas que usam o IAM.

  • Nível do projeto. Os projetos representam uma relação de confiança dentro da empresa. Os serviços de um mesmo projeto têm um nível padrão de confiança. Os papéis do IAM concedidos no nível do projeto são herdados por recursos desse projeto. Para mais informações, consulte Controle de acesso para projetos que usam o IAM.

  • Nível do recurso. Além dos sistemas Cloud Storage e BigQuery ACL, outros recursos, como tópicos do Pub/Sub e instâncias do Compute Engine, são compatíveis com papéis de nível inferior. Assim, é possível conceder a determinados usuários permissão para um único recurso em um projeto.

As políticas de IAM são hierárquicas e se propagam em sentido descendente na estrutura. A política de permissão efetiva de um recurso é a união da política de permissão definida nesse recurso e da política de permissão herdada do recurso pai.

Os exemplos a seguir explicam como a herança de políticas funciona na prática.

Exemplo: Pub/Sub

No Pub/Sub, tópicos e inscrições são recursos que residem em um projeto. Suponha que project_1 tenha um tópico topic_a. Se você definir uma política de permissão em project_1 que concede o papel Editor a Kalani e definir uma política de permissão em topic_a que concede o papel Publicador a Nur, você efetivamente concede o papel Editor a Kalani e o papel Publicador a Nur para topic_a.

O diagrama a seguir ilustra o exemplo anterior.

Exemplo do Pub/Sub.

Se um papel herdado já conceder a um principal todas as permissões necessárias, não será preciso conceder outros papéis no próprio recurso. Conceder outro papel que contenha as mesmas permissões ou menos é redundante e não tem efeito.

Por exemplo, considere os papéis básicos Proprietário, Editor e Leitor. Esses papéis são concêntricos, ou seja, o Proprietário tem as permissões do Editor e o Editor tem as permissões do Leitor. Por isso, se você conceder a Kalani o papel de editor no nível do projeto, conceder a ela o papel de leitor em topic_a será redundante. Isso ocorre porque Kalani já tem todas as permissões do papel de leitor pelo papel de editor, que é herdado da política de permissão do projeto.

O diagrama a seguir ilustra o exemplo anterior.

Exemplo do Pub/Sub.

Exemplo: Cloud Storage

No Cloud Storage, os buckets e os objetos são recursos, e os objetos estão localizados em buckets. Um exemplo de uso do IAM com o Cloud Storage é permitir acesso de leitura a arquivos carregados.

Considere uma situação em que muitos usuários fazem upload de arquivos em um bucket, mas não podem ler ou excluir nenhum dos arquivos carregados por outros usuários. A especialista em processamento de dados poderá ler e excluir arquivos carregados, mas não poderá excluir buckets porque outros estão usando a localização do bucket para fazer upload dos arquivos deles. Nesse caso, você definiria as políticas no projeto da seguinte maneira:

  • Conceda o papel de administrador de objetos do Storage (roles/storage.objectAdmin) ao especialista em tratamento de dados, Nur. Com esse papel, Nur pode ler, adicionar e excluir qualquer objeto em qualquer bucket do projeto.
  • Conceda o papel Criador de objetos do Storage (roles/storage.objectCreator) ao grupo data-uploaders. Com essa função, os membros do grupo podem fazer upload de arquivos para o bucket, mas não podem ler ou excluir arquivos enviados por outros usuários.

O diagrama a seguir ilustra o exemplo anterior.

Exemplo do Cloud Storage.

Exemplo: Compute Engine

Nas grandes empresas, o gerenciamento de recursos de rede e segurança, por exemplo, firewalls, geralmente é feito por uma equipe dedicada, diferente da equipe de desenvolvimento. As equipes de desenvolvimento talvez precisem de flexibilidade para inicializar instâncias e executar outras ações relacionadas a instâncias nos projetos.

Em uma situação como essa, você pode configurar as políticas de permissão da seguinte maneira:

  • Conceda o papel de administrador de rede do Compute (roles/compute.networkAdmin) à sua administradora de rede e segurança, Kalani, no nível da organização. Com essa função, Kalani pode fazer mudanças nos recursos de rede da organização e em qualquer projeto dela.
  • Conceda o papel de administrador de instâncias do Compute (roles/compute.instanceAdmin) a um líder da equipe de desenvolvimento, Nur, no projeto project_2. Essa função permite que Nur realize qualquer ação nas instâncias dela, mas impede que ela faça mudanças nos recursos de rede associados ao projeto. No entanto, ela não permite que eles façam mudanças nos recursos de rede em outros projetos.

Exemplo do Compute Engine.

Permissões para visualizar políticas herdadas

Para visualizar as políticas do IAM herdadas de um recurso pai, você precisa da permissão para visualizar a política do IAM do recurso pai. Por exemplo, para visualizar todas as políticas do IAM herdadas por um projeto, você precisa da permissão para visualizar a política do IAM da organização pai do projeto e para visualizar as políticas do IAM de todas as pastas mãe.

Para ter as permissões necessárias para visualizar as políticas do IAM herdadas de recursos pai, peça ao administrador para conceder a você os seguintes papéis do IAM:

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Esses papéis predefinidos contêm as permissões necessárias para visualizar as políticas do IAM herdadas de recursos pai. Para conferir as permissões exatas necessárias, expanda a seção Permissões necessárias:

Permissões necessárias

As permissões a seguir são necessárias para visualizar as políticas do IAM herdadas de recursos pai:

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

Essas permissões também podem ser concedidas com funções personalizadas ou outros papéis predefinidos.

Práticas recomendadas

  • Espelhe a estrutura de hierarquia de recursos do Google Cloud na estrutura da organização. A hierarquia de recursos do Google Cloud deve refletir como sua empresa é organizada, seja uma startup, uma PME ou uma grande corporação. Uma startup pode começar com uma hierarquia de recursos simples, sem o recurso de organização. À medida que mais colaboradores são incluídos nos projetos e a quantidade de projetos aumenta, faz mais sentido ter um recurso de organização. Recomendamos esse recurso para grandes empresas com vários departamentos e equipes, em que cada equipe é responsável pelo próprio conjunto de aplicativos e serviços.

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

  • Quando possível, conceda papéis a um grupo, não a usuários individuais. É mais fácil gerenciar membros em um grupo do que atualizar uma política de permissão. Controle a propriedade do grupo usado nas políticas de permissão.

    Para mais informações sobre como gerenciar os Grupos do Google, consulte a Ajuda dos Grupos do Google.

  • Use o princípio de segurança do privilégio mínimo ao conceder papéis do IAM, ou seja, dê o mínimo de acesso necessário aos recursos.

    Para encontrar o papel predefinido apropriado, consulte a referência de papéis predefinidos. Se não houver papéis predefinidos apropriados, também é possível criar seus próprios papéis personalizados.

  • Conceda papéis com o menor escopo necessário. Por exemplo, se um usuário precisa apenas publicar mensagens em um tópico do Pub/Sub, conceda o papel de Publicador desse tópico.

  • Lembre-se de que as políticas de permissão para recursos filhos herdam as políticas de permissão dos recursos pais. Por exemplo, se a política de um projeto conceder a um usuário a capacidade de administrar instâncias de máquina virtual (VM) do Compute Engine, ele poderá administrar qualquer VM do Compute Engine nesse projeto, independentemente da política definida em cada VM.

  • Em todos os projetos, verifique se pelo menos dois principais têm o papel de proprietário (roles/owner). Como alternativa, conceda o papel de Proprietário a um grupo que contém pelo menos dois principais.

    Essa prática ajuda a garantir que, se um dos principais sair da empresa, você ainda terá uma maneira de gerenciar o projeto.

  • Se você precisar conceder um papel a um usuário ou grupo presente em vários projetos, defina esse papel no nível da pasta em vez de defini-lo no nível do projeto.

  • Utilize etiquetas para fazer anotações, agrupar e filtrar recursos.

  • Faça uma auditoria nas políticas para garantir a conformidade. Os registros de auditoria contêm todas as chamadas setIamPolicy() para que você possa rastrear quando uma política de permissão foi criada ou modificada.

  • Faça uma auditoria da propriedade e da associação dos grupos usados nas políticas de permissão.

  • Se você quiser limitar a criação de projetos na organização, altere a política de acesso da organização para conceder o papel de Criador de projetos a um Grupo gerenciado por você.