Segurança

Cada projeto roda na própria célula de banco de dados: um processo PostgreSQL dedicado, seu próprio conjunto de armazenamento, suas próprias credenciais e seus próprios limites de CPU e memória impostos pelo sistema operacional. Não há banco compartilhado, esquema compartilhado nem partição por linha entre dois clientes.

Esse é todo o argumento de isolamento, e ele é deliberadamente sem graça. Um vizinho barulhento não consegue esgotar sua memória porque o limite não é compartilhado. Um bug na consulta de outro inquilino não alcança seus dados porque o processo não os enxerga.

Um repositório K/V recebe o mesmo tratamento: processo próprio, limite de memória próprio, armazenamento próprio e credencial própria. Ele não tem rota de rede para o seu banco de dados nem para a internet pública — só o endpoint autenticado chega até ele.

Células padrão rodam em um namespace de rede privado com uma interface de loopback e nada além disso. Não conseguem abrir conexão de saída para a internet, para outra célula ou para o plano de controle - não por política, mas porque não existe rota.

O tráfego do cliente chega à célula por um socket entregue pela camada de roteamento. Extensões que fazem chamadas de rede para fora ficam indisponíveis nas células padrão exatamente por isso, e preferimos dizer não a afrouxar a fronteira em silêncio.

• -TLS em toda conexão pública, direta e via pooler, com certificados emitidos por região e nomes de host verificados
• -Painel, API, CLI e todos os SDKs falam apenas HTTPS, com HSTS no domínio próprio
• -O armazenamento das células e o arquivo de backup são criptografados em repouso
• -Backups e segmentos do log de escrita antecipada são criptografados antes de deixarem o nó

A camada de roteamento retransmite a autenticação SCRAM do PostgreSQL de ponta a ponta. Ela nunca vê, guarda ou consegue reconstruir sua senha de banco de dados: repassa o desafio e a resposta e sai do caminho.

Chaves de API da organização são guardadas apenas como hash e não podem ser lidas depois de emitidas; se perder uma, você a rotaciona. Credenciais de banco por projeto que o plano de controle mantém para operações de ciclo de vida são criptografadas em repouso com uma chave que não fica junto delas. O login é delegado a um provedor de identidade dedicado, de modo que nenhuma senha sua existe em nossos sistemas de forma alguma.

• -Arquivamento contínuo fora do nó: os segmentos do log de escrita antecipada saem conforme são produzidos, não em uma rotina noturna
• -Recuperação para um instante dentro da janela de retenção do seu plano, não apenas para o último backup completo
• -Restaurações são exercitadas em cronograma em vez de presumidas funcionais, e um backup desatualizado ou com falha gera um alerta sobre o qual agimos
• -Bancos de preview são feitos por clonagem, então testar uma restauração ou uma migração destrutiva custa um clone, não uma indisponibilidade
• -Operações destrutivas no painel, na CLI e no servidor MCP pedem antes um ponto de restauração

O acesso à produção é restrito a quem opera a plataforma, concedido por necessidade e não por cargo, e exige autenticação multifator. O acesso a um nó ocorre apenas por canais autenticados; não há logins compartilhados nem console permanentemente aberto.

Um operador lê o conteúdo de uma célula somente para um suporte que você pediu, ou para um incidente que não pode ser resolvido de outro jeito. Ambos ficam registrados, e é esse registro que mostraríamos se você pedisse.

• -Aplicação automática de correções de segurança em cada nó, com os temporizadores realmente verificados e não presumidos ativos
• -Varredura de dependências e vulnerabilidades no pipeline de cada repositório, para todas as linguagens da stack
• -Isolamento de serviços: a unidade de cada célula roda com visão mínima do sistema de arquivos, namespace de rede privado e limites de cgroup
• -Versões menores do Postgres são aplicadas como reinício; uma célula dormindo recebe sua atualização de graça no próximo despertar
• -Cabeçalhos de segurança, política de segurança de conteúdo e limitação de abuso nas superfícies web públicas

Saúde dos nós, saúde das células, atualidade dos backups, verificação de restauração e pressão de recursos são consultadas continuamente e alertam uma pessoa. A disponibilidade por região é publicada ao vivo na página de status.

Quando algo quebra e afeta você, avisamos por e-mail e na página de status em vez de esperar a pergunta. Se uma violação de dados pessoais atinge o limiar de notificação, valem os prazos do Acordo de Tratamento de Dados.

A CapyDB não tem relatório SOC 2 nem certificado ISO 27001, e não oferece acordo HIPAA. Preferimos dizer isso na página de segurança a deixar você descobrir num questionário.

O que oferecemos: um Acordo de Tratamento de Dados autosserviço, vigente desde o primeiro dia; uma posição pública sobre suboperadores; residência de dados na UE para células e backups; e resposta direta a qualquer questionário de segurança. Se uma certificação for requisito obrigatório para a sua compra, diga: é útil para nós saber disso.

Envie para o endereço do nosso security.txt, ou escreva direto. Inclua o suficiente para reproduzir. Confirmamos rápido, contamos o que encontramos e creditamos você se quiser. Não há programa de recompensa paga.

Testar contra um projeto seu é permitido e bem-vindo. Testar contra outro inquilino, ou rodar ataques volumétricos contra a plataforma, não é - e é a única coisa que suspende uma conta sem aviso prévio.