Visão geral da política de autorização

Uma política de autorização (AuthzPolicy), anexada à regra de encaminhamento de um balanceador de carga, permite especificar condições que autorizam, restringem ou delegam a autorização de solicitações com base na origem e nas operações pretendidas. As solicitações que passam nessas verificações são roteadas para o serviço de back-end do balanceador de carga, enquanto as que falham são rejeitadas com uma resposta não autorizada.

É possível configurar políticas de autorização na regra de encaminhamento de todos os balanceadores de carga de aplicativo com um esquema de balanceamento de carga de EXTERNAL_MANAGED ou INTERNAL_MANAGED. Os seguintes balanceadores de carga de aplicativo são compatíveis com políticas de autorização:

• Balanceadores de carga de aplicativos externos globais

• Balanceadores de carga de aplicativo externos regionais
• Balanceadores de carga de aplicativo internos regionais

• Balanceadores de carga de aplicativo internos entre regiões

Regras da política de autorização

Uma política de autorização consiste em uma lista de regras HTTP para corresponder à solicitação de entrada.

Para uma política de autorização com uma ação ALLOW ou DENY, uma regra HTTP (AuthzRule) define as condições que determinam se o tráfego pode passar pelo balanceador de carga. É necessário ter pelo menos uma regra HTTP.

Para uma política de autorização com uma ação CUSTOM, uma regra HTTP (AuthzRule) define as condições que determinam se o tráfego é delegado ao provedor personalizado para autorização. Um provedor personalizado é obrigatório, enquanto as regras HTTP são opcionais.

Uma correspondência de política ocorre quando pelo menos uma regra HTTP corresponde à solicitação ou quando nenhuma regra HTTP é definida na política.

Uma regra HTTP de política de autorização consiste nos seguintes campos:

• from: especifica a identidade do cliente permitida pela regra. A identidade pode ser derivada de um certificado de cliente em uma conexão TLS mútua ou pode ser a identidade ambiente associada à instância de máquina virtual (VM) do cliente, como de uma conta de serviço ou uma tag segura.
• to: especifica as operações permitidas pela regra, como os URLs que podem ser acessados ou os métodos HTTP permitidos.
• when: especifica outras restrições que precisam ser atendidas. É possível usar expressões da Common Expression Language (CEL) para definir as restrições.

Ações da política de autorização

Ao avaliar uma solicitação, uma política de autorização especifica a ação (AuthzAction) a ser aplicada. Uma política de autorização precisa ter pelo menos uma ação, que pode ser uma das seguintes:

• ALLOW: permite que a solicitação passe para o back-end se ela corresponder a qualquer uma das regras especificadas em uma política ALLOW. Se houver políticas ALLOW, mas não houver correspondência, a solicitação será negada. Em outras palavras, a solicitação será negada se nenhuma das políticas de autorização configuradas com uma ação ALLOW corresponder a ela. No Cloud Logging, essa ação é registrada como denied_as_no_allow_policies_matched_request.

  Para que uma ação ALLOW seja aplicada, você precisa de pelo menos uma regra HTTP.

• DENY: nega a solicitação se ela corresponder a qualquer uma das regras especificadas em uma política DENY. Se houver políticas DENY, mas nenhuma correspondência, a solicitação será permitida. Em outras palavras, a solicitação será permitida se nenhuma das políticas de autorização configuradas com uma ação DENY corresponder a ela. No Cloud Logging, essa ação é registrada como allowed_as_no_deny_policies_matched_request.

  Para que uma ação de DENY seja aplicada, você precisa de pelo menos uma regra HTTP.

• CUSTOM: delega a decisão de autorização a um provedor de autorização personalizado, como IAP ou extensões de serviço. Para saber mais, consulte Delegar decisões de autorização.

  Se houver regras HTTP configuradas para uma política CUSTOM, a solicitação precisará corresponder às regras HTTP para invocar o provedor personalizado. No entanto, se nenhuma regra HTTP estiver definida, a política de autorização sempre vai delegar a decisão de autorização a um provedor de autorização personalizado. Para saber mais, consulte os exemplos em Política de autorização para delegar decisões de autorização.

Ordem de avaliação da política de autorização

Uma política de autorização oferece suporte a políticas CUSTOM, DENY e ALLOW para controle de acesso. Quando várias políticas de autorização estão associadas a um único recurso, a política CUSTOM é avaliada primeiro, depois a DENY e, por fim, a ALLOW. A avaliação é determinada pelas seguintes regras:

1. Se houver uma política CUSTOM que corresponda à solicitação, ela será avaliada usando um provedor de autorização personalizado.CUSTOM Se o provedor personalizado rejeitar a solicitação, ela será negada. As políticas DENY ou ALLOW não são avaliadas, mesmo que alguma delas esteja configurada.

2. Se houver alguma política DENY que corresponda à solicitação, ela será negada. Nenhuma política de ALLOW é avaliada, mesmo que esteja configurada.

3. Se não houver políticas ALLOW, a solicitação será permitida.

4. Se alguma das políticas ALLOW corresponder à solicitação, permita-a.

5. Se houver políticas ALLOW, mas não houver correspondência, a solicitação será negada. Em outras palavras, a solicitação é negada por padrão se nenhuma das AuthzPolicies configuradas com a ação ALLOW corresponder a ela.

Para balanceadores de carga de aplicativo externos regionais, balanceadores de carga de aplicativo internos regionais e Secure Web Proxy, os serviçosGoogle Cloud que oferecem suporte a perfis de política, a ordem de avaliação da política de autorização é a seguinte:

1. Se houver uma política de autorização de solicitação personalizada (REQUEST_AUTHZ) que corresponda à solicitação, a política REQUEST_AUTHZ será avaliada usando um provedor de autorização personalizado. Se o provedor personalizado rejeitar a solicitação, ela será negada. As políticas DENY, ALLOW e CONTENT_AUTHZ não são avaliadas, mesmo que alguma delas esteja configurada.

2. Se houver alguma política DENY que corresponda à solicitação, ela será negada. As políticas ALLOW e CONTENT_AUTHZ não são avaliadas, mesmo que estejam configuradas.

3. Se não houver políticas ALLOW, a solicitação vai para a avaliação de autorização de conteúdo (CONTENT_AUTHZ).

4. Se alguma das políticas ALLOW corresponder à solicitação, ela passará para a avaliação de CONTENT_AUTHZ.

5. Se houver políticas ALLOW, mas não houver correspondência, a solicitação será negada. As políticas CONTENT_AUTHZ não são avaliadas.

6. Se houver uma política CONTENT_AUTHZ que corresponda à solicitação, ela será avaliada por último. Se o provedor personalizado rejeitar a solicitação, ela será negada.

Perfis de política em políticas de autorização

Visualizar

Este recurso está sujeito aos Termos das Soluções Pré-GA na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Os perfis de política em políticas de autorização são compatíveis com os seguintes serviços do Google Cloud :

• Balanceadores de carga de aplicativo externos regionais
• Balanceadores de carga de aplicativo internos regionais
• Proxy seguro da Web

Um perfil de política (PolicyProfile) em uma política de autorização é dos seguintes tipos:

• Perfil de autorização de solicitação (REQUEST_AUTHZ): depende de informações nos cabeçalhos de solicitação HTTP para permitir ou negar o tráfego.
• Perfil de autorização de conteúdo (CONTENT_AUTHZ): oferece segurança e filtragem com base em conteúdo para bloquear ataques de injeção de comandos, evitar vazamentos de dados sensíveis e filtrar conteúdo nocivo.

É possível configurar uma política de autorização com um perfil REQUEST_AUTHZ ou CONTENT_AUTHZ, mas não ambos. Se um perfil de política não for especificado, a política de autorização usará o perfil REQUEST_AUTHZ por padrão.

Solicitar perfil de autorização

As políticas de autorização que usam o perfil de política REQUEST_AUTHZ podem avaliar decisões de acesso para tráfego de entrada diretamente ou delegar essas decisões. É possível delegar decisões de acesso ao Identity-Aware Proxy ou a um mecanismo de autorização personalizado usando uma extensão de autorização. O perfil de política REQUEST_AUTHZ usa informações nos cabeçalhos de solicitação HTTP para permitir ou negar uma solicitação.

Uma política de autorização com o perfil de política REQUEST_AUTHZ pode ter uma ação ALLOW, DENY ou CUSTOM aplicada à solicitação. Uma ação de ALLOW ou DENY significa que a decisão de acesso é avaliada diretamente, enquanto uma ação de CUSTOM significa que a decisão de acesso é delegada.

Quando a decisão de acesso é delegada, uma política de autorização, configurada na regra de encaminhamento do balanceador de carga, aponta para uma extensão de autorização de solicitação que é executada em um serviço de back-end de callout. Para cada solicitação de autorização, o balanceador de carga encaminha os cabeçalhos de solicitação para a extensão de autorização usando o protocolo ext_proc ou ext_authz do Envoy. Dependendo da resposta da extensão, o proxy do balanceador de carga encaminha a solicitação para o serviço de back-end ou a rejeita.

Se um perfil de política não for especificado, a política de autorização usará o perfil de autorização de solicitação (REQUEST_AUTHZ) por padrão.

Perfil de autorização de conteúdo

As políticas de autorização que usam o perfil de política CONTENT_AUTHZ podem ser usadas para fazer uma inspeção detalhada dos payloads do aplicativo para permitir ou negar solicitações ou alterar as solicitações ou respostas, conforme necessário. Você pode delegar decisões de acesso ao Model Armor ou à sua própria extensão de higienização de conteúdo.

Uma política de autorização com o perfil de política CONTENT_AUTHZ só pode ter uma ação CUSTOM aplicada à solicitação. Isso significa que a solicitação não pode ser avaliada diretamente e precisa ser delegada.

Uma política de autorização, configurada na regra de encaminhamento do balanceador de carga, aponta para uma extensão de autorização de conteúdo. Para cada solicitação de autorização, o balanceador de carga encaminha o conteúdo completo da solicitação e da resposta, que inclui cabeçalhos, corpo e trailers, usando o protocolo ext_proc do Envoy no modo de streaming full duplex (FULL_DUPLEX_STREAMED) para a extensão de autorização de conteúdo. Dependendo da resposta da extensão, o proxy do balanceador de carga encaminha a solicitação para o destino ou a rejeita. O destino, no caso de uma solicitação, é o serviço de back-end do balanceador de carga e, no caso de uma resposta, é o cliente.

Delegar decisões de autorização

As políticas de autorização podem ser avaliadas diretamente ou delegadas. Para decisões de autorização complexas que não podem ser expressas usando uma política de autorização, crie uma política com uma ação CUSTOM e delegue a decisão a um serviço gerenciado pelo Google ou pelo usuário usando extensões de serviço.

• Serviço gerenciado pelo Google
  • Model Armor
  • Identity-Aware Proxy
• Serviço gerenciado pelo usuário
  • um serviço de back-end Google Cloud
  • um serviço acessível por um nome de domínio totalmente qualificado (FQDN) que oferece suporte ao protocolo ext_proc ou ext_authz do Envoy

A tabela a seguir resume os diferentes serviços a que uma decisão de autorização pode ser delegada por Service Extensions.

Política de autorização	Avaliado diretamente	Delegado às extensões de serviço (extensão de autorização)
		Serviços gerenciados pelo Google		Serviços gerenciados pelo usuário
		Model Armor	Identity-Aware Proxy	Google Cloud serviço de back-end	Serviço baseado em FQDN
Perfil do REQUEST_AUTHZ
Perfil do CONTENT_AUTHZ

Extensões de serviço

É possível usar políticas de autorização para delegar decisões de autorização a Service Extensions, especificamente do tipo extensão de autorização. As extensões de autorização aceitam chamadas para injetar lógica personalizada em balanceadores de carga de aplicativo Google Cloud. Com esse recurso, é possível escrever seu próprio código para realizar várias atividades no tráfego processado por um balanceador de carga, como reescritas de cabeçalho, segurança incremental, geração de registros personalizados e autenticação de usuário personalizada.

Com os Service Extensions callouts, você instrui o balanceador de carga a encaminhar o tráfego do caminho de processamento de dados de balanceamento de carga usando chamadas gRPC para um serviço de destaque, que pode ser gerenciado pelo usuário ou pelo Google. Os diferentes serviços de callout são definidos na tabela anterior. Esses serviços de callout executam a extensão de autorização e podem aplicar várias políticas ou funções antes de retornar o tráfego ao balanceador de carga para processamento adicional. O diagrama a seguir mostra esse processo.

Política de autorização que delega a decisão de autorização por uma extensão de autorização (clique para ampliar).

Para delegar decisões de autorização a uma extensão de autorização, crie uma extensão de autorização (AuthzExtension) que seja executada em um serviço de callout. Em seguida, é possível criar uma política de autorização com uma ação CUSTOM e apontá-la para a extensão de autorização que você criou. A extensão de autorização pode ser usada para realizar autorização no nível da solicitação (REQUEST_AUTHZ) e limpeza de conteúdo (CONTENT_AUTHZ).

Para saber mais sobre como delegar a decisão de autorização a um serviço de back-endGoogle Cloud gerenciado pelo usuário ou a um serviço baseado em FQDN, consulte Delegar a decisão de autorização a um serviço gerenciado pelo usuário.

Extensões de autorização no caminho de processamento de dados

Ao delegar uma decisão de autorização para Service Extensions, especificamente do tipo extensão de autorização, observe a seguinte terminologia:

• Quando uma política de autorização personalizada com um perfil de política REQUEST_AUTHZ aponta para uma extensão de autorização (AuthzExtension), ela é chamada de extensão de autorização de solicitação.

• Quando uma política de autorização com um perfil de política CONTENT_AUTHZ aponta para uma extensão de autorização (AuthzExtension), ela é chamada de extensão de autorização de conteúdo.

No caminho de processamento de solicitações, uma extensão de autorização de solicitação é invocada primeiro, seguida pela avaliação da política de negação e permissão, depois a extensão de autorização de conteúdo e, por fim, a extensão de tráfego. Uma extensão de autorização de conteúdo também pode ser invocada no caminho de processamento da resposta. O diagrama a seguir mostra a sequência em que diferentes extensões são invocadas.

Observação: a extensão de autorização de solicitação é invocada somente quando os cabeçalhos de solicitação chegam. O corpo da solicitação, os cabeçalhos e o corpo da resposta não ficam visíveis para a extensão de autorização de solicitação.

Extensão de autorização de solicitação invocada antes de uma extensão de autorização de conteúdo (clique para ampliar).

Pense nas diferentes extensões como hooks que são acionados em determinados pontos do caminho de processamento de dados. Para saber mais sobre as diferentes extensões, consulte Pontos de extensibilidade no caminho de dados de balanceamento de carga na documentação de Service Extensions.

Model Armor

É possível usar políticas de autorização para ativar o Model Armor e aplicar proteções de IA que evitam a geração de conteúdo nocivo, a injeção de comandos e o vazamento de dados.

Para isso, crie uma extensão de autorização (AuthzExtension) que é executada em um serviço do Model Armor. Em seguida, crie uma política de autorização com uma ação CUSTOM e um perfil CONTENT_AUTHZ que aponte para a extensão de autorização criada.

Para saber mais sobre como delegar a autorização ao Model Armor, consulte Delegar a decisão de autorização ao Model Armor.

Identity-Aware Proxy

Você pode delegar decisões de autorização ao Identity-Aware Proxy. O IAP verifica a identidade do usuário e o contexto da solicitação para determinar se um usuário pode acessar um aplicativo ou um recurso.

Para balanceadores de carga de aplicativo externos globais e balanceadores de carga de aplicativo internos entre regiões, não é possível delegar a decisão de autorização ao IAP por uma extensão de autorização.

Para balanceadores de carga de aplicativo externos regionais e balanceadores de carga de aplicativo internos regionais, é possível configurar uma política de autorização para delegar a decisão de autorização ao IAP por uma extensão de autorização.

Para saber mais sobre como usar o IAP como um serviço de autorização, consulte Delegar a decisão de autorização ao Identity-Aware Proxy.

Política de autorização baseada em principais

Observação: a política de autorização com base em principais não é compatível com balanceadores de carga de aplicativo externos globais.

Para identificar a origem do tráfego com alta granularidade, configure políticas de autorização com base em identidades derivadas do certificado de um cliente. Esse método exige que o mTLS de front-end esteja ativado no balanceador de carga e usa os seguintes atributos de certificado como um seletor principal para identificação:

• SANs de URI do certificado do cliente (CLIENT_CERT_URI_SAN)
• SANs de nome DNS do certificado do cliente (CLIENT_CERT_DNS_NAME_SAN)
• Nome comum do certificado do cliente (CLIENT_CERT_COMMON_NAME)

Se nenhum seletor principal for especificado para identificação, CLIENT_CERT_URI_SAN será usado como o seletor principal padrão. Isso significa que as SANs de URI do certificado do cliente são avaliadas ao tomar decisões de autorização.

Para que a autorização baseada em principal funcione, as seguintes condições precisam ser atendidas:

• O mTLS de front-end precisa estar ativado. Se o mTLS de front-end não estiver ativado, o cliente não vai apresentar um certificado. Como resultado, nenhuma regra baseada em principais na política de autorização encontra informações de certificado para avaliação. Por exemplo, uma regra que verifica CLIENT_CERT_URI_SAN encontra um valor vazio.

• É necessário ter um certificado do cliente válido. Mesmo com o mTLS ativado, um certificado do cliente não é usado para autorização se a conexão foi estabelecida com um certificado ausente ou inválido. Esse cenário ocorre quando o modo de validação do cliente mTLS está definido como o modo permissivo ALLOW_INVALID_OR_MISSING_CLIENT_CERT. Nesse caso também, nenhuma regra baseada em principais na política de autorização encontra informações de certificado para avaliação. Por exemplo, uma regra que verifica CLIENT_CERT_URI_SAN encontra um valor vazio.

Impacto dos limites de tamanho dos atributos

As decisões de autorização são sensíveis ao tamanho dos atributos do certificado do cliente. Uma solicitação é rejeitada se um atributo exceder o limite de tamanho e a política estiver configurada para validar esse atributo específico.

Uma rejeição pode ocorrer nas seguintes condições:

• A política valida em relação a CLIENT_CERT_URI_SAN, e os SANs do URI do certificado excedem o limite de tamanho.
• A política valida em relação a CLIENT_CERT_DNS_NAME_SAN, e os SANs de nome DNS do certificado excedem o limite de tamanho.
• A política valida CLIENT_CERT_COMMON_NAME, e o assunto do certificado (que contém o nome comum) excede o limite de tamanho.

Se um atributo de certificado exceder o limite de tamanho, mas não for explicitamente validado pelo seletor principal da política, a solicitação ainda será avaliada de acordo com as regras principais configuradas. Por exemplo, se uma política for configurada para validar apenas o CLIENT_CERT_DNS_NAME_SAN, uma solicitação de um cliente com SANs de URI grandes não será rejeitada por esse motivo. A política avalia a solicitação com base nas SANs de nome DNS.

Para ver um exemplo de política de autorização baseada em principais, consulte Política de autorização para negar solicitações.

Política de autorização baseada em contas de serviço ou tags seguras

Uma política de autorização baseada em contas de serviço ou tags seguras é compatível com os seguintes balanceadores de carga:

• Balanceadores de carga de aplicativo internos regionais
• Balanceadores de carga de aplicativo internos entre regiões

Observação: não é possível aplicar políticas de autorização com base em contas de serviço ou tags em balanceadores de carga de aplicativo externos.

Com as políticas de autorização, baseadas em contas de serviço e tags seguras, é possível aplicar regras de segurança com base em quem ou o que está enviando o tráfego, e não apenas no endereço IP. Isso resulta em uma mudança de regras baseadas em IP para controles baseados em identidade usando contas de serviço e tags seguras para definir o perímetro de segurança. Por exemplo, é possível criar uma política de autorização para fazer o seguinte:

• negar a uma VM do Compute Engine com uma conta de serviço específica (my-sa-123@PROJECT_ID.iam.gserviceaccount.com) o acesso ao caminho /api/payments.

• permitir que as VMs do Compute Engine com uma tag segura (par de chave-valor environment: prod) alcancem o caminho /api/payments.

É possível aplicar políticas de autorização com base em contas de serviço ou tags seguras anexadas a vários serviços do Google Cloud . Todo o tráfego originado desses serviços do Google Cloud , que estão vinculados a uma conta de serviço específica ou a uma tag segura, pode ser permitido, negado ou delegado para avaliação posterior.

A tabela a seguir lista os vários serviços Google Cloud que aceitam o uso de contas de serviço e tags seguras.

Serviço doGoogle Cloud	Suporte para contas de serviço	Suporte a tags seguras
Máquina virtual (VM) do Compute Engine
Nó do Google Kubernetes Engine (GKE)
Contêiner do Google Kubernetes Engine (GKE)	^1	^1
VPC direta para o Cloud Run		^1
Conector de acesso VPC sem servidor	^2	^2
Cloud VPN	^1	^1
Cloud Interconnect no local	^1	^1
Balanceador de carga de aplicativo	^3	^3
Balanceador de carga de rede	^3	^3

¹ Indisponível com Google Cloud.

² O endereço IP de origem é exclusivo e pode ser usado.

³ As contas de serviço e as tags não são compatíveis quando os balanceadores de carga de aplicativo e de rede atuam como fontes de tráfego em uma arquitetura em camadas.

A tabela a seguir lista as diferentes arquiteturas de nuvem privada virtual (VPC) que oferecem suporte ao uso de contas de serviço e tags.

VPC	Arquitetura da VPC	Suporte
Na VPC	Entre projetos (VPC compartilhada)
Na VPC	Entre regiões
Entre VPCs	Link de peering cruzado (VPC de peering)
Entre VPCs	Private Service Connect entre projetos
Entre VPCs	Spokes do Network Connectivity Center entre redes

Para saber mais sobre como configurar uma política de autorização baseada em contas de serviço e tags anexadas a um recurso Google Cloud , consulte Política de autorização baseada em contas de serviço ou tags.

Cotas

Para informações sobre cotas de políticas de autorização, consulte cotas e limites para políticas de autorização.

Preços

Para informações sobre preços, consulte Preços.

A seguir

• Configurar políticas de autorização para balanceadores de carga de aplicativo

• Configurar uma extensão de autorização