Segurança

1. O que esta página é

Esta página descreve as medidas técnicas que o Cardim aplica hoje, escritas a partir do código tal como está publicado. Não é um contrato: os compromissos contratuais estão nos Termos de Serviço, e o que fazemos com dados pessoais, e com que fundamento, está na Política de Privacidade.

O Cardim é um produto recente, operado por uma equipa muito pequena. Preferimos dizê-lo aqui, no início, a deixá-lo implícito: a secção 7 enumera o que não existe.

2. Onde ficam os dados

As marcações e os dados dos clientes ficam numa base de dados Postgres alojada pela Neon em Londres, no Reino Unido, sobre infraestrutura AWS na região eu-west-2. A aplicação corre na Vercel, os emails transacionais são entregues pela Resend e os relatórios de erro vão para a Sentry. A lista completa de fornecedores, com as finalidades de cada um, está na secção 5 da Política de Privacidade.

Todo o tráfego é servido sobre HTTPS. A cifra do armazenamento em disco é a que estes fornecedores publicam e não é nossa; ao nível da aplicação, o que ciframos ou transformamos em hash é exatamente o que a secção seguinte enumera, e nada mais.

3. Palavras-passe, chaves e ligações

Nada nesta lista fica guardado numa forma que uma leitura da base de dados torne reutilizável, com uma exceção assinalada: os tokens de calendário têm de ser devolvidos ao fornecedor, por isso são cifrados em vez de transformados em hash.

• Palavras-passe dos comerciantes — nunca guardadas. Guardamos o resultado de scrypt, com um sal diferente por utilizador, e a verificação é feita com uma comparação em tempo constante.
• Ligações de reposição de palavra-passe — 32 bytes de aleatoriedade criptográfica, e a base de dados guarda apenas o SHA-256 do token: quem leia a base de dados não consegue repor a palavra-passe de ninguém.
• Tokens do Google Calendar e do Outlook — cifrados com AES-256-GCM antes de serem escritos, com um conjunto de chaves que permite substituir a chave sem invalidar o que já lá está.
• Sessões e ligações de marcação — identificadores de 128 bits gerados pelo gerador criptográfico do sistema. A sessão viaja num cookie httpOnly e caduca ao fim de 30 dias.

A ligação que o cliente recebe por email é, por si só, a autorização para ver, alterar ou cancelar aquela marcação — do lado do cliente não há conta nem palavra-passe. É por isso que essas ligações, e os endereços de email, são retirados dos relatórios de erro antes de saírem da aplicação, e por isso que os formulários públicos limitam o número de tentativas por origem.

4. O que a base de dados não deixa acontecer

Duas marcações não podem ocupar o mesmo recurso à mesma hora, e a garantia não está no código da aplicação: cada linha de ocupação guarda o seu intervalo temporal, e uma restrição de exclusão do Postgres recusa qualquer sobreposição. Dois pedidos que cheguem no mesmo instante não podem ambos ganhar, aconteça o que acontecer acima da base de dados.

Um gatilho separado impede que o mesmo cliente fique com duas marcações sobrepostas. Nas mesas e salas de capacidade partilhada, a contagem de lugares é validada dentro da mesma transação, com bloqueios por recurso adquiridos sempre pela mesma ordem, para que dois pedidos simultâneos não fiquem à espera um do outro.

5. Quem vê o quê

Cada ecrã do painel consulta apenas os dados do comerciante da sessão, e os pedidos de exportação e de apagamento exigem esse mesmo âmbito: um comerciante não consegue exportar nem apagar os registos de outro.

Existe uma consola interna, usada para operar o serviço, cujo acesso está limitado a uma lista fechada de endereços de email definida na configuração do servidor. Quando essa lista não está configurada, a consola recusa toda a gente em vez de deixar entrar.

6. Conservação, apagamento e exportação

Corre periodicamente uma limpeza que apaga o que já não serve para nada:

• sessões cuja validade expirou — uma sessão abandonada é uma credencial viva enquanto a linha existir;
• reservas temporárias de lugar que já caducaram;
• registos de limitação de tentativas com mais de 24 horas, que de resto guardam um hash e não o endereço original;
• inscrições em lista de espera para datas com mais de 30 dias, que são um nome, um telefone e um email de alguém que nunca chegou a ser cliente.

As marcações e os clientes não são apagados por temporizador: são o registo do negócio do comerciante. O apagamento é feito a pedido e é uma anonimização no lugar — a marcação, a hora e o valor continuam a existir, a identidade da pessoa desaparece, incluindo as observações em texto livre e os eventos espelhados no calendário ligado. Se algum desses eventos não puder ser apagado, o comerciante é informado disso em vez de ser tranquilizado.

Um comerciante pode pedir a exportação dos seus dados e o apagamento integral da conta.

7. O que não temos

Esta lista existe porque a alternativa é deixar a pergunta sem resposta e esperar que ninguém a faça:

• não temos certificação SOC 2, ISO 27001 ou qualquer outra;
• não houve auditoria de segurança externa nem teste de intrusão por terceiros;
• não oferecemos acordo de nível de serviço de disponibilidade, e a disponibilidade real depende dos fornecedores indicados na secção 2;
• não temos programa de recompensas por comunicação de vulnerabilidades.

8. Comunicar um problema

Se encontrou uma falha de segurança, escreva para support@usecardim.com com os passos para a reproduzir. Respondemos e corrigimos o que estiver ao nosso alcance, e pedimos-lhe que não a divulgue publicamente antes de estar corrigida.