Como usar a hierarquia de recursos para controle de acesso

Os recursos do Cloud Platform são organizados hierarquicamente, sendo que 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 os filhos dos projetos. As políticas de IAM podem ser definidas em níveis diferentes da hierarquia de recursos. Os recursos herdam as políticas do recurso pai. A política efetiva de um recurso é a união da política definida para o recurso com a herdada do pai dele.

Nesta página, você encontra alguns exemplos de como a herança de politicas de IAM funciona e as melhores práticas que precisam ser pensadas na criação de recursos durante a implantação do IAM.

Pré-requisitos

Contexto

O seguinte diagrama mostra um exemplo de hierarquia de recursos do Cloud Platform:

Hierarquia de recursos

Com o IAM, você define políticas nos seguintes níveis de hierarquia de recursos:

  • Nível da organização. O recurso Organização representa a sua empresa. Os papéis de IAM concedidos nesse nível são herdados por todos os recursos dessa organização.

  • Nível do projeto. Os projetos representam uma relação de confiança dentro da sua empresa. Os serviços do mesmo projeto têm um nível padrão de confiança. Por exemplo, as instâncias do App Engine podem acessar intervalos do Cloud Storage dentro do mesmo projeto. Os papéis de IAM concedidos no nível do projeto são herdados pelos recursos desse projeto.

  • Nível do recurso. Além dos sistemas de ACL do Cloud Storage e do BigQuery, outros recursos como os conjuntos de dados do Genomics e os tópicos do Pub/Sub são compatíveis com papéis no nível do recurso. Isso significa que você consegue definir permissões de usuário específicas para um único recurso.

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

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

Exemplo: Cloud Pub/Sub

No Cloud Pub/Sub, os tópicos e as inscrições são recursos que residem em um projeto. Veja um caso em que o project_a tenha um tópico topic_a. Suponha que você defina uma política que conceda o papel de editor a bob@gmail.com no project_a e outra, no topic_a, que conceda o papel de publicador a alice@gmail.com. Nesse caso, bob@gmail.com tem o papel de editor e alice@gmail.com o de publicador no topic_a.

No diagrama a seguir, o exemplo acima está ilustrado:

Exemplo do Pub/Sub

Os papéis de proprietário, editor e visualizador são concêntricos, ou seja, o proprietário tem as permissões do editor e o editor tem as permissões do visualizador. Quando você concede papéis com permissões diferentes à mesma pessoa, por exemplo, editor e visualizador, apenas o papel mais abrangente é válido. Por exemplo, se bob@gmail.com tem o papel de editor no nível do projeto, e o de visualizador no topic_a, então ele é editor no topic_a. Isso porque o papel de editor já foi concedido ao Bob, ou seja, ele foi herdado da política definida para o project_a.

No diagrama a seguir, o exemplo acima está ilustrado:

Exemplo do Pub/Sub

Exemplo: Cloud Storage

No Cloud Storage, os intervalos e os objetos são recursos. Os intervalos são os contêineres que mantêm os objetos. Um exemplo de uso do Cloud IAM com o Cloud Storage é permitir acesso de leitura aos arquivos do upload.

Considere um cenário em que muitos usuários fazem upload de arquivos em um intervalo, mas não são capazes de ler ou excluir nenhum dos arquivos carregados por outros usuários. O especialista em processamento de dados poderá ler e excluir arquivos do upload, mas não será capaz de excluir intervalos porque outros estão usando a localização do intervalo para fazer upload dos arquivos deles. Nesse cenário, você definiria as políticas no projeto da seguinte maneira:

  • Concessão de Administrador de objetos do Storage para a especialista em processamento de dados, Alice em alice@example.com.
    • Alice tem direitos de administrador de objetos no nível do projeto e pode ler, adicionar e excluir qualquer objeto em qualquer intervalo do projeto.
  • Concessão de Criador de objeto do Storage para um grupo de usuários, data_uploaders@example.com.
    • Essa política significa que qualquer pessoa que é membro do data_uploaders@example.com pode enviar arquivos para o intervalo.
    • Um membro do grupo é o proprietário dos arquivos que fez upload, mas não consegue ler ou excluir arquivos que outros usuários fizeram upload.

No diagrama a seguir, o exemplo acima está ilustrado:

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, mas que não seja a de desenvolvimento. As equipes de desenvolvimento talvez precisem de flexibilidade para inicializar instâncias e executar outras ações relacionadas a essas instâncias nos projetos. Conceder o papel de Administrador de redes do Compute a bob@example.com no nível da organização e o de Administrador de instâncias do Compute a alice@example.com no projeto "project_2" possibilita que Alice execute qualquer ação nas instâncias e, ao mesmo tempo, impede que ela altere os recursos de rede associados ao projeto dela. Somente o Bob altera os recursos de rede na organização e em qualquer projeto abaixo dessa organização.

Exemplo do Cloud Storage

Práticas recomendadas

  • Espelhe a estrutura hierárquica de políticas de IAM na estrutura da sua organização. A hierarquia IAM precisa refletir a organização da sua empresa, seja ela uma startup, uma PME ou uma grande corporação. Uma startup pode começar com uma hierarquia de políticas 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 os projetos do Cloud Platform para agrupar recursos que compartilhem a mesma relação de confiança. Por exemplo, os recursos do mesmo produto ou microsserviço podem pertencer ao mesmo projeto.

  • Defina políticas nos níveis da organização e do projeto, em vez de defini-las no nível do recurso. À medida que novos recursos são adicionados, pode ser necessário que eles herdem as políticas do recurso pai automaticamente. Por exemplo, quando novas máquinas virtuais são adicionadas ao projeto por meio do escalonamento automático, elas herdam automaticamente a política no projeto.

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

  • Quando possível, conceda papéis a um grupo do Google, em vez de a usuários individuais. É mais fácil adicionar membros e removê-los de um grupo do Google do que atualizar uma política do Cloud IAM para incluir ou excluir usuários.

  • Controle a propriedade do grupo do Google usada nas políticas de IAM.

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

  • Lembre-se de que uma política definida para um recurso filho não restringe o acesso concedido ao pai. Verifique a política concedida a cada recurso e fique atento à herança hierárquica.

  • Para conceder um papel que abranja vários projetos a um usuário ou grupo, defina esse papel no nível da organização em vez de defini-lo no nível do projeto.

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

  • Faça uma auditoria nas políticas para garantir a conformidade. Os registros de auditoria do Cloud contêm todas as chamadas a setiampolicy, ou seja, você consegue rastreá-las para saber quando uma política foi aplicada.

  • Faça uma auditoria da propriedade e da filiação dos grupos do Google usados nas políticas.

  • Para limitar a criação de projetos na sua organização, altere a Política de acesso da organização para conceder o Papel de criador de projetos a um grupo que você gerencia.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Cloud Identity and Access Management