Postura e princípios de segurança

Cinco princípios atravessam cada decisão de design do PEART. Vale enunciá-los à parte, porque o resto desta seção é a aplicação deles.

Seguro por padrão, recusado quando inseguro

O PEART recusa configuração insegura em vez de cair num default conveniente. O config.example.yaml distribuído não roda como está: o token de renderização é um placeholder que o validador de configuração rejeita de saída, sem default que ele possa substituir em silêncio. Rodar sem TLS recusa subir a menos que o operador também ligue accept_insecure_http, então uma instalação em HTTP puro é sempre uma escolha explícita, nunca um acidente. Colocar a chave mestra dentro de um diretório de dados é recusado no boot, porque isso poria a chave no mesmo backup que os dados que ela protege. Uma configuração perigosa tem que ser pedida; ela nunca é o caminho de menor resistência.

Menor privilégio

Cada processo detém só o que precisa. O portal lê tudo o que o cliente vê por uma conexão em que o próprio driver do SQLite recusa escrita, e mantém uma segunda conexão, estreita, para as únicas linhas que ele escreve sobre si mesmo: a sessão, os registros de auditoria dele, a senha definida a partir de um convite e o segundo fator opcional. Nenhuma das duas carrega a chave mestra nem alcança o diretório de evidências. O renderizador de PDF roda sem rede, sem banco, sem chave e sem acesso a evidência, recebendo apenas um diretório de trabalho com o HTML já resolvido e devolvendo um PDF. O comprometimento de uma superfície não entrega os ativos que as outras detêm.

Defesa em profundidade

Nenhum controle isolado é tratado como suficiente. Conteúdo hostil é contido por separação de processos, uma Content-Security-Policy estrita, escape de saída por contexto e um dialeto restrito de Markdown, em camadas, para que uma falha em uma não seja, sozinha, uma brecha. Só o renderizador de PDF fica atrás de três camadas independentes, nenhuma delas confiável por si só.

Conteúdo hostil por padrão

Todo campo de texto é tratado como entrada hostil, inclusive os preenchidos por usuários de confiança. Um pentester registrando um payload de XSS ou de SQL injection como texto de achado está fazendo exatamente o trabalho, e o efeito desse conteúdo é indistinguível do de um atacante. O PEART armazena, exibe, exporta e imprime essas strings sem nunca executá-las, em todos os contextos de saída.

Limitação declarada acima de promessa vaga, relacionar acima de certificar

O PEART diz com todas as letras o que não protege, porque um produto de segurança que exagera nas garantias perde as que tem. E o mapeamento de conformidade relaciona um achado a um controle, nunca certifica conformidade. Os dois são o mesmo instinto: dizer exatamente o que é verdade, e deixar o leitor confiar porque não está inflado.