Replicación
Información
La replicación está disponible en dispositivos con firmware a partir de la versión 3.
El HSM dispone de un sistema de replicación automática de operaciones entre HSMs, funcionando como una base de datos distribuida, donde todos los HSMs que participan en la replicación mantienen una visión unificada de la base de datos, incluyendo claves y particiones de usuarios.
masterEl mecanismo funciona de forma totalmente distribuida y descentralizada en modo múltiple, es decir, no existe una diferenciación fija de funciones o atributos entre los HSM. Toda la replicación tiene lugar de forma transparente para la aplicación; una vez configurados los HSM, no es necesaria ninguna acción por parte del desarrollador o del operadordel HSM. Tampoco hay archivos de configuración ni controles fuera del HSM, ya que toda la información para operar la replicación está en el propio HSM.
Los HSM que participan en el esquema de replicación se denominan Nodos y el conjunto de HSM que se comunican para mantener la base de datos replicada se denomina Dominio (o pool) de replicación.
Para participar en un dominio de replicación, los HSM deben utilizar la misma clave maestra de servidor (SVMK) y estar en el mismo modo de funcionamiento, así como tener conectividad punto a punto, es decir, todos los HSM deben poder comunicarse con todos los demás HSM. El puerto del servicio de replicación es el mismo que el del servicio general de HSM (TCP 4433). Es el mismo requisito SVMK que permite la comunicación segura entre los HSM durante la replicación. Toda la comunicación entre los HSM en el protocolo de replicación está cifrada.
Las operaciones de creación, destrucción y actualización de claves y objetos en la base del HSM se replican, al igual que las operaciones de partición de usuarios. Las operaciones de lectura y las operaciones con claves y objetos temporales no se replican, ya que sólo existen durante la sesión de comunicación entre un cliente y el HSM; una vez finalizada la sesión, los objetos temporales se eliminan automáticamente.
El mecanismo de replicación se activa siempre desde el HSM donde se solicita la operación, ya sea por una sesión de cliente o por el operador. El HSM que inicia el proceso se denomina Coordinador y los demás, Participantes. Como el sistema está descentralizado, estos papeles de Coordinador y Participante se asignan a cada nueva operación y pueden asignarse a cualquier HSM del pool para una operación determinada.
El protocolo de comunicación utilizado es Two Phase Commit (2PC). Este protocolo de transacciones distribuidas funciona en dos fases, en la primera el coordinador de transacciones pide a los participantes que voten una transacción propuesta, cada participante recibe y analiza la transacción, si es posible llevarla a cabo el participante responde al coordinador que está listo para comprometerse. Cuando el coordinador recibe el voto de todos los participantes, decide si la transacción debe ser implementada o cancelada, basándose en los votos recibidos; si todos los participantes votaron a favor de implementar la transacción, el coordinador envía un mensaje de commit a todos los nodos, y todos implementan el cambio en sus bases de datos locales, si alguno de los participantes votó negativamente, el coordinador envía un mensaje de rollback a los participantes y la transacción es cancelada, lo que significa que todos los nodos permanecen con la base de datos en el estado original, previo a la solicitud de voto del coordinador.
---
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;Información
El conjunto de HSM de un dominio de replicación está, por definición, siempre sincronizado. Siguiendo el modelo de la teoría CAP (Consistencia, Disponibilidad, Tolerancia a la Partición), que establece que un sistema distribuido puede tener hasta dos, pero nunca las tres características al mismo tiempo, la replicación HSM se caracteriza por ser CP (Consistencia y Tolerancia a la Partición). Para el mundo exterior, la única señal de que el pool puede estar en un estado inconsistente es la devolución de ocupado a la aplicación, pero incluso en este caso se preserva la consistencia, ya que todos los nodos estarán en el mismo estado ocupado. No hay estados intermedios entre transacciones, o el pool realiza la transacción en su totalidad o no la realiza en absoluto.
Si un nodo sufre un fallo y no puede comunicarse con el coordinador mientras está en medio de una transacción, en cuanto se recupere necesita conocer la decisión del coordinador sobre la transacción pendiente. El mecanismo de replicación utiliza la optimización Presumed Abort; cuando el coordinador decide abortar una transacción, envía un mensaje a los nodos participantes y no espera respuesta, simplemente borra el registro de esa transacción de su base de datos. En caso de fallo en el nodo participante, durante el proceso de recuperación, si el nodo participante no encuentra un registro de la transacción pendiente consultando al coordinador, se asume que la transacción fue abortada y el proceso de recuperación del nodo se completa abortando la transacción.
Desde el punto de vista de la aplicación de llamada, los HSM que participan en el grupo de replicación siguen siendo entidades distintas, a cada una de las cuales se accede mediante su propia dirección IP. Las funcionalidades de equilibrio de carga y caché de sesión, por ejemplo, no se ven afectadas por el mecanismo de replicación. Lo que importa al usuario o a la aplicación llamante es que en los HSM que funcionan bajo replicación, una vez realizada una operación en uno de los HSM, ésta se replicará inmediatamente a todos los demás HSM del Dominio, y al abrir una nueva sesión en un HSM diferente el resultado de la transacción estará ahí, como si el usuario estuviera abriendo esta nueva sesión en el HSM original. Por ejemplo, si un usuario crea una clave en el HSM A, cierra la sesión y, a continuación, abre una nueva sesión en el HSM B, la clave creada en la primera sesión estará disponible en esta nueva sesión, es decir, existirá tanto en el HSM A como en el HSM B.
Todas las transacciones replicadas en el HSM reciben un identificador único (un GUID, Globally Unique Identifier), y los logs de todos los HSM registran la misma transacción con el mismo GUID. Cada vez que una transacción replicada se completa con éxito, se genera un valor llamado Punto de Sincronización, que tiene en cuenta tanto el GUID de la transacción actual como el de la última transacción, aprovechando un efecto de avalancha positiva. Los HSM del pool están sincronizados en un momento dado si todos los nodos tienen el mismo valor de Sync Point.
Si alguno de los nodos tiene un punto de sincronización diferente, no sólo este nodo no podrá replicarse con los demás, sino que los nodos que tengan este nodo en la lista de nodos tampoco podrán replicarse, es decir, se produce una situación de conflicto o inconsistencia de base y el pool queda bloqueado hasta que los nodos se vuelvan a sincronizar. La mayoría de las veces, el sistema de recuperación de la replicación resolverá la incoherencia automáticamente. En los casos en los que un nodo abandona el pool de forma permanente, por ejemplo por un fallo de hardware, el operador puede resolver el conflicto de forma remota utilizando la consola remota del 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 2Requisitos previos
Para empezar a crear un dominio de replicación y mantener la replicación en funcionamiento, los HSM deben estar activados y configurados con la misma clave maestra de servidor (SVMK) y configurados en el mismo modo de funcionamiento, además de disponer de conectividad IP.
Configuración automática
El HSM utiliza el Protocolo de Localización de Servicios (SLP, RFCs 2608 y 3224), basado en multidifusión IP, para encontrar automáticamente los nodos de replicación en la vecindad de la red. Todos los nodos, una vez configurados para un Dominio de Replicación, anunciarán este servicio, y cualquier nodo que escanee la red podrá detectar inmediatamente qué otros nodos están en qué Dominios. Esta funcionalidad permite una configuración muy sencilla y rápida del pool de Replicación, ya que basta con iniciar un Dominio en uno de los nodos y luego en el resto de nodos basta con escanear y solicitar la inclusión en el Dominio, sin necesidad de realizar un registro cruzado manual, listando todas las IPs en todos los nodos. En entornos donde el uso de multidifusión IP está restringido, la configuración puede hacerse manualmente (ver más abajo). La operación de replicación sólo necesita conectividad IP entre los HSM para funcionar, no depende de la multidifusión IP. El protocolo SLP se ofrece como facilitador de la etapa de configuración.
En el primer HSM se debe crear el Dominio. El sistema siempre escaneará el vecindario en busca de nodos que anuncien el servicio de Replicación; en este primer HSM no debería encontrarse ningún Dominio, por lo que es necesario crear uno nuevo simplemente introduciendo un nombre identificativo para este Dominio.
En los siguientes HSM, una vez que el sistema ha escaneado el barrio y ha encontrado el Dominio de Replicación que ya se ha creado, lo único que tiene que hacer es unir el HSM a este Dominio seleccionando la opción Unir.
Información
Para que un HSM se una a un dominio, su base de datos se sobrescribirá con la base de datos utilizada por el pool en el momento de la unión. Por lo tanto, es importante elegir qué HSM del pool se utilizará para crear el dominio, ya que se conservará la base de datos de este HSM y, a continuación, se utilizará para sobrescribir las bases de datos de los demás HSM.
Para eliminar un nodo del pool, se puede realizar el proceso inverso: primero el operador elimina el nodo de un Dominio, y después debe eliminar el nodo de la lista de HSM restantes. Como la replicación no es conmutativa, es necesario romper la relación de los nodos del pool en ambos extremos, eliminando el nodo A del Dominio y eliminando también el nodo A de la lista de nodos restantes. Estas actividades se realizan localmente en la consola local de HSM. En los casos en los que el nodo a eliminar tenga algún problema (como un fallo de comunicación o de hardware) también es posible utilizar la Consola Remota para notificar al pool, a través de cualquiera de los nodos, que un determinado nodo debe ser eliminado del pool, de forma que el nodo que recibe la notificación se encarga de comunicarlo a todos los demás nodos de su lista para que actualicen la lista de nodos y así dejen de intentar replicar con el nodo informado. Véase más adelante el Protocolo de Terminación.
Atención
Un nodo puede ser añadido o eliminado del Dominio de Replicación sin tener que parar el pool.
Configuración manual
En los casos en los que no sea posible escanear el vecindario con multidifusión IP o no se puedan localizar los nodos del pool, las direcciones IP de cada HSM del pool deberán introducirse manualmente, y la operación de sincronización en línea de la base de datos (Database Live Sync) también deberá realizarla manualmente el operador.
Cuando un nodo se añade a un dominio y realiza correctamente la sincronización en vivo de la base de datos, se envía una señal a todos los demás nodos del grupo denominada "Sensibilización". La función de esta señal es incluir la dirección del nuevo nodo que se añade en los nodos que ya forman parte del Dominio, de forma que el operador no tenga que volver a cada HSM después de que se haya configurado el último nodo para actualizar la lista de nodos en cada HSM.
Para configurar un dominio manualmente, defina el 1er HSM, que tendrá la base de datos conservada y se copiará a los demás HSM.
El segundo HSM debe realizar dos pasos: añadir la IP del 1er HSM y, a continuación, realizar una operación de sincronización de bases de datos online (Database Live Sync). Tras esto, el 1er HSM estará sensibilizado y tendrá la IP del 2º HSM en su lista de replicación, por lo que los HSM tendrán sus bases sincronizadas y listas para replicar.
El tercer HSM requiere los mismos pasos: añadir la IP del primer y segundo HSM y, a continuación, ejecutar la sincronización en línea de la base de datos (Database Live Sync).
Para el cuarto HSM y los siguientes, el procedimiento es el mismo: añadir las IP de todos los HSM que ya están en el dominio y ejecutar la sincronización de base.
En la configuración manual, todas las IP de los HSM existentes deben añadirse al nuevo HSM antes de la sincronización de la base; de lo contrario, la lista de nodos estará incompleta y el pool se desequilibrará, ya que algunos nodos no tendrán conocimiento de todos los demás.
Es importante tener en cuenta que con cada nuevo HSM que entra en el dominio, sólo es necesario configurar este nuevo HSM; ninguno de los existentes requiere la intervención del operador.
En la configuración manual, el nombre del dominio de replicación es opcional; si no se ha configurado ninguno, el campo HSM indicará en la barra de estado (parte inferior de la pantalla), mostrando que el HSM tiene una lista de nodos para replicar, pero no hay ningún nombre definido para este pool.
La eliminación de nodos en la configuración manual se realiza del mismo modo que en la configuración automática (véase más arriba).
Aplicaciones cliente
Para las aplicaciones que utilizan las API del HSM, no es necesario cambiar esto debido a la replicación. En determinados escenarios puede ser interesante que la aplicación implemente algún tratamiento específico para los códigos de retorno de la replicación; esto podría ser, por ejemplo, enviar la solicitud de vuelta al HSM.
Debido a la naturaleza distribuida de la replicación, durante la comunicación del protocolo entre los HSMs, el pool puede quedar en estado bloqueado (u ocupado) para nuevas operaciones y peticiones de clientes, lo que debería ocurrir siempre a intervalos muy cortos, liberándose de nuevo el pool en cuanto finalice el protocolo de replicación. Este mecanismo garantiza que todos los HSM tengan siempre la misma vista de la base de datos, manteniendo la integridad y coherencia para la aplicación que llama, independientemente del nodo desde el que acceda al pool.
Las operaciones de lectura, como el cifrado y descifrado de datos, la firma digital y la verificación, nunca se replican, por lo que no se ven afectadas por una situación de pool bloqueado. Dado que el escenario de uso más común del HSM es realizar muchas más operaciones de lectura que de escritura (generación de claves, por ejemplo), se espera que el usuario normal del HSM experimente pocas situaciones de pool bloqueado, y muy raramente alguna en la que sea necesaria la resolución manual.
Protocolo de resolución
Una característica intrínseca de un sistema distribuido con un protocolo basado en el consenso (el caso de Two Phase Commit) es que el sistema asume que un nodo nunca abandona definitivamente el pool, es decir, cualquier acción que se pueda realizar de forma autónoma e interna siempre asume que los nodos vuelven a un estado operativo. Se trata de una premisa que permite modelizar el sistema dentro de ciertos límites, pero que no puede aplicarse al caso real. Por lo tanto, en determinadas situaciones de fallo, el sistema de replicación HSM debe ofrecer mecanismos para resolver el fallo y no sólo mantener la consistencia de la base de datos del pool, sino proporcionar funciones que permitan al operador restablecer el nivel operativo del pool. Una de estas situaciones de fallo es la salida abrupta de un nodo, por el motivo que sea. Como todos los nodos del pool mantienen una lista de nodos con los que replicarán sus transacciones, la salida de un nodo sin actualizar adecuadamente las listas de los nodos restantes crea una situación de bloqueo en el pool, ya que cualquier nueva transacción devolverá un error por no haber recibido respuesta del nodo saliente.
Para resolver la situación y liberar los nodos restantes del nodo saliente, que ya no está operativo ni accesible, el operador debe intervenir y notificar al pool que el nodo está caído y debe ser eliminado de la lista de todos los nodos. El Protocolo de Terminación (TP) permite difundir esta notificación al pool utilizando los propios canales de replicación, sin necesidad de que el operador tenga que ir a cada Consola HSM y actualizar la lista. Desde una sesión de Consola Remota, en cualquiera de los nodos restantes, el operador notifica a este nodo sobre el nodo con el problema (informándole de la dirección IP) y a partir de ese momento, el nodo que recibió la notificación confirma que no se puede acceder a la IP informada, y se encarga de transmitir la misma notificación a los nodos restantes. Cuando cada nodo recibe la notificación, actualiza su lista eliminando la IP informada e informa del resultado al nodo que le avisó. A partir de ese momento, el pool se reconstruye, ahora sin el nodo problemático, y sin necesidad de tiempo de inactividad para reconfigurar el Dominio de Replicación.