Tipos de políticas de IAM

A gestão de identidade e de acesso (IAM) oferece vários tipos de políticas para ajudar a controlar a que recursos os principais podem aceder. Esta página ajuda a compreender as diferenças entre a forma como usa e gere estes tipos de políticas.

Tipos de políticas de IAM no Google Cloud

O IAM oferece os seguintes tipos de políticas:

• Políticas de permissão
• Políticas de recusa
• Políticas de limite de acesso principal (PAB)
• Políticas de acesso

A tabela seguinte resume as diferenças entre estes tipos de políticas:

Política	Função da política	API usada para gerir a política	Relação entre políticas e alvos	Método de anexação de políticas ao alvo	Recurso principal da política
Políticas de permissão	Conceda aos principais acesso aos recursos	A API do recurso para o qual quer gerir políticas de permissão	Relação individual Cada política de permissão está associada a um recurso. Cada recurso só pode ter uma política de permissão	Especifique o recurso ao criar a política	Igual ao recurso ao qual a política de permissão está anexada
Políticas de recusa	Certifique-se de que os responsáveis não podem usar autorizações específicas	A API IAM v2	Relação um-para-muitos Cada política de recusa está anexada a um recurso. Cada recurso pode ter até 500 políticas de recusa	Especifique o recurso ao criar a política de recusa	Igual ao recurso ao qual a política de negação está anexada
Políticas de PAB	Restrinja os recursos aos quais um principal é elegível para aceder	A API IAM v3	Relação muitos-para-muitos Cada política de PAB pode ser anexada a um número ilimitado de conjuntos de principais. Cada conjunto de principais pode ter até 10 políticas de PAB associadas	Crie uma associação de políticas que anexe a política PAB a um conjunto de principais	A organização
Políticas de acesso	Conceda ou recuse o acesso dos principais aos recursos para serviços suportados	A API IAM v3	Relação muitos-para-muitos Cada política de acesso pode ser anexada a um máximo de 5 recursos; cada recurso pode ter um máximo de 5 políticas de acesso associadas	Crie uma associação de política de acesso que anexe a política de acesso ao recurso	O projeto, a pasta ou a organização onde a política de acesso é criada

As secções seguintes fornecem detalhes sobre cada tipo de política.

Políticas para conceder acesso a principais

Para conceder aos principais acesso a recursos, use uma das seguintes políticas:

• Use políticas de permissão para conceder acesso a qualquer tipo de recurso.
• Use políticas de acesso para conceder acesso a recursos do Eventarc.

As políticas de autorização permitem-lhe conceder acesso a recursos no Google Cloud. As políticas de permissão são compostas por associações de funções e metadados. As associações de funções especificam que principais devem ter uma determinada função no recurso.

As políticas de permissão estão sempre anexadas a um único recurso. Depois de anexar uma política de autorização a um recurso, a política é herdada pelos descendentes desse recurso.

Para criar e aplicar uma política de autorização, identifica um recurso que aceita políticas de autorização e, em seguida, usa o método setIamPolicy desse recurso para criar a política de autorização. A todos os responsáveis na política de autorização são atribuídas as funções especificadas no recurso e em todos os descendentes do recurso. Cada recurso só pode ter uma política de permissão anexada.

Para mais informações sobre as políticas de autorização, consulte o artigo Compreender as políticas de autorização.

As políticas de acesso permitem-lhe controlar o acesso aos recursos do Eventarc. As políticas de acesso podem permitir e recusar o acesso a recursos. Para criar e aplicar uma política de acesso, crie uma política de acesso e, em seguida, crie uma associação de políticas para associar essa política a um projeto com recursos do Eventarc.

Cada associação de política associa uma política de acesso a um recurso. Uma política de acesso pode ser associada a um máximo de 5 recursos. Cada recurso pode ter até 5 políticas de acesso associadas. Quando uma política de acesso é eliminada, todas as associações de políticas relacionadas com essa política também são eliminadas.

Para saber mais sobre a utilização de políticas de acesso para controlar o acesso aos recursos do Eventarc, consulte a documentação do Eventarc.

Políticas para negar o acesso a responsáveis

Para negar o acesso de responsáveis a recursos, use uma das seguintes opções:

• Use políticas de negação para negar o acesso a qualquer tipo de recurso.
• Use políticas de acesso para negar o acesso a recursos do Eventarc.

As políticas de recusa, tal como as políticas de permissão, estão sempre anexadas a um único recurso. Pode anexar uma política de recusa a um projeto, uma pasta ou uma organização. Este projeto, pasta ou organização também funciona como o principal da política na hierarquia de recursos. Depois de anexar uma política de recusa a um recurso, a política é herdada pelos descendentes desse recurso.

Para criar e aplicar políticas de negação, usa a API IAM v2. Quando cria uma política de recusa, especifica o recurso ao qual a política de recusa está anexada. Todos os principais na política de recusa são impedidos de usar as autorizações especificadas para aceder a esse recurso e a qualquer um dos descendentes desse recurso. Cada recurso pode ter até 500 políticas de recusa anexadas.

Para mais informações acerca das políticas de recusa, consulte o artigo Políticas de recusa.

As políticas de acesso permitem-lhe controlar o acesso aos recursos do Eventarc. As políticas de acesso podem permitir e recusar o acesso a recursos. Para criar e aplicar uma política de acesso, crie uma política de acesso e, em seguida, crie uma associação de políticas para associar essa política a um projeto com recursos do Eventarc.

Cada associação de políticas associa uma política de acesso a um recurso. Uma política de acesso pode ser associada a um máximo de 5 recursos. Cada recurso pode ter até 5 políticas de acesso associadas. Quando uma política de acesso é eliminada, todas as associações de políticas relacionadas com essa política também são eliminadas.

Para saber mais sobre a utilização de políticas de acesso para controlar o acesso aos recursos do Eventarc, consulte a documentação do Eventarc.

Políticas para restringir os recursos aos quais um principal pode aceder

Para restringir os recursos aos quais um principal é elegível para aceder, use uma política de limite de acesso principal. As políticas de limite de acesso principal estão disponíveis na API IAM v3.

Para criar e aplicar uma política de limite de acesso principal, crie uma política de limite de acesso principal e, em seguida, crie uma associação de políticas para associar essa política a um conjunto de principais.

As políticas de limite de acesso principal são sempre subordinadas à sua organização. As associações de políticas para políticas de limite de acesso principal são subordinadas ao projeto, à pasta ou à organização mais próximos do conjunto principal referenciado na associação de políticas.

Cada associação de políticas associa uma política de limite de acesso principal a um conjunto principal. Uma política de limite de acesso principal pode estar associada a qualquer número de conjuntos de principais. Cada conjunto de principais pode ter até 10 políticas de limite de acesso principal associadas. Quando uma política de limite de acesso principal é eliminada, todas as associações de políticas relacionadas com essa política também são eliminadas.

Para mais informações acerca das políticas de limite de acesso principal, consulte o artigo Políticas de limite de acesso principal.

Avaliação de políticas

Quando um principal tenta aceder a um recurso, o IAM avalia todas as políticas de permissão, negação e limite de acesso principal relevantes para ver se o principal tem permissão para aceder ao recurso. Se alguma destas políticas indicar que o principal não deve poder aceder ao recurso, o IAM impede o acesso.

Na realidade, a IAM avalia todos os tipos de políticas em simultâneo e, em seguida, compila os resultados para determinar se o principal pode aceder ao recurso. No entanto, pode ser útil pensar nesta avaliação de políticas que ocorre nas seguintes fases:

1. O IAM verifica todas as políticas de limite de acesso principais relevantes para ver se o principal é elegível para aceder ao recurso. Uma política de limite de acesso principal é relevante se as seguintes condições forem verdadeiras:

   • A política está associada a um conjunto de principais que inclui o principal
   • A política de limite de acesso principal bloqueia a autorização que o principal está a tentar usar. As autorizações que uma política de limite de acesso principal bloqueia dependem da versão da política de limite de acesso principal. Especifica a versão da política quando cria a política de limite de acesso principal. Para mais informações, consulte as versões da política de limite de acesso principal.

   Após verificar as políticas de limite de acesso principal relevantes, o IAM faz uma das seguintes ações:

   • Se as políticas de limite de acesso principal relevantes não incluírem o recurso ao qual o principal está a tentar aceder ou se o IAM não conseguir avaliar as políticas de limite de acesso principal relevantes, o IAM impede o acesso ao recurso.
   • Se as políticas de limite de acesso principais relevantes incluírem o recurso ao qual o principal está a tentar aceder, o IAM continua para o passo seguinte.
   • Se não existirem políticas de limite de acesso principal relevantes, o IAM avança para o passo seguinte.

2. O IAM verifica todas as políticas de recusa relevantes para ver se a autorização foi recusada ao principal. As políticas de recusa relevantes são as políticas de recusa anexadas ao recurso, bem como quaisquer políticas de recusa herdadas.

   Para recursos do Eventarc, o IAM também avalia quaisquer políticas de acesso com a ação DENY. Se o IAM não conseguir avaliar as políticas de acesso, ignora-as e continua com a avaliação.
   • Se alguma destas políticas de negação impedir o principal de usar uma autorização necessária, o IAM impede o principal de aceder ao recurso.
   • Se nenhuma política de recusa impedir o principal de usar uma autorização obrigatória, o IAM avança para o passo seguinte.

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

   Para recursos do Eventarc, o IAM também avalia quaisquer políticas de acesso com a ação ALLOW. Se o IAM não conseguir avaliar as políticas de acesso, ignora-as e continua com a avaliação.
   • Se o principal não tiver as autorizações necessárias, o IAM impede o acesso ao recurso.
   • Se o principal tiver as autorizações necessárias, o IAM permite-lhe aceder ao recurso.

O diagrama seguinte mostra este fluxo de avaliação de políticas:

O que se segue?

• Saiba mais acerca das políticas de autorização.
• Saiba mais acerca das políticas de recusa.
• Saiba mais sobre as políticas de limite de acesso principal.