Segurança

Num relance

• A mesma proteção em todos os planos

  Todos os planos têm a mesma criptografia e o mesmo isolamento. Os planos superiores acrescentam controle, não segurança.

• Criptografado em repouso

  Os volumes do PostgreSQL, os objetos no R2 e os backups são criptografados em repouso pelos provedores. Os dados enviados, o HTML, os PDFs e as versões em Markdown dos relatórios são criptografados de novo com uma chave de dados por espaço de trabalho antes de ir para o armazenamento; apagar um espaço de trabalho destrói a chave.

• Criptografado em trânsito

  TLS 1.2 ou superior em todos os endpoints públicos; HSTS; o tráfego interno entre a aplicação e o plano de renderização fica na rede privada da Railway e é autenticado com um HMAC.

• Hospedagem na UE

  A aplicação, o banco de dados, os workers e o plano de renderização rodam na região EU West da Railway (Amsterdã); dados enviados, HTML, PDFs e versões em Markdown ficam no Cloudflare R2 com a restrição de jurisdição da UE. A região é uma propriedade do seu espaço de trabalho; hoje só a região da UE está ativa.

• Segurança em nível de linha

  Cada tabela de clientes leva o id do espaço de trabalho, e a segurança em nível de linha do PostgreSQL é imposta nela. O serviço web se conecta com um papel que não consegue contorná-la, e toda a suíte de testes roda uma segunda vez com esse papel.

• Versões de modelo imutáveis

  Publicar cria uma versão só de acréscimo, presa a um hash do conteúdo do kit; triggers do banco recusam alterações em versões publicadas. Os relatórios ficam ligados a uma versão, e o HTML e o PDF são congelados na renderização, com seus hashes guardados no relatório.

• Nenhum código de cliente é executado

  Um modelo é JSON validado contra um esquema. O plano de renderização o interpreta com um kit fixo de widgets; o Chromium roda com JavaScript desligado e com toda requisição de rede bloqueada. O plano de renderização não tem banco de dados, nem bucket, nem segredos além da chave HMAC.

• Um DPA para cada cliente

  A descrição do tratamento, as medidas técnicas e organizacionais e a lista de suboperadores são anexos. Comprometemo-nos a avisar você de uma violação de dados pessoais em até 48 horas depois de tomarmos conhecimento dela.

• Links assinados e relatórios privados no Pro

  URLs assinadas dão acesso por tempo limitado sem um link compartilhável; relatórios privados abrem só para membros do espaço de trabalho com login. O modo sem retenção, no Pro, apaga cada relatório um tempo definido depois que ele fica pronto.

• Todo PDF pode ser conferido

  A partir do Standard, a impressão digital de cada PDF real é registrada quando ele é gerado. Qualquer pessoa pode conferir uma cópia na página de verificação: o arquivo é processado no navegador dela e nunca é enviado. Os registros não guardam conteúdo do relatório e ficam guardados por 10 anos.

• Ainda sem BAA da HIPAA

  Não envie à Pressfox informações de saúde protegidas pela lei dos EUA. Dados de saúde sob o GDPR (art. 9) podem ser tratados conforme o DPA quando a sua própria base legal os cobrir.

1. A arquitetura em um parágrafo

Três partes implantáveis. Um plano de controle em Django cuida de contas, espaços de trabalho, modelos, relatórios, cobrança e da API pública. Um plano de renderização privado em Node recebe um documento validado, os dados e um tema, gera o HTML, imprime em PDF com o Chromium e devolve os dois; ele não guarda nada e não acessa nada. Um app React estático é o painel e o editor. Cada tabela de clientes leva o id do espaço de trabalho, e a segurança em nível de linha do PostgreSQL reforça o isolamento que a própria aplicação aplica, então um erro numa consulta não consegue vazar linhas de outro espaço de trabalho.

2. Infraestrutura e provedores

A aplicação, o banco de dados PostgreSQL, os workers em segundo plano e o plano de renderização rodam na Railway, na região EU West (Amsterdã). O Cloudflare fornece DNS, TLS, a CDN, os hostnames personalizados para relatórios no seu próprio domínio e o armazenamento de objetos R2 com a restrição de jurisdição da UE. A Paddle cuida dos pagamentos como revendedora (merchant of record). A Resend envia e-mails a partir da sua região de envio na UE (Irlanda). O Sentry recebe relatórios de erro na sua região da UE (Frankfurt), com o conteúdo dos dados removido. A Anthropic processa texto para os recursos opcionais de IA. O Google só é usado quando você escolhe entrar com o Google. A produção roda separada do ambiente de homologação.

A página de suboperadores (em inglês) é a lista única e oficial: o que cada provedor faz, onde, com qual mecanismo de transferência, e o aviso que damos antes de incluir um novo.

3. Criptografia e chaves

• Os dados enviados, o HTML, os PDFs e as versões em Markdown dos relatórios são criptografados com uma chave de dados por espaço de trabalho antes de ir para o armazenamento de objetos. Apagar um espaço de trabalho destrói a chave dele.
• TLS 1.2 ou superior em todos os endpoints públicos, com HSTS. A aplicação e o plano de renderização conversam pela rede privada da Railway, e cada requisição entre eles é autenticada com um HMAC.
• As chaves de API são por espaço de trabalho, com o prefixo pf_live_ ou pf_test_, mostradas uma vez, guardadas com hash e revogáveis a qualquer momento. Chaves de teste geram relatórios com marca d'água e sem cobrança.
• As senhas de relatório são guardadas com hash, nunca em texto puro.
• As senhas de PDF são usadas uma vez, para criptografar o arquivo, e apagadas junto com os dados enviados quando o relatório fica pronto; não conseguimos recuperá-las. A senha de permissões é aleatória para cada relatório e descartada, então ninguém consegue mudar as permissões de um PDF depois.
• Só identificadores públicos: as chaves internas nunca saem do banco de dados. Os links de relatório usam um token aleatório separado, que não deriva do id do relatório.

4. Isolamento dos espaços de trabalho e papéis

• Cada tabela de clientes leva o id do espaço de trabalho, e a segurança em nível de linha do PostgreSQL é imposta nela, então o próprio banco recusa linhas de outro espaço de trabalho.
• O serviço web se conecta ao banco com um papel que não consegue contornar a segurança em nível de linha.
• Na integração contínua, a suíte completa de testes roda uma segunda vez com esse papel, então uma consulta que só funciona contornando as políticas quebra o build.
• Quatro papéis (proprietário, administrador, editor, leitor) correspondem a uma única matriz de permissões; cada endpoint da API é conferido pelo mesmo mecanismo.

5. Login e sessões

• Sem senhas. Você entra com um código de uso único enviado por e-mail, ou com o Google. Três tentativas erradas invalidam o código, e você pede um novo.
• Um novo cadastro fica pendente até o código ser confirmado, então ninguém cria uma conta com um endereço que não controla.
• Os pedidos de login e de código têm limite de frequência.
• As sessões ficam no servidor. Uma sessão termina depois de 7 dias sem uso e depois de 30 dias no máximo.
• Sua conta lista as suas sessões ativas, para você sair de outros dispositivos.
• Enviamos um e-mail quando a sua conta entra a partir de um dispositivo novo.

6. O plano de renderização

Nenhum código de cliente roda. Um modelo é JSON validado contra um esquema, interpretado pelo plano de renderização com um kit fixo de widgets. O Chromium o imprime com JavaScript desligado e com toda requisição de rede bloqueada. Cada renderização tem prazos, então uma tarefa travada é interrompida em vez de ficar rodando. O plano de renderização só é acessível pela rede privada: ele não tem endereço público, nem banco de dados, nem bucket, nem segredos além da chave HMAC.

7. Os dados que você envia

• Todos os dados enviados são validados contra o contrato do modelo antes de qualquer renderização; dados que não batem são recusados.
• O material de que um relatório é feito, os dados enviados e as imagens buscadas nas suas URLs, é apagado assim que o relatório fica pronto, ou 24 horas depois de uma renderização que falhou.
• As imagens são buscadas nas suas URLs atrás de uma proteção contra falsificação de requisições do lado do servidor (SSRF): o endereço é conferido, e a conexão fica presa ao endereço conferido.
• Os metadados das fotos, incluindo a localização GPS, são removidos das versões impressas das suas imagens.
• A versão em Markdown de um relatório é gerada por código a partir do próprio relatório, não por IA.
• As propriedades de um PDF trazem só o título, o nome do emissor e identificadores públicos: nunca outros dados que você enviou, nem os nomes ou versões das ferramentas que o geraram.

8. Acesso aos relatórios

Por relatório, na criação: link aberto (token impossível de adivinhar), senha, data de validade e, no Pro, URLs assinadas e relatórios privados. A partir do Standard, o próprio PDF também pode abrir só com uma senha: AES-256, definida por relatório ou tirada de um campo dos dados; o leitor continua podendo imprimir, copiar e usar um leitor de tela. A tela de senha bloqueia depois de tentativas erradas repetidas. Os QR codes são assinados por relatório. As páginas hospedadas não gravam cookies de rastreamento; o único cookie é o da tela de senha, restrito ao hostname do relatório. A personalização por espaço de trabalho das páginas de erro, de expiração e de senha ainda não está pronta; hoje elas levam o nome da Pressfox.

9. Verificar um documento

• A partir do Standard, o PDF de cada relatório real recebe um registro de verificação quando fica pronto: a impressão digital SHA-256, o nome do emissor e a hora da emissão e, depois, se uma correção o substituiu ou o emissor o revogou. Relatórios de teste e relatórios no modo sem retenção não recebem nenhum.
• Quem tiver o PDF pode conferi-lo na página de verificação, em app.pressfox.io/verify ou em /verify no seu próprio endereço de relatórios. O navegador calcula a impressão digital; o arquivo nunca é enviado. A resposta é autêntico (quem o emitiu e quando), substituído, revogado com o motivo do emissor, ou não encontrado.
• Quando o seu espaço de trabalho tem o próprio endereço de relatórios, cada PDF imprime uma linha dizendo onde conferi-lo: nesse endereço, nunca no nosso. Ali, a página responde só pelos documentos do seu espaço de trabalho.
• Não encontrado significa que a Pressfox não emitiu o arquivo, ou que ele mudou depois de emitido: anotar ou salvar de novo um PDF muda a impressão digital. Uma cópia assinada no seu provedor de assinatura é um arquivo novo; confira a cópia emitida pela Pressfox.
• Um registro não guarda título, dados nem etiquetas, então sobrevive ao relatório: fica guardado por 10 anos e é apagado com o espaço de trabalho. As consultas têm limites na borda da rede e por endereço, sem captcha e sem cookies. A verificação prova que um arquivo não mudou desde que foi emitido; não é uma assinatura nem um selo eletrônico.

10. Webhooks e a API

• Cada entrega de webhook é assinada segundo a especificação Standard Webhooks, para que o seu endpoint confira que veio de nós e não foi alterada; o horário assinado permite recusar entregas antigas.
• As entregas que falham são tentadas de novo numa escala de 1 minuto a 24 horas. Um endpoint que falha por 3 dias sem nenhum sucesso é desativado automaticamente; o app mostra quando e por quê ao lado dele, e o registro de auditoria anota. Depois de corrigido o receptor, um proprietário ou administrador reativa o endpoint com um clique, mantendo a URL e o segredo de assinatura. Isso zera a contagem de falhas, começa um novo prazo de 3 dias e fica no registro de auditoria; os eventos perdidos enquanto ele esteve desativado podem ser reenviados a partir das entregas dele.
• Os endpoints de webhook passam pela mesma proteção contra SSRF da busca de imagens, presos ao endereço conferido, então um webhook não pode apontar para endereços internos.
• A API aceita chaves de idempotência, então uma requisição repetida depois de um timeout não cria um segundo relatório.
• A API tem limite de requisições por chave de API e por espaço de trabalho, em janelas de um minuto: 600 requisições por minuto por chave, das quais 120 podem criar relatórios, e 1.200 requisições (240 criações de relatório) por minuto somando todas as chaves de um espaço de trabalho, de teste e reais juntas. Uma requisição acima de um limite é recusada com HTTP 429 e um cabeçalho Retry-After; toda resposta contada traz RateLimit-Limit, RateLimit-Remaining e RateLimit-Reset. Veja rate_limited (em inglês).
• O login, o assistente de IA, o Playground, as importações de modelo e a tela de senha dos relatórios hospedados também têm limite de frequência.

11. Recursos de IA e agentes de IA

Os recursos de IA da Pressfox são opcionais e trabalham só com texto, nunca com imagens: rascunhos das traduções de um modelo, tradução dos campos de texto que você marcar no relatório, resumos nos relatórios, o assistente do editor e a montagem de um rascunho de modelo a partir de um PDF que você enviar (só o texto; o próprio PDF é apagado em até 24 horas). Um relatório renderizado nunca chama um modelo de IA: as traduções do modelo são revisadas e congeladas quando você publica, e o texto de IA que entra num relatório é escrito uma vez, antes da impressão, e apagado junto com os outros insumos do relatório quando ele fica pronto. Só os campos marcados de um relatório são enviados; o texto vai como dado, nunca como instrução, e é conferido antes do uso (marcadores, formatação e números precisam sobreviver). Esse texto é processado pela Anthropic nos Estados Unidos, conforme o DPA dela e as Cláusulas Contratuais Padrão, e não é usado para treinar modelos; relatórios, dados enviados e PDFs ficam na UE. Os recursos de IA ficam desligados em espaços de trabalho de saúde.

Agentes de IA podem se conectar à Pressfox via MCP. Você autoriza cada um numa tela de consentimento OAuth; um agente conectado pode encontrar modelos e criar, ler e compartilhar relatórios (ele não pode apagar relatórios, mudar modelos nem mexer em membros, chaves ou cobrança), e você pode desconectá-lo a qualquer momento. O MCP está em prévia: ligamos para um espaço de trabalho quando pedido.

12. Acesso da equipe

Não há painel administrativo em produção; as operações passam pelo console autenticado do provedor de hospedagem e por comandos de gestão auditados. Hoje só o fundador tem acesso à produção.

13. Pagamentos

A Paddle é a nossa revendedora (merchant of record): ela cuida do checkout, das faturas, dos impostos e dos reembolsos. Os dados do cartão vão para a Paddle; nós nunca recebemos números de cartão.

14. Registros, monitoramento e auditoria

• Os registros levam ids de requisição, nunca o conteúdo dos dados enviados. Um teste automático de redação de registros no build comprova isso.
• Os erros vão para o Sentry na UE (Frankfurt), com o conteúdo dos dados removido.
• Um registro de auditoria só de acréscimo anota logins, mudanças de papel, criação e revogação de chaves de API, publicações e exclusões de modelos. Ele é guardado por 1 ano em todos os planos e por 2 anos no Pro e no Enterprise, onde proprietários e administradores também podem baixá-lo em CSV ou NDJSON.

15. Backups e recuperação

O banco de dados tem recuperação para um ponto no tempo: podemos restaurá-lo para qualquer minuto das últimas 4 semanas. Os backups são criptografados em repouso. Vamos ensaiar uma restauração a cada trimestre, a primeira antes do lançamento geral. A meta é voltar em até 4 horas e perder no máximo 15 minutos de alterações; publicamos os tempos medidos quando um ensaio os registrar. As exclusões e as revogações (espaços de trabalho, relatórios, arquivos, chaves de API, links de relatórios, envios, convites e membros) são registradas fora do banco de dados, e o nosso procedimento de restauração reaplica as registradas desde o ponto de restauração antes de reabrirmos o serviço.

16. Retenção e exclusão

Nos planos pagos, os relatórios hospedados, os seus PDFs e os seus links ficam guardados enquanto a assinatura estiver ativa e por 30 dias depois que ela terminar, e depois são apagados. No Free, ficam guardados por 7 dias; no Enterprise, conforme o contrato. Um proprietário pode definir um prazo menor para o espaço de trabalho, e uma integração para um relatório. Cada relatório mantém o prazo com que foi criado: trocar entre planos pagos nunca o encurta. O armazenamento de relatórios tem um limite por plano; no limite, novos relatórios são recusados, e nada é apagado para abrir espaço. Relatórios de teste ficam guardados por 24 horas em todos os planos. O material de origem sai antes: os dados enviados e as imagens buscadas nas suas URLs são apagados assim que o relatório fica pronto, e 24 horas depois de uma renderização que falhou. A exclusão de um relatório ou de um espaço de trabalho chega ao banco de dados, ao armazenamento de objetos, ao cache da CDN e aos arquivos temporários do plano de renderização. Um espaço de trabalho excluído pode ser restaurado por 30 dias; depois apagamos os seus dados e destruímos a sua chave de criptografia. Os backups do banco de dados ainda podem guardar essa chave por no máximo 35 dias a mais; o sistema foi projetado para que, quando eles expirarem, os dados não possam mais ser decifrados, nem por nós nem por ninguém. A exportação do espaço de trabalho gera um arquivo legível por máquina com modelos, versões, perfis de marca, relatórios e metadados.

17. Modo sem retenção

No Pro e no Enterprise, um proprietário pode ligar o modo sem retenção para o espaço de trabalho, e uma integração pode pedi-lo para um relatório. Um relatório feito assim é apagado um tempo definido depois que fica pronto: entre 5 minutos e 24 horas, 1 hora se você não escolher outro.

Os dados que você envia são apagados assim que o relatório fica pronto, e na hora se a renderização falhar. As páginas e o PDF ficam num armazenamento à parte que apaga tudo em até dois dias, mesmo que o nosso próprio processo de exclusão falhe.

Busque o relatório dentro desse prazo: por webhook e depois um download com a sua chave de API, ou com um link assinado. Depois disso, a API responde que o prazo terminou. Excluir o relatório pela API encerra o prazo antes.

Os recursos que guardam dados ou os enviam para outro lugar ficam desligados neste modo: links abertos (os relatórios usam links assinados), compartilhamento por e-mail, tradução e resumos com IA, e formulários preenchidos pela metade. O título do relatório vem da sua requisição, ou do nome do modelo e da data, nunca dos dados.

Se o espaço de trabalho passar para um plano sem este modo, ele continua ligado até um proprietário desligá-lo. Ele limita o que guardamos; não muda o nosso papel: enquanto renderizamos um relatório, continuamos tratando os dados dele, como seu operador conforme o DPA.

18. Resposta a incidentes

Quando algo dá errado, seguimos cinco etapas:

1. Conter o problema e preservar as evidências.
2. Descobrir o alcance: quais espaços de trabalho, quais dados, desde quando.
3. Trocar as chaves e os segredos que possam ter sido afetados.
4. Avisar os clientes afetados em até 48 horas depois de tomarmos conhecimento de uma violação de dados pessoais, como o DPA (em inglês) estabelece, e as autoridades quando a lei exigir.
5. Corrigir a causa e registrar o ocorrido.

19. A sua parte

A segurança é compartilhada. Do seu lado:

• Guarde as chaves de API num cofre de segredos, nunca no código nem no navegador, e use chaves de teste em desenvolvimento.
• Escolha a política de acesso certa para cada relatório: uma senha, uma data de validade, ou URLs assinadas para qualquer coisa sensível.
• Fixe versões de modelo em produção, para que uma publicação nunca mude um relatório que os seus sistemas enviam.
• Confira a assinatura de cada webhook antes de confiar nele.
• Remova os membros que saem da sua equipe e troque qualquer chave de API que eles possam ter visto.
• Não envie informações de saúde protegidas pela lei dos EUA: não assinamos um acordo de associado comercial da HIPAA.

20. Divulgação responsável

Se você encontrar uma vulnerabilidade, conte para nós. Escreva para hello@pressfox.io com o assunto "Relato de segurança", com detalhes suficientes para reproduzirmos. Confirmamos o recebimento em até 2 dias úteis. Não há recompensa em dinheiro; se você quiser, agradecemos pelo nome nesta página.

No escopo: pressfox.io, app.pressfox.io, api.pressfox.io, reports.pressfox.io, *.pressfox.app, a API e o servidor MCP.

Fora do escopo: a própria Paddle, o Cloudflare e o Google (relate a eles); negação de serviço; spam; engenharia social; ataques físicos; e dados de outros clientes.

Regras: teste só no seu próprio espaço de trabalho. Se chegar a dados de outra pessoa, pare, não os guarde e nos avise.

Porto seguro: não processamos nem denunciamos pesquisadores que agem de boa-fé dentro destas regras. Nossos contatos também estão publicados em /.well-known/security.txt (RFC 9116).

21. Certificações

Nenhuma ainda. A Pressfox não tem relatório SOC 2, nem certificado ISO 27001, nem acordo de associado comercial da HIPAA. Nossos provedores têm certificações próprias; elas são deles, não nossas, e não as reivindicamos.

22. O que ainda não temos, dito com clareza

• Ainda sem segundo fator no login.
• Sem CAPTCHA nos formulários públicos; limites de frequência e cadastros pendentes cuidam dos abusos hoje.
• Ainda sem cabeçalho Content-Security-Policy.
• Nenhum teste de intrusão externo concluído ainda; um está planejado antes do lançamento geral, e vamos publicar o resumo.
• Ainda sem página pública de status.
• Sem relatório SOC 2 e sem certificado ISO 27001.
• Ainda sem armazenamento dedicado, sem chaves de criptografia gerenciadas pelo cliente e sem armazenamento no seu próprio bucket. São opções do Enterprise que conversamos sob consulta.
• Nenhuma região além da UE. Outras regiões virão quando um cliente precisar, com armazenamento por região.
• Sem acordo de associado comercial da HIPAA e sem região dedicada à saúde.
• Ainda sem login único (SAML); só código por e-mail e Google.
• Localizada na UE, não soberana na UE: nossos provedores de hospedagem são empresas americanas com planos de controle globais, vinculadas por Cláusulas Contratuais Padrão.

23. Histórico de versões