Permite restrição de acesso em Documento Acessório para Documento Administrativo e Matéria Legislativa

[cristian-longhi]

Descrição

Implementação dos campos "restrito" e "justificativa_restricao" na tabela de Documentos Acessórios, em Documentos Administrativos e em Matérias Legislativas, possibilitando o cadastro dos mesmos com a restrição de acesso, permitindo visualização dos mesmos somente para usuários logados e com a devida permissão.

Issue Relacionada

#3598

Motivação e Contexto

No caso de Visibilidade dos Documentos Administrativos cadastrada como Ostensiva, os processos ali cadastrados estão disponíveis para acesso sem necessidade de usuário logado. No entanto, alguns documentos integrantes do processo podem conter informações além daquelas relevantes para o andamento do processo. A possibilidade de restringir o acesso evita a necessidade de se manter um arquivo paralelo de documentos que não podem ser cadastrados, bem como auxilia a Casa Legislativa na adequação à LGPD.
Embora a Issue relacionada fala apenas de Documentos Administrativos, a funcionalidade foi extendida às Matérias Legislativas.

Como Isso Foi Testado?

Manualmente.

Capturas de Tela (se apropriado):

Tela de listagem de Documentos Acessórios quando há algum documento restrito para usuário anônimo ou sem permissão:

Tela de detalhamento do Documento Acessório restrito para usuário anônimo ou sem permissão:

Tipos de Mudanças

• Bug fix (alteração que corrige uma issue e não altera funcionalidades já existentes)
• Nova feature (alteração que adiciona uma funcionalidade e não altera funcionalidades já existentes)
• Alteração disruptiva (Breaking change) (Correção ou funcionalidade que causa alteração nas funcionalidades existentes)

Checklist:

• Eu li o documento de Contribuição (CONTRIBUTING).
• Meu código segue o estilo de código deste projeto.
• Minha alteração requer uma alteração na documentação.
• Eu atualizei a documentação de acordo.
• Eu adicionei testes para cobrir minhas mudanças.
• Todos os testes novos e existentes passaram.

[robsonsda]

Alguma novidade sobre essa implementação? É muito necessária, pois temos tramitação praticamente toda digital. Alguns documentos acessórios que ficam públicos ferem a LGPD, e devem ser de consulta interna.

[robsonsda]

Prezados,

Gostaria de saber se há alguma atualização sobre essa implementação. Ela é fundamental, considerando que nossa tramitação é praticamente toda digital. Alguns documentos acessórios acabam ficando públicos, o que pode violar a LGPD, pois contêm dados pessoais sensíveis que deveriam ser restritos à consulta interna.

Além disso, a falta desse ajuste compromete a segurança jurídica do processo e expõe a instituição a riscos de responsabilização por tratamento inadequado de dados. Também pode gerar questionamentos por parte dos interessados, o que impacta diretamente a confiabilidade do sistema e a imagem da Casa.

Portanto, reforço a urgência da demanda e coloco-me à disposição para qualquer esclarecimento ou apoio necessário para viabilizar a solução.

[zwinglio]

Ta pronto pra implementar, mas não anda...

[edwardoliveira]

Obrigado pelo PR, @cristian-longhi — a motivação é legítima e a demanda é real (como os comentários do @robsonsda e do @zwinglio confirmam).

Porém, depois de analisar o diff com cuidado, concluímos que a abordagem atual tem problemas de segurança que impedem o merge. Os principais:

1. Sem bloqueio server-side: as views de detalhe não retornam 403, carregam o objeto completo e delegam a "proteção" ao template. Qualquer acesso direto à view, ou qualquer mudança futura no template, expõe os dados.

2. Acesso direto aos arquivos: os documentos são ocultados na listagem e no detalhe, mas continuam acessíveis pela URL direta do arquivo (/media/...). A proteção é visual, não server-side.

3. Pesquisa textual (Solr): o SAPL indexa o conteúdo de todos os documentos. Como o PR não altera a indexação nem os filtros de busca, documentos marcados como restritos continuariam aparecendo nos resultados da pesquisa textual.

4. Modelo de permissão sem granularidade: a restrição é binária, isto é, quem tem change_documentoacessorioadministrativo vê tudo, quem não tem não vê nada. Na prática, qualquer operador do sistema com essa permissão (de qualquer setor, até mesmo um estagiário) teria acesso a documentos restritos de todos os setores, o que não atende ao princípio do mínimo necessário da LGPD.

5. XSS introduzido: o campo justificativa_restricao é renderizado com |safe nos templates de listagem, permitindo injeção de JavaScript e ironicamente criando uma vulnerabilidade nova num PR motivado por segurança.

As mudanças necessárias para resolver isso de verdade são mais profundas do que aparentam. Restrição de acesso a documentos toca em várias camadas do sistema ao mesmo tempo: modelo de dados, serving de arquivos, indexação, API, templates, e demanda um olhar holístico e cuidadoso. Sem isso, o risco é entregar uma solução que parece funcionar na interface, mas que tem furos exploráveis por caminhos alternativos (URL direta, busca textual, API), o que pode ser pior do que não ter a funcionalidade, porque dá uma falsa sensação de segurança.

A boa notícia é que já estamos trabalhando numa solução que endereça esses pontos, com controle de acesso vinculado a setores/responsáveis e proteção efetiva no nível do servidor e do índice de busca.