Questa pagina descrive la postura di resilienza dell'architettura. Diversi meccanismi sono ancora in fase di sviluppo attivo; il design è bloccato e le minacce sono reali. Se desidera lo stato di implementazione per elemento, ci contatti — condivideremo i progressi attuali sotto NDA.
Infrastruttura
Progettato per continuare a funzionare quando qualcosa non va.
Ogni parte dell'infrastruttura di Clavitor è stata progettata ponendo la stessa domanda per ogni dipendenza, ogni fornitore, ogni strato: cosa succede quando questo fallisce? Abbiamo analizzato questa domanda sull'intero stack e progettato l'architettura in modo che la risposta sia sempre la stessa: la cassaforte continua a servire.
Questa pagina elenca ciò a cui abbiamo pensato. I meccanismi specifici — come risolviamo ciascuno di essi — rimangono privati; i clienti sofisticati possono ricevere tali dettagli sotto NDA. Pubblicare l'elenco delle minacce è un'onestà riguardo all'ingegneria. Pubblicare le difese è un diagramma gratuito per gli avversari.
Ciò per cui abbiamo progettato
Interruzioni cloud su larga scala
I principali provider cloud vanno offline. Non spesso, ma visibilmente, e quando lo fanno portano con sé gran parte di Internet. Abbiamo progettato partendo dal presupposto che qualsiasi singolo hyperscaler avrà alla fine una giornata disastrosa a livello globale. Clavitor continua a fornire credenziali quando ciò accade.
Disastri regionali ed eventi cinetici
Un evento regionale — un attacco di droni a un data center, il taglio di un cavo sottomarino, un disastro naturale, una guerra regionale — può mettere offline un'intera regione cloud. Il 1° marzo 2026, entrambe le regioni AWS Medio Oriente sono andate offline nello stesso incidente. L'abbiamo preso come una lezione, non un'ipotesi. L'architettura tratta un evento regionale come una modalità di guasto di routine che i clienti non notano.
Interruzioni del provider DNS
Se l'azienda che ospita il Suo DNS va offline, il Suo servizio scompare anche se ogni altra parte del Suo stack è integra. Questo vale per Cloudflare, Route 53, ogni principale provider DNS. Abbiamo considerato cosa succede quando il nostro provider DNS ha una brutta giornata.
Interruzioni dell'autorità di certificazione
Se la Sua autorità di certificazione è irraggiungibile quando il Suo certificato necessita di rinnovo, il Suo TLS si disattiva. Se un'autorità di certificazione viene compromessa, ogni certificato da essa emesso diventa non valido. Abbiamo considerato cosa succede al TLS quando l'infrastruttura della CA si comporta male.
Problemi con il registrar di domini
Se il Suo registrar sospende il Suo account o viene compromesso, il Suo dominio scompare o viene reindirizzato indipendentemente da dove è ospitato il DNS. Abbiamo considerato cosa succede se il nostro registrar fallisce.
Problemi con l'operatore TLD
L'organizzazione che gestisce un dominio di primo livello (.com, .ai, .io) è essa stessa un singolo punto di fallimento. I TLD più piccoli sono gestiti da organizzazioni più piccole con minore profondità operativa. Abbiamo considerato cosa succede se un operatore TLD ha una brutta settimana.
Interruzioni del provider di posta elettronica
Se il tuo provider di posta elettronica è offline, i codici di recupero account non arrivano, le conferme di iscrizione non arrivano, la casella di posta del supporto clienti è inattiva. Abbiamo considerato cosa succede all'autenticazione e al recupero quando il nostro provider di posta elettronica è irraggiungibile — e, soprattutto, cosa succede al resto del prodotto mentre l'email è offline.
Dipendenza da SMS / numeri di telefono
Molti servizi ricorrono agli SMS per la verifica quando l'email è offline. Abbiamo considerato questo e abbiamo deciso di non farlo. Richiedere un numero di telefono aggiunge una categoria di dati personali che non vogliamo raccogliere, espone i clienti ad attacchi di SIM-swap e aggiunge un'ulteriore dipendenza dal fornitore. Abbiamo scelto una strada migliore.
Interruzioni del piano di controllo operativo
Gli strumenti che utilizziamo per gestire la nostra infrastruttura possono a loro volta andare offline: il mesh di orchestrazione, il livello di coordinamento, la pipeline di distribuzione. Ciascuno è una relazione con un fornitore che può fallire. Abbiamo considerato le conseguenze di ciascuno e ridotto progressivamente la nostra dipendenza da piani di controllo gestiti da fornitori.
Bug software
La causa più probabile di un'interruzione uniforme è un bug nel nostro software, distribuito ovunque contemporaneamente. Nessuna distribuzione geografica aiuta quando ogni copia in esecuzione si blocca nello stesso modo. Abbiamo considerato questo e progettato di conseguenza le nostre pratiche di distribuzione — rollout canary, rollback rapido, kill switch.
Azioni dei fornitori a livello di account
Sospensioni dell'account, controversie di fatturazione, blocchi normativi e applicazione dei Termini di Servizio possono disabilitare qualsiasi singola relazione con un fornitore in un colpo solo. Abbiamo considerato le conseguenze di ogni relazione critica con un fornitore interrotta unilateralmente e progettato contro il lock-in a fornitore singolo a ogni livello.
Fallimenti correlati
Alcuni eventi causano il malfunzionamento di più cose contemporaneamente — il taglio di un cavo principale che interessa più percorsi, un attacco coordinato tra servizi, un disastro naturale che colpisce sia un primario che quello che doveva essere il suo backup. Abbiamo considerato specificamente le modalità di guasto correlate: il guasto del "backup" proprio quando anche il primario è offline. L'architettura è progettata in modo che nessun singolo evento possa causare il guasto sia del primario che del suo fail-over.
I clienti della cassaforte non dovrebbero dover scegliere tra sicurezza e recuperabilità dei propri dati.
I clienti di Vault non dovrebbero dover scegliere tra sicurezza e recuperabilità dei propri dati. Abbiamo considerato ogni punto in cui la cassaforte dell'utente dipende da qualcos'altro che potrebbe perdere: il proprio numero di telefono, il proprio account email, un singolo dispositivo, una singola password. Ognuno di questi è stato eliminato o aggirato.
Raggiungibilità del team operativo
Un'azienda di casseforti deve essere raggiungibile dal proprio team durante un incidente. Abbiamo considerato cosa succede alla nostra capacità di rispondere quando Internet intorno ai nostri operatori degrada.
Orizzonte crittografico
La crittografia non è statica. Abbiamo considerato il percorso di migrazione a lungo termine per ogni primitiva crittografica da cui dipendiamo, inclusa la post-quantistica.
Ciò che non pretendiamo di proteggere
Siamo espliciti sui limiti di ciò che l'ingegneria dell'infrastruttura può ottenere.
Metterebbe offline Internet globale per giorni. Nulla che l'infrastruttura possa fare aiuta; i clienti non possono raggiungere nulla comunque.
Una classe di eventi contro cui nessuna infrastruttura commerciale può difendersi unilateralmente.
Siamo onesti riguardo a questi — e progettiamo tutto il resto per essere resiliente partendo dal presupposto che non accadranno.
Dettagli dell'architettura sotto NDA.
L'elenco sopra è ciò che abbiamo considerato. Il dettaglio di come ogni difesa è progettata — la topologia specifica, le scelte dei fornitori, le procedure di cutover, i protocolli crittografici — viene condiviso con i clienti enterprise sotto NDA, con i loro team di sicurezza, nel loro processo di approvvigionamento.