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.

É 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.

Avaliação da política

Quando um principal tenta acessar um recurso, o IAM avalia todas as políticas de permissão e negação relevantes para ver se o principal tem permissão para acessar o recurso. Ele avalia as políticas nesta ordem:

  1. O IAM verifica todas as políticas de negação relevantes para ver se a permissão da conta principal foi negada. As políticas de negação relevantes são as políticas de negação anexadas ao recurso, bem como quaisquer políticas de negação herdadas.

    Se qualquer uma dessas políticas de negação impedir que o principal use uma permissão necessária, o IAM impedirá o acesso ao recurso.

    Se nenhuma política de negação impedir que o principal use uma permissão necessária, o IAM prosseguirá para a próxima etapa.

  2. O IAM verifica todas as políticas de permissão relevantes para ver se o principal tem as permissões necessárias. As políticas de permissão relevantes são as anexadas ao recurso, bem como quaisquer políticas de permissão herdadas.

    Se o principal tiver as permissões necessárias, o IAM permitirá que elas acessem o recurso.

    Se o principal não tiver as permissões necessárias, o IAM impedirá o acesso.

O diagrama a seguir mostra esse fluxo de avaliação da política:

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. Não é possível usar caracteres curinga em outros nomes de permissão.

O identificador de um grupo de permissões substitui uma ou mais seções de um nome de permissão por um caractere curinga (*). O grupo de permissões inclui todas as permissões que correspondem a esse padrão.

Curingas podem aparecer nos seguintes locais:

  • 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.

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 project-admins@example.com 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/project-admins@example.com"
        ],
        "deniedPermissions": [
          "cloudresourcemanager.googleapis.com/projects.delete"
        ],
        "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.

  • 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 (custom-role-admins@example.com):

{
  "deniedPrincipals": [
    "principalSet://goog/public:all"
  ],
  "exceptionPrincipals": [
    "principalSet://goog/group/custom-role-admins@example.com"
  ],
  "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 custom-role-admins@example.com podem gerenciar papéis personalizados, mesmo que outros usuários tenham as permissões necessárias.

Por exemplo, imagine que yuri@example.com e tal@example.com têm o papel de administrador de papéis da organização (roles/iam.organizationRoleAdmin). No entanto, yuri@example.com é um membro de custom-role-admins@example.com e tal@example.com não. Com essa política de negação, somente yuri@example.com 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, eng@example.com, 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 eng@example.com:

{
  "deniedPrincipals": [
    "principalSet://goog/group/eng@example.com"
  ],
  "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 eng@example.com na pasta Engineering sem permitir que o grupo crie ou exclua chaves de conta de serviço em example-prod.

Os membros de eng@example.com podem criar e excluir chaves de conta de serviço em todos os projetos, exceto example-prod. Por exemplo, se izumi@example.com for membro de eng@example.com, 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 eng@example.com possa criar e excluir chaves de contas de serviço em example-prod. Esse subconjunto é representado pelo grupo eng-prod@example.com. Para permitir que os membros de eng-prod@example.com criem e excluam chaves de conta de serviço em example-prod, isente o grupo da regra de negação:

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

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

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 project-admins@example.com 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 project-admins@example.com, 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/project-admins@example.com"
        ],
        "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 project-admins@example.com excluam projetos marcados com prod.

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

A seguir