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 descendentes 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 políticas de IAM funciona e as práticas recomendadas que precisam ser consideradas 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 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 da pasta serão herdados por projetos ou outras pastas contidas na pasta pai. Para mais informações, consulte Controle de acesso para pastas usando o IAM.

  • Nível do projeto. Os projetos representam uma relação de confiança dentro da 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 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, recursos adicionais, como conjuntos de dados genômicos, tópicos 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 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.

O exemplo acima está ilustrado no seguinte diagrama:

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 é atribuído. Por exemplo, se você conceder a bob@gmail.com o papel de editor no nível do projeto, e o de visualizador no topic_a, ele terá o papel de editor no topic_a. Isso ocorre porque o papel de editor já foi concedido a Bob para o topic_a ao ser herdado da política definida para o project_a.

O exemplo acima está ilustrado no seguinte diagrama:

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 onde ficam guardados os objetos. Um exemplo de uso do Cloud 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 intervalo, 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 intervalos porque outros estão usando a localização do intervalo para fazer upload dos arquivos deles. Nesse caso, 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 objetos do Storage para um grupo de usuários, data_uploaders@example.com.
    • Essa política significa que qualquer pessoa que seja membro de data_uploaders@example.com poderá enviar arquivos para o intervalo.
    • Um membro do grupo é o proprietário dos arquivos que enviou, mas não consegue ler ou excluir arquivos carregados por outros usuários.

O exemplo acima está ilustrado no seguinte diagrama:

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. Conceder a bob@example.com o papel de Administrador de redes do Compute no nível da organização e a alice@example.com o papel de Administrador de instâncias do Compute no projeto dela, o "project_2", permitirá que Alice execute qualquer ação nas instâncias e evitará que ela altere os recursos de rede associados ao projeto. Somente Bob pode alterar os recursos de rede na organização e em qualquer projeto dessa organização.

Exemplo do Cloud Storage

Práticas recomendadas

  • Espelhe a estrutura hierárquica de políticas do Cloud IAM na estrutura da organização. A hierarquia de políticas do Cloud IAM precisa refletir como a empresa é organizada, seja 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 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.

  • 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, convém que eles herdem automaticamente as políticas do recurso pai deles. Por exemplo, quando novas máquinas virtuais são adicionadas ao projeto por meio do escalonamento automático, elas herdam automaticamente a política do projeto.

  • Use o princípio de segurança do privilégio mínimo ao conceder papéis do Cloud 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 gerenciar membros em um grupo do Google do que atualizar uma política do Cloud IAM.

  • Controle a propriedade do grupo do Google usado nas políticas do Cloud IAM.

  • Conceda papéis com o menor escopo necessário. Por exemplo, se um usuário só precisar de acesso para publicar mensagens em um tópico do Cloud Pub/Sub, conceda a função Publicador ao usuário desse tópico.

  • Lembre-se de que uma política definida como 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.

  • 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.

  • Use rótulos 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(). Dessa maneira, é possível verificar quando uma política foi criada ou modificada.

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

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

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

Enviar comentários sobre…

Documentação do Cloud IAM