Ta strona opisuje postawę odporności architektury. Wiele mechanizmów jest wciąż w fazie aktywnego rozwoju; projekt jest zablokowany, a zagrożenia są realne. Jeśli chcą Państwo poznać status implementacji poszczególnych elementów, prosimy o kontakt — udostępnimy aktualny postęp w ramach NDA.
Infrastruktura
Zaprojektowane, aby działać, gdy coś przestanie działać.
Każda część infrastruktury Clavitor została zaprojektowana poprzez zadanie tego samego pytania dla każdego zasobu, każdego dostawcy, każdej warstwy: co się stanie, gdy to zawiedzie? Przeanalizowaliśmy to pytanie w całym stosie technologicznym i zaprojektowaliśmy architekturę tak, aby odpowiedź zawsze brzmiała tak samo: sejf nadal działa.
Ta strona wymienia to, o czym myśleliśmy. Konkretne mechanizmy — jak rozwiązujemy każdy z nich — pozostają poufne; zaawansowani klienci mogą otrzymać te szczegóły w ramach NDA. Publikowanie listy zagrożeń to uczciwe podejście do inżynierii. Publikowanie zabezpieczeń to darmowy schemat dla przeciwników.
Co zaprojektowaliśmy
Awaryjność chmury na dużą skalę
Główni dostawcy chmury ulegają awarii. Nieczęsto, ale widocznie, a kiedy to się dzieje, zabierają ze sobą duże części internetu. Projektowaliśmy przy założeniu, że każdy pojedynczy dostawca chmury na dużą skalę w końcu będzie miał globalnie zły dzień. Clavitor nadal udostępnia poświadczenia, gdy to się dzieje.
Katastrofy regionalne i zdarzenia kinetyczne
Zdarzenie regionalne — atak dronem na centrum danych, przerwanie kabla podmorskiego, klęska żywiołowa, wojna regionalna — może wyłączyć cały region chmury. 1 marca 2026 r. oba regiony AWS na Bliskim Wschodzie zniknęły w tym samym incydencie. Potraktowaliśmy to jako lekcję, a nie hipotezę. Architektura traktuje zdarzenie regionalne jako rutynowy tryb awarii, którego klienci nie zauważają.
Awaryjność dostawcy DNS
Jeśli firma hostująca Państwa DNS ulegnie awarii, Państwa usługa zniknie, nawet jeśli każda inna część Państwa stosu działa poprawnie. Dotyczy to Cloudflare, Route 53, każdego głównego dostawcy DNS. Rozważaliśmy, co się stanie, gdy nasz dostawca DNS będzie miał zły dzień.
Awaryjność urzędu certyfikacji
Jeśli Państwa urząd certyfikacji jest niedostępny, gdy Państwa certyfikat wymaga odnowienia, Państwa TLS zniknie. Jeśli urząd certyfikacji zostanie skompromitowany, każdy wydany przez niego certyfikat stanie się nieważny. Rozważaliśmy, co stanie się z TLS, gdy infrastruktura CA będzie działać nieprawidłowo.
Problemy z rejestratorem domen
Jeśli Państwa rejestrator zawiesi Państwa konto lub zostanie skompromitowany, Państwa domena zniknie lub zostanie przekierowana, niezależnie od tego, gdzie hostowany jest DNS. Rozważaliśmy, co się stanie, jeśli nasz rejestrator zawiedzie.
Problemy z operatorem TLD
Organizacja zarządzająca domeną najwyższego poziomu (.com, .ai, .io) sama w sobie jest pojedynczym punktem awarii. Mniejsze TLD są zarządzane przez mniejsze organizacje o mniejszej głębokości operacyjnej. Rozważaliśmy, co się stanie, jeśli operator TLD będzie miał zły tydzień.
Awaryjność dostawcy poczty e-mail
Jeśli Państwa dostawca poczty e-mail jest niedostępny, kody odzyskiwania konta nie docierają, potwierdzenia rejestracji nie docierają, skrzynka wsparcia klienta jest niedostępna. Rozważaliśmy, co stanie się z uwierzytelnianiem i odzyskiwaniem, gdy nasz dostawca poczty e-mail będzie niedostępny — i co kluczowe, co stanie się z resztą produktu, gdy poczta e-mail będzie niedostępna.
Zależność od SMS / numeru telefonu
Wiele usług powraca do SMS w celu weryfikacji, gdy poczta e-mail jest niedostępna. Rozważaliśmy to i postanowiliśmy tego nie robić. Prośba o numer telefonu dodaje kategorię danych osobowych, których nie chcemy zbierać, naraża klientów na ataki SIM-swap i dodaje kolejną zależność od dostawcy. Wybraliśmy lepszą ścieżkę.
Awaryjność operacyjnego płaszczyzny sterowania
Narzędzia, których używamy do zarządzania naszą infrastrukturą, same mogą ulec awarii: siatka orkiestracji, warstwa koordynacji, potok wdrażania. Każdy z nich to relacja z dostawcą, która może zawieść. Rozważaliśmy konsekwencje każdego z nich i stopniowo zmniejszaliśmy naszą zależność od płaszczyzn sterowania obsługiwanych przez dostawców.
Błędy oprogramowania
Najbardziej prawdopodobną przyczyną jednolitej awarii jest błąd w naszym własnym oprogramowaniu, wdrożony wszędzie jednocześnie. Żadna ilość dystrybucji geograficznej nie pomaga, gdy każda działająca kopia ulega awarii w ten sam sposób. Rozważaliśmy to i odpowiednio zaprojektowaliśmy nasze praktyki wdrażania — wdrożenia kanarkowe, szybkie wycofywanie, wyłączniki awaryjne.
Działania dostawcy na poziomie konta
Zawieszenie konta, spory dotyczące rozliczeń, blokady regulacyjne i egzekwowanie warunków świadczenia usług mogą uniemożliwić każdą pojedynczą relację z dostawcą jednym pociągnięciem. Rozważaliśmy konsekwencje jednostronnego zakończenia każdej krytycznej relacji z dostawcą i zaprojektowaliśmy ochronę przed blokadą u jednego dostawcy na każdej warstwie.
Skorelowane awarie
Niektóre zdarzenia powodują jednoczesne awarie wielu rzeczy — przerwanie głównego kabla wpływające na kilka tras, skoordynowany atak na usługi, klęska żywiołowa uderzająca zarówno w główny, jak i w jego zapasowy system. Rozważaliśmy skorelowane tryby awarii: awarię "zapasowego" systemu dokładnie wtedy, gdy główny system również jest niedostępny. Architektura jest zaprojektowana tak, aby żadne pojedyncze zdarzenie nie spowodowało awarii zarówno systemu głównego, jak i jego przełączenia awaryjnego.
Katastrofalne zależności od danych osobowych
Klienci sejfu nie powinni wybierać między bezpieczeństwem a możliwością odzyskania własnych danych. Rozważaliśmy każde miejsce, w którym sejf klienta zależy od czegoś innego, co może stracić: numer telefonu, konto e-mail, pojedyncze urządzenie, pojedyncze hasło. Każde z nich zostało wyeliminowane lub zaprojektowane tak, aby działało inaczej.
Dostępność zespołu operacyjnego
Firma zajmująca się sejfami musi być dostępna dla swojego zespołu podczas incydentu. Rozważaliśmy, co stanie się z naszą zdolnością do reagowania, gdy internet wokół naszych operatorów ulegnie degradacji.
Horyzont kryptograficzny
Kryptografia nie jest statyczna. Rozważaliśmy długoterminową ścieżkę migracji dla każdego używanego przez nas prymitywu kryptograficznego, w tym postkwantowego.
Czego nie twierdzimy, że chronimy
Jesteśmy otwarci na temat ograniczeń tego, co inżynieria infrastruktury może osiągnąć.
Wyłączyłoby globalny internet na dni. Nic, co może zrobić infrastruktura, nie pomoże; klienci i tak nie mieliby dostępu do niczego.
Klasa zdarzeń, przed którymi żadna komercyjna infrastruktura nie może się jednostronnie obronić.
Jesteśmy wobec tego uczciwi — i projektujemy wszystko inne tak, aby było odporne przy założeniu, że to się nie wydarzy.
Szczegóły architektury w ramach NDA.
Powyższa lista to to, co rozważaliśmy. Szczegóły tego, jak zaprojektowano każde zabezpieczenie — konkretna topologia, wybór dostawców, procedury przełączania, protokoły kryptograficzne — są udostępniane klientom korporacyjnym w ramach NDA, wraz z ich zespołami ds. bezpieczeństwa, w procesie ich zakupu.