> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Operar Lerian SISBAJUD > Operar Lerian SISBAJUD: alcance por institución, conciliación, cadencia de bloqueo permanente, ventanas de respuesta, rotación de claves y credenciales, y garantías de cifrado envelope. 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](/es/rails/sisbajud/how-sisbajud-works#permanent-block) 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`. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.