Diese Seite beschreibt die Ausfallsicherheit der Architektur. Mehrere Mechanismen befinden sich noch in aktiver Entwicklung; das Design ist festgelegt und die Bedrohungen sind real. Wenn Sie den Implementierungsstatus pro Punkt erfahren möchten, kontaktieren Sie uns – wir teilen Ihnen den aktuellen Fortschritt unter NDA mit.
Infrastruktur
Entwickelt, um weiter zu funktionieren, wenn etwas ausfällt.
Jeder Teil der Clavitor-Infrastruktur wurde entwickelt, indem für jede Abhängigkeit, jeden Anbieter, jede Schicht dieselbe Frage gestellt wurde: Was passiert, wenn dies ausfällt? Wir haben diese Frage über den gesamten Stack hinweg bearbeitet und die Architektur so entwickelt, dass die Antwort immer dieselbe ist: Der Tresor stellt weiterhin Anmeldedaten bereit.
Diese Seite listet auf, worüber wir nachgedacht haben. Die spezifischen Mechanismen – wie wir jedes Problem lösen – bleiben privat; anspruchsvolle Kunden können diese Details unter NDA erhalten. Die Veröffentlichung der Bedrohungsliste ist Ehrlichkeit über die Entwicklung. Die Veröffentlichung der Abwehrmaßnahmen ist eine kostenlose Skizze für Angreifer.
Was wir entwickelt haben
Hyperscale-Cloud-Ausfälle
Die großen Cloud-Anbieter fallen aus. Nicht oft, aber sichtbar, und wenn sie es tun, reißen sie große Teile des Internets mit sich. Wir haben unter der Annahme entwickelt, dass jeder einzelne Hyperscaler irgendwann einen globalen schlechten Tag haben wird. Clavitor liefert weiterhin Anmeldedaten, wenn dies geschieht.
Regionale Katastrophen und kinetische Ereignisse
Ein regionales Ereignis – ein Drohnenangriff auf ein Rechenzentrum, eine Unterbrechung eines Unterseekabels, eine Naturkatastrophe, ein regionaler Krieg – kann eine gesamte Cloud-Region offline nehmen. Am 1. März 2026 fielen beide AWS Middle East-Regionen im selben Vorfall aus. Wir haben das als Lektion genommen, nicht als Hypothese. Die Architektur behandelt ein regionales Ereignis als normalen Ausfallmodus, den Kunden nicht bemerken.
Ausfälle von DNS-Anbietern
Wenn das Unternehmen, das Ihr DNS hostet, ausfällt, ist Ihr Dienst nicht mehr erreichbar, selbst wenn alle anderen Teile Ihres Stacks einwandfrei funktionieren. Dies gilt für Cloudflare, Route 53 und jeden großen DNS-Anbieter. Wir haben berücksichtigt, was passiert, wenn unser DNS-Anbieter einen schlechten Tag hat.
Ausfälle von Zertifizierungsstellen
Wenn Ihre Zertifizierungsstelle nicht erreichbar ist, wenn Ihr Zertifikat erneuert werden muss, ist Ihre TLS-Verbindung nicht mehr verfügbar. Wenn eine Zertifizierungsstelle kompromittiert wird, werden alle von ihr ausgestellten Zertifikate ungültig. Wir haben berücksichtigt, was mit TLS passiert, wenn die CA-Infrastruktur fehlerhaft ist.
Probleme mit Domain-Registraren
Wenn Ihr Registrar Ihr Konto sperrt oder kompromittiert wird, verschwindet Ihre Domain oder wird umgeleitet, unabhängig davon, wo das DNS gehostet wird. Wir haben berücksichtigt, was passiert, wenn unser Registrar ausfällt.
Probleme mit TLD-Betreibern
Die Organisation, die eine Top-Level-Domain (.com, .ai, .io) betreibt, ist selbst ein Single Point of Failure. Kleinere TLDs werden von kleineren Organisationen mit geringerer operativer Tiefe betrieben. Wir haben berücksichtigt, was passiert, wenn ein TLD-Betreiber eine schlechte Woche hat.
Ausfälle von E-Mail-Anbietern
Wenn Ihr E-Mail-Anbieter ausfällt, kommen keine Codes zur Kontowiederherstellung an, keine Anmeldebestätigungen, die Kunden-Support-Inbox ist nicht erreichbar. Wir haben berücksichtigt, was mit der Authentifizierung und Wiederherstellung passiert, wenn unser E-Mail-Anbieter nicht erreichbar ist – und entscheidend, was mit dem Rest des Produkts passiert, während E-Mail ausfällt.
Abhängigkeit von SMS / Telefonnummern
Viele Dienste greifen bei E-Mail-Ausfällen auf SMS zur Verifizierung zurück. Wir haben dies berücksichtigt und uns dagegen entschieden. Die Abfrage einer Telefonnummer fügt eine Kategorie persönlicher Daten hinzu, die wir nicht sammeln möchten, setzt Kunden SIM-Swap-Angriffen aus und fügt eine weitere Anbieterabhängigkeit hinzu. Wir haben einen besseren Weg gewählt.
Ausfälle der operativen Kontrollfläche
Die Werkzeuge, die wir zur Verwaltung unserer eigenen Infrastruktur verwenden, können selbst ausfallen: das Orchestrierungs-Mesh, die Koordinationsschicht, die Bereitstellungspipeline. Jede ist eine Anbieterbeziehung, die fehlschlagen kann. Wir haben die Konsequenzen jedes einzelnen berücksichtigt und unsere Abhängigkeit von Anbieter-betriebenen Kontrollflächen schrittweise reduziert.
Softwarefehler
Die wahrscheinlichste Ursache für einen einheitlichen Ausfall ist ein Fehler in unserer eigenen Software, der überall gleichzeitig bereitgestellt wird. Keine geografische Verteilung hilft, wenn jede laufende Kopie auf dieselbe Weise abstürzt. Wir haben dies berücksichtigt und unsere Bereitstellungspraktiken – Canary-Rollouts, schnelles Rollback, Kill-Switches – entsprechend entwickelt.
Kontobezogene Anbieteraktionen
Kontosperrung, Abrechnungsstreitigkeiten, behördliche Auflagen und die Durchsetzung von Nutzungsbedingungen können jede einzelne Anbieterbeziehung mit einem Schlag deaktivieren. Wir haben die Konsequenzen jeder kritischen Anbieterbeziehung, die einseitig beendet wird, berücksichtigt und auf allen Ebenen gegen eine Abhängigkeit von einem einzigen Anbieter entwickelt.
Korrelierte Ausfälle
Einige Ereignisse führen gleichzeitig zum Ausfall mehrerer Dinge – ein großer Kabelbruch, der mehrere Routen betrifft, ein koordinierter Angriff auf Dienste, eine Naturkatastrophe, die sowohl ein primäres als auch sein Backup trifft. Wir haben korrelierte Ausfallmodi speziell berücksichtigt: den Ausfall des "Backups" genau dann, wenn auch das primäre ausfällt. Die Architektur ist so konzipiert, dass kein einzelnes Ereignis sowohl ein primäres als auch sein Failover zum Ausfall bringt.
Katastrophale Abhängigkeiten von persönlichen Daten
Tresorkunden sollten nicht zwischen Sicherheit und Wiederherstellbarkeit ihrer eigenen Daten wählen müssen. Wir haben jeden Punkt berücksichtigt, an dem der Tresor des Benutzers von etwas anderem abhängt, das er verlieren könnte: seine Telefonnummer, sein E-Mail-Konto, ein einzelnes Gerät, ein einzelnes Passwort. Jeder dieser Punkte wurde entweder eliminiert oder umgangen.
Erreichbarkeit des operativen Teams
Ein Tresorunternehmen muss während eines Vorfalls für sein eigenes Team erreichbar sein. Wir haben berücksichtigt, was mit unserer Reaktionsfähigkeit passiert, wenn das Internet um unsere eigenen Betreiber herum beeinträchtigt wird.
Kryptografischer Horizont
Kryptografie ist nicht statisch. Wir haben den langfristigen Migrationspfad für jedes kryptografische Primitiv, von dem wir abhängen, einschließlich Post-Quanten-Kryptografie, berücksichtigt.
Wogegen wir keinen Schutz beanspruchen
Wir sind explizit über die Grenzen dessen, was Infrastruktur-Engineering leisten kann.
Würde das globale Internet tagelang lahmlegen. Nichts, was die Infrastruktur tun kann, hilft; Kunden können sowieso nichts erreichen.
Eine Klasse von Ereignissen, gegen die keine kommerzielle Infrastruktur einseitig Abwehrmaßnahmen ergreifen kann.
Wir sind ehrlich darüber – und wir entwerfen alles andere so, dass es ausfallsicher ist, unter der Annahme, dass sie nicht eintreten werden.
Architekturelle Details unter NDA.
Die obige Liste ist was wir berücksichtigt haben. Die Details, wie jede Abwehr entwickelt ist – die spezifische Topologie, die Anbieterwahl, die Cutover-Verfahren, die kryptografischen Protokolle – werden mit Unternehmenskunden unter NDA, mit deren Sicherheitsteams, in deren Beschaffungsprozess geteilt.