Arquitetura Local (On-Premises) do Harmony Endpoint: Componentes, Fluxos de Comunicação e Portas

[jorgeluiznim]

Artigo 1 da série Harmony Endpoint Deep Dives · Endpoint Security Management R81.20 (on-premises) · Autor: Jorge Luiz

Objetivo: mapear a arquitetura completa de um ambiente Check Point Endpoint Security on-premises (R81.20): cada componente, cada canal de comunicação e cada porta — para você projetar, liberar no firewall e fazer troubleshooting do seu deployment com segurança.

Público: Engenheiros de Segurança, Administradores de Endpoint, Analistas SOC — amigável para iniciantes.

Pré-requisitos: familiaridade básica com conceitos de gerenciamento Check Point (SmartConsole). Não é necessário conhecimento prévio de Harmony Endpoint.

Visão Geral

O Check Point Endpoint Security é uma suíte integrada que combina data security, network security, advanced threat prevention, forensics e remote access VPN — tudo gerenciado centralmente a partir de um único console.

Um ambiente on-premises é composto por três elementos obrigatórios e dois opcionais:

Componente	Função
Endpoint Security Management Server	Concentra o gerenciamento de políticas e os bancos de dados (políticas, objetos de usuário/computador, licenciamento, dados de monitoramento). Comunica-se com os clients para atualizar componentes, políticas e dados de proteção. Contém o Directory Scanner, que lê a estrutura do Active Directory para atribuição de políticas baseada em diretório.
SmartEndpoint	A aplicação do SmartConsole usada para fazer deploy, monitorar e configurar os clients e as políticas.
Endpoint Security Clients	Software nos computadores dos usuários que monitora o status de segurança e aplica as políticas.
Endpoint Policy Server (opcional)	Melhora a performance em ambientes grandes assumindo a maior parte da comunicação com os clients: heartbeat e sincronização, download de políticas, atualizações de Anti-Malware e logs dos clients.
Secondary Management Server (opcional)	High Availability — um servidor de backup caso o primário fique indisponível.

ℹ️ Nota: na documentação da Check Point, "Endpoint Security Management Server" se refere a todos os servidores Endpoint Security do ambiente — incluindo os Endpoint Policy Servers opcionais.

ℹ️ Nota: o servidor de Active Directory é o repositório das informações de usuários da organização, mas não faz parte do Endpoint Security Management Server.

Como Funciona — Fluxos de Comunicação

1. Client → Server: o client é SEMPRE quem inicia

Este é o fato arquitetural mais importante para o desenho de regras de firewall: os endpoint clients sempre iniciam as conexões. O servidor nunca conecta "para baixo" em um client.

Serviço (Protocolo/Porta)	Comunicação	Observações
HTTPS (TCP/443)	Maior parte da comunicação (TLSv1.2)	ex.: registro do endpoint, obtenção de novas chaves de criptografia de arquivos
HTTPS (TCP/443)	Download de políticas	Os arquivos de política são criptografados com AES
HTTPS (TCP/443)	Heartbeat	Periódico; reporta mudanças de status de política e compliance
HTTPS (TCP/443)	Consultas do Application Control	Reputação de aplicações desconhecidas
HTTPS (TCP/443)	Upload de logs	Logs do client enviados ao servidor
Protocolo proprietário Check Point	Serviços sensíveis	FDE Recovery Data Upload, Media Encryption & Port Protection Key Exchange, FDE User Acquisition e credenciais
HTTPS (TCP/80)	Atualizações de assinaturas do Anti-Malware	O engine verifica as assinaturas antes de carregar e durante a atualização
HTTPS (TCP/443)	Download de pacotes do client	Os pacotes são assinados e verificados no client antes da instalação

⚠️ Atenção: garanta que os serviços/portas HTTP (TCP/80) e HTTPS (TCP/443) estejam liberados nas regras de Firewall ou Application Control, e que exista roteamento entre todos os elementos do Endpoint Security. A falta de um dos dois é a causa-raiz clássica do "agente não comunica".

2. Console e Server → Server (SIC)

A comunicação entre os elementos de gerenciamento usa o Secure Internal Communication (SIC) da Check Point — os elementos se autenticam mutuamente com certificados.

Serviço (Protocolo/Porta)	Comunicação
SIC (TCP/18190–18193)	SmartEndpoint console → Management Servers
SIC (TCP/18190–18193)	Endpoint Policy Server → Management Servers
SIC (TCP/18221)	Secondary → Primary Management
HTTPS (TCP/443)	Endpoint Policy Server → Primary Management (eventos de monitoramento)

3. O Heartbeat — mensagem pequena, responsabilidades grandes

A cada 60 segundos (padrão), cada client inicia um heartbeat para o seu servidor. O heartbeat:

1. Confirma a conectividade
2. Reporta mudanças no status das políticas
3. Atualiza o estado de Compliance do endpoint

O heartbeat também comanda a máquina de estados de enforcement de compliance — por padrão, o client é restringido após 5 heartbeats consecutivos fora de compliance:

Configuração

Ajustando o intervalo de heartbeat

1. No SmartEndpoint, clique em Manage > Endpoint Connection Settings
2. Em Connection Settings, defina o Interval between client heartbeats
3. Em Out-Of-Compliance, defina "Client will restrict non compliant endpoint after" (padrão: 5 heartbeats)
4. Clique em OK

💡 Dica: intervalo menor = dados de compliance mais frescos, porém mais carga no management. Intervalo maior = menos carga, porém logs e relatórios menos atualizados. 60 segundos é o padrão equilibrado.

Forçando somente TLSv1.2

Por padrão, os servidores aceitam TLSv1.2 e TLSv1. Para restringir a TLSv1.2 apenas, em cada servidor:

cpstop
# Faça backup primeiro:
cp -v $UEPMDIR/apache/conf/ssl.conf{,_BKP}
# Edite $UEPMDIR/apache/conf/ssl.conf e altere:
#   SSLProtocol +TLSv1 +TLSv1.2   -->   SSLProtocol TLSv1.2
cpstart

Certificado de gerenciamento SHA-256

Em instalações limpas R80+ o certificado de gerenciamento já é SHA-256 por padrão. Em ambientes atualizados a partir do R77.x ou anterior, o SHA-256 pode ser usado em certificados renovados após a expiração do anterior:

cpca_client set_sign_hash sha256

Segundo a sk103840, vale entender a mecânica por trás:

• No R77.x e anteriores, a Internal CA (ICA) emite certificados baseados em SHA-1 por padrão; no R80.xx, a ICA passa a ser assinada com SHA-256 por padrão.
• Certificados emitidos pela ICA herdam o algoritmo de assinatura do certificado da ICA. Certificados antigos emitidos por uma ICA root SHA-1 permanecem SHA-1 mesmo depois que a ICA root é recriada com SHA-256 — precisam ser renovados/recriados para herdar o SHA-256.

Para verificar o algoritmo de assinatura do certificado da ICA (Expert mode no Management Server):

cpopenssl pkcs12 -in $FWDIR/conf/InternalCA.p12 -nokeys -nomacver -passin pass: | cpopenssl x509 -noout -text | grep "Signature Algorithm"
# Saída com SHA-256: Signature Algorithm: sha256WithRSAEncryption

ℹ️ Nota: se a ICA ainda estiver em SHA-1, consulte a sk158096 (renovação do certificado da ICA). Dois fatos dessa SK que valem a pena conhecer: o certificado da ICA é válido por 20 anos e historicamente não renovava sozinho — a renovação automática (um ano antes da expiração) chegou a partir do R82 e dos Jumbo Hotfix Takes recentes (R81.20 JHF Take 26+). E se a ICA expirar, os novos certificados assinados por ela (SIC, IKE, usuário) já nascem expirados — renove com pelo menos 2 semanas de antecedência.

Boas Práticas

✅ Boa prática: use Endpoint Policy Servers em ambientes grandes ou multi-site. Por quê: eles assumem heartbeat/sincronização, download de políticas, atualizações de Anti-Malware e logs dos clients, aliviando o Management Server e reduzindo a banda entre sites.

✅ Boa prática: implante um Secondary Management Server. Por quê: garante um management de backup se o primário cair.

✅ Boa prática: na troca de certificados SSL, faça push do novo certificado CA para uma OU pequena primeiro, migre servidores/clients gradualmente e deixe os servidores primário e secundário por último. Por quê: clients sem a CA correspondente não conseguem enviar mensagens SSL (ex.: payloads de FDE e audit logs) para um servidor cujo certificado não confiam.

Erros Comuns

Erro	Impacto	Solução
TCP/80 ou TCP/443 bloqueados entre client e servidor	Agentes aparecem offline, sem políticas/assinaturas	Libere as duas portas nas regras de Firewall/App Control; verifique o roteamento
Trocar o certificado SSL do servidor antes de fazer push da CA correspondente aos clients	Clients não conseguem enviar payloads de FDE e audit logs àquele servidor	Siga o fluxo de troca gradual (CA primeiro, OU pequena, servidores por último)
Esperar que o servidor inicie conexão com os clients	Regras de firewall mal desenhadas	Lembre-se: o client é sempre quem inicia
Esquecer o Install Database no servidor secundário após instalar certificado SSL (HA)	Comportamento inconsistente do HA	Sempre repita o Install Database no secundário

Troubleshooting

Sintoma: clients aparecem desconectados / políticas nunca chegam
Ambiente: Management R81.20 on-premises, qualquer versão de client
Causa-raiz (mais comum): TCP/80 e/ou TCP/443 não liberados entre client e servidor, ou falta de roteamento entre os elementos

Resolução:

1. Confirme que o client alcança o servidor na TCP/443 (e TCP/80 para atualizações do Anti-Malware)
2. Verifique regras intermediárias de Firewall / Application Control
3. Confirme o roteamento entre todos os elementos do Endpoint Security
4. Verifique a confiança de certificados caso certificados SSL tenham sido trocados recentemente

FAQ

P: Quais portas preciso liberar para os endpoint clients?
R: TCP/443 (HTTPS — quase todo o tráfego) e TCP/80 (atualizações de assinaturas do Anti-Malware). O client sempre inicia.

P: O que exatamente o Endpoint Policy Server assume?
R: Heartbeat e requisições de sincronização, download de políticas, atualizações de Anti-Malware e coleta de logs dos clients.

P: O heartbeat é configurável?
R: Sim — padrão de 60 segundos, em Manage > Endpoint Connection Settings. O limite de restrição por out-of-compliance (padrão 5 heartbeats) é configurado no mesmo lugar.

P: Os arquivos de política são protegidos em trânsito?
R: Eles trafegam por HTTPS (TLSv1.2) e os arquivos em si são criptografados com AES. Payloads sensíveis (dados de recovery do FDE, key exchange do ME&PP, credenciais do FDE) usam adicionalmente um protocolo proprietário da Check Point.

Referências

• Check Point R81.20 Endpoint Security Administration Guide (PDF) — capítulos "Introduction to Endpoint Security" e "Endpoint Security Architecture"
• Introduction to Endpoint Security (versão online)
• sk103840 — SHA-1 and SHA-256 certificates in Check Point Internal CA (ICA) (conteúdo verificado em 2026-07-16)
• sk158096 — How to renew an Internal Certificate Authority (ICA) certificate (conteúdo verificado em 2026-07-16)

---

Versões Suportadas: Endpoint Security Management R81.20 (on-premises)  |  Última Atualização: 2026-07-16  |  Autor: Jorge Luiz  |  Artigo 1 da série Harmony Endpoint Deep Dives