# Tecnisol Ponto — validação de segurança e saúde

**Data:** 31/10/2026. **Revisão:** 1.0. **Distribuição:** edição para revisão, sem inventário explorável do servidor. O relatório técnico detalhado possui download separado, restrito a administradores do WordPress.

## 1. Resultado executivo

O código e o serviço possuem controles relevantes de autenticação, autorização, isolamento e preservação de dados. Os testes funcionais e de permissões passaram. A recuperação de backup local foi demonstrada em ambiente isolado.

**A revisão também encontrou pendências prioritárias de infraestrutura e continuidade.** A análise das imagens retornou avisos altos/críticos, o acesso administrativo requer fortalecimento e ainda faltam confirmação de referência de hora, backup externo e redundância comprovada. Portanto, não se deve tratar a aprovação dos testes como liberação irrestrita de segurança ou adequação legal.

Não foi realizada uma investigação forense completa que permita afirmar ausência de comprometimento passado. Aviso de vulnerabilidade não comprova invasão; teste aprovado também não comprova impossibilidade de invasão futura.

## 2. Escopo e método

Foram combinados:

1. leitura das instruções, documentação e código de servidor/Android;
2. revisão de autenticação, permissões, banco, tratamento de entradas e saídas;
3. execução da suíte PostgreSQL e verificações de publicação;
4. verificações HTTPS do serviço publicado, sem sessão e sem dados reais em requisições de teste;
5. consulta de vulnerabilidades nas dependências Python e Android;
6. análise estática com revisão dos alertas;
7. inventário somente de leitura do host, rede, serviços e contêineres;
8. análise das imagens exatas dos serviços, incluindo componentes de outras aplicações da mesma VPS;
9. conferência do WordPress e do mecanismo de envio privado existente;
10. restauração do backup local em PostgreSQL descartável, sem rede externa.

Não foram realizados ataques de indisponibilidade, força bruta, exploração invasiva, leitura indiscriminada dos dados de funcionários ou alterações no sistema antigo. Esta é uma auditoria técnica interna datada, sem certificação independente.

## 3. Evidências principais

| Verificação | Resultado |
|---|---|
| Testes de servidor com PostgreSQL | **305 aprovados** |
| Verificação de migrações | Nenhuma alteração de modelo pendente |
| Consistência das dependências instaladas | Sem requisitos quebrados |
| Código local versus serviço | **187 arquivos Python coincidentes** |
| Segurança da configuração Django | Dois avisos conhecidos de escopo HSTS, sem erro impeditivo |
| Controles do serviço publicado | Autenticação, arquivos privados, API e isolamento aprovados; backup externo permanece pendente |
| Dependências Python fixadas | **19 consultadas**, sem avisos conhecidos nessa consulta |
| Dependências Android resolvidas | **73 consultadas**, sem avisos conhecidos nessa consulta |
| Análise estática do servidor | **29 alertas: 6 médios e 23 baixos; nenhum alto** |
| Resultados Android | **76 testes sem falhas/erros**, reutilizados pelo Gradle para fonte sem mudanças |
| Lint Android | Sem erros; **9 avisos e 1 indicação informativa** |
| Imagens distintas analisadas | **11**, com avisos em bibliotecas/pacotes/bins de base |
| Inventário de pacotes do host | Distribuição e pacotes reconhecidos; avisos requerem separar kernel em execução, versões instaladas e componentes não utilizados |
| Integridade do WordPress | Arquivos do núcleo conferidos contra checksums oficiais; arquivo adicional do empacotamento apontado para revisão |
| Restauração isolada | Aprovada, inclusive permissões, arquivos e integridade do diário |
| Distribuição dos documentos | 18 verificações HTTPS aprovadas, incluindo integridade e acesso restrito ao anexo; duas contas de teste removidas |

Os resultados de bibliotecas e de imagens têm escopos diferentes. A primeira consulta não inclui automaticamente todos os pacotes do sistema operacional, bibliotecas nativas, binários auxiliares ou componentes das demais aplicações.

## 4. Proteções implementadas e verificadas

### 4.1 Contas e autorização

| Ameaça | Controle constatado | Limite |
|---|---|---|
| Acesso sem autenticação a dados de RH | Bloqueio nas rotas e API | Deve ser preservado em novas rotas |
| Consulta de outro cliente por troca de identificador | Vínculo/contexto verificados e testes entre bancos | Não é isolamento físico de uma VPS |
| Escalada de perfil pelo cliente | Perfis conferidos no servidor; sem promoção global pelo formulário | Administração do host é outra fronteira |
| Compartilhamento indevido da sessão da gestão | Cookies/sessões separados | Higiene do navegador e do computador continua necessária |
| Uso abusivo de conta global | MFA obrigatório e suporte com confirmação nova | Não elimina risco de dispositivo comprometido |
| Acesso assistido sem autoria | Motivo, prazo, empresa e identidade real | Processo organizacional de revisão precisa ser formalizado |
| Recuperação cruzada de contas | Fluxos separados, tokens temporários e proteção de conta interna | E-mail transacional ainda não homologado |
| Tentativas repetidas de senha/fator | Limitadores e bloqueios aplicáveis | Não equivalem a proteção integral contra DDoS |

### 4.2 Entradas, uploads e saídas

O servidor utiliza ORM/valores parametrizados, validação de tipos/formatos e escape adequado de HTML/PDF/CSV. Entradas de escrita recusam marcação ativa e controles indevidos; senhas conservam a variedade de caracteres. SQL não é protegido por uma lista ingênua de palavras proibidas.

Há limites para tamanho/profundidade de JSON e para arquivos, expansão de planilhas e volume de relatórios. A importação possui prévia, confirmação vinculada, prazo, transação e revalidação. Fórmulas/macros/vínculos externos são recusados no fluxo examinado. O CSV neutraliza fórmulas na exportação.

Esses controles reduzem injeção, XSS, arquivos maliciosos e esgotamento por requisição. Não representam uma sandbox universal para qualquer formato ou um serviço antivírus de todos os arquivos da empresa.

### 4.3 Navegador e comunicação

No ponto: HTTPS, hosts restritos, DEBUG desligado, cookies protegidos, CSRF, políticas de conteúdo, bloqueio de incorreta interpretação de MIME e páginas autenticadas sem cache compartilhado. As páginas provisórias e o domínio público têm condições de confiança diferentes; o acesso definitivo com certificado publicamente reconhecido continua uma prioridade.

Dois avisos HSTS permanecem por não ampliar automaticamente a política a todos os subdomínios de infraestrutura compartilhada. Devem ser reavaliados com o domínio definitivo, considerando o impacto nos outros serviços.

### 4.4 Banco e processo de execução

Papel restrito de banco, manutenção fora do web, proteção dos originais/diário e assinaturas geradas em fluxo separado. O web não recebe pacotes/chaves de recuperação manual nem o volume SQLite legado. Aplicação sem root, filesystem somente leitura, sem capabilities e sem novos privilégios, com limites de recursos.

Banco e web do ponto não têm portas públicas próprias. O serviço interno é alcançado por proxies. Firewall e portas de contêiner precisam ser avaliados em conjunto: regras Docker podem não seguir a expectativa de um firewall de host isoladamente. [Documentação oficial Docker](https://docs.docker.com/engine/network/packet-filtering-firewalls/).

### 4.5 Android

Autorização específica por aparelho/empresa, segredo cifrado com Keystore, validação HTTPS normal, bloqueio de tráfego HTTP e de troca arbitrária de origem após o vínculo. Reenvio idempotente e conflito preservado. Backup automático do aplicativo desativado; atualização conserva a base local por migrações aditivas.

Os quatro dígitos são identificação operacional, não autenticação forte. Permanecem riscos de marcação por outra pessoa, acesso físico ao aparelho, Android desatualizado, perda do tablet e uso sem gerenciamento adequado. A proteção de sessão não significa cifragem adicional de toda a fila Room.

## 5. Revisão dos alertas de análise estática

| Grupo | Avaliação |
|---|---|
| Chave de desenvolvimento | Caminho de DEBUG; configuração de produção recusa chave ausente/curta |
| Uso de subprocesso | Rotina de manutenção com lista de argumentos; não foi identificado shell com comando livre do navegador |
| SQL dinâmico em importação/ponte | Nomes controlados/allowlist e valores parametrizados no escopo examinado |
| Consulta externa de feriados | Origem HTTPS fixa e parâmetros/volume limitados; acompanhar dependência externa |
| Importação XML/PDF | Alertas ligados a exceção/escape; parser efetivo protegido no fluxo revisado |
| Assertions em comando de ensaio | Verificações auxiliares podem desaparecer em Python otimizado; não são autorização das rotas de produção |

Não foram suprimidos alertas para produzir uma contagem artificialmente limpa. As conclusões têm validade para o código examinado; novos caminhos ou mudanças exigem nova revisão.

## 6. Imagens: interpretação correta dos avisos

Os avisos incluem pacotes de sistema, bibliotecas, ferramentas e componentes que podem não estar no caminho de atendimento externo. A mesma CVE pode aparecer em vários pacotes/imagens. Contagem bruta não é quantidade de ataques comprovados nem medida direta de explorabilidade.

A triagem precisa considerar versão corrigida pelo fornecedor, arquitetura, uso efetivo, exposição e mitigação. Alguns avisos de kernel encontrados em arquivos de desenvolvimento de uma imagem não significam que aquele contêiner execute um kernel próprio. Binários auxiliares também não devem ser confundidos com o serviço principal de banco.

Mesmo com essas ressalvas, os resultados justificam um plano prioritário de atualização das bases/imagens. Fixar digest garante repetibilidade da imagem selecionada; não mantém essa imagem automaticamente atualizada.

O anexo restrito conserva imagens, versões, classes de avisos e prioridades. As imagens dos outros serviços foram analisadas como superfície compartilhada, sem alteração de seus repositórios ou publicação de atualizações.

## 7. Saúde e continuidade do servidor

Na amostra coletada, havia espaço livre de disco e memória disponível, sem evidência de saturação sustentada. Aproximadamente 20% do disco raiz e 7% dos inodes estavam utilizados. Isso não constitui teste de carga ou dimensionamento comercial.

Os serviços principais examinados estavam respondendo. Existe unidade de verificação de referência de hora com falha e indicação de reinicialização necessária após atualizações. A reinicialização deve ser planejada porque o host atende várias aplicações.

Atualizações automáticas do sistema estavam ativas. A lista local recente de pacotes não apresentava atualização pendente; isso não equivale a ausência de CVEs nem à ativação de um kernel já instalado que ainda dependa de reboot.

## 8. Pendências e prioridades

| ID | Prioridade | Trabalho necessário | Critério de conclusão |
|---|---|---|---|
| S01 | Alta | Atualizar/mitigar imagens e componentes após triagem | Nova consulta e verificação das versões corrigidas |
| S02 | Alta | Fortalecer o acesso administrativo ao host | Acesso alternativo testado e política mínima validada |
| S03 | Alta | Implantar backup externo protegido | Envio confirmado e restauração fora da origem local |
| S04 | Alta para operação de ponto | Comprovar a referência de hora | Medições válidas, falhas tratadas e acompanhamento |
| S05 | Alta antes da operação final | Comprovar redundância/disponibilidade | Falhas e recuperação ensaiadas |
| S06 | Planejar manutenção | Ativar atualizações que dependem de reboot | Janela coordenada e serviços conferidos após retorno |
| S07 | Alta antes de acesso comercial | Concluir domínio/HTTPS definitivo | Certificado validado sem exceção manual |
| S08 | Média | Reforçar administração/controles do WordPress | Revisão de autenticação, superfície e políticas |
| S09 | Média | Formalizar alertas, resposta a incidentes e revisão de acessos | Canal real e exercício registrado |
| S10 | Média | Avaliar proteção de dados em repouso e aparelhos | Riscos, responsabilidades e medidas documentados |
| S11 | Média | Formalizar retenção, contratos e direitos LGPD | Procedimentos aprovados e implementados |
| S12 | Próxima validação | Testes independentes de intrusão e de campo | Escopo acordado e achados tratados |

Nenhuma alteração de SSH, firewall, base produtiva ou reinicialização do host foi feita como consequência automática deste diagnóstico. Os ajustes desta entrega se restringem às ferramentas de auditoria/documentação e à publicação autorizada dos materiais.

## 9. O que ainda não foi demonstrado

- Ausência de comprometimento anterior por investigação forense completa.
- Proteção integral contra ataque volumétrico/DDoS no provedor.
- Segurança física da hospedagem e controles internos do provedor.
- Cifragem integral de todos os dados e volumes da infraestrutura.
- Pentest independente, cobertura exaustiva de todos os caminhos ou capacidade de carga máxima.
- Auditoria completa do código dos demais produtos da VPS.
- Backup externo, failover ou disponibilidade contratada já operando.
- Instalação/atualização e validação física dos dois tablets atuais.
- Adequação organizacional e trabalhista completa apenas pela aprovação dos testes.

## 10. Plano de manutenção proposto

1. Tratar S01–S02 com a equipe responsável, sem bloquear o acesso administrativo legítimo.
2. Concluir o destino externo e validar a recuperação; proteger chaves fora da VPS.
3. Coordenar as atualizações/reboot dos serviços compartilhados com retorno verificável.
4. Resolver referência de hora e arquitetura de continuidade antes da liberação final do ponto.
5. Formalizar donos, prazos, alertas e revisões recorrentes.
6. Repetir a validação após as correções, vinculando o resultado às versões efetivamente publicadas.

O [guia de segurança da ANPD](https://www.gov.br/anpd/pt-br/centrais-de-conteudo/materiais-educativos-e-publicacoes/guia-vf.pdf) serve de apoio à organização das medidas administrativas e técnicas; a implantação deve ser comprovada, não apenas descrita.

## 11. Apontamentos

> ID do achado:  
> Minha decisão:  
> Responsável:  
> Prazo de trabalho:  
> Dependências:  
> Critério de aceite:  
> Evidência de conclusão: