Skip to main content
Lerian SISBAJUD cifra los datos personales que guarda en su propia base de datos y bucket. También mantiene un registro de auditoría de los cambios que hace.

​
Alcance por institución

Lerian SISBAJUD corre en modo de un solo tenant de forma predeterminada. En el modo multi-tenant, el tenant es el límite de aislamiento de la base de datos: cada tenant tiene su propia base de datos, y Lerian SISBAJUD lee el tenant de la declaración (claim) tenantId. El modo de un solo tenant usa el DEFAULT_TENANT_ID, cuyo valor predeterminado es 11111111-1111-1111-1111-111111111111. La institución es una unidad separada. Lerian SISBAJUD delimita las órdenes, los archivos, las credenciales y las claves de cifrado de cada institución. Un tenant puede contener muchas instituciones, y un solo despliegue las atiende a todas.

​
Conciliación

La conciliación compara, para cada cuenta de bloqueo de una orden en monitoreo, el monto que el servicio bloqueó con el saldo disponible en el ledger. Un escaneo programado (RECONCILIATION_ENABLED, cada hora de forma predeterminada) registra en el registro de auditoría las diferencias que encuentra. Con EXECUTION_ENABLED activado, una diferencia también inicia una ejecución de recuperación para el titular de la cuenta. Un operador también puede iniciar una conciliación manual a demanda, incluso con el escaneo programado desactivado. Dos jobs diarios cierran el monitoreo. Ambos están desactivados de forma predeterminada:
  • MONITORING_EXPIRY_ENABLED cierra las órdenes no permanentes en monitoreo cuya ventana de monitoreo ya pasó. Con él desactivado, una orden tradicional bloqueada parcialmente permanece en monitoreo y no recibe respuesta.
  • PERMANENT_BLOCK_EXPIRY_ENABLED detiene los reintentos de los bloqueos permanentes que superaron su plazo.

​
Cadencia de bloqueo permanente

Las órdenes permanentes reintentan el bloqueo ante eventos de cambio de saldo del ledger y en un barrido cada 5 segundos, mientras EXECUTION_ENABLED está activado. Con PERMANENT_BLOCK_EXPIRY_ENABLED desactivado, el valor predeterminado, los reintentos no se detienen en el plazo. Cómo funciona Lerian SISBAJUD describe los plazos.

​
Ventanas de respuesta

BACEN define el plazo de la respuesta de bloqueo según la hora de envío de cada remesa. Una remesa enviada hasta las 13:00 BRT vence a las 19:00 BRT del mismo día. Una remesa enviada después de las 13:00 BRT vence a las 12:00 BRT del siguiente día hábil. Lerian SISBAJUD genera los archivos de respuesta en un intervalo, no en horarios fijos. Configura RETURN_FILE_GENERATION_SCAN_INTERVAL e INFORMATION_RETURN_FILE_GENERATION_SCAN_INTERVAL para que cada ciclo cumpla los plazos de BACEN. Ambos tienen un valor predeterminado de una hora.

​
Credenciales y rotación de claves

La rotación es administrativa y corre por institución:
  • Credenciales del conector. Lerian SISBAJUD usa estas credenciales para llegar al ledger de Midaz y, en el modo de CRM legacy, al CRM. Un operador las define en la configuración de la institución: POST /institutions la crea, y PATCH /institutions/{institutionId} reemplaza las credenciales. Un reemplazo no revoca el secreto anterior en su emisor. Las credenciales de Lerian STA valen para todo el servicio: STA_CLIENT_ID y STA_CLIENT_SECRET.
  • Clave de las credenciales. credential-kek:rotate rota la clave que envuelve las credenciales almacenadas. Ningún valor de credencial cambia.
  • Clave de cifrado de claves (KEK). kek:rotate rota la KEK de la institución. Con Vault como proveedor de claves, la rotación emite un evento kek.rotated. La clave de datos (DEK) de cada registro se ubica bajo la KEK. Por eso, una rotación avanza la versión de la KEK activa sin volver a cifrar ningún campo. Las claves de datos selladas bajo la versión anterior siguen siendo legibles. El job de reenvolvimiento (KEK_REWRAP_BACKFILL_ENABLED) las avanza a la nueva versión.
  • Keyset de tokenización. keyset:rotate agrega una nueva clave primaria al keyset del índice ciego de la institución. El job de re-hash (REHASH_BACKFILL_ENABLED) mueve los hashes existentes a la nueva clave.
Una rotación devuelve SBJ-0007 / 409 cuando otra rotación ya está en curso. Una rotación que se confirma pero no se puede auditar devuelve SBJ-0002 / 500. La clave ya avanzó, así que esto no es reintentable. Reintentarlo rota una segunda vez y amplía la brecha de auditoría. Escala y concilia el registro de auditoría en su lugar.

​
Protección de datos

  • Cifrado envelope. Cada registro lleva su propia clave de datos, sellada bajo la KEK de la institución con AES-256-GCM. Los datos autenticados adicionales vinculan cada texto cifrado a su institución, tabla, registro y campo, así que nadie puede intercambiar un texto cifrado entre campos o registros.
  • Tokenización buscable. Un índice ciego admite indexación por coincidencia exacta en los identificadores fiscales (CPF/CNPJ) y el número de proceso sin almacenamiento en texto plano. No reemplaza el descubrimiento de cuentas: para consultar el CRM, Lerian SISBAJUD descifra el CPF/CNPJ. Lerian SISBAJUD cifra el texto libre y no lo tokeniza. No tokeniza los valores monetarios, y almacena los valores monetarios de las tablas de órdenes como texto plano, no como texto cifrado.
  • Registro de auditoría. Lerian SISBAJUD agrega eventos de auditoría a un log sin brechas y de solo adición. Un código de autenticación por evento vincula cada entrada a su posición. GET /admin/audit/verify vuelve a verificar un rango de entradas sin descifrar ningún payload.
  • LGPD. Una solicitud de acceso del titular exporta las órdenes judiciales del titular y los metadatos de los archivos que las respaldan. El borrado criptográfico honra una solicitud de eliminación. Destruye la clave de datos de cada registro coincidente, así que su texto cifrado ya no se puede descifrar, y pone los montos en cero. La fila y un registro de auditoría de la eliminación permanecen.

​
Contingencia

Lerian SISBAJUD lleva una orden fallida a FAILED en lugar de dejarla en procesamiento. No reintenta por sí mismo una orden fallida. Un operador puede reprocesarla, lo que la devuelve al estado pendiente. Las vistas de estado de SLA y estadísticas de procesamiento muestran dónde están las órdenes. La resolución del conector falla de forma segura. Si la integración no puede resolver de forma segura una cuenta o una credencial, rechaza la operación en lugar de actuar sobre un objetivo ambiguo.

​
Superficie HTTP

Las órdenes llegan solo por archivo, así que la superficie HTTP no admite el envío de órdenes judiciales. La mayoría de los endpoints son administrativos y de observación. POST /remittance-files/notifications es operacional: recibe y analiza de forma síncrona un objeto de remesa que ya está almacenado. No acepta un payload de orden. Un operador puede:
  • listar órdenes y archivos, y leer el detalle de una sola orden o archivo
  • reprocesar órdenes fallidas
  • ejecutar una conciliación y leer su estado
  • ver el estado de SLA y las estadísticas de procesamiento
  • verificar el registro de auditoría
  • manejar solicitudes de LGPD: crearlas, resolverlas, ejecutar una eliminación y exportar los datos de un titular
  • registrar justificaciones de incumplimiento
  • leer el resumen de un titular en las organizaciones de Midaz de la institución
  • generar, reconsolidar o resolver la transmisión de un archivo de respuesta
  • confirmar un evento en dead letter de Lerian STA
  • configurar la institución, incluidas sus credenciales del conector, y rotar sus claves
Activa la autenticación de plugin fuera de local y development.