Denne side beskriver arkitekturens modstandsdygtighed. Flere mekanismer er stadig under aktiv udvikling; designet er låst, og truslerne er reelle. Hvis du ønsker implementeringsstatus pr. punkt, kontakt os — vi deler den aktuelle fremgang under NDA.
Infrastruktur
Designet til at blive ved med at fungere, når noget ikke gør.
Hver del af Clavitors infrastruktur blev designet ved at stille det samme spørgsmål for hver afhængighed, hver leverandør, hvert lag: hvad sker der, når dette fejler? Vi arbejdede os igennem det spørgsmål på tværs af hele stakken og designede arkitekturen, så svaret altid er det samme: boksen bliver ved med at levere.
Denne side lister, hvad vi har tænkt over. De specifikke mekanismer — hvordan vi løser hver enkelt — forbliver private; sofistikerede kunder kan modtage disse detaljer under NDA. Offentliggørelse af trusselslisten er ærlighed om ingeniørarbejdet. Offentliggørelse af forsvarsmekanismerne er et gratis diagram for modstandere.
Hvad vi har designet til
Hyperscale cloud-nedbrud
De store cloud-udbydere går ned. Ikke ofte, men synligt, og når de gør det, tager de store dele af internettet med sig. Vi designede med antagelsen om, at enhver enkelt hyperscaler i sidste ende vil have en globalt dårlig dag. Clavitor fortsætter med at levere loginoplysninger, når det sker.
Regionale katastrofer og kinetiske begivenheder
En regional begivenhed — et droneangreb på et datacenter, et undersøisk kabelbrud, en naturkatastrofe, en regional krig — kan tage en hel cloud-region offline. Den 1. marts 2026 gik begge AWS Mellemøsten-regioner mørke i samme hændelse. Vi tog det som en lektion, ikke et hypotetisk scenarie. Arkitekturen behandler en regional begivenhed som en rutinemæssig fejltilstand, som kunderne ikke bemærker.
DNS-udbydernedbrud
Hvis firmaet, der hoster din DNS, går ned, bliver din tjeneste mørk, selvom alle andre dele af din stak er sunde. Dette gælder for Cloudflare, Route 53, enhver stor DNS-udbyder. Vi overvejede, hvad der sker, når vores DNS-udbyder har en dårlig dag.
Nedbrud hos certifikatmyndigheder
Hvis din certifikatmyndighed er utilgængelig, når dit certifikat skal fornyes, bliver din TLS mørk. Hvis en certifikatmyndighed kompromitteres, bliver alle certifikater, den har udstedt, ugyldige. Vi overvejede, hvad der sker med TLS, når CA-infrastrukturen opfører sig forkert.
Problemer med domæneregistrar
Hvis din registrar suspenderer din konto eller bliver kompromitteret, forsvinder dit domæne eller omdirigeres, uanset hvor DNS er hostet. Vi overvejede, hvad der sker, hvis vores registrar fejler.
Problemer med TLD-operatører
Organisationen, der driver et topdomæne (.com, .ai, .io), er i sig selv et enkelt fejlepunkt. Mindre TLD'er drives af mindre organisationer med mindre operationel dybde. Vi overvejede, hvad der sker, hvis en TLD-operatør har en dårlig uge.
Nedbrud hos e-mailudbydere
Hvis din e-mailudbyder er nede, ankommer koder til konto-gendannelse ikke, tilmeldingsbekræftelser ankommer ikke, kundeservice-indbakken er mørk. Vi overvejede, hvad der sker med godkendelse og gendannelse, når vores e-mailudbyder er utilgængelig — og afgørende, hvad der sker med resten af produktet, mens e-mail er nede.
Afhængighed af SMS / telefonnummer
Mange tjenester falder tilbage på SMS til verifikation, når e-mail er nede. Vi overvejede dette og besluttede ikke at gøre det. At bede om et telefonnummer tilføjer en kategori af personlige data, som vi ikke ønsker at indsamle, udsætter kunder for SIM-swap-angreb og tilføjer endnu en leverandørafhængighed. Vi valgte en bedre vej.
Nedbrud i operationel kontrolplan
De værktøjer, vi bruger til at administrere vores egen infrastruktur, kan selv gå ned: orkestrerings-meshet, koordineringslaget, udrulnings-pipelinen. Hver er et leverandørforhold, der kan fejle. Vi overvejede konsekvenserne af hver enkelt og reducerede gradvist vores afhængighed af leverandørdrevne kontrolplaner.
Softwarefejl
Den mest sandsynlige årsag til et ensartet nedbrud er en fejl i vores egen software, udrullet overalt på én gang. Ingen geografisk distribution hjælper, når hver kørende kopi crasher på samme måde. Vi overvejede dette og designede vores udrulningspraksis — canary-udrulninger, hurtig rollback, kill switches — derefter.
Leverandøraktioner på kontoniveau
Kontosuspension, faktureringsuenigheder, regulatoriske tilbageholdelser og håndhævelse af servicevilkår kan deaktivere ethvert enkelt leverandørforhold med et snuptag. Vi overvejede konsekvenserne af, at ethvert kritisk leverandørforhold blev ensidigt opsagt, og designede mod enkelt-leverandør-lock-in på alle niveauer.
Korrelerede fejl
Nogle begivenheder tager flere ting ned på én gang — et stort kabelbrud, der påvirker flere ruter, et koordineret angreb på tværs af tjenester, en naturkatastrofe, der rammer både en primær og dens formodede backup. Vi overvejede specifikt korrelerede fejltilstande: fejlen af "backuppen", lige når primæren også er nede. Arkitekturen er designet, så ingen enkelt begivenhed tager både en primær og dens fail-over ned.
Katastrofale afhængigheder af personlige data
Boks-kunder bør ikke skulle vælge mellem sikkerhed og muligheden for at gendanne deres egne data. Vi overvejede alle steder, hvor brugerens boks afhænger af noget andet, de kunne miste: deres telefonnummer, deres e-mailkonto, en enkelt enhed, en enkelt adgangskode. Hver af disse blev enten elimineret eller der blev designet løsninger til den.
Operationel teams rækkevidde
Et boks-firma skal være tilgængeligt for sit eget team under en hændelse. Vi overvejede, hvad der sker med vores evne til at reagere, når internettet omkring vores egne operatører forringes.
Kryptografisk horisont
Kryptografi er ikke statisk. Vi overvejede den langsigtede migrationsvej for enhver kryptografisk primitiv, vi afhænger af, inklusive post-kvante.
Hvad vi ikke påstår at beskytte imod
Vi er eksplicitte omkring grænserne for, hvad infrastruktur-ingeniørarbejde kan opnå.
Ville tage det globale internet ned i dagevis. Intet, infrastruktur kan gøre, hjælper; kunder kan alligevel ikke nå noget.
En klasse af begivenheder, som ingen kommerciel infrastruktur kan forsvare sig imod ensidigt.
Vi er ærlige omkring disse — og vi designer alt andet til at være modstandsdygtigt med den antagelse, at de ikke vil ske.
Arkitekturdetaljer under NDA.
Listen ovenfor er hvad vi har overvejet. Detaljerne om hvordan hver forsvarsmekanisme er designet — den specifikke topologi, leverandørvalg, overgangsprocedurer, kryptografiske protokoller — deles med enterprise-kunder under NDA, med deres sikkerhedsteams, i deres indkøbsproces.