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.
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 |
Exemplo da CLI gcloud:
Exemplo da API REST: |
Pasta |
Exemplo da CLI gcloud:
Exemplo da API REST: |
Projeto |
Exemplo da CLI gcloud:
Exemplo da API REST: |
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
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",
"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 formatopolicies/ATTACHMENT_POINT/denypolicies/POLICY_ID
, em queATTACHMENT_POINT
é o projeto, pasta ou organização a que a política de negação está anexada ePOLICY_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. Okind
de uma política de negação é sempreDenyPolicy
.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 valoretag
precisa corresponder ao valor armazenado no IAM. Se os valores deetag
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 emdeniedPrincipals
ou façam parte de um grupo listado emdeniedPrincipals
.É 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ãov2
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 emdeniedPermissions
. 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 comotrue
ou não puder ser avaliada, a permissão será negada. Se a condição for avaliada comofalse
, 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
- 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.