Ця сторінка описує стійкість архітектури. Кілька механізмів ще перебувають у стадії активної розробки; дизайн зафіксовано, а загрози реальні. Якщо Вам потрібен статус реалізації за пунктами, зв'яжіться з нами — ми надамо поточний прогрес за угодою про нерозголошення (NDA).
Інфраструктура
Розроблено для роботи, коли щось виходить з ладу.
Кожна частина інфраструктури Clavitor розроблялася з одним і тим самим запитанням для кожної залежності, кожного постачальника, кожного рівня: що станеться, коли це вийде з ладу? Ми пройшли крізь це запитання на всіх рівнях стеку та розробили архітектуру так, щоб відповідь завжди була однією: сховище продовжує працювати.
Ця сторінка перелічує те, що ми розглянули. Конкретні механізми — як ми вирішуємо кожну проблему — залишаються конфіденційними; досвідчені клієнти можуть отримати цю деталь за угодою про нерозголошення (NDA). Публікація списку загроз — це чесність щодо нашого підходу до розробки. Публікація захисних заходів — це безкоштовна схема для зловмисників.
Те, для чого ми розробляли
Масштабні збої хмарних сервісів
Основні хмарні провайдери виходять з ладу. Нечасто, але помітно, і коли це відбувається, вони забирають із собою значну частину Інтернету. Ми розробляли з припущенням, що будь-який окремий гіперскейлер зрештою матиме глобальний поганий день. Clavitor продовжує надавати облікові дані, коли це відбувається.
Регіональні катастрофи та кінетичні події
Регіональна подія — удар дрона по дата-центру, обрив підводного кабелю, стихійне лихо, регіональна війна — може вивести з ладу цілий хмарний регіон. 1 березня 2026 року обидва регіони AWS на Близькому Сході були недоступні внаслідок одного інциденту. Ми сприйняли це як урок, а не як гіпотезу. Архітектура розглядає регіональну подію як звичайний режим відмови, який клієнти не помічають.
Збої DNS-провайдерів
Якщо компанія, яка обслуговує Ваш DNS, виходить з ладу, Ваш сервіс стає недоступним, навіть якщо всі інші частини Вашого стеку працюють справно. Це стосується Cloudflare, Route 53, кожного великого DNS-провайдера. Ми розглянули, що станеться, коли наш DNS-провайдер матиме поганий день.
Збої центрів сертифікації
Якщо Ваш центр сертифікації недоступний під час необхідності поновлення Вашого сертифіката, Ваш TLS стає недоступним. Якщо центр сертифікації скомпрометовано, кожен виданий ним сертифікат стає недійсним. Ми розглянули, що станеться з TLS, коли інфраструктура центру сертифікації працюватиме некоректно.
Проблеми з реєстратором доменів
Якщо Ваш реєстратор призупиняє Ваш обліковий запис або його скомпрометовано, Ваш домен зникає або перенаправляється незалежно від того, де розміщено DNS. Ми розглянули, що станеться, якщо наш реєстратор вийде з ладу.
Проблеми з операторами TLD
Організація, яка керує доменом верхнього рівня (.com, .ai, .io), сама по собі є єдиною точкою відмови. Менші TLD керуються меншими організаціями з меншою операційною глибиною. Ми розглянули, що станеться, якщо оператор TLD матиме поганий тиждень.
Збої поштових провайдерів
Якщо Ваш поштовий провайдер недоступний, коди для відновлення доступу не надходять, підтвердження реєстрації не надходять, скринька служби підтримки клієнтів не працює. Ми розглянули, що станеться з автентифікацією та відновленням доступу, коли наш поштовий провайдер недоступний — і, що найважливіше, що станеться з рештою продукту, поки пошта недоступна.
Залежність від SMS / номеру телефону
Багато сервісів повертаються до SMS для верифікації, коли пошта недоступна. Ми це врахували і вирішили не робити так. Запит номеру телефону додає категорію персональних даних, які ми не хочемо збирати, наражає клієнтів на атаки SIM-свопінгу та додає ще одну залежність від постачальника. Ми обрали кращий шлях.
Збої операційної площини керування
Інструменти, які ми використовуємо для керування власною інфраструктурою, можуть самі виходити з ладу: оркестраційний меш, координаційний шар, конвеєр розгортання. Кожен з них є відносинами з постачальником, які можуть дати збій. Ми розглянули наслідки кожного з них і поступово зменшили залежність від площин керування, керованих постачальниками.
Програмні помилки
Найбільш імовірною причиною одночасного збою є помилка у нашому власному програмному забезпеченні, розгорнутому всюди одночасно. Жодний географічний розподіл не допоможе, коли кожна запущена копія аварійно завершує роботу однаково. Ми це врахували і відповідно розробили наші практики розгортання — канарейкові розгортання, швидке відкочування, аварійні вимикачі.
Дії постачальників на рівні облікового запису
Призупинення облікового запису, суперечки щодо білінгу, регуляторні блокування та примусове виконання умов обслуговування можуть вимкнути будь-які відносини з постачальником одним махом. Ми розглянули наслідки одностороннього припинення всіх критичних відносин з постачальниками та розробили захист від залежності від одного постачальника на кожному рівні.
Корельовані збої
Деякі події призводять до одночасного виходу з ладу кількох систем — обрив великого кабелю, що впливає на кілька маршрутів, скоординована атака на різні сервіси, стихійне лихо, що вражає як основний, так і його резервний варіант. Ми спеціально розглянули режими корельованих збоїв: вихід з ладу "резервного" варіанту саме тоді, коли основний також не працює. Архітектура розроблена таким чином, щоб жодна окрема подія не вивела з ладу як основний, так і його резервний варіант.
Катастрофічні залежності від персональних даних
Клієнти сховища не повинні вибирати між безпекою та можливістю відновлення власних даних. Ми розглянули кожне місце, де сховище користувача залежить від чогось іншого, що він може втратити: номер телефону, обліковий запис електронної пошти, один пристрій, один пароль. Кожне з них було або усунуто, або обійдено засобами архітектури.
Доступність операційної команди
Компанія, що надає сховище, повинна бути доступною для своєї команди під час інциденту. Ми розглянули, що станеться з нашою здатністю реагувати, коли Інтернет навколо наших операторів погіршиться.
Криптографічний горизонт
Криптографія не є статичною. Ми розглянули довгостроковий шлях міграції для кожного криптографічного примітиву, від якого ми залежимо, включаючи постквантову криптографію.
Проти чого ми не стверджуємо, що захищаємо
Ми чітко визначаємо межі того, чого може досягти інженерія інфраструктури.
Зупинила б глобальний Інтернет на кілька днів. Інфраструктура нічим не допоможе; клієнти все одно ні до чого не зможуть отримати доступ.
Клас подій, проти яких жодна комерційна інфраструктура не може захиститися одноосібно.
Ми чесні щодо цього — і ми розробляємо все інше так, щоб воно було стійким, виходячи з припущення, що цього не станеться.
Деталі архітектури за угодою про нерозголошення (NDA).
Перелік вище — це те, що ми розглянули. Деталі того, як розроблено кожен захист — конкретна топологія, вибір постачальників, процедури переключення, криптографічні протоколи — надаються корпоративним клієнтам за угодою про нерозголошення (NDA), їхнім командам безпеки, у їхньому закупівельному процесі.