mTLS

Mutual TLS (mTLS), também chamado de autenticação mútua, adiciona uma verificação do cliente ao handshake TLS: o cliente também apresenta um certificado, e o servidor o valida. Em um workload, a Azion valida o certificado de cliente em relação a um certificado de CA confiável, um dos tipos listados em Certificados. O mTLS é opcional em um workload, e o modelo Open Banking o exige, por isso workloads que atendem serviços financeiros e pagamentos costumam precisar dele. Para a linha mtls entre todos os outros campos de um workload, consulte Configurações de workload.

Campos

O objeto mtls de um workload ativa a verificação do certificado de cliente e indica em relação a que o workload verifica. Defina-o com PATCH /v4/workspace/workloads/{workload_id}, ou no arquivo JSON de azion update workload --file, que lê o ID do workload de uma chave "id" no arquivo.

O certificado de CA confiável é o certificado da autoridade que assina os certificados dos seus clientes. Você o envia sem chave privada, e a API recusa o ID de um certificado de servidor em mtls.config.certificate. Um certificado de CA confiável aparece como inactive no Certificate Manager até que um workload o indique, e como active a partir de então.

Uma CRL lista certificados que o emissor revogou antes de expirarem. Uma CRL é anexada a um workload somente por meio de mtls.config.crl, em um workload com mtls.enabled definido como true, e um workload pode indicar várias CRLs no mesmo array.

Por exemplo, um workload que admite somente clientes que a sua autoridade de certificação assinou, e que anexa uma CRL, envia este arquivo, salvo como mtls.json:

Aplique-o com a CLI:

O comando imprime o ID do workload que alterou:

Em seguida, o workload é lido de volta com este objeto mtls:

Na API v3, o mTLS pertencia ao objeto de domínio, em is_mtls_enabled, mtls_verification e mtls_trusted_ca_certificate_id. Na API v4, as mesmas configurações são mtls.enabled, mtls.config.verification e mtls.config.certificate no workload. Para o mapeamento completo entre os dois modelos, consulte API v4 Migration.

Modos de verificação

O campo mtls.config.verification decide o que um workload faz com um cliente que não apresenta certificado, ou que apresenta um certificado que a CA confiável não assinou. No modo enforce, o workload solicita o certificado de cliente durante o handshake TLS e encerra o handshake quando a verificação falha. A tabela mostra o que cada cliente recebe de um workload em cada modo:

enforce bloqueia todo cliente cuja identidade o workload não consegue verificar, tanto nos seus próprios domínios quanto no workload domain. Use-o quando todo cliente legítimo tiver um certificado que a sua autoridade de certificação assinou.

permissive permite que todo cliente conclua o handshake e deixa a decisão para as suas regras. Use-o para testar o mTLS, ou para admitir clientes sob condições específicas. Para recusar os demais, adicione uma regra de firewall sobre a variável Client Certificate Validation, como descreve a seção Dados do certificado de cliente em regras.

Uma alteração em mtls leva vários minutos para chegar a toda a infraestrutura distribuída da Azion, e a propagação é feita com o melhor esforço. Até que ela termine, algumas requisições encontram o modo antigo e outras o novo. Antes de depender de uma alteração, envie uma requisição sem certificado de cliente e confirme que o resultado corresponde ao novo modo.

Dados do certificado de cliente em regras

Rules Engine lê detalhes do certificado de cliente, para que uma regra possa agir conforme a identidade do cliente.

No Rules Engine for Firewall, a variável Client Certificate Validation avalia se o certificado da requisição é válido em relação à CA confiável do workload. Em um workload no modo permissive, uma regra que nega requisições em que Client Certificate Validation não é igual a true retorna 403 Forbidden a todo cliente sem um certificado válido. O critério Client Certificate Validation aparece somente em uma conta em que o mTLS está ativado.

Uma regra de firewall também pode corresponder a atributos do certificado de cliente, como o Common Name (CN), o emissor ou a impressão digital (fingerprint), que as variáveis de header de mTLS carregam. Essas variáveis devem ser definidas na sua aplicação antes que uma regra de firewall possa usá-las como critérios.

Uma aplicação define as variáveis de header de mTLS como headers de requisição, por exemplo para atender aos requisitos do Open Banking. A lista de variáveis que Rules Engine aceita está em Rules Engine para Applications. Para a configuração da regra passo a passo, consulte Configure mTLS em um workload.

Requisitos

Um workload verifica certificados de cliente somente quando estas condições são atendidas:

• O mTLS está ativado na sua conta. A Azion ativa o mTLS por conta. Para ativá-lo, entre em contato com a equipe de Vendas.
• O workload atende HTTPS. O certificado de cliente trafega no handshake TLS, por isso o mTLS funciona somente em conexões HTTPS. As configurações de mTLS em um workload que atende somente HTTP não verificam nada.
• Existe um certificado de CA confiável no Certificate Manager. Uma autoridade de certificação de terceiros o emite, e você o envia antes de definir mtls.config.certificate. Um certificado que a Azion gera, como o certificado Azion SAN, não pode servir como CA confiável.
• Os clientes enviam SNI no modo enforce. Server Name Indication (SNI) é a extensão TLS que indica o host no handshake. Uma conexão sem SNI chega à configuração padrão, que apresenta o certificado Azion SAN. Em um workload no modo enforce, a Azion fecha essa conexão antes de resolver uma rota da sua aplicação.

Para o número de certificados que uma conta pode ter e o tamanho máximo de um certificado de CA confiável, consulte Limites de Workloads.

Erros

A API recusa as duas primeiras requisições abaixo com a mensagem da primeira coluna. A CLI imprime a mensagem dentro de Error: Failed to update the Workload: [...], seguida de Check your settings and try again. If the error persists, contact Azion support. A última linha é o que um cliente vê, não uma mensagem da API.

A falha do handshake aparece na saída detalhada do curl. Envie uma requisição sem certificado de cliente a um workload no modo enforce:

O workload solicita um certificado, o cliente não envia nenhum e a conexão termina:

Recursos relacionados