A tua contabilidade. Bem trancada.
Sem teatro de SOC 2. Sem "encriptação ao nível de um banco" em letras a 60 pontos. Esta página explica, por palavras simples, o que fazemos mesmo com os teus dados, onde vivem, e aquilo a que ainda não chegámos.
Seis coisas, bem feitas.
Em vez de uma parede de logótipos, aqui está o que acontece aos teus dados desde o momento em que saem do teu browser até ao momento em que os restauramos às 3 da manhã de uma terça-feira.
Encriptado entre o teu browser e o nosso.
Tudo o que sai da tua máquina viaja sobre TLS 1.3. Estamos na lista de HSTS preload, por isso até um bookmark que escreveste em 2019 é promovido para https antes de a ligação sequer abrir. Os certificados rodam automaticamente de 60 em 60 dias através do Let's Encrypt. As nossas cipher suites são as que a Mozilla classifica de 'modern', e cortámos o TLS 1.1 em 2023.
Encriptado em disco. Chaves por tenant.
As tuas faturas, clientes, anexos, e entradas de tempo são encriptadas com AES-256 antes de tocarem na base de dados. Cada workspace tem a sua própria chave, derivada de uma chave-mestra que vive no AWS KMS. Se uma imagem de disco vazasse, o atacante ficava com ciphertext e um encolher de ombros.
Bruno. De propósito, quando pedires.
Três pessoas têm acesso a produção: Bruno, Marta (ops), e Carl (on-call de backup). Cada acesso fica registado, assinado, e enviado por email aos outros dois. Se abrires um ticket de suporte e for preciso olharmos para o teu workspace, pedimos primeiro, no ticket, por escrito. Podes dizer que não. A maioria dos problemas não precisa mesmo que olhemos.
Diários, encriptados, em duas regiões.
As bases de dados fazem snapshot de 6 em 6 horas, o armazenamento de ficheiros replica continuamente. Os backups vão parar a us-east-1 e eu-central-1, encriptados com chaves que não são usadas para mais nada. Na segunda terça-feira de cada mês restauramos a base de dados de produção num ambiente vazio a partir de cold storage. Se não arrancar, não saímos de lá até arrancar.
Hetzner para computação. AWS para armazenamento.
O Gingerbread (alojado) corre em servidores dedicados da Hetzner em Falkenstein e Helsinki. Escolhemos a Hetzner porque é barata, rápida, e gerida por engenheiros e não por MBAs. O armazenamento a longo prazo, os backups, e a camada de secrets vivem na AWS, porque há coisas que queremos aborrecidamente conservadoras. A residência dos dados é UE por defeito, ou EUA se escolheres essa região no registo.
Equipa pequena, dependências sossegadas.
O Gingerbread tem cerca de 54k linhas de PHP e 18k linhas de TypeScript. Dependemos de 31 pacotes npm diretos e 22 pacotes composer. Lemos cada changelog antes de subir uma versão. O Dependabot abre PRs, nós fazemos merge, o CI corre um Semgrep, o Playwright volta a correr os testes dos fluxos críticos, e fazemos release.
O que ainda não fizemos.
Todas as outras páginas de segurança fingem que isto não existe. Preferimos que saibas à partida, para decidires.
Sem relatório SOC 2.
A chegar no final de 2026Gastaríamos $50k por ano para que três empregados de um banco grande o pudessem ignorar. Quando chegarmos a 500 clientes empresariais, começamos o Type I. Se precisares da carta entretanto, manda um email. Trabalhamos contigo.
Sem BAA do HIPAA.
Não planeadoO Gingerbread não foi feito para dados de saúde protegidos. Se és terapeuta a faturar sessões, tudo bem. Se estás a guardar notas de diagnóstico em campos de cliente, por favor não o faças.
Ainda sem SSO/SAML.
Em stagingO 2FA normal funciona. O SAML está construído e parado em staging. Sai quando encontrarmos cinco clientes que o queiram mesmo. Se és um deles, responde a qualquer email.
Ainda sem bug bounty.
Ad-hoc por agoraPagamos aos investigadores caso a caso através do formulário de report. Um programa a sério está na lista quando tivermos folga para triar. Em 2025 pagámos $8.400 em 11 relatórios.
O registo todo. Sem cortes.
Cada incidente, simulacro, e patch de dependência que vale a pena mencionar desde que começámos a publicar este registo em março de 2024.
Subscreve o feed (em breve)Base de dados de produção restaurada num ambiente vazio a partir de cold storage. 2h 14m, arranque limpo.
Dependência atualizada 6 horas depois do advisory. Sem exposição no nosso uploader, corrigido preventivamente.
Oscilação na rede da Hetzner. O tráfego fez failover para Helsinki automaticamente. Downtime total visível para o utilizador: 47 minutos nos workspaces da UE.
Reportado pelo formulário, triado em 40 min, corrigido em 18 horas. $1.200 pagos ao investigador. Postmortem publicado.
Revisão completa de dependências, 4 dependências transitivas removidas, sem achados.
Rodámos a chave-mestra por workspace. Impacto zero para clientes, ~3 min de tail latency elevada.
O que guardamos, onde, e por quanto tempo.
Sem dark patterns. Se quiseres apagar alguma linha, manda-nos um email e confirmamos por escrito assim que desaparecer.
| O quê | Onde vive | Guardado por | Quem vê |
|---|---|---|---|
| Dados do negócio (faturas, clientes, tarefas, tempo) | Encriptado na DB do teu workspace | Até apagares, ou 30 dias depois do fecho da conta | Tu. A tua equipa. Nós só com consentimento no ticket. |
| Anexos | S3, SSE-KMS, prefixo de bucket por workspace | Igual aos dados do negócio | Igual. Nunca indexado, analisado, ou usado para ML. |
| Dados de pagamento | Nunca toca nos nossos servidores. A Stripe tokeniza no browser. | Política da Stripe. Não nossa. | Vemos os últimos quatro dígitos, a marca, e a validade. Mais nada. |
| Emails e tickets de suporte | Fastmail (UE), separado da DB do produto | 3 anos, depois arquivado | Bruno, Marta. Apagado ao fim de 90 dias, salvo se necessário. |
| Logs de login e de sessão | DB do produto, IP com hash, TTL de 90 dias | 90 dias | Podes ver a tua em Definições → Segurança. |
| Analytics web | Corremos o Plausible só no site de marketing. | Agregado, 24 meses | Sem cookies, sem fingerprinting, sem tracking nas páginas autenticadas. |
Encontraste alguma coisa? Escreve-nos.
Dá-nos uma janela razoável (normalmente 90 dias) antes de tornares público. Em troca recebes uma resposta humana num dia útil, crédito no changelog, e um pagamento se a descoberta for relevante.
Se a tua contabilidade é importante, aloja-a tu.
A versão auto-alojada corre no teu servidor, com os teus backups, por trás da tua firewall. Se for preciso uma equipa de segurança aprovar, normalmente é esta a resposta fácil.