Migração de servidor local para nuvem e integração de facial Hikvision

1. Escopo e aplicabilidade

Este documento consolida as instruções técnicas para dois procedimentos que a equipe de integração e manutenção conduz em projetos KeyAccess:

• Migração de estrutura KeyAccess Server local para nuvem (aplicável a qualquer arquitetura — com ou sem facial, com ou sem módulo Cloud).

• Implantação e configuração de facial Hikvision com servidor KeyAccess em nuvem (aplicável quando o projeto inclui terminais Hikvision).

A migração é o assunto principal e a arquitetura com facial Hikvision aparece como um dos cenários possíveis dessa migração — dois dos cinco cenários descritos na seção 3.6 envolvem facial. Sempre que o projeto tem facial Hikvision, os requisitos técnicos específicos das seções 4 a 7 se aplicam.

Documento destinado à equipe de integração e manutenção homologada KeyAccess. Assume os pré-requisitos do curso de certificação KeyAccess já cumpridos; procedimentos básicos de configuração inicial do terminal Hikvision e da controladora KA que constam do treinamento não são repetidos aqui.

2. Pré-requisitos gerais

2.1. Link de internet — restrição de CGNAT

Aplicável sempre que houver servidor KeyAccess em nuvem — seja para migração de estrutura local, seja para novo projeto em nuvem, seja para facial Hikvision comunicando com servidor em nuvem.

Como verificar antes da implantação:

1. Consultar um site de verificação de IPs a partir da rede do cliente (meuip.com.br, whatismyipaddress.com etc.).

2. Verificar se o IPv4 (não IPv6) está no range 100.xxx.yyy.zzz — se estiver, é CGNAT.

3. Caso positivo, consultar a operadora sobre a troca do link para um com endereço válido na internet, sem CGNAT. Sem essa troca a implantação não avança.

2.2. Equipamentos compatíveis com servidor em nuvem

Admite-se integração com o servidor KeyAccess em nuvem os seguintes dispositivos:

• Controladora KeyAccess com periféricos: leitor de cartões, leitor biométrico digital marca Suprema e leitor de QR Code.

• Leitor biométrico facial marca Hikvision — obrigatório o uso de certificado digital (HTTPS).

O cliente pode pretender utilizar dispositivos que não se integram ao servidor em nuvem por não estarem dotados de criptografia. Se sim, a manobra pode ser inviável — identificar isso na análise prévia (3.2).

Os modelos específicos suportados devem ser verificados junto ao setor comercial da empresa de integração, contra a lista de equipamentos compatíveis fornecida pelo time KeyAccess.

2.3. Dados de acesso ao servidor KeyAccess em nuvem

Os dados que servirão de base à implantação/migração são fornecidos após a abertura do chamado, com a criação do servidor em nuvem. As informações básicas são:

• Endereço de acesso ao servidor KeyAccess.

• Porta UDP para conexão da controladora ao servidor.

• ID da licença (configurado na controladora KA em DNS Options → Type: RETAIL → ID: 000000000[x]).

• Portas de comunicação com o(s) terminal(is) facial(is), quando houver.

3. Migração de KeyAccess Server local para nuvem

3.1. Aplicabilidade

Procedimento de mudança da estrutura de um KeyAccess Server em cliente tipo company, com servidor local, para servidor em nuvem.

Cliente tipo company: escritórios ou outras estruturas dedicadas ao controle de acesso em áreas privativas, com fluxos moderados.

3.2. Análise prévia — obrigatória antes de agendar a migração

Ao direcionar dispositivos instalados nas dependências do cliente para comunicação com estrutura em nuvem, o tráfego passa a atravessar as camadas de proteção virtual gerenciadas pelo time de segurança da informação do cliente. Estabilidade e velocidade da banda de internet passam a ser fundamentais.

Antes de iniciar qualquer tratativa, identifique:

• Todos os recursos utilizados pelo cliente hoje (KA + Cloud sim/não · facial Hikvision sim/não · outros).

• Expectativa de expansão — pretensão de dispositivos que não se integram ao servidor em nuvem por não estarem dotados de criptografia inviabiliza a manobra.

• Liberações que o cliente deverá providenciar em sua estrutura de segurança virtual: IPs, portas de comunicação e URLs necessárias.

A análise deve ser fundamentada na política de segurança da informação adotada pelo cliente. Só após esse fechamento a migração pode ser agendada.

3.3. Banco de dados — decisão de migrar ou não

O cliente pode optar por transferir as informações armazenadas no banco de dados do servidor local para o novo servidor em nuvem, ou começar limpo. Se optar por transferir:

1. O KeyAccess Server deve ser atualizado para a última versão disponível no portal de instaladores. Responsabilidade da empresa de integração.

2. O integrador atualiza o firmware das controladoras para a última versão disponível e atualiza configurações de hardware e acessos conforme o curso de certificação KeyAccess — garante compatibilidade entre versões e memórias das controladoras alimentadas com as últimas informações da base.

3. A empresa disponibiliza acesso remoto ao servidor local via Anydesk para o time KeyAccess fazer análise prévia do tamanho da base. Em data agendada, também dá acesso para a exportação dos registros.

4. Para exportar, os serviços do sistema são interrompidos. Apenas as controladoras KA permanecem em funcionamento, com seus periféricos, em modo offline. As validações de passagens ocorrem com base nas informações em memória das controladoras. As liberações por reconhecimento facial ficam interrompidas nesse intervalo.

5. As bases exportadas são copiadas para o ambiente KeyAccess durante o acesso remoto — a empresa atribui os privilégios necessários para a cópia.

3.4. Reconfiguração das controladoras KeyAccess

A alteração da estrutura torna obrigatória a reconfiguração das controladoras KeyAccess. Elas passarão a apontar para o IP e porta UDP do novo servidor em nuvem, fornecidos pelo time KeyAccess.

Requisitos obrigatórios:

• Habilitar DTLS (Datagram Transport Layer Security) para garantir comunicação criptografada com o servidor.

• Modificar a regra de validação de on server para on local.

• Garantir que o endereço do servidor e a porta UDP estejam liberados na rede do cliente — caso contrário as controladoras ficam offline.

Estas ações são executadas pela equipe de integração e manutenção contratada pelo cliente, com base no manual de certificação KeyAccess.

3.5. Cronograma

O preparo do servidor em nuvem requer dias. A empresa de integração deve providenciar cronograma considerando os prazos estabelecidos no Playbook do KeyAccess.

Em caso de uso do sistema facial no projeto, o servidor KA em nuvem precisa encontrar o dispositivo de reconhecimento facial nas dependências do cliente. Aplicam-se então as seções 4 (arquitetura) · 5 (configuração do terminal Hikvision) · 6 (roteador) · 7 (servidor KA para facial) deste documento.

3.6. Matrizes de responsabilidade por cenário de migração

Cinco cenários possíveis, com divisão de atividades entre técnico/cliente e equipe KeyAccess. Os cenários D e E envolvem facial Hikvision e ativam os requisitos das seções 4 a 7.

Cenário A · KeyAccess Company sem Cloud

Cenário B · KeyAccess Company com Cloud (sem migração de dados)

Cenário C · KeyAccess Company com Cloud (com migração de dados)

Cenário D · KeyAccess Company sem Cloud com facial Hikvision

Cenário E · KeyAccess Company com Cloud e facial Hikvision (com migração de dados)

4. Arquitetura com facial Hikvision em nuvem

4.1. Visão geral

A arquitetura compreende um servidor KeyAccess em nuvem que estabelece comunicação com os leitores faciais Hikvision e com as controladoras KeyAccess instaladas nas dependências do cliente.

Elementos:

• Servidor KA em nuvem — inicia conexões para os terminais faciais no local (por HTTPS) e recebe conexões UDP das controladoras.

• Modem/roteador da operadora no site do cliente — precisa expor os terminais Hikvision para a internet via port forwarding (seção 6).

• Terminais faciais Hikvision — atuam como servidor HTTPS (respondem a conexões iniciadas pelo servidor KA). Cada terminal ocupa uma porta externa distinta.

• Controladoras KA — se comunicam com o servidor em nuvem por UDP com DTLS habilitado; validação on local (seção 3.4). A arquitetura sem controladora KA é tratada na seção 8.

4.2. Mapeamento IP externo × IP interno dos leitores faciais

Cada terminal facial precisa ser alcançado individualmente a partir da rede externa. Como o site do cliente normalmente tem um único IP público, o esquema é: uma porta externa distinta por terminal, todas apontando para a porta HTTPS interna do respectivo terminal.

Exemplo de referência (projeto com 5 terminais):

O time de TI do cliente configura o mapeamento no roteador. Os IPs e portas são fictícios no exemplo — a implantação usa os valores reais informados pelo cliente. As portas 7824–7828 são apenas convenção do exemplo; a seção 6 explica por que se recomenda usar portas fora dos valores padrão IANA.

5. Configuração do terminal facial Hikvision

5.1. Firmware do terminal

É recomendado atualizar o firmware do terminal facial para a última versão disponível antes de habilitar HTTPS. A primeira versão de firmware tem problemas conhecidos com HTTPS e pode não funcionar.

Duas rotas de atualização:

• Vários dispositivos ao mesmo tempo — ferramenta Batch Tool disponível no site da Hikvision, área de suporte.

• Um a um — diretamente pela interface web do dispositivo, em Configuration → System → Maintenance → Upgrade.

Obtenção: hikvision.com → Support → Download → Firmware (digite o modelo do equipamento).

5.2. Acesso à interface web e porta HTTPS

Para habilitar HTTPS, faça logon no sistema web do dispositivo por HTTP, como você faria para configurá-lo inicialmente. Se a configuração inicial tiver sido feita pela interface do próprio dispositivo, esta etapa exige a interface web.

Endereço: IP do próprio dispositivo. Login inicial: admin / <senha do administrador cadastrada inicialmente>. As instruções assumem interface em inglês.

Acesse: Configuration → Network → Basic Settings → Port.

Localize HTTPS Port e especifique o número da porta para comunicação HTTPS. O padrão IANA é TCP 443, mas você pode especificar valor diferente por conveniência. Clique em Save.

Valores padrão típicos das outras portas na mesma tela: HTTP 80 · RTSP 554 · HTTPS 443 · Server 8000.

5.3. Importação dos certificados digitais

Acesse: Configuration → System → Security → Certificate Management. A instalação segue esta ordem (três arquivos, três áreas da mesma tela):

5.3.1. CA Certificate

1. Na área Import CA Certificate, clique no ícone de pasta e localize 50-intermediate-ca.cert.pem.

2. Clique em Install. Havendo sucesso, aparecerá um número com ícone de verificação em Custom ID.

5.3.2. Communication Certificate

1. Na área Import Communication Certificate, em Certificate Type escolha HTTPS.

2. Localize HIKVISIONxxxx.cert.pem e clique em Install.

5.3.3. Chave privada (Import Passwords)

1. Na área Import Passwords, em Certificate Type escolha HTTPS.

2. Localize HIKVISIONxxxx.key.pem e clique em Install.

5.4. Authentication Settings

Acesse: Configuration → Access Control → Privacy. Na seção Authentication Settings:

• Display Authentication Result: marcar apenas Face Picture (desmarcar Name e Employee ID).

• Clicar em Save.

5.5. Picture Uploading and Storage

Logo abaixo da seção anterior, na mesma tela, configure Picture Uploading and Storage conforme:

• Upload Captured Picture When Authenticating: desligado.

• Save Captured Picture When Authenticating: ligado.

• Save Registered Picture: ligado.

• Upload Picture After Linked Capture: desligado.

• Save Pictures After Linked Capture: ligado.

Clicar em Save.

5.6. Aviso do navegador ao acessar por HTTPS

6. Configuração do roteador — port forwarding

6.1. Por que port forwarding é obrigatório

O roteador da operadora, em seu NAT, possui por padrão um firewall que bloqueia início de conexões da WAN (internet) para a LAN (rede interna) — segurança intrínseca contra ataques externos. Nessa configuração padrão, porém, a solução não funciona: tanto o terminal facial quanto o servidor KeyAccess iniciam conexões (agem como servidores de forma mútua).

Para permitir essa comunicação é necessário liberar (abrir e rotear) uma porta do roteador para a internet, redirecionando conexões que chegam ao IP público na porta escolhida para o IP e porta internos do terminal facial. O recurso chama-se Port Forwarding — em alguns roteadores mais novos, Virtual Server.

6.2. Boas práticas de segurança na escolha da porta externa

Referência da tabela IANA: https://pt.wikipedia.org/wiki/Lista_de_portas_dos_protocolos_TCP_e_UDP

6.3. Exemplo em roteador da operadora Vivo

Exemplo típico em Vivo Box (menu Rede local → Redirecionar Portas):

Nesse exemplo, tudo que chega no IP público via porta 7834 é entregue ao terminal facial em 192.168.1.10:443. Repita a regra para cada terminal facial adicional, mudando a porta externa e o IP interno.

Seu roteador pode ser diferente (outra operadora, outro fabricante) — entenda o conceito e replique consultando o manual do modelo ou vídeos específicos. Caso não consiga, envolva um especialista em redes do cliente.

7. Configuração do servidor KeyAccess para facial Hikvision

7.1. Ativação de HTTPS no módulo facial

Acesse o servidor KeyAccess com usuário técnico (ou com privilégio de técnico). No menu à direita, vá em Configurações avançadas → Módulo Facial.

Ative ambas as opções de HTTPS:

• “O KeyAccess está utilizando HTTPS?” → Sim.

• “O Facial utiliza HTTPS com PADs/Servidores?” → Sim.

Confirme também os campos:

• Host do KeyAccess: host correto do KA em nuvem.

• Porta do KeyAccess: porta de execução do KA (padrão típico 9443).

• IP e porta do Módulo ControlID: quando aplicável.

7.2. Cadastro do dispositivo facial

No menu principal do KeyAccess, item Facial, cadastre cada terminal facial com os campos abaixo. Este é o mesmo menu utilizado nas configurações iniciais.

Tipo de servidor: PAD Hikvision.

• Nome: nome identificador do terminal (ex: “Entrada Principal”, “Hikvision-1”).

• Ativo: Sim.

• Master: Sim / Não conforme o projeto.

• Login / Senha: credenciais do dispositivo (padrão admin).

• IP / Nome do Servidor: ver 7.3.

• Porta 1: ver 7.3.

• Debounce: intervalo entre capturas em ms (padrão 5000).

• Controladora KA: Sim quando existir controladora KA associada. Não quando for arquitetura sem controladora (ver seção 8).

• Temperatura mínima / máxima: válidas apenas em PADs com controle de temperatura.

• Detecção de máscara: ativar se o projeto exigir.

7.3. IP e porta do terminal — cadastro correto por cenário

O que preencher em IP/Nome do Servidor e Porta 1 depende do cenário:

Erro comum: em projeto KA em nuvem, preencher com IP interno do terminal — o servidor em nuvem não consegue acessar a LAN privada do cliente e a comunicação falha silenciosamente.

8. Caso especial — facial Hikvision sem controladora KeyAccess

8.1. Contexto e aplicabilidade

Esta solução é destinada a projetos que utilizam dispositivos de reconhecimento facial Hikvision sem a utilização de controladoras KeyAccess.

É normalmente aplicada em portas equipadas com eletroímã, cujo acionamento é realizado diretamente pelo relé integrado ao dispositivo de reconhecimento facial.

8.2. Sintoma reportado

8.3. Causa

Na arquitetura em que o dispositivo Hikvision realiza o acionamento da porta diretamente, o KeyAccess passa a validar os grupos de acesso de forma mais rigorosa a partir da versão 2.2.29.5.

Quando um grupo de acesso possui mais de um período associado à mesma área, a sincronização com o dispositivo facial ocorre de forma incompatível — daí a mensagem “Horário não permitido no grupo de acesso” e a porta não libera.

8.4. Configuração correta dos grupos de acesso

Revise todos os grupos de acesso do projeto e ajuste para respeitar a regra 1 período por área. Se o projeto exige múltiplos períodos, avaliar a criação de áreas separadas.

8.5. Configuração do servidor facial no KeyAccess

As configurações do servidor cadastrado no KeyAccess como dispositivo facial devem seguir os parâmetros recomendados para este tipo de arquitetura (consultar cadastro-modelo com o SAC / referência do treinamento). Em particular:

• Cadastro do PAD Hikvision com Controladora KA = Não.

• Demais campos conforme seção 7.2 deste documento.

8.6. Sincronismo com o dispositivo facial

Após ajustar as configurações dos grupos de acesso, é necessário sincronizar com o dispositivo facial. No KeyAccess:

1. Acesse o cadastro do Servidor Facial.

2. Clique em Ações.

3. Selecione Sincronizar grupos.

Confirme a operação testando a liberação por reconhecimento facial no terminal. A mensagem “Horário não permitido no grupo de acesso” não deve mais ocorrer.

9. Verificação final e escalação

9.1. Checklist de verificação após implantação/migração

• As controladoras KA mostram-se conectadas ao servidor em nuvem (não offline) — DTLS ativo e validação on local.

• Se houve migração de banco: os cadastros e o histórico do cliente estão íntegros na nuvem.

• Se há facial: cada terminal responde por HTTPS na porta externa configurada no roteador (testar do IP público, não da LAN interna).

• Se há facial: o servidor KeyAccess mostra os terminais faciais como online no cadastro do módulo Facial.

• Um teste real de liberação de porta (cartão / QR / facial, conforme o projeto) é registrado no monitor de eventos do KeyAccess.

• Se arquitetura sem controladora KA: nenhuma mensagem “Horário não permitido no grupo de acesso” aparece em teste com usuário válido.

9.2. Quando escalar para o time KeyAccess

• Inconsistências na base de dados após restauração no servidor em nuvem — envolver a equipe KeyAccess responsável pela publicação.

• Controladoras não conectam ao servidor em nuvem mesmo com DTLS e liberação de portas UDP confirmadas.

• Certificados digitais fornecidos não instalam no terminal Hikvision — abrir chamado no SAC com o log do erro.

• Terminal facial cadastrado no KA aparece offline mesmo com port forwarding correto e teste externo passando — abrir chamado no SAC.