Эта страница описывает устойчивость архитектуры. Несколько механизмов находятся в активной разработке; дизайн зафиксирован, а угрозы реальны. Если Вам нужен статус реализации по пунктам, свяжитесь с нами — мы поделимся текущим прогрессом по 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-swap и добавляет еще одну зависимость от поставщика. Мы выбрали лучший путь.
Сбои операционной плоскости управления
Инструменты, которые мы используем для управления нашей собственной инфраструктурой, сами могут выйти из строя: оркестрационная сетка, слой координации, конвейер развёртывания. Каждый из них — это отношения с поставщиком, которые могут дать сбой. Мы учли последствия каждого и постепенно снижали нашу зависимость от плоскостей управления, управляемых поставщиками.
Программные ошибки
Единственная наиболее вероятная причина повсеместного сбоя — это ошибка в нашем собственном программном обеспечении, развернутом везде одновременно. Никакое географическое распределение не поможет, когда каждая запущенная копия аварийно завершает работу одинаково. Мы учли это и соответствующим образом спроектировали наши практики развертывания — поэтапное развертывание (canary rollouts), быстрый откат, аварийные выключатели.
Действия поставщиков на уровне аккаунта
Приостановка аккаунта, споры по биллингу, регуляторные ограничения и принудительное соблюдение условий обслуживания могут в одночасье отключить любые отношения с поставщиком. Мы учли последствия одностороннего прекращения всех критически важных отношений с поставщиками и спроектировали защиту от привязки к одному поставщику на каждом уровне.
Коррелированные сбои
Некоторые события выводят из строя несколько систем одновременно — крупный обрыв кабеля, затрагивающий несколько маршрутов, скоординированная атака на сервисы, стихийное бедствие, которое поражает как основной, так и предполагаемый резервный центр. Мы специально учли режимы коррелированных сбоев: отказ "резервного" именно тогда, когда основной также недоступен. Архитектура спроектирована так, чтобы ни одно событие не вывело из строя как основной, так и его резервный вариант.
Катастрофические зависимости от персональных данных
Клиенты Vault не должны выбирать между безопасностью и восстанавливаемостью своих собственных данных. Мы учли каждое место, где хранилище пользователя зависит от чего-то другого, что он может потерять: его номер телефона, его учетную запись электронной почты, одно устройство, один пароль. Каждое из них было либо устранено, либо обойдено.
Доступность операционной команды
Компания, предоставляющая хранилище, должна быть доступна для своей команды во время инцидента. Мы учли, что произойдет с нашей способностью реагировать, когда интернет вокруг наших операторов ухудшится.
Криптографический горизонт
Криптография не статична. Мы учли долгосрочный путь миграции для каждого криптографического примитива, от которого мы зависим, включая постквантовую криптографию.
Против чего мы не утверждаем, что защищаем
Мы явно указываем на пределы того, чего может достичь инжиниринг инфраструктуры.
Остановит глобальный интернет на несколько дней. Ничего, что может сделать инфраструктура, не поможет; клиенты все равно ни до чего не смогут добраться.
Класс событий, от которых ни одна коммерческая инфраструктура не может защититься в одностороннем порядке.
Мы честны в отношении этих моментов — и проектируем все остальное так, чтобы оно было устойчивым, исходя из предположения, что они не произойдут.
Детали архитектуры по NDA.
Список выше — это то, что мы рассмотрели. Детали того, как спроектирована каждая защита — конкретная топология, выбор поставщиков, процедуры переключения, криптографические протоколы — предоставляются корпоративным клиентам по NDA, их командам безопасности, в процессе их закупок.