Políticas de limite de acesso principal

As políticas de limite de acesso principal (PAB) permitem-lhe definir os recursos aos quais os principais podem aceder.

Por exemplo, pode usar políticas de limite de acesso principal para impedir que os seus principais acedam a recursos noutras organizações, o que pode ajudar a evitar ataques de phishing ou exfiltração de dados.

Para saber mais sobre os outros tipos de políticas de controlo de acesso que a Gestão de identidade e acesso (IAM) oferece, consulte o artigo Tipos de políticas.

Como funcionam as políticas de limite de acesso principal

Por predefinição, os principais são elegíveis para aceder a qualquer Trusted Cloud by S3NS recurso. Isto significa que, se um principal tiver uma autorização no recurso e essa autorização não lhe for negada, pode usar essa autorização para aceder ao recurso.

Com as políticas de limite de acesso principal, pode definir os recursos aos quais um principal é elegível para aceder. Se uma política de limite de acesso principal tornar um principal inelegível para aceder a um recurso, o respetivo acesso a esse recurso é limitado, independentemente das funções que lhe foram concedidas.

Quando os principais tentam aceder a recursos para os quais não são elegíveis, as políticas de limite de acesso principal podem bloquear algumas, mas não todas, as autorizações de gestão de identidade e de acesso (IAM). Para saber mais sobre as autorizações bloqueadas, consulte o artigo Autorizações que o limite de acesso principal pode bloquear.

As políticas de limite de acesso principal são compostas por regras de limite de acesso principal. Cada regra de limite de acesso principal define um conjunto de recursos aos quais os principais afetados são elegíveis para aceder. Pode criar até 1000 políticas de limite de acesso principal na sua organização.

Depois de criar uma política de limite de acesso principal, cria uma associação de políticas para aplicar a política a um conjunto de principais.

Um principal pode estar sujeito a uma ou mais políticas de limite de acesso principal. Cada principal só é elegível para aceder aos recursos indicados nessas políticas. Para todos os outros recursos, o acesso do principal a esse recurso é limitado, mesmo que atribua funções ao principal nesse recurso.

Uma vez que as políticas de limite de acesso principal estão associadas a principais e não a recursos, pode usá-las para impedir que os principais acedam a recursos que não lhe pertencem. Por exemplo, considere o seguinte cenário:

• O principal Tal (tal@example.com) faz parte da organização do Google Workspace example.com.
• A Tal tem a função de administrador do armazenamento (roles/storage.admin) num contentor do Cloud Storage numa organização diferente, cymbalgroup.com. Esta função contém a autorização storage.objects.get, que é necessária para ver objetos no contentor.
• Não existem políticas de negação em cymbalgroup.com que impeçam Tal de usar a autorização storage.objects.get.

Com apenas políticas de permissão e recusa, o example.com não pode impedir que o Tal veja objetos neste contentor externo. Nenhum principal example.com tem autorização para editar a política de autorização do contentor, pelo que não pode revogar a função de Tal. Também não têm autorização para criar políticas de recusa em cymbalgroup.com, pelo que não podem usar uma política de recusa para impedir que o Tal aceda ao contentor.

No entanto, com as políticas de limite de acesso principal, os example.com administradores podem garantir que o Tal não pode ver objetos no contentor cymbalgroup.com nem em nenhum contentor fora de example.com. Para tal, os administradores podem criar uma política de limite de acesso principal que indique que os principais example.com só são elegíveis para aceder a recursos em example.com. Em seguida, podem criar uma associação de políticas para anexar esta política a todos os responsáveis na organização example.com. Com esta política implementada, o Tal não vai poder ver objetos no contentor cymbalgroup.com, apesar de lhe ter sido concedido o papel de administrador de armazenamento no contentor.

Avaliação de falha fechada

As políticas de limite de acesso principal falham fechadas. Isto significa que, se o IAM não conseguir avaliar uma política de limite de acesso principal quando avaliar o acesso de um principal, o IAM impede que o principal aceda ao recurso.

O motivo mais comum pelo qual o IAM não consegue avaliar as políticas de limite de acesso do principal é o facto de os detalhes de um principal ainda estarem a propagar-se através do sistema. É mais provável que isto ocorra para utilizadores criados recentemente. Para resolver este problema, peça ao novo principal que aguarde e tente aceder ao recurso novamente mais tarde.

Autorizações que as políticas de limite de acesso da entidade de confiança bloqueiam

Quando os principais tentam aceder a um recurso ao qual não são elegíveis, as políticas de limite de acesso principal impedem-nos de usar algumas, mas não todas, as autorizações da gestão de identidade e de acesso (IAM) para aceder ao recurso.

Se uma política de limite de acesso principal bloquear uma autorização, o IAM aplica políticas de limite de acesso principal para essa autorização. Por outras palavras, impede que quaisquer responsáveis que não sejam elegíveis para aceder a um recurso usem essa autorização para aceder ao recurso.

Se uma política de limite de acesso principal não bloquear uma autorização, as políticas de limite de acesso principal não têm efeito sobre se os principais podem usar a autorização.

Por exemplo, imagine que a principal, Lee (lee@example.com), tem a função de programador do Dataflow (roles/dataflow.developer). Esta função inclui a autorização dataflow.jobs.snapshot, que permite a Lee tirar capturas de ecrã de tarefas do Dataflow. O Lee também está sujeito a uma política de limite de acesso principal que o torna inelegível para aceder a recursos fora de example.com. No entanto, se as políticas de limites de acesso principais não bloquearem a autorização dataflow.jobs.snapshot, Lee pode continuar a tirar capturas de ecrã de tarefas do Dataflow em organizações fora de example.com.

As autorizações que uma política de limite de acesso principal bloqueia dependem da versão de aplicação do limite de acesso principal.

Versões da aplicação do limite de acesso principal

Cada política de limite de acesso principal especifica uma versão de aplicação, que identifica uma lista predefinida de autorizações de IAM que a política de limite de acesso principal pode bloquear. Especifica a versão de aplicação quando cria ou atualiza uma política de limite de acesso principal. Se não especificar uma versão de aplicação, o IAM usa a versão de aplicação mais recente e continua a usá-la até a atualizar.

Periodicamente, o IAM adiciona novas versões de aplicação de limites de acesso de entidades que podem bloquear autorizações adicionais. Cada nova versão também pode bloquear todas as autorizações na versão anterior.

Para bloquear as autorizações numa nova versão de aplicação, tem de atualizar as suas políticas de limite de acesso principal para usar a nova versão. Se quiser que a versão de aplicação da política seja atualizada automaticamente à medida que são lançadas novas versões, pode usar o valor latest quando criar a política. No entanto, não recomendamos a utilização deste valor, uma vez que pode fazer com que os principais percam o acesso aos recursos inesperadamente.

Para ver uma lista completa das autorizações que cada versão de aplicação de políticas bloqueia, consulte o artigo Autorizações que as políticas de limite de acesso principal bloqueiam.

Associe políticas de limite de acesso principal a conjuntos de principais

Para associar uma política de limite de acesso principal a um conjunto de principais, cria uma associação de políticas que especifica a política de limite de acesso principal que quer aplicar e o conjunto de principais para o qual quer aplicá-la. Depois de associar a política a um conjunto de entidades, as entidades nesse conjunto de entidades só podem aceder aos recursos incluídos nas regras da política de limite de acesso de entidades.

Pode associar uma política de limite de acesso principal a qualquer número de conjuntos de principais. Cada conjunto de principais pode ter até 10 políticas de limite de acesso principal associadas.

Só pode criar associações para políticas de limite de acesso principal existentes. A tentativa de criar uma associação para uma política de limite de acesso principal eliminada falha. Se tiver eliminado recentemente uma política de limite de acesso principal, por vezes, pode criar uma associação com êxito, mas a associação não tem qualquer efeito. O IAM limpa estas associações automaticamente.

Para saber como gerir políticas de limites de acesso principais, consulte o artigo Crie e aplique políticas de limites de acesso principais.

Conjuntos de principais suportados

A tabela seguinte lista os tipos de conjuntos de principais aos quais pode associar políticas de limite de acesso principal. Cada linha contém o seguinte:

• O tipo de conjunto de principais
• Os principais nesse tipo de conjunto de principais
• O formato dos IDs desse tipo de conjunto de principais
• O recurso do Resource Manager (projeto, pasta ou organização) que é o principal dos bindings de políticas para esse tipo de conjunto principal

Associações de políticas condicionais para políticas de limite de acesso principal

Pode usar expressões de condição em associações de políticas para políticas de limite de acesso principal para refinar ainda mais os principais aos quais a política se aplica.

As expressões de condições para associações de políticas consistem em uma ou mais declarações unidas por até 10 operadores lógicos (&&, || ou !). Cada declaração expressa uma regra de controlo baseada em atributos que se aplica à associação de políticas e, em última análise, determina se a política se aplica.

Pode usar os atributos principal.type e principal.subject nas condições para associações de políticas. Não são suportados outros atributos nas condições para associações de políticas.

• O atributo principal.type indica que tipo de principal está no pedido, por exemplo, contas de serviço ou identidades num conjunto de identidades da carga de trabalho. Pode usar condições com este atributo para controlar a que tipos de responsáveis se aplica uma política de limite de acesso do responsável.

  Por exemplo, se adicionar a seguinte expressão de condição a uma associação para uma política de limite de acesso principal, a política aplica-se apenas a contas de serviço:

  principal.type == 'iam.googleapis.com/ServiceAccount'
  

• O atributo principal.subject indica a identidade do principal no pedido, por exemplo, cruz@example.com. Pode usar condições com este atributo para controlar exatamente que responsáveis estão sujeitos a uma política de limite de acesso de responsáveis.

  Por exemplo, se adicionar a seguinte expressão de condição a uma associação para uma política de limite de acesso principal, a política não se aplica ao utilizador special-admin@example.com:

  principal.subject != 'special-admin@example.com'
  

Para saber mais sobre os valores que pode usar para estas condições, consulte a referência do atributo de condições.

Exemplo: use condições para reduzir os recursos aos quais um principal é elegível para aceder

Uma das formas de usar condições em associações de políticas de limites de acesso principais é reduzir os recursos aos quais um único principal é elegível para aceder.

Imagine que tem uma conta de serviço, dev-project-service-account, com o endereço de email dev-project-service-account@dev-project.s3ns-system.iam.gserviceaccount.com. Esta conta de serviço está sujeita a uma política de limite de acesso principal que torna os principais elegíveis para aceder a todos os recursos na organização example.com. Esta política está anexada ao conjunto principal da organização example.com.

Decide que não quer que dev-project-service-account seja elegível para aceder a todos os recursos em example.com. Quer que seja elegível apenas para aceder a recursos em dev-project. No entanto, não quer alterar os recursos aos quais outros responsáveis no conjunto de responsáveis example.com são elegíveis para aceder.

Para fazer esta alteração, siga o procedimento para reduzir os recursos aos quais os diretores são elegíveis para aceder, mas adicione uma condição à associação da política em vez de a eliminar:

1. Confirma que a única política de limite de acesso principal a que o dev-project-service-account está sujeito é a política que torna os principais elegíveis para aceder a todos os recursos no example.com.

2. Cria uma nova política de limite de acesso principal que torna os principais elegíveis para aceder a recursos em dev-project e anexa-a ao conjunto de principais para dev-project. Use a seguinte condição na associação de políticas para garantir que a política só é aplicada a dev-project-service-account:

   "condition": {
     "title": "Only dev-project-service-account",
     "expression": "principal.type == 'iam.googleapis.com/ServiceAccount' && principal.subject == 'dev-project-service-account@dev-project.s3ns-system.iam.gserviceaccount.com'"
   }
   

3. Exime o dev-project-service-account da política de limite de acesso principal que torna os principais elegíveis para aceder a todos os recursos no example.com. Para o fazer, adicione a seguinte condição à associação de políticas que anexa essa política de limite de acesso principal ao conjunto de principais da organização:

   "condition": {
     "title": "Exempt dev-project-service-account",
     "expression": "principal.subject != 'dev-project-service-account@dev-project.s3ns-system.iam.gserviceaccount.com' || principal.type != 'iam.googleapis.com/ServiceAccount'"
   }
   

   Para saber como atualizar as políticas de limites de acesso principais existentes, consulte o artigo Edite as políticas de limites de acesso principais.

Depois de adicionar esta condição à associação de políticas, dev-project-service-account deixa de ser elegível para aceder a todos os recursos em example.com. Em alternativa, só é elegível para aceder a recursos em dev-project.

Associações de políticas entre organizações

Não pode criar uma associação de políticas entre organizações para uma política de limite de acesso principal. Uma associação de políticas entre organizações é uma associação de políticas que associa uma política numa organização a um conjunto de principais noutra organização.

O IAM elimina periodicamente todas as associações de políticas entre organizações existentes. As associações de políticas entre organizações podem ocorrer quando move um projeto de uma organização para outra. Por exemplo, considere a seguinte situação:

• Tem um projeto, example-project, na organização example.com.
• Quer que os principais em example-project sejam elegíveis para aceder a recursos em example.com. Para o fazer, crie uma política de limite de acesso principal em example.com que torne os principais elegíveis para aceder a recursos em example.com e associe essa política ao conjunto de principais para example-project.
• Move example-project de example.com para cymbalgroup.com.

Nesta situação, a movimentação do projeto criaria uma associação de políticas entre organizações. Isto deve-se ao facto de a política de limite de acesso principal em example.com estar associada a um conjunto de principais em cymbalgroup.com. Se não eliminar a associação manualmente, o IAM acaba por eliminá-la automaticamente. A eliminação desta associação ajuda a garantir que os administradores do cymbalgroup.com têm acesso a todas as políticas de limites de acesso principais associadas aos respetivos principais.

Interações com políticas

O IAM avalia cada política de limite de acesso principal em combinação com as suas políticas de permissão e negação, e com as suas outras políticas de limite de acesso principal. Todas estas políticas são usadas para determinar se um principal pode aceder a um recurso.

Interação com outros tipos de políticas

Quando um principal tenta aceder a um recurso, o IAM avalia todas as políticas de limite de acesso, de permissão e de negação relevantes do principal para ver se o principal tem permissão para aceder ao recurso. Se alguma destas políticas indicar que o principal não deve poder aceder ao recurso, o IAM impede o acesso.

Consequentemente, se uma política de limite de acesso principal impedir que um principal aceda a um recurso, o IAM impede que o principal aceda a esse recurso, independentemente das políticas de autorização e negação anexadas ao recurso.

Além disso, as políticas de limite de acesso principal por si só não concedem aos principais acesso aos recursos. Embora as políticas de limite de acesso principal possam tornar um principal elegível para aceder a um recurso, apenas as políticas de permissão podem conceder efetivamente ao principal acesso ao recurso.

Para saber mais sobre a avaliação de políticas de IAM, consulte o artigo Avaliação de políticas.

Interação entre políticas de limite de acesso principal

Se alguma política de limite de acesso principal tornar um principal elegível para aceder a um recurso, o principal é elegível para aceder a esse recurso, independentemente das outras políticas de limite de acesso principal às quais o principal está sujeito. Como resultado, se um principal já estiver sujeito a uma política de limite de acesso principal, não pode adicionar políticas de limite de acesso principal para reduzir o acesso de um principal.

Por exemplo, imagine que uma diretora, Daniela (dana@example.com), está sujeita a uma única política de limite de acesso do principal, prod-projects-policy. Esta política torna os principais elegíveis para aceder a recursos no prod-project. A Dana está sujeita a esta política porque está associada ao conjunto de principais da respetiva organização.

Cria uma nova política de limite de acesso principal, dev-staging-projects-policy, que torna os principais elegíveis para aceder a recursos em dev-project e staging-project e, em seguida, associa-a ao conjunto de principais da organização.

Como resultado destas políticas de limite de acesso principal, a Dana é elegível para aceder aos recursos em dev-project, staging-project e prod-project.

Se quiser reduzir os recursos aos quais a Dana é elegível para aceder, tem de modificar ou remover as políticas de limite de acesso principal às quais a Dana está sujeita.

Por exemplo, pode editar dev-staging-projects-policy para que não torne os principais elegíveis para aceder a recursos em dev-project. Em seguida, a Dana só seria elegível para aceder a recursos em staging-project e prod-project.

Em alternativa, pode remover prod-projects-policy eliminando a associação de políticas que a associa ao conjunto de principais da organização. Em seguida, a Dana só seria elegível para aceder a recursos no dev-project e staging-project.

No entanto, estas alterações não afetam apenas a Dana. Também afetam os outros principais sujeitos às políticas e às associações de limites de acesso principais modificadas. Se quiser reduzir os recursos aos quais um único principal é elegível para aceder, use associações de políticas condicionais.

Herança de políticas

As políticas de limite de acesso principal estão anexadas a conjuntos principais e não a recursos do Resource Manager. Como tal, não são herdadas através da hierarquia de recursos da mesma forma que as políticas de permissão e negação.

No entanto, os conjuntos de principais para recursos principais do Resource Manager, ou seja, pastas e organizações, incluem sempre todos os principais nos conjuntos de principais dos respetivos descendentes. Por exemplo, se um principal estiver incluído no conjunto de principais de um projeto, também está incluído nos conjuntos de principais de quaisquer pastas ou organizações principais.

Por exemplo, considere uma organização, example.com. Esta organização está associada ao domínio example.com e tem os seguintes recursos do Resource Manager:

• Uma organização, example.com
• Um projeto, project-1, que é um filho da organização
• Uma pasta, folder-a, que é secundária da organização
• Dois projetos, project-2 e project-3, que são secundários de folder-a

Os conjuntos de principais destes recursos contêm as seguintes identidades:

Como resultado, os seguintes principais são afetados pelas seguintes políticas de limite de acesso principal:

• Uma identidade do Google Workspace no domínio example.com está no conjunto de principais para example.com e será afetada pelas políticas de limite de acesso principal associadas a esse conjunto de principais.

• Uma conta de serviço no project-1 está nos conjuntos principais para project-1 e example.com e será afetada pelas políticas de limite de acesso principal associadas a qualquer um desses conjuntos principais.

• Uma conta de serviço em project-3 está nos conjuntos de entidades principais para project-3, folder-a e example.com, e será afetada pelas políticas de limites de acesso de entidades principais associadas a qualquer um desses conjuntos de entidades principais.

Políticas de limite de acesso principal e recursos em cache

Determinados Trusted Cloud by S3NS serviços armazenam em cache recursos visíveis publicamente. Por exemplo, o Cloud Storage coloca em cache objetos que são publicamente legíveis.

Se o limite de acesso principal pode impedir que os principais não elegíveis vejam um recurso visível publicamente depende de o recurso estar em cache:

• Se o recurso estiver em cache, o limite de acesso principal não pode impedir que os principais vejam o recurso
• Se o recurso não estiver em cache, o limite de acesso principal impede que os principais não elegíveis vejam o recurso

Em todos os casos, as políticas de limite de acesso principal impedem que os principais não elegíveis modifiquem ou eliminem recursos visíveis publicamente.

Estrutura de uma política de limite de acesso principal

Uma política de limite de acesso principal é uma coleção de metadados e detalhes da política de limite de acesso principal. Os metadados fornecem informações como o nome da política e quando a política foi criada. Os detalhes da política definem o que a política faz, por exemplo, os recursos aos quais os principais afetados são elegíveis para aceder.

Por exemplo, a seguinte política de limite de acesso principal torna os principais sujeitos à política elegíveis para aceder aos recursos na organização com o ID 0123456789012.

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "uid": "puid_0123456789012345678",
  "etag": "W/\"Gh/PcTdJD/AWHUhPW45kdw==\"",
  "displayName": "Example policy",
  "annotations": {
    "example-key": "example-value"
  },
  "createTime": "2024-01-02T15:01:23Z",
  "updateTime": "2024-01-02T15:01:23Z",
  "details": {
    "rules": [
      {
        "description": "Example principal access boundary policy rule",
        "resources": [
          "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

As secções seguintes descrevem os campos nos metadados e detalhes de uma política de limite de acesso principal.

Metadados

As políticas de limite de acesso principal contêm os seguintes metadados:

• name: O nome da política de limite de acesso principal. Este nome tem o formato organizations/ORGANIZATION_ID/locations/global/principalAccessBoundaryPolicies/PAB_POLICY_ID, em que ORGANIZATION_ID é o ID numérico da organização onde a política de limite de acesso principal foi criada e PAB_POLICY_ID é o ID alfanumérico da política de limite de acesso principal.
• uid: um ID exclusivo atribuído à política de limite de acesso principal.
• etag: um identificador do estado atual da política. Este valor é alterado quando atualiza a política. Para evitar atualizações em conflito, o valor de etag tem de corresponder ao valor armazenado no IAM. Se os valores de etag não corresponderem, o pedido falha.
• displayName: um nome legível para humanos para a política de limite de acesso principal.
• annotations: opcional. Uma lista de pares de chave-valor definidos pelo utilizador. Pode usar estas anotações para adicionar metadados adicionais à política, por exemplo, quem criou a política ou se a política foi implementada por um pipeline automatizado. Para mais informações sobre as anotações, consulte o artigo Anotações.
• createTime: a hora em que a política de limite de acesso principal foi criada.
• updateTime: a hora em que a política de limite de acesso principal foi atualizada pela última vez.

Detalhes

Cada política de limite de acesso principal contém um campo details. Este campo contém a versão de aplicação e as regras do limite de acesso principal:

• rules: Uma lista de regras de limite de acesso principal, que definem os recursos aos quais os principais afetados são elegíveis para aceder. Cada regra contém os seguintes campos:

  • description: uma descrição legível da regra.

  • resources: uma lista de recursos do Resource Manager (projetos, pastas e organizações) aos quais quer que os principais sejam elegíveis para aceder. Qualquer principal sujeito a esta política é elegível para aceder a estes recursos.

    Cada política de limite de acesso principal pode referenciar um máximo de 500 recursos em todas as regras na política.

  • effect: a relação que os principais têm com os recursos indicados no campo resources. O único efeito que pode especificar nas regras de limite de acesso principal é "ALLOW". Esta relação torna os principais elegíveis para aceder aos recursos indicados na regra.

• enforcementVersion: a versão de aplicação que o IAM usa quando aplica a política. A versão da política de limite de acesso principal determina as autorizações que a política de limite de acesso principal pode bloquear.

  Para mais informações sobre as versões da política de limite de acesso principal, consulte o artigo Versões de aplicação do limite de acesso principal nesta página.

Estrutura de uma associação de políticas

Uma associação de políticas para uma política de limite de acesso principal contém o nome de uma política, o nome do conjunto principal ao qual associar a política e metadados que descrevem a associação de políticas. Também pode conter condições que modificam os principais exatos aos quais a política se aplica.

Por exemplo, a seguinte associação de políticas associa a política example-policy a todos os principais na organização example.com, que tem o ID 0123456789012. A associação de políticas também contém uma condição que impede a aplicação da política para o principal super-admin@example.com.

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-policy-binding",
  "uid": "buid_01234567890123456789", 
  "etag": "W/\"cRMdDXbT82aLuZlvoL9Gqg==\"",
  "displayName": "Example policy binding",
  "annotations": {
    "example-key": "example-value"
  },
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "policyUid": "puid_0123456789012345678",
  "condition": {
    "title": "Exempt principal",
    "description": "Don't enforce the policy for super-admin@example.com",
    "expression": "principal.subject != 'super-admin@example.com'"
  },
  "createTime": "2024-01-02T17:00:16Z",
  "updateTime": "2024-01-02T17:00:16Z"
}

Cada associação de políticas contém os seguintes campos:

• name: o nome da associação de políticas. Este nome tem o formato RESOURCE_TYPE/RESOURCE_ID/locations/global/policyBindings/BINDING_ID, em que RESOURCE_TYPE/RESOURCE_ID é o tipo e o ID do recurso principal da associação de políticas e BINDING_ID é o ID alfanumérico da associação de políticas.
• uid: um ID exclusivo atribuído à associação de políticas.
• etag: um identificador do estado atual da política. Este valor é alterado quando atualiza a política. Para evitar atualizações em conflito, o valor de etag tem de corresponder ao valor armazenado no IAM. Se os valores de etag não corresponderem, o pedido falha.
• displayName: um nome legível para a associação de políticas.
• annotations: opcional. Uma lista de pares de chave-valor definidos pelo utilizador. Pode usar estas anotações para adicionar metadados adicionais à associação de políticas. Por exemplo, quem criou a associação de políticas ou se a associação de políticas foi implementada por um pipeline automatizado. Para mais informações sobre as anotações, consulte o artigo Anotações.

• target: o principal definido para associar a política. O valor tem o formato {"principalSet": PRINCIPAL_SET}, em que PRINCIPAL_SET é o ID do conjunto principal ao qual quer associar a política.

  Cada destino pode ter até 10 políticas associadas.

• policyKind: o tipo de política a que a associação de políticas faz referência. Para as associações de políticas de políticas de limite de acesso principal, este valor é sempre PRINCIPAL_ACCESS_BOUNDARY.

• policy: a política de limite de acesso principal a associar ao conjunto de principais de destino.

• policyUid: um ID exclusivo atribuído à política de limite de acesso principal referenciada no campo policy.

• condition: opcional. Uma expressão lógica que afeta os responsáveis pelos quais o IAM aplica a política. Se a condição for avaliada como verdadeira ou não puder ser avaliada, a gestão de identidades e acessos aplica a política ao principal que faz o pedido. Se a condição for avaliada como falsa, a gestão de identidade e de acesso não aplica a política ao principal. Para mais informações, consulte a secção Condições e limites de acesso principal nesta página.

• createTime: a hora em que a associação de políticas foi criada.

• updateTime: a hora em que a associação de políticas foi atualizada pela última vez.

Exemplos de utilização

Seguem-se situações comuns em que pode querer usar políticas de limite de acesso principal e exemplos de políticas de limite de acesso principal e associações de políticas que pode criar em cada situação. Para saber como criar políticas de limite de acesso principal e associá-las a conjuntos de principais, consulte o artigo Crie e aplique políticas de limite de acesso principal.

Tornar os principais elegíveis para acederem a recursos na sua organização

Pode usar uma política de limite de acesso principal para tornar os principais na sua organização elegíveis para aceder a recursos na sua organização. Se esta for a única política de limite de acesso principal à qual os principais na sua organização estão sujeitos, a política de limite de acesso principal também torna os principais na sua organização inelegíveis para aceder a recursos fora da sua organização.

Por exemplo, imagine que quer tornar todos os principais na organização example.com elegíveis para aceder a recursos em example.com e inelegíveis para aceder a recursos noutras organizações. Os principais que estão em example.com incluem todas as identidades no domínio example.com, todos os Workload Identity Pools em example.com e todas as contas de serviço e Workload Identity Pools em qualquer projeto em example.com.

Não tem políticas de limite de acesso principal que se apliquem a nenhum dos principais na sua organização. Como resultado, todos os diretores são elegíveis para aceder a todos os recursos.

Para tornar os principais elegíveis para aceder a recursos em example.com e inelegíveis para aceder a recursos fora de example.com, crie uma política de limite de acesso principal que torna os principais elegíveis para aceder a recursos em example.com:

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "displayName": "Boundary for principals in example.org",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example.org",
        "resources": [
            "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

Em seguida, crie uma associação de políticas para associar esta política ao conjunto de principais da organização:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only"
}

Quando associada ao conjunto de entidades empresariais da organização, esta política torna todas as entidades empresariais em example.com elegíveis para aceder a recursos em example.com. Uma vez que esta é a única política de limite de acesso principal à qual estes principais estão sujeitos, a política também torna os principais em example.com inelegíveis para aceder a recursos fora da sua organização. Isto significa que não podem usar autorizações bloqueadas pela política de limite de acesso principal para aceder a recursos fora de example.com, mesmo que tenham essas autorizações nesses recursos.

Tornar as contas de serviço elegíveis para recursos num único projeto

Pode criar uma política de limite de acesso principal para tornar as contas de serviço num projeto específico elegíveis para aceder a recursos nesse projeto.

Se esta for a única política de limite de acesso principal à qual as contas de serviço estão sujeitas, as contas de serviço só são elegíveis para aceder a recursos nesse projeto.

Por exemplo, imagine que tem um projeto, example-dev, com o número do projeto 901234567890. Quer garantir que as contas de serviço em example-dev só são elegíveis para aceder a recursos em example-dev.

Tem uma política de limite de acesso principal que torna todos os principais na sua organização, incluindo as contas de serviço em example-dev, elegíveis para aceder a recursos em example.com. Para ver o aspeto deste tipo de política, consulte o artigo Torne os principais elegíveis para aceder a recursos na sua organização.

Para tornar as contas de serviço em example-dev inelegíveis para aceder a recursos fora de example-dev, primeiro, crie uma política de limite de acesso principal que torne os principais elegíveis para aceder a recursos em example-dev

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "displayName": "Boundary for principals in example-dev",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example-dev",
        "resources": [
          "//cloudresourcemanager.googleapis.com/projects/example-dev"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

Em seguida, crie uma associação de políticas para associar esta política a todos os responsáveis em example-dev e adicione uma condição para que a associação de políticas se aplique apenas às contas de serviço:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-dev-only-binding",
  "displayName": "Bind policy to all service accounts in example-dev",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/projects/example-dev"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "condition": {
    "title": "Only service accounts",
    "description": "Only enforce the policy if the principal in the request is a service account",
    "expression": "principal.type == 'iam.googleapis.com/ServiceAccount'"
  }
}

No entanto, esta política por si só não altera os recursos aos quais as contas de serviço são elegíveis para aceder. Isto acontece porque existe uma política de limite de acesso principal que torna todos os principais em example.com elegíveis para aceder a todos os recursos em example.com. As políticas de limite de acesso principal são aditivas, pelo que as contas de serviço em example-dev continuam a ser elegíveis para aceder a todos os recursos em example.com.

Para garantir que as contas de serviço em example-dev só são elegíveis para aceder a recursos em example-dev, tem de adicionar uma condição à associação de políticas para a política de limite de acesso principal existente que impeça a respetiva aplicação às contas de serviço, incluindo as contas de serviço predefinidas, em example-dev:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "condition": {
    "title": "Exempt example-dev service accounts",
    "description": "Don't enforce the policy for service accounts in the example-dev project",
    "expression": "principal.type != 'iam.googleapis.com/ServiceAccount' || !principal.subject.endsWith('@example-dev.s3ns-system.iam.gserviceaccount.com') || !principal.subject == 'example-dev@appspot.s3ns-system.iam.gserviceaccount.com || !principal.subject == '901234567890-compute@developer.s3ns-system.iam.gserviceaccount.com'"
  }
}

Agora, as contas de serviço em example-dev só são elegíveis para aceder a recursos em example-dev. Os utilizadores são impedidos de usar autorizações bloqueadas pela política de limite de acesso principal para aceder a recursos fora de example-dev, mesmo que tenham essas autorizações nesses recursos.

Posteriormente, se quiser aumentar os recursos aos quais estas contas de serviço são elegíveis para aceder, pode adicionar recursos adicionais à política example-dev-only ou criar uma política de limite de acesso principal adicional e associá-la às contas de serviço.

O que se segue?

• Saiba como criar e aplicar políticas de limite de acesso principal.
• Reveja a autorização que cada versão da aplicação da política de limite de acesso principal bloqueia.