Skip to main content
O Lerian SISBAJUD trata as realidades operacionais do bloqueio judicial de ativos. Ele cumpre e informa cada ordem por instituição, reitera as ordens permanentes por semanas e mantém os dados pessoais fora do texto plano. Ele também prova cada mudança que faz, porque a lei exige essa prova. O isolamento por instituição enquadra tudo isso.

​
Isolamento por instituição

O Lerian SISBAJUD é multitenant. O tenant é a fronteira de isolamento de banco de dados. O Lerian SISBAJUD o lê do claim tenantId, e o modo single-tenant usa o DEFAULT_TENANT_ID definido explicitamente. Não há um valor padrão de string efetivo, portanto um deployment single-tenant utilizável deve definir um UUID válido. A instituição é uma unidade à parte. O Lerian SISBAJUD isola as ordens, os arquivos, as credenciais e as chaves de criptografia de cada instituição. Um tenant pode conter muitas instituições, e um deployment as atende todas sem visibilidade entre instituições.

​
Reconciliação

A reconciliação trabalha no grão de uma ordem de monitoramento contra um snapshot de saldo do ledger. Uma varredura agendada compara as ordens pendentes com o ledger e registra qualquer lacuna que encontre. Um operador também pode iniciar uma reconciliação manual sob demanda. Uma varredura diária à parte fecha as ordens de monitoramento que ultrapassam o seu teto ou prazo, de modo que nada permaneça além da sua vida legal.

​
Cadência do bloqueio permanente

As ordens permanentes reiteram o bloqueio com os eventos de mudança de saldo do ledger. O teto de reiteração de 60 dias do CNJ, ou o prazo judicial da ordem, limita cada ordem. Não há uma passada de reiteração agendada. Um depósito acorda a reiteração diretamente, e uma varredura diária de expiração encerra as ordens cujo prazo venceu.

​
Credenciais e rotação de chaves

Duas coisas rotacionam por instituição, e ambas são administrativas:
  • Credenciais de conector. O Lerian SISBAJUD usa essas credenciais para alcançar o ledger e o canal de troca de arquivos. Um operador as registra e as rotaciona.
  • Chave de criptografia de chaves (KEK). Um operador rotaciona a KEK da instituição, e a rotação emite um evento kek.rotated. A chave de dados (DEK) de cada registro fica sob a KEK. Por isso uma rotação sobe a versão ativa da KEK sem recriptografar nenhum campo. As chaves de dados seladas sob a versão anterior seguem legíveis, e um re-empacotamento em segundo plano depois as avança para a versão nova. Uma rotação quando já existe outra em curso devolve SBJ-0007 / 409. Uma rotação que commita mas não consegue ser auditada devolve SBJ-0002 / 500: a KEK já avançou, então não se deve repetir a operação, porque repetir rotaciona uma segunda vez e amplia a lacuna de auditoria. Escale e reconcilie a trilha de auditoria contra o evento kek.rotated.

​
Proteção de dados

O Lerian SISBAJUD protege os dados pessoais em repouso por design:
  • Criptografia envelopada. Cada registro carrega a sua própria chave de dados, selada sob a KEK da instituição com AES-256-GCM. Os dados adicionais autenticados por campo vinculam cada conteúdo criptografado a um único campo e registro, de modo que ninguém pode trocar um conteúdo criptografado entre campos ou registros.
  • Tokenização pesquisável. Um blind index apoia a indexação por correspondência exata sobre identificadores fiscais (CPF/CNPJ) e o número de processo sem armazenar texto plano. Ele não substitui a descoberta de contas: para consultar o CRM, o Lerian SISBAJUD descriptografa o CPF/CNPJ apenas quando necessário e nunca o registra em logs. O Lerian SISBAJUD só criptografa o texto livre e nunca o tokeniza. Ele não tokeniza os valores monetários, e armazena os valores monetários das tabelas de ordens como texto plano, não criptografado.
  • Trilha de auditoria à prova de adulteração. O Lerian SISBAJUD anexa cada mudança de estado a um log sem lacunas e protegido criptograficamente. Um código de autenticação por evento vincula cada entrada à sua posição. Os hashes de folha de Merkle permitem a um operador verificar a trilha sem descriptografar nenhum payload.
  • LGPD. Um pedido de acesso do titular exporta os dados que a instituição guarda de um titular. A cripto-eliminação honra um pedido de eliminação. Ela destrói a chave do registro e anula os seus valores em texto plano, de modo que os dados pessoais ficam irrecuperáveis, enquanto o registro de auditoria da mudança sobrevive.

​
Contingência

O Lerian SISBAJUD leva as ordens que falham a um estado terminal FAILED, não presas em processamento, e um operador pode reprocessá-las. As visões de status de SLA e de estatísticas de processamento mostram onde as ordens estão. A resolução do conector falha de forma fechada. Se a integração não consegue resolver com segurança uma conta ou uma credencial, ela recusa a operação em vez de agir sobre um alvo ambíguo.

​
Superfície HTTP

As ordens chegam apenas por arquivo, então a superfície HTTP não envia ordens judiciais. A maioria dos endpoints é administrativa e de observação. POST /remittance-files/notifications é operacional: recebe e faz o parsing síncrono de um objeto de remessa já entregue pelo canal de troca de arquivos; não aceita um payload de ordem. Um operador pode:
  • listar ordens e arquivos, e ler o detalhe de uma única ordem ou arquivo
  • reprocessar ordens que falharam
  • executar uma reconciliação e ler o seu status
  • ver o status de SLA e as estatísticas de processamento
  • verificar a trilha de auditoria
  • tratar os pedidos LGPD — criá-los, resolvê-los, executar uma eliminação e exportar os dados de um titular
  • registrar justificativas de descumprimento
  • configurar a instituição, e registrar ou rotacionar as credenciais de conector