Exemplos de casos de uso para políticas de limite de acesso de principal

Confira a seguir situações comuns em que convém usar políticas de limite de acesso de principal e exemplos das políticas e vinculações de políticas que podem ser criadas em cada caso. Para saber como criar políticas de limite de acesso de principal e vinculá-las a conjuntos de principais, consulte Criar e aplicar políticas de limite de acesso de principal.

Impedir que os usuários acessem recursos fora da sua organização

Como as políticas de limite de acesso de principal estão associadas a principais e não a recursos, é possível usá-las para impedir que os principais acessem recursos que não são seus. Por exemplo, considere o seguinte cenário:

Política de limite de acesso de principal que impede o acesso a um recurso

Política de limite de acesso de principal que impede o acesso a um recurso

  • O principal Tal (tal@example.com) faz parte da organização example.com do Google Workspace.
  • Tal recebe o papel de Administrador do Storage (roles/storage.admin) em um bucket do Cloud Storage em outra organização, cymbalgroup.com. Esse papel contém a permissão storage.objects.get, que é necessária para visualizar objetos no bucket.
  • Não há políticas de negação em cymbalgroup.com que impeçam Tal de usar a permissão storage.objects.get.

Os administradores de example.com não podem usar políticas de permissão e negação para impedir que Tal visualize objetos nesse bucket externo. Nenhum principal de example.com tem permissão para editar a política de permissão do bucket. Portanto, eles não podem revogar o papel de Tal. Eles também não têm permissão para criar políticas de negação em cymbalgroup.com. Portanto, não podem usar uma política de negação para impedir que Tal acesse o bucket.

No entanto, com as políticas de limite de acesso de principal, os administradores de example.com podem impedir que Tal visualize objetos no bucket cymbalgroup.com ou em qualquer bucket fora de example.com.

Para fazer isso, os administradores podem criar uma política de limite de acesso de principal que diga que os principais de example.com só podem acessar 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": "4"
  }
}

Em seguida, eles podem criar uma vinculação de política para anexar essa política a todos os principais da organização example.com:

{
  "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"
}

Os principais que estão em example.com incluem todas as identidades no domínio example.com, todos os pools de identidade da força de trabalho em example.com e todas as contas de serviço e pools de identidade da carga de trabalho em qualquer projeto em example.com.

Com essa política, os principais em example.com não podem usar permissões que são bloqueadas pela política de limite de acesso de principal para acessar recursos fora de example.com, mesmo que tenham essas permissões nesses recursos.

Nesse caso, a política de limite de acesso de principal usa a versão de aplicação 4. Portanto, ela pode bloquear a permissão storage.objects.get. Como resultado, Tal não poderá visualizar objetos no bucket cymbalgroup.com, mesmo que tenha recebido o papel de Administrador do Storage no bucket.

Tornar as contas de serviço qualificadas para acessar recursos em um único projeto

Também é possível usar políticas de limite de acesso de principal para qualificar subconjuntos de principais para acessar subconjuntos de recursos na sua organização.

Por exemplo, imagine que você tenha um projeto, example-dev, com o número 901234567890. Você quer garantir que as contas de serviço em example-dev só possam acessar recursos em example-dev.

Para fazer isso, primeiro crie uma nova política de limite de acesso de principal que qualifique os principais para acessar recursos em dev-project:

{
  "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": "4"
  }
}

Essa política de limite de acesso de principal usa a versão de aplicação 4, o que significa que ela pode bloquear todas as permissões compatíveis com a versão de aplicação 4.

Depois de criar a política de limite de acesso de principal, crie uma vinculação de política para vincular a nova política a todos os principais em example-dev, e adicione uma condição para que a vinculação de política só se aplique a 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'"
  }
}

Se essa for a única política de limite de acesso de principal a que as contas de serviço estão sujeitas, elas não poderão usar nenhuma permissão que a política de limite de acesso de principal possa bloquear para acessar recursos fora de example-dev.

Gerenciar a qualificação para diferentes grupos de principais

É possível usar várias políticas de limite de acesso de principal na mesma organização para qualificar diferentes principais para acessar recursos diferentes. Ao usar várias políticas de limite de acesso de principal, use condições nas vinculações de políticas para garantir que cada política só se aplique aos principais que você quer.

Por exemplo, imagine que você quer que a maioria dos principais possa acessar todos os recursos da sua organização, conforme mostrado em Impedir que os usuários acessem recursos fora da sua organização. No entanto, você também quer garantir que as contas de serviço em example-dev só possam acessar recursos em example-dev, conforme mostrado em Tornar as contas de serviço qualificadas para acessar recursos em um único projeto.

Para atingir essa meta, faça o seguinte:

  1. Seguindo o exemplo em Impedir que os usuários acessem recursos fora de sua organização, crie uma política de limite de acesso de principal que qualifique os principais para acessar recursos em example.com e vincule-a ao conjunto de principais da organização.

  2. Seguindo o exemplo em Tornar as contas de serviço qualificadas para acessar recursos em um único projeto, crie uma política de limite de acesso de principal que qualifique as contas de serviço em example-dev para acessar recursos em example-dev e vincule-a às contas de serviço em example-dev.

  3. Exclua as contas de serviço em example-dev da política de limite de acesso de principal que qualifica os principais para acessar todos os recursos em example.com. Para fazer isso, adicione a seguinte condição à vinculação de política que anexa essa política de limite de acesso de principal ao conjunto de principais da organização:

    "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.iam.gserviceaccount.com') && principal.subject != 'example-dev@appspot.gserviceaccount.com' && principal.subject != '901234567890-compute@developer.gserviceaccount.com')"
}

Essa última etapa é fundamental. Se você não isentar as contas de serviço de example-dev da política de limite de acesso de principal inicial, essa política vai qualificá-las para acessar todos os recursos em example.com, independentemente das outras políticas de limite de acesso de principal a que estão sujeitas. Para mais informações, consulte Definir recursos qualificados.

Também é importante criar e anexar uma nova política de limite de acesso de principal às contas de serviço de example-dev antes de isentá-las da política de limite de acesso de principal inicial. Seguir esse procedimento garante que as contas de serviço estejam sempre sujeitas a pelo menos uma política de limite de acesso de principal, o que impede que elas se qualifiquem para acessar todos os recursos. Google CloudPara mais informações sobre como reduzir com segurança os recursos que um principal pode acessar, consulte Reduzir os recursos que os principais podem acessar.

A seguir