Neste tópico, mostramos como configurar as permissões do gerenciamento de identidade e acesso (IAM, na sigla em inglês) para cenários de rede. Fornecemos orientação sobre quais papéis do 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. Os cenários descritos abaixo pressupõem que uma organização do Google Cloud está configurada.
Neste documento, não há explicações detalhadas sobre papéis e permissões de rede. Veja uma descrição detalhada dos papéis e permissões associados às APIs de computação e rede em Papéis predefinidos do 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.
As tabelas abaixo explicam os papéis do IAM que precisam ser concedidos à equipe de segurança e administração e à equipe de desenvolvimento, além do nível de recurso em que os papéis são concedidos.
| Recurso: | Organização | |
|---|---|---|
| Papéis: | Administrador de VPC compartilhada Administrador de rede Administrador de segurança |
|
| Principal: | 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 | |
| Principal: | 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 | |
| Principal: | Desenvolvedores |
Nesse cenário, você precisa de três políticas de permissão separadas: uma para a organização, uma para o projeto host e uma para os projetos de serviço.
A primeira política de permissão, que precisa ser anexada no nível da organização, concede à equipe de rede e segurança os papéis necessários para administrar projetos de host de VPC compartilhada. 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 de permissão 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 de permissão 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 principais. No exemplo acima, você adicionaria os IDs dos usuários que gerenciam os controles de segurança e de rede ao Grupo sec-net e os desenvolvedores ao Grupo developers.
Quando é necessário modificar quem pode executar cada papel, basta ajustar a associação ao grupo. Ou seja, não é preciso atualizar a política de permissão.
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.
Veja nas tabelas abaixo os papéis de permissão que precisam ser concedidos à equipe de segurança e administração e à equipe de desenvolvimento, além do nível de recurso em que os papéis são concedidos.
| Recurso: | Organização | |
|---|---|---|
| Papéis: | Administrador de VPC compartilhada Administrador de rede |
|
| Principal: | Equipe de administração de rede |
| Recurso: | Organização | |
|---|---|---|
| Papéis: | Administrador de segurança Administrador da organização |
|
| Principal: | 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 | |
| Principal: | 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 | |
| Principal: | Desenvolvedores |
Nesse cenário, você precisa de três políticas de permissão separadas: uma para a organização, uma para o projeto host e uma para os projetos de serviço.
A primeira política de permissão, que precisa ser anexada no nível da organização, concede à equipe de rede os papéis necessários para administrar projetos host de VPC compartilhada e gerenciar todos os recursos 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 visualizar, mas não modificar, as regras de firewall. Além disso, com essa política, a equipe de segurança define as políticas de permissão 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 de permissão precisa estar associada ao projeto host. Essa política permite que os desenvolvedores da organização usem as redes compartilhadas no projeto host da VPC compartilhada.
{
"bindings": [
{
"role": "roles/compute.networkUser",
"members": [
"group:developers@example.com"
]
}
]
}
A terceira política de permissão 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 implementar esse cenário, cada equipe de desenvolvedores recebe uma pasta própria. Essa estrutura garante que os projetos individuais criados na pasta herdem as permissões apropriadas, permitindo que cada equipe trabalhe de forma independente. Cada equipe ainda deve seguir o princípio do menor privilégio ao definir políticas de permissão para os próprios recursos.
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. Ele também permite alterar os acessos aos recursos sem precisar modificar a política de permissão sempre que ocorrer 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 do projeto Administrador de pastas |
|
| Principal: | Líderes de equipe de desenvolvimento Conta de serviço |
| Recurso: | Pasta | |
|---|---|---|
| Papéis: | Administrador de rede Administrador de segurança |
|
| Principal: | 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 |
|
| Principal: | Desenvolvedores |
Isso requer uma política de permissão 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"
]
}
]
}