Certificados Premium do Firewall do Azure

  • Artigo

Para configurar corretamente a inspeção TLS Premium do Firewall do Azure, você deve fornecer um certificado de CA intermediário válido e depositá-lo no cofre da Chave do Azure.

Certificados usados pelo Firewall Premium do Azure

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

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

    Uma Autoridade de Certificação (CA) é uma organização confiável para assinar certificados digitais. Uma autoridade de certificação verifica a identidade e a legitimidade de uma empresa ou indivíduo que solicita um certificado. Se a verificação for bem-sucedida, a autoridade de certificação emitirá um certificado assinado. Quando o servidor apresenta o certificado ao cliente (por exemplo, seu navegador da Web) durante um handshake SSL/TLS, o cliente tenta verificar a assinatura em relação a uma lista de signatários em boas condições . Os navegadores da Web normalmente vêm com listas de autoridades de certificação nas quais confiam implicitamente para identificar hosts. Se a autoridade não estiver na lista, como acontece com alguns sites que assinam seus próprios certificados, o navegador alerta o usuário de que o certificado não está assinado por uma autoridade reconhecida e pergunta ao usuário se ele deseja continuar as comunicações 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, isso significa que uma autoridade de certificação tomou medidas para verificar se o endereço da Web realmente pertence a essa organização. Quando você digita um URL ou segue um link para um site seguro, seu navegador verifica o certificado quanto às 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 descartará 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 alto da árvore.

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

Certificate process

Requisitos de certificado de autoridade de certificação intermediários

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

  • Quando implantado como um segredo do Cofre da Chave, você deve usar o PFX sem senha (PKCS12) com um certificado e uma chave privada. Não há suporte para certificados PEM.

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

  • Deve ser válido por um ano a mais.

  • Deve ser uma chave privada RSA com tamanho mínimo de 4096 bytes.

  • Ele deve ter a extensão marcada KeyUsage como Crítica com o KeyCertSign sinalizador (RFC 5280; 4.2.1.3 Key Usage).

  • Ele deve ter a extensão marcada BasicConstraints como Crítica (RFC 5280; 4.2.1.9 Restrições básicas).

  • O CA sinalizador deve ser definido como TRUE.

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

  • Tem de ser exportável.

Azure Key Vault

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

Para configurar o cofre de chaves:

  • Você precisa importar um certificado existente com seu par de chaves para o cofre de chaves.
  • Como alternativa, você também pode usar um segredo do cofre de chaves que é armazenado como um arquivo PFX codificado em base 64 sem senha. Um arquivo PFX é um certificado digital que contém chave privada e chave pública.
  • É recomendável usar uma importação de certificado de autoridade de certificação porque ela permite configurar 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 a ser concedida obtenha 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 estão implantados corretamente.
  • Como o Firewall Premium do Azure está listado como Serviço Confiável do Cofre da Chave, ele permite que você ignore o Firewall interno do Cofre da Chave e elimine qualquer exposição do Cofre da Chave à Internet.

Nota

Sempre que importar um novo certificado de CA de Firewall para o Cofre de Chaves do Azure (pela primeira vez ou substituindo uma certificação de CA expirada), você deve atualizar explicitamente a configuração 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 do Cofre da Chave em seu nome. Para obter mais informações, consulte O que são identidades gerenciadas para recursos do Azure?

Nota

O controle de acesso baseado em função do Azure (Azure RBAC) não é suportado atualmente para autorização. Em vez disso, use o modelo de política de acesso. Para obter mais informações, consulte Controle de acesso baseado em função do Azure (Azure RBAC) versus políticas de acesso.

Configurar um certificado na sua política

Para configurar um certificado de autoridade de certificação em sua política de Firewall Premium, selecione sua política e, em seguida, selecione inspeção TLS. Selecione Ativado na página de inspeção TLS. Em seguida, selecione seu certificado de CA no Cofre de Chaves do Azure, conforme mostrado na figura a seguir:

Azure Firewall Premium overview diagram

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 ao Cofre da Chave. Dê à sua conta de utilizador Obter e Listar em Permissões Secretas. Azure Key Vault Access policy

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

Se quiser criar seus próprios certificados para ajudá-lo a testar e verificar a inspeção TLS, você pode usar os scripts a seguir para criar sua própria CA raiz autoassinada e CA intermediária.

Importante

Para produção, você deve usar sua PKI corporativa para criar um certificado de autoridade de certificação intermediária. Uma PKI corporativa aproveita a infraestrutura existente e lida com a distribuição de CA raiz para todas as máquinas de ponto final. Para obter mais informações, consulte Implantar e configurar certificados de CA corporativa para o Firewall do Azure.

Existem duas versões deste script:

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

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

Os scripts geram os seguintes ficheiros:

  • rootCA.crt/rootCA.key - Certificado público e chave privada da autoridade de certificação raiz.
  • interCA.crt/interCA.key - Certificado público de CA intermediário e chave privada
  • interCA.pfx - Pacote intermediário CA pkcs12 que será usado pelo firewall

Importante

rootCA.key deve ser armazenado em um local offline seguro. Os scripts geram um certificado com validade de 1024 dias. Os scripts requerem binários openssl instalados em sua máquina local. Para mais informações, consultar: https://www.openssl.org/

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

  • rootCA.crt - Implante em máquinas de ponto de extremidade (somente certificado público).
  • interCA.pfx - Importe como certificado em um Cofre de Chaves e atribua à 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 certificados

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

  • Identidade Gerida
  • Key Vault
  • Certificado de autoridade de certificação raiz autoassinado

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

Screenshot showing auto-generated certificates.

Resolução de Problemas

Se o certificado da autoridade de certificação for válido, mas você não puder 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 da autoridade de certificação raiz está instalado no sistema operacional cliente.

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

  • Verifique se o tipo de URL de destino em sua regra de aplicativo cobre o caminho correto e quaisquer outros hiperlinks incorporados na página HTML de destino. Você pode usar curingas para facilitar a cobertura de todo o caminho de URL necessário.

Próximos passos