Onde termina a proteção do Crunu
Criptografar nos seus dispositivos significa que o servidor não consegue ler os seus segredos. Isso não elimina todos os riscos. Aqui está cada limite que conhecemos, tirado do próprio modelo de ameaças do produto, e o que fazer em cada caso.
O que a criptografia nos seus dispositivos não consegue impedir
O Crunu descriptografa nos seus dispositivos, então quem controla um dispositivo, ou a página que roda nele, consegue ver o que esse dispositivo descriptografa. A criptografia também não desfaz o que alguém já viu.
- Uma página adulterada poderia capturar a sua senha e a sua Secret Key.A página em app.crunu.com vem do servidor, então um servidor invadido ou operado de má-fé poderia enviar uma página que registra o que você digita. O app se confere com o manifesto assinado do Crunu a cada carregamento, mas essa verificação roda dentro da mesma página. Em app.crunu.com, você confia isso ao Crunu e à hospedagem dele; num servidor próprio, a quem o opera. O que fazer: se o app avisar “Build signature doesn’t match: do not enter your password”, não digite a senha, e rode o seu próprio servidor se a página precisar vir de uma infraestrutura que você controla.
- O que alguém já viu não tem como ser desfeito.Remover uma pessoa ou revogar uma máquina rotaciona as chaves, então elas não conseguem ler nada novo. Os valores que já viram continuam funcionando onde quer que esses valores sejam válidos. O que fazer: use Remove from organization, percorra o checklist de reemissão e reemita cada valor no provedor dele, começando pelos que mais importam.
- Quem controla um dispositivo ou uma máquina vê o que ele descriptografa.Um malware, uma extensão de navegador ou o root no seu computador consegue ler o que é descriptografado ali. O root numa máquina com o agente vê tudo o que é entregue a ela, e um programa em execução mantém as suas variáveis até ser reiniciado. O que fazer: use dispositivos que você controla, dê às máquinas apenas o que elas executam e, depois de um comprometimento, use Device compromised ou revogue a máquina; em seguida, reemita os valores dela.
O que o servidor ainda consegue fazer
Em app.crunu.com, quem opera o servidor é o Crunu; num servidor próprio, quem o opera. Nos dois casos, estes limites também valem para quem invadir o servidor. Ele não consegue ler os seus ambientes, mas não fica sem poder nenhum.
- Ele vê metadados.O servidor lê os nomes de organizações, projetos, ambientes, máquinas e pessoas, os endereços de e-mail, o log de auditoria, quem recebeu qual versão e de onde, e o horário e o tamanho de cada versão. Nada dentro de um ambiente, nem mesmo nomes de variáveis ou de arquivos. O que fazer: 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.
- Ele pode negar o serviço ou descartar gravações.Um servidor pode parar de responder, ou alegar que nunca recebeu uma alteração, e a criptografia não tem como obrigá-lo a atender você. O que fazer: baixe uma cópia offline de tempos em tempos. Ela abre com a sua senha e a sua Secret Key, sem nenhum servidor. Num servidor próprio, exporte o banco de dados diariamente. Durante o acesso antecipado, app.crunu.com não tem compromisso de disponibilidade.
- Ele poderia mostrar a um dispositivo novo uma visão antiga da sua organização.Os seus dispositivos recusam qualquer coisa mais antiga do que já aceitaram, mas um dispositivo que você nunca usou não tem com o que comparar. Um servidor comprometido, em conluio com alguém que você removeu, poderia mostrar a ele a sua organização como era antes da remoção. O Crunu não consegue fechar isso por completo sem uma fonte externa de atualidade. O que fazer: num dispositivo novo, use Compare with your other devices em Organization settings e, se os números forem diferentes, não salve nada a partir dele e avise quem tem a função Owner.
- As regras de rede são regras do servidor, não criptografia.Um servidor comprometido pode ignorar uma restrição de IP. Todos atrás do mesmo NAT ou proxy compartilham um endereço, então todos contam como dentro, e o conteúdo entregue antes de uma restrição fica onde chegou. O que fazer: use regras de rede além de um acesso restrito, vincule os tokens de CI com OIDC em vez de depender das faixas de IP dos runners e, depois de apertar uma regra, reemita os valores que já saíram.
A recuperação tem limites rígidos
Como o servidor nunca tem a sua senha nem a sua Secret Key, ninguém consegue redefini-las por você. Os caminhos de volta à conta ficam sob a sua guarda, e eles abrem mais do que você talvez imagine.
- Ninguém consegue redefinir a sua senha.Se você perder a senha, a Secret Key e o código de recuperação, ninguém consegue abrir a sua conta, nem nós. Se todos os owners e admins perderem o acesso, não sobra ninguém para gerenciar a organização. O que fazer: imprima o Emergency Kit e guarde-o longe dos seus dispositivos, crie um código de recuperação e mantenha pelo menos dois owners ou admins.
- Um código de recuperação dispensa o seu segundo fator.Ele abre a sua conta depois de um período de espera, uma hora por padrão. Quem controla a espera e envia o alerta é o servidor, então um servidor comprometido, em conluio com alguém que tem o seu código, poderia liberar o acesso na hora. O que fazer: guarde o código separado do Emergency Kit e dos dispositivos e, se receber um alerta de uma recuperação que você não iniciou, cancele-a e apague o código.
- Owners e admins conseguem abrir os ambientes compartilhados.Toda chave de ambiente compartilhado também é selada para a chave de recuperação da organização, que owners e admins têm. Enquanto a recuperação de ambientes pessoais estiver ativada, o padrão, eles também conseguem abrir os ambientes pessoais dos membros. O que fazer: reserve essas funções às poucas pessoas que administram a organização. Um owner pode desativar a recuperação de ambientes pessoais, mas aí uma conta perdida perde os seus ambientes pessoais.
- Um dispositivo roubado guarda a sua Secret Key.Por padrão, o navegador guarda a Secret Key para você não precisar digitá-la a cada login, o que deixa a senha como a barreira que resta. O que fazer: use uma senha forte, exclusiva do Crunu, mantenha curto o bloqueio por inatividade e, de outro dispositivo, remova o roubado ou use Device compromised.
Se você roda o seu próprio servidor
Estes limites valem para quem opera o servidor. Em app.crunu.com, quem opera é o Crunu. Um deles afeta os seus dispositivos em qualquer servidor, inclusive o app.crunu.com: restaurar o banco de dados a partir de um backup desfaz todas as alterações feitas depois dele.
- Sem e-mail, os endereços dos convites não são confirmados.Um servidor sem e-mail configurado não consegue enviar um código para confirmar o endereço de um convite, então alguém poderia ficar com um endereço que não é seu. A conferência da impressão digital continua impedindo a entrada da chave de um estranho. O app.crunu.com tem e-mail configurado. O que fazer: defina
RESEND_API_KEYeALERT_EMAIL_FROMantes de convidar pessoas de fora da sua equipe, e sempre confira a impressão digital. - A
SERVER_KEYé o segredo do próprio servidor.Ela assina sessões, links de compartilhamento e convites e criptografa os segredos de apps autenticadores, mas não os seus ambientes. Perdê-la desconecta todo mundo e quebra os links de compartilhamento. Se ela vazar junto com uma cópia do banco de dados, enfraquece os códigos dos apps autenticadores. O que fazer: guarde o arquivo.envnum gerenciador de senhas, separado dos backups, e rotacione a chave pelo procedimento documentado. - Uma restauração faz tudo voltar atrás.Restaurar um backup desfaz todas as alterações feitas depois dele, e os dispositivos que viram dados mais novos acusam uma reversão e recusam esses ambientes até que o estado salvo deles seja redefinido. O que fazer: faça backup diariamente, redefina agentes e navegadores somente depois de uma restauração que você mesmo fez, e trate um aviso de reversão sem restauração como um sinal de alerta.
- Escolha com cuidado o endereço e a plataforma.As assinaturas de login, os links de compartilhamento, as passkeys e os agentes ficam presos ao endereço do servidor, então ele não pode mudar depois. No plano gratuito do Cloudflare Workers, uma requisição tem 10 ms de CPU, e no Google Cloud Run e no AWS App Runner alguns alertas chegam com atraso. A AWS fechou o App Runner para novos clientes. O que fazer: use um domínio que você vai manter, o Workers Paid para uma equipe e uma plataforma com agendador se esses alertas importarem.
Fora do Crunu por design, ou ainda não
Algumas coisas o Crunu não faz. Uma ele nunca vai fazer, porque exigiria chaves no servidor. As outras faltam hoje, então planeje-se em torno delas.
- Sem segredos dinâmicos.O Crunu não cria sob demanda senhas de banco de dados nem credenciais de nuvem de curta duração. Isso exige chaves no servidor, que é exatamente o que o Crunu foi construído para não ter, e isso não vai mudar. O que fazer: use as credenciais de curta duração do seu provedor, onde ele as oferecer.
- Sem reemissão automática nos provedores.A rotação no Crunu troca chaves de criptografia. Os próprios valores são reemitidos à mão em cada provedor, a partir do checklist de reemissão. O que fazer: reemita as credenciais de longa duração com uma periodicidade definida e salve cada novo valor como uma nova versão.
- Sem acesso temporário para pessoas.O acesso a um ambiente não tem data de expiração. A expiração existe para convites, links de compartilhamento, tokens de serviço, concessões de máquinas e acesso break-glass. O que fazer: revise quem tem acesso a production quando as pessoas mudam de função e use um link de compartilhamento com validade para necessidades pontuais.
Perguntas sobre estes limites
A equipe do Crunu consegue ler os meus segredos?
Não. Em app.crunu.com, o Crunu opera o servidor, e o servidor tem apenas texto cifrado e nenhuma chave para descriptografá-lo. Conseguimos ver metadados como nomes, endereços de e-mail e o log de auditoria, listados na Política de Privacidade. Chegar aos seus valores exigiria alterar o código que roda no seu dispositivo, que é o primeiro limite desta página.
Rodar o meu próprio servidor elimina esses limites?
Alguns passam para você. Você decide quem opera o servidor que envia a página web e vê os metadados, e assume os limites de “Se você roda o seu próprio servidor”. Os limites nos seus dispositivos continuam os mesmos.
Por que vocês não conseguem redefinir a minha senha?
A chave da sua conta é derivada no seu dispositivo a partir da sua senha e da sua Secret Key, e nunca recebemos nenhuma das duas. É isso que mantém os seus dados ilegíveis para nós. O seu Emergency Kit e um código de recuperação são os caminhos de volta à conta.
O que fazer primeiro quando alguém sai?
Remova a pessoa da organização. O Crunu para de atendê-la e rotaciona todas as chaves que ela tinha. Depois, percorra o checklist de reemissão e reemita em cada provedor os valores que ela viu.
O Crunu vai ter segredos dinâmicos?
Não. Criar credenciais sob demanda exige chaves no servidor, e o Crunu foi construído para que o servidor nunca as tenha.
Encontrou um limite que não está nesta página?
Escreva para security@crunu.com. Preferimos listá-lo aqui a você descobri-lo da pior maneira.
Guarde os segredos da sua equipe onde o servidor não consegue lê-los
Crie a sua conta em app.crunu.com. As suas chaves são criadas no seu navegador, e o servidor recebe apenas texto cifrado.