Skip to main content
O Lerian SISBAJUD é o rail de propriedade da Lerian que cumpre ordens judiciais de bloqueio de ativos e protege os dados pessoais que elas carregam. Você define essas variáveis no momento do deploy. Elas só entram em vigor após uma reinicialização do serviço. A referência de configuração BYOC documenta o backbone universal que todo serviço Go da Lerian compartilha: servidor, datastores, multi-tenancy, telemetria, autenticação de plugin e licenciamento. Esta página cobre apenas as variáveis distintivas do Lerian SISBAJUD. Nas tabelas abaixo, a coluna Padrão / Obrigatória mostra o valor padrão. Um qualificador em negrito (por exemplo Obrigatória ou Obrigatória se habilitado) marca as variáveis que você deve definir. significa que não há padrão. Qualquer variável marcada como Sensível carrega material de credencial ou de chave. Injete-a a partir do seu gerenciador de segredos no momento do deploy. Nunca faça commit de um valor.

Serviço e runtime

O Lerian SISBAJUD expõe /health (liveness), /readyz (readiness), /version e /metrics na porta principal. Quando você habilita a multi-tenancy, ele também expõe GET /readyz/tenant/{id}. Consulte Saúde e prontidão para o contrato das probes.

Backend de segurança

O serviço valida o provider KMS no boot. Ele seleciona o backend que protege, com criptografia de envelope, os dados de bloqueio determinados por ordem judicial. Em produção, um valor não definido ou não suportado falha o boot fechado. Fora de produção, o padrão é vault.
KMS_PROVIDER=vault requer as variáveis do Vault abaixo. KMS_PROVIDER=aws requer a AWS_REGION compartilhada. As credenciais de conector por instituição são seladas dentro dos metadados de configuração da instituição, sob uma KEK de classe de credenciais; nenhum seletor de ambiente escolhe onde armazená-las. KMS_PROVIDER usa vault como padrão quando não definido fora de produção. Em produção, você deve defini-lo explicitamente ou o boot falha fechado.

Vault (quando KMS_PROVIDER=vault)

| VAULT_TOKEN_RENEW_ENABLED | true | Executa um renewer em segundo plano que renova o token do Vault antes de o lease expirar. | | VAULT_TOKEN_RENEW_MIN_INTERVAL_SEC | 60 | Piso, em segundos, entre tentativas de renovação. | | VAULT_TIMEOUT_SEC | 15 | Timeout por requisição, em segundos, para cada round-trip do Vault. |

AWS (quando KMS_PROVIDER=aws)

Ciclo de vida cripto

A criptografia de envelope usa uma data key por registro selada sob a chave-mestra da instituição, além de um blind index para busca por correspondência exata em identificadores fiscais.

Workers de domínio

O processamento de ordens judiciais roda como um conjunto de crons em segundo plano por instituição. Todos ficam desligados por padrão, exceto o reaper de locks de processamento, que roda por padrão. Os workers usam os parâmetros de cadência *_SCAN_INTERVAL (segundos) e *_BATCH_SIZE quando aplicável.

Armazenamento de objetos

O Lerian SISBAJUD escreve os artefatos de bloqueio determinados por ordem judicial em um object store compatível com S3, já criptografados. A camada de blob nunca vê texto plano.

Conector do ledger Midaz

O Lerian SISBAJUD lê saldos e bloqueios através do ledger Midaz. MIDAZ_BASE_URL é um fallback opcional para todo o serviço; os metadados do conector por instituição têm precedência.