あなたのクラウドVPNは今もホスティング事業者に依存している

OSを入れ、サービスを強化し、鍵を握っていると、サーバーは自分のものになった気がしてくる。だがそれは賃貸マンションと同じで、ドアの鍵は自分の管理下にあっても建物はそうではない。ハイパーバイザー、インスタンスの手前のネットワーク、そしてすべてを作り直せるアカウントは他人のものだ。この区別が、復旧計画が何をカバーすべきかを決める。そしてセルフホスティングが最も変えない部分でもある。

アカウントこそが本当の制御面

ホスティングのアカウントは、仮想マシン、そのディスク、スナップショット、パブリックアドレス、ネットワークルールを管理する。そのどれもがゲストにログインせずに変更できる。つまりアカウントは、多くのVPN解説が描く脅威モデルの外側にある。完璧なトンネル設定でも、ディスクを入れ替えるアカウント操作には耐えられない。

そのアカウントは別の資産として守る。独立した認証情報、ハードウェアに支えられた第二要素、そして誰かが実際に読む監査ログを用意する。VPNサービスと同じパスワード管理の項目を共有するのは、他のすべての統制を無意味にする誤りだ。

事業者の責任分担は、クラウド全般ではなく個別の製品について読む。共有責任モデルは層の分け方の参考になる例であり、他の事業者はそれを引き継ぐのではなく自社の境界を説明している。見るべきは、どの障害を自分が直すことになっているか、どれを報告するしかないかだ。

自分では管理できないインフラの出来事

ライブマイグレーション、ホストの保守、物理ノードのハードウェア障害、キャパシティ関連の出来事は、どれも事業者が独自の予定で処理する。再起動や短いパケット損失、アドレス変更が見えることはあっても、理由は見えない。インスタンスを固定点とみなす設計は、そのすべてをVPNの不具合と解釈してしまう。正しい対応は、消えるインスタンスに耐えるサービスにすることで、決して示されない原因を追うことではない。

バックアップはトンネルではなくこの層に属する。サーバー設定、識別情報、アドレス計画、許可するルートを、インスタンスに到達できるかどうかに依存しない場所へ置き、元のディスクなしで復元できることを確認する。

アドレスの挙動は個別に確認する価値がある。パブリックアドレスが停止、入れ替え、削除のどれを経ても残るかは割り当て方で決まり、この三つの操作は互換ではない。インシデントで急に問われる前に、どれに依存しているかを書き留めておく。

作り直した後に何が残るかを確かめる

すべてが動いているうちに復旧経路を作る。事業者が提供するコンソールや帯域外アクセスを特定し、トンネルなしで到達できることを確認し、壊れたノートPCや紛失した携帯に持っていかれない場所に認証情報を置く。ローカルのファイアウォール変更がトンネルを止めたとき、そのコンソールが唯一の戻り道になる。

curl -s http://169.254.169.254/latest/meta-data/instance-id
curl -s http://169.254.169.254/latest/meta-data/public-ipv4
cloud-init status --long

メタデータサービスは、ゲストからは他に見えないインスタンスの情報に答える。その正確なパスは事業者やプラットフォームによって異なるため、動かしている製品のドキュメントで確認する。そのうえでテスト用インスタンスを一度、統制された手順で作り直し、時間を測る。誰も実行していない復旧手順は仮説にすぎない。

作り直しがアドレス、ホスト鍵、ディスクの識別、クライアントが固定しているものに何をしたかを記録する。ホスト鍵をキャッシュしたクライアントは作り直しの後に警告を出すが、それは抑え込むべき不具合ではなく正しい挙動だ。

セルフホスティングが実際に変えるものを決める

自前のVPNを動かすと、信頼はVPN事業者からホスティング事業者と自分自身へ移る。それは確かな変化だが、第三者をなくすこととは違う。目的が商用VPNに通信を観測させないことだったなら、事業者は依然としてインスタンスのネットワーク、ディスク、請求記録を観測できる。

自分のログは自分のソフトウェアを語るもので、事業者が保持するインフラの記録をすべて語るわけではない。逆もまた真で、インフラの可視性は事業者が何を保存するかを示さない。どちらの問いも事業者の方針と自分の設定を必要とし、一方が他方の答えになることはない。

答えは分業として書き出す。どの層が壊れたのか、誰が直せるのか、その修理にどれだけかかるのか。セルフホスティングは信頼する相手を変える。この作業で役に立つのは、どの層についてその相手を信頼しているのかを正確に知ることだ。