Denne siden beskriver arkitekturens motstandsdyktighet. Flere mekanismer er fortsatt under aktiv utvikling; designet er låst og truslene er reelle. Hvis du ønsker implementeringsstatus per punkt, ta kontakt — vi deler den nåværende fremdriften under NDA.
Infrastruktur
Konstruert for å fortsette å fungere når noe svikter.
Hver del av Clavitors infrastruktur ble designet ved å stille det samme spørsmålet for hver avhengighet, hver leverandør, hvert lag: hva skjer når dette svikter? Vi jobbet gjennom det spørsmålet på tvers av hele stabelen og konstruerte arkitekturen slik at svaret alltid er det samme: hvelvet fortsetter å levere.
Denne siden lister opp hva vi har tenkt på. De spesifikke mekanismene — hvordan vi løser hver enkelt — forblir private; sofistikerte kunder kan motta den detaljen under NDA. Å publisere truslene er ærlighet om ingeniørarbeidet. Å publisere forsvaret er et gratis diagram for motstandere.
Det vi har konstruert for
Hyperskalare skytjenesteutfall
De store skyleverandørene går ned. Ikke ofte, men synlig, og når de gjør det, tar de store deler av internett med seg. Vi designet med antakelsen om at enhver enkelt hyperskaler til slutt vil ha en globalt dårlig dag. Clavitor fortsetter å levere påloggingsinformasjon når det skjer.
Regionale katastrofer og kinetiske hendelser
En regional hendelse — et droneangrep på et datasenter, et kutt i en undersjøisk kabel, en naturkatastrofe, en regional krig — kan ta en hel skyregion offline. 1. mars 2026 gikk begge AWS Midtøsten-regionene mørke i samme hendelse. Vi tok det som en lærdom, ikke et hypotetisk scenario. Arkitekturen behandler en regional hendelse som en rutinemessig feilmodus som kunder ikke merker.
Utfall hos DNS-leverandører
Hvis selskapet som hoster din DNS går ned, blir tjenesten din mørk selv om alle andre deler av stabelen din er sunne. Dette gjelder for Cloudflare, Route 53, alle store DNS-leverandører. Vi vurderte hva som skjer når vår DNS-leverandør har en dårlig dag.
Utfall hos sertifikatmyndigheter
Hvis sertifikatmyndigheten din er utilgjengelig når sertifikatet ditt trenger å fornyes, blir TLS-en din mørk. Hvis en sertifikatmyndighet blir kompromittert, blir alle sertifikater den har utstedt ugyldige. Vi vurderte hva som skjer med TLS når CA-infrastrukturen oppfører seg feil.
Problemer med domene-registrar
Hvis registrar-en din suspenderer kontoen din eller blir kompromittert, forsvinner domenet ditt eller blir omdirigert uavhengig av hvor DNS er hostet. Vi vurderte hva som skjer hvis registrar-en vår svikter.
Problemer med TLD-operatører
Organisasjonen som drifter et toppnivådomene (.com, .ai, .io) er i seg selv et enkelt feilpunkt. Mindre TLD-er driftes av mindre organisasjoner med mindre operasjonell dybde. Vi vurderte hva som skjer hvis en TLD-operatør har en dårlig uke.
Utfall hos e-postleverandører
Hvis e-postleverandøren din er nede, kommer ikke gjenopprettingskoder for kontoen frem, registreringsbekreftelser kommer ikke frem, kundeservice-inboksen er mørk. Vi vurderte hva som skjer med autentisering og gjenoppretting når e-postleverandøren vår er utilgjengelig — og avgjørende, hva som skjer med resten av produktet mens e-post er nede.
Avhengighet av SMS / telefonnummer
Mange tjenester faller tilbake på SMS for verifisering når e-post er nede. Vi vurderte dette og bestemte oss for å ikke gjøre det. Å be om et telefonnummer legger til en kategori personlige data vi ikke ønsker å samle inn, utsetter kunder for SIM-bytteangrep, og legger til enda en leverandøravhengighet. Vi valgte en bedre vei.
Utfall av operasjonell kontrollplan
Verktøyene vi bruker for å administrere vår egen infrastruktur kan selv gå ned: orkestreringsnettverket, koordineringslaget, utrullingspipelinen. Hver er et leverandørforhold som kan svikte. Vi vurderte konsekvensene av hver enkelt og reduserte gradvis vår avhengighet av leverandør-opererte kontrollplaner.
Programvarefeil
Den enkelt mest sannsynlige årsaken til et enhetlig utfall er en feil i vår egen programvare, utplassert overalt samtidig. Ingen geografisk distribusjon hjelper når hver kjørende kopi krasjer på samme måte. Vi vurderte dette og konstruerte våre utrullingspraksiser — kanari-utrullinger, rask tilbakerulling, nødknapper — deretter.
Leverandørhandlinger på kontonivå
Kontosuspensjon, faktureringsuenigheter, regulatoriske sperringer og håndhevelse av vilkår kan deaktivere ethvert enkelt leverandørforhold i ett slag. Vi vurderte konsekvensene av at hvert kritiske leverandørforhold ble ensidig avsluttet, og designet mot enkelt-leverandør-låsning på hvert lag.
Korrelerte feil
Noen hendelser tar ned flere ting samtidig — et stort kabelkutt som påvirker flere ruter, et koordinert angrep på tvers av tjenester, en naturkatastrofe som rammer både en primær og det som skulle være dens backup. Vi vurderte korrelerte feilmodi spesifikt: sviktet til "backuppen" akkurat når primæren også er nede. Arkitekturen er designet slik at ingen enkelt hendelse tar ned både en primær og dens fail-over.
Katastrofale avhengigheter av personlige data
Hvelvkunder skal ikke måtte velge mellom sikkerhet og gjenopprettbarheten av sine egne data. Vi vurderte hvert sted der brukerens hvelv avhenger av noe annet de kan miste: telefonnummeret deres, e-postkontoen deres, en enkelt enhet, et enkelt passord. Hver av disse ble enten eliminert eller konstruert rundt.
Tilgjengelighet for operasjonelt team
Et hvelvselskap må være tilgjengelig for sitt eget team under en hendelse. Vi vurderte hva som skjer med vår evne til å respondere når internett rundt våre egne operatører forringes.
Kryptografisk horisont
Kryptografi er ikke statisk. Vi vurderte den langsiktige migrasjonsveien for hver kryptografiske primitiv vi er avhengige av, inkludert post-kvante.
Hva vi ikke hevder å beskytte mot
Vi er eksplisitte om grensene for hva infrastrukturteknikk kan oppnå.
Ville tatt ned det globale internett i dager. Ingen infrastruktur kan hjelpe; kunder kan uansett ikke nå noe.
En klasse hendelser som ingen kommersiell infrastruktur kan forsvare seg mot ensidig.
Vi er ærlige om disse — og vi designer alt annet for å være motstandsdyktig under antakelsen om at de ikke vil skje.
Detaljer om arkitektur under NDA.
Listen ovenfor er hva vi vurderte. Detaljene om hvordan hvert forsvar er konstruert — den spesifikke topologien, leverandørvalgene, overgangsprosedyrene, de kryptografiske protokollene — deles med bedriftskunder under NDA, med deres sikkerhetsteam, i deres anskaffelsesprosess.