Saltar al contenido principal
Lerian SPI es la integración de mensajería nativa de Lerian para Pix. Llega al sistema de pagos instantáneos de BACEN (SPI) y al directorio de claves DICT a través de la RSFN. Incluye cuatro binarios en tiempo de ejecución (spi, dict, brcode y core), por lo que su conjunto de variables es amplio. El servicio lee todas las variables al iniciar. Un valor que no se puede leer en su tipo, como yes en un interruptor, detiene el inicio. Cuando systemplane está activo (el valor predeterminado), puede anular un subconjunto en tiempo de ejecución sin reiniciar. El resto de las variables requieren un reinicio para cambiar. Para los parámetros que se comportan igual en todos los servicios de Lerian en Go (postura de despliegue, almacenes de datos, telemetría), consulta Elementos esenciales de configuración de BYOC. En las tablas siguientes, Obligatorio marca una variable que debes configurar, siempre (Sí) o bajo la condición indicada. — significa que no tiene valor predeterminado. Las condiciones usan tres términos:
  • En vivo: el endpoint de BACEN usa https. Un entorno local también acepta un endpoint http.
  • Entorno local: ENV_NAME es development, local o test.
  • Entorno protegido: ENV_NAME es production, prod, staging, stage, pre-prod, preprod, pre-production o preproduction.
La mayoría de las variables orientadas a BACEN llevan un prefijo de superficie: BACEN_SPI_* para el transporte de liquidación de SPI, BACEN_DICT_* para el cliente DICT, BACEN_BRCODE_JOSE_* para la firma JOSE de BR Code, y BACEN_ICOM_* para el canal de long-poll entrante.

Tiempo de ejecución y servidor

Un entorno protegido exige los archivos de certificado y de clave del servidor, o TLS_TERMINATED_UPSTREAM=true.

Autenticación

Lerian SPI autoriza las rutas protegidas, incluida la API de administración de systemplane, a través de Access Manager.

Declaración de permisos

Cada binario puede publicar su declaración de permisos en Access Manager al iniciar. Estas variables son independientes de AUTH_ENABLED. Con IDP_DECLARATION_ENABLED=true, el binario no inicia cuando una de las tres variables obligatorias está vacía, cuando IDP_HOST no es válido o cuando PLUGIN_AUTH_ENABLED no es true. La publicación también necesita la dirección de Access Manager, definida en PLUGIN_AUTH_ADDRESS. Cuando Access Manager rechaza la publicación o no responde, el binario sigue iniciando.

Licencia

Todo binario (spi, dict, brcode y core) necesita una licencia para arrancar. Una licencia cubre los cuatro binarios y es global: el riel no lee lista de organizaciones. Un binario detiene el arranque cuando ninguna de las dos variables está configurada, sea cual sea el valor de ENV_NAME. La verificación de licencia cubre toda ruta, salvo /health, /readyz, /version, /metrics, así que cubre también las rutas de payload y de conjunto de claves del BR Code. Cuando la licencia se rechaza, al arrancar o en una verificación posterior en segundo plano, el binario se detiene. Un pod con LICENSE_KEY necesita HTTPS de salida hacia license.lerian.io.

Callback de BACEN (entrante desde SPI)

Fuera de un entorno local, el riel necesita exactamente un modo de TLS mutuo de callback. En el modo directo, configura SERVER_TLS_CERT_FILE, SERVER_TLS_KEY_FILE y SERVER_TLS_CLIENT_CA_FILE. En el modo proxy, configura TLS_TERMINATED_UPSTREAM=true, los CIDRs de confianza y el secreto de header.

Transporte de liquidación de SPI (BACEN_SPI_*)

Conexión al endpoint de liquidación SPI de BACEN a través de la RSFN, con el canal secundario de mensajería y el endpoint de transferencia de archivos (ARQ).

TLS mutuo con BACEN

Los archivos BACEN_TLS_* respaldan el canal TLS mutuo con BACEN. Los clientes de SPI y DICT los comparten. Con BACEN_TLS_KEY_KIND=kmip, la clave privada del cliente se queda en tu HSM. El binario la abre mediante la conexión KMIP de su propio firmante: define BACEN_SPI_SIGNER_KIND=kmip en spi o BACEN_DICT_SIGNER_KIND=kmip en dict. El inicio se rechaza a menos que los dos UID estén definidos y el UID de la clave privada sea distinto del UID de la clave privada de firma. Si el binario no puede abrir la clave en el HSM, no queda listo. Un BACEN_TLS_CERT_FILE renovado debe contener el certificado de la misma clave del HSM: el binario rechaza un certificado de otra clave y mantiene el certificado cargado.

Firma de mensajes y certificados

Lerian SPI firma digitalmente sus mensajes salientes. Elige un backend de custodia con BACEN_SPI_SIGNER_KIND. Con el backend kmip, un UID incorrecto de la clave privada de firma o un ajuste incorrecto de DigestInfo detiene el inicio. Lo mismo vale para los backends KMIP de DICT y de BR Code JOSE.

Validación de certificados (OCSP/CRL)

Resolutor de payload

Estas variables controlan cómo el servicio almacena y referencia payloads grandes de SPI.

Canal entrante (BACEN_ICOM_*)

Canal de long-poll para los mensajes que BACEN envía de vuelta al participante. Cada consumidor requiere un backend de persistencia configurado, BACEN_ICOM_ISPB, BACEN_SPI_INTERNAL_CALLBACK_SECRET y BACEN_CALLBACK_MTLS_HEADER_SECRET. El consumidor principal también requiere BACEN_ICOM_BASE_URL. El consumidor secundario también requiere BACEN_SPI_SECONDARY_ENDPOINT. Un consumidor habilitado requiere el modo proxy de callback: TLS_TERMINATED_UPSTREAM=true, ningún SERVER_TLS_CLIENT_CA_FILE y BACEN_CALLBACK_TRUSTED_PROXY_CIDRS con la dirección desde la que reenvía el consumidor. Con el SERVER_ADDRESS predeterminado, esa dirección es 127.0.0.1.

Cliente DICT (BACEN_DICT_*)

Cliente para el directorio de claves Pix de BACEN (DICT), incluido el endpoint NP para verificaciones de existencia de claves por lote. El cliente no lee HTTP_PROXY ni HTTPS_PROXY.

Firma JOSE de BR Code (BACEN_BRCODE_JOSE_*)

Firma payloads dinámicos de BR Code (JWS). Cuando BACEN_BRCODE_JOSE_SIGNER_KIND no está configurada, JOSE queda deshabilitado y los endpoints públicos de payload se niegan a servir. Con JOSE habilitado, enruta las rutas de payload (/api/v1/brcode/payload/*) y la ruta del conjunto de claves (/api/v1/brcode/.well-known/jwks.json) bajo PUBLIC_BASE_URL al binario brcode, sin ningún autorizador delante. El PSP del pagador llama a estas rutas sin credencial.

Resolución de QR de BR Code (BACEN_BRCODE_QR_PAYER_*)

Controla la resolución de un QR dinámico del lado del pagador. Cuando la resolución está desactivada, su operación responde 503. Con BACEN_ARQ_ENDPOINT configurada y BACEN_ARQ_ENABLED distinta de false, el binario spi revisa la lista de certificados cada hora. Cuando la lista almacenada tiene 24 horas, descarga la lista de BACEN por los archivos BACEN_TLS_*, la valida y la almacena en la base de datos. Una descarga fallida o inválida conserva la última lista. El ENV_NAME del binario spi selecciona la lista: production descarga la lista de producción, y cualquier otro valor descarga la lista de homologación. El binario brcode lee la lista almacenada cada minuto y no necesita para ello los archivos BACEN_TLS_* ni BACEN_ARQ_ENDPOINT, así que brcode y spi deben usar la misma base PostgreSQL. Hasta que se almacene la primera lista, la resolución responde 503. El binario spi detiene el arranque cuando BACEN_BRCODE_QR_PAYER_ENABLED es true en su propio entorno, la confianza de prueba está apagada, BACEN_ARQ_ENDPOINT está vacía y BACEN_ARQ_ENABLED es distinta de false.

Cifrado y hashing de PII

Cada variable a continuación contiene material sensible de clave o pepper. Protege los datos personales en reposo mediante cifrado e indexación ciega. Nunca confirmes ni registres un valor en logs. Inyéctalo en el momento del despliegue a través de tu gestor de secretos. Una rotación de pepper o clave requiere un reindexado o recifrado planificado.
Cada clave tiene 32 bytes, en formato bruto o base64. Cada pepper tiene al menos 32 caracteres.

PostgreSQL

Redis

Archivo regulatorio (REGULATORY_ARCHIVE_*)

Los binarios spi y dict mantienen el archivo regulatorio en un almacenamiento compatible con S3. Los binarios brcode y core no usan estas variables. Aquí, un entorno de desarrollo es aquel en el que ENV_NAME es development, develop, dev, local o test, y DEPLOYMENT_MODE no es saas. Estas reglas leen ENV_NAME tal como está configurado, así que un ENV_NAME sin configurar no es un entorno de desarrollo. Una variable obligatoria ausente detiene el inicio. En un entorno de desarrollo sin bucket, el riel no archiva nada. Con el archivo activo, /readyz en spi y dict indica falla en la verificación del archivo mientras el bucket no responde, y sigue listo.

Outbox y streaming

Lerian SPI publica eventos mediante un outbox transaccional y un productor de streaming, y consume eventos de liquidación para BR Code. El consumidor de liquidación de BR Code se ejecuta de forma incondicional. Streaming no tiene interruptor de activación: STREAMING_BROKERS es obligatorio al iniciar, incluso cuando OUTBOX_ENABLED=false. Cada binario requiere su propio valor fijo de STREAMING_CLOUDEVENTS_SOURCE, y cualquier otro valor detiene el inicio: br-spi para spi, br-spi-dict para dict, br-spi-brcode para brcode y br-spi-core para core. Una entrada de STREAMING_EVENT_POLICIES que desactiva un evento de Lerian SPI detiene el inicio. Solo los dos eventos spi_tracking y tres eventos dict_med_operations (inconsistent_projection, feed_blocked y feed_record_abandoned) se pueden desactivar.

Programadores

Trabajos en segundo plano, cada uno con su propio interruptor. Los dos trabajos de DICT con valor predeterminado true tienen deberes regulatorios, así que el binario dict inicia su programador para ellos, a menos que SCHEDULER_ENABLED=false. El binario spi hace lo mismo para los trabajos de veredicto de las programaciones y de plazo de portabilidad. Los trabajos con valor predeterminado false también requieren SCHEDULER_ENABLED=true. Los workers de descubrimiento e inventario de DICT tienen sus propios controles en la siguiente sección.

Descubrimiento e inventario de DICT

Los workers siguientes se ejecutan de forma independiente a SCHEDULER_ENABLED, cada uno con su propio interruptor.

Rate limiting, idempotencia y conectividad

Systemplane y configuración en tiempo de ejecución

Consulta Systemplane para conocer la API, los espacios de nombres y los permisos requeridos.

Observabilidad

Documentación

Salud y readiness

Lerian SPI expone GET /health (liveness), GET /readyz (readiness) y GET /version en el puerto HTTP principal. /metrics se ejecuta en su propio listener cuando está habilitado. Consulta Salud y readiness para conocer el contrato de las verificaciones. La respuesta de /readyz incluye una verificación license. Con LICENSE_KEY, la verificación siempre está activa y no llama al servicio de licencias, así que una licencia inválida no lleva /readyz a 503. Una licencia que el riel rechaza detiene el binario, al iniciar o en una verificación posterior en segundo plano. Las verificaciones de certificados, la de custodia del firmante y la del archivo regulatorio informan su estado real en el cuerpo de /readyz. Cuando una indica falla, /readyz sigue listo.