Certificados do Firewall do Azure Premium

Para configurar a inspeção de TLS no Firewall do Azure Premium, você precisa apresentar um certificado de AC intermediário válido e depositar no Azure Key Vault.

Certificados usados pelo Firewall do Azure Premium

Há três tipos de certificados usados em uma implantação típica:

  • Certificado de autoridade de certificação intermediário (certificado de AC)

    Uma autoridade de certificação (CA) é uma organização confiável para assinar certificados digitais. Ela verifica a identidade e a legitimidade de uma empresa ou indivíduo solicitando um certificado. Se a verificação for bem-sucedida, a AC emitirá um certificado assinado. Quando o servidor apresenta o certificado para o cliente (por exemplo, seu navegador da Web) durante um handshake de SSL/TLS, o cliente tenta verificar a assinatura em uma lista de assinantes válidos conhecidos. Os navegadores da Web normalmente têm listas de CAs em que eles confiam implicitamente para identificar hosts. Se a autoridade não estiver na lista, como ocorre com alguns sites que assinam seus próprios certificados, o navegador alertará o usuário de que o certificado não está assinado por uma autoridade reconhecida e perguntará se o usuário deseja continuar a comunicação com o site não verificado.

  • Certificado do servidor (certificado do site)

    Um certificado associado a um nome de domínio específico. Se um site tiver um certificado válido, significa que uma autoridade de certificação executou etapas para verificar se o endereço da Web realmente pertence a essa organização. Quando você digita uma URL ou segue um link para um site seguro, seu navegador verifica o certificado para as seguintes características:

    • O endereço do site corresponde ao endereço no certificado.
    • O certificado é assinado por uma autoridade de certificação que o navegador reconhece como uma autoridade confiável.

    Ocasionalmente, os usuários podem se conectar a um servidor com um certificado não confiável. O Firewall do Azure removerá a conexão como se o servidor encerrasse a conexão.

  • Certificado de autoridade de certificação raiz (certificado raiz)

    Uma autoridade de certificação pode emitir vários certificados na forma de uma estrutura de árvore. Um certificado raiz é o certificado mais importante da árvore.

O Firewall do Azure Premium pode interceptar o tráfego HTTP/S de saída e gerar automaticamente um certificado do servidor para o www.website.com. Esse certificado é gerado usando o certificado de autoridade de certificação intermediário que você fornece. Os aplicativos cliente e o navegador do usuário final (IaaS, PaaS e outras cargas de trabalho) precisam confiar no certificado da autoridade de certificação raiz da sua organização ou no certificado de autoridade de certificação intermediária para que esse procedimento funcione.

Processo de certificado

Requisitos de certificado de AC intermediário

Certifique-se de que seu certificado da autoridade de certificação está em conformidade com os seguintes requisitos:

  • Quando implantado como um segredo de Key Vault, você deve usar o PFX (PKCS12) com um certificado e uma chave privada sem senha. Não há suporte para certificados de cliente.

  • Ele deve ser um certificado único, e não deve incluir toda a cadeia de certificados.

  • Ele deve ser válido por um ano.

  • Ele deve ser uma chave privada RSA com um tamanho mínimo de 4096 bytes.

  • Ele de ter a extensão KeyUsage marcada como Crítico com o sinalizador KeyCertSign (RFC 5280; uso de chave 4.2.1.3).

  • O certificado tem a extensão BasicConstraints marcada como Crítico (RFC 5280; restrições básicas do 4.2.1.9).

  • O sinalizador CA deve ser definido como TRUE.

  • O comprimento do caminho deve ser maior ou igual a um.

  • Deve ser exportável.

Cofre de Chave do Azure

Azure Key Vault é um repositório de segredos gerenciado por plataforma que você pode usar para proteger segredos, chaves e certificados TLS/SSL. O Firewall do Azure Premium dá suporte à integração com o Key Vault para certificados de servidor anexados a uma política de firewall.

Para configurar o key vault:

  • Você precisa importar um certificado existente com seu par de chaves para o key vault.
  • Você também pode usar um segredo do Key Vault que é armazenado como um arquivo PFX base-64 codificado por senha. Um arquivo PFX é um certificado digital que contém uma chave privada e uma chave pública.
  • É recomendável usar uma importação de certificado de autoridade de certificação, pois ela permite que você configure um alerta com base na data de expiração do certificado.
  • Depois de importar um certificado ou um segredo, você precisa definir políticas de acesso no cofre de chaves para permitir que a identidade receba acesso ao certificado/segredo.
  • O certificado de autoridade de certificação fornecido precisa ser confiável para sua carga de trabalho do Azure. Certifique-se de que eles foram implantados corretamente.
  • Como o Firewall do Azure Premium está listado como Key Vault Serviço confiável, ele permite ignorar Firewall interno do Key Vault e eliminar qualquer exposição do Key Vault à Internet.

Observação

Sempre que você importar um novo certificado de AC do Firewall para o Azure Key Vault (pela primeira vez ou para substituir uma certificação de AC expirada), você deve explicitamente atualizar a configuração do TLS da Política de Firewall do Azure com o novo certificado.

Você pode criar ou reutilizar uma identidade gerenciada atribuída pelo usuário existente, que o Firewall do Azure usa para recuperar certificados de Key Vault em seu nome. Para saber mais, confira O que são identidades gerenciadas para recursos do Azure?

Observação

Atualmente, não há suporte para autorização do controle de acesso baseado em função do Azure (RBAC do Azure). Em vez disso, use o modelo de política de acesso. Para saber mais, consulte controle de acesso baseado em função do Azure (RBAC do Azure) versus políticas de acesso.

Configurar um certificado em sua política

Para configurar um certificado de autoridade de certificação na política Premium do firewall, selecione sua política e selecione Inspeção TLS. Selecione Habilitado na página Inspeção TLS. Em seguida, selecione seu certificado de autoridade de certificação em Azure Key Vault, conforme mostrado na figura a seguir:

Diagrama de visão geral do Firewall do Azure Premium

Importante

Para ver e configurar um certificado do portal do Azure, você deve adicionar sua conta de usuário do Azure à política de acesso do Key Vault. Habilite sua conta de usuário para Obter e Listar em Permissões secretas. Política de acesso do Azure Key Vault

Crie seu próprio certificado de autoridade de certificação autoassinado

Se quiser criar seus próprios certificados para ajudar a testar e verificar a inspeção de TLS, você pode usar os scripts a seguir para criar sua própria AC raiz autoassinada e autoridade de certificação intermediária.

Importante

Para produção, você deve usar sua PKI corporativa para criar um certificado de autoridade de certificação intermediário. Uma PKI corporativa aproveita a infraestrutura existente e manipula a distribuição da AC raiz para todos os computadores de ponto de extremidade. Para obter mais informações, confira Implantar e configurar certificados de AC corporativa para o Firewall do Azure.

Há duas versões desse script:

  • um script bash cert.sh
  • um script do PowerShell cert.ps1

Além disso, os dois scripts usam o arquivo de configuração openssl.cnf. Para usar os scripts, copie o conteúdo de openssl.cnf, e cert.sh ou cert.ps1 para o computador local.

Os scripts geram os seguintes arquivos:

  • rootCA. CRT/rootCA.key - Certificado público da AC raiz e chave privada.
  • interCA. CRT/interCA.key - Certificado público da CA intermediária e chave privada
  • interCA.pfx - Pacote pkcs 12 da AC intermediária que será usado pelo firewall

Importante

rootCA.key deve ser armazenada em um local seguro offline. Os scripts geram um certificado com validade de 1024 dias. Os scripts exigem binários OpenSSL instalados em seu computador local. Para obter mais informações, confira https://www.openssl.org/

Depois que os certificados forem criados, implante-os nos seguintes locais:

  • rootCA.crt – Implantar em computadores de ponto de extremidade (somente certificado público).
  • IinterCA.fx - importar como certificado em um Key Vault e atribuir à política de firewall.

openssl.cnf

[ req ]
default_bits        = 4096
distinguished_name  = req_distinguished_name
string_mask         = utf8only
default_md          = sha512

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code)
stateOrProvinceName             = State or Province Name
localityName                    = Locality Name
0.organizationName              = Organization Name
organizationalUnitName          = Organizational Unit Name
commonName                      = Common Name
emailAddress                    = Email Address

[ rootCA_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ interCA_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:1
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ server_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:false
keyUsage = critical, digitalSignature
extendedKeyUsage = serverAuth

Script Bash - cert.sh

#!/bin/bash

# Create root CA
openssl req -x509 -new -nodes -newkey rsa:4096 -keyout rootCA.key -sha256 -days 1024 -out rootCA.crt -subj "/C=US/ST=US/O=Self Signed/CN=Self Signed Root CA" -config openssl.cnf -extensions rootCA_ext

# Create intermediate CA request
openssl req -new -nodes -newkey rsa:4096 -keyout interCA.key -sha256 -out interCA.csr -subj "/C=US/ST=US/O=Self Signed/CN=Self Signed Intermediate CA"

# Sign on the intermediate CA
openssl x509 -req -in interCA.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out interCA.crt -days 1024 -sha256 -extfile openssl.cnf -extensions interCA_ext

# Export the intermediate CA into PFX
openssl pkcs12 -export -out interCA.pfx -inkey interCA.key -in interCA.crt -password "pass:"

echo ""
echo "================"
echo "Successfully generated root and intermediate CA certificates"
echo "   - rootCA.crt/rootCA.key - Root CA public certificate and private key"
echo "   - interCA.crt/interCA.key - Intermediate CA public certificate and private key"
echo "   - interCA.pfx - Intermediate CA pkcs12 package which could be uploaded to Key Vault"
echo "================"

PowerShell - cert.ps1

# Create root CA
openssl req -x509 -new -nodes -newkey rsa:4096 -keyout rootCA.key -sha256 -days 3650 -out rootCA.crt -subj '/C=US/ST=US/O=Self Signed/CN=Self Signed Root CA' -config openssl.cnf -extensions rootCA_ext

# Create intermediate CA request
openssl req -new -nodes -newkey rsa:4096 -keyout interCA.key -sha256 -out interCA.csr -subj '/C=US/ST=US/O=Self Signed/CN=Self Signed Intermediate CA'

# Sign on the intermediate CA
openssl x509 -req -in interCA.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out interCA.crt -days 3650 -sha256 -extfile openssl.cnf -extensions interCA_ext

# Export the intermediate CA into PFX
openssl pkcs12 -export -out interCA.pfx -inkey interCA.key -in interCA.crt -password 'pass:'

Write-Host ""
Write-Host "================"
Write-Host "Successfully generated root and intermediate CA certificates"
Write-Host "   - rootCA.crt/rootCA.key - Root CA public certificate and private key"
Write-Host "   - interCA.crt/interCA.key - Intermediate CA public certificate and private key"
Write-Host "   - interCA.pfx - Intermediate CA pkcs12 package which could be uploaded to Key Vault"
Write-Host "================"

Geração automática de certificado

Para implantações que não são de produção, você pode usar o Firewall do Azure Premium de Geração Automática de Certificação, que cria automaticamente os três seguintes recursos para você:

  • Identidade Gerenciada
  • Key Vault
  • Certificado de AC raiz autoassinado

Basta escolher a nova identidade gerenciada e ela vincula os três recursos em sua política de Premium e configura a inspeção de TLS.

Captura de tela mostrando certificados gerados automaticamente.

Solução de problemas

Se o seu certificado da autoridade de certificação for válido, mas você não conseguir acessar FQDNs ou URLs na inspeção TLS, verifique os seguintes itens:

  • Verifique se o certificado do servidor Web é válido.

  • Verifique se o certificado de autoridade de certificação raiz está instalado no sistema operacional do cliente.

  • Verifique se o navegador ou o cliente HTTPS contém um certificado raiz válido. O Firefox e alguns outros navegadores podem ter políticas de certificação especiais.

  • Certifique-se de que o tipo de destino da URL em sua regra de aplicativo abrange o caminho correto e todos os outros hiperlinks inseridos na página HTML de destino. Você pode usar curingas para uma fácil cobertura do caminho de URL completo necessário.

Próximas etapas