レジストラのロックダウンと多層防御、どちらを選ぶべきか

ある朝目覚めると、会社が所有するすべてのドメイン（本番環境、ステージング、MXレコードを保持しているドメインまで）が、一晩のうちにドメインレジストラによって停止されている。デプロイは壊れていない。サーバーもクラッシュしていない。信頼と安全のチーム（より可能性が高いのは自動化された不正報告パイプライン）がスイッチを切り、インターネット上のプレゼンスがまるごと消えた。仮想的な話ではない。確認されていない不正報告、曖昧なツイート、数百万件のユーザーアップロードのうちたった1枚のフラグ付き画像などを理由に、レジストラがアカウントを無効化したという恐ろしい体験談が、sysadminのフォーラムには途切れず投稿されている。

私はインフラチームのインシデント対応に何年も携わってきたが、パターンはいつも同じだ。エンジニアはコンピュートには精巧な冗長化を施す（マルチAZ、マルチリージョン、フェイルオーバーのランブック）のに、再デプロイできない唯一の資産、つまりドメイン名そのものは、パスワードと場合によってはSMSコードで守られた1つのアカウントに置きっぱなしにする。本記事では、このリスクへの2つの考え方を比較する。伝統的なレジストラのロックダウン（信頼できるレジストラを選び、アカウントを堅牢化して、あとは相手を信頼する）と、多層防御（レジストラが裏切る前提で、その周りを設計する）だ。結論を先に言えば両方必要だが、午前3時に本当に助けてくれるのは後者である。

なぜレジストラは別種の単一障害点なのか

スタック内のほとんどの単一障害点は自分で制御できるものだ。データベースのプライマリ、NATゲートウェイ、メッセージブローカーは複製できるし、フェイルオーバー計画も自分で書いている。しかしレジストラは3つの理由で事情が違う。第一に、複製できない制御プレーンの依存先であること。同じドメインを2つのレジストラで管理することはできない。レジストリに登録された管理者は1社だけだ。第二に、レジストラの障害モードは遅いこと。通常の条件でもドメイン移管には5〜7日かかり、現在のレジストラがアカウントを停止していれば、移管を開始するための認証コードすら取得できないことがある。第三に、障害の性質が妙に敵対的なこと。攻撃者ではなく、あなたが見たこともない不正報告に基づいて、プロバイダー自身があなたに牙をむくのだ。

影響範囲も、多くの人が想定しているより悪い。レジストラがドメインを停止すると、通常はNSレコードを停止ページに向けるか、単に応答をやめる。もちろんウェブサイトは落ちる。だがそれだけではない。メール（MXレコードはDNSにある）も、コールバックがドメインを参照しているならSSOも、APIクライアントも、同じドメインにあるならステータスページも落ちる。そして個人的に一番気に入っているのは、復旧手順を受け取るためのメールアドレスまで道連れになることだ。レジストラアカウントのメールがadmin@yourdomain.comで、そのyourdomain.comが停止されていると、信頼されないアドレスからサポートに本人確認を試みることになる。この無限ループで丸一日インシデント対応が潰れたのを、私は実際に見てきた。

そして経済的なインセンティブもあなたに不利に動く。レジストラがプライベートエクイティに買収されると（大手のいくつかがそうなったように）、定石は予測しやすい。人によるサポートを削り、不正対応を自動化し、値上げする。自動化された不正対応システムが最適化するのは彼ら自身のリスクであって、あなたのリスクではない。後に無実だと判明するドメインを停止しても彼らに損失はない。後に有罪と判明するドメインを放置すれば、レジストリとのトラブルや悪評が返ってくる。どちらの方向に自動化が誤るか、予想はつくだろう。

アプローチ1：レジストラのロックダウン（単一障害点を固める）

ロックダウンの考え方は、レジストラが単一障害点であることを受け入れ、その一点をできるだけ堅くする、というものだ。明言しているかどうかは別として、実際に多くの企業がこの戦略で運用している。きちんと実施すると次のようになる。

• 価格ではなくサポート品質でレジストラを選ぶ。ドメイン1件あたり年3ドル節約しても、1日のダウンタイムに比べれば無意味だ。電話サポートがあり、大規模ポートフォリオなら専任の担当者がいて、万一の際に自国の法管轄で訴えられる会社を選ぶ。
• すべてのドメインでレジストラロック（clientTransferProhibited）を有効にし、重要なものにはレジストリロックをかける。レジストリロックでは、ネームサーバーや移管の変更の前に、帯域外の確認（通常はパスフレーズを使った電話確認）が必要になる。面倒だが、それが狙いだ。
• ハードウェアキーかTOTPによる2要素認証を使い、SMSは使わない。説得力のあるチャットの作り話でサポート担当者に2FAを外させられた話は枚挙にいとまがない。今では「ハードウェアキーなしではアカウント変更不可」という方針を打ち出すレジストラもある。それを選ぼう。
• レジストラアカウント専用のロールベースのメールアドレスを用意する。そのアドレスは、同じレジストラで登録したドメインのものであってはならない。domains-admin@example.org のように、まったく別のところで登録されたドメインを使う。
• アクセスできる人を絞る。名前の分かる2〜3人に限り、認証情報は社内のパスワード管理基盤に置く。スプレッドシートに共有ログインを書いてはいけない。
• すべてを文書化する。アカウント番号、PIN、サポートのエスカレーション経路、アカウント確認に使った正確な本人確認書類。インシデント対応のランブックに記載しておく。

ロックダウンには確かな強みがある。最も多いレジストラの大事故を防げるのだ。それは押収ではなく、乗っ取りである。ソーシャルエンジニアリングによる移管やアカウント乗っ取りは、長年にわたり価値の高いドメインを盗んできた。レジストリロックとハードウェア2FAを組み合わせれば、そのほぼすべてを止められる。さらに安価で、継続的なエンジニアリング作業も不要だ。

しかし不都合な真実がある。ロックダウンが守ってくれるのは攻撃者からであって、レジストラ本体からではない。上に挙げた制御はすべて、レジストラが運用しているものだ。彼らの不正対応自動化があなたのアカウントを無効化すれば、レジストラロックはあなた自身を締め出す存在になり、サポートPINはあなたが到達できないシステムの中にあり、それを覆せる担当者は、前四半期にサポートが「最適化」されたせいでもういないかもしれない。誤検知の単純なケースでさえ復旧に6時間以上かかったという報告があり、停止が週末にまたがると数日に及ぶ騒動になる。ロックダウンは必要だ。しかし十分ではない。

アプローチ2：多層防御（レジストラに裏切られる前提で設計する）

多層防御の考え方は、より暗い前提から出発する。悪意、自動化、ミスのいずれによるにせよ、いつかレジストラがドメインを止めるので、サポートの待ち行列が回ってくる前にオンラインに戻らなければならない、というものだ。これは壊滅的障害に備える防御的エンジニアリングと同じ発想である。障害を防ぐのではなく、障害を乗り越えられるようにするのだ。

中核となる手法は、普通はまとめられているレイヤーを分離することだ。小規模な企業の多くは、ドメインをレジストラで買い、そのレジストラのDNSを使い、同じ会社のホスティングに載せ、メールも任せている。これでは単一障害点が1つのアカウントに4つ積み重なっている。分離しよう。

• ドメイン登録：安定性とサポートで選んだレジストラA。
• 権威DNS：独立したDNSプロバイダーB（または2社によるデュアルプライマリ構成）。コードとして管理する。
• ホスティング：ワークロードに合う場所を選び、AともBとも無関係にする。
• メール：専用プロバイダーを使い、AとBのアカウント復旧用アドレスは、さらに別のドメインに置く。
• 予備ドメイン：別のレジストラで事前に用意したフォールバック用ドメイン。TLS証明書を発行しておき、最重要サービスの最小構成をすでに応答させておく。

予備ドメインは強調する価値がある。ほとんどの人がやっていないうえ、最もレバレッジの効く一手だからだ。主要ドメインが停止されたとき、DNSのTTLやリゾルバーのキャッシュがあるため、「バックアップに切り替える」だけでは済まない。バックアップはインシデントより前に存在し、ウォームアップされ、名前解決できる状態になっていなければならない。例えばexample-status.netのように別のレジストラで登録したフォールバックに、ステータスページ、インシデント連絡、緊急用MXレコードを載せておけば、会社の存続に関わる障害が、気まずい火曜日の出来事に変わる。

DNSのコード化：誰もが飛ばしがちなレイヤー

実際のインシデントで2回見たことがある失敗がある。レジストラの停止から復旧し、すべてを再びオンラインにしたら、DNSが間違っていた。ゾーンの「正」のソースがレジストラのWeb UIで、それがインシデント中はアクセスできず、そもそも誰の記憶とも食い違っていたからだ。障害中に200件のレコードを持つゾーンファイルを記憶から組み直すのは、独特の苦しさがある。以前書いたように、DNSの設定ミスは通常時でも本番環境を壊し続けている。レジストラの障害時には、それが壊滅的になる。

解決策は地味だ。DNSゾーンをバージョン管理されたコードとして管理し、CIでデプロイする。dnscontrolやTerraformのDNSプロバイダーといったツールを使えば、ゾーンを宣言的に記述し、複数のプロバイダーへ反映できる。こうすればDNSの状態は、どのプロバイダーの制御プレーンを失っても生き残る。「DNSプロバイダーBへフェイルオーバーする」は、英雄的なコピペ作業ではなく、1行の変更とデプロイで済む。

# dnsconfig.js — one zone, two providers, deployed by CI
var REG_NONE = NewRegistrar('none');
var DSP_CLOUDFLARE = NewDnsProvider('cloudflare');
var DSP_ROUTE53 = NewDnsProvider('route53');
D('example.com', REG_NONE,
DnsProvider(DSP_CLOUDFLARE),
DnsProvider(DSP_ROUTE53),   // dual-authoritative: either can die
A('@', '203.0.113.10'),
A('www', '203.0.113.10'),
MX('@', 10, 'mail.example.net.'),   // MX on a DIFFERENT TLD/provider domain
TXT('@', 'v=spf1 include:_spf.example.net -all'),
CNAME('status', 'statuspage.example.net.')
);

デュアル権威DNSは過小評価されている。ほとんどのリゾルバーは、列挙されたネームサーバーすべてを喜んで試すので、片方のプロバイダーに障害が起きても（大手DNSプロバイダーにも障害は起きる）名前解決は続く。問題は両方を同期させ続けることだが、それこそDNSのコード化が無償で提供してくれるものだ。それがなければ、デュアルプロバイダーのDNSは設定のずれを生む装置になり、単一プロバイダーより悪いと言えるかもしれない。

TTLについては一つ注意がある。チームは「パフォーマンスのため」にTTLを86400まで引き上げがちだが、インシデント時に、インターネットの四分の一が古いネームサーバーのレコードを丸一日キャッシュしていたと気づくことになる。ネームサーバー関連のレコードや、緊急時に変更するかもしれないものは、TTLを300〜900秒に保つこと。クエリ量の増加は、機動性に比べれば無視できるコストだ。

直接対決：どちらのアプローチが勝つのか

トレードオフをはっきり言おう。両戦略は異なる脅威と異なる組織を前提に最適化されているからだ。

• 脅威モデル：ロックダウンは乗っ取りやソーシャルエンジニアリング、つまり統計的に多い災害に強い。多層防御はレジストラ側の障害（不正対応の自動化、アカウントの押収、倒産、サポートの崩壊）に強い。
• コスト：ロックダウンはほぼ費用がかからない。レジストリロックの料金、ハードウェアキー、規律くらいだ。多層防御には、2つ目のプロバイダーの請求、予備ドメイン、CIの仕組み、設定のずれを防ぐための継続的な注意が必要になる。
• 復旧時間：押収のシナリオでは、ロックダウンだけのチームはサポートの待ち行列次第になる（聞いた体験談の全てで数時間から数日）。予備ドメインを温めてある多層防御のチームは、数分から数時間で復旧する。
• 運用負荷：ロックダウンは設定したら放置できる。多層防御は、メンテナンスしなければ劣化する。テストされていない予備ドメインや期限切れの証明書は、セキュリティの見せかけにすぎない。
• 組織への適合：SaaSプロダクトを1つ持つ5人規模のスタートアップは、フルのロックダウンに加え、最も安価な多層防御の2つ、すなわち外部DNSのコード化とドメイン外の復旧用メールを導入すべきだ。ドメインを失えば収益が消えてしまう企業は、多層防御のスタック全体が必要だ。

ロックダウンはドメインを攻撃者から守る。多層防御はビジネスをレジストラから守る。あなたは両方に晒されているので、両方が必要だ。

手遅れになるまで誰も書かない復旧ランブック

どの構えを選ぶにせよ、押収時のランブックは今すぐ書いておくこと。うまくいったインシデントはすべてランブックがあった。大失敗はその場の即興だった。次の項目を順番に含めるべきだ。影響範囲の確認（1ドメインだけか、アカウント全体か。whoisのステータスコード、たとえばclientHoldやserverHoldを確認する）、記録済みのアカウント識別子を使ってサポートチケットを起票する、予備ドメインを有効化しステータス連絡を更新する、停止されたドメインに依存しない経路で顧客に通知する、そして移管手続きを並行して開始する。解決を待ってから離脱を決めてはいけない。

地味な部分の予行演習もしておこう。ハードウェアキーを使い、クリーンなデバイスからレジストラにログインできるか？ 停止されたドメインのSSOの裏にあるパスワードマネージャーなしで？ レジストリロックのパスフレーズは、オンライン当番が見つけられる場所にあるか？ チームはデータベースのフェイルオーバーを四半期ごとにテストするが、レジストラの復旧は一度もテストしない。レジストラの障害は、他のすべてに到達するためのSSOを道連れにするのだから、その優先順位は逆になっている。

私の推奨

ロックダウンは完全に行おう。半日の作業で済み、最も起こりやすい攻撃を防げる。そのうえで、多層防御を次の3点だけ、この順番で導入する。まず権威DNSをレジストラから移し、コードとして管理すること。次にレジストラアカウントの復旧用メールを、別のレジストラで取得したドメインに移すこと。そして証明書、ステータスページ、緊急用MXを備えたウォームな予備ドメインを立ち上げること。この3つで、年間数百ドルで主要な障害モードをカバーできる。フルのデュアルレジストラ・デュアルDNSのアーキテクチャは、ドメインを1日全部失うといくらかかるかを説明できる組織のために取っておこう。その数字が6桁（10万ドル以上）に届くなら、何をすべきかはもう分かっているはずだ。

それでもまだ主に価格でレジストラを選んでいるなら、やめよう。格安レジストラ市場は、人間の判断を自動化で置き換えることに利害を持つ所有者の下に統合されつつある。その自動化は、誤検知であなたを喜んで停止し、チケットには木曜日になってやっと対応する。ドメインは、コンテナイメージから再デプロイできない唯一のインフラだ。そういうものとして扱おう。