Replicação
Info
A Replicação está disponível em equipamentos com firmware a partir da versão 3.
O HSM conta com um sistema de replicação automática de operações entre HSMs, funcionando como uma base de dados distribuída, onde todos os HSM participantes da replicação mantém uma visão unificada da base de dados, o que inclui chaves e partições de usuários.
O mecanismo funciona de forma inteiramente distribuída e descentralizada em modo multi-master, ou seja, não há diferenciação fixa de papel ou atributos entre os HSMs. Toda a replicação acontece de forma transparente para a aplicação; uma vez configurados os HSMs, nenhuma ação por parte do desenvolvedor ou do operador do HSM é necessária. Também não há arquivos de configuração ou controles fora do HSM, já que toda a informação para operar a replicação está no próprio HSM.
Os HSMs participantes do esquema de replicação são denominados Nós (ou Nodes) e o conjunto dos HSMs se comunicando para manter a base de dados replicada é chamado Domínio de Replicação (ou pool).
Para participarem de um Domínio de Replicação, os HSMs precisam usar a mesma Server Master Key (SVMK) e estar no mesmo modo de operação, além de possuírem conectividade ponto a ponto, ou seja, todos os HSM devem poder se comunicar com todos os demais HSMs. A porta do serviço de replicação é a mesma do serviço geral do HSM (TCP 4433). É o requisito de mesma SVMK que permite a comunicação segura entre os HSM durante a replicação. Toda a comunicação entre os HSMs no protocolo de replicação é criptografada.
São replicadas as operações de criação, destruição e atualização de chaves e objetos na base do HSM, assim como as operações de partição de usuários. Não são replicadas operações de leitura e operações com chaves e objetos temporários, pois estes só existem durante a sessão de comunicação entre um client e o HSM, finalizada a sessão os objetos temporários são automaticamente removidos.
O mecanismo de replicação é disparado sempre a partir do HSM onde é solicitada a operação, seja por uma sessão cliente, seja pelo operador. Este HSM que inicia o processo é denominado Coordenador e os demais são chamados Participantes. Como o sistema é descentralizado, estes papéis de Coordenador e Participante são atribuídos a cada nova operação e podem ser atribuídos a qualquer HSM do pool em uma dada operação.
O protocolo de comunicação utilizado é o Two Phase Commit (2PC). Este protocolo de transação distribuída trabalha em duas etapas, na primeira o coordenador da transação pede que os participantes votem numa transação proposta, cada participantes recebe e analisa a transação, se for possível efetivar a transação o participantes responde ao coordenador que está pronto para fazer o commit. Quando o coordenador recebe o voto de todos os participantes, ele decide se transação deverá ser efetivada ou cancelada, baseada nos votos recebidos; se todos os participantes votaram pela efetivação o coordenador emite uma mensagem de commit para todos os nós, e todos efetivam a mudança em suas bases locais .Se algum dos participantes votou negativamente, o coordenador emite uma mensagem de rollback para os participantes e a transação é cancelada, o que faz com que todos os nós permaneçam com a base de dados no status original, antes do pedido de voto do coordenador.
---
title: Protocolo Two Phase Commit
---
%%{ init: { 'flowchart': { 'curve': 'basis' } } }%%
flowchart LR
classDef red_s stroke:#f00
Coord[Coordenador]
Part1[Participante]
Part2[Participante]
Part3[Participante]
Coord -.prepare.-> Part1
Part1 -.vote.-> Coord
Coord -.-> Part2
Part2 -.-> Coord
Coord -.-> Part3
Part3 -.-> Coord
Coord2[Coordenador]
Part1.2[Participante]
Part2.2[Participante]
Part3.2[Participante]
Coord2 -.commit/rollbak.-> Part1.2
Part1.2 -.ack.-> Coord2
Coord2 -.-> Part2.2
Part2.2 -.-> Coord2
Coord2 -.-> Part3.2
Part3.2 -.-> Coord2
linkStyle 0,6,2,4,6,8,10 stroke:#f33,stroke-width:1px;
linkStyle 1,7,3,5,7,9,11 stroke:#77f,stroke-width:1px;Info
O pool de HSMs num domínio de replicação por definição está sempre sincronizado. Num modelamento da teoria CAP (Consistency, Availability, Partition Tolerance) que estabelece que um sistema distribuído pode ter até duas, mas nunca estas três características ao mesmo tempo, a replicação do HSM se caracteriza por ser CP (Consistency and Partition Tolerance). Para o mundo exterior o único sinal que o pool pode estar num estado inconsistente é o retorno de ocupado (busy) para a aplicação, mas mesmo neste caso a consistência é preservada, pois todos os nós estarão no mesmo estado de ocupado. Não existem estados intermediários entre transações, ou o pool efetiva a transação como um todo ou não efetiva de forma alguma.
Caso um nó sofra alguma falha e não consiga comunicar com o coordenador enquanto está no meio de uma transação, logo que o nó estiver recuperado ele precisa saber a decisão do coordenador da transação que ficou pendente. O mecanismo de replicação usa otimização do tipo Presumed Abort; quando o coordenador decide abortar uma transação ele envia mensagem aos nós participantes e não aguarda pela resposta, apenas elimina registro daquela transação em sua base. Em caso de alguma falha no nó participante, durante o processo de recuperação (recovery) se o nó participante não encontra um registro de pendência daquela transação consultando o coordenador, assume-se que a mesma foi abortada e o processo de recovery do nó completa abortando a transação.
Do ponto de vista da aplicação chamadora os HSMs participantes do pool de Replicação continuam sendo entidades distintas, cada um acessado por seu endereço IP. As funcionalidades de balanceamento de carga e cache de sessão por exemplo não são afetadas pelo mecanismo de replicação. Para o usuário ou aplicação chamadora o que importa é que nos HSMs operando em replicação, uma vez realizada uma operação num dos HSMs ela será replicada imediatamente para todos os outros HSMs no Domínio, e ao abrir nova sessão em um HSM diferente o resultado da transação estará lá, como se o usuário estivesse abrindo esta nova sessão no HSM original. Por exemplo, se um usuário cria uma chave num HSM A, fecha a sessão e num outro momento abre nova sessão num HSM B, a chave criada na primeira sessão estará disponível nesta nova sessão, ou seja, existirá tanto na base do HSM A quanto na base do HSM B.
Todas as transações de replicação no HSM recebem um identificador único (um GUID, Globally Unique Identifier), e os logs em todos os HSM registram a mesma transação com o mesmo GUID. A cada vez que uma transação replicada é finalizada com sucesso é gerado um valor chamado Ponto de Sincronização (Sync Point), que leva em conta tanto o GUID da transação atual quanto da última transação, aproveitando um efeito positivo de avalanche. Os HSMs do pool estarão sincronizados em um dado instante se todos os nós estiverem com o mesmo valor de Sync Point.
Caso algum dos nós tenha um Sync Point diferente, não apenas este nó não conseguirá replicar com os demais, com os nós que têm este nó na lista de nós também não conseguirão replicar, ou seja, existe uma situação de conflito ou inconsistência de base e o pool fica bloqueado até que os nós voltem a estar sincronizados. Na grande maiorias das vezes o sistema de recuperação (Recovery) da replicação irá resolver a inconsistência automaticamente. Nos casos onde um nó sai do pool de forma definitiva, por exemplo uma falha de hardware, o operador pode fazer a resolução de conflito remotamente, usando a console remota do HSM.
---
title: Esquema geral de replicação do HSM
---
%%{ init: { 'flowchart': { 'curve': 'basis' } } }%%
flowchart TD
classDef red_s stroke:#f00
hsm1[HSM 1]
hsm2[HSM 2]
hsm3[HSM 3]
hsmn[HSM n]
db[(repl)]:::red_s
u1((1))
u2((2))
u3((3))
hsm1 -.- db
hsm2 -.- db
hsm3 -.- db
hsmn -.- db
u1 --> hsm1
u1 --> hsm2
u1 --> hsm3
u2 --> hsm2
u2 --> hsmn
u3 --> hsmn
linkStyle 0,1,2,3,4,5,6,7,8 stroke-width:1px;
style db stroke:#f66,stroke-width:1px,stroke-dasharray: 2 2Pré-requisitos
Para iniciar a criação de um Domínio de Replicação e manter a replicação operando os HSM deverão estar ativados e configurados com a mesma Server Master Key (SVMK) e configurados no mesmo modo de operação, além de possuírem conectividade IP.
Configuração Automática
O HSM utiliza o protocolo de localização de serviço SLP (Service Location Protocol, RFCs 2608 e 3224), baseado em IP multicast, para encontrar automaticamente os nodes de replicação na vizinhança de rede. Todos os nós, uma vez configurados para um Domínio de Replicação irão anunciar este serviço, e qualquer nó que fizer uma varredura na rede poderá detectar imediatamente quais outros nodes estão em quais Domínios. Esta funcionalidade permite uma configuração bastante simples e rápida do pool de Replicação, uma vez que basta iniciar um Domínio em um dos nós e a partir daí nos demais nós só é necessário fazer a varredura e solicitar a inclusão no Domínio, sem necessidade da cadastramentos manuais cruzados, listando todos os IP em todos os nós. Nos ambientes onde há restrição ao uso de IP multicast a configuração pode ser feita manualmente (vide abaixo). A operação da replicação precisa apenas de conectividade IP entre os HSMs para funcionar, não depende de IP multicast. O protocolo SLP é oferecido como um facilitador para a etapa de configuração.
No primeiro HSM deve ser feita a criação do Domínio. O sistema sempre fará uma varredura na vizinhança procurando por nós anunciando o serviço de Replicação; neste primeiro HSM nenhum Domínio deve ser encontrado, então é necessário a criação de um novo, simplesmente informando um nome de identificação para este Domínio.
Nos HSMs seguintes, após o sistema fazer a varredura na vizinhança e encontrar o Domínio de Replicação já criado basta juntar o HSM a este Domínio, escolhendo a opção de Join.
Info
Para que um HSM possa se juntar a um Domínio, sua base de dados será sobrescrita com a base utilizada pelo pool no momento do Join. Portanto é importante escolher qual HSM do pool será usado para criar o Domínio, já que este HSM terá sua base de dados preservada e em seguida usada para sobrescrever as bases dos demais HSMs.
Para retirar um nó do pool pode ser realizado o processo inverso, primeiro o operador exclui o nó de um Domínio, e em seguida o operador deve remover o nó da lista dos demais HSMs restantes. Como a replicação tem característica não comutativa, é necessário quebrar a relação de nós no pool nas duas pontas, retirando o nó A do Domínio e também retirando o nó A da lista dos demais nós. Esta atividades são realizadas localmente na Console Local do HSM. Nos casos onde o nó a ser retirado tem algum problema (como falha de comunicação ou no hardware) é possível também utilizar a Console Remota para notificar o pool, via qualquer um dos nós, que um dado nó deve ser retirado do pool, assim o nó que recebe a notificação cuida de comunicar a todos os demais nós que estão em sua lista para que atualizem a lista de nós e assim não mais tentar replicar com o nó informado. Veja abaixo sobre Termination Protocol.
Atenção
Um nó pode ser adicionado ou removido do Domínio de Replicação sem necessidade de downtime do pool.
Configuração Manual
Nos cenários onde não for possível realizar a varredura na vizinhança com IP multicast ou não forem localizados os nós do pool, os endereços IPs de cada HSM do pool devem ser cadastrados manualmente, assim como a operação de sincronização online da base de dados (Database Live Sync) também deve ser feita manualmente pelo operador.
Quando um nó é adicionado a um Domínio e realiza com sucesso a Sincronização Online de Base (Database Live Sync) é disparado um sinal para todos os demais nós no pool chamado Sensibilization. O papel deste sinal é incluir nos nós que já fazem parte do Domínio o endereço do novo nó que está sendo adicionado, assim o operador não vai precisar voltar em cada HSM após o último nó ser configurado para atualizar a lista de nós em cada HSM.
Para configurar um Domínio manualmente defina o 1o. HSM, que terá a base de dados preservada e será copiada para os outros HSM.
No segundo HSM são necessários dois passos: adicionar o IP do 1o. HSM e em seguida executar uma operação de sincronização online de base (Database Live Sync). Após isso o 1o. HSM será sensibilizado e terá o IP do 2o. HSM em sua lista de replicação, assim os HSM terão as bases sincronizadas e prontos para replicar.
No terceiro HSM são necessários os mesmos passos: adicionar o IP do 1o. e do 2o. HSM e em seguida executar a sincronização online de base (Database Live Sync).
No quarto HSM e nos seguintes o procedimento é o mesmo: adicionar os IPs de todos os HSM já existentes no Domínio e executar a sincronização de base.
Na configuração manual todos os IPs de HSMs já existentes devem ser adicionados no novo HSM antes da sincronização de base, ou a lista de nós será incompleta e o pool ficará desbalanceado, com alguns nós não tendo conhecimento de todos os demais nós.
É importante notar que a cada novo HSM entrante no Domínio, só há necessidade de configuração neste novo HSM, nenhum dos já existentes precisa de qualquer intervenção do operador.
Na configuração manual o nome do Domínio de Replicação é opcional; se não for configurado um, a console do HSM indicará na barra de status (parte inferior da tela), mostrando que o HSM tem uma lista de nós para replicar, mas não há um nome definido para este pool.
A remoção de nós na configuração manual é feita da mesma forma que na configuração automática (vide acima).
Aplicações Cliente
Para as aplicações que utilizam as APIs do HSM não há necessidade de mudança por conta de replicação. Em certos cenários pode ser interessante para a aplicação implementar algum tratamento específico para os códigos de retorno de replicação; este tratamento pode ser por exemplo reenviar a solicitação ao HSM.
Pela natureza distribuída da replicação, durante a comunicação protocolar entre os HSMs, o pool poderá ser colocado em estado bloqueado (ou busy) para novas operações e solicitações de clientes, o que deve ocorrer sempre em intervalos muitos curtos, liberando o pool novamente tão logo termine o protocolo de replicação. Este mecanismo garante que todos o HSMs a qualquer instantes terão sempre a mesma visão da base de dados, mantendo integridade e coerência para a aplicação chamadora, não importando por qual dos nós ela acesse o pool.
As operações de Read, como por exemplo criptografia e decriptografia de dados, assinatura digital e verificação nunca são replicadas, portanto não são afetadas por um condição de pool bloqueado. Como o cenário mais comum de uso de HSM é realizar muito mais operações de Read que de Write (geração de chave por exemplo), o esperado que o usuário normal do HSM experimente poucas situações de pool bloqueado, e muito raramente alguma onde haja necessidade de resolução manual.
Protocolo de Resolução
Uma característica intrínseca a um sistema distribuído com protocolo baseado em consenso (caso do Two Phase Commit) é que o sistema assume que um nó nunca sai definitivamente do pool, ou seja, qualquer medida que possa ser tomada autônoma e internamente sempre assume que o nós voltam ao estado operacional. Esta é uma premissa que permite modelar o sistema dentro de certos limites, mas não pode ser levada ao caso real. Portanto em certas situações de falha, o sistema de replicação do HSM deve oferecer mecanismos para resolver a falha e não apenas manter a consistência da base de dados do pool, mas prover funções que permita ao operador restabelecer o nível operacional do pool. Umas destas situações de falha é exatamente a saída abrupta de um nó, por qualquer motivo. Como todos os nós do pool mantém uma lista de nós com quem vão replicar suas transações, a saída de nó, sem a devida atualização das listas dos nós remanescentes cria uma situação de bloqueio no pool, qualquer nova transação vai retornar erro por conta de não receber a resposta do nó sainte.
Para resolver a situação, e liberar os nós remanescentes do nó sainte, que deixou de ser operacional e acessível, o operador deve intervir, notificando o pool que aquele nó está com problema (down) e deve ser excluído da lista de todos os nós. O protocolo de resolução ou Termination Protocol - TP permite que esta notificação seja difundida no pool usando os próprios canais de replicação, sem necessidade de operador ir em cada Console de HSM e atualizar a lista. A partir de uma sessão de Console Remota, em qualquer um dos nós remanescentes, o operador avisa este nó sobre o nó com problema (informando o endereço IP) e a partir daí este nó que recebeu a notificação confirma que o IP informado não pode ser acessado, se encarrega de transmitir a mesma notificação aos nós remanescentes. Cada nó ao receber a notificação atualiza sua lista removendo o IP informado e informa o resultado ao nó que avisou. A partir daí o pool está reconstruído, agora sem o nó problemático, se sem necessidade de downtime para reconfiguração de Domínio de Replicação.