Vista geral da política de autorização

Uma política de autorização (AuthzPolicy) aplicada na regra de encaminhamento dos equilibradores de carga de aplicações define regras que especificam a origem do tráfego de entrada e as operações permitidas ou restritas para essa origem. Além disso, a política de autorização descreve as condições em que uma regra se aplica e especifica uma ação para permitir, recusar ou avaliar mais detalhadamente o tráfego.

As políticas de autorização permitem-lhe estabelecer verificações de controlo de acesso para o tráfego de entrada nos equilibradores de carga de aplicações. Os pedidos que passam nestas verificações são encaminhados para os serviços de back-end. Os pedidos que falham estas verificações são terminados com uma resposta não autorizada.

As políticas de autorização podem ser configuradas na regra de encaminhamento de todos os balanceadores de carga de aplicações com um esquema de balanceamento de carga de EXTERNAL_MANAGED ou INTERNAL_MANAGED. Os seguintes equilibradores de carga de aplicações suportam políticas de autorização:

  • Balanceadores de carga de aplicações externos globais

  • Balanceadores de carga de aplicações externos regionais

  • Balanceadores de carga de aplicações internos regionais

  • Balanceadores de carga de aplicações internos entre regiões

Nos equilibradores de carga de aplicações, as políticas de autorização são invocadas depois de avaliar as extensões de rotas, as políticas de segurança de rede (avaliadas pelo Google Cloud Armor), as políticas de partilha de recursos de origem cruzada (CORS) e as políticas do Identity-Aware Proxy (IAP), mas antes de executar ações de gestão de tráfego.

Para saber mais sobre quando as políticas de autorização são invocadas no caminho de processamento de pedidos, consulte o artigo Pontos de extensibilidade no caminho de dados de equilíbrio de carga.

Se quiser usar políticas de autorização para serviços implementados com o Cloud Service Mesh, consulte o artigo Configure a segurança do serviço com o Envoy.

Regras da política de autorização

Uma política de autorização consiste numa lista de regras HTTP a comparar com o pedido recebido.

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 tem autorização para passar pelo balanceador de carga. É necessária, 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 fornecedor personalizado para autorização. É necessário um fornecedor personalizado, enquanto as regras HTTP são opcionais.

Uma correspondência de política ocorre quando, pelo menos, uma regra HTTP corresponde ao pedido ou quando não são definidas regras HTTP na política.

Uma regra HTTP de política de autorização é composta pelos seguintes campos:

  • from: especifica a identidade do cliente permitida pela regra. A identidade pode ser derivada de um certificado de cliente numa ligaçã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 de uma etiqueta segura.
  • to: especifica as operações permitidas pela regra, como os URLs que podem ser acedidos ou os métodos HTTP permitidos.
  • when: especifica restrições adicionais que têm de ser cumpridas. Pode usar expressões do Idioma de expressão comum (IEC) para definir as restrições.

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

Ao avaliar um pedido, uma política de autorização especifica a ação (AuthzAction) a aplicar ao pedido. Uma política de autorização tem de ter, pelo menos, uma ação, que pode ser uma das seguintes:

  • ALLOW: permite que o pedido seja transmitido para o back-end se corresponder a alguma das regras especificadas numa política de ALLOW. Se existirem políticas ALLOW, mas não houver uma correspondência, o pedido é recusado. Por outras palavras, o pedido é recusado se nenhuma das políticas de autorização configuradas com uma ação ALLOW corresponder ao pedido. No Cloud Logging, esta ação é registada como denied_as_no_allow_policies_matched_request.

    Para aplicar uma ação ALLOW, precisa de, pelo menos, uma regra HTTP.

  • DENY: nega o pedido se este corresponder a alguma das regras especificadas numa política de DENY. Se existirem políticas DENY, mas não houver correspondência, o pedido é permitido. Por outras palavras, o pedido é permitido se nenhuma das políticas de autorização configuradas com uma ação DENY corresponder ao pedido. No Cloud Logging, esta ação é registada como allowed_as_no_deny_policies_matched_request.

    Para aplicar uma ação DENY, precisa de, pelo menos, uma regra HTTP.

  • CUSTOM: delega a decisão de autorização num fornecedor de autorização personalizado, como o IAP ou as extensões de serviços. Para saber mais, consulte o artigo Use políticas de autorização para delegar decisões de autorização.

    Se existirem regras HTTP configuradas para uma política CUSTOM, o pedido tem de corresponder às regras HTTP para invocar o fornecedor personalizado. No entanto, se não forem definidas regras HTTP, a política de autorização delega sempre a decisão de autorização num fornecedor de autorização personalizado. Para saber mais, consulte o exemplo seguinte, em que não são definidas regras HTTP e a política de autorização delega a decisão de autorização a um IAP:

    Crie a política de autorização e ative o IAP

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

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

  1. Se existir uma política CUSTOM que corresponda ao pedido, a política CUSTOM é avaliada através dos fornecedores de autorização personalizados, e o pedido é recusado se o fornecedor o rejeitar. As políticas DENY ou ALLOW não são avaliadas, mesmo que alguma esteja configurada.

  2. Se existirem DENYpolíticas que correspondam ao pedido, o pedido é recusado. As políticas ALLOW não são avaliadas, mesmo que estejam configuradas.

  3. Se não existirem políticas ALLOW, o pedido é permitido.

  4. Se alguma das políticas ALLOW corresponder ao pedido, permita o pedido.

  5. Se existirem políticas ALLOW, mas não houver uma correspondência, o pedido é recusado. Por outras palavras, o pedido é recusado por predefinição se nenhuma das AuthzPolicies configuradas com a ação ALLOW corresponder ao pedido.

Use políticas de autorização para delegar decisões de autorização

Para decisões de autorização complexas que não podem ser expressas através da política de autorização, delegue a decisão de autorização em fornecedores de autorização personalizados, como o Identity-Aware Proxy (IAP), ou crie a sua própria extensão de autorização criada com extensões de serviços. Isto é útil quando quer usar o seu motor de autorização no local ou fornecedores de identidade de terceiros através da IAP.

  • IAP: configure o IAP para controlar o acesso a aplicações atrás das regras de encaminhamento do balanceador de carga de aplicações. O IAP valida a identidade e o contexto do utilizador para determinar o acesso. Também pode autenticar tokens de contas de serviço da gestão de identidade e de acesso (IAM) e avaliar políticas de IAM, protegendo o acesso a contentores de back-end expostos a partir do Application Load Balancer. Para mais informações, consulte os artigos Delegue a autorização ao IAP e ao IAM.

    Pode optar por delegar a autenticação no IAP e no IAM nos seguintes cenários:

    • Use o IAM para a gestão de autorizações.
    • Implemente o acesso sensível ao contexto.
    • Use a autenticação baseada no navegador para aplicações Web que requerem autenticação interativa.

  • Extensões de serviço: delegue as decisões de autorização no seu motor de autorização personalizado em execução em Google Cloud instâncias de VM ou no local. Isto oferece flexibilidade para políticas de autorização complexas que não são cobertas por políticas incorporadas. Para mais informações, consulte o artigo Configure uma extensão de autorização.

Política de autorização baseada em responsáveis

Para identificar a origem do tráfego com grande detalhe, pode configurar políticas de autorização com base em identidades derivadas do certificado de um cliente. Este método requer 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 do URI do certificado de cliente (CLIENT_CERT_URI_SAN)
  • SANs de nome DNS do certificado de cliente (CLIENT_CERT_DNS_NAME_SAN)
  • Nome comum do certificado de cliente (CLIENT_CERT_COMMON_NAME)

Se não for especificado nenhum seletor principal para identificação, CLIENT_CERT_URI_SAN é usado como seletor principal predefinido. Isto significa que os SANs do URI do certificado do cliente são avaliados ao tomar decisões de autorização.

Para que a autorização baseada em entidades funcione, têm de se aplicar as seguintes condições:

  • O mTLS de front-end tem de estar ativado. Se o mTLS de front-end não estiver ativado, o cliente não apresenta um certificado. Como resultado, as regras baseadas em diretor na política de autorização não encontram informações de certificado para avaliar. Por exemplo, uma regra que verifique CLIENT_CERT_URI_SAN vê um valor vazio.

  • Tem de existir um certificado de cliente válido. Mesmo com o mTLS ativado, não é usado um certificado de cliente para autorização se a ligação tiver sido estabelecida com um certificado em falta ou inválido. Este cenário ocorre quando o modo de validação do cliente mTLS está definido como o modo permissivo ALLOW_INVALID_OR_MISSING_CLIENT_CERT. Neste caso, as regras baseadas em entidades na política de autorização não encontram informações de certificados para avaliação. Por exemplo, uma regra que verifique CLIENT_CERT_URI_SAN vê 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 de cliente. Um pedido é rejeitado se um atributo exceder o respetivo 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 é validada em relação a CLIENT_CERT_URI_SAN, e os SANs do URI do certificado excedem o limite de tamanho.
  • A política é validada em relação a CLIENT_CERT_DNS_NAME_SAN, e os SANs do nome DNS do certificado excedem o limite de tamanho.
  • A política é validada em relação a CLIENT_CERT_COMMON_NAME, e o assunto do certificado (que contém o nome comum) excede o limite de tamanho.

Se o atributo de um certificado exceder o respetivo limite de tamanho, mas não for validado explicitamente pelo seletor principal da política, o pedido continua a ser avaliado em função das regras principais configuradas. Por exemplo, se uma política estiver configurada para validar apenas o CLIENT_CERT_DNS_NAME_SAN, um pedido de um cliente com SANs de URI demasiado grandes não é rejeitado por esse motivo. A política prossegue para avaliar o pedido com base nos SANs do nome DNS.

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

Pode usar atributos como contas de serviço ou etiquetas para identificar a origem do tráfego para equilibradores de carga de aplicações internos.

Para equilibradores de carga de aplicações internos, pode aplicar políticas de autorização com base em contas de serviço ou etiquetas anexadas a recursos. Google Cloud Qualquer tráfego originário destes Google Cloud recursos associados a uma conta de serviço ou uma etiqueta específica pode ser permitido, recusado ou delegado a um serviço externo.

As tabelas seguintes indicam os recursos de origem e as diferentes arquiteturas da nuvem virtual privada (VPC) que suportam a utilização de contas de serviço e etiquetas.

Fonte Apoio técnico para contas de serviço Suporte de etiquetas
Máquina virtual (VM)
Nó do GKE
Contentor do GKE * *
VPC direta para o Cloud Run *
Conetor do Acesso a VPC sem servidor † †
Cloud VPN * *
Cloud Interconnect no local * *
Balanceador de carga de aplicações
Balanceador de carga de rede

* Não suportado por Google Cloud.

† O endereço IP de origem é exclusivo e pode ser usado em alternativa.

VPC Arquitetura de VPC Apoio técnico
Na VPC Entre projetos (VPC partilhada)
Na VPC Entre regiões
VPC cruzada Link de intercâmbio (VPC de pares)
VPC cruzada Private Service Connect entre projetos
VPC cruzada Hubs do Network Connectivity Center de várias redes

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

Quotas

Para ver informações sobre as quotas das políticas de autorização, consulte o artigo Quotas e limites das políticas de autorização.

Preços

As políticas de autorização não são cobradas durante o período de pré-visualização. No entanto, incorre em custos de rede quando usa balanceadores de carga Google Cloud . Para ver informações de preços, consulte a secção Preços.

O que se segue?