Ir para o conteúdo

Segurança e conformidade

O PEART guarda, num único lugar, a lista consolidada das vulnerabilidades ainda não corrigidas dos clientes de uma consultoria, com passo a passo de exploração e evidências que frequentemente contêm credenciais, tokens e dados pessoais. Parte disso fica exposta à internet por decisão de produto, porque o cliente acessa o portal. Isso faz do PEART um dos alvos mais valiosos que uma consultoria de segurança pode hospedar, e define o padrão de como o próprio produto é construído.

Esta seção é escrita para quem avalia isso: auditores, DPOs e operadores atentos à segurança. Ela destila a documentação normativa de segurança do projeto (docs/security.md e os registros de decisão de arquitetura) num relato voltado ao leitor. Onde uma afirmação importa, ela aponta para a fonte autoritativa em vez de repeti-la, para que as duas nunca divirjam.

O princípio que esta seção mantém

Duas disciplinas governam tudo aqui.

Limitação declarada vale mais que promessa vaga. O PEART diz com clareza o que não protege, porque um produto de segurança que exagera nas garantias perde as que de fato tem. O exemplo mais claro é o banco de dados: ele fica em texto claro por uma decisão deliberada e documentada, com cifragem de disco no host como controle compensatório. Isso está escrito, não escondido, e esta seção reflete exatamente isso.

Relacionar, não certificar. O mapeamento de conformidade diz que um achado se relaciona ao controle X do framework Y. Nunca diz que um achado prova não-conformidade. Quem conclui é o auditor; a ferramenta entrega o mapa correlacional que o auditor montaria na mão.

Modelo de ameaça, em resumo

O modelo de ameaça completo está em docs/security.md. Dois pontos enquadram o resto desta seção.

Os ativos mais valiosos, em ordem, são as evidências (prints e capturas que carregam credenciais, tokens e dados pessoais), o passo a passo de exploração contra sistemas ainda em produção, e o catálogo de achados abertos (saber quais sistemas de quem estão vulneráveis, e desde quando, já é acionável). Chaves de cifragem e credenciais de conta ficam abaixo desses, e a disponibilidade abaixo ainda: uma indisponibilidade é um transtorno, um vazamento é o fim da consultoria.

A fronteira de confiança principal não é entre autenticado e anônimo. É entre a superfície do portal e a superfície interna. Comprometer o peart-portal não pode entregar a chave de cifragem, a evidência original, campos internos nem escrita no conteúdo do relatório. O portal roda como processo separado, nunca detém a chave mestra e não lê o diretório de evidências; ele serve toda leitura que o cliente vê por uma conexão em que o driver do SQLite recusa escrita, e alcança as poucas linhas que escreve sobre si mesmo, a sessão, os registros de auditoria dele e a própria credencial, por uma segunda conexão estreitada por interface. A fronteira que o produto deliberadamente não defende é o operador do host, confiado por desenho, com a trilha de auditoria como único controle; isso também está declarado abertamente.

Nesta seção