Halaman ini menjelaskan postur ketahanan arsitektur. Beberapa mekanisme masih dalam pengembangan aktif; desainnya sudah final dan ancamannya nyata. Jika Anda menginginkan status implementasi berdasarkan item, hubungi kami — kami akan membagikan kemajuan saat ini dengan NDA.
Infrastruktur
Direkayasa agar tetap berfungsi saat ada komponen yang gagal.
Setiap bagian dari infrastruktur Clavitor dirancang dengan mengajukan pertanyaan yang sama untuk setiap dependensi, setiap vendor, setiap lapisan: apa yang terjadi jika ini gagal? Kami menelusuri pertanyaan itu di seluruh stack dan merancang arsitektur sehingga jawabannya selalu sama: brankas tetap melayani.
Halaman ini mencantumkan apa yang kami pikirkan. Mekanisme spesifik — bagaimana kami menyelesaikan masing-masing — tetap bersifat pribadi; pelanggan tingkat lanjut dapat menerima detail tersebut dengan NDA. Menerbitkan daftar ancaman adalah bentuk transparansi dalam perancangan. Menerbitkan mekanisme pertahanan sama saja memberikan diagram gratis kepada musuh.
Apa yang kami rancang
Gangguan cloud skala besar
Penyedia cloud utama mengalami gangguan. Tidak sering, tetapi terlihat jelas, dan ketika itu terjadi, mereka melumpuhkan sebagian besar internet. Kami merancang dengan asumsi bahwa setiap hyperscaler pada akhirnya akan mengalami gangguan berskala global. Clavitor terus melayani kredensial ketika hal itu terjadi.
Bencana regional dan peristiwa kinetik
Insiden regional — serangan drone di pusat data, pemutusan kabel bawah laut, bencana alam, perang regional — dapat melumpuhkan seluruh region cloud. Pada 1 Maret 2026, kedua region AWS Timur Tengah mengalami gangguan dalam insiden yang sama. Kami menjadikannya pelajaran, bukan sekadar hipotesis. Arsitektur memperlakukan insiden regional sebagai mode kegagalan rutin yang tidak disadari oleh pelanggan.
Gangguan penyedia DNS
Jika perusahaan yang menghosting DNS Anda mengalami gangguan, layanan Anda akan lumpuh meskipun semua bagian lain dari stack Anda berjalan normal. Ini berlaku untuk Cloudflare, Route 53, dan setiap penyedia DNS utama. Kami mempertimbangkan apa yang terjadi ketika penyedia DNS kami mengalami gangguan.
Gangguan otoritas sertifikat
Jika otoritas sertifikat Anda tidak dapat dijangkau saat sertifikat Anda perlu diperpanjang, TLS Anda tidak berfungsi. Jika otoritas sertifikat disusupi, setiap sertifikat yang dikeluarkannya menjadi tidak valid. Kami mempertimbangkan apa yang terjadi pada TLS ketika infrastruktur CA bermasalah.
Masalah pendaftar domain
Jika pendaftar Anda menangguhkan akun Anda atau disusupi, domain Anda menghilang atau dialihkan terlepas dari di mana DNS dihosting. Kami mempertimbangkan apa yang terjadi jika pendaftar kami mengalami gangguan.
Masalah operator TLD
Organisasi yang menjalankan domain tingkat atas (.com, .ai, .io) itu sendiri merupakan titik kegagalan tunggal. TLD yang lebih kecil dioperasikan oleh organisasi yang lebih kecil dengan kapasitas operasional yang lebih terbatas. Kami mempertimbangkan apa yang terjadi jika operator TLD mengalami masalah berkepanjangan.
Gangguan penyedia email
Jika penyedia email Anda mengalami gangguan, kode pemulihan akun tidak terkirim, konfirmasi pendaftaran tidak terkirim, kotak masuk dukungan pelanggan tidak dapat diakses. Kami mempertimbangkan apa yang terjadi pada otentikasi dan pemulihan ketika penyedia email kami tidak dapat dijangkau — dan yang terpenting, apa yang terjadi pada sisa produk saat email mengalami gangguan.
Ketergantungan SMS / nomor telepon
Banyak layanan beralih ke SMS untuk verifikasi ketika email mengalami gangguan. Kami mempertimbangkan hal ini dan memutuskan untuk tidak melakukannya. Meminta nomor telepon menambahkan kategori data pribadi yang tidak ingin kami kumpulkan, mengekspos pelanggan ke serangan SIM-swap, dan menambahkan ketergantungan pada vendor lain. Kami memilih pendekatan yang lebih baik.
Gangguan bidang kontrol operasional
Alat yang kami gunakan untuk mengelola infrastruktur kami sendiri dapat mengalami gangguan: mesh orkestrasi, lapisan koordinasi, pipeline deployment. Masing-masing melibatkan hubungan dengan vendor yang dapat mengalami gangguan. Kami mempertimbangkan konsekuensi dari masing-masing dan secara bertahap mengurangi ketergantungan kami pada control plane yang dioperasikan vendor.
Bug perangkat lunak
Penyebab tunggal yang paling mungkin dari gangguan massal adalah bug dalam perangkat lunak kami sendiri, yang di-deploy di mana-mana secara bersamaan. Distribusi geografis sejauh apa pun tidak akan membantu ketika setiap salinan yang berjalan crash dengan cara yang sama. Kami mempertimbangkan hal ini dan merancang praktik deployment kami — canary rollout, rollback cepat, kill switch — sesuai dengan itu.
Tindakan vendor tingkat akun
Penangguhan akun, perselisihan penagihan, pemblokiran regulasi, dan penegakan ToS dapat menonaktifkan hubungan vendor tunggal secara langsung. Kami mempertimbangkan konsekuensi dari setiap hubungan vendor penting yang diakhiri secara sepihak, dan merancang sistem untuk menghindari lock-in vendor tunggal di setiap lapisan.
Kegagalan yang berkorelasi
Beberapa insiden melumpuhkan banyak komponen sekaligus — pemutusan kabel utama yang memengaruhi beberapa rute, serangan terkoordinasi di berbagai layanan, bencana alam yang melanda sistem utama maupun cadangannya. Kami secara khusus mempertimbangkan mode kegagalan yang berkorelasi: kegagalan "cadangan" tepat ketika sistem utama juga mengalami gangguan. Arsitektur dirancang sedemikian rupa sehingga tidak ada satu insiden pun yang melumpuhkan sistem utama dan failover-nya.
Ketergantungan data pribadi yang katastropik
Pelanggan brankas seharusnya tidak perlu memilih antara keamanan dan pemulihan data mereka sendiri. Kami mempertimbangkan setiap titik di mana brankas pengguna bergantung pada hal lain yang bisa mereka kehilangan aksesnya: nomor telepon mereka, akun email mereka, satu perangkat, satu kata sandi. Masing-masing faktor tersebut telah dihilangkan atau diatasi melalui perancangan.
Keterjangkauan tim operasional
Perusahaan brankas perlu dapat dijangkau oleh timnya sendiri selama insiden. Kami mempertimbangkan apa yang terjadi pada kemampuan kami untuk merespons ketika internet di sekitar operator kami mengalami degradasi.
Cakrawala kriptografi
Kriptografi tidak statis. Kami mempertimbangkan jalur migrasi jangka panjang untuk setiap primitif kriptografi yang kami andalkan, termasuk pasca-kuantum.
Apa yang tidak kami klaim mampu kami lindungi
Kami bersikap eksplisit mengenai batasan dari apa yang dapat dicapai oleh perancangan infrastruktur.
Akan melumpuhkan internet global selama berhari-hari. Tidak ada yang dapat dilakukan oleh infrastruktur; pelanggan tetap tidak dapat mengakses apa pun.
Kelas insiden yang tidak dapat ditangkal oleh infrastruktur komersial secara sepihak.
Kami bersikap jujur mengenai hal ini — dan kami merancang segala hal lainnya agar tangguh dengan asumsi bahwa hal tersebut tidak akan terjadi.
Detail arsitektur dengan NDA.
Daftar di atas adalah apa yang kami pertimbangkan. Detail bagaimana setiap pertahanan dirancang — topologi spesifik, pilihan vendor, prosedur cutover, protokol kriptografi — dibagikan kepada pelanggan Enterprise dengan NDA, bersama tim keamanan mereka, dalam proses pengadaan mereka.