Arquitectura
Esta sección describe la arquitectura del sistema, QSen, que permite el ruteo de órdenes a SENEBI.
El objetivo del sistema es disponer de un medio que permita al agente operar en SENEBI las ordenes cursadas en la plataforma de Quantex. Esto sin la necesidad de que Quantex tenga acceso a los certificados dados de alta en BYMA, ni al servidor con la IP habilitada para operar.
De esta forma el Agente puede evitar que la plataforma curse órdenes, en el instante que lo desee.
Quantex pone a disposición de los Agentes todo el código fuente del software que instala en el servidor, escrito en lenguaje de programación Go. Junto con el script de bash utilizado para compilar dicho software, realizar la instalación del mismo y configurar la seguridad del servidor.
Si bien Quantex le brinda al Agente acceso al código, este sólo puede utilizarlo con el fin auditarlo. Pero este software es propiedad de Quantex y el Agente o auditor de ninguna manera puede utilizarlo con otro fin.
Quantex sólo tiene acceso a la interfaz expuesta por los servicios (API REST), por lo tanto es claro y evidente qué puede y qué no puede hacer Quantex mediante la utilización del sistema.
El código fuente de todo el proyecto de QSen se encuentra disponible en Gitlab:
https://gitlab.com/quantex-customers/qsen
Para acceder utilice estas credenciales:
usuario: quantex-guest
clave: Tex_Wdrt$t13
Dado que el acceso al Webservice de SENEBI es común y no está aislado por usuarios, es necesario un mecanismo para asegurar que Quantex no va a interferir con otros usuarios que pudiera tener el agente, y también asegurar que sólo puede consultar información de órdenes y operaciones cursadas por la plataforma.
Para asegurar que Quantex no tiene visibilidad de ninguna otra operatoria del agente y no interfiere con otros usos del agente, el software de Qsen tiene restringida su operatoria a un rango de ids establecido al momento de realizar la instalación.
El rango por defecto está entre 9.999.000.000.000.000.000 y 9.999.999.999.999.999.999.
Este rango puede ser establecido con un valor diferente al momento de la instalación si el agente así lo requiere.
Los rangos en la figura anterior no están a escala. Si bien QSen se reserva, por defecto, un rango de 1000 millones de ids,
teniendo en cuenta que el rango total tiene 19 dígitos, el rango utilizado por QSen representa tan solo
el 0.01% del número total de ids.
Por lo tanto el agente tiene prácticamente todo el rango disponible para su propio uso si así lo necesitara.
El proceso principal denominado nodo qsen, es el encargado de exponer la interfaz (API REST) que permite rutear órdenes a SENEBI. Adicionalmente hay un proceso auxiliar denominado nodo kan (keep alive node) del cual se ejecutan 3 instancias que se encargan de tareas de supervisión y mantenimiento del sistema.
El sistema solo expone 6 puertos (todos los otros puertos permanecen cerrados):
- un puerto para acceso remoto al servidor (Sólo por parte del Agente)
- un puerto para comunicarse con SENEBI (Para conectarse a BYMA)
- un puerto para el nodo qsen (Para acceso a la API de Quantex)
- y otros 3 puertos, uno para cada nodo kan (Para acceso a la API de Quantex)
| Servicio | Puerto |
|---|---|
| SSH | 52022 |
| WebService de SENEBI | 443 |
| qsen | 8443 |
| kan 0 | 8444 |
| kan 1 | 8445 |
| kan 2 | 8446 |
En un futuro pueden reducirse a solo 4 puertos, exponiendo el puerto de solo uno de los nodos kan.
Si bien la arquitectura pretende ser compatible con diferentes plataformas unix o windows, lo recomendado y actualmente probado es bajo plataformas linux.
Dado que Quantex no tendrá en ningún momento acceso al servidor donde se va a instalar el servicio ni los certificados para operar en SENEBI, será el Agente, bajo nuestra supervisión, quién ejecute el script de instalación.
Los endpoint están divididos en 2 grupos: Externos e Internos
Externos: se pueden acceder desde afuera del servidor y están protegidos con autenticación mutua. Como mencionamos anteriormente, en este caso, el servidor se asegura quién es el cliente que se conecta y el cliente se asegura cuál es el servidor al que se está conectando.
| Método | Endpoint | Descripción |
|---|---|---|
| POST | /qsen/v1/getBilateralOrders | Retorna una lista de las órdenes enviadas a SENEBI |
| POST | /qsen/v1/getBilateralOperations | Retorna una lista de las operaciones realizadas en SENEBI |
| POST | /qsen/v1/sendOrder | Envía una orden a SENEBI |
| POST | /qsen/v1/decrypt | Endpoint auxiliar para verificar la encriptación de los certificados |
| POST | /qsen/v1/ping/senebi | Utilizado para verificar que el WebService de SENEBI responda correctamente |
| GET | /qsen/v1/metrics/golang | Expone las métricas del proceso qsen |
| POST | /qsen/v1/cert/info | Devuelve la fecha de expiración del certificado |
| GET | /qsen/v1/status | Devuelve metricas sobre los request realizados a senebi |
| GET | /qsen/v1/config | Devuelve el contenido del archivo de configuración |
| Método | Endpoint | Descripción |
|---|---|---|
| GET | /kan/v1/status | Devuelve información de estado del sistema |
| GET | /kan/v1/version | Devuelve la versión del software |
| GET | /kan/v1/restart_qsen | Reinicia el nodo qsen |
| GET | /kan/v1/restart_kan | Reinicia el nodo kan |
| GET | /kan/v1/logs | Devuelve uno o todos los archivos de logs |
| GET | /kan/v1/logs/tail | Devuelve la última porción de un archivo de log |
| GET | /kan/v1/logs/truncate | Trunca los archivos de logs. Eliminado el contenido más viejo. |
| GET | /kan/v1/metrics/golang | Devuelve las métricas del proceso kan |
| GET | /kan/v1/metrics/system | Devuelve las métricas del sistema |
| GET | /kan/v1/cmd/top | Devuelve la salida del comando ’top -b -n 1' |
| GET | /kan/v1/cmd/ls | Devuelve la salida del comando ’ls -Rlath' |
Internos: sólo pueden accederse desde el mismo servidor (localhost) y no están expuestos externamente.
| Método | Endpoint | Descripción |
|---|---|---|
| GET | /qsen/v1/ping | Utilizado para verificar que el proceso responda |
| Método | Endpoint | Descripción |
|---|---|---|
| GET | /kan/v1/ping | Utilizado para verificar que el proceso responda |
El sistema expone métricas del proceso qsen y cada uno de los procesos kan y además expone métricas del sistema utilizando Node Exporter.
Como no es posible acceder directamente al endpoint de node exporter, se hace través de alguno de los nodos kan que actúan de proxy añadiendo la capa de seguridad previamente descrita (autenticación mutua).
El nodo qsen se inicia previo a que abra la rueda de negociación de BYMA y se detiene posteriormente; y únicamente los días de semana permaneciendo apagado los fines de semana. De esta manera el servicio está activo solo cuando es necesario (la hora de inicio y fin de dicho servicio se configura desde el archivo conf.toml). Los nodos kan se reinician luego de la medianoche.