Pode conceder acesso a Trusted Cloud by S3NS recursos através de políticas de autorização, também conhecidas como políticas de gestão de identidade e de acesso (IAM), que são anexadas a recursos. Só pode anexar uma política de autorização a cada recurso. A política de autorização controla o acesso ao próprio recurso, bem como a todos os descendentes desse recurso que herdam a política de autorização.
Esta página mostra as políticas de permissão no formato JSON. Também pode usar a Google Cloud CLI para obter políticas de autorização no formato YAML.
Estrutura das políticas
Uma política de permissão é um conjunto de associações de funções e metadados. Uma associação de funções especifica o acesso que deve ser concedido a um recurso. Associa, ou associa, um ou mais diretores a uma única função do IAM e a quaisquer condições específicas do contexto que alteram como e quando a função é concedida. Os metadados incluem informações adicionais sobre a política de autorização, como um etag e uma versão para facilitar a gestão de políticas.
Cada associação de funções pode incluir os seguintes campos:
- Um ou mais principais, também conhecidos como membros ou identidades. Existem vários tipos de principais, incluindo utilizadores individuais, grupos de utilizadores e contas de serviço. Para ver uma lista completa dos tipos de principais suportados, consulte Tipos de principais.
- Uma função, que é uma coleção com nome de autorizações que permitem realizar ações em Trusted Cloud recursos.
Uma condição, que é uma expressão lógica opcional que restringe ainda mais a associação de funções com base em atributos sobre o pedido, como a sua origem ou o recurso de destino. Normalmente, as condições são usadas para controlar se o acesso é concedido com base no contexto de um pedido.
Se uma associação de funções contiver uma condição, é denominada associação de funções condicional.
Alguns Trusted Cloud serviços não aceitam condições em políticas de permissão. Para ver uma lista de serviços e tipos de recursos que aceitam condições, consulte o artigo Tipos de recursos que aceitam associações de funções condicionais.
As alterações ao acesso de um principal são eventualmente consistentes. Isto significa que as alterações de acesso demoram algum tempo a propagar-se através do sistema. Para saber quanto tempo, em média, demoram as alterações de acesso a propagar-se, consulte o artigo Propagação de alterações de acesso.
Limites em todos os responsáveis
Cada política de autorização pode conter até 1500 responsáveis.
Para efeitos deste limite, a IAM contabiliza todas as ocorrências de cada principal nas associações de funções da política de autorização, bem como os principais que a política de autorização isenta do registo de auditoria do acesso aos dados. Não remove duplicados de entidades de segurança que aparecem em mais do que uma associação de funções. Por exemplo, se uma política de permissão contiver apenas associações de funções para o principal principal://iam.googleapis.com/locations/global/workforcePools/my-pool/subject/my-user@example.com
e este principal aparecer em 50 associações de funções, pode adicionar mais 1450 principais às associações de funções na política de permissão.
Além disso, para efeitos deste limite, cada apresentação de um conjunto principal é contabilizada como um único principal, independentemente do número de membros individuais no conjunto.
Se usar condições de IAM ou conceder funções a muitos responsáveis com identificadores invulgarmente longos, o IAM pode permitir menos responsáveis na política de autorização.
Metadados de políticas
Os metadados de uma política de permissão incluem os seguintes campos:
- Um campo
etag
, que é usado para o controlo de simultaneidade e garante que as políticas de autorização são atualizadas de forma consistente. Para ver detalhes, consulte a secção Usar etags numa política nesta página. - Um campo
version
, que especifica a versão do esquema para uma determinada política de permissão. Para ver detalhes, consulte Versões das políticas nesta página.
Para organizações, pastas, projetos e contas de faturação, a política de permissão também pode conter um campo auditConfig
, que especifica os tipos de atividade que geram registos de auditoria para cada serviço. Para saber como configurar esta parte de uma política de permissão, consulte o artigo Configurar registos de auditoria de acesso a dados.
Usar etags numa política
Quando vários sistemas tentam escrever na mesma política de autorização ao mesmo tempo, existe o risco de esses sistemas substituírem as alterações uns dos outros. Este risco existe porque as políticas de permissão são atualizadas através do padrão read-modify-write, que envolve várias operações:
- Ler a política de permissão existente
- Modificar a política de permissão
- Escrever toda a política de autorização
Se o sistema A ler uma política de permissão e o sistema B escrever imediatamente uma versão atualizada dessa política de permissão, o sistema A não tem conhecimento das alterações do sistema B. Quando o sistema A escreve as suas próprias alterações na política de autorização, as alterações do sistema B podem ser perdidas.
Para ajudar a evitar este problema, o Identity and Access Management (IAM) suporta o controlo de simultaneidade através da utilização de um campo etag
na política de autorização. Todas as políticas de permissão contêm um campo etag
, e o valor deste campo muda sempre que uma política de permissão é atualizada. Se uma política de autorização contiver um campo etag
, mas não contiver associações de funções, a política de autorização não concede funções do IAM.
O campo etag
contém um valor como BwUjMhCsNvY=
. Quando atualizar a política de permissão, certifique-se de que inclui o campo etag
na política de permissão atualizada.
Se a política de permissão tiver sido modificada desde que a recuperou, o valor etag
não vai corresponder e a atualização vai falhar. Para a API REST, recebe o código de estado HTTP 409 Conflict
e o corpo da resposta é semelhante ao seguinte:
{
"error": {
"code": 409,
"message": "There were concurrent policy changes. Please retry the whole read-modify-write with exponential backoff.",
"status": "ABORTED"
}
}
Se receber este erro, repita toda a série de operações: leia novamente a política de permissão, modifique-a conforme necessário e escreva a política de permissão atualizada. Deve fazer novas tentativas automaticamente, com recuo exponencial, em todas as ferramentas que usa para gerir políticas de autorização.
Exemplo: política simples
Considere a seguinte política de autorização que associa um principal a uma função:
{
"bindings": [
{
"members": [
"principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/jie@example.com"
],
"role": "roles/owner"
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
No exemplo anterior, é concedido a Jie o papel básico de proprietário sem quaisquer condições. Esta função dá a Jie acesso quase ilimitado.
Exemplo: política com várias vinculações de funções
Considere a seguinte política de permissão que contém mais de uma associação de funções. Cada associação de funções concede uma função diferente:
{
"bindings": [
{
"members": [
"principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/jie@example.com"
],
"role": "roles/resourcemanager.organizationAdmin"
},
{
"members": [
"principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/raha@example.com",
"principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/jie@example.com"
],
"role": "roles/resourcemanager.projectCreator"
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
No exemplo anterior, a Jie recebe a função predefinida Organization
Admin (roles/resourcemanager.organizationAdmin
) na primeira associação de funções. Esta função contém autorizações para operações de organizações, pastas e projetos limitados. Na segunda associação de funções, tanto Jie como Raha têm a capacidade de criar projetos através da função de criador de projetos (roles/resourcemanager.projectCreator
). Em conjunto, estas associações de funções concedem acesso detalhado a Jie e Raha, e Jie tem mais acesso do que Raha.
Exemplo: política com associação de funções condicional
Considere a seguinte política de autorização, que associa os responsáveis a uma função predefinida e usa uma expressão de condição para restringir a associação de funções:
{
"bindings": [
{
"members": [
"principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/prod-dev",
"serviceAccount:prod-dev-example@appspot.s3ns-system.iam.gserviceaccount.com"
],
"role": "roles/appengine.deployer",
"condition": {
"title": "Expires_July_1_2022",
"description": "Expires on July 1, 2022",
"expression":
"request.time < timestamp('2022-07-01T00:00:00.000Z')"
}
}
],
"etag": "BwWKmjvelug=",
"version": 3
}
Neste exemplo, o campo version
está definido como 3
,
porque a política de permissão contém uma expressão de condição. A associação de funções na política de permissão é condicional; concede a função ao grupo prod-dev
e à conta de serviço prod-dev-example@appspot.s3ns-system.iam.gserviceaccount.com
, mas apenas até 1 de julho de 2022.
Para ver detalhes sobre as funcionalidades suportadas por cada versão da política de autorização, consulte a secção Versões da política nesta página.
Exemplo: política com associações de funções condicionais e incondicionais
Considere a seguinte política de permissão, que contém associações de funções condicionais e incondicionais para a mesma função:
{
"bindings": [
{
"members": [
"serviceAccount:prod-dev-example@appspot.s3ns-system.iam.gserviceaccount.com"
],
"role": "roles/appengine.deployer"
},
{
"members": [
"principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/prod-dev",
"serviceAccount:prod-dev-example@appspot.s3ns-system.iam.gserviceaccount.com"
],
"role": "roles/appengine.deployer",
"condition": {
"title": "Expires_July_1_2022",
"description": "Expires on July 1, 2022",
"expression":
"request.time < timestamp('2022-07-01T00:00:00.000Z')"
}
}
],
"etag": "BwWKmjvelug=",
"version": 3
}
Neste exemplo, a conta de serviço
serviceAccount:prod-dev-example@appspot.s3ns-system.iam.gserviceaccount.com
está incluída em duas associações de funções para a mesma função. A primeira associação de funções não tem uma condição. A segunda associação de funções tem uma condição que só concede a função até 1 de julho de 2022.
Efetivamente, esta política de permissão concede sempre a função à conta de serviço. No IAM, as associações de funções condicionais não substituem as associações de funções sem condições. Se um principal estiver associado a uma função e a associação de funções não tiver uma condição, o principal tem sempre essa função. Adicionar o principal a uma associação de funções condicional para a mesma função não tem efeito.
Por outro lado, o grupo prod-dev
só está incluído na associação de funções condicional. Por isso, tem a função apenas antes de 1 de julho de 2022.
Exemplo: política que associa uma função a um principal eliminado
Considere a seguinte política de permissão. Esta política de autorização associa uma função a uma conta
de serviço, serviceAccount:my-service-account@my-project.s3ns-system.iam.gserviceaccount.com
, que foi eliminada. Como resultado, o identificador da conta de serviço tem agora o prefixo deleted:
:
{
"bindings": [
{
"members": [
"deleted:serviceAccount:my-service-account@my-project.s3ns-system.iam.gserviceaccount.com?uid=123456789012345678901"
],
"role": "roles/owner"
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
Se criar uma nova conta de serviço com o mesmo nome, as vinculações de funções da política de autorização para a conta de serviço eliminada não se aplicam à nova conta de serviço. Este comportamento aplica-se a todos os tipos de responsáveis eliminados.
Este comportamento impede que novos responsáveis herdem funções concedidas a responsáveis eliminados. Se quiser conceder funções ao novo principal, adicione o novo principal às associações de funções da política de autorização, conforme mostrado em Políticas com principais eliminados nesta página.
Todos os principais eliminados têm o prefixo deleted:
. Alguns tipos de principais eliminados, como contas de serviço, também têm o sufixo ?uid=numeric-id
, em que numeric-id
é o ID numérico exclusivo do principal eliminado.
Neste exemplo, em vez de serviceAccount:serviceAccount:my-service-account@my-project.s3ns-system.iam.gserviceaccount.com
, a política de permissão mostra o identificador deleted:serviceAccount:my-service-account@my-project.s3ns-system.iam.gserviceaccount.com?uid=123456789012345678901
.
Políticas predefinidas
Todos os recursos que aceitam políticas de permissão são criados
com políticas de permissão predefinidas. As políticas de autorização predefinidas da maioria dos recursos estão vazias.
No entanto, as políticas de autorização predefinidas de alguns recursos contêm automaticamente determinadas associações de funções. Por exemplo, quando cria um novo projeto, a política de autorização do projeto tem automaticamente uma associação de funções que lhe concede a função de proprietário (roles/owner
) no projeto.
Estas associações de funções são criadas pelo sistema, pelo que o utilizador não precisa das autorizações getIamPolicy
nem setIamPolicy
no recurso para que as associações de funções sejam criadas.
Para saber se um recurso é criado com uma política de permissão, consulte a documentação do recurso.
Herança de políticas e hierarquia de recursos
Trusted Cloud Os recursos estão organizados hierarquicamente, em que o nó da organização é o nó raiz na hierarquia, seguido opcionalmente de pastas e, depois, projetos. A maioria dos outros recursos é criada e gerida num projeto. Cada recurso tem exatamente um principal, exceto a organização. A organização, como o nó raiz na hierarquia, não tem principal. Consulte o tópico Hierarquia de recursos para mais informações.
É importante ter em conta a hierarquia de recursos ao definir uma política de autorização. Quando define uma política de autorização a um nível superior na hierarquia, como ao nível da organização, da pasta ou do projeto, o âmbito de acesso concedido inclui o nível de recurso ao qual esta política de autorização está anexada e todos os recursos abaixo desse nível. Por exemplo, uma política de permissão definida ao nível da organização aplica-se à organização e a todos os recursos na organização. Da mesma forma, uma política de permissão definida ao nível do projeto aplica-se ao projeto e a todos os recursos no projeto.
A herança de políticas é o termo que descreve como as políticas de permissão se aplicam aos recursos abaixo do respetivo nível na hierarquia de recursos. A política em vigor é o termo que descreve como todas as políticas de permissão principais na hierarquia de recursos são herdadas para um recurso. É a união do seguinte:
- A política de permissão definida no recurso
- As políticas de permissão definidas em todos os níveis de recursos de hierarquia do recurso
Cada nova associação de funções (herdada de recursos principais) que afeta a política de permissão efetiva do recurso é avaliada de forma independente. Um pedido de acesso específico ao recurso é concedido se qualquer uma das associações de funções de nível superior conceder acesso ao pedido.
Se for introduzida uma nova associação de funções em qualquer nível da política de autorização herdada de um recurso, o âmbito da concessão de acesso aumenta.
Exemplo: herança de políticas
Para compreender a herança de políticas de autorização, considere um cenário em que concede a um utilizador, o João, duas funções do IAM diferentes em dois níveis diferentes na hierarquia de recursos.
Para conceder a Raha uma função ao nível da organização, defina a seguinte política de permissão na sua organização:
{
"bindings": [
{
"members": [
"principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/raha@example.com"
],
"role": "roles/storage.objectViewer"
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
Esta política de autorização concede à Raha a função de leitor de objetos de armazenamento (roles/storage.objectViewer
), que contém as autorizações get
e list
para projetos e objetos do Cloud Storage. Uma vez que definiu a política de permissão na sua organização, o Raha pode usar estas autorizações para todos os projetos e todos os objetos do Cloud Storage na sua organização.
Para conceder uma função a Raha ao nível do projeto, defina a seguinte política de autorização no projeto myproject-123
:
{
"bindings": [
{
"members": [
"principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/raha@example.com"
],
"role": "roles/storage.objectCreator"
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
Esta política de permissão concede à Raha a função de criador de objetos de armazenamento (roles/storage.objectCreator
), o que lhe permite criar objetos do Cloud Storage. Uma vez que definiu a política de permissão em myproject-123
, o Raha só pode criar objetos do Cloud Storage em myproject-123
.
Agora que existem duas associações de funções que concedem acesso a Raha aos objetos do Cloud Storage de destino em myproject-123
, aplicam-se as seguintes políticas de autorização:
- Uma política de autorização ao nível da organização concede a capacidade de listar e obter todos os objetos do Cloud Storage nesta organização.
- Uma política de permissão ao nível do projeto, para o projeto
myproject-123
, concede a capacidade de criar objetos nesse projeto.
A tabela seguinte resume a política eficaz da Raha:
Autorizações da função de leitor de objetos de armazenamento na organização | Autorizações da função de criador de objetos do Storage em `myproject-123` | Autorizações em vigor para Raha em `myproject-123` |
---|---|---|
resourcemanager.projects.get resourcemanager.projects.list storage.objects.get storage.objects.list |
resourcemanager.projects.get resourcemanager.projects.list storage.objects.create |
resourcemanager.projects.get resourcemanager.projects.list storage.objects.get storage.objects.list storage.objects.create |
Versões das políticas
Ao longo do tempo, o IAM pode adicionar novas funcionalidades que adicionam ou alteram significativamente os campos no esquema da política de autorização. Para evitar a interrupção das integrações existentes que dependem da consistência na estrutura da política de autorização, estas alterações são introduzidas em novas versões do esquema da política de autorização.
Se estiver a fazer a integração com o IAM pela primeira vez, recomendamos que use a versão do esquema da política de autorização mais recente disponível nesse momento. A secção seguinte aborda as diferentes versões disponíveis e como usar cada uma delas. Também descreve como especificar uma versão da política e aborda alguns cenários de resolução de problemas.
Todas as políticas de permissão existentes especificam um campo version
como parte dos metadados da política de permissão. Considere a parte realçada do seguinte exemplo:
{ "bindings": [ { "members": [ "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/jie@example.com" ], "role": "roles/owner" } ], "etag": "BwUjMhCsNvY=", "version": 1 }
Este campo especifica a versão do esquema de sintaxe da política de autorização. Cada versão da política de autorização contém um esquema de sintaxe específico que pode ser usado por associações de funções. A versão mais recente pode conter associações de funções com o esquema de sintaxe mais recente que não é suportado por versões anteriores. Este campo não se destina a ser usado para fins que não sejam o controlo do esquema de sintaxe da política de autorização.
Versões válidas das políticas
As políticas de permissão podem usar as seguintes versões de políticas de permissão:
Versão | Descrição |
---|---|
1 |
A primeira versão do esquema de sintaxe do IAM para políticas. Suporta a associação de uma função a um ou mais responsáveis. Não suporta associações de funções condicionais. |
2 |
Reservado para utilização interna. |
3 |
Apresenta o campo condition na associação de funções, que
restringe a associação de funções através de regras baseadas no contexto e em atributos. Para mais informações, consulte a
vista geral das condições
do IAM.
|
Especificar uma versão da política ao obter uma política
Para a API REST e as bibliotecas cliente, quando obtém uma política de autorização, recomendamos que especifique uma versão da política de autorização no pedido. Quando um pedido especifica uma versão da política de autorização, o IAM assume que o autor da chamada está ciente das funcionalidades nessa versão da política de autorização e pode processá-las corretamente.
Se o pedido não especificar uma versão da política de autorização, o IAM assume que o autor da chamada quer uma versão da política de autorização 1
.
Quando recebe uma política de autorização, o IAM verifica a versão da política de autorização no pedido ou a versão predefinida se o pedido não tiver especificado uma versão. O IAM também verifica a política de permissão para campos que não são suportados numa política de permissão da versão 1
. Utiliza estas informações para decidir que tipo de resposta enviar:
- Se a política de permissão não contiver condições, o IAM devolve sempre uma versão
1
da política de permissão, independentemente do número da versão no pedido. - Se a política de autorização contiver condições e o autor da chamada tiver pedido uma política de autorização
3
, o IAM devolve uma política de autorização3
que inclui as condições. Para ver um exemplo, consulte o cenário 1 nesta página. Se a política de permissão contiver condições e o autor da chamada tiver pedido uma versão
1
da política de permissão ou não tiver especificado uma versão, o IAM devolve uma política de permissão1
.Para associações de funções que incluem uma condição, o IAM anexa a string
_withcond_
ao nome da função, seguida de um valor hash; por exemplo,roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8
. A própria condição não está presente. Para ver um exemplo, consulte o cenário 2 nesta página.
Cenário 1: versão da política que suporta totalmente as condições do IAM
Suponhamos que chama o seguinte método da API REST para obter a política de autorização para um projeto:
POST https://cloudresourcemanager.s3nsapis.fr/v1/projects/project-id:getIamPolicy
O corpo do pedido contém o seguinte texto:
{
"options": {
"requestedPolicyVersion": 3
}
}
A resposta contém a política de autorização do projeto. Se a política de autorização contiver, pelo menos, uma associação de funções condicional, o respetivo campo version
é definido como 3
:
{
"bindings": [
{
"members": [
"principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/tal@example.com"
],
"role": "roles/iam.securityReviewer",
"condition": {
"title": "Expires_July_1_2022",
"description": "Expires on July 1, 2022",
"expression": "request.time < timestamp('2022-07-01T00:00:00.000Z')"
}
}
],
"etag": "BwWKmjvelug=",
"version": 3
}
Se a política de autorização não contiver associações de funções condicionais, o respetivo campo version
é definido como 1
, mesmo que o pedido tenha especificado a versão 3
:
{
"bindings": [
{
"members": [
"principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/tal@example.com"
],
"role": "roles/iam.securityReviewer",
}
],
"etag": "BwWKmjvelug=",
"version": 1
}
Cenário 2: versão da política com suporte limitado para condições do IAM
Suponhamos que chama o seguinte método da API REST para obter a política de autorização para um projeto:
POST https://cloudresourcemanager.s3nsapis.fr/v1/projects/project-id:getIamPolicy
O corpo do pedido está vazio; não especifica um número de versão. Como resultado,
o IAM usa a versão da política de autorização predefinida,
1
.
A política de permissão contém uma associação de funções condicional. Uma vez que a versão da política de permissão é 1
, a condição não aparece na resposta. Para indicar que a associação de funções usa uma condição, o IAM anexa a string _withcond_
ao nome da função, seguido de um valor hash:
{
"bindings": [
{
"members": [
"principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/tal@example.com"
],
"role": "roles/iam.securityReviewer_withcond_58e135cabb940ad9346c"
}
],
"etag": "BwWKmjvelug=",
"version": 1
}
Especificar uma versão da política ao definir uma política
Quando define uma política de autorização, recomendamos que especifique uma versão da política de autorização no pedido. Quando um pedido especifica uma versão da política de autorização, o IAM assume que o autor da chamada está ciente das funcionalidades nessa versão da política de autorização e pode processá-las corretamente.
Se o pedido não especificar uma versão da política de autorização, o IAM aceita apenas os campos que podem aparecer numa versão 1
da política de autorização. Como prática recomendada, não altere as associações de funções condicionais numa versão da política 1
allow, porque a política allow não mostra a condição para cada associação de funções. Por isso, não sabe quando nem onde a associação de funções é efetivamente concedida.
Em alternativa, obtenha a representação 3
da política de autorização, que mostra a condição para cada associação de funções, e use essa representação para atualizar as associações de funções.
Cenário: versões de políticas em pedidos e respostas
Suponhamos que usa a API REST para obter uma política de permissão e especifica a versão 3
no pedido. A resposta contém a seguinte política de permissão, que usa a versão 3
:
{
"bindings": [
{
"members": [
"principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/raha@example.com"
],
"role": "roles/storage.admin",
"condition": {
"title": "Weekday_access",
"description": "Monday thru Friday access only in America/Chicago",
"expression": "request.time.getDayOfWeek('America/Chicago') >= 1 && request.time.getDayOfWeek('America/Chicago') <= 5"
}
}
],
"etag": "BwUjMhCsNvY=",
"version": 3
}
Decide que a Rita deve ter a função de administrador do armazenamento (roles/storage.admin
) durante toda a semana e não apenas nos dias úteis. Remove a condição da associação de funções e envia um pedido da API REST para definir a política de permissão. Mais uma vez, especifica a versão 3
no pedido:
{
"bindings": [
{
"members": [
"principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/raha@example.com"
],
"role": "roles/storage.admin"
}
],
"etag": "BwUjMhCsNvY=",
"version": 3
}
A resposta contém a política de permissão atualizada:
{
"bindings": [
{
"members": [
"principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/raha@example.com"
],
"role": "roles/storage.admin"
}
],
"etag": "BwWd8I+ZUAQ=",
"version": 1
}
A política de permissão na resposta usa a versão 1
, embora o pedido tenha especificado a versão 3
, porque a política de permissão usa apenas campos suportados numa política de permissão 1
.
Políticas com responsáveis eliminados
Se uma associação de funções numa política de autorização incluir um principal eliminado e adicionar uma associação de funções para um novo principal com o mesmo nome, a associação de funções é sempre aplicada ao novo principal.
Por exemplo, considere esta política de autorização que inclui uma vinculação de funções para uma conta de serviço eliminada, my-service-account@project-id.s3ns-system.iam.gserviceaccount.com
. Como resultado, o identificador de cada conta de serviço tem o prefixo deleted:
:
{
"bindings": [
{
"members": [
"deleted:serviceAccount:my-service-account@project-id.s3ns-system.iam.gserviceaccount.com?uid=123456789012345678901"
],
"role": "roles/owner"
}
],
"etag": "BwUjMhCsNvY=",
"version": 1
}
Suponhamos que cria uma nova conta de serviço também denominada
my-service-account@project-id.s3ns-system.iam.gserviceaccount.com
e quer conceder-lhe a função de criador de projetos
(roles/resourcemanager.projectCreator
). Para conceder a função à nova conta de serviço, atualize a política de autorização conforme mostrado neste exemplo:
{ "bindings": [ { "members": [ "deleted:serviceAccount:my-service-account@project-id.s3ns-system.iam.gserviceaccount.com?uid=123456789012345678901" ], "role": "roles/owner" }, { "members": [ "serviceAccount:my-service-account@project-id.s3ns-system.iam.gserviceaccount.com" ], "role": "roles/resourcemanager.projectCreator" } ], "etag": "BwUjMhCsNvY=", "version": 1 }
Para facilitar a auditoria das suas políticas de autorização do IAM, também pode remover o utilizador eliminado da associação de funções à função de proprietário:
{ "bindings": [ { "members": [ "deleted:serviceAccount:my-service-account@project-id.s3ns-system.iam.gserviceaccount.com?uid=123456789012345678901" ], "role": "roles/owner" }, { "members": [ "user:donald@example.com" ], "role": "roles/resourcemanager.projectCreator" } ], "etag": "BwUjMhCsNvY=", "version": 1 }
Práticas recomendadas de políticas
As seguintes práticas recomendadas aplicam-se a organizações com muitos Trusted Cloud utilizadores:
Quando gerir vários responsáveis com as mesmas configurações de acesso, use grupos. Coloque cada principal individual no grupo e conceda as funções pretendidas ao grupo em vez de aos principais das contas de utilizador individuais.
Funções concedidas ao nível da organização: considere cuidadosamente a que principais são concedidas funções ao nível da organização. Para a maioria das organizações, apenas algumas equipas específicas, como as equipas de segurança e de rede, devem ter acesso a este nível da hierarquia de recursos.
Funções concedidas ao nível das pastas: pondere refletir a estrutura de funcionamento da sua organização através de níveis de pastas, em que cada pasta pode ser configurada com diferentes conjuntos de concessões de acesso alinhados com as necessidades empresariais e de funcionamento. Por exemplo, uma pasta principal pode refletir um departamento, uma das respetivas pastas secundárias pode refletir o acesso e a operação de recursos por um grupo e outra pasta secundária pode refletir uma pequena equipa. Ambas as pastas podem conter projetos para as necessidades de funcionamento da equipa. A utilização de pastas desta forma pode garantir a separação adequada do acesso, ao mesmo tempo que respeita as políticas de permissão herdadas das pastas principais e da organização. Esta prática requer menos manutenção das políticas de autorização quando cria e gere recursos Trusted Cloud .
Funções concedidas ao nível do projeto: conceda associações de funções ao nível do projeto quando necessário para seguir o princípio do menor privilégio. Por exemplo, se um principal precisar de acesso a 3 dos 10 projetos numa pasta, deve conceder acesso a cada um dos 3 projetos individualmente. Em contrapartida, se concedesse uma função na pasta, o principal obteria acesso de que não precisa a outros 7 projetos.
Em alternativa, pode usar as condições da IAM para conceder funções ao nível da organização ou da pasta, mas apenas para um subconjunto de pastas ou projetos.
Conceda acesso apenas a responsáveis no seu domínio: para melhorar a segurança da sua organização, não conceda funções a responsáveis fora do seu domínio. Pode aplicar esta prática recomendada aplicando a restrição da política da organização
iam.allowedPolicyMemberDomains
.
O que se segue?
- Saiba como
resolver problemas de políticas de permissão que contêm a string
withcond
nos nomes das funções. - Saiba como gerir as associações de funções numa política de permissão.
- Veja uma vista geral das condições de IAM, que usam a versão
3
de políticas de autorização.