Modelo de segurança: o servidor só guarda texto cifrado

O Crunu criptografa o conteúdo de cada ambiente no seu navegador ou no agente crunu antes de qualquer envio. O servidor guarda texto cifrado, chaves públicas e registros assinados, e em nenhum momento do protocolo tem uma chave capaz de descriptografá-los.

Em app.crunu.com, quem opera esse servidor é o Crunu. Se você hospeda o Crunu por conta própria, quem opera é você. Nos dois casos, o servidor não consegue ler os seus valores. O Crunu está em acesso antecipado, então descrevemos apenas o que a versão atual faz e atualizamos esta página quando isso mudar.

A versão curta

• Os seus ambientes são criptografados nos seus dispositivos. O servidor armazena apenas texto cifrado e não tem chave para lê-lo.
• A sua senha e a sua Secret Key nunca saem do seu dispositivo; por isso, um banco de dados roubado não ajuda ninguém a adivinhá-las.
• Cada ambiente tem a sua própria chave. Pessoas, máquinas e tokens de CI recebem apenas os ambientes que lhes foram concedidos.
• As listas de acesso e as versões são assinadas, então o servidor não consegue se incluir como destinatário nem alterar os seus dados sem que isso apareça.
• O servidor ainda vê metadados: nomes, endereços de e-mail, o log de auditoria e quando cada versão foi salva.
• O principal risco que resta é uma página web adulterada. Limitações conhecidas descreve esse risco junto com todos os outros limites que conhecemos.
• Não publicamos relatório SOC 2 nem auditoria externa. Encontrou um problema? Escreva para security@crunu.com.

O caminho de um segredo, passo a passo

Acompanhe a STRIPE_SECRET_KEY desde o momento em que Priya a salva até os programas que a leem.

1. O navegador de Priya criptografa e assina. A senha dela e a Secret Key, 26 caracteres aleatórios criados no dispositivo dela, são combinadas na chave da conta, e nenhuma das duas é enviada. Ao salvar, o navegador criptografa a nova versão inteira do ambiente, com todos os arquivos e variáveis, como um único registro com a chave desse ambiente (AES-256-GCM). Ele completa o registro até blocos inteiros de 4 KB para que o tamanho exato não apareça e assina a versão em nome de Priya (Ed25519).
2. O servidor guarda o que não consegue abrir. Ele mantém um registro criptografado por versão, e não um por valor, junto com a lista de acesso assinada que diz quem pode lê-lo. O servidor decide a quem entregar o texto cifrado, mas não tem chave para descriptografá-lo.
3. Um colega recebe apenas os ambientes concedidos a ele. Jonas recebe as chaves dos ambientes de development e staging, cada uma selada para a chave pública dele (X25519). Production não está na lista de acesso dele, então ele nunca recebe essa chave. O navegador dele confere cada assinatura e cada número de versão antes de descriptografar.
4. Um servidor recebe o seu ambiente do mesmo jeito. O agente em api-prod-1 recebe a chave de production selada para essa máquina, confere o que o servidor enviou e mantém o ambiente descriptografado em memória. O seu programa o recebe por meio do crunu run, ou como arquivos onde você pedir, com crunu pull.
5. Um job de CI recebe exatamente a sua parte. O token de serviço do GitHub Actions só consegue ler web-app / staging. Com um vínculo de CI (OIDC), ele só funciona a partir do repositório e do branch que você escolheu.

Em app.crunu.com, o servidor roda na Cloudflare. A página Suboperadores lista cada empresa que trata dados para o serviço e o que cada uma consegue ver.

Na documentação: Como funciona a criptografia

Chaves e algoritmos

O Crunu usa blocos de construção padrão: AES-256-GCM para criptografar, X25519 para selar chaves para um destinatário, Ed25519 para assinar e HKDF-SHA256 e PBKDF2-SHA256 para derivar chaves. O navegador usa o WebCrypto embutido, e o agente usa a biblioteca padrão do Go. Os dois são testados com os mesmos vetores de teste.

Se uma cópia do banco de dados vazar, adivinhar a sua senha a partir dela não funciona: cada tentativa também precisa da sua Secret Key, que nunca esteve no servidor, então testar um único palpite significa percorrer cerca de 2¹²⁸ possibilidades. Os tokens são armazenados apenas como hashes com chave.

Na documentação: Emergency Kit e Secret Key · Código de recuperação

Cada ambiente é selado separadamente

• As organizações ficam separadas pelas próprias chaves. Um servidor pode hospedar muitas organizações. Cada uma tem as próprias chaves de assinatura e de recuperação, e as chaves dos ambientes dela são seladas apenas para membros e máquinas que essa organização certificou.
• Acesso a development não abre production. Cada ambiente tem a sua própria chave, e quem não tem a chave de production não consegue ler production.
• Specific files quer dizer arquivos específicos. Uma pessoa com essa função, ou uma máquina configurada com Selected files, recebe uma cópia selada apenas dos arquivos escolhidos.
• Operators configuram máquinas sem ver os valores. Eles não têm nenhuma chave de ambiente. Uma pessoa que tem a chave aprova o acesso de cada máquina.
• As regras de rede limitam para onde o conteúdo vai. Um ambiente pode ser entregue apenas a faixas de IP permitidas, para pessoas, máquinas e tokens igualmente. Afrouxar uma regra exige esperar 15 minutos, com um alerta, a menos que um segundo administrador a assine. Apertar vale na hora. Isso é uma regra que o servidor impõe, não criptografia.

Na documentação: Funções em organizações e ambientes · Regras de rede

O que o servidor consegue ver, e o que não consegue

Um servidor cego ainda precisa de alguns fatos: a quem entregar o texto cifrado e o que escrever no log de auditoria. Esta é a lista completa.

Legível para o servidor

• Nomes de organizações, projetos, ambientes, máquinas, tokens de serviço, perfis de acesso e listas de redes
• Nomes e endereços de e-mail dos membros, e os endereços para onde vão os convites
• Quem tem qual função em qual ambiente, a partir da lista de acesso assinada
• De cada versão: o número, quem a salvou, quando e o tamanho arredondado para cima até um múltiplo de 4 KB
• Qual versão cada pessoa, máquina e token recebeu, quando e de qual endereço IP
• O log de auditoria, os seus dispositivos e sessões e os endereços IP que eles usam
• As suas regras de rede: as faixas de IP que você permite
• O segredo do seu app autenticador, se você usa um. O servidor confere os seus códigos, então guarda esse segredo criptografado com uma chave própria.

Só texto cifrado

• Tudo o que está dentro de um ambiente: nomes e valores de variáveis, nomes de arquivos, caminhos, conteúdo e notas. Cada versão é um único registro criptografado do ambiente inteiro, então o servidor não vê variáveis individuais nem qual delas mudou.
• Arquivos que você envia por links de compartilhamento
• As chaves privadas das contas e da organização

Nunca enviado ao servidor

• A sua senha e a sua Secret Key
• O seu código de recuperação. O servidor guarda uma cópia da chave da sua conta que só o código consegue descriptografar.
• As chaves privadas das máquinas, criadas na própria máquina e que ficam lá
• A chave de um link de compartilhamento, que fica depois do # que os navegadores não enviam
• Os próprios tokens de serviço. O servidor conhece apenas as chaves públicas deles.

É isso que chamamos de servidor cego: ele vê quem e quando, mas nada dentro dos seus ambientes. Em app.crunu.com, a lista legível é exatamente o que o Crunu consegue ver, e a Política de Privacidade diz por quanto tempo guardamos esses dados. Não coloque segredos em nomes: um projeto com o nome de um negócio ainda não anunciado conta ao servidor sobre esse negócio, mesmo com todos os valores lá dentro criptografados.

Na documentação: O que o servidor vê

Quem consegue ler os seus segredos

• As pessoas a quem você dá acesso. Os membros recebem apenas os ambientes concedidos a eles. Esconder valores no app é uma escolha de exibição: quem consegue descriptografar um valor consegue copiá-lo.
• Owners e admins. Eles têm a chave de recuperação da organização, então conseguem abrir todos os ambientes compartilhados. Também conseguem abrir os ambientes pessoais dos membros enquanto a configuração de recuperação de ambientes pessoais da organização estiver ativada, o que é o padrão.
• Máquinas e CI. Cada máquina e cada token leem apenas o que receberam. Os códigos de registro valem 15 minutos por padrão e deixam de funcionar no primeiro uso, e você só aprova uma máquina depois de conferir a impressão digital que o crunu enroll exibe nela. Uma máquina revogada descarta os seus ambientes em poucos minutos enquanto está online.
• Não a equipe do Crunu. Em app.crunu.com, o Crunu opera o servidor, e o servidor não tem chave. Vemos os metadados acima. Chegar aos seus valores exigiria alterar o código que roda no seu dispositivo, por exemplo, com uma página web adulterada. Limitações conhecidas explica esse risco.
• Quem tenta entrar numa conta. O login aceita 10 falhas por endereço IP e 5 por conta em 15 minutos, e um e-mail desconhecido e uma senha errada recebem a mesma resposta. Um novo dispositivo precisa do seu segundo fator, um app autenticador ou uma passkey, depois que você ativa um. As sessões terminam após 12 horas de inatividade e duram no máximo 7 dias, e uma sessão roubada não consegue alterar a sua senha, a sua Secret Key nem as chaves da sua conta.

Na documentação: Máquinas e concessões · Vincular um token de serviço ao CI com OIDC · Entrar pelo terminal

Como as versões são geradas e conferidas

• Cada versão do agente crunu e do app web é assinada com uma chave de release Ed25519.
• As versões do agente são publicadas em releases.crunu.com: binários, pacotes .deb, o install.sh e um manifesto assinado. O instalador confere o SHA-256 do binário do agente, e o crunu self-update confere a assinatura da versão com uma chave embutida no agente. O comando de instalação que o app web mostra traz as somas de verificação da versão assinada.
• O Crunu publica o manifesto assinado do app web em app.crunu.com. Quando o app carrega, ele confere essa assinatura e o próprio build com o manifesto e mostra Signed build na barra lateral. Selecione a marca para conferir cada arquivo do site. Se algo não bater, o app avisa para você não digitar a sua senha.
• Essa verificação roda em código entregue pelo mesmo servidor. Ela pega um deploy quebrado ou misturado, mas não um servidor que altere a página e a verificação ao mesmo tempo.
• O build do app web é reproduzível: um mesmo commit do código-fonte sempre gera os mesmos arquivos. A página não permite scripts de terceiros e carrega o próprio código com somas de integridade (CSP e SRI).
• Poucas dependências: o agente usa apenas a biblioteca padrão do Go, e o código do navegador inclui um único pacote npm, o yaml.

Na documentação: Atualizar o crunu com self-update

Backups, disponibilidade e saída

• Em app.crunu.com, o banco de dados guarda até 30 dias de histórico de restauração na Cloudflare. Durante o acesso antecipado, não prometemos nenhum nível de disponibilidade. Veja os Termos de Serviço.
• Guarde a sua própria cópia. O app pode baixar uma cópia offline de todos os ambientes a que você tem acesso. Ela abre com a sua senha e a sua Secret Key, sem nenhum servidor. Ambientes com restrição de rede não são incluídos.
• Rode por conta própria, ou mude de lugar. O mesmo servidor roda em Docker numa máquina sua, no Cloudflare Workers, na Vercel e no Google Cloud Run, e no AWS App Runner em contas que ainda têm acesso a ele. Um único arquivo exportado, sem nenhum valor em texto puro, leva o servidor de uma plataforma para outra, e esse mesmo arquivo é o seu backup. Veja Hospedagem própria.

Na documentação: Exportação e cópia offline · Backups e restauração

O que é guardado e por quanto tempo

• Versões. Cada ambiente guarda as suas últimas 100 versões, até 64 MB. Restaurar uma versão antiga a salva como uma nova.
• Log de auditoria. Logins, convites, mudanças de função, versões salvas, rotações de chaves, máquinas, tokens, links de compartilhamento e solicitações recusadas vão para um log cujas entradas formam uma cadeia de hashes. Editar, apagar ou inserir uma entrada quebra a cadeia, e Verify integrity mostra isso. O log é guardado por 365 dias por padrão, e os owners podem estender esse prazo. Os valores nunca aparecem nele, porque o servidor não os tem.
• Registros de entrega e exclusão. O registro de quem recebeu cada versão é guardado por 90 dias depois da última entrega e então consolidado num resumo. Excluir a sua conta exige a sua senha e a sua Secret Key. Uma organização excluída fica indisponível na hora e é removida em lotes pouco depois. A Política de Privacidade traz a tabela completa.

Na documentação: Log de auditoria · Versões e histórico

Se o próprio servidor for comprometido

Projetamos para o pior caso: um banco de dados invadido, um operador mal-intencionado ou uma conta de nuvem sequestrada, depois do que o servidor pode responder o que quiser. Os seus dispositivos conferem o que ele envia, então mesmo assim ele não consegue ler os seus valores, se incluir como destinatário, trocar uma chave, alterar uma versão, renomear production, fazer passar uma organização criada por ele nem introduzir outra chave quando alguém entra. Os apps e os agentes também lembram o estado mais recente que aceitaram e recusam qualquer coisa mais antiga, então uma lista de acesso reenviada não traz de volta alguém que você removeu. Um dispositivo totalmente novo não tem com o que comparar, então não consegue detectar uma reversão na primeira visita.

O que ele ainda consegue fazer é negar o serviço, ler metadados e entregar uma página web adulterada. Os alertas sinalizam logins de dispositivos novos, códigos de registro reutilizados, tokens de CI reenviados e recusas repetidas. Quando alguém sai, o app rotaciona as chaves que essa pessoa tinha e lista os valores a reemitir. Para um dispositivo roubado, Device compromised substitui as chaves da sua conta e rotaciona cada ambiente cuja chave você tinha.

Se soubermos que app.crunu.com foi invadido, avisaremos por e-mail os titulares das contas afetadas sem demora injustificada: o que aconteceu, quais dados foram envolvidos e o que fazer em seguida. Uma invasão do serviço expõe texto cifrado e metadados, não os valores dos seus ambientes, que não podem ser descriptografados sem a sua senha e a sua Secret Key. A Política de Privacidade registra o mesmo compromisso.

Na documentação: Remover alguém da equipe · Rotacionar as chaves dos ambientes · Alertas

O que depende de você

A criptografia tira o servidor da lista de coisas que conseguem ler os seus segredos. Algumas coisas, só você pode fazer.

• Imprima o seu Emergency Kit ao criar a conta e guarde-o longe dos seus dispositivos. Ninguém, nem nós, consegue redefinir a sua senha ou recuperar a sua Secret Key.
• Crie um código de recuperação e guarde-o separado do Emergency Kit. Ele abre a sua conta depois de um período de espera, uma hora por padrão, sem o seu segundo fator.
• Ative um segundo fator e mantenha curto o bloqueio por inatividade. Por padrão, o app esquece as suas chaves após 10 minutos sem atividade.
• Dê a cada pessoa e a cada máquina apenas o que elas precisam, e mantenha poucos owners e admins.
• Quando alguém sai, reemita em cada provedor os valores que essa pessoa viu. A rotação protege as novas versões, não o que ela já viu.
• Se o app avisar “Build signature doesn’t match: do not enter your password”, não digite a senha e avise o seu administrador.

Na documentação: Limitações · Bloqueio e tempo de inatividade

Auditorias e documentos

O Crunu é novo e está em acesso antecipado. Ele não tem certificação SOC 2 nem ISO 27001, e nenhuma auditoria externa foi publicada.

Estes documentos explicam como o serviço trata os dados:

• Política de Privacidade: o que guardamos, por que e por quanto tempo
• Suboperadores: quem opera o serviço conosco, e onde
• Termos de Serviço e Política de Uso Aceitável

Para as suas próprias revisões, owners e admins podem exportar o log de auditoria em JSONL e conferir a cadeia de hashes fora do Crunu. Quando alguém sai, o relatório de exposição mostra quais versões de quais ambientes a pessoa recebeu, quando e de onde, e você pode baixá-lo.

Relate uma vulnerabilidade

Escreva para security@crunu.com com os passos para reproduzir o problema. Não inclua segredos reais no relato.

Ao testar, por favor:

• teste apenas em contas e organizações que você mesmo criou, ou com a permissão dos owners delas;
• não acesse nem guarde dados de outras pessoas, e nos avise se chegar a eles por acidente;
• não faça testes de negação de serviço, não envie spam e não use engenharia social;
• mantenha as varreduras automatizadas leves o bastante para não afetar outros usuários.

Confirmaremos o recebimento do seu relato e manteremos você informado enquanto trabalhamos nele. Combinaremos com você uma data de divulgação, normalmente em até 90 dias a partir do relato.

A Política de Uso Aceitável traz as regras completas, incluindo o nosso compromisso de não tomar medidas judiciais contra pesquisas feitas de boa-fé. O mesmo contato está no security.txt.