Esta página descreve a postura de resiliência da arquitetura. Vários mecanismos ainda estão em desenvolvimento ativo; o design está travado e as ameaças são reais. Se você quiser o status da implementação por item, entre em contato — compartilharemos o progresso atual sob NDA.
Infraestrutura
Projetado para continuar funcionando quando algo não funciona.
Cada parte da infraestrutura do Clavitor foi projetada fazendo a mesma pergunta para cada dependência, cada fornecedor, cada camada: o que acontece quando isso falha? Trabalhamos nessa questão em toda a pilha e projetamos a arquitetura para que a resposta seja sempre a mesma: o cofre continua atendendo.
Esta página lista o que pensamos. Os mecanismos específicos — como resolvemos cada um — permanecem privados; clientes sofisticados podem receber esses detalhes sob NDA. Publicar a lista de ameaças é honestidade sobre a engenharia. Publicar as defesas é um diagrama gratuito para adversários.
O que projetamos
Interrupções em nuvem de hiperescala
Os principais provedores de nuvem caem. Não com frequência, mas visivelmente, e quando o fazem, levam grandes partes da internet com eles. Projetamos com a suposição de que qualquer hiperescala única eventualmente terá um dia ruim globalmente. O Clavitor continua a servir credenciais quando isso acontece.
Desastres regionais e eventos cinéticos
Um evento regional — um ataque de drone a um data center, um corte de cabo submarino, um desastre natural, uma guerra regional — pode tirar uma região de nuvem inteira do ar. Em 1º de março de 2026, ambas as regiões do Oriente Médio da AWS ficaram offline no mesmo incidente. Levamos isso como uma lição, não uma hipótese. A arquitetura trata um evento regional como um modo de falha rotineiro que os clientes não percebem.
Interrupções no provedor de DNS
Se a empresa que hospeda seu DNS cair, seu serviço fica offline mesmo que todas as outras partes de sua pilha estejam saudáveis. Isso é verdade para Cloudflare, Route 53, todos os principais provedores de DNS. Consideramos o que acontece quando nosso provedor de DNS tem um dia ruim.
Interrupções na autoridade certificadora
Se sua autoridade certificadora estiver inacessível quando seu certificado precisar ser renovado, seu TLS ficará offline. Se uma autoridade certificadora for comprometida, todos os certificados que ela emitiu se tornarão inválidos. Consideramos o que acontece com o TLS quando a infraestrutura da CA se comporta mal.
Problemas com o registrador de domínio
Se o seu registrador suspender sua conta ou for comprometido, seu domínio desaparecerá ou será redirecionado, independentemente de onde o DNS esteja hospedado. Consideramos o que acontece se nosso registrador falhar.
Problemas com o operador de TLD
A organização que executa um domínio de nível superior (.com, .ai, .io) é, em si, um único ponto de falha. TLDs menores são operados por organizações menores com menos profundidade operacional. Consideramos o que acontece se um operador de TLD tiver uma semana ruim.
Interrupções no provedor de e-mail
Se o seu provedor de e-mail estiver inativo, os códigos de recuperação de conta não chegarão, as confirmações de inscrição não chegarão, a caixa de entrada de suporte ao cliente estará offline. Consideramos o que acontece com a autenticação e recuperação quando nosso provedor de e-mail está inacessível — e crucialmente, o que acontece com o resto do produto enquanto o e-mail está inativo.
Dependência de SMS / número de telefone
Muitos serviços recorrem ao SMS para verificação quando o e-mail está inativo. Consideramos isso e decidimos não fazê-lo. Solicitar um número de telefone adiciona uma categoria de dados pessoais que não queremos coletar, expõe os clientes a ataques de troca de SIM e adiciona outra dependência de fornecedor. Escolhemos um caminho melhor.
Interrupções no plano de controle operacional
As ferramentas que usamos para gerenciar nossa própria infraestrutura podem cair: a malha de orquestração, a camada de coordenação, o pipeline de implantação. Cada um é um relacionamento com um fornecedor que pode falhar. Consideramos as consequências de cada um e reduzimos progressivamente nossa dependência de planos de controle operados por fornecedores.
Bugs de software
A causa mais provável de uma interrupção uniforme é um bug em nosso próprio software, implantado em todos os lugares de uma vez. Nenhuma quantidade de distribuição geográfica ajuda quando cada cópia em execução falha da mesma maneira. Consideramos isso e projetamos nossas práticas de implantação — rollouts canários, rollback rápido, kill switches — de acordo.
Ações de fornecedor em nível de conta
Suspensão de conta, disputas de faturamento, retenções regulatórias e aplicação de termos de serviço podem desabilitar qualquer relacionamento individual com um fornecedor de uma só vez. Consideramos as consequências de cada relacionamento crítico com um fornecedor ser unilateralmente rescindido e projetamos contra o lock-in de fornecedor único em todas as camadas.
Falhas correlacionadas
Alguns eventos derrubam várias coisas ao mesmo tempo — um grande corte de cabo afetando várias rotas, um ataque coordenado entre serviços, um desastre natural que atinge tanto um primário quanto o que deveria ser seu backup. Consideramos especificamente modos de falha correlacionados: a falha "do backup" exatamente quando o primário também está inativo. A arquitetura é projetada para que nenhum evento único derrube um primário e seu fail-over.
Dependências catastróficas de dados pessoais
Clientes do cofre não deveriam ter que escolher entre segurança e recuperabilidade de seus próprios dados. Consideramos todos os lugares onde o cofre do usuário depende de algo que eles poderiam perder: seu número de telefone, sua conta de e-mail, um único dispositivo, uma única senha. Cada um desses foi eliminado ou contornado.
Alcançabilidade da equipe operacional
Uma empresa de cofre precisa ser alcançável por sua própria equipe durante um incidente. Consideramos o que acontece com nossa capacidade de responder quando a internet ao redor de nossos próprios operadores se degrada.
Horizonte criptográfico
A criptografia não é estática. Consideramos o caminho de migração de longo prazo para cada primitiva criptográfica em que dependemos, incluindo pós-quântica.
Contra o que não reivindicamos proteger
Somos explícitos sobre os limites do que a engenharia de infraestrutura pode alcançar.
Derrubaria a internet global por dias. Nada que a infraestrutura possa fazer ajuda; os clientes não conseguem acessar nada de qualquer maneira.
Uma classe de evento contra a qual nenhuma infraestrutura comercial pode se defender unilateralmente.
Somos honestos sobre isso — e projetamos todo o resto para ser resiliente com a suposição de que eles não acontecerão.
Detalhes da arquitetura sob NDA.
A lista acima é o que consideramos. O detalhe de como cada defesa é projetada — a topologia específica, as escolhas de fornecedores, os procedimentos de corte, os protocolos criptográficos — é compartilhado com clientes empresariais sob NDA, com suas equipes de segurança, em seu processo de aquisição.