Segurança

Introdução

Este guia consolida um conjunto de diretrizes e recomendações técnicas voltadas ao fortalecimento da segurança em ambientes restritos que fazem uso intensivo de HSMs DINAMO e material criptográfico sensível. Esses ambientes são particularmente críticos em instituições financeiras e prestadores de serviço que operam sistemas como o SPB (Sistema de Pagamentos Brasileiro) e o Pix, nos quais a integridade das chaves e certificados institucionais é pressuposto inegociável para a continuidade dos serviços e para a confiança depositada pelos clientes, contrapartes e órgãos reguladores.

As práticas aqui descritas partem do princípio de defesa em profundidade: múltiplas camadas de controle se sobrepõem de modo que a falha isolada de uma delas não comprometa o todo. O texto a seguir está organizado em blocos temáticos, iniciando pelos controles mais genéricos de infraestrutura e avançando progressivamente para as particularidades da operação segura de HSMs.

Note

Consulte também o tópico Procedimentos de Segurança para o Operador.

Controles Genéricos de Infraestrutura

Antes de tratar das especificidades criptográficas, é indispensável que o ambiente em que o HSM está inserido siga controles básicos de segurança. Um HSM operando dentro de uma rede permissiva, com máquinas cliente mal protegidas e políticas de acesso frouxas, tem seu valor significativamente reduzido,pois o atacante raramente precisará enfrentar o HSM diretamente, basta comprometer o que está ao seu redor.

Isolamento de Rede

O ambiente deve estar segregado em uma rede dedicada, protegida por firewalls configurados para permitir somente o tráfego estritamente necessário à operação. O acesso administrativo deve ser realizado exclusivamente por meio de bastion hosts ou jump servers devidamente monitorados, e jamais deve haver exposição direta do HSM ou das máquinas operacionais à Internet ou a redes corporativas de propósito geral. Sempre que possível, as interfaces de gerenciamento do HSM devem residir em uma VLAN distinta daVLAN de uso das aplicações clientes, separando o plano de controle do plano de dados.

Filtro de IP

Há uma feature no HSM, onde todo acesso , seja para operação transacional, seja para administração, deve passar por listas de controle de acesso baseadas em endereço IP de origem (e, opcionalmente usuário + IP).Essa restrição deve ser aplicada tanto no nível do firewall quanto, preferencialmente, na própria configuração do HSM, criando uma dupla barreira. O filtro de IP elimina uma vasta gama de ataques oportunistas e reduz drasticamente o espaço de tentativas de força bruta e varredura. Recomenda-se arevisão periódica dessas listas, de modo a remover entradas de máquinas desativadas ou de colaboradores desligados.

Política de Senhas

A instituição deve manter uma política de senhas formalizada, aplicável a todas as contas de uso do HSM e dos sistemas correlatos. Essa política precisa contemplar, no mínimo:

Controle de falhas de autenticação, com bloqueio temporário ou permanente da conta após um número definido de tentativas consecutivas malsucedidas, prevenindo ataques de força bruta e gerando sinalização a ser tratada pela equipe de resposta a incidentes;
Tamanho mínimo e requisitos de complexidade compatíveis com o que está definido no manual, ou seja, 16 caracteres no máximo mas que representa 128 bits onde a recomendação é a geração de novas senhas utilizando um gerador com distribuição uniforme usando caracteres base62, evitando senhas previsíveis e dificultando ao máximo ataques com uso de dicionário;
Rotacionamento periódico em intervalos definidos, complementado por rotacionamento extraordinário sempre que houver suspeita de comprometimento ou desligamento de custodiantes, esse item não se trata de uma feature do HSM e sim uma prática arquitetural de projeto para o uso.

A política de senhas isoladamente é insuficiente como medida de proteção, mas compõe o alicerce sobre o qual os demais controles se apoiam.

Conta-Alvo: A Raiz da Confiança Institucional

Dentro do HSM, a instituição deve constituir uma ou mais contas, denominadas de partições no nível do manual do equipamento, destinadas exclusivamente à custódia dos certificados institucionais. A segregação recomendada é a seguinte:

Para o SPB, deve-se manter uma conta-alvo por domínio ou instituição participante;
Para o Pix, deve-se manter uma conta-alvo por instituição;
Para outros sistemas críticos, aplicar a mesma lógica de segregação por domínio de responsabilidade.

A conta-alvo deve ser compreendida como a raiz da confiança institucional dentro do HSM. Seu uso cotidiano é, por desenho, raro: ela é acessada essencialmente para substabelecer outros acessos, isto é, para autorizar que contas operacionais subordinadas passem a exercer funções em nome da instituição. Em um ciclo normal de operação, essa movimentação ocorre com baixíssima frequência, muitas vezes em intervalos de meses ou anos, o que permite aplicar sobre ela controles mais restritivos sem prejuízo da agilidade operacional.

Custódia Compartilhada

A senha da conta-alvo nunca deve estar integralmente sob o controle de um único indivíduo. O mecanismo recomendado é o de múltiplos custodiantes, com no mínimo dois participantes. Essa divisão de responsabilidade impede ações unilaterais, reduz o risco associado a coação ou má-fé individual e cria um processo formal e observável para qualquer ação crítica.

Restrição por Usuário e IP

Além da custódia compartilhada, o acesso à conta-alvo deve estar condicionado à combinação autorizada de usuário e endereço IP de origem. Essa amarração física-lógica impede que credenciais eventualmente vazadas sejam utilizadas fora da estação operacional originalmente autorizada, e converte qualquer tentativa de uso a partir de origem não prevista em evento de segurança digno de investigação imediata.

Deve-se monitorar os logins para essas contas periodicamente usando processamento das logs das máquinas.

Conta de Aplicação (App)

A operação cotidiana do HSM, a assinatura de mensagens, a validação de certificados e as demais funções criptográficas consumidas pelos sistemas internos, jamais deve ser realizada a partir da conta-alvo. Essa responsabilidade cabe a uma conta de aplicação, criada especificamente para este fim, usando o permissionamento específico.

Permissionamento Granular

A conta de aplicação deve ser configurada segundo o princípio do menor privilégio, recebendo apenas as permissões de leitura de objetos da conta-alvo. Operações administrativas, criação de novas chaves fora do fluxo previsto e acesso a objetos de outras aplicações devem estar explicitamente vedados. Quando a instituição opera múltiplas aplicações distintas,recomenda-se fortemente que cada uma possua sua própria conta de App, de modo que um eventual comprometimento de uma aplicação não se propague às demais.

Rotacionamento de Senha

A credencial da conta de App não precisa ser uma senha textual: o HSM admite o uso de um PSK (PreShared Key) de 128 bits (16 bytes), denominado ATOKEN, como mecanismo de autenticação. O ATOKEN é igualmente rotacionável e, por ser um segredo de alta entropia gerado aleatoriamente, elimina as fragilidades típicas de senhas escolhidas (previsibilidade, reuso, suscetibilidade a ataques de dicionário),sendo a opção preferencial para autenticação de aplicações.

A senha, ou o ATOKEN, da conta de App deve ser rotacionada periodicamente, em ciclos compatíveis com a criticidade da aplicação e com a política interna da instituição. Para que esse rotacionamento ocorra sem impacto operacional, devem existir scripts ou ferramentas automatizadas responsáveis por gerar uma nova senha, atualizá-la no HSM e propagá-la ao cofre de segredos utilizado pelas aplicações. Esse processo deve ser auditável, resistente a falhas intermediárias, ou seja, capaz de recuperar um estado consistente caso interrompido, e testado regularmente fora de janela crítica. Senhas de conta de App jamais devem ser armazenadas em arquivos de configuração em claro, em repositórios de código ou em ferramentas de colaboração.

Autenticação Multifator da Conta de APP (Chave Assimétrica + PSK)

Para aplicações críticas, recomenda-se elevar a autenticação da conta de APP para dois fatores, combinando a PSK (senha ou ATOKEN) com um certificado X.509 e sua respectiva chave privada, associados à partição. Nesse arranjo, o cliente se autentica ao HSM por meio de mTLS (TLS mútuo), o HSM valida o certificado apresentado pela aplicação e, em seguida, exige a PSK correspondente, de modo que a posse de apenas um dos fatores é insuficiente para estabelecer a sessão.

Esse modelo aumenta substancialmente o nível de segurança efetivo da autenticação, pois combina algo que a aplicação sabe (a PSK, com alta entropia quando gerada como ATOKEN de 128 bits) com algo que a aplicação possui (a chave privada associada ao certificado). Para que as garantias do segundo fator não sejam erodidas, a chave privada usada no mTLS não deve residir em variável de ambiente nem em arquivos de configuração irrestritos: ela deve ser armazenada em arquivo protegido por listas de controle de acesso (ACLs) no sistema de arquivos, sob uma cadeia de custódia distinta da que administra a PSK. Dessa forma, um eventual comprometimento de um dos fatores, vazamento da PSK do cofre de segredos ou acesso indevido à chave privada, não é suficiente, isoladamente, para autenticar-se como a aplicação.

A rotação dos dois fatores deve ser independente e automatizada, seguindo os mesmos princípios descritos acima. Cabe observar que o HSM não admite todas as combinações possíveis de fatores: especificamente, a combinação de ATOKEN com PSK não é suportada por desenho; a composição recomendada para 2FA na conta de App é, portanto, chave assimétrica (certificado X.509) associada à PSK.

Conta dos Integrantes da Equipe de Segurança

A inclusão, substituição e remoção de certificados no HSM é uma atividade periódica que normalmente fica a cargo de uma equipe de segurança especializada. Cada integrante dessa equipe deve possuir sua própria conta pessoal e nominal no HSM, em vez de compartilhar credenciais genéricas.

A existência de contas individuais produz três benefícios diretos:

Cria registros de auditoria precisos, nos quais cada operação de manipulação de objetos fica associada a um operador identificável, viabilizando processos de revisão, perícia e responsabilização.
Permite a revogação imediata de acesso em caso de desligamento ou mudança de função, sem os custos associados a trocar senhas compartilhadas e redistribuí-las.
Cria as condições para aplicação de autenticação multifator (MFA) por operador, combinando a senha com um segundo fator de posse, um token físico, um smartcard ou uma aplicação autenticadora, o que eleva substancialmente o custo de um ataque bem-sucedido.

A política de segurança da instituição deve tornar o uso de MFA obrigatório para essas contas, e nenhuma exceção deve ser admitida sob pretexto de conveniência operacional.

Usuários Operadores do HSM e Segregação de Privilégios

Além das contas de custódia de certificados e das contas de aplicação, o HSM permite a criação de usuários operadores, dotados de funções administrativas que os usuários comuns não possuem. Entre as atribuições típicas desse perfil estão a extração e visualização de logs, a criação de novos usuários, a alteração de parâmetros de configuração das máquinas e demais operações de manutenção que sustentam a administração saudável do equipamento. A existência de um perfil operador distinto é fundamental para que atividades administrativas rotineiras possam ser realizadas sem que seja necessário acessar diretamente contas-alvo ou contas de aplicação, respeitando-se o princípio da separação de responsabilidades. Uma informação importante seria a "não utilização" do usuário master (que vem no HSM como default e não pode ser apagado). Este usuário possui permissão igual a um operador, com a restrição (além de não poder ser apagado), de que se sua senha for bloqueada, somente pode ser desbloqueada por operação em console local fisicamente ligada ao HSM.

É importante destacar, contudo, uma garantia fundamental oferecida pelo HSM em relação a esses usuários administrativos: não há qualquer possibilidade de um usuário operador utilizar um objeto, como uma chave, pertencente a outra partição para realizar operações criptográficas, a menos que lhe tenha sido concedida permissão explícita para tanto. Essa propriedade é crucial, pois significa que privilégios administrativos não se convertem automaticamente em privilégios de uso do material criptográfico custodiado. O administrador pode gerenciar o equipamento sem, com isso, ganhar acesso operacional às chaves das partições, a barreira entre o plano de administração e o plano de uso criptográfico é mantida pelo próprio HSM, independentemente das boas práticas aplicadas pela instituição. Esse comportamento, por si só, já reduz substancialmente o risco associado ao comprometimento de contas administrativas e reforça o valor da segregação de partições descrita nas seções anteriores.

Geração e Gestão do Material Criptográfico

O tratamento dado às chaves é, em última análise, o que define a qualidade do uso do HSM. Um HSM operado com chaves exportáveis, manipuladas fora do equipamento ou transferidas por meios inseguros,perde boa parte de sua razão de ser.

Chaves Não Exportáveis

Sempre que possível, as chaves privadas devem ser geradas diretamente dentro do HSM, com o atributo de não exportabilidade definido no momento da criação. Dessa maneira, o material criptográfico sensível nunca sai do equipamento em claro, e mesmo um administrador com privilégios elevados fica impedido de extraí-lo. Esta é a configuração que realmente materializa as garantias de proteção oferecidas pelo HSM.

Fluxo Adequado para Certificados

O uxo recomendado para obtenção de um certificado operacional é o seguinte: gera-se a chave privada dentro do HSM, produz-se o CSR (Certificate Signing Request) a partir dessa chave ainda dentro do equipamento, envia-se o CSR à autoridade certificadora e, por fim, importa-se apenas o certificado assinado resultante. Em nenhum momento a chave privada trafega fora do HSM. Esse processo deve ser documentado passo a passo, e a equipe de segurança deve ser treinada para recusar fluxos alternativos que impliquem a geração externa da chave.

Transferência entre Partições

Em cenários em que uma mesma chave precisa estar disponível em partições distintas, por exemplo, para atender a requisitos de alta disponibilidade ou para replicação entre ambientes equivalentes, a transferência deve ser realizada por meio do mecanismo de backup e restore de chave oferecido pelo próprio HSM. Esse mecanismo transporta o material criptografado com proteção de alta qualidade e preserva as propriedades de não exportabilidade e de controle de acesso da chave original. Nunca se deve recorrer à exportação em claro ou a formatos intermediários inseguros para realizar essa transferência.

Proteção Física e Operacional dos Equipamentos

A segurança lógica depende de uma base de segurança física consistente. O HSM deve estar instalado em ambiente com controle de acesso físico auditado, preferencialmente em sala-cofre ou rack trancado dentro de datacenter classificado.

Smartcards e Custódia Compartilhada em Operações Administrativas

As operações administrativas dos equipamentos, inicialização, mudança de parâmetros, mudança de rede,entre outras, devem ser protegidas por smartcards acompanhados de PIN, operados também sob esquema de múltiplos custodiantes. Essa combinação exige a presença física simultânea de mais de uma pessoa autorizada para que qualquer ação crítica seja concretizada, o que reproduz no plano administrativo as mesmas garantias já descritas para a conta-alvo.

Segregação de Ambientes

Sempre que viável, diferentes aplicações devem operar em HSMs ou partições distintas. A separação entre SPB, Pix e demais sistemas críticos é altamente recomendada, pois limita o impacto de eventuais comprometimentos e facilita a atribuição de responsabilidades. Já a separação entre os ambientes de homologação e produção é obrigatória: um HSM de produção jamais deve ser utilizado para testes, e chaves de produção jamais devem transitar pelo ambiente de homologação. Essa regra deve ser tratada como inegociável, inclusive diante de pressões de cronograma.

HSMs Dinamo possuem a característica de rapidamente serem colocados operacionais, então é possível mediante a configuração de rede e de dominio colocar um HSM antes utilizado em outro ambiente (como por exemplo, homologação) em um ambiente de produção por algum motivo de substituição de máquina ou acréscimo no cluster. Essa operação não provoca a parada do ambiente produtivo alvo.

Continuidade Operacional e Recuperação de Desastres

A perda do acesso às chaves institucionais equivale, do ponto de vista prático, à interrupção dos serviços que delas dependem. Por isso, a estratégia de continuidade precisa ser planejada com o mesmo rigor aplicado aos controles preventivos.

Devem ser realizados backups periódicos e controlados seguindo uma rotina formal que defina periodicidade, responsáveis, locais de armazenamento e prazo de retenção. Os backups precisam ser armazenados em meios seguros e fisicamente segregados do ambiente de produção, preferencialmente em mais de um local.

Monitoramento e Auditoria Contínua

Nenhum conjunto de controles é capaz de eliminar completamente a possibilidade de incidentes. A diferença entre uma instituição resiliente e uma instituição vulnerável costuma estar na velocidade com que anomalias são detectadas e tratadas.

Os equipamentos HSM devem ser monitorados continuamente, idealmente por meio de protocolos como SNMP para coleta de métricas e SMTP para envio de alertas, além da integração com a plataforma de SIEM corporativa. Devem gerar alertas específicos pelo menos para os seguintes eventos:

Criação de novos usuários ou partições, operação incomum que merece revisão imediata sempre que ocorrer fora de um plano autorizado;
Logins fora do período normal de operação, em especial para contas de App ou contas administrativas, que sinalizam possível uso indevido de credenciais;
Tentativas repetidas de autenticação malsucedida, que podem indicar ataques de força bruta ou erros de configuração relevantes;
Alterações de políticas, de configuração ou de permissionamento, que alteram o perímetro de segurança do equipamento;
Eventos de saúde do equipamento, como falhas de hardware, temperatura anômala ou violação (tamper), que exigem resposta operacional imediata.

Os logs produzidos devem ser preservados por período compatível com as exigências regulatórias e com a política de retenção da instituição, e devem ser protegidos contra adulteração.

Recomendações Finais

As boas práticas descritas neste guia não formam uma lista estática. O cenário de ameaças evolui continuamente, assim como as capacidades dos equipamentos, os requisitos regulatórios e as exigências das contrapartes. Por isso, recomenda-se que este documento seja revisado periodicamente, no mínimo uma vez por ano, ou sempre que houver mudanças significativas na infraestrutura, na legislação aplicável ou no portfólio de aplicações críticas da instituição.

Recomenda-se também que a adoção dessas práticas seja acompanhada por programas de treinamento e conscientização direcionados às equipes envolvidas, pois a eficácia dos controles depende diretamente do grau de compreensão e adesão dos profissionais que os operam. A documentação técnica dos equipamentos deve permanecer acessível à equipe responsável, especialmente nos momentos de planejamento de mudanças e de resposta a incidentes.