Papéis do IAM para funções de jobs relacionadas a redes

Neste tópico, você aprende a configurar as permissões do IAM nos cenários de rede. Nele, você encontra quais papéis de IAM conceder aos papéis funcionais relacionados à rede da sua empresa. Este conteúdo foi especialmente elaborado para os administradores de rede e funcionários que executam as tarefas de gerenciamento de rede de uma organização. Em todos os cenários descritos abaixo, presume-se que uma organização do Cloud esteja configurada.

Neste documento, não há explicações detalhadas sobre papéis e permissões de rede. Para uma descrição detalhada dos papéis e permissões associados às APIs de computação e rede, leia Papéis de IAM do Compute Engine.

Uma única equipe gerencia a segurança e a rede da organização

Neste cenário, uma grande organização tem uma equipe central que gerencia os controles de segurança e rede de toda a empresa. Os desenvolvedores não têm permissões para alterar as configurações de rede nem de segurança definidas por essa equipe. No entanto, podem criar recursos como máquinas virtuais nas sub-redes compartilhadas.

Para facilitar esse processo, a organização usa uma nuvem privada virtual (VPC, na sigla em inglês) compartilhada. Com ela, é possível criar uma rede VPC de espaços de IPs RFC1918 que pode ser usada pelos projetos associados (projetos de serviço). Os desenvolvedores que usam esses projetos criam instâncias de VM nos espaços da rede VPC. Os administradores de rede e segurança da organização podem criar sub-redes, VPNs e regras de firewall utilizáveis em todos os projetos da rede VPC.

Na tabela abaixo, veja os papéis de IAM que precisam ser concedidos à equipe de segurança e administração, à de desenvolvimento e a qual nível de recurso esses papéis são atribuídos.

Recurso: Organização
Papéis: Administrador de VPC compartilhada
Administrador de rede
Administrador de segurança
Membro: Equipe de administração de segurança e rede
Recurso: Projeto host Com esse papel, você concede a permissão de usar sub-redes compartilhadas na VPC compartilhada.
Papel: Usuário de rede
Membro: Desenvolvedores
Recurso: Projeto de serviço Observe que, com esse papel, você permite que endereços IP externos sejam usados. Consulte a nota abaixo para saber como restringir essa ação.
Papel: compute.instanceAdmin
Membro: Desenvolvedores

Para este cenário, são necessárias três políticas IAM separadas, uma vez que elas estão anexadas a projetos e níveis de hierarquia diferentes.

A primeira política IAM que precisa ser anexada no nível da organização é aquela usada para conceder permissões de administração dos projetos host da VPC à equipe de rede e segurança. Isso inclui a capacidade de associar os projetos de serviço ao projeto host. Além disso, com essa política, a equipe consegue gerenciar todos os recursos de segurança e rede de todos os projetos da organização.

{
  "bindings": [
    {
      "role": "roles/compute.xpnAdmin",
      "members": [
        "group:sec-net@example.com"
      ]
    },
    {
      "role":"roles/compute.networkAdmin",
      "members": [
        "group:sec-net@example.com"
      ]
    },
    {
      "role": "roles/compute.securityAdmin",
      "members": [
        "group:sec-net@example.com"
      ]
    }
  ]
}

A segunda política IAM precisa ser associada ao projeto host. Com ela, os desenvolvedores da organização usam as redes compartilhadas no projeto host da VPC compartilhada.

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "group:developers@example.com"
      ]
    }
  ]
}

A terceira política IAM precisa ser associada a cada projeto de serviço. Com ela, os desenvolvedores usam o projeto para gerenciar as instâncias no projeto de serviço e podem utilizar as sub-redes compartilhadas no projeto host.

Também é possível colocar todos os projetos de serviço em uma pasta e definir essa política específica no nível da hierarquia. Isso permite que todos os projetos criados nessa pasta herdem as permissões definidas na pasta dentro da qual o projeto de serviço foi criado.

Você também precisa conceder o papel de usuário de rede aos desenvolvedores no projeto de serviço.

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "group:developers@example.com"
        ]
    },
    {
      "role": "roles/compute.instanceAdmin",
      "members": [
        "group:developers@example.com"
        ]
    }
  ]
}

A prática recomendada é usar grupos para gerenciar membros. No exemplo acima, você adicionaria os códigos dos usuários que gerenciam os controles de segurança e rede ao grupo sec-net e os desenvolvedores ao grupo developers. Quando você tiver que modificar quem pode executar cada função, bastará ajustar a filiação do grupo, ou seja, não será necessário atualizar a política.

Equipes de rede e de segurança separadas

Nesse cenário, uma grande organização tem duas equipes centrais: uma que gerencia os controles de segurança e outra que gerencia todos os outros recursos de rede para toda a empresa. Os desenvolvedores não têm permissões para alterar as configurações de rede nem de segurança definidas por essa equipe, mas podem criar recursos como máquinas virtuais nas sub-redes compartilhadas.

Como no primeiro cenário, uma VPC compartilhada será usada e as permissões adequadas serão configuradas para os três grupos: rede, segurança e desenvolvedores.

Na tabela abaixo, veja os papéis de IAM que precisam ser concedidos à equipe de segurança e administração, à de desenvolvimento e a qual nível de recurso esses papéis são atribuídos.

Recurso: Organização
Papéis: Administrador de VPC compartilhada
Administrador de rede
Membro: Equipe de administração de rede
Recurso: Organização
Papéis: Administrador de segurança
Administrador da organização
Membro: Equipe de segurança
Recurso: Projeto host Com esse papel, você concede a permissão de usar sub-redes compartilhadas na VPC compartilhada.
Papel: Usuário de rede
Membro: Desenvolvedores
Recurso: Projeto de serviço Observe que, com esse papel, você permite que endereços IP externos sejam usados. Consulte a nota abaixo para saber como restringir essa ação.
Papel: compute.instanceAdmin
Membro: Desenvolvedores

Para este cenário, são necessárias três políticas IAM separadas, uma vez que elas estão anexadas a projetos e níveis de hierarquia diferentes.

A primeira política IAM que precisa ser anexada no nível da organização é aquela usada para conceder permissões de administração dos projetos host da VPC à equipe de rede. Isso inclui a capacidade de associar os projetos de serviço ao projeto host. O papel do administrador de rede também concede à equipe a possibilidade de ver, mas não modificar, as regras de firewall. Além disso, com essa política, a equipe de segurança define as políticas IAM e gerencia as regras de firewall e certificados SSL de todos os projetos da organização.

{
  "bindings": [
  {
    "role": "roles/compute.xpnAdmin",
    "members": [
      "group:networks@example.com"
      ]
  },
  {
    "role": "roles/compute.networkAdmin",
    "members": [
      "group:networks@example.com"
      ]
  },
  {
    "role": "roles/compute.securityAdmin",
    "members": [
      "group:security@example.com"
      ]
    },
    {
      "role": "roles/resourcemanager.organizationAdmin",
      "members": [
        "group:security@example.com"
        ]
    }
  ]
}

A segunda política IAM precisa ser associada ao projeto host. Com ela, os desenvolvedores da organização usam as redes compartilhadas no projeto host da VPC compartilhada.

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "group:developers@example.com"
        ]
    }
  ]
}

A terceira política IAM precisa ser associada a cada projeto de serviço. Com ela, os desenvolvedores usam o projeto para gerenciar as instâncias no projeto de serviço e podem utilizar as sub-redes compartilhadas no projeto host.

Também é possível colocar todos os projetos de serviço em uma pasta e definir essa política específica no nível da hierarquia. Isso permite que todos os projetos criados nessa pasta herdem as permissões definidas na pasta dentro da qual o projeto de serviço foi criado.

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "group:developers@example.com"
        ]
      },
      {
        "role": "roles/compute.instanceAdmin",
        "members": [
          "group:developers@example.com"
          ]
      }
    ]
}

Cada equipe pode gerenciar a própria rede

Uma empresa arrojada quer dar à equipe de desenvolvimento a possibilidade de trabalhar com autonomia. Eles não têm uma equipe de administradores de TI e confiam nos desenvolvedores para gerenciar todos os aspectos dos projetos.

A despeito disso, eles também querem implantar alguns controles flexíveis para que possam adotar uma estrutura mais formal à medida que crescem e o produto deles é lançado.

Para atender a esse cenário, cada equipe de desenvolvedores tem a própria pasta atribuída a ela. Isso significa que os projetos individuais subordinados à pasta herdam as permissões apropriadas. A equipe gerencia a rede associada dentro de cada um dos projetos de modo autônomo. Os processos e as políticas IAM precisam ser implementados de modo que, mesmo dentro dessas equipes autônomas, o mínimo de privilégios seja aplicado desde o início. Assim, você garante que não haja conflitos quando elas começam a trabalhar em conjunto.

Embora inicialmente os membros da equipe que gerenciam os recursos de rede e os recursos reais dos projetos sejam os mesmos, a criação de grupos lógicos separados é uma prática recomendada.

Essa abordagem facilita a limitação do acesso aos recursos que um colaborador temporário ou recém-contratado em treinamento precisaria antes de modificar os recursos da rede. Isso também permite alterar quem tem acesso a quais recursos sem a necessidade de modificar a política IAM todas as vezes que ocorre uma alteração na equipe.

Recurso: Pasta Use uma conta de serviço para criar e se tornar proprietário de projetos.
Papéis: Criador de projetos
Administrador de pasta
Membro: Líderes de equipe de desenvolvimento
Conta de serviço
Recurso: Pasta
Papéis: Administrador de rede

Administrador de segurança

Membro: Equipe de rede e segurança
Recurso: Pasta Com esses papéis, os desenvolvedores gerenciam todos os aspectos do BigQuery e do Compute Engine.
Papéis: Administrador de instâncias
Administrador do BigQuery
Membro: Desenvolvedores

Isso requer uma política do IAM vinculada à pasta alocada a cada equipe.

{
  "bindings": [
    {
      "role": "roles/resourcemanager.foldersAdmin",
      "members": [
        "group:devteamleads01@example.com",
        "serviceAccount:dev01-project-creator@shared-resources-proj.iam.gserviceaccount.com"
        ]
    },
    {
      "role":"roles/resourcemanager.projectCreator",
      "members": [
        "group:devteamleads01@example.com",
        "serviceAccount:dev01-project-creator@shared-resources-proj.iam.gserviceaccount.com"
      ]
    },
    {
      "role": "roles/compute.securityAdmin",
      "members": [
        "group:net-sec-dev01@example.com"
        ]
    },
    {
      "role": "roles/compute.networkAdmin",
      "members": [
        "group:net-sec-dev01@example.com"
        ]
    },
    {
      "role": "roles/compute.instanceAdmin",
      "members": [
        "group:dev01@example.com"
        ]
    },
    {
      "role": "roles/bigquery.admin",
      "members": [
        "group:dev01@example.com"
        ]
    }
  ]
}
Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Cloud Identity and Access Management