SEI no Docker é laboratório: como testar sem expor a rede nem usar dado real

Segunda de manhã, a tela de login do SEI aparece no notebook do analista da prefeitura. Dois comandos e um café. Na reunião, alguém sugere: "Então já dá para usar nos processos da secretaria". Não dá. O container prova que o software sobe; não prova que existe backup, atualização, responsável e autorização para operar processo público.

A resposta curta: use o ambiente Docker de sistemas públicos como laboratório. Prenda as portas ao localhost, troque toda senha padrão, alimente só com dado inventado e destrua o ambiente quando terminar. A implantação de verdade passa pelo caminho formal da instituição, com o órgão gestor do sistema, infraestrutura dimensionada e alguém que responde por ela.

Por que o container parece mais do que é

Repositórios como o sei-docker existem para facilitar desenvolvimento, testes e avaliação. Eles empacotam o servidor web, o banco, a indexação e o que mais for necessário, com valores que funcionam de primeira. Esses valores são escolhidos para conveniência: senhas conhecidas, portas abertas em todas as interfaces, volumes locais, nenhum backup.

Uma tela de login funcionando dá uma sensação de produto pronto. Só que a parte difícil de operar um sistema de processo eletrônico não é instalar. É manter atualizado com as versões oficiais, guardar e testar backups de documentos que têm valor jurídico, controlar quem tem acesso, registrar quem fez o quê e responder quando alguém pedir um processo de cinco anos atrás.

Além disso, sistema público tem dono. A adoção institucional do SEI passa por um processo formal com o órgão gestor, e as regras de uso estão nos canais oficiais. Confira as condições atuais lá antes de qualquer conversa sobre produção. O post sobre código público do governo não ser atalho para o seu sistema trata do mesmo cuidado do ponto de vista do código.

Os riscos de um laboratório mal montado

A porta aberta na rede do escritório

Um mapeamento como "8000:80" no compose publica a porta em todas as interfaces da máquina. No notebook ligado ao Wi-Fi da prefeitura, qualquer pessoa da rede acessa a tela de login, e o usuário administrador ainda tem a senha do README. Em Linux, há um detalhe que pega muita gente: as portas publicadas pelo Docker passam por regras próprias de firewall e podem ficar acessíveis mesmo com o ufw bloqueando aquela porta.

A base real "só para testar"

A tentação de importar um dump do sistema atual para ver como fica é grande. O resultado é uma cópia de processos com dados pessoais num notebook, sem criptografia, sem controle de acesso e sem registro. Isso é um incidente de dados esperando acontecer, e nenhuma justificativa de teste muda isso. O guia de adequação à LGPD em sistema pequeno ajuda a enxergar por que cópia de base é tratamento de dado como qualquer outro.

A versão congelada

Quem sobe o ambiente hoje e deixa rodando por meses fica com uma versão que não recebe correção. Se esse ambiente "de teste" virar o que todo mundo usa, você tem um sistema público sem atualização de segurança.

Como montar o laboratório com segurança, passo a passo

1. Leia o README e a licença do repositório antes de subir. Anote a versão do sistema que a imagem traz e os pré-requisitos que o projeto pede.
2. Clone numa pasta própria e trabalhe numa cópia local dos arquivos de configuração. Não edite direto o que veio do repositório se pretende acompanhar atualizações.
3. Prenda as portas ao localhost editando os mapeamentos para o formato "127.0.0.1:8000:80". Não confie em arquivo de override para isso: no merge do Compose, listas de portas se somam, e a publicação original continua lá.
4. Troque toda senha padrão que o projeto documenta, de banco e de usuário administrador, e guarde as novas num arquivo .env fora do Git.
5. Confira o resultado com docker compose config e com a lista de portas em escuta na máquina.
6. Use só dado fictício: unidades, usuários e processos inventados, com nomes que não existem.
7. Destrua quando terminar com docker compose down -v, que remove containers e volumes nomeados.

Exemplo de verificação

O nome do serviço e as portas variam conforme o compose do projeto; adapte ao que estiver no arquivo. A ideia é sempre a mesma: publicar só no endereço de loopback e conferir.

# trecho do compose na sua cópia local
services:
  web:
    ports:
      - "127.0.0.1:8000:80"

# mostra o arquivo final que o Compose vai usar, já com variáveis resolvidas
docker compose config

# portas publicadas por cada container
docker compose ps

# no Linux: em quais endereços a máquina está escutando
ss -tlnp | grep 8000

Na saída do ss, o que você quer ver é 127.0.0.1:8000. Se aparecer 0.0.0.0:8000 ou [::]:8000, a porta está aberta para a rede. Teste também de outra máquina da rede: a página não deve abrir.

Para senhas, um .env ao lado do compose, listado no .gitignore, resolve o laboratório. Em qualquer ambiente que não seja o seu notebook, siga o que está no post sobre manter segredo fora da imagem.

Dado fictício que parece real o suficiente

Para avaliar o sistema, você precisa de volume e variedade, não de dado verdadeiro. Crie uma estrutura de unidades parecida com a da prefeitura, mas com nomes genéricos ("Secretaria de Teste 1"), usuários como "analista.teste01" e processos com assuntos inventados. Se for testar busca e indexação, gere documentos com texto de preenchimento. Se alguém insistir em "um processo real para ver como fica", a resposta é não; a avaliação não depende disso.

O que levar do laboratório para a decisão

O laboratório serve para responder perguntas concretas: o fluxo atende os tipos de processo da secretaria, quanto treino a equipe precisaria, que integrações seriam necessárias. Anote essas respostas com a versão testada. Elas alimentam a conversa com quem decide e com o órgão gestor.

O que ele não responde: dimensionamento de servidor para a carga real, política de backup, plano de atualização, suporte. Isso exige equipe de infraestrutura e o caminho formal. O post sobre o primeiro container não ser a arquitetura inteira lista o que separa um container rodando de um serviço operado.

Erros comuns

• Publicar a porta sem o 127.0.0.1: o sistema fica acessível para toda a rede do escritório, com a senha que está no README.
• Tentar fechar a porta com override: as listas de portas se somam no merge, e a publicação em todas as interfaces continua ativa.
• Confiar no ufw para bloquear porta do Docker: as regras que o Docker cria podem expor a porta mesmo com o firewall do host negando.
• Importar a base real para testar: processos com dados pessoais passam a existir numa máquina sem nenhum controle, o que é incidente de dados.
• Deixar o laboratório virar produção: sem backup, atualização e responsável, o primeiro disco que falha leva processos que tinham valor legal.
• Esquecer o ambiente ligado: meses depois, uma versão sem correções continua escutando na máquina.

Checklist

• A versão do sistema e a licença do repositório estão anotadas.
• Todos os mapeamentos de porta começam com 127.0.0.1:.
• ss -tlnp mostra a porta só em 127.0.0.1, e outra máquina da rede não abre a página.
• Todas as senhas padrão foram trocadas e estão num .env fora do Git.
• O banco contém só unidades, usuários e processos inventados.
• Existe data marcada para destruir o ambiente com docker compose down -v.
• As conclusões da avaliação foram registradas com a versão testada.

Abra agora o banco do seu ambiente de teste e procure por um CPF, um nome de servidor ou um número de processo verdadeiro. Existe algum dado ali que não foi inventado?