Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
A autenticação mútua, ou autenticação do cliente, permite que o Gateway de Aplicações autentique o cliente que está enviando solicitações. Normalmente, somente o cliente autentica o Gateway de Aplicativo. A autenticação mútua permite que o cliente e o Gateway de Aplicativo se autentiquem.
Observação
É recomendável 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 Gateway de Aplicativo dá suporte à autenticação mútua baseada em certificado. Você pode carregar certificados de AC confiáveis de clientes no Gateway de Aplicações, e o gateway usa esses certificados para autenticar os clientes que enviam solicitações. Com o aumento dos casos de uso de IoT e o aumento dos requisitos de segurança em todos os setores, a autenticação mútua fornece uma maneira de gerenciar e controlar quais clientes podem se comunicar com o Gateway de Aplicativo.
O Gateway de Aplicativo fornece as duas opções a seguir para validar certificados de cliente:
Modo de passagem do TLS mútuo
No modo de passagem do TLS mútuo (mTLS), o Gateway de Aplicativo solicita um certificado de cliente durante o handshake do TLS, mas não encerra a conexão se o certificado estiver ausente ou inválido. A conexão com o back-end continua independentemente da presença ou validade do certificado. Se um certificado for fornecido, o Gateway de Aplicativo poderá encaminhá-lo para o back-end, se exigido pelo aplicativo. O serviço de back-end é responsável por validar o certificado do cliente.
Benefícios do modo de passagem do mTLS
O modo de passagem do mTLS fornece as seguintes vantagens:
- Configuração simplificada do gateway: nenhum upload de certificado de autoridade certificadora é necessário no nível do gateway.
- Autenticação flexível: dá suporte a cenários de tráfego misto em que alguns clientes usam certificados e outros usam autenticação baseada em token.
- Imposição de política de back-end: Permite que seu aplicativo de back-end implemente lógica e políticas personalizadas para validação de certificados.
- Sobrecarga de gateway reduzida: descarrega a validação do certificado para o back-end, reduzindo o processamento no gateway.
- Suporte gradual à migração: permite a distribuição em fases do mTLS sem interromper os padrões de tráfego existentes.
Para encaminhar certificados de cliente para o back-end, configure variáveis de servidor. Para obter mais informações, consulte variáveis de servidor.
Configurar o modo de passagem do mTLS
Você pode configurar o modo de passagem do mTLS usando o portal Azure ou modelos do ARM.
Para configurar o modo de passagem do mTLS no portal Azure:
Acesse o recurso Gateway de Aplicações.
Em Configurações, selecione perfis SSL.
Selecione + Adicionar para criar um novo perfil SSL.
Insira um nome para seu perfil SSL.
Na guia Autenticação do Cliente , selecione Passagem.
No modo Passthrough, o certificado do cliente é opcional. O servidor de back-end é responsável pela autenticação do cliente.
Defina as configurações da Política SSL conforme necessário.
Selecione Adicionar para criar o perfil SSL.
Associe o perfil SSL ao ouvinte HTTPS.
Observação
O suporte do PowerShell e da CLI para a configuração de passthrough não está disponível no momento.
Modo estrito do Mutual TLS
No modo estrito do TLS mútuo, o Gateway de Aplicativo impõe a autenticação de certificado do cliente durante o handshake do TLS, exigindo um certificado do cliente válido. Para habilitar o modo estrito, carregue um certificado de AC do cliente confiável que contenha uma AC raiz e, opcionalmente, CAs intermediárias como parte do perfil SSL. Associe esse perfil SSL a um ouvinte para impor a autenticação mútua.
Configurar o modo estrito do TLS mútuo
Para configurar o modo estrito de autenticação mútua, carregue um certificado CA cliente confiável como parte da autenticação do cliente de um perfil SSL. Em seguida, associe o perfil SSL a um ouvinte para concluir a configuração. O certificado do cliente que você carrega sempre deve incluir um certificado de CA raiz. Você pode carregar uma cadeia de certificados, mas a cadeia deve incluir um certificado raiz da autoridade certificadora, além de quaisquer certificados de AC intermediários. O tamanho máximo de cada arquivo carregado deve ser de 25 KB ou menos.
Por exemplo, se o certificado do cliente contiver um certificado de autoridade de certificação raiz, vários certificados de autoridade de certificação intermediários e um certificado folha, carregue o certificado de autoridade de certificação raiz e todos os certificados de autoridade de certificação intermediários ao Gateway de Aplicações em um único arquivo. Para obter mais informações sobre como extrair um certificado CA de cliente confiável, consulte Extrair certificados de AC de cliente confiáveis.
Se você estiver carregando uma cadeia de certificados com certificados da AC raiz e intermediários, carregue-a como um arquivo PEM ou CER no gateway.
Importante
Carregue toda a cadeia de certificados CA de cliente confiável no Gateway de Aplicações ao usar autenticação mútua.
Cada perfil de SSL pode dar suporte a até 100 cadeias de certificados de AC de cliente confiáveis. Um Gateway de Aplicativo individual pode dar suporte a um total de 200 cadeias de certificados de AC de cliente confiáveis.
Observação
- A autenticação mútua está disponível apenas em SKUs Standard_v2 e WAF_v2.
- A configuração da autenticação mútua para ouvintes de protocolo TLS está disponível atualmente por meio da API REST, do PowerShell e da CLI.
Certificados com suporte para autenticação de modo estrito do TLS mútua
O Gateway de Aplicativo dá suporte a certificados emitidos por autoridades de certificação estabelecidas públicas e privadas.
- Certificados CA emitidos por autoridades certificadoras bem conhecidas: certificados intermediários e raiz geralmente são encontrados em repositórios de certificados confiáveis e permitem conexões seguras com pouca ou nenhuma configuração extra no dispositivo.
- Certificados de autoridade de certificação emitidos por autoridades de certificação estabelecidas pela organização: esses certificados normalmente são emitidos internamente pela sua organização e não são aceitos por outras entidades. Importe certificados intermediários e raiz em repositórios de certificados confiáveis para que os clientes estabeleçam confiança na cadeia.
Observação
Ao emitir certificados de cliente de autoridades de certificação bem estabelecidas, considere trabalhar com a autoridade de certificação para ver se um certificado intermediário pode ser emitido para sua organização. Essa abordagem impede a autenticação inadvertida de certificado de cliente entre organizações.
Validação de autenticação de clientes para modo estrito de TLS mútuo
Verificar DN do certificado de cliente
Você pode verificar o emissor imediato do certificado do cliente e apenas permitir que o Gateway de Aplicativo confie nesse emissor. Essa opção está desativada por padrão, mas você pode habilitá-la por meio do portal, do PowerShell ou do CLI do Azure.
Se você habilitar o Gateway de Aplicativo para verificar o emissor imediato do certificado do cliente, os seguintes cenários descrevem como o DN do emissor do certificado do cliente é extraído dos certificados carregados:
-
Cenário 1: a cadeia de certificados inclui certificado raiz, certificado intermediário e certificado folha.
- O nome da entidade do certificado intermediário é extraído como o 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 sujeito do certificado intermediate2 é extraído como o DN do emissor do certificado do cliente.
-
Cenário 3: a cadeia de certificados inclui o certificado raiz e o certificado intermediário.
- O nome do assunto do certificado raiz é extraído como o DN do emissor do certificado do cliente.
-
Cenário 4: Várias cadeias de certificados do mesmo comprimento no mesmo arquivo. A cadeia 1 inclui certificado raiz, certificado intermediário1 e certificado folha. A cadeia 2 inclui certificado raiz, certificado intermediário2 e certificado folha.
- O nome da entidade do certificado intermediário1 é extraído como o DN do emissor do certificado do cliente.
-
Cenário 5: Várias cadeias de certificados de comprimentos diferentes no mesmo arquivo. A cadeia 1 inclui certificado raiz, certificado intermediário1 e certificado folha. A cadeia 2 inclui o certificado raiz, o certificado intermediário 2, o certificado intermediário 3 e o certificado folha.
- O nome do certificado intermediário3 é extraído como o DN do emissor do certificado do cliente.
Importante
Recomendamos carregar apenas uma cadeia de certificados por arquivo. Essa recomendação é especialmente importante se você habilitar a opção de verificação do DN do certificado do cliente. Carregar várias cadeias de certificados em um arquivo corresponde ao cenário quatro ou cinco, o que pode causar problemas posteriormente quando o certificado do cliente apresentado não corresponder ao DN do emissor do certificado do cliente extraído pelo Gateway de Aplicação a partir das cadeias.
Para obter mais informações sobre como extrair cadeias de certificados de AC de cliente confiáveis, consulte Extrair cadeias de certificados de AC de cliente confiáveis.
Variáveis de servidor
Com a autenticação mútua do TLS, você pode usar variáveis de servidor adicionais para passar informações sobre o certificado do cliente para os servidores de back-end por trás do Gateway de Aplicativo. Para obter mais informações sobre quais variáveis de servidor estão disponíveis e como usá-las, consulte variáveis de servidor.
Revogação de certificado
Quando um cliente inicia uma conexão com um Gateway de Aplicativo configurado com autenticação TLS mútua, a cadeia de certificados e o nome diferenciado do emissor podem ser validados. Além disso, o status de revogação do certificado do cliente pode ser verificado com o OCSP (Protocolo de Status do Certificado Online). Durante a validação, o certificado apresentado pelo cliente é consultado por meio do responder OCSP definido em sua extensão de Acesso às Informações de Autoridade (AIA). Se o certificado do cliente tiver sido revogado, o Gateway de Aplicativo responderá ao cliente com um código de status HTTP 400 e um motivo. Se o certificado for válido, a solicitação continuará sendo processada pelo Gateway de Aplicativo e encaminhada para o pool de back-end definido.
Você pode habilitar a revogação de certificado do cliente por meio da API REST, modelo do ARM, Bicep, CLI ou PowerShell.
Para configurar a verificação de revogação do cliente em um Gateway de Aplicativo 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 obter uma lista de todas as referências de Azure PowerShell para a configuração de autenticação de cliente no Gateway de Aplicativo, consulte os seguintes artigos:
Para verificar se o status de revogação do OCSP foi avaliado para a solicitação do cliente, os logs de acesso contêm uma propriedade chamada sslClientVerify que mostra o status da resposta OCSP.
É fundamental que o respondente OCSP esteja altamente disponível e que a conectividade de rede entre o Gateway de Aplicativo e o respondente seja possível. Se o Gateway de Aplicativo não puder resolver o FQDN (nome de domínio totalmente qualificado) do respondente definido ou se a conectividade de rede for bloqueada para ou do respondente, o status de revogação do certificado falhará e o Gateway de Aplicativo retornará uma resposta HTTP 400 ao cliente solicitante.
Observação
As verificações do OCSP são validadas usando o cache local com base no tempo definido por uma resposta anterior do OCSP. Se o cache OCSP não tiver sido preenchido de uma solicitação anterior, a primeira resposta poderá falhar. Após a nova tentativa do cliente, a resposta deve ser encontrada no cache e a solicitação é processada como esperado.
Observações
- A verificação de revogação via CRL não é suportada.
- A verificação de revogação do cliente foi introduzida na API versão 2022-05-01.
Conteúdo relacionado
Depois de saber mais sobre autenticação mútua, vá para Configurar o Gateway de Aplicativo com autenticação mútua no PowerShell para criar um Gateway de Aplicativo que use autenticação mútua.