Todos os produtos
Search
Central de documentação

Cloud Firewall:TLS inspection

Última atualização: Sep 23, 2026

Ameaças ocultas no tráfego HTTPS escapam da detecção porque o payload está criptografado. A inspeção de TLS no Cloud Firewall descriptografa o tráfego de saída ao substituir o certificado TLS original por uma CA raiz privada. Isso permite que o mecanismo IPS inspecione o texto simples e, em seguida, o recriptografe para uma entrega segura.

Nota

A inspeção de TLS está em preview público e pode sofrer alterações antes da disponibilidade geral. Em caso de dúvidas ou feedback, entre em contato com o gerente da sua conta.

Por que a inspeção de TLS é necessária

O HTTPS criptografa os payloads das requisições em texto cifrado, o que cria um ponto cego onde o mecanismo IPS não consegue analisar o conteúdo. A inspeção de TLS substitui o certificado TLS original por um certificado privado entre o cliente e o firewall. Assim, o tráfego é descriptografado para uma análise profunda de pacotes, permitindo a detecção de ataques avançados e exfiltração de dados.

Riscos de segurança do tráfego criptografado

Risco 1: Ataques avançados e violações de dados passam despercebidos pelo IPS Atacantes utilizam túneis HTTPS para entregar payloads maliciosos, exfiltrar dados ou se comunicar com servidores C2. O tráfego criptografado impede que o IPS engine identifique assinaturas de ataque ou vazamentos de dados. A inspeção de TLS expõe o tráfego em texto simples, o que possibilita ao IPS detectar e bloquear essas ameaças.

Risco 2: A filtragem web não consegue aplicar controles no nível de caminho sobre o tráfego HTTPS O Web filtering corresponde a nomes de host e caminhos em requisições HTTP (como example.com/upload/*). Sem a descriptografia, o firewall só consegue ler o domínio a partir do SNI e não extrai os caminhos da URL. Isso faz com que políticas granulares, como "permitir navegação, mas negar uploads", falhem. A inspeção de TLS permite a correspondência completa de caminhos no tráfego HTTPS.

Risco 3: A precisão na identificação de aplicações cai sob criptografia, limitando a granularidade do controle O Application control usa inspeção profunda de pacotes (DPI) para identificar aplicações a partir dos dados do payload. Sem descriptografia, o DPI depende apenas de informações de handshake, como SNI e certificados. Isso torna impossível distinguir comportamentos sob o mesmo domínio (por exemplo, "navegar no GitHub" versus "fazer upload para o GitHub"). A inspeção de TLS oferece visibilidade total do tráfego para uma identificação precisa de comportamentos.

Notas de uso

  • Limitação de método de faturamento: Este recurso não é compatível com instâncias do Cloud Firewall que utilizam o método de faturamento legacy pay-as-you-go 1.0.

  • Limitação de região: Este recurso está disponível apenas nas seguintes regiões: China (Beijing), China (Shanghai), China (Hangzhou), China (Zhangjiakou), China (Ulanqab), China (Shenzhen), China (Hong Kong), Indonesia (Jakarta), UK (London), Malaysia (Kuala Lumpur) e Germany (Frankfurt).

  • Limitação de versão do protocolo TLS:

    • TLS 1.3 sem ECH: O sistema suporta verificações TLS para conexões TLS 1.3 que não utilizam a extensão Encrypted Client Hello (ECH).

    • TLS 1.3 com ECH: O sistema não suporta verificações TLS para conexões TLS 1.3 que utilizam a extensão ECH. No entanto, o tráfego pode ser encaminhado normalmente.

    • Protocolos SSL legados: O sistema não é compatível com versões anteriores de protocolo, como SSL 1.0, SSL 2.0 ou SSL 3.0. Se um cliente usar esses protocolos, o tráfego poderá ser interrompido.

  • Limitação de tipo de protocolo: Requisições não TCP, como o tráfego QUIC que usa UDP, são encaminhadas, mas não inspecionadas.

  • Impacto no diagnóstico de rede: Após ativar a inspeção de TLS, o TCP MTR (My Traceroute) não consegue rastrear o caminho até o servidor de origem.

  • Limitação de modo de autenticação: Este recurso não suporta TLS mútuo (mTLS). Ele suporta apenas o TLS padrão, onde o cliente valida o certificado do servidor.

  • Requisito de SNI: O Server Name Indication (SNI) do TLS deve corresponder ao nome de domínio no certificado configurado para que a inspeção de TLS tenha efeito.

Procedimento

Faça login no Cloud Firewall console. No painel de navegação à esquerda, escolha Protect > TLS Inspection para ir até a página TLS Inspection.

Etapa 1: Configurar uma política de inspeção de TLS

Na página TLS Inspection, clique em Create TLS Inspection Policy acima da lista de políticas. O painel Create TLS Inspection Policy será aberto à direita.

  1. Associate Certificate.

    Parâmetro

    Descrição

    Policy Name

    Insira um nome descritivo para a política.

    Associate TLS Certificate

    Selecione um certificado existente.

    Nota

    Ao criar sua primeira política, o menu suspenso de certificados inclui a opção Apply for a Trial Certificate. Clique nela para gerar um certificado de teste e avaliar a inspeção de TLS. Um certificado de teste só pode ser usado uma vez. Em ambientes de produção, compre e utilize seu próprio certificado.

    Atualmente, apenas certificados PCA são suportados. O certificado deve atender aos seguintes requisitos:

    • A finalidade do certificado deve ser definida como "Internal enterprise use".

    • Certificados com algoritmos criptográficos chineses não são suportados.

    • Se você usar o algoritmo de chave privada RSA, o comprimento da chave deve ser de pelo menos 2048 bits.

    • Se você usar o algoritmo de chave privada ECC, selecione P-256.

    Se não houver certificados disponíveis, clique em Buy Certificate para acessar o console do Certificate Management Service. Ao comprar o certificado, certifique-se de que a finalidade do certificado PCA esteja definida como "Internal enterprise use". What is a PCA certificate?.

    Certificate Validity

    Exibe o período de validade do certificado após a seleção. Um alerta é exibido quando a validade restante cai para menos de um ano. Certifique-se de que os certificados mantenham pelo menos um ano de validade.

    Description

    Insira uma descrição para a política.

    Após configurar os parâmetros, clique em Next para prosseguir para a etapa Configure Inspection Range. A política é criada e salva ao avançar para a próxima etapa.

  2. Configure Inspection Range.

    Importante
    • A cota total para todos os intervalos de inspeção é de 20.000.

    • A cota consumida por uma única política de inspeção de TLS é a soma das cotas de todos os seus intervalos de inspeção.

    • Um único intervalo de inspeção consome cota calculada da seguinte forma: número de endereços IP de origem × número de intervalos de portas de origem × número de endereços IP de destino × número de intervalos de portas de destino.

    Parâmetro

    Descrição

    Protocol Type

    Atualmente, apenas o protocolo TCP é suportado.

    Source IP Address

    Selecione os endereços IP dos hosts para a inspeção de tráfego de saída. Máximo: 1.000 endereços.

    Nota

    Tipos de ativos suportados: ECS EIP, ECS public IP, NAT EIP, EIP e ENI EIP.

    Source Port

    Especifique as portas no formato start port/end port. Intervalo válido: 0-65535. Separe vários intervalos com vírgulas. Máximo: 100 intervalos.

    Nota
    • Todas as portas usam o formato de intervalo, mesmo para uma única porta. Por exemplo, 8080/8080 verifica apenas a porta 8080.

    • Para verificar todas as portas, use 0/65535.

    Destination IP Address

    Endereços IP de destino que os hosts de origem acessam.

    Nota
    • Você deve usar endereços IPv4 ou intervalos de endereços na notação CIDR. Por exemplo: 192.0.2.0/24,8.8.8.8/32.

    • É possível inserir até 100 objetos de endereço IP. Separe vários objetos com vírgulas (,).

    • Para representar todos os endereços, use 0.0.0.0/0.

    Destination Port

    Portas de serviço de destino. Formato: start port/end port. Intervalo válido: 0-65535. Separe vários intervalos com vírgulas. Máximo: 100 intervalos.

    Description

    Insira uma descrição para o intervalo de inspeção.

    Outras operações

    • Salvar: Clique em Save abaixo da seção Inspection Scope para salvar o intervalo de inspeção sem clicar em Next. Após salvar o escopo, Saved aparece no canto superior direito da seção.

    • Adicionar: Clique em Add an inspection range para adicionar outro intervalo de inspeção. Uma única política suporta até 10 intervalos de inspeção.

    • Excluir: Clique no ícone image no canto superior direito da seção Inspection Scope para excluir o intervalo de inspeção atual. Após confirmar a exclusão, o intervalo é excluído imediatamente, sem a necessidade de clicar em Next. Use esta opção com cautela.

    Após configurar os parâmetros, clique em Next para concluir a configuração da política.

  3. Revise as informações da política.

    Após a configuração da política, os detalhes da política e de seu intervalo de inspeção são exibidos. O Policy ID é incluído nos logs.

Etapa 2: Instalar o certificado TLS

Instale o certificado associado em todos os hosts no escopo de inspeção.

Importante

Se um ativo inspecionado for um NAT EIP, você deve instalar o certificado em todas as instâncias ECS que acessam a internet por meio desse gateway NAT de internet. Caso contrário, o tráfego poderá ser interrompido.

  1. Baixe o certificado.

    image

    Na lista Configure TLS Inspection Policy, localize a política que você criou e clique em Download Certificate na coluna Actions à direita. O certificado será baixado para sua máquina local. Descompacte o pacote para obter o arquivo de certificado (.crt).

  2. Faça login no host do IP de origem.

    Faça login no host que você especificou como Source IP Address ao criar o Inspection Scope. Faça o upload do certificado para qualquer diretório no host. Methods for transferring files.

  3. Instale o certificado.

    Copie o certificado para o repositório de confiança do sistema operacional e execute o comando de atualização. As etapas variam de acordo com o sistema operacional.

    Nota
    • Se a sua política TLS usar um certificado de CA subordinada, você deve instalar tanto a CA raiz quanto a CA subordinada.

    • Os exemplos a seguir aplicam-se a cenários em que o repositório de confiança é o repositório do sistema. Se a sua aplicação usar um repositório de confiança diferente, instale o certificado no repositório correto.

    CentOS/Alibaba Cloud Linux/Anolis/Red Hat

    1. Copie o arquivo de certificado: cp <certificate_file_name> /etc/pki/ca-trust/source/anchors/

    2. Atualize os certificados: sudo update-ca-trust

    3. Visualize o certificado atualizado: cat /etc/ssl/certs/ca-bundle.crt

      Se a saída exibir o conteúdo do certificado, a instalação foi bem-sucedida.

      image

    Ubuntu

    1. Copie o arquivo de certificado: cp <certificate_file_name> /usr/local/share/ca-certificates/

    2. Atualize os certificados: sudo update-ca-certificates

    3. Visualize o certificado atualizado:cat /etc/ssl/certs/ca-certificates.crt

      Se a saída exibir o conteúdo do certificado, a instalação foi bem-sucedida.

      image

    Windows

    Importante
    • Se você usar um certificado que referencia uma CA subordinada (CA intermediária), o Gerenciador de Certificados nativo do Windows não instala todas as CAs em um arquivo de cadeia de certificados de uma só vez. Ele instala apenas a primeira CA no arquivo. Nesse cenário, você deve dividir manualmente cada bloco de conteúdo de CA em um arquivo separado e, em seguida, instalar cada arquivo.

    • Divida o certificado abrindo o arquivo de certificado baixado e descompactado em um editor de texto, recortando o bloco de conteúdo de -----BEGIN CERTIFICATE----- até -----END CERTIFICATE----- e salvando-o como um novo arquivo com a extensão .crt.

      image

      Após a divisão: image

    1. Instale o certificado: Clique com o botão direito no arquivo de certificado e clique em Install Certificate. Em seguida, siga estas etapas:

      1

      2

      3

      image

      image

      image

      Clique em Next para concluir a importação do certificado.

    2. Visualize os certificados importados: Insira certmgr.msc no Prompt de Comando para abrir o Gerenciador de Certificados.

      image

    SUSE

    1. Copie o arquivo de certificado: cp <certificate_file_name> /etc/pki/trust/anchors

    2. Atualize os certificados: sudo c_rehash .

    3. Visualize o certificado atualizado: sudo trust list --filter=ca-anchors |grep -C 2 <Certificate CN>

      Se as informações do certificado forem exibidas, o certificado foi instalado com sucesso.

      image

    Fedora and Fedora CoreOS

    1. Copie o arquivo de certificado: sudo cp <certificate-file-name> /etc/pki/ca-trust/source/anchors/

    2. Atualize os certificados: sudo update-ca-trust extract

    3. Visualize o certificado atualizado: sudo trust list --filter=ca-anchors |grep -C 2 <certificate_CN>

      Se as informações do certificado forem exibidas, o certificado foi instalado com sucesso.

      image

    Container Service (ACK)

    Quando o tráfego de saída se origina de pods em um cluster ACK, instale o certificado PCA dentro de cada pod, pois o ambiente de contêiner é isolado do host. Se os nós também iniciarem requisições HTTPS (como fazer pull de imagens de um repositório público), instale o certificado nos nós também.

    Nota
    • As etapas a seguir aplicam-se ao Alibaba Cloud Linux 3.2104 LTS 64 bits (otimizado para contêineres) e servem apenas como referência. Ajuste os comandos com base no seu sistema operacional e nos requisitos do seu negócio.

    • Alguns dos comandos a seguir reiniciam recursos. Para evitar interrupções nos negócios, recomendamos que você execute essas operações fora dos horários de pico.

    Instalar o certificado nos nós

    Faça login em cada nó e execute os seguintes comandos.

    1. Copie o arquivo de certificado: cp <certificate_file_name> /etc/pki/ca-trust/source/anchors/

    2. Atualize os certificados: sudo update-ca-trust

    3. Visualize o certificado atualizado:cat /etc/ssl/certs/ca-bundle.crt

      Se o conteúdo do certificado for exibido, o certificado está instalado.

    4. Reinicie o serviço de contêiner para que as alterações tenham efeito: sudo systemctl restart containerd.

    Instalar o certificado nos pods

    1. Crie um Secret no console do cluster de destino. A seguir, um exemplo de configuração. O valor da chave é o conteúdo do arquivo de certificado. Para obter detalhes sobre como criar um Secret, consulte Manage Secrets.image Alternativamente, você pode executar o seguinte comando kubectl para criar o Secret, o que tem o mesmo efeito. Você deve substituir ca_chain.crt no comando pelo nome real do arquivo de certificado.

      kubectl create secret generic cfw-pca-cert \
        --from-file=ca_chain.crt=./ca_chain.crt \
        -n default
    2. Para um exemplo de Deployment, adicione o seguinte conteúdo ao seu arquivo YAML:

      1. Acesse o campo spec.template.spec.containers e adicione o seguinte conteúdo para montar o certificado e atualizar o repositório de confiança. No conteúdo, secretName é o nome do Secret que você criou na etapa anterior, por exemplo, cfw-pca-cert.

        volumes:
                - name: custom-ca-volume
                  secret:
                    secretName: cfw-pca-cert   
        volumeMounts:
                - name: custom-ca-volume
                  mountPath: /etc/ssl/custom
                  readOnly: true  
      2. Continue adicionando o comando de inicialização sob o campo spec.template.spec.containers.

        Nota

        O exemplo a seguir é baseado no sistema de contêiner CentOS e serve apenas como referência. Ajuste os comandos com base no seu sistema operacional e nos requisitos do seu negócio.

        command:
                  - "/bin/sh"
                  - "-c"
                  - |
                    # 1. Install curl.
                    echo "Installing curl......"
                    yum install -y curl
        
                    # 2. Verify that the certificate is mounted. Replace ca_chain.crt with the actual certificate filename.
                    if [ ! -f /etc/ssl/custom/ca_chain.crt ]; then
                      echo "ERROR: Certificate file not found!"
                      exit 1
                    fi
        
                    # 3. Inject the certificate based on the steps for CentOS.
                    echo "Copying certificate to anchors directory..."
                    cp /etc/ssl/custom/ca_chain.crt /etc/pki/ca-trust/source/anchors/
        
                    echo "Updating CA trust store..."
                    update-ca-trust        
        
                    # 4. Keep the pod running.
                    echo "Pod ready for manual testing. Use 'kubectl exec' to test further."
                    sleep infinity

Repositório de confiança do navegador

Navegadores como o Firefox mantêm seus próprios bancos de dados de confiança de certificados em vez de usar o repositório de confiança de CA do sistema. O navegador ainda pode mostrar o certificado como não confiável mesmo após a execução de update-ca-certificates. Importe o certificado diretamente para o banco de dados de confiança do navegador.

Nota

As etapas para importar um certificado nesses navegadores são as mesmas no Linux e no Windows.

1

2

image

image

Etapa 3: Ativar a inspeção e consultar os logs de tráfego

  1. Após instalar os certificados em todos os hosts, ative a política.

    Importante

    Ao ativar a inspeção de TLS, a proteção para novas conexões entra em vigor em cerca de um minuto. As conexões persistentes existentes não são afetadas e não serão protegidas.

    Para EIPs que já estão protegidos e com a inspeção de TLS ativada, desativar a inspeção de TLS interrompe as conexões persistentes. A duração da interrupção depende do tempo de reconexão da sua aplicação.

    image

    A página TLS Inspection lista todas as políticas. Alterne o botão de status para ativar uma política. Uma vez ativado, o Cloud Firewall inspeciona o tráfego de saída criptografado de acordo com a sua configuração.

    Nota

    Você só pode excluir uma política quando ela estiver desativada.

  2. Consulte os logs de tráfego.

    Após os hosts inspecionados gerarem tráfego, no painel de navegação à esquerda do console do Cloud Firewall, acesse Detection & Response > Log Audit.

    Na aba Traffic Logs > Internet Firewall tab, consulte o tráfego gerado pelos hosts, incluindo a política de inspeção de TLS e o intervalo de inspeção correspondentes.

    Os logs exibem os IDs da política e do intervalo de inspeção.

    image