Políticas de negação

As políticas de negação do Identity and Access Management (IAM) permitem definir proteções no acesso aos recursos do Google Cloud. Com as políticas de negação, é possível definir regras de negação que impedem determinados principais de usar determinadas permissões, independentemente dos papéis atribuídos.

Nesta página, você encontra uma visão geral das políticas e regras de negação. Para saber como criar e atualizar políticas de negação, consulte Negar acesso aos recursos.

Como funcionam as políticas de negação

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

• Um conjunto de principais com permissões negadas
• As permissões negadas aos principais, ou que eles não podem usar
• Opcional: a condição que precisa ser verdadeira para a permissão ser negada

Quando uma permissão negada a um principal, ele não pode fazer nada que exija essa permissão, independentemente dos papéis do IAM atribuídos. Isso ocorre porque o IAM sempre verifica as políticas de negação relevantes antes de verificar as políticas de permissão. Para mais detalhes, consulte avaliação de política.

Para especificar onde você quer aplicar, anexe a política de negação a um projeto, pasta ou organização. Quando uma política de negação é anexada a um desses recursos, os principais da política não podem usar as permissões especificadas para acessar o recurso ou qualquer um dos descendentes dele. Para saber mais sobre onde é possível anexar uma política de negação, consulte Ponto de vinculação nesta página.

É possível anexar várias políticas de negação a um único recurso. Isso permite criar políticas de negação separadas para diferentes tipos de regras de negação. Por exemplo, é possível colocar regras de negação relacionadas à conformidade em uma política e usar outra política para outras regras de negação. Cada política de negação é avaliada independentemente de todas as outras políticas de negação.

Cada recurso pode ter até 500 políticas de negação. Juntas, essas políticas de negação podem conter um total de 500 regras de negação.

Observação: as mudanças no acesso de um principal têm consistência posterior. Isso significa que leva algum tempo para que as mudanças no acesso se propaguem pelo sistema. Para saber quanto tempo leva, em média, para as alterações de acesso propagadas, consulte Acesso à propagação de mudança.

Ponto de anexo

Cada política de negação é anexada a uma organização, pasta ou projeto. Quando anexadas a um desses recursos, as políticas de negação 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, você precisa de um identificador para o recurso a que a política de negação está anexada, o que é chamado de ponto de anexo. Esse identificador usa um dos formatos na tabela a seguir:

Formato do ponto do anexo
Organização	cloudresourcemanager.googleapis.com/organizations/ORG_ID Substitua ORG_ID pelo ID numérico da organização. Para a API REST, codifique o URL de todo o valor. Exemplo da CLI gcloud: cloudresourcemanager.googleapis.com/organizations/123456789012 Exemplo da API REST: cloudresourcemanager.googleapis.com%2Forganizations%2F123456789012
Pasta	cloudresourcemanager.googleapis.com/folders/FOLDER_ID Substitua FOLDER_ID pelo ID da pasta numérica. Para a API REST, codifique o URL de todo o valor. Exemplo da CLI gcloud: cloudresourcemanager.googleapis.com/folders/987654321098 Exemplo da API REST: cloudresourcemanager.googleapis.com%2Ffolders%2F987654321098
Projeto	cloudresourcemanager.googleapis.com/projects/PROJECT_ID Substitua PROJECT_ID pelo ID alfanumérico ou numérico do projeto. Para a API REST, codifique o URL de todo o valor. Exemplo da CLI gcloud: cloudresourcemanager.googleapis.com/projects/my-project Exemplo da API REST: cloudresourcemanager.googleapis.com%2Fprojects%2Fmy-project

Negar herança de políticas

As políticas de negação, como as de permissão, são herdadas pela hierarquia de recursos. Quando você anexa uma política de negação a um projeto, pasta ou organização, a política também é aplicada a todos os recursos dentro desse projeto, pasta ou organização.

Por exemplo, se uma política de negação para uma organização disser que um principal não pode usar uma permissão específica, o principal não poderá usar essa permissão em qualquer recurso na organização. Essa regra se aplica mesmo se as pastas e os projetos dessa organização tiverem 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 permissão específica, o principal não poderá usar essa permissão em qualquer recurso o projeto. Essa regra é aplicável mesmo se a organização e as pastas pais tiverem políticas de negação mais permissivas.

Condições de negação

As condições de negação especificam o que precisa ser atendido para que uma regra de negação seja aplicada. Se a condição for avaliada como true ou não puder ser avaliada, a regra de negação será aplicada e os principais não poderão usar as permissões especificadas. Se a condição for avaliada como false, a regra de negação não se aplicará e os principais poderão usar as permissões especificadas, se houver.

As condições de negação têm a mesma estrutura das condições do IAM. No entanto, as condições de negação reconhecem somente funções de tag de recurso.

Para saber como gravar condições, consulte a visão geral das condições do IAM.

Grupos de permissões

Alguns serviços permitem que você negue grupos de permissões. Grupos de permissões são conjuntos de permissões que correspondem a um padrão especificado. É possível usar um grupo de permissões para negar conjuntos de permissões relacionadas. Por exemplo, é possível negar todas as permissões de um único serviço ou recurso.

Os grupos de permissões com suporte estão listados em Permissões compatíveis em políticas de negação. Os identificadores dos grupos de permissões com suporte substituem uma ou mais seções de um nome de permissão por um caractere curinga (*). As permissões que cada grupo inclui dependem da posição do curinga:

• SERVICE_FQDN/RESOURCE.*: nega todas as permissões para o recurso especificado.
• SERVICE_FQDN/*.*: nega todas as permissões para o serviço especificado.
• SERVICE_FQDN/*.VERB: nega todas as permissões para um serviço que termina com o verbo especificado.

Os grupos de permissões incluem todas as permissões atuais e futuras que correspondem ao padrão especificado. Por exemplo, imagine que você usa o grupo de permissões example.googleapis.com/exampleResource.* para negar a um usuário todas as permissões do tipo de recurso exampleResource. Se example.googleapis.com adicionar uma nova permissão para o tipo de recurso exampleResource, como example.googleapis.com/exampleResource.newPermission, o usuário receberá automaticamente a nova permissão.

Só é possível usar caracteres curinga em grupos de permissão compatíveis. Não é possível usar caracteres curinga em outros nomes de permissão.

Estrutura de uma política de negação

Essa política é um conjunto de metadados e regras de negação. Uma regra de negação associa um conjunto de principais a um conjunto de permissões que foram negadas para os principais ou que eles não conseguem usar. Cada regra também pode especificar uma condição que determina quando a permissão é negada.

Por exemplo, a seguinte política de negação impede que todos os principais excluam projetos, a menos que ele seja membro de [e-mail] ou que o projeto que está sendo excluído tenha uma tag 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://goog/group/[e-mail]"
        ],
        "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 seções a seguir descrevem os campos nos metadados e nas regras de negação de uma política.

Metadados

As políticas de negação contêm os seguintes metadados:

• name: o nome da política de negação. Esse nome tem o formato policies/ATTACHMENT_POINT/denypolicies/POLICY_ID, em que ATTACHMENT_POINT é o projeto, pasta ou organização a que a política de negação está anexada e POLICY_ID é o ID alfanumérico da política de negação.
• uid: um ID exclusivo atribuído à política de negação pelo Google.
• kind: o tipo de política. O kind de uma política de negação é 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 conflitantes, o valor etag precisa corresponder ao valor armazenado no IAM. Se os valores de etag não corresponderem, a solicitação falha.
• createTime: o horário em que a política de negação foi criada.
• updateTime: a última vez que a política de negação foi atualizada.

Regras de negação

Cada regra de negação pode ter os seguintes campos:

• deniedPrincipals: principais que têm essas permissões negadas. É possível listar principais individuais e conjuntos. Os tipos principais individuais incluem contas de usuário, contas de serviço e identidades únicas em um pool de Identidade da carga de trabalho ou de trabalho. Os conjuntos de principais incluem grupos do Google, domínios do Cloud Identity, conjuntos de identidades de força de trabalho ou carga de trabalho e todos os usuários na Internet.

  Para ver uma lista dos tipos e identificadores principais válidos, consulte Principais identificadores da API do IAM v2beta.

• exceptionPrincipals: opcional. Os principais que estão isentos da regra de negação. As permissões especificadas não são negadas a esses principais mesmo que estejam listados em deniedPrincipals ou façam parte de um grupo listado em deniedPrincipals.

  É possível listar principais individuais e conjuntos. Os tipos principais individuais incluem contas de usuário, contas de serviço e identidades únicas em um pool de Identidade da carga de trabalho ou de trabalho. Os conjuntos de principais incluem grupos do Google, domínios do Cloud Identity, conjuntos de identidades de força de trabalho ou carga de trabalho e todos os usuários na Internet.

  Para ver uma lista dos tipos e identificadores principais válidos, consulte Principais identificadores da API do IAM v2beta.

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

  Apenas algumas permissões podem ser negadas. Para uma lista completa de permissões que podem ser negadas, consulte Permissões compatíveis com políticas de negação.

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

• exceptionPermissions: opcional. Uma lista de permissões que os principais especificados podem usar, mesmo que essas permissões estejam incluídas em deniedPermissions. Por exemplo, é possível usar esse campo para criar exceções para permissões específicas em um grupo de permissões.

• denialConditions: opcional. Uma expressão lógica que afeta quando a regra de negação é aplicada. Se a condição for avaliada como true ou não puder ser avaliada, a permissão será negada. Se a condição for avaliada como false, a permissão não será negada. Para mais informações, consulte Condições de negação nesta página.

Casos de uso comuns

Veja a seguir situações comuns em que convém usar políticas de negação e exemplos de regras de negação que podem ser criadas em cada caso. Para saber como criar e atualizar políticas de negação, consulte Negar acesso aos recursos.

Como centralizar privilégios administrativos

É possível usar políticas de negação para restringir determinados tipos de atividades administrativas a um conjunto específico de principais.

Por exemplo, imagine que você queira limitar o gerenciamento de papéis personalizados da organização a uma única equipe central. Para fazer isso, crie uma regra de negação que negue as permissões necessárias para o gerenciamento de papéis personalizados a todos os usuários, exceto aos usuários no grupo administrativo ([e-mail]):

{
  "deniedPrincipals": [
    "principalSet://goog/public:all"
  ],
  "exceptionPrincipals": [
    "principalSet://goog/group/[e-mail]"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/roles.create",
    "iam.googleapis.com/roles.delete",
    "iam.googleapis.com/roles.update",
  ]
}

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

Agora, apenas membros do grupo [e-mail] podem gerenciar papéis personalizados, mesmo que outros usuários tenham as permissões necessárias.

Por exemplo, imagine que [e-mail] e [e-mail] têm o papel de administrador de papéis da organização (roles/iam.organizationRoleAdmin). No entanto, [e-mail] é um membro de [e-mail] e [e-mail] não. Com essa política de negação, somente [e-mail] consegue criar, excluir e atualizar papéis.

Como criar exceções para acessar concessões

É possível usar políticas de negação para negar permissões herdadas. Esse recurso oferece a opção de atribuir um papel em um nível superior na hierarquia de recursos e, em seguida, negar as permissões do papel em recursos individuais de nível inferior, se necessário.

Por exemplo, imagine que você tem uma pasta, Engineering, com vários projetos. Você quer conceder a um grupo, [e-mail], as permissões do papel "Administrador de chaves de conta de serviço" (roles/iam.serviceAccountKeyAdmin) para quase todos os projetos da pasta. No entanto, você não quer que o grupo possa criar e excluir chaves de contas de serviço em um projeto específico dessa pasta, o example-prod.

Em vez de conceder o papel Administrador de chaves de conta de serviço a cada projeto individual, é possível criar a seguinte regra de negação, que nega permissões de criação e exclusão para o papel de administrador de chave de conta de serviço para os principais em [e-mail]:

{
  "deniedPrincipals": [
    "principalSet://goog/group/[e-mail]"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/serviceAccountKeys.create",
    "iam.googleapis.com/serviceAccountKeys.delete"
  ]
}

Em seguida, adicione essa regra de negação a uma política de negação e anexe a política ao projeto example-prod.

Depois de anexar a política de negação ao projeto, é possível atribuir o papel Administrador de chaves da conta de serviço a [e-mail] na pasta Engineering sem permitir que o grupo crie ou exclua chaves de conta de serviço em example-prod.

Os membros de [e-mail] podem criar e excluir chaves de conta de serviço em todos os projetos, exceto example-prod. Por exemplo, se [e-mail] for membro de [e-mail], ele poderá criar e excluir chaves para contas de serviço em example-dev e example-test, mas não em example-prod.

No entanto, imagine que você quer que um subconjunto de [e-mail] possa criar e excluir chaves de contas de serviço em example-prod. Esse subconjunto é representado pelo grupo [e-mail]. Para permitir que os membros de [e-mail] criem e excluam chaves de conta de serviço em example-prod, isente o grupo da regra de negação:

{
  "deniedPrincipals": [
    "principalSet://goog/group/[e-mail]"
  ],
  "exceptionPrincipals": [
    "principalSet://goog/group/[e-mail]"
  ],
  "deniedPermissions": [
    "iam.googleapis.com/serviceAccountKeys.create",
    "iam.googleapis.com/serviceAccountKeys.delete"
  ]
}

Com essa revisão da política de negação, os membros de [e-mail] podem criar e excluir chaves de conta de serviço em todos os projetos, incluindo example-prod. Por exemplo, se [e-mail] for membro de [e-mail], ele pode criar e excluir chaves em example-dev, example-test e example-prod, mesmo se também seja membro de [e-mail].

Como bloquear o acesso com base em tags

Uma tag é um par de chave-valor que pode ser anexado a uma organização, pasta ou projeto. É possível usar políticas de negação para negar permissões com base em tags sem adicionar uma condição do IAM toda vez que um papel for atribuído.

Por exemplo, imagine que você marca com uma tag todos os seus projetos como dev, test ou prod. Você quer que apenas os membros de [e-mail] possam excluir projetos marcados com prod.

Para resolver esse problema, crie uma regra de negação que negue a permissão cloudresourcemanager.googleapis.com/projects.delete para todos, exceto [e-mail], para recursos com as tags prod:

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

Em seguida, adicione essa regra de negação a uma política de negação e anexe a política à organização.

Devido a essa regra de negação, é possível limitar o acesso dos principais sem adicionar uma condição quando o papel é atribuído. Em vez disso, é possível atribuir papéis principais com a permissão cloudresourcemanager.googleapis.com/projects.delete e usar a regra de negação para evitar que principais fora de [e-mail] excluam projetos marcados com prod.

Por exemplo, considere dois usuários, [e-mail] e [e-mail]. Os dois usuários têm o papel de Excluidor de projetos (roles/resourcemanager.projectDeleter). Além disso, [e-mail] é membro de [e-mail]. Com essa política de negação, só [e-mail] pode excluir projetos que tenham a tag dev ou test. [e-mail] pode excluir todos os projetos, independentemente das tags.

A seguir

• Saiba como criar, atualizar e excluir políticas de negação.
• Descubra como solucionar problemas de acesso com políticas de negação.
• Revise as permissões que podem ser negadas.
• Veja os tipos de principais que podem ser incluídos em políticas de negação.