Políticas de limite de acesso principal

As políticas de limite de acesso de principal (PAB) permitem definir os recursos que os principais podem acessar.

Outras políticas relacionadas ao acesso, como políticas de permissão e negação, são anexadas aos recursos. Essas políticas definem quem pode acessar o recurso a que estão vinculadas. Já as políticas de limite de acesso de principal são anexadas a conjuntos de principais e controlam o que os principais no conjunto podem fazer.

Por exemplo, é possível usar políticas de limite de acesso principal para impedir que seus principais acessem recursos em outras organizações, o que ajuda a evitar ataques de phishing ou exfiltração de dados.

Como funcionam as políticas de limite de acesso principal

Por padrão, os principais podem acessar qualquer recurso Cloud de Confiance by S3NS . Isso significa que, se uma política de permissão conceder a um principal acesso a um recurso e nenhuma política de negação bloquear esse acesso, o principal poderá acessar o recurso.

Com as políticas de limite de acesso de principal, é possível definir os recursos que um principal pode acessar. Se um principal não puder acessar um recurso, o acesso a ele será limitado, independentemente das funções concedidas. Para mais informações sobre como usar políticas de limite de acesso de principal para definir os recursos que um principal pode acessar, consulte Definir recursos qualificados.

As políticas de limite de acesso principal bloqueiam apenas tentativas de acesso que envolvem permissões compatíveis. Se uma política de limite de acesso principal não puder bloquear uma permissão, os principais poderão usar essa permissão para acessar qualquer recurso, independentemente das políticas a que estão sujeitos. Para mais informações, consulte Permissões que as políticas de limite de acesso de principal podem bloquear.

Casos de uso

As políticas de limite de acesso principal são úteis em circunstâncias como as seguintes:

• Impedir que principais acessem recursos que não são seus
• Manter determinados tipos de principais, como contas de serviço, limitados a determinados projetos

Para exemplos detalhados de como usar políticas de limite de acesso de principal em situações como essas, consulte Exemplos de casos de uso de políticas de limite de acesso de principal.

Componentes da política de limite de acesso principal

As políticas de limite de acesso de principal consistem em regras individuais. Cada regra define um conjunto de recursos que os principais podem acessar. Cada política pode ter até 500 regras.

As políticas também contêm outras informações, incluindo metadados e detalhes de configuração. Para mais informações, consulte Estrutura de uma política de limite de acesso de principal.

Depois de criar uma política de limite de acesso de principal, aplique essa política a conjuntos de principais criando vinculações de política. Todos os principais nesses conjuntos de principais estão sujeitos a essa política de limite de acesso de principal, o que significa que eles podem acessar os recursos listados na política. É possível vincular uma política de limite de acesso de principal a qualquer número de conjuntos de principais.

É possível criar até mil políticas de limite de acesso de principal na sua organização.

Permissões bloqueadas pelas políticas de limite de acesso principal

As políticas de limite de acesso de principal podem bloquear todas as permissões incluídas na versão de aplicação da política. Se uma política de limite de acesso de principal puder bloquear uma permissão, ela poderá impedir que principais inelegíveis usem essa permissão para acessar recursos.

Você especifica a versão de aplicação de uma política ao criá-la. Atualizar a versão de aplicação atualiza as permissões que a política pode bloquear. Para uma lista completa das permissões bloqueadas por cada versão de aplicação, consulte a referência de versão de aplicação.

Se uma política de limite de acesso de principal não puder bloquear uma permissão, ela não terá efeito sobre a possibilidade de os principais usarem a permissão. Em outras palavras, o IAM não pode aplicar a política para tentativas de acesso que envolvem essa permissão.

Por exemplo, imagine que um principal, Lee (lee@example.com), receba o papel de desenvolvedor do Dataflow (roles/dataflow.developer). Esse papel inclui a permissão dataflow.googleapis.com/jobs.snapshot, que permite que Lee faça snapshots de jobs do Dataflow. Lee também está sujeito a uma política de limite de acesso de principal que o impede de acessar recursos fora de example.com. No entanto, se essa política de limite de acesso principal não puder bloquear a permissão dataflow.jobs.snapshot, Lee ainda poderá criar snapshots de jobs do Dataflow em organizações fora de example.com.

Gerenciar versões de restrição

Periodicamente, o IAM adiciona novas versões de aplicação que podem bloquear permissões adicionais. Cada nova versão também pode bloquear todas as permissões da versão anterior.

Para bloquear as permissões em uma nova versão de aplicação, atualize suas políticas de limite de acesso de principal para usar a nova versão.

Se você quiser que a versão de aplicação de uma política seja atualizada automaticamente à medida que novas versões forem lançadas, use o valor latest ao criar a política. No entanto, não recomendamos usar esse valor, porque ele pode fazer com que os principais percam o acesso aos recursos inesperadamente.

As políticas que usam latest para o número da versão usam a versão de aplicação padrão. A versão de aplicação padrão geralmente é a mais recente. No entanto, pode levar até quatro semanas para que uma nova versão se torne a versão de aplicação padrão. Para saber qual versão de restrição é a padrão, consulte a referência de versão de restrição.

A versão de aplicação padrão também é usada para novas políticas de limite de acesso de principal que não especificam um número de versão.

Definir recursos qualificados

Os principais podem ser afetados ou sujeitos a qualquer número de políticas de limite de acesso de principal. Juntas, essas políticas definem os recursos que o principal pode acessar.

As políticas de limite de acesso de principal são complementares. Isso significa que os recursos que um principal pode acessar são a união de todos os recursos em todas as políticas de limite de acesso de principal a que ele está sujeito. Em outras palavras, se uma única política de limite de acesso de principal qualificar um principal para acessar um recurso, ele poderá acessar o recurso, independentemente das outras políticas de limite de acesso de principal a que estiver sujeito.

Se um principal não estiver sujeito a nenhuma política de limite de acesso de principal, ele poderá acessar qualquer recurso do Cloud de Confiance .

As seções a seguir descrevem como personalizar o conjunto de recursos a que um principal pode acessar.

Adicionar recursos qualificados

Há várias maneiras de tornar uma principal qualificada para acessar um recurso que ela não pode acessar:

• Adicione o recurso a uma política de limite de acesso de principal a que o principal está sujeito.
• Crie uma política de limite de acesso de principal com o recurso adicional e vincule a política a um conjunto de principais que inclua o principal.
• Remova ou exclua todas as políticas de limite de acesso de principal a que o principal está sujeito. Essa ação torna o principal qualificado para acessar todos os recursos do Cloud de Confiance .

Remover recursos qualificados

Há várias maneiras de impedir que uma principal acesse um recurso que ela pode acessar.

Primeiro, encontre todas as políticas de limite de acesso de principal a que o principal está sujeito e que incluem o recurso. Com base nas políticas encontradas, você pode fazer uma das seguintes ações:

• Se o principal não estiver sujeito a nenhuma política de limite de acesso de principal, crie uma nova política de limite de acesso de principal que inclua apenas os recursos que você quer que o principal possa acessar. Em seguida, vincule essa política a um conjunto de principais que contenha o principal.

  Depois de aplicar a política, o principal passa de qualificado para acessar todos os recursos a qualificado para acessar apenas os recursos listados na política.

• Se o principal já estiver sujeito a uma ou mais políticas de limite de acesso de principal, verifique se nenhuma delas inclui o recurso. Para instruções detalhadas, consulte Reduzir os recursos que os principais podem acessar.

  Durante esse processo, verifique se o principal está sempre sujeito a pelo menos uma política de limite de acesso de principal. Caso contrário, o principal poderá se qualificar para acessar todos os recursos.

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

Alguns serviços Cloud de Confiance by S3NS armazenam em cache recursos visíveis publicamente. Por exemplo, o Cloud Storage armazena em cache objetos que são publicamente legíveis.

Se uma política de limite de acesso de principal pode impedir que principais inelegíveis vejam um recurso visível publicamente depende de se o recurso está em cache:

• Se o recurso estiver em cache, as políticas de limite de acesso de principal não poderão impedir que os principais vejam o recurso.
• Se o recurso não estiver em cache, o limite de acesso de principal impede que principais não qualificados vejam o recurso.

Em todos os casos, as políticas de limite de acesso de principal ainda impedem que principais inelegíveis modifiquem ou excluam recursos visíveis publicamente.

Avaliação da política de limite de acesso principal

Quando um principal tenta acessar um recurso, o IAM avalia as políticas relevantes de limite de acesso de principal para determinar se o acesso deve ser bloqueado. Uma política é relevante se o principal que está tentando acessar estiver sujeito a ela.

As políticas de limite de acesso de principal só podem bloquear ou não bloquear o acesso. Elas não podem conceder acesso. Somente as políticas de permissão podem conceder acesso aos recursos para os principais. Para saber como diferentes tipos de políticas afetam o acesso dos principais aos recursos, consulte Tipos de políticas.

O IAM não bloqueia o acesso se alguma das seguintes condições for verdadeira:

• O principal não está sujeito a nenhuma política de limite de acesso de principal
• As políticas de limite de acesso de principal relevantes não podem bloquear a permissão na solicitação.
• Uma política de limite de acesso de principal qualifica o principal para acessar o recurso.

O IAM bloqueia o acesso se o principal estiver sujeito a pelo menos uma política de limite de acesso do principal, mas nenhuma das políticas relevantes o qualifica para acessar o recurso.

Avaliação de falha ao fechar

As políticas de limite de acesso principal falham ao serem fechadas. Isso significa que, se o IAM encontrar um erro ao avaliar uma política de limite de acesso de principal, ele vai impedir que o principal acesse o recurso.

O motivo mais comum para o IAM encontrar um erro ao avaliar políticas de limite de acesso de principal é que os detalhes de um principal ainda estão sendo propagados pelo sistema. Isso provavelmente vai acontecer com usuários recém-criados. Para resolver esse problema, peça para o novo principal aguardar e tentar acessar o recurso novamente mais tarde.

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

Para aplicar uma política de limite de acesso de principal a um conjunto de principais, crie uma vinculação de política que especifique a política de limite de acesso de principal que você quer aplicar e o conjunto de principais a que ela será aplicada. Essa vinculação de política associa a política ao conjunto de principais.

Depois de vincular uma política a um conjunto de principais, eles só poderão acessar os recursos listados nas políticas de limite de acesso de principal a que estão sujeitos.

É possível vincular uma política de limite de acesso de principal a qualquer número de conjuntos de principais. Cada conjunto de principais pode ter até 10 políticas de limite de acesso de principal vinculadas a ele.

Só é possível criar vinculações para políticas de limite de acesso de principal atuais. A tentativa de criar uma vinculação para uma política de limite de acesso de principal excluída vai falhar. Se você excluiu recentemente uma política de limite de acesso principal, às vezes é possível criar uma vinculação, mas ela não terá efeito. O IAM limpa essas vinculações automaticamente.

Para saber como gerenciar políticas de limite de acesso de principal, consulte Criar e aplicar políticas de limite de acesso de principal.

Conjuntos principais compatíveis

A tabela a seguir lista os tipos de conjuntos principais a que é possível vincular políticas de limite de acesso principal. Cada linha contém o seguinte:

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

Herança de políticas e conjuntos de principais

As políticas de limite de acesso principal são anexadas a conjuntos de principais, não a recursos. Como resultado, elas não são herdadas pela hierarquia de recursos da mesma forma que as políticas de permissão e negação.

No entanto, os conjuntos de principais para pastas e organizações sempre incluem todos os principais nos conjuntos de principais dos descendentes. Por exemplo, se um principal estiver incluído no conjunto de principais de um projeto, ele também será incluído nos conjuntos de principais de pastas ou organizações pai.

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

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

Os conjuntos principais desses recursos contêm as seguintes identidades:

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

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

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

• Uma identidade de agente em project-3 está nos conjuntos de principais para project-3, folder-a e example.com, e será afetada por políticas de limite de acesso de principal vinculadas a qualquer um desses conjuntos.

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

É possível usar expressões de condição em vinculações de políticas para políticas de limite de acesso de principal para refinar ainda mais a quais principais a política se aplica.

As expressões condicionais para vinculações de políticas consistem em uma ou mais instruções unidas por até 10 operadores lógicos (&&, || ou !). Cada instrução expressa uma regra de controle baseada em atributo que se aplica à vinculação de políticas e, por fim, determina se a política é aplicável.

É possível usar os atributos principal.type e principal.subject em condições para vinculações de políticas. Nenhum outro atributo é compatível.

• O atributo principal.type se refere ao tipo do principal que fez a solicitação, por exemplo, uma conta de serviço ou uma identidade de agente. É possível usar condições com esse atributo para controlar a quais tipos de principais uma política de limite de acesso de principal se aplica.

  Por exemplo, se você adicionar a seguinte expressão de condição a uma vinculação para uma política de limite de acesso principal, a política será aplicada apenas a contas de serviço:

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

• O atributo principal.subject se refere à identidade do principal que fez a solicitação, por exemplo, cruz@example.com. É possível usar condições com esse atributo para controlar exatamente quais principais estão sujeitos a uma política de limite de acesso de principal.

  Por exemplo, se você adicionar a seguinte expressão de condição a uma vinculação para uma política de limite de acesso de principal, a política não será aplicada ao usuário special-admin@example.com:

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

Para saber mais sobre os valores que podem ser usados nessas condições, consulte a referência do atributo de condições.

Para um exemplo de como usar essas condições nas políticas de limite de acesso principal, consulte Tornar as contas de serviço qualificadas para acessar recursos em um único projeto.

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

Não é possível criar uma vinculação de política entre organizações para uma política de limite de acesso de principal. Uma vinculação de política entre organizações é uma vinculação que associa uma política em uma organização a um conjunto de principais em outra.

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

• Você tem um projeto, example-project, na organização example.com.
• Você quer que os principais em example-project possam acessar recursos em example.com. Para fazer isso, crie uma política de limite de acesso principal em example.com que qualifique os principais para acessar recursos em example.com e vincule essa política ao conjunto de principais para example-project.
• Você move example-project de example.com para cymbalgroup.com.

Nessa situação, a movimentação do projeto cria uma vinculação de política entre organizações. Isso acontece porque a política de limite de acesso de principal em example.com está vinculada a um conjunto de principais em cymbalgroup.com. Se você não excluir a vinculação manualmente, o IAM vai fazer isso automaticamente. A exclusão dessa vinculação ajuda a garantir que os administradores do cymbalgroup.com tenham acesso a todas as políticas de limite de acesso de principal vinculadas aos principais deles.

Estrutura de uma política de limite de acesso de principal

Uma política de limite de acesso principal é um conjunto 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 ela foi criada. Os detalhes da política definem o que ela faz, por exemplo, os recursos que os principais afetados podem acessar.

Por exemplo, a política de limite de acesso de principal a seguir permite que os principais sujeitos a ela acessem os 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": "4"
  }
}

As seções a seguir descrevem os campos nos metadados e detalhes de uma política de limite de acesso de 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 de principal. Esse nome tem o formato organizations/ORGANIZATION_ID/locations/global/principalAccessBoundaryPolicies/PAB_POLICY_ID, em que ORGANIZATION_ID é o ID numérico da organização em que a política de limite de acesso de principal foi criada e PAB_POLICY_ID é o ID alfanumérico da política de limite de acesso de principal.
• uid: um ID exclusivo atribuído à política de limite de acesso de principal.
• etag: um identificador do estado atual da política. Esse valor muda quando você atualiza a política. Para evitar atualizações conflitantes, o valor etag precisa corresponder ao valor armazenado no IAM. Se os valores de etag não corresponderem, a solicitação falhará.
• displayName: um nome legível para a política de limite de acesso de principal.
• annotations: opcional. Uma lista de pares de chave-valor definidos pelo usuário. É possível usar essas anotações para adicionar metadados extras à política, por exemplo, quem criou a política ou se ela foi implantada por um pipeline automatizado. Para mais informações sobre anotações, consulte Anotações.
• createTime: o horário em que a política de limite de acesso de principal foi criada.
• updateTime: a última vez que a política de limite de acesso de principal foi atualizada.

Detalhes

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

• rules: uma lista de regras de limite de acesso de principal, que definem os recursos que os principais afetados podem acessar. 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) que você quer que os principais usuários tenham acesso. Qualquer principal sujeita a essa política pode acessar esses recursos.

    Cada política de limite de acesso de principal pode se referir a no máximo 500 recursos em todas as regras da política.

  • effect: a relação que os principais têm com os recursos listados no campo resources. O único efeito que pode ser especificado nas regras de limite de acesso de principal é "ALLOW". Essa relação torna os principais qualificados para acessar os recursos listados na regra.

• enforcementVersion: a versão de aplicação que o IAM usa ao aplicar a política. A versão da política de limite de acesso de principal determina quais permissões ela pode bloquear.

  Para mais informações sobre como definir e gerenciar versões de restrição, consulte Gerenciar versões de restrição nesta página.

Estrutura de uma vinculação de política

Uma vinculação de política para uma política de limite de acesso principal contém o nome de uma política, o nome do conjunto de principais a que a política será vinculada e metadados que descrevem a vinculação. Ela também pode conter condições que modificam os principais exatos a que a política se aplica.

Por exemplo, a vinculação de política a seguir vincula a política example-policy a todos os principais na organização example.com, que tem o ID 0123456789012. A vinculação de política também contém uma condição que impede a aplicação da política ao 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 vinculação de política contém os seguintes campos:

• name: o nome da vinculação de política. Esse nome tem o formato RESOURCE_TYPE/RESOURCE_ID/locations/global/policyBindings/BINDING_ID, em que RESOURCE_TYPE/RESOURCE_ID é o tipo e ID do recurso principal da vinculação de política e BINDING_ID é o ID alfanumérico da vinculação de política.
• uid: um ID exclusivo atribuído à vinculação de política.
• etag: um identificador do estado atual da política. Esse valor muda quando você atualiza a política. Para evitar atualizações conflitantes, o valor etag precisa corresponder ao valor armazenado no IAM. Se os valores de etag não corresponderem, a solicitação falhará.
• displayName: um nome legível para a vinculação de política.
• annotations: opcional. Uma lista de pares de chave-valor definidos pelo usuário. É possível usar essas anotações para adicionar metadados extras à vinculação de política. Por exemplo, quem criou a vinculação ou se ela foi implantada por um pipeline automatizado. Para mais informações sobre anotações, consulte Anotações.

• target: o principal definido para vincular a política. O valor tem o formato {"principalSet": PRINCIPAL_SET}, em que PRINCIPAL_SET é o ID do conjunto de principais a que você quer vincular a política.

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

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

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

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

• condition: opcional. Uma expressão lógica que afeta para quais principais o IAM aplica a política. Se a condição for avaliada como "true" ou não puder ser avaliada, o Identity and Access Management vai aplicar a política ao principal que fez a solicitação. Se a condição for avaliada como falsa, o Identity and Access Management não vai aplicar a política ao principal. Para mais informações, consulte Limite de acesso de principal e condições nesta página.

• createTime: o horário em que a vinculação de política foi criada.

• updateTime: o horário em que a vinculação de política foi atualizada pela última vez.

A seguir

• Saiba mais sobre os casos de uso das políticas de limite de acesso de principal.
• Saiba como criar e aplicar políticas de limite de acesso de principal.
• Revise a permissão que cada versão de aplicação da política de limite de acesso de principal bloqueia.