Funções de IAM para funções relacionadas com redes

Este tópico mostra como configurar as autorizações de gestão de identidade e de acesso (IAM) para cenários de rede. Fornece orientações sobre as funções de IAM a conceder às funções funcionais relacionadas com a rede na sua empresa para os cenários. Este conteúdo destina-se principalmente a administradores de rede e funcionários que gerem tarefas de rede para uma organização. Os cenários descritos abaixo partem do princípio de que uma organização está configurada. Trusted Cloud by S3NS

Este documento não explica detalhadamente as funções e as autorizações de rede. Para uma descrição detalhada das funções e autorizações associadas às APIs de computação e de rede, leia o artigo Funções de IAM do Compute Engine predefinidas.

Uma única equipa gere a segurança e a rede da organização

Neste cenário, uma grande organização tem uma equipa central que gere os controlos de segurança e de rede para toda a organização. Os programadores não têm autorização para fazer alterações a quaisquer definições de rede ou de segurança definidas pela equipa de segurança e rede, mas têm autorização para criar recursos, como máquinas virtuais em sub-redes partilhadas.

Para facilitar este processo, a organização usa uma VPC partilhada (nuvem privada virtual). Uma VPC partilhada permite a criação de uma rede VPC de espaços de IP RFC 1918 que os projetos associados (projetos de serviço) podem usar. Os programadores que usam os projetos associados podem criar instâncias de VM nos espaços da rede VPC partilhada. Os administradores de rede e segurança da organização podem criar sub-redes, VPNs e regras de firewall que podem ser usadas por todos os projetos na rede de VPC.

As tabelas abaixo explicam as funções de IAM que têm de ser concedidas à equipa de segurança e administração e à equipa de desenvolvimento, bem como o nível do recurso ao qual as funções são concedidas.

Para este cenário, precisa de três políticas de autorização separadas: uma para a organização, uma para o projeto anfitrião e uma para os projetos de serviço.

A primeira política de permissão, que tem de ser anexada ao nível da organização, concede à equipa de rede e segurança as funções de que necessita para administrar projetos anfitriões de VPC partilhada. Isto inclui a capacidade de associar projetos de serviço ao projeto anfitrião. Também concede à equipa de rede e segurança a capacidade de gerir todos os recursos de rede e segurança em todos os projetos da organização.

{
  "bindings": [
    {
      "role": "roles/compute.xpnAdmin",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/sec-net"
      ]
    },
    {
      "role":"roles/compute.networkAdmin",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/sec-net"
      ]
    },
    {
      "role": "roles/compute.securityAdmin",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/sec-net"
      ]
    }
  ]
}

A segunda política de permissão tem de estar associada ao projeto anfitrião e permite que os programadores na organização usem as redes partilhadas no projeto anfitrião de VPC partilhada.

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/developers"
      ]
    }
  ]
}

A terceira política de autorização tem de estar associada a cada projeto de serviço. Isto permite que os programadores que usam o projeto geram instâncias no projeto de serviço e usem as sub-redes partilhadas no projeto anfitrião.

Pode colocar todos os projetos de serviço numa pasta e definir esta política de permissão específica nesse nível da hierarquia. Isto permite que todos os projetos criados nessa pasta herdem as autorizações definidas na pasta na qual o projeto de serviço é criado.

Também tem de conceder aos programadores a função de utilizador da rede no projeto de serviço.

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/developers"
        ]
    },
    {
      "role": "roles/compute.instanceAdmin",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/developers"
        ]
    }
  ]
}

A prática recomendada é usar grupos para gerir os responsáveis. No exemplo acima, adicionaria os IDs dos utilizadores que gerem os controlos de segurança e de rede ao grupo sec-net e os programadores ao grupo developers. Quando precisa de modificar quem pode realizar a função, basta ajustar a associação ao grupo, o que elimina a necessidade de atualizar a política de autorização.

Equipas de segurança e de rede separadas

Neste cenário, uma organização grande tem duas equipas centrais: uma que gere os controlos de segurança e outra que gere todos os outros recursos de rede para toda a organização. Os programadores não têm autorização para fazer alterações a quaisquer definições de rede ou de segurança definidas pela equipa de segurança e rede, mas têm autorização para criar recursos, como máquinas virtuais, em sub-redes partilhadas.

Tal como no primeiro cenário, é usada uma VPC partilhada e as autorizações adequadas são configuradas para os três grupos: rede, segurança e programadores.

As tabelas abaixo explicam as funções do IAM que têm de ser concedidas à equipa de segurança e administração e à equipa de desenvolvimento, bem como o nível de recurso ao qual as funções são concedidas.

Para este cenário, precisa de três políticas de autorização separadas: uma para a organização, uma para o projeto anfitrião e uma para os projetos de serviço.

A primeira política de autorização, que tem de ser anexada ao nível da organização, concede à equipa de rede as funções de que necessita para administrar projetos anfitriões da VPC partilhada e gerir todos os recursos de rede. Isto inclui a capacidade de associar projetos de serviço ao projeto anfitrião. A função de administrador de rede também concede à equipa de rede a capacidade de ver, mas não de modificar as regras da firewall. Também concede à equipa de segurança a capacidade de definir políticas de permissão e gerir regras de firewall e certificados SSL em todos os projetos da organização.

{
  "bindings": [
  {
    "role": "roles/compute.xpnAdmin",
    "members": [
      "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/networks"
      ]
  },
  {
    "role": "roles/compute.networkAdmin",
    "members": [
      "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/networks"
      ]
  },
  {
    "role": "roles/compute.securityAdmin",
    "members": [
      "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/security"
      ]
    },
    {
      "role": "roles/resourcemanager.organizationAdmin",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/security"
        ]
    }
  ]
}

A segunda política de permissão tem de estar associada ao projeto anfitrião. Esta política permite que os programadores na organização usem as redes partilhadas no projeto anfitrião da VPC partilhada.

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/developers"
        ]
    }
  ]
}

A terceira política de autorização tem de estar associada a cada projeto de serviço. Isto permite que os programadores que usam o projeto geram instâncias no projeto de serviço e usem as sub-redes partilhadas no projeto anfitrião.

Pode colocar todos os projetos de serviço numa pasta e definir esta política de permissão específica nesse nível da hierarquia. Isto permite que todos os projetos criados nessa pasta herdem as autorizações definidas na pasta na qual o projeto de serviço é criado.

{
  "bindings": [
    {
      "role": "roles/compute.networkUser",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/developers"
        ]
      },
      {
        "role": "roles/compute.instanceAdmin",
        "members": [
          "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/developers"
          ]
      }
    ]
}

Cada equipa pode gerir a sua própria rede

Um nativo digital quer dar às suas equipas de desenvolvimento a capacidade de trabalhar de forma autónoma. Não têm equipas de administração de TI centralizadas e confiam que as suas equipas gerem todos os aspetos dos respetivos projetos.

Apesar disso, também querem poder implementar alguns controlos flexíveis para lhes permitir adotar uma configuração mais formal à medida que crescem e o respetivo produto é lançado.

Para implementar este cenário, cada equipa de programadores tem a sua própria pasta atribuída. Esta estrutura garante que os projetos individuais criados na pasta herdam as autorizações adequadas, ao mesmo tempo que permite que cada equipa trabalhe de forma independente. Cada equipa deve continuar a seguir o princípio do menor privilégio quando define políticas de autorização para os seus próprios recursos.

Embora, inicialmente, sejam os mesmos membros da equipa a gerir os recursos de rede e os recursos reais nos projetos, a criação de grupos separados para as tarefas lógicas é uma prática recomendada.

Esta abordagem facilita a limitação do acesso aos recursos de que o pessoal temporário precisa ou pode ser pessoal novo que precisa de formação antes de poder modificar os recursos de rede. Também permite alterar quem tem acesso a que recursos sem ter de modificar a política de autorização sempre que ocorre uma alteração de pessoal.

Isto requer uma política de permissão associada à pasta atribuída a cada equipa.

{
  "bindings": [
    {
      "role": "roles/resourcemanager.foldersAdmin",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/devteamleads01",
        "serviceAccount:dev01-project-creator@shared-resources-proj.s3ns-system.iam.gserviceaccount.com"
        ]
    },
    {
      "role":"roles/resourcemanager.projectCreator",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/devteamleads01",
        "serviceAccount:dev01-project-creator@shared-resources-proj.s3ns-system.iam.gserviceaccount.com"
      ]
    },
    {
      "role": "roles/compute.securityAdmin",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/net-sec-dev01"
        ]
    },
    {
      "role": "roles/compute.networkAdmin",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/net-sec-dev01"
        ]
    },
    {
      "role": "roles/compute.instanceAdmin",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/dev01"
        ]
    },
    {
      "role": "roles/bigquery.admin",
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/dev01"
        ]
    }
  ]
}