Um cofre que você consegue analisar, inclusive onde ele para

Perguntas que vão fazer a você

A maior parte do trabalho de segurança com segredos é responder perguntas. Quem consegue ler o production? Quem de fato leu? O que uma invasão da hospedagem exporia? O que mudou depois que alguém saiu?

O trabalho é ter essas respostas numa forma que você possa mostrar a um auditor, a um cliente ou ao seu conselho.

O que você pode afirmar, e por que se sustenta

• O servidor não consegue ler os valores. A criptografia acontece só no navegador e no agente crunu. O servidor armazena texto cifrado, chaves públicas e documentos assinados, e não tem chave de descriptografia em nenhum ponto do protocolo.
• Um banco de dados roubado não abre os valores. A chave da conta é derivada com PBKDF2-SHA256 em 1.000.000 iterações a partir da senha e de uma Secret Key de cerca de 128 bits, e nenhuma das duas chega ao servidor. Uma cópia completa do banco de dados é inútil para adivinhações.
• O servidor não consegue conceder acesso a si mesmo. As listas de acesso e todas as versões são assinadas. Clientes e agentes conferem as assinaturas e rejeitam estados mais antigos que o mais novo que já viram. Um dispositivo que nunca viu o estado mais novo não consegue detectar uma reversão.
• As funções são garantidas por chaves. Um membro com acesso ao development não tem a chave do production. Um Operator registra máquinas sem ver nenhum valor.
• O log revela adulterações. O log de auditoria é uma cadeia de hashes: editar, apagar ou inserir uma entrada aparece quando você o confere. Confira com um clique, ou exporte em JSONL e verifique fora do Crunu.
• Exibir e copiar também ficam registrados. Quando alguém revela, copia ou exporta um valor, o evento é registrado com a assinatura da pessoa e marcado como informado pelo cliente.
• Saídas deixam registro. A remoção de um membro gera um relatório de exposição: quais versões de quais ambientes a pessoa recebeu, quando e de qual endereço.
• Você pode conferir o cliente que roda. Os releases são assinados com Ed25519, o cliente web tem build reproduzível, e o app confere o próprio build com o release assinado a cada carregamento.
• O login tem limite de tentativas. 10 tentativas falhas por endereço e 5 por conta em 15 minutos, e “conta inexistente” parece igual a “senha errada”. Uma sessão dura 12 horas sem atividade e 7 dias no máximo, e não consegue mudar a senha nem excluir a conta sem a senha e a Secret Key.
• Segundo fator em todas as contas. Códigos de app autenticador e passkeys na web; no terminal, um código do app ou a aprovação de outro dispositivo conectado.

Algoritmos: AES-256-GCM para os valores, X25519 para selar chaves, Ed25519 para assinaturas, HKDF-SHA256 para derivação de chaves. O modelo de segurança explica como eles se encaixam.

Quando algo parece errado

• Alertas disparam em logins de um dispositivo novo, num código de registro reutilizado, numa máquina num endereço novo, num token de CI reutilizado, numa série de recusas, numa concessão expirada, num login com código de recuperação, em certificados perto de expirar, em chaves não entregues e em eventos de rede, como uma política afrouxada ou um acesso break-glass. Eles vão para um webhook assinado com HMAC ou para o e-mail.
• Restrições de rede entregam o production apenas a faixas de endereços permitidas. Afrouxar uma política espera 15 minutos, com um alerta e a opção de desfazer; o acesso break-glass de um Owner dura até 60 minutos, exige um motivo e gera um alerta.
• A ação Device compromised substitui as chaves da conta da pessoa, desconecta os outros dispositivos dela e rotaciona todos os ambientes dos quais ela tinha chave.
• Retenção sob o seu controle. O log de auditoria é mantido por 365 dias por padrão, e a organização só pode estender esse prazo, até 36.500 dias ou sem limite. O corte guarda um ponto de controle, então a cadeia continua verificável.

O que o Crunu não consegue proteger

• Um cliente web adulterado é o principal risco que resta, como em qualquer cofre que roda no navegador: uma página entregue por um servidor comprometido poderia capturar a senha e a Secret Key no login. As defesas são o manifesto assinado, com o qual o app se confere a cada carregamento, e uma política de segurança de conteúdo com integridade de sub-recursos, que bloqueia scripts de terceiros. Essa autoverificação roda na mesma página, por isso não consegue detectar um servidor que altere as duas coisas. As assinaturas dependem da chave de release, então não protegem contra quem tem essa chave.
• Valores já vistos não podem ser recuperados. A rotação protege as novas versões. Reemita os próprios valores em cada provedor.
• O servidor vê metadados: nomes de organizações, projetos, ambientes e máquinas, endereços de e-mail, o log de auditoria e os tamanhos e horários das versões.
• O servidor pode negar serviço ou descartar gravações. As exportações, as cópias offline e, se você hospeda o servidor, os backups são a defesa.
• Um malware num dispositivo onde as chaves são descriptografadas (um keylogger, uma extensão de navegador, root numa máquina) consegue ler o que esse dispositivo consegue ler.
• Um código de recuperação abre uma conta depois de um período de espera, sem segundo fator. A espera é garantida pelo servidor, então um servidor comprometido poderia pulá-la.
• As restrições de rede são aplicadas pelo servidor, não pela criptografia.
• Owners e Admins alcançam todos os ambientes compartilhados pela chave de recuperação da organização.
• Um servidor comprometido, em conluio com um membro removido, poderia manter um dispositivo novo num estado mais antigo da organização. Fechar isso por completo exigiria um log de transparência externo.
• Se o banco de dados do servidor e a chave própria dele vazarem juntos, os códigos de app autenticador ficam enfraquecidos como segundo fator.
• Sem single sign-on nem SCIM.

Cada limite, com o que fazer a respeito, está na página de limitações.

Encontrou algo?

Escreva para security@crunu.com. O nosso security.txt está em /.well-known/security.txt.

Documentação relacionada

• Como funciona a criptografia
• O que o servidor vê
• Limitações
• Log de auditoria
• Alertas
• Regras de rede
• Remova uma pessoa da equipe