Deze pagina beschrijft de veerkracht van de architectuur. Verschillende mechanismen zijn nog in actieve ontwikkeling; het ontwerp is vastgelegd en de bedreigingen zijn reëel. Als je de implementatiestatus per item wilt weten, neem contact op — we delen de huidige voortgang onder NDA.
Infrastructuur
Ontworpen om te blijven werken als er iets misgaat.
Elk deel van Clavitor's infrastructuur is ontworpen door voor elke afhankelijkheid, elke leverancier, elke laag dezelfde vraag te stellen: wat gebeurt er als dit faalt? We hebben die vraag door de hele stack uitgewerkt en de architectuur zo ontworpen dat het antwoord altijd hetzelfde is: de kluis blijft beschikbaar.
Deze pagina geeft weer waar we over hebben nagedacht. De specifieke mechanismen — hoe we elk probleem oplossen — blijven privé; geavanceerde klanten kunnen die details onder NDA ontvangen. Het publiceren van de lijst met bedreigingen is eerlijkheid over de engineering. Het publiceren van de verdedigingen is een gratis diagram voor tegenstanders.
Waar we voor hebben ontworpen
Hyperscale cloud-uitval
De grote cloudproviders vallen uit. Niet vaak, maar zichtbaar, en als ze dat doen, nemen ze grote delen van het internet mee. We hebben ontworpen met de aanname dat elke individuele hyperscaler uiteindelijk een wereldwijd slechte dag zal hebben. Clavitor blijft inloggegevens leveren wanneer dat gebeurt.
Regionale rampen en kinetische gebeurtenissen
Een regionale gebeurtenis — een droneaanval op een datacenter, een onderzeese kabelbreuk, een natuurramp, een regionale oorlog — kan een hele cloudregio offline halen. Op 1 maart 2026 gingen beide AWS Middle East-regio's offline door hetzelfde incident. We hebben dat als les genomen, niet als hypothetisch scenario. De architectuur behandelt een regionale gebeurtenis als een routineuze faalmodus die klanten niet merken.
DNS-provider-uitval
Als het bedrijf dat je DNS host uitvalt, verdwijnt je service, zelfs als al het andere in je stack gezond is. Dit geldt voor Cloudflare, Route 53, elke grote DNS-provider. We hebben overwogen wat er gebeurt als onze DNS-provider een slechte dag heeft.
Certificaatautoriteit-uitval
Als je certificaatautoriteit onbereikbaar is wanneer je certificaat moet vernieuwen, verdwijnt je TLS. Als een certificaatautoriteit gecompromitteerd is, worden alle door haar uitgegeven certificaten ongeldig. We hebben overwogen wat er met TLS gebeurt als de CA-infrastructuur zich misdraagt.
Problemen met domeinregistrar
Als je registrar je account schorst of gecompromitteerd raakt, verdwijnt je domein of wordt het omgeleid, ongeacht waar de DNS wordt gehost. We hebben overwogen wat er gebeurt als onze registrar faalt.
TLD-operator-problemen
De organisatie die een top-level domein (.com, .ai, .io) beheert, is zelf een enkel storingspunt. Kleinere TLD's worden beheerd door kleinere organisaties met minder operationele diepgang. We hebben overwogen wat er gebeurt als een TLD-operator een slechte week heeft.
E-mailprovider-uitval
Als je e-mailprovider uitvalt, komen herstelcodes voor accounts niet aan, komen aanmeldingsbevestigingen niet aan, is de klantenservice-inbox onbereikbaar. We hebben overwogen wat er gebeurt met authenticatie en herstel wanneer onze e-mailprovider onbereikbaar is — en cruciaal, wat er gebeurt met de rest van het product terwijl e-mail uitvalt.
Afhankelijkheid van SMS / telefoonnummer
Veel services vallen terug op SMS voor verificatie wanneer e-mail uitvalt. We hebben dit overwogen en besloten het niet te doen. Het vragen om een telefoonnummer voegt een categorie persoonlijke gegevens toe die we niet willen verzamelen, stelt klanten bloot aan SIM-swap-aanvallen en voegt een extra leveranciersafhankelijkheid toe. We hebben een betere weg gekozen.
Uitval van operationele control-planes
De tools die we gebruiken om onze eigen infrastructuur te beheren, kunnen zelf uitvallen: de orchestratiemesh, de coördinatielaag, de implementatiepijplijn. Elk is een leveranciersrelatie die kan falen. We hebben de gevolgen van elk overwogen en onze afhankelijkheid van door leveranciers beheerde control-planes geleidelijk verminderd.
Softwarefouten
De meest waarschijnlijke oorzaak van een uniforme uitval is een bug in onze eigen software, die overal tegelijk wordt geïmplementeerd. Geen enkele geografische distributie helpt wanneer elke draaiende kopie op dezelfde manier crasht. We hebben dit overwogen en onze implementatiepraktijken — canary rollouts, snelle rollback, kill switches — dienovereenkomstig ontworpen.
Acties van leveranciers op accountniveau
Accountopschorting, factureringsgeschillen, wettelijke blokkades en handhaving van servicevoorwaarden kunnen elke individuele leveranciersrelatie in één klap uitschakelen. We hebben de gevolgen overwogen van het eenzijdig beëindigen van elke kritieke leveranciersrelatie en hebben ontworpen tegen single-vendor lock-in op elk niveau.
Gecorreleerde storingen
Sommige gebeurtenissen schakelen meerdere dingen tegelijk uit — een grote kabelbreuk die meerdere routes treft, een gecoördineerde aanval op services, een natuurramp die zowel een primaire als de beoogde back-up treft. We hebben specifiek gecorreleerde faalmodi overwogen: het falen van "de back-up" precies wanneer de primaire ook uitvalt. De architectuur is zo ontworpen dat geen enkele gebeurtenis zowel een primaire als de fail-over uitschakelt.
Catastrofale afhankelijkheden van persoonlijke gegevens
Kluisklanten hoeven niet te kiezen tussen beveiliging en herstelbaarheid van hun eigen gegevens. We hebben elke plek overwogen waar de kluis van de gebruiker afhankelijk is van iets anders dat ze kunnen verliezen: hun telefoonnummer, hun e-mailaccount, een enkel apparaat, een enkel wachtwoord. Elk van deze is geëlimineerd of eromheen ontworpen.
Bereikbaarheid van het operationele team
Een kluisbedrijf moet bereikbaar zijn voor zijn eigen team tijdens een incident. We hebben overwogen wat er gebeurt met ons vermogen om te reageren wanneer het internet rond onze eigen operators verslechtert.
Cryptografische horizon
Cryptografie staat niet stil. We hebben het migratiepad op lange termijn overwogen voor elke cryptografische primitieve waar we van afhankelijk zijn, inclusief post-kwantum.
Waar we ons niet tegen beschermen
We zijn expliciet over de grenzen van wat infrastructuurengineering kan bereiken.
Zou het wereldwijde internet dagenlang platleggen. Niets wat infrastructuur kan doen helpt; klanten kunnen sowieso niets bereiken.
Een klasse van gebeurtenissen waartegen commerciële infrastructuur niet eenzijdig kan verdedigen.
We zijn hier eerlijk over — en we ontwerpen al het andere veerkrachtig met de aanname dat ze niet zullen gebeuren.
Architectuurdetails onder NDA.
De bovenstaande lijst is waar we over hebben nagedacht. De details van hoe elke verdediging is ontworpen — de specifieke topologie, de leverancierskeuzes, de overdrachtsprocedures, de cryptografische protocollen — worden gedeeld met enterprise-klanten onder NDA, met hun beveiligingsteams, in hun inkoopproces.