Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
A autenticação mútua, ou autenticação de cliente, permite que o Application Gateway autentique o cliente que envia pedidos. Normalmente, só o cliente autentica o Gateway de Aplicação. A autenticação mútua permite que tanto o cliente como o Gateway de Aplicações se autentiquem mutuamente.
Nota
Recomendamos usar o TLS 1.2 com autenticação mútua porque o TLS 1.2 será obrigatório no futuro.
Autenticação mútua
O Application Gateway suporta autenticação mútua baseada em certificados. Pode carregar certificados de CA de clientes de confiança para o Application Gateway, e o gateway usa esses certificados para autenticar os clientes que enviam pedidos. Com o aumento dos casos de uso de IoT e o aumento dos requisitos de segurança em vários setores, a autenticação mútua oferece uma forma de gerir e controlar quais os clientes que podem comunicar com o seu Application Gateway.
O Application Gateway oferece as seguintes duas opções para validar certificados do cliente:
Modo TLS mútuo de passagem
No modo de passagem TLS mútuo (mTLS), o Application Gateway solicita um certificado de cliente durante o handshake TLS, mas não termina a ligação se o certificado estiver em falta ou inválido. A ligação ao backend prossegue independentemente da presença ou validade do certificado. Se for fornecido um certificado, o Application Gateway pode encaminhá-lo para o backend, se a aplicação o exigir. O serviço de backend é responsável por validar o certificado do cliente.
Benefícios do modo passthrough mTLS
O modo passthrough mTLS oferece as seguintes vantagens:
- Configuração simplificada do gateway: Não é necessário o carregamento de certificados da CA ao nível do gateway.
- Autenticação flexível: Suporta cenários de tráfego misto onde alguns clientes usam certificados e outros utilizam autenticação baseada em tokens.
- Aplicação de políticas backend: Permite que a sua aplicação backend implemente lógica e políticas personalizadas de validação de certificados.
- Redução da sobrecarga do gateway: Descarrega a validação do certificado para o backend, reduzindo o processamento no gateway.
- Suporte de migração gradual: Permite a implementação faseada do mTLS sem perturbar os padrões de tráfego existentes.
Para encaminhar os certificados do cliente para o backend, configure variáveis do servidor. Para mais informações, veja Variáveis do servidor.
Configurar o modo mTLS passthrough
Pode configurar o modo de passagem mTLS usando o portal do Azure ou modelos ARM.
Para configurar o modo de passagem mTLS no portal do Azure:
Navegue até ao recurso Application Gateway.
Em Definições, selecione perfis SSL.
Selecionar + Adicionar para criar um novo perfil SSL.
Introduza um nome para o seu perfil SSL.
No separador Autenticação do Cliente , selecione Passthrough.
No modo Passthrough, o certificado do cliente é opcional. O servidor backend é responsável pela autenticação do cliente.
Configure as definições da Política SSL conforme necessário.
Selecione Adicionar para criar o perfil SSL.
Associe o perfil SSL ao seu ouvinte HTTPS.
Nota
O suporte para PowerShell e CLI para configuração de passagem está atualmente indisponível.
Modo estrito de Mutual TLS
No modo TLS restrito mútuo, o Application Gateway impõe a autenticação do certificado do cliente durante o handshake TLS, exigindo um certificado cliente válido. Para ativar o modo estrito, carregue um certificado de CA cliente de confiança que contenha uma CA raiz e, opcionalmente, CAs intermédias como parte do perfil SSL. Associe este perfil SSL a um ouvinte para impor autenticação mútua.
Configurar o modo restrito TLS mútuo
Para configurar o modo estrito de autenticação mútua, carregue um certificado de CA cliente de confiança como parte da autenticação do cliente de um perfil SSL. Depois, associe o perfil SSL a um ouvinte para completar a configuração. O certificado do cliente que carregar deve sempre incluir um certificado de Autoridade de Certificação (CA) raiz. Pode carregar uma cadeia de certificados, mas a cadeia deve incluir um certificado de CA raiz além de quaisquer certificados intermédios de CA. O tamanho máximo de cada ficheiro carregado tem de ser igual ou inferior a 25 KB.
Por exemplo, se o seu certificado de cliente contiver um certificado de CA raiz, vários certificados de CA intermédios e um certificado folha, carregue o certificado de CA raiz e todos os certificados intermédios para o Application Gateway num só ficheiro. Para mais informações sobre como extrair um certificado de CA de cliente confiável, consulte Extrair certificados de CA de cliente de confiança.
Se estiveres a carregar uma cadeia de certificados com certificados de CA raiz e certificados intermédios, carrega a cadeia de certificados como ficheiro PEM ou CER para o gateway.
Importante
Carregue toda a cadeia completa de certificados de uma CA cliente confiável para o "Application Gateway" quando usar autenticação mútua.
Cada perfil SSL pode suportar até 100 cadeias de certificados de CA de clientes confiáveis. Um único Application Gateway pode suportar um total de 200 cadeias de certificados de CA de clientes confiáveis.
Nota
- A autenticação mútua está disponível apenas em SKUs Standard_v2 e WAF_v2.
- A configuração de autenticação mútua para ouvintes de protocolos TLS está atualmente disponível através da API REST, PowerShell e CLI.
Certificados suportados para autenticação mútua em modo estrito TLS
O Application Gateway oferece suporte a certificados emitidos por autoridades de certificação públicas e privadas.
- Certificados CA emitidos por autoridades certificadoras bem conhecidas: Certificados intermédios e raiz são frequentemente encontrados em lojas de certificados confiáveis e permitem ligações confiáveis com pouca ou nenhuma configuração adicional no dispositivo.
- Certificados de CA emitidos por autoridades certificadoras estabelecidas pela organização: Estes certificados são normalmente emitidos de forma privada através da sua organização e não são confiáveis por outras entidades. Importar certificados intermédios e raiz nos armazenamentos de certificados confiáveis para que os clientes possam estabelecer confiança na cadeia.
Nota
Quando emitir certificados de clientes de autoridades certificadoras bem estabelecidas, considere trabalhar com a autoridade certificadora para verificar se é possível emitir um certificado intermédio para a sua organização. Esta abordagem previne a autenticação inadvertida de certificados de clientes entre organizações.
Validação da autenticação de cliente no modo estrito de TLS mútuo
Verificar o DN do certificado do cliente
Podes verificar o emissor imediato do certificado do cliente e só permitir que o Application Gateway confie nesse emissor. Esta opção está desativada por defeito, mas pode ativar através do portal, PowerShell ou CLI do Azure.
Se ativar o Application Gateway para verificar o emissor imediato do certificado cliente, os seguintes cenários descrevem como a DN do emissor do certificado cliente é extraída dos certificados carregados:
-
Cenário 1: Cadeia de certificados inclui certificado raiz, certificado intermédio e certificado folha.
- O nome do assunto do certificado intermédio é extraído como DN do emissor do certificado do cliente.
-
Cenário 2: A cadeia de certificados inclui certificado raiz, certificado intermediário1, certificado intermediário2 e certificado folha.
- O nome do assunto do certificado intermediate2 é extraído como DN do emissor do certificado do cliente.
-
Cenário 3: A cadeia de certificados inclui certificado raiz e certificado terminal.
- O nome do assunto do certificado raiz é extraído como DN do emissor do certificado cliente.
-
Cenário 4: Múltiplas cadeias de certificados do mesmo comprimento no mesmo ficheiro. Chain 1 inclui certificado raiz, certificado intermediário1 e certificado folha. Chain 2 inclui certificado raiz, certificado intermediário2 e certificado folha.
- O assunto do certificado intermediate1 é extraído como o DN do emissor do certificado do cliente.
-
Cenário 5: Múltiplas cadeias de certificados de comprimentos diferentes no mesmo ficheiro. Chain 1 inclui o certificado raiz, o certificado intermediário 1 e o certificado folha. Chain 2 inclui certificado raiz, certificado intermediário 2, certificado intermediário 3 e certificado final.
- O nome do sujeito do certificado intermediate3 é extraído como o DN do emissor do certificado do cliente.
Importante
Recomendamos carregar apenas uma cadeia de certificados por ficheiro. Esta recomendação é especialmente importante se ativar a opção de verificação de DN do certificado do cliente. Carregar múltiplas cadeias de certificados num único ficheiro resulta no cenário quatro ou cinco, que pode causar problemas mais tarde quando o certificado do cliente apresentado não corresponder ao DN do emissor do certificado do cliente que o Gateway de Aplicação extraiu das cadeias.
Para mais informações sobre como extrair cadeias de certificados de CA de cliente confiáveis, consulte Extrair cadeias de certificados de CA de cliente confiáveis.
Variáveis de servidor
Com autenticação TLS mútua, pode usar variáveis adicionais do servidor para passar informações sobre o certificado do cliente aos servidores backend atrás do Application Gateway. Para mais informações sobre quais as variáveis de servidor disponíveis e como as utilizar, consulte Variáveis de servidor.
Revogação do certificado
Quando um cliente inicia uma ligação a um Gateway de Aplicações configurado com autenticação TLS mútua, a cadeia de certificados e o nome distinto do emissor podem ser validados. Além disso, o estado de revogação do certificado do cliente pode ser verificado com o OCSP (Protocolo de Estado de Certificado Online). Durante a validação, o certificado apresentado pelo cliente é verificado através do respondedor OCSP definido na sua extensão de Acesso a Informação da Autoridade (AIA). Se o certificado do cliente for revogado, o Application Gateway responde ao cliente com um código de estado HTTP 400 e uma razão. Se o certificado for válido, o pedido continua a ser processado pelo Application Gateway e encaminhado para o pool de backend definido.
Pode ativar a revogação de certificados do cliente através da API REST, modelo ARM, Bicep, CLI ou PowerShell.
Para configurar a verificação de revogação do cliente num Application Gateway existente usando Azure PowerShell, use os seguintes comandos:
# Get Application Gateway configuration
$AppGw = Get-AzApplicationGateway -Name "ApplicationGateway01" -ResourceGroupName "ResourceGroup01"
# Create new SSL Profile
$profile = Get-AzApplicationGatewaySslProfile -Name "SslProfile01" -ApplicationGateway $AppGw
# Verify Client Cert Issuer DN and enable Client Revocation Check
Set-AzApplicationGatewayClientAuthConfiguration -SslProfile $profile -VerifyClientCertIssuerDN -VerifyClientRevocation OCSP
# Update Application Gateway
Set-AzApplicationGateway -ApplicationGateway $AppGw
Para uma lista de todas as referências ao Azure PowerShell para configuração de autenticação de clientes no Application Gateway, consulte os seguintes artigos:
Para verificar se o estado de revogação do OCSP foi avaliado para o pedido do cliente, os registos de acesso contêm uma propriedade chamada sslClientVerify que mostra o estado da resposta do OCSP.
É fundamental que o respondedor OCSP esteja altamente disponível e que a conectividade de rede entre o Application Gateway e o respondedor seja possível. Se o Gateway de Aplicação não conseguir resolver o nome de domínio totalmente qualificado (FQDN) do respondente definido, ou se a conectividade de rede for bloqueada para ou desde o respondedor, o estado de revogação do certificado falha e o Gateway de Aplicação devolve uma resposta HTTP 400 ao cliente solicitante.
Nota
As verificações OCSP são validadas via cache local com base no nextUpdate tempo definido por uma resposta OCSP anterior. Se a cache OCSP não estivesse preenchida a partir de um pedido anterior, a primeira resposta pode falhar. Ao tentar novamente o cliente, a resposta deve ser encontrada na cache e o pedido é processado conforme esperado.
Notas
- A verificação de revogação via CRL não é suportada.
- A verificação de revogação do cliente foi introduzida na versão da API 2022-05-01.
Conteúdo relacionado
Depois de aprender sobre autenticação mútua, vá a Configurar Application Gateway com autenticação mútua no PowerShell para criar um Application Gateway que use autenticação mútua.