Esta página describe la postura de resiliencia de la arquitectura. Varios mecanismos aún están en desarrollo activo; el diseño está bloqueado y las amenazas son reales. Si desea el estado de implementación por elemento, contáctenos — compartiremos el progreso actual bajo NDA.
Infraestructura
Diseñado para seguir funcionando cuando algo no lo hace.
Cada parte de la infraestructura de Clavitor fue diseñada haciendo la misma pregunta para cada dependencia, cada proveedor, cada capa: ¿qué sucede cuando esto falla? Trabajamos esa pregunta en toda la pila y diseñamos la arquitectura para que la respuesta sea siempre la misma: la bóveda sigue prestando servicio.
Esta página enumera lo que hemos considerado. Los mecanismos específicos — cómo resolvemos cada uno — permanecen privados; los clientes sofisticados pueden recibir ese detalle bajo NDA. Publicar la lista de amenazas es honestidad sobre la ingeniería. Publicar las defensas es un diagrama gratuito para los adversarios.
Lo que hemos diseñado
Interrupciones de la nube a hiperescala
Los principales proveedores de nube se caen. No a menudo, pero sí visiblemente, y cuando lo hacen, se llevan consigo grandes partes de Internet. Diseñamos asumiendo que cualquier hiperescalador único tendrá eventualmente un día malo a nivel mundial. Clavitor continúa sirviendo credenciales cuando eso sucede.
Desastres regionales y eventos cinéticos
Un evento regional — un ataque con drones a un centro de datos, un corte de cable submarino, un desastre natural, una guerra regional — puede dejar una región de nube entera fuera de servicio. El 1 de marzo de 2026, ambas regiones de AWS en Oriente Medio quedaron a oscuras en el mismo incidente. Tomamos eso como una lección, no como una hipótesis. La arquitectura trata un evento regional como un modo de fallo rutinario que los clientes no notan.
Interrupciones del proveedor de DNS
Si la empresa que aloja su DNS se cae, su servicio queda a oscuras incluso si todas las demás partes de su pila están en buen estado. Esto es cierto para Cloudflare, Route 53, todos los principales proveedores de DNS. Consideramos qué sucede cuando nuestro proveedor de DNS tiene un mal día.
Interrupciones de la autoridad de certificación
Si su autoridad de certificación no es accesible cuando su certificado necesita renovarse, su TLS queda a oscuras. Si una autoridad de certificación se ve comprometida, todos los certificados que emitió quedan invalidados. Consideramos qué le sucede a TLS cuando la infraestructura de la CA se comporta de manera anómala.
Problemas con el registrador de dominios
Si su registrador suspende su cuenta o se ve comprometido, su dominio desaparece o se redirige independientemente de dónde se aloje el DNS. Consideramos qué sucede si nuestro registrador falla.
Problemas con el operador de TLD
La organización que administra un dominio de nivel superior (.com, .ai, .io) es en sí misma un único punto de fallo. Los TLD más pequeños son operados por organizaciones más pequeñas con menor profundidad operativa. Consideramos qué sucede si un operador de TLD tiene una mala semana.
Interrupciones del proveedor de correo electrónico
Si su proveedor de correo electrónico está caído, los códigos de recuperación de cuenta no llegan, las confirmaciones de registro no llegan, la bandeja de entrada de soporte al cliente está a oscuras. Consideramos qué le sucede a la autenticación y recuperación cuando nuestro proveedor de correo electrónico no es accesible — y, crucialmente, qué le sucede al resto del producto mientras el correo electrónico está caído.
Dependencia de SMS / número de teléfono
Muchos servicios recurren a SMS para verificación cuando el correo electrónico está caído. Consideramos esto y decidimos no hacerlo. Solicitar un número de teléfono agrega una categoría de datos personales que no queremos recopilar, expone a los clientes a ataques de intercambio de SIM y agrega otra dependencia de proveedor. Elegimos un camino mejor.
Interrupciones del plano de control operativo
Las herramientas que utilizamos para administrar nuestra propia infraestructura pueden caerse: la malla de orquestación, la capa de coordinación, el pipeline de implementación. Cada una es una relación con un proveedor que puede fallar. Consideramos las consecuencias de cada una y redujimos progresivamente nuestra dependencia de planos de control operados por proveedores.
Errores de software
La causa más probable de una interrupción uniforme es un error en nuestro propio software, desplegado en todas partes a la vez. Ninguna cantidad de distribución geográfica ayuda cuando cada copia en ejecución se bloquea de la misma manera. Consideramos esto y diseñamos nuestras prácticas de implementación — lanzamientos canarios, reversiones rápidas, interruptores de apagado — en consecuencia.
Acciones de proveedores a nivel de cuenta
La suspensión de cuentas, disputas de facturación, retenciones regulatorias y aplicación de términos de servicio pueden deshabilitar cualquier relación individual con un proveedor de un solo golpe. Consideramos las consecuencias de que cada relación crítica con un proveedor sea terminada unilateralmente, y diseñamos contra el bloqueo de un solo proveedor en cada capa.
Fallos correlacionados
Algunos eventos derriban múltiples cosas a la vez — un corte importante de cable que afecta varias rutas, un ataque coordinado entre servicios, un desastre natural que golpea tanto a un primario como a lo que se suponía que era su respaldo. Consideramos específicamente los modos de fallo correlacionados: el fallo del "respaldo" justo cuando el primario también está caído. La arquitectura está diseñada para que ningún evento único derribe tanto un primario como su conmutación por error.
Dependencias catastróficas de datos personales
Los clientes de la bóveda no deberían tener que elegir entre seguridad y recuperabilidad de sus propios datos. Consideramos cada lugar donde la bóveda del usuario depende de algo más que podría perder: su número de teléfono, su cuenta de correo electrónico, un solo dispositivo, una sola contraseña. Cada uno de esos fue eliminado o se diseñó en torno a ellos.
Alcanzabilidad del equipo operativo
Una empresa de bóvedas necesita ser accesible por su propio equipo durante un incidente. Consideramos qué sucede con nuestra capacidad de respuesta cuando Internet alrededor de nuestros propios operadores se degrada.
Horizonte criptográfico
La criptografía no es estática. Consideramos la ruta de migración a largo plazo para cada primitiva criptográfica de la que dependemos, incluida la post-cuántica.
Contra qué no afirmamos protegernos
Somos explícitos sobre los límites de lo que la ingeniería de infraestructura puede lograr.
Derribaría Internet global durante días. Nada que la infraestructura pueda hacer ayuda; los clientes no pueden acceder a nada de todos modos.
Una clase de evento contra la que ninguna infraestructura comercial puede defenderse unilateralmente.
Somos honestos acerca de estos — y diseñamos todo lo demás para que sea resiliente asumiendo que no sucederán.
Detalle de la arquitectura bajo NDA.
La lista anterior es lo que hemos considerado. El detalle de cómo se diseña cada defensa — la topología específica, las opciones de proveedor, los procedimientos de corte, los protocolos criptográficos — se comparte con los clientes empresariales bajo NDA, con sus equipos de seguridad, en su proceso de adquisición.