Diese Seite beschreibt die Resilienzstrategie der Architektur. Mehrere Mechanismen befinden sich noch in aktiver Entwicklung; das Design steht fest und die Bedrohungen sind real. Wenn Sie den Implementierungsstatus einzelner Punkte erfahren möchten, kontaktieren Sie uns bitte — wir teilen den aktuellen Fortschritt unter NDA mit Ihnen.
Infrastruktur
Entwickelt, um weiterzuarbeiten, wenn etwas ausfällt.
Jeder Teil der Clavitor-Infrastruktur wurde unter der Berücksichtigung derselben Frage für jede Abhängigkeit, jeden Anbieter und jede Schicht entworfen: Was passiert, wenn dies ausfällt? Wir sind dieser Frage über den gesamten Stack hinweg nachgegangen und haben die Architektur so konzipiert, dass die Antwort immer dieselbe lautet: Der Tresor bleibt einsatzbereit.
Diese Seite listet auf, was wir berücksichtigt haben. Die spezifischen Mechanismen — wie wir jedes Problem lösen — bleiben vertraulich; anspruchsvolle Kunden können diese Details unter NDA anfordern. Die Veröffentlichung der Bedrohungsliste ist ein Zeichen von Ehrlichkeit in der Ingenieurskunst. Die Veröffentlichung der Abwehrmechanismen wäre jedoch eine kostenlose Anleitung für Angreifer.
Was wir berücksichtigt 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 entworfen, dass jeder einzelne Hyperscaler irgendwann einen globalen Ausfall erleidet. Clavitor stellt die Bereitstellung von Anmeldedaten auch dann sicher, wenn dies geschieht.
Regionale Katastrophen und kinetische Ereignisse
Ein regionales Ereignis — ein Drohnenangriff auf ein Rechenzentrum, ein Unterseekabelbruch, eine Naturkatastrophe, ein regionaler Krieg — kann eine gesamte Cloud-Region offline nehmen. Am 1. März 2026 fielen beide AWS-Regionen im Nahen Osten durch denselben Vorfall aus. Wir haben dies als Lehre und nicht als Hypothese betrachtet. Die Architektur behandelt ein regionales Ereignis als routinemäßigen Ausfallmodus, den Kunden nicht bemerken.
DNS-Anbieter-Ausfälle
Wenn das Unternehmen, das Ihr DNS hostet, ausfällt, wird Ihr Dienst nicht mehr erreichbar sein, 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 Ausfall hat.
Ausfälle von Zertifizierungsstellen (CA)
Wenn Ihre Zertifizierungsstelle nicht erreichbar ist, wenn Ihr Zertifikat erneuert werden muss, fällt Ihr TLS aus. Wenn eine Zertifizierungsstelle kompromittiert wird, wird jedes von ihr ausgestellte Zertifikat ungültig. Wir haben berücksichtigt, was mit TLS passiert, wenn die CA-Infrastruktur versagt.
Probleme mit Domain-Registraren
Wenn Ihr Registrar Ihr Konto suspendiert 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) verwaltet, stellt selbst einen Single Point of Failure dar. Kleinere TLDs werden von kleineren Organisationen mit weniger operativer Tiefe betrieben. Wir haben berücksichtigt, was passiert, wenn ein TLD-Betreiber eine kritische Phase durchläuft.
E-Mail-Anbieter-Ausfälle
Wenn Ihr E-Mail-Anbieter ausfällt, kommen keine Codes zur Kontowiederherstellung an, keine Anmeldebestätigungen, und das Postfach des Kundensupports 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 die E-Mail-Kommunikation unterbrochen ist.
Abhängigkeit von SMS / Telefonnummern
Viele Dienste greifen auf SMS zur Verifizierung zurück, wenn E-Mails nicht funktionieren. Wir haben dies geprüft und uns dagegen entschieden. Die Abfrage einer Telefonnummer fügt eine Kategorie personenbezogener Daten hinzu, die wir nicht sammeln möchten, setzt Kunden SIM-Swap-Angriffen aus und schafft eine weitere Anbieterabhängigkeit. Wir haben einen besseren Weg gewählt.
Ausfälle der operativen Control-Plane
Die Werkzeuge, die wir zur Verwaltung unserer eigenen Infrastruktur nutzen, können selbst ausfallen: das Orchestrierungs-Mesh, die Koordinationsschicht, die Deployment-Pipeline. Jede davon ist eine Anbieterbeziehung, die scheitern kann. Wir haben die Folgen jeder einzelnen betrachtet und unsere Abhängigkeit von anbietergesteuerten Control Planes schrittweise reduziert.
Softwarefehler
Die wahrscheinlichste Ursache für einen flächendeckenden Ausfall ist ein Fehler in unserer eigenen Software, der überall gleichzeitig implementiert wird. Keine geografische Verteilung hilft, wenn jede laufende Instanz auf die gleiche Weise abstürzt. Wir haben dies berücksichtigt und unsere Deployment-Praktiken — Canary-Rollouts, schnelles Rollback, Kill-Switches — entsprechend gestaltet.
Maßnahmen auf Account-Ebene durch Anbieter
Kontosperrungen, Abrechnungsstreitigkeiten, regulatorische Sperren und die Durchsetzung von Nutzungsbedingungen können jede einzelne Anbieterbeziehung mit einem Schlag beenden. Wir haben die Folgen betrachtet, falls eine kritische Anbieterbeziehung einseitig gekündigt wird, und haben bei jeder Schicht darauf ausgelegt, einen Single-Vendor-Lock-in zu vermeiden.
Korrelierte Ausfälle
Einige Ereignisse legen mehrere Systeme gleichzeitig lahm — ein großer Kabelbruch, der mehrere Routen betrifft, ein koordinierter Angriff über verschiedene Dienste hinweg oder eine Naturkatastrophe, die sowohl das Primärsystem als auch das vermeintliche Backup trifft. Wir haben korrelierte Ausfallmodi spezifisch betrachtet: das Versagen des "Backups" genau in dem Moment, in dem auch das Primärsystem ausfällt. Die Architektur ist so konzipiert, dass kein einzelnes Ereignis sowohl das Primärsystem als auch das Failover lahmlegt.
Katastrophale Abhängigkeiten von personenbezogenen Daten
Kunden des Tresors sollten nicht zwischen Sicherheit und der Wiederherstellbarkeit ihrer eigenen Daten wählen müssen. Wir haben jeden Punkt betrachtet, an dem der Tresor des Nutzers von etwas anderem abhängt, das er verlieren könnte: seiner Telefonnummer, seinem E-Mail-Konto, einem einzelnen Gerät oder einem einzelnen Passwort. Jeder dieser Punkte wurde entweder eliminiert oder durch technische Maßnahmen umgangen.
Erreichbarkeit des Betriebsteams
Ein Unternehmen, das Tresore verwaltet, muss während eines Vorfalls durch sein eigenes Team erreichbar sein. Wir haben berücksichtigt, was mit unserer Reaktionsfähigkeit passiert, wenn die Internetverbindung um unsere Techniker herum beeinträchtigt ist.
Kryptografischer Horizont
Kryptografie ist nicht statisch. Wir haben den langfristigen Migrationspfad für jede kryptografische Primitive, auf die wir angewiesen sind, berücksichtigt, einschließlich Post-Quanten-Kryptografie.
Was wir nicht zu schützen versprechen
Wir sind explizit in Bezug auf die Grenzen dessen, was Infrastruktur-Engineering leisten kann.
Dies würde das globale Internet für Tage lahmlegen. Nichts, was die Infrastruktur leisten kann, würde helfen; Kunden könnten ohnehin nichts erreichen.
Eine Art von Ereignis, gegen die keine kommerzielle Infrastruktur einseitig verteidigen kann.
Wir sind ehrlich in Bezug auf diese Punkte — und wir entwickeln alles andere so resilient, dass wir davon ausgehen können, dass sie nicht eintreten werden.
Architekturdetails unter NDA.
Die obige Liste beschreibt, was wir berücksichtigt haben. Die Details darüber, wie jede Abwehr technisch umgesetzt ist — die spezifische Topologie, die Anbieterwahl, die Umschaltverfahren, die kryptographischen Protokolle — werden Unternehmenskunden unter NDA mit deren Sicherheitsteams im Rahmen ihres Beschaffungsprozesses mitgeteilt.