Sesiones
A continuación se detallan los ajustes para controlar el equilibrio de carga y el almacenamiento en caché de sesión.
Variable | Descripción rápida |
---|---|
HSM_DISABLE_SESSION_CACHE |
Desactiva (1) la caché de sesión. |
HSM_LOAD_BALANCE_LIST |
Ruta del archivo con la lista de HSM para equilibrar. |
HSM_LB_FILE_REFRESH_INTERVAL |
Intervalo de actualización (en segundos) del archivo de equilibrado. |
HSM_BALANCE_SUSPEND_TIME |
Tiempo (en segundos) de suspensión automática de un HSM que no responde de la línea de equilibrado. |
HSM_PIX_HTTP_CONN_REFRESH_INTERVAL |
Pix Intervalo de actualización (en segundos) para cargar objetos HSM en operaciones de solicitud (POST/GET/DELETE). |
Caché de sesión
Variable de entorno que debe definirse: HSM_DISABLE_SESSION_CACHE
Valor | Caché de sesión |
---|---|
No definido | habilitado |
0 | habilitado |
1 | desactivado |
Sólo desactive la caché de sesión si está seguro de que la aplicación se beneficiará de algún modo de esta configuración.
Para más detalles, consulte el tema Caché de sesión.
Junto con el balanceo, un sistema de caché de sesión trabaja para optimizar el uso del ancho de banda de la red y la asignación/desasignación de recursos en el HSM y en el servidor de aplicaciones. Cuando la aplicación solicita la finalización de la sesión al HSM, ésta se termina lógicamente (para la aplicación, la sesión se ha cerrado con éxito); la biblioteca del HSM (cargada en el espacio de direcciones del proceso de aplicación) mantiene la sesión física con el HSM durante un determinado periodo de tiempo; si se solicita una nueva sesión, la biblioteca reutiliza esa sesión física (reautenticando al usuario localmente). Al reutilizar una sesión ya establecida, se evita tener que volver a negociar la sesión física, especialmente si la aplicación utiliza sesiones cifradas (TLS). El tipo de la nueva sesión (abierta o cifrada) debe ser el mismo que el de la sesión física existente. Si la sesión física en la caché no se reutiliza dentro del periodo de tiempo de espera, se termina físicamente.
La caché de sesión tiene las siguientes características:
- Intraproceso: la caché se realiza por proceso. Esto significa que 2 aplicaciones en la misma máquina tendrán cada una una caché, sin compartir sesiones entre los procesos;
- Centralizada: implementada en la biblioteca HSM. De este modo, la caché se habilita en un punto central y todas las demás bibliotecas que dependen de ella heredan la funcionalidad;
- Transparente: para activar la caché de sesión basta con activar una variable de entorno. No es necesario cambiar la aplicación.
Observaciones:
- Las sesiones con autenticación de segundo factor no se almacenan en caché. Un ejemplo es el uso de OTP;
- La caché de sesión puede ignorarse en una sesión determinada utilizando el indicador CACHE_BYPASS en DOpenSesssion;
- La caché de sesión está activada por defecto;
- Se puede forzar la eliminación de una sesión de la caché utilizando la bandera CLOSE_PHYSICALLY en DCloseSession;
- Puede utilizarse junto con el equilibrio de carga.
- El tiempo de espera antes de que la sesión sea descartada por la biblioteca es de 04 minutos.
Un flujo de caché de sesión puede representarse como en la figura siguiente:
---
title: Fluxo de cache de sessões
---
%%{ init: { 'flowchart': { 'curve': 'basis' }} }%%
sequenceDiagram
autonumber
participant app as Aplicação
participant lib as Biblioteca
participant hsm as HSM
app ->> lib: Início da sessão 1
activate app
lib ->> hsm: Abre sessão
activate lib
activate hsm
loop Sessão 1
%% necessário manter o espaço após o spi: (ou usar um text)
app -->> lib: Requisição
lib -->> app: Resposta
end
app ->> lib: Fim da sessão 1
deactivate app
Note right of lib: A sessão física<br>permanece aberta
app ->> lib: Início da sessão 2
activate app
Note right of lib: A sessão existente<br>é reutilizada
loop Sessão 2
%% necessário manter o espaço após o spi: (ou usar um text)
app -->> lib: Requisição
lib -->> app: Resposta
end
app ->> lib: Fim da sessão 2
deactivate app
deactivate lib
deactivate hsm
Equilibrio de la carga
Variable de entorno que debe definirse: HSM_LOAD_BALANCE_LIST
Valor | Equilibrio de la carga |
---|---|
No definido | desactivado |
nombre del archivo | utilizar la lista de HSM |
Contiene la ruta y el nombre del archivo con la lista de direcciones IP y puertos de los HSM. Cada línea del archivo debe contener la dirección y el puerto (utilice 4433) de un HSM. Se pueden introducir hasta dieciséis direcciones. El archivo debe estar en formato de texto ASCII con el siguiente contenido:
<endereco_ip_1> <porta>
<endereco_ip_2> <porta>
...
<endereco_ip_16> <porta>
Por ejemplo:
10.0.20.1 4433
10.0.20.2 4433
Para utilizar este esquema activo-pasivo, crea cada lista de HSMs en un fichero con el formato indicado anteriormente, y en el valor de la variable de entorno indica todos los ficheros, con la ruta completa, separados según el estándar del sistema operativo donde estés ejecutando la aplicación, ;
para Windows y :
para Unix/Linux.
Dinamo dispone de un mecanismo de balanceo de carga, lo que permite una mayor disponibilidad del entorno y rendimiento para las aplicaciones. Dinamo Es posible tener hasta 16 (dieciséis) unidades en un sistema de balanceo de carga, con el mismo número de sesiones en cada dispositivo. El balanceo de carga es transparente para la aplicación, es decir, una vez habilitado el balanceo de carga en el entorno, la aplicación se beneficia de él sin necesidad de realizar ningún cambio.
El balanceo funciona de forma round-robin, distribuyendo circularmente las conexiones entre los HSM configurados para el balanceo. La unidad de balanceo es la sesión con el HSM, independientemente de la carga o APIs utilizadas en cada sesión y también de la tasa de utilización de recursos en cada HSM. El HSM que establecerá la sesión con la aplicación viene definido por la estructura de balanceo y no por la aplicación. El esquema de balanceo funciona por proceso, es decir, dentro de cada proceso son sus sesiones las que se balancearán; si dos procesos se ejecutan al mismo tiempo, cada uno tendrá una estructura de balanceo separada e independiente.
Si la aplicación utiliza objetos almacenados en el HSM, el objeto debe existir en todos los HSM. Se recomienda preparar inicialmente un HSM con todos los objetos utilizados por la aplicación y generar a partir de él una copia de seguridad, que se restaurará en todos los demás HSM que formen parte del conjunto de equilibrado.
Atención
El balanceo no puede ser utilizado por aplicaciones que crean objetos dentro de la sesión, necesitan persistir estos objetos entre sesiones pero no utilizan el mecanismo de replicación del HSM, porque en este caso la creación del objeto no se replica entre los HSMs y no hay garantía de que la siguiente sesión se dirija al HSM donde se creó el objeto. Para las aplicaciones que crean objetos que deben persistir entre sesiones, y no se utiliza el mecanismo de replicación entre HSMs, es tarea de la aplicación mantener un mecanismo de sincronización entre las bases de los HSMs que participan en el balanceo. Este mecanismo puede basarse, por ejemplo, en la exportación e importación de objetos.
El equilibrio de carga y el almacenamiento en caché de sesión se activan mediante variables de entorno. Si la definición de la variable de entorno es para todo el sistema, todas las aplicaciones se benefician de la estructura de equilibrio y/o almacenamiento en caché (porque los procesos heredan las definiciones de variables de entorno del sistema). También es posible realizar una configuración que defina la variable de entorno sólo para el proceso concreto de una aplicación. Consulte la documentación del sistema operativo para más detalles sobre la creación y el alcance de las variables de entorno.
El equilibrio de carga tiene las siguientes características:
- Intraproceso: el equilibrio de carga se realiza por proceso. Esto significa que 2 aplicaciones en la misma máquina tendrán diferentes conjuntos de equilibrado;
- Centralizado: implementado en la biblioteca HSM. De esta forma, el equilibrado se habilita en un punto central y el resto de bibliotecas dependientes de ella heredan la funcionalidad
- Transparente: para activar el equilibrado basta con activar una variable de entorno. No es necesario modificar el código fuente de la aplicación.
En la siguiente figura se muestra un diagrama estructural del mecanismo de equilibrio de carga:
---
title: Balanceamento de carga
---
%%{ init: { 'flowchart': { 'curve': 'basis' } } }%%
flowchart LR
classDef red_s stroke:#f00
s1.1[Sessão 1]
s2.1[Sessão 2]
sn.1[Sessão n]
lib1((biblioteca<br>fa:fa-list-ol)):::red_s
s1.2[Sessão 1]
s2.2[Sessão 2]
sn.2[Sessão n]
lib2((biblioteca<br>fa:fa-list-ol)):::red_s
hsm1[fa:fa-network-wired HSM 1]
hsm2[fa:fa-network-wired HSM 2]
hsmn[fa:fa-network-wired HSM n]
subgraph Processo 1
s1.1 --> lib1
s2.1 --> lib1
sn.1 --> lib1
end
subgraph Processo 2
s1.2 --> lib2
s2.2 --> lib2
sn.2 --> lib2
end
%%subgraph Pool de HSMs
hsm1:::red_s
hsm2:::red_s
hsmn:::red_s
%%end
lib1 -...-> hsm1
lib1 -...-> hsm2
lib1 -...-> hsmn
lib2 -...-> hsm1
lib2 -...-> hsm2
lib2 -...-> hsmn
Intervalo de actualización
Variable de entorno que debe definirse: HSM_LB_FILE_REFRESH_INTERVAL
Valor | Intervalo de actualización |
---|---|
No definido | sólo al inicializar la biblioteca. |
0 | sólo al inicializar la biblioteca. |
n | recarga (en segundos) de la lista de saldos. |
Las listas cargadas son las definidas en la variable de entorno HSM_LOAD_BALANCE_LIST
.
Si los archivos de la lista de saldos están dañados o no son válidos, la lista de saldos modificada no se actualizará.
Si la lista de saldos modificada es la misma que la lista de saldos actual, la actualización no se llevará a cabo, para evitar una recarga innecesaria de la lista de saldos.
Si se actualiza la lista de saldos, las sesiones en curso se marcarán para su finalización al término de las operaciones y se crearán nuevas sesiones utilizando la nueva lista de saldos.
Tiempo de suspensión
Variable de entorno que debe definirse: HSM_BALANCE_SUSPEND_TIME
Valor | Tiempo de suspensión |
---|---|
No definido | tiempo de suspensión por defecto de 120 segundos. |
n | tiempo de suspensión en segundos. |
Durante el funcionamiento de la biblioteca de equilibrado de carga, puede ocurrir que una o varias de las direcciones de la lista no puedan establecer una sesión con la aplicación. En este caso, la biblioteca eliminará temporalmente la dirección problemática de la lista de equilibrado e intentará una nueva conexión una vez transcurrido este periodo.
Pix Intervalo desde la solicitud
Variable de entorno que debe definirse: HSM_PIX_HTTP_CONN_REFRESH_INTERVAL
Valor | Intervalo de actualización |
---|---|
No definido | Pix actualiza los objetos con cada operación Request. |
0 | Pix actualiza los objetos con cada operación Request. |
n | recarga (en segundos) de la lista de saldos. |
Pix Cada operación Request( peticiones HTTP POST, GET y DELETE) carga los objetos almacenados en el HSM (manejador de clave privada, certificado y cadena de pares) para poder cerrar el túnel TLS.
Pix La ventaja de recargar los objetos después de cada operación Request es que permite volver a cargar el objeto en la siguiente operación si cambia. Por otro lado, esta recarga frecuente provoca un coste de rendimiento innecesario.
Pix La ventaja de definir un intervalo de tiempo para la recarga de objetos HSM en las operaciones Request es una mejora del rendimiento. Esto permite mejorar el rendimiento a costa de no tener que esperar más que el tiempo de recarga definido en la variable de entorno para que se recarguen los nuevos objetos. Dado que el intercambio de claves y certificados suele realizarse con poca frecuencia, es posible establecer un intervalo para que los objetos se recarguen con un impacto reducido.