Segurança da Informação e Proteção de Dados Pessoais
Última atualização: 2 de setembro de 2026 — Responsável técnico: Paulo Alencar — paulojuan@alencara.adv.br
1. Política de Privacidade e Proteção de Dados Pessoais (LGPD)
1.1. Controlador e encarregado
Controlador dos dados: Paulo Juan Sociedade Individual de Advocacia, CNPJ 41.911.177/0001-27. Responsável técnico e ponto de contato para assuntos de proteção de dados: Paulo Alencar, paulojuan@alencara.adv.br.
1.2. Dados tratados e finalidade
Os dados pessoais tratados por meio das integrações com o CNJ/PDPJ (DataJud, Domicílio Judicial Eletrônico e, quando aprovado, Datalake) compreendem número de processo, nome e documento das partes e de seus representantes, movimentações processuais e conteúdo de citações/intimações oficiais. São utilizados exclusivamente para consulta de andamento processual, recebimento de citações e intimações, e organização interna dos casos sob patrocínio deste escritório — nunca para finalidade diversa, comercialização, perfilamento ou compartilhamento com terceiros.
1.3. Base legal
O tratamento se ampara na execução de contrato de prestação de serviços advocatícios com o cliente titular dos dados (art. 7º, V, LGPD), no cumprimento de obrigação legal própria da atividade da advocacia — incluindo o dever de acompanhamento processual e de observância de prazos — e, subsidiariamente, no legítimo interesse do escritório em organizar e proteger os interesses de seus clientes (art. 7º, IX, LGPD).
1.4. Minimização de dados
A consulta é tecnicamente limitada aos processos vinculados às inscrições na OAB dos advogados do próprio escritório — não há varredura, consulta em massa nem acesso a processos de terceiros alheios à atuação do escritório. Cada integração (DataJud, PDPJ) é configurada e auditada de forma independente, com credenciais próprias, evitando escopo de acesso além do estritamente necessário.
1.5. Retenção e eliminação
Os dados processuais são mantidos enquanto durar a relação contratual com o cliente e pelo prazo de guarda aplicável à atividade advocatícia e à prescrição das pretensões envolvidas. Registros de auditoria (item 3) são mantidos por prazo compatível com a finalidade de rastreabilidade, sem prazo de expurgo automático que comprometa a capacidade de reconstituição de acessos passados.
1.6. Compartilhamento com terceiros
Os dados obtidos das APIs do CNJ/PDPJ não são repassados a outras pessoas físicas ou jurídicas, em conformidade com a vedação expressa nesse sentido. As únicas integrações de terceiros existentes (Banco Inter, para emissão de boleto/PIX financeiro; Google Drive, para armazenamento de documentos do processo) operam sobre dados distintos dos obtidos via CNJ/PDPJ e sob controle exclusivo do escritório.
1.7. Direitos do titular
Qualquer titular de dados pode exercer os direitos previstos no art. 18 da LGPD (confirmação de tratamento, acesso, correção, anonimização, portabilidade, eliminação, informação sobre compartilhamento, entre outros) mediante contato direto com o encarregado indicado no item 1.1, respeitadas as obrigações de guarda de informações ligadas a processos judiciais em andamento.
2. Segurança da Informação
Estruturada com base no Guia Orientativo sobre Segurança da Informação para Agentes de Tratamento de Pequeno Porte e no Checklist de Medidas de Segurança para Agentes de Tratamento de Pequeno Porte, ambos publicados pela ANPD (ver referências ao final).
2.1. Controle de acesso
O acesso ao sistema é individual e nominal — não existem contas compartilhadas. Permissões seguem dois eixos independentes: perfil de acesso (gestão geral, gerência, colaborador), que define quais telas e módulos cada pessoa pode ver; e nível de autonomia (colaborador, advogado supervisionado, advogado autônomo, coordenador), que define o grau de confirmação necessário em prazos e compromissos — permitindo controlar separadamente "o que a pessoa pode acessar" de "o quanto ela pode decidir sozinha". Senhas nunca são armazenadas em texto plano — são protegidas por função de hash unidirecional (bcrypt), tornando inviável sua recuperação mesmo com acesso direto ao banco de dados.
2.2. Criptografia de dados sensíveis
Credenciais de integração com terceiros — client secrets das APIs do CNJ/PDPJ, certificados digitais A1, chaves privadas usadas em integrações bancárias — são armazenadas exclusivamente de forma criptografada, nunca em texto plano. O algoritmo empregado é AES-256-GCM, com vetor de inicialização (IV) aleatório e exclusivo gerado para cada registro individualmente e tag de autenticação que detecta qualquer adulteração do valor cifrado. Uma vez cadastradas, as credenciais não são reexibidas na interface — qualquer atualização exige o valor completo novo, nunca uma edição parcial do já salvo.
2.3. Segurança das comunicações e perímetro de rede
Toda comunicação com os sistemas é feita exclusivamente via HTTPS/TLS, com certificados emitidos e renovados automaticamente (Let's Encrypt) através de proxy reverso dedicado. O servidor mantém firewall de borda ativo, com política padrão de bloqueio de entrada e liberação expressa apenas das portas estritamente necessárias à operação (administração remota via SSH e acesso HTTP/HTTPS à aplicação). Nenhum serviço de banco de dados ou cache é exposto diretamente à internet — o acesso a esses serviços só é possível a partir da rede interna dos próprios containers da aplicação.
2.4. Isolamento de processos e cópias de segurança
A aplicação, o banco de dados e o cache de sessão rodam em processos isolados (containers) dentro do mesmo host, comunicando-se apenas pela rede interna definida para essa finalidade. O banco de dados é copiado integralmente de forma automatizada uma vez por dia, com retenção de 30 dias e acesso ao arquivo de backup restrito ao responsável técnico do sistema (permissão de leitura exclusiva do usuário administrador do servidor).
2.5. Gerenciamento de vulnerabilidades e atualização
A aplicação é reconstruída do zero a cada nova implantação, com todas as dependências de software resolvidas em suas versões vigentes no momento do build — não há acúmulo de pacotes desatualizados entre versões. Revisões de segurança pontuais já foram realizadas sobre a base de código, cobrindo controles de acesso a recursos internos, validação de origem de requisições externas e limites de tentativa em rotas sensíveis, com os achados corrigidos e documentados internamente.
2.6. Revisão desta política
Esta política é revisada a cada mudança relevante de infraestrutura ou de integração com terceiros, e no mínimo uma vez ao ano, de forma a acompanhar a evolução real do sistema e nunca descrever controle que tenha deixado de existir ou que ainda não tenha sido implementado.
3. Protocolos de Auditoria
Estruturados com base nas diretrizes de rastreabilidade do ecossistema PDPJ-Br e nas recomendações de auditoria do CNJ — em especial a exigência de reconstrução do processo de acesso aos dados pelos usuários. O sistema mantém duas trilhas de auditoria complementares, cobrindo dois momentos distintos do fluxo de dados.
3.1. Trilha de chamadas externas (integração com o CNJ/PDPJ)
Toda chamada realizada pelo sistema às APIs externas do CNJ/PDPJ é registrada automaticamente numa tabela de auditoria dedicada, apartada dos dados de negócio, no exato momento da chamada — não é um log de aplicação genérico, é um registro estruturado com campos fixos: qual integração e qual operação específica foi chamada (ex.: consulta de processo, consulta por OAB, obtenção de comunicação), número do processo envolvido quando aplicável, identificação do usuário do sistema que originou a chamada (ou indicação explícita de que foi disparada por rotina automatizada, não por ação manual), resultado da chamada, código de status HTTP retornado, duração em milissegundos e data/hora. Em nenhuma hipótese são registrados credenciais, tokens de acesso ou segredos — a trilha contém somente metadados da chamada.
3.2. Trilha de acesso interno (leitura dos dados já trazidos ao sistema)
Como a chamada externa ao CNJ/PDPJ é executada sob a credencial única do responsável técnico (item 5) — limitação inerente ao modelo de credencial de serviço do próprio ecossistema PDPJ, não uma opção deste sistema —, a rastreabilidade por pessoa física é garantida numa segunda camada, interna e independente: cada usuário do sistema possui cadastro individual e nominal com CPF próprio, e toda vez que esse usuário abre a página de um processo — passando a ter acesso de fato aos dados nela contidos, incluindo os trazidos do CNJ/PDPJ — esse acesso é registrado com data, hora e identificação do usuário, numa tabela própria e apartada da trilha de chamadas externas. A combinação das duas trilhas permite reconstituir, para qualquer processo e a qualquer momento, tanto quando o dado foi buscado no CNJ quanto exatamente qual pessoa física, dentro do escritório, chegou a visualizá-lo depois.
3.3. Integridade temporal dos registros
O servidor mantém sincronização de relógio ativa via NTP (Network Time Protocol), garantindo que os carimbos de data/hora gravados nas duas trilhas de auditoria correspondam ao tempo real, sem deriva perceptível — condição necessária para que a ordem cronológica dos acessos seja confiável em qualquer reconstituição posterior.
3.4. Imutabilidade e controle de acesso à auditoria
Nenhuma das duas trilhas de auditoria expõe funcionalidade de edição ou exclusão de registros pela interface do sistema — são estritamente de escrita (a cada evento) e leitura (na consulta), nunca de atualização. A trilha de chamadas externas é consultável em tela própria, com filtro por integração, processo e período, restrita ao perfil de gestão máxima do escritório, com exportação sob demanda para conferência ou apresentação a terceiros — incluindo, quando necessário, ao próprio CNJ.
4. Disponibilidade e Uptime
4.1. Perfil de uso proporcional
O acesso do sistema às APIs do CNJ/PDPJ ocorre por rotina agendada — execução automatizada em janela diária fixa —, e não por consulta contínua ou concorrente. É um perfil de uso proporcional ao porte do escritório, sem geração de carga relevante sobre os sistemas do CNJ e sem características de consumo abusivo (não há execução de operações repetitivas em curto espaço de tempo nem consulta sistemática a processos sem relação com o escritório).
4.2. Infraestrutura e isolamento de serviços
A infraestrutura roda em servidor dedicado, com aplicação, banco de dados e cache isolados em processos independentes (containers), orquestrados por proxy reverso que gerencia automaticamente a emissão e renovação de certificados TLS. Esse desenho permite que a atualização ou eventual falha de um componente não derrube os demais — por exemplo, uma manutenção no banco de dados não interrompe o certificado HTTPS já emitido nem exige reconfiguração manual ao voltar.
4.3. Continuidade e recuperação de dados
O banco de dados é copiado integralmente de forma automatizada uma vez por dia, com retenção de 30 dias — cobrindo tanto falha de hardware quanto erro operacional humano, com janela de recuperação de até um mês.
4.4. Monitoramento ativo e resposta a falhas
As rotinas de sincronização com o CNJ/PDPJ são monitoradas por mecanismo próprio de alerta: qualquer falha de sincronização — de qualquer uma das fontes de dados em uso — é registrada automaticamente como notificação interna e, quando recorrente, também disparada como aviso direto ao responsável técnico, com verificação horária independente da própria saúde da sessão de integração. Esse desenho garante que uma falha nunca fique descoberta até ser notada manualmente por um usuário — o próprio sistema monitora a si mesmo e escala o alerta automaticamente.
4.5. Redundância de fontes de dados
Para dados de andamento processual e citações/intimações, o sistema já opera com mais de uma fonte independente em paralelo (API pública DataJud do CNJ e Domicílio Judicial Eletrônico da PDPJ), cada uma isolada em sua própria rotina de sincronização — a falha de uma fonte específica não compromete as demais nem interrompe o funcionamento geral do sistema. Essa redundância é, na prática, o próprio mecanismo de continuidade do serviço do ponto de vista do usuário final do escritório.
5. Capacidade Técnica e Gestão de Identidades
5.1. Responsável técnico
Paulo Alencar — web designer com especialidade em desenvolvimento back-end, automação de processos e fluxos de dados, com experiência prática na integração de soluções modernas e ferramentas baseadas em inteligência artificial para otimização de rotinas. Responsável pela concepção, desenvolvimento e operação técnica de todos os sistemas do escritório, incluindo as integrações com o CNJ/PDPJ descritas neste documento.
5.2. Modelo de gestão de identidade e controle de acesso
O acesso interno segue um modelo de permissão em duas dimensões (perfil funcional e nível de autonomia, detalhado no item 2.1), com granularidade por módulo — cada tela do sistema (processos, financeiro, agenda, relatórios etc.) pode ser liberada ou restrita independentemente por usuário. Credenciais de terceiros (bancárias e do CNJ/PDPJ) são cadastradas por usuário autorizado através de tela própria, armazenadas exclusivamente de forma criptografada e nunca reexibidas depois de salvas — qualquer atualização exige o valor completo novo.
5.3. Arquitetura preparada para crescimento
A infraestrutura roda em ambiente de nuvem containerizado, com os serviços de aplicação, banco de dados e cache desacoplados entre si — arquitetura que permite ajustar e escalar recursos (processamento, memória, réplicas de aplicação) conforme a demanda de acesso, sem necessidade de redesenho estrutural do sistema. As rotas da aplicação são predominantemente sem estado (stateless), delegando persistência de sessão e dados ao banco de dados e ao cache dedicados — característica que viabiliza a adição de novas instâncias da aplicação atrás do mesmo proxy reverso, sem alteração de código, caso o volume de uso venha a exigir.
5.4. Evolução planejada da autenticação
A gestão de identidade está em evolução para apoiar-se em provedor de identidade externo (Google, via OAuth 2.0/OpenID Connect), o que delegará parte da capacidade de autenticação e verificação em duas etapas à infraestrutura desse provedor — reduzindo a responsabilidade do sistema próprio à camada de autorização (o que cada usuário autenticado pode ver e fazer), já hoje implementada e descrita no item 5.2.
Referências
- ANPD — Guia Orientativo sobre Segurança da Informação para Agentes de Tratamento de Pequeno Porte: gov.br/anpd
- ANPD — Checklist de Medidas de Segurança para Agentes de Tratamento de Pequeno Porte: gov.br/anpd
- ANPD — Modelo de Registro das Operações de Tratamento de Dados Pessoais (ROPA) para ATPP: gov.br/anpd
- Lei nº 13.709/2018 — Lei Geral de Proteção de Dados Pessoais (LGPD)
- CNJ — Portaria Presidência nº 316, de 20 de setembro de 2024 (disciplina o acesso a dados judiciais públicos consolidados em repositório centralizado — datalake)
- CNJ — Normativos de Segurança da Informação: cnj.jus.br
Contato
Documento publicado em caráter de transparência e para instrução de solicitações de credencial de integração junto ao CNJ/PDPJ. Dúvidas: paulojuan@alencara.adv.br.
