Entenda a arquitetura, a operação e conformidade
Sobre migração da Infraestrutura de pagamentos para bancos e instituições de pagamentos. A modernização da infraestrutura criptográfica de pagamentos exige uma abordagem que vá além da simples substituição de hardware. Em ambientes financeiros regulados, a camada criptográfica é parte crítica da continuidade operacional, da conformidade e da integridade transacional. Por isso, a migração de um ambiente baseado em Thales payShield 10K on-premises para um modelo de Cloud HSM HoP (HSM off-Premises) deve ser tratada como um projeto estruturado de arquitetura, segurança, governança de chaves e integração aplicacional.
O objetivo deste recurso é fornecer basicamente uma visão técnica, porém não aprofundada sobre o processo de migração, detalhando os modelos arquiteturais disponíveis, os requisitos mandatórios, os impactos na gestão criptográfica e os cuidados operacionais necessários para garantir continuidade e aderência regulatória.
1. Contexto técnico da modernização
A infraestrutura criptográfica em pagamentos sustenta funções críticas como PIN translation, geração e validação de CVV/CVC, tokenização, criptografia de trilhas, proteção de chaves e comandos de autorização.
Em ambientes legados, é comum que bancos, adquirentes e processadoras operem com HSMs físicos instalados em datacenters próprios (ou contratados), dimensionados para suportar picos sazonais, contingência e crescimento futuro. Embora esse modelo ofereça controle físico direto, ele também gera desafios relevantes de capacidade, ociosidade, ciclos de expansão, manutenção e compliance.
A migração para o HoP elimina a dependência da gestão física do equipamento, preservando a robustez criptográfica do payShield 10K, agora disponibilizado como serviço gerenciado em ambiente cloud certificado.
O principal ganho técnico é a transição de um modelo de CAPEX com gestão local de hardware para uma arquitetura de infraestrutura criptográfica elástica, segregada logicamente e operada sob SLA.
2. Modelos de migração
A migração pode seguir dois caminhos arquiteturais distintos, definidos pela maturidade da aplicação e pelo objetivo do projeto.
2.1 HoP GO — continuidade com comandos nativos
O modelo HoP GO é indicado para ambientes onde a aplicação já consome comandos nativos do HSM via TCP/IP. Neste cenário, o foco é a preservação do legado, mantendo a lógica criptográfica já implementada na aplicação.
Isso significa que autorizadores, switches e aplicações de terceiros, como Postilion, Base24 ou ACI, continuam enviando os mesmos comandos proprietários Thales que já enviavam para o HSM físico.
Do ponto de vista da aplicação, não há necessidade de refatoração funcional. A principal mudança ocorre na camada de conectividade e na gestão criptográfica.
A aplicação deixa de apontar para o IP do HSM físico local e passa a se conectar ao tenant lógico dedicado no HoP por meio de um túnel seguro mTLS.
2.2 HoP API — modernização e abstração
O modelo HoP API é orientado à modernização de aplicações e ao desenvolvimento de novos produtos. Neste caso, a complexidade dos comandos proprietários do HSM é abstraída por uma camada RESTful.
A aplicação deixa de montar comandos binários ou strings hexadecimais e passa a consumir endpoints HTTPS em JSON. A tradução do request, autenticação, execução criptográfica e retorno da resposta passam a ser responsabilidade do API Gateway do HoP.
Esse modelo é recomendado para arquiteturas baseadas em microsserviços, aplicações cloud-native, APIs financeiras e novos canais digitais.
3. Arquitetura de conectividade
A conectividade é um dos pontos tecnicamente mais sensíveis do projeto. O principal fator que pode gerar atraso em projetos reais é a prontidão da equipe no lado da instituição que consome os serviços para configurar certificados e regras de rede.
A comunicação entre a aplicação e o HoP ocorre por Mutual TLS (mTLS). Isso significa que ambas as pontas realizam autenticação mútua antes do tráfego de qualquer dado transacional.
A infraestrutura da instituição que consome os serviços deve gerar:
- CSR - chave privada - certificado cliente - gestão de expiração e renovação
A First Tech consome o certificado público e realiza a instalação no tenant.
A responsabilidade sobre geração e ciclo de vida do certificado é integralmente da empresa que consome o serviço.
Além disso, a equipe de infraestrutura deve configurar:
- allow-listing de IPs
- regras de egress
- liberação de portas
- validação de rotas
- monitoramento de disponibilidade
A indisponibilidade ou expiração do certificado interrompe completamente o fluxo transacional.
4. Migração de chaves criptográficas
Esta é a etapa tecnicamente mais crítica de toda a jornada e a migração para HoP exige alinhamento com padrões de conformidade em nuvem, especialmente PCI PIN e PCI DSS. Por isso, ambientes que ainda utilizam chaves no formato Variant precisam passar por conversão para Key Block, padrão requerido para ambientes cloud PCI.
Essa etapa envolve:
- inventário completo do parque de chaves
- classificação por tipo
- volumetria
- dependências por aplicação
- planejamento de cerimônia
- validação por KCV
Entre os tipos de chave normalmente migrados estão: LMK, ZMK, PVK, CVK, TAK e ZPK.
A ausência de inventário completo pode causar indisponibilidade em funções críticas como: validação de CVV, PIN verification, PIN translate, geração de MAC e tokenização.
5. Cerimônia de chaves
A migração de chaves deve ocorrer por cerimônia formal e os custodiantes da instituição que consome os serviços devem estar disponíveis com: smart cards, componentes físicos, senhas compartilhadas e segredos particionados.
A First Tech provê o ambiente lógico e o console de operação e a instituição mantém responsabilidade sobre a posse dos segredos. A First Tech não realiza custódia física de componentes Smart Cards ou anotações de senhas de componentes de chaves da instituição.
6. Homologação técnica
A homologação deve garantir equivalência funcional absoluta entre o ambiente anterior e o novo. São recomendados testes de paridade de comandos, ou seja, o mesmo input deve gerar exatamente o mesmo output. Isso inclui: códigos de retorno, formatos, tempos médios e consistência criptográfica.
Além disso, devem ser executados testes de: RTT, timeout, failover, retry e rollback.
7. Go-live e hypercare
A virada deve ocorrer em janela formal de corte. A recomendação técnica é possuir plano documentado de rollback. Durante as primeiras horas de operação, deve existir monitoramento intensivo com acompanhamento conjunto entre First Tech e a instituição.
O foco é validar estabilidade do túnel, throughput, latência, falhas 4xx/5xx, consumo do tenant e indicadores de HSM pool.
8. Considerações de arquitetura
A migração para HoP deve ser tratada como evolução arquitetural e não é apenas mudança de endpoint. Isso envolve conectividade segura, adequação PCI, evolução de formato de chaves, redefinição de operação, observabilidade e
modelo de SLA.
Para bancos, adquirentes e fintechs, isso significa sustentar crescimento transacional com governança e elasticidade.
