Skip to main content
O Lerian SISBAJUD é o trilho 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 apenas entram em vigor depois de um reinício do serviço. Fundamentos de configuração do BYOC documenta a base universal que todo serviço Go da Lerian compartilha: servidor, armazenamento de dados, multi-tenancy, telemetria, autenticação de plugin e licenciamento. Esta página cobre apenas as variáveis específicas do Lerian SISBAJUD. Nas tabelas abaixo, a coluna Padrão / Obrigatório mostra o valor padrão. Um qualificador em negrito (por exemplo, Obrigatório ou Obrigatório se habilitada) marca as variáveis que você deve definir. significa que não há padrão. Qualquer variável sinalizada como Sensível carrega material de credencial ou 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 Health e readiness para o contrato das sondas.

Backend de segurança

O serviço valida o provedor de KMS na inicialização. Ele seleciona o backend que protege os dados de apreensão determinada judicialmente com criptografia por envelope. Em produção, um valor não definido ou não suportado falha a inicialização de forma fechada. Fora de produção, o padrão é vault.
KMS_PROVIDER=vault exige as variáveis do Vault abaixo. KMS_PROVIDER=aws exige a AWS_REGION compartilhada. As credenciais do conector por instituição ficam seladas dentro dos metadados de configuração da instituição, sob uma KEK de classe credenciais. Nenhum seletor de ambiente escolhe o armazenamento delas. KMS_PROVIDER usa vault como padrão quando não definida fora de produção. Em produção, você deve defini-la explicitamente ou a inicialização falha de forma fechada.

Vault (quando KMS_PROVIDER=vault)

| VAULT_TOKEN_RENEW_ENABLED | true | Executa um renovador em segundo plano que atualiza o token do Vault antes que o lease dele expire. | | 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 ao Vault. |

AWS (quando KMS_PROVIDER=aws)

Ciclo de vida de criptografia

A criptografia por envelope usa uma chave de dados por registro, selada sob a chave mestra da instituição, além de um índice cego 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 vêm desabilitados por padrão, exceto o reaper de processing lock, que roda por padrão. Os workers usam os controles de cadência *_SCAN_INTERVAL (segundos) e *_BATCH_SIZE (quando aplicável).

Armazenamento de objetos

O Lerian SISBAJUD grava artefatos de apreensão determinada judicialmente em um armazenamento de objetos compatível com S3, já criptografados. A camada de blob nunca vê o texto plano.

Conector do ledger Midaz

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