Políticas de recusa

As políticas de negação da gestão de identidade e de acesso (IAM) permitem definir limites de proteção no acesso aos Trusted Cloud by S3NS recursos. Com as políticas de recusa, pode definir regras de recusa que impedem que determinados responsáveis usem determinadas autorizações, independentemente das funções que lhes são concedidas.

Esta página oferece uma vista geral das políticas de recusa e das regras de recusa. Para saber como criar e atualizar políticas de recusa, consulte o artigo Recuse o acesso a recursos.

Como funcionam as políticas de recusa

As políticas de recusa são compostas por regras de recusa. Cada regra de recusa especifica o seguinte:

  • Um conjunto de responsáveis aos quais são negadas autorizações
  • As autorizações que os responsáveis são recusadas ou não conseguem usar
  • Opcional: a condição que tem de ser verdadeira para que a autorização seja recusada

Quando um principal tem uma autorização recusada, não pode fazer nada que exija essa autorização, independentemente das funções do IAM que lhe foram concedidas. Isto deve-se ao facto de o IAM verificar sempre as políticas de negação relevantes antes de verificar as políticas de autorização relevantes. Para ver detalhes, consulte a avaliação de políticas.

Para especificar onde quer que uma política de recusa seja aplicada, anexe-a a um projeto, uma pasta ou uma organização. Quando uma política de recusa é anexada a um destes recursos, os principais na política não podem usar as autorizações especificadas para aceder ao recurso ou a qualquer um dos descendentes do recurso. Para saber mais sobre onde pode anexar uma política de recusa, consulte o Ponto de anexação nesta página.

Pode anexar várias políticas de recusa a um único recurso. Isto permite-lhe criar políticas de recusa separadas para diferentes tipos de regras de recusa. Por exemplo, pode colocar regras de recusa relacionadas com a conformidade numa política e, em seguida, usar outra política para outras regras de recusa. Cada política de recusa é avaliada independentemente de todas as outras políticas de recusa.

Cada recurso pode ter até 500 políticas de recusa. Em conjunto, estas políticas de recusa podem conter um total de 500 regras de recusa.

Ponto de fixação

Cada política de recusa está anexada a uma organização, uma pasta ou um projeto. Quando anexadas a um destes recursos, as políticas de recusa são herdadas por todos os recursos de nível inferior nesse projeto, pasta ou organização. Para trabalhar com políticas de negação, precisa de um identificador para o recurso ao qual a política de negação está anexada, que se denomina ponto de anexação. Este identificador usa um dos formatos na tabela seguinte:

Formato do ponto de fixação
Organização

cloudresourcemanager.googleapis.com/organizations/ORG_ID
Substitua ORG_ID pelo ID numérico da organização. Para a API REST, codifique por URL o valor completo.

Exemplo para a CLI gcloud:
cloudresourcemanager.googleapis.com/organizations/123456789012

Exemplo para a API REST:
cloudresourcemanager.googleapis.com%2Forganizations%2F123456789012

Pasta

cloudresourcemanager.googleapis.com/folders/FOLDER_ID
Substitua FOLDER_ID pelo ID numérico da pasta. Para a API REST, codifique por URL o valor completo.

Exemplo para a CLI gcloud:
cloudresourcemanager.googleapis.com/folders/987654321098

Exemplo para a API REST:
cloudresourcemanager.googleapis.com%2Ffolders%2F987654321098

Projeto

cloudresourcemanager.googleapis.com/projects/PROJECT_ID
Substitua PROJECT_ID pelo ID do projeto alfanumérico ou numérico. Para a API REST, codifique por URL o valor completo.

Exemplo para a CLI gcloud:
cloudresourcemanager.googleapis.com/projects/my-project

Exemplo para a API REST:
cloudresourcemanager.googleapis.com%2Fprojects%2Fmy-project

Recuse a herança de políticas

As políticas de recusa, tal como as políticas de autorização, são herdadas através da hierarquia de recursos. Quando anexa uma política de recusa a um projeto, uma pasta ou uma organização, a política também é eficaz para todos os recursos no interior desse projeto, pasta ou organização.

Por exemplo, se uma política de recusa para uma organização indicar que um principal não pode usar uma autorização específica, o principal não pode usar essa autorização para nenhum recurso na organização. Esta regra aplica-se mesmo que as pastas e os projetos nessa organização tenham políticas de negação mais permissivas.

Da mesma forma, se uma política de negação para um projeto indicar que um principal não pode usar uma autorização específica, o principal não pode usar essa autorização para nenhum recurso no projeto. Esta regra aplica-se mesmo que a organização principal e as pastas tenham políticas de negação mais permissivas.

Condições de recusa

As condições de recusa especificam as condições que têm de ser cumpridas para que uma regra de recusa seja aplicada. Se a condição for avaliada como true ou não puder ser avaliada, a regra de negação aplica-se e os responsáveis não podem usar as autorizações especificadas. Se a condição for avaliada como false, a regra de recusa não se aplica e os principais podem usar as autorizações especificadas, se as tiverem.

As condições de recusa têm a mesma estrutura que as condições do IAM. No entanto, as condições de negação só reconhecem funções de etiquetas de recursos.

Para saber como escrever condições, consulte a vista geral das condições do IAM.

Grupos de autorizações

Alguns serviços permitem-lhe recusar grupos de autorizações. Os grupos de autorizações são conjuntos de autorizações que correspondem a um padrão especificado. Pode usar um grupo de autorizações para recusar conjuntos de autorizações relacionadas. Por exemplo, pode recusar todas as autorizações para um único serviço ou recurso.

Os grupos de autorizações suportados estão listados em Autorizações suportadas em políticas de recusa. Os identificadores dos grupos de autorizações suportados substituem uma ou mais secções de um nome de autorização por um caráter universal (*). As autorizações que cada grupo inclui dependem da posição do caráter universal:

  • SERVICE_FQDN/RESOURCE.*: nega todas as autorizações para o recurso especificado.
  • SERVICE_FQDN/*.*: nega todas as autorizações para o serviço especificado.
  • SERVICE_FQDN/*.VERB: nega todas as autorizações para um serviço que termine no verbo especificado.

Os grupos de autorizações incluem todas as autorizações atuais e futuras que correspondem ao padrão especificado. Por exemplo, imagine que usa o grupo de autorizações example.googleapis.com/exampleResource.* para negar a um utilizador todas as autorizações para o tipo de recurso exampleResource. Se example.googleapis.com adicionar uma nova autorização para o tipo de recurso exampleResource, como example.googleapis.com/exampleResource.newPermission, a nova autorização é automaticamente recusada ao utilizador.

Só pode usar carateres universais em grupos de autorizações suportados. A utilização de carateres universais noutros nomes de autorizações não é suportada.

Estrutura de uma política de recusa

Uma política de recusa é uma coleção de metadados e regras de recusa. Uma regra de negação associa um conjunto de responsáveis a um conjunto de autorizações que os responsáveis não podem usar. Cada regra também pode especificar uma condição que determina quando a autorização é recusada.

Por exemplo, a seguinte política de recusa impede que todos os responsáveis eliminem projetos, a menos que o responsável seja membro do grupo project-admins ou que o projeto a ser eliminado tenha uma etiqueta com o valor test.

{
  "name": "policies/cloudresourcemanager.googleapis.com%2Fprojects%2F253519172624/denypolicies/limit-project-deletion",
  "uid": "06ccd2eb-d2a5-5dd1-a746-eaf4c6g3f816",
  "kind": "DenyPolicy",
  "displayName": "Only project admins can delete projects.",
  "etag": "MTc1MTkzMjY0MjUyMTExODMxMDQ=",
  "createTime": "2021-09-07T23:15:35.258319Z",
  "updateTime": "2021-09-07T23:15:35.258319Z",
  "rules": [
    {
      "denyRule": {
        "deniedPrincipals": [
          "principalSet://goog/public:all"
        ],
        "exceptionPrincipals": [
          "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/project-admins"
        ],
        "deniedPermissions": [
          "cloudresourcemanager.googleapis.com/projects.delete",
          "cloudresourcemanager.googleapis.com/folders.*"
        ],
        "exceptionPermissions": [
          "cloudresourcemanager.googleapis.com/folders.list",
          "cloudresourcemanager.googelapis.com/folders.get"
        ],
        "denialCondition": {
          "title":  "Only for non-test projects",
          "expression": "!resource.matchTag('12345678/env', 'test')"
        }
      }
    }
  ]
}

As secções seguintes descrevem os campos nos metadados de uma política de recusa e nas regras de recusa.

Metadados

As políticas de recusa contêm os seguintes metadados:

  • name: o nome da política de recusa. Este nome tem o formato policies/ATTACHMENT_POINT/denypolicies/POLICY_ID, em que ATTACHMENT_POINT é o projeto, a pasta ou a organização à qual a política de recusa está anexada e POLICY_ID é o ID alfanumérico da política de recusa.
  • uid: um ID exclusivo atribuído à política de recusa pela Google.
  • kind: o tipo de política. O kind para uma política de recusa é sempre DenyPolicy.
  • displayName: opcional. Um nome legível para a política de negação.
  • etag: um identificador de uma versão da política. Para evitar atualizações em conflito, o valor etag tem de corresponder ao valor armazenado no IAM. Se os valores de etag não corresponderem, o pedido falha.
  • createTime: a hora em que a política de recusa foi criada.
  • updateTime: a última vez que a política de recusa foi atualizada.

Regras de recusa

Cada regra de recusa pode ter os seguintes campos:

  • deniedPrincipals: os principais aos quais as autorizações são recusadas. Pode listar principais individuais e conjuntos de principais. Os tipos de principais individuais incluem contas de utilizador, contas de serviço e identidades únicas num Workload Identity Pool ou num Workforce Identity Pool. Os conjuntos de principais incluem grupos Google, domínios do Cloud ID, conjuntos de identidades da força de trabalho ou de cargas de trabalho e todos os utilizadores na Internet.

    Para ver uma lista de tipos e identificadores de diretor válidos, consulte o artigo Identificadores de diretor para políticas de negação.

  • exceptionPrincipals: opcional. Os diretores que estão isentos da regra de recusa. A estes principais não são negadas as autorizações especificadas, mesmo que estejam listados em deniedPrincipals ou façam parte de um grupo listado em deniedPrincipals.

    Pode listar conjuntos de principais e principais individuais. Os tipos de principais individuais incluem contas de utilizador, contas de serviço e identidades únicas num conjunto de identidades de força de trabalho ou de carga de trabalho. Os conjuntos de principais incluem grupos Google, domínios do Cloud ID, conjuntos de identidades do Workforce ou do Workload e todos os utilizadores na Internet.

    Para ver uma lista de tipos e identificadores de diretor válidos, consulte o artigo Identificadores de diretor para políticas de negação.

  • deniedPermissions: As autorizações que os principais especificados não podem usar ou que lhes foram negadas. Estas autorizações usam o formato de autorização do IAM, que usa nomes do domínio totalmente qualificados (FQDNs) para identificar o serviço.v2 O formato é SERVICE_FQDN/RESOURCE.ACTION. As APIs Google usam o domínio *.googleapis.com. Por exemplo, iam.googleapis.com/roles.delete.

    Só é possível recusar algumas autorizações. Para ver uma lista completa das autorizações que podem ser recusadas, consulte o artigo Autorizações suportadas nas políticas de recusa.

    Em alguns casos, também pode usar grupos de autorizações para negar conjuntos de autorizações. Para mais informações, consulte Grupos de autorizações.

  • exceptionPermissions: opcional. Uma lista de autorizações que os principais especificados podem usar, mesmo que essas autorizações estejam incluídas em deniedPermissions. Por exemplo, pode usar este campo para criar exceções para autorizações específicas num grupo de autorizações.

  • denialConditions: opcional. Uma expressão lógica que afeta o momento em que a regra de recusa se aplica. Se a condição for avaliada como true ou não puder ser avaliada, a autorização é recusada. Se a condição for avaliada como false, a autorização não é recusada. Para mais informações, consulte as condições de recusa nesta página.

Exemplos de utilização comuns

Seguem-se situações comuns em que pode querer usar políticas de recusa e exemplos das regras de recusa que pode criar em cada situação. Para saber como criar e atualizar políticas de recusa, consulte o artigo Recuse o acesso a recursos.

Centralizar os privilégios administrativos

Pode usar políticas de recusa para restringir determinados tipos de atividades administrativas a um conjunto específico de responsáveis.

Por exemplo, imagine que quer limitar a gestão de funções personalizadas da sua organização a uma única equipa central. Para tal, crie uma regra de recusa que recuse as autorizações necessárias para a gestão de funções personalizadas a todos os utilizadores, exceto aos utilizadores no grupo administrativo (custom-role-admins):

{
  "deniedPrincipals": [
    "principalSet://goog/public:all"
  ],
  "exceptionPrincipals": [
    "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/custom-role-admins"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/roles.create",
    "iam.googleapis.com/roles.delete",
    "iam.googleapis.com/roles.update",
  ]
}

Em seguida, anexe a política de recusa à sua organização.

Agora, apenas os membros do grupo custom-role-admins podem gerir funções personalizadas, mesmo que outros utilizadores tenham as autorizações necessárias.

Por exemplo, imagine que o Yuri e o Tal têm a função de administrador (roles/iam.organizationRoleAdmin) da organização. No entanto, o Yuri é membro de custom-role-admins e o Tal não. Com esta política de negação, apenas o Yuri pode criar, eliminar e atualizar funções.

Criar exceções às concessões de acesso

Pode usar políticas de recusa para recusar autorizações herdadas. Esta capacidade dá-lhe a opção de conceder uma função a um nível elevado na hierarquia de recursos e, em seguida, negar as autorizações da função em recursos individuais de nível inferior, se necessário.

Por exemplo, imagine que tem uma pasta, Engineering, que contém vários projetos. Quer conceder a um grupo, eng, as autorizações na função de administrador da chave da conta de serviço (roles/iam.serviceAccountKeyAdmin) em quase todos os projetos na pasta. No entanto, não quer que o grupo ganhe a capacidade de criar e eliminar chaves de contas de serviço num projeto específico na pasta, example-prod.

Em vez de conceder a função de administrador da chave de conta de serviço em cada projeto individual, cria a seguinte regra de recusa, que recusa as autorizações de criação e eliminação na função de administrador da chave de conta de serviço aos responsáveis no grupo eng:

{
  "deniedPrincipals": [
    "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/eng"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/serviceAccountKeys.create",
    "iam.googleapis.com/serviceAccountKeys.delete"
  ]
}

Em seguida, adiciona esta regra de recusa a uma política de recusa e anexa a política ao projeto example-prod.

Depois de anexar a política de recusa ao projeto, pode conceder a função de administrador da chave da conta de serviço ao grupo eng na pasta Engineering sem permitir que o grupo crie ou elimine chaves de contas de serviço em example-prod.

Os membros do grupo eng podem criar e eliminar chaves de contas de serviço em todos os projetos, exceto no example-prod. Por exemplo, se o Izumi for membro do grupo eng, pode criar e eliminar chaves para contas de serviço em example-dev e example-test, mas não em example-prod.

No entanto, imagine que quer que um subconjunto do grupo eng possa criar e eliminar chaves de contas de serviço em example-prod. Este subconjunto é representado pelo grupo eng-prod. Para permitir que os membros do grupo eng-prod criem e eliminem chaves de contas de serviço em example-prod, pode isentar o grupo da regra de recusa:

{
  "deniedPrincipals": [
    "principalSet://goog/group/eng@example.com"
  ],
  "exceptionPrincipals": [
    "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/eng-prod"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/serviceAccountKeys.create",
    "iam.googleapis.com/serviceAccountKeys.delete"
  ]
}

Com esta política de recusa revista, os membros do grupo eng-prod podem criar e eliminar chaves de contas de serviço em todos os projetos, incluindo example-prod. Por exemplo, se o Carlos for membro do grupo eng-prod, pode criar e eliminar chaves em example-dev, example-test e example-prod, mesmo que também seja membro do grupo eng.

Bloquear o acesso com base em etiquetas

Uma etiqueta é um par de chave-valor que pode ser anexado a uma organização, uma pasta ou um projeto. Pode usar políticas de recusa para recusar autorizações com base em etiquetas sem adicionar uma condição de IAM a cada concessão de função.

Por exemplo, imagine que etiqueta todos os seus projetos como dev, test ou prod. Quer que apenas os membros do grupo project-admins possam eliminar projetos etiquetados com prod.

Para resolver este problema, crie uma regra de recusa que recuse a autorização cloudresourcemanager.googleapis.com/projects.delete a todos, exceto ao grupo project-admins, para recursos etiquetados como prod:

{
  "displayName": "Only project admins can delete production projects.",
  "rules": [
    {
      "denyRule": {
        "deniedPrincipals": [
          "principalSet://goog/public:all"
        ],
        "exceptionPrincipals": [
          "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/project-admins"
        ],
        "deniedPermissions": [
          "cloudresourcemanager.googleapis.com/projects.delete"
        ],
        "denialCondition": {
          "title":  "Only for prod projects",
          "expression": "resource.matchTag('12345678/env', 'prod')"
        }
      }
    }
  ]
}

Em seguida, adiciona esta regra de recusa a uma política de recusa e anexa a política à sua organização.

Devido a esta regra de recusa, pode limitar o acesso dos responsáveis sem adicionar uma condição às respetivas concessões de funções. Em alternativa, pode conceder funções aos principais que contenham a autorização cloudresourcemanager.googleapis.com/projects.delete, e basear-se na regra de recusa para impedir que os principais fora do grupo project-admins eliminem projetos etiquetados como prod.

Por exemplo, considere dois utilizadores, a Ana e o João. Ambos os utilizadores têm a função Project Deleter (roles/resourcemanager.projectDeleter). Além disso, o Kiran é membro do grupo project-admins. Com esta política de recusa, o Bola só pode eliminar projetos que tenham a etiqueta dev ou test. O Kiran pode eliminar todos os projetos, independentemente das respetivas etiquetas.

O que se segue?