一部の機能が停止しても動作し続けるよう設計されています。

設計で想定した事項

ハイパースケールクラウドの障害

主要なクラウドプロバイダーもダウンします。頻繁ではありませんが、ひとたび発生すれば大々的に報じられ、インターネットの広範な領域が影響を受けます。当社は、いずれかのハイパースケーラーで最終的にグローバル規模の重大な障害が発生するという前提で設計を行いました。そのような事態が発生しても、Clavitorは資格情報の提供を継続します。

地域災害および物理的攻撃

地域的な事象（データセンターへのドローン攻撃、海底ケーブルの切断、自然災害、地域紛争）は、クラウドリージョン全体をオフラインにする可能性があります。2026年3月1日には、AWSの中東2リージョンが同一のインシデントにより停止しました。当社はこれを単なる仮定ではなく教訓として受け止めています。本アーキテクチャでは、地域的な事象をお客様が気づかない程度の日常的な障害モードとして扱います。

DNSプロバイダーの障害

DNSをホストする企業がダウンすれば、スタックの他のすべての部分が正常であってもサービスは停止します。これはCloudflare、Route 53をはじめ、あらゆる主要DNSプロバイダーに当てはまります。当社は、DNSプロバイダーで重大な障害が発生した場合に何が起こるかを検討しました。

認証局の障害

証明書の更新時に認証局に接続できない場合、TLSは機能しなくなります。認証局が侵害されれば、発行されたすべての証明書が無効になります。当社は、認証局インフラストラクチャが正常に機能しなくなった場合にTLSへどのような影響が出るかを検討しました。

ドメインレジストラの問題

レジストラによってアカウントが停止されたり、レジストラ自体が侵害されたりした場合、DNSのホスト場所に関わらず、ドメインは消失するか、あるいはリダイレクトされます。当社は、レジストラで障害が発生した場合に何が起こるかを検討しました。

TLD運営機関の問題

トップレベルドメイン（.com、.ai、.io）を運営する組織自体が単一障害点となります。小規模なTLDは、運用リソースの乏しい小規模な組織によって運営されています。当社は、TLD運営機関で長期的な障害が発生した場合に何が起こるかを検討しました。

メールプロバイダーの障害

メールプロバイダーがダウンすれば、アカウント復旧コードもサインアップ確認メールも届かず、カスタマーサポートの受信トレイも機能しなくなります。当社は、メールプロバイダーに接続できない場合に認証と復旧プロセスへどのような影響が出るか、そして何より重要なのは、メールが停止している間に製品のその他の部分にどのような影響が出るかを検討しました。

SMS/電話番号への依存

多くのサービスでは、メールが停止した際のフォールバックとしてSMS認証を採用しています。当社もこれを検討しましたが、採用しないことを決定しました。電話番号の要求は、収集を望まない個人データの項目を増やすだけでなく、お客様をSIMスワップ攻撃のリスクにさらし、新たなベンダー依存を生み出します。当社はより優れたアプローチを選択しました。

運用コントロールプレーンの障害

自社インフラストラクチャの管理に使用するツール自体もダウンする可能性があります。オーケストレーションメッシュ、協調レイヤー、デプロイパイプラインなどです。これらはそれぞれ、障害が発生し得るベンダーとの契約関係です。当社はそれぞれの影響を検討し、ベンダーが運用するコントロールプレーンへの依存を段階的に削減しました。

ソフトウェアのバグ

広範囲に及ぶ一斉障害の最も可能性の高い原因は、一度にすべての環境へデプロイされた自社ソフトウェアのバグです。実行中のすべてのインスタンスが同じようにクラッシュする場合、いかに地理的に分散させていても意味がありません。当社はこれを考慮し、カナリアリリース、迅速なロールバック、キルスイッチといったデプロイメントのプラクティスを設計に組み込みました。

アカウントレベルのベンダーによる措置

アカウント停止、請求に関する紛争、規制による保留、利用規約の適用は、いずれも単一のベンダーとの契約を一度に無効化し得ます。当社は、重要なベンダーとの契約がすべて一方的に解除された場合の影響を検討し、あらゆるレイヤーで単一ベンダーへのロックインを回避する設計を行いました。

相関障害

一部の事象は複数のシステムを同時に停止させます。複数のルートに影響を与える大規模なケーブル切断、サービス全体への協調攻撃、プライマリシステムとバックアップシステムの両方に被害を与える自然災害などです。当社は相関障害モード、すなわちプライマリシステムが停止しているまさにその時にバックアップシステムも障害を起こす事態を特に想定しました。本アーキテクチャは、単一の事象によってプライマリシステムとそのフェイルオーバー先の両方が停止することがないよう設計されています。

個人データへの致命的な依存

ボールトをご利用のお客様が、セキュリティとご自身のデータの復旧可能性の二者択一を迫られることがあってはなりません。当社は、ユーザーのボールトが喪失リスクのある他の要素（電話番号、メールアカウント、単一のデバイス、単一のパスワード）に依存している箇所をすべて洗い出しました。そして、それらの依存関係を排除するか、あるいは回避する設計を施しました。

運用チームへの連絡経路

ボールトを提供する企業は、インシデント発生時に自社のチームから確実に連絡が取れる状態である必要があります。当社は、自社オペレーター周辺のインターネット環境が悪化した際に、インシデント対応能力へどのような影響が出るかを検討しました。

暗号技術の将来展望

暗号技術は静的なものではありません。当社は、ポスト量子暗号を含む、依存するすべての暗号プリミティブについて長期的な移行パスを検討しました。

保護を保証しない脅威

当社は、インフラストラクチャのエンジニアリングで達成できることの限界を明確にしています。

当社はこれらの点について率直に認めています。そして、それらが発生しないことを前提に、その他のすべての要素が耐障害性を持つよう設計しています。