要約

  • 2019年に公表されたCISA、ICANN、Mandiant、Cisco Talosの資料は、相互に関連するDNS変更管理上の失敗類型を示すが、単一の攻撃者、被害者一覧、作戦を証明する一つの事件記録ではない。
  • DNSの説明責任は、制度上の威信ではなく、DNS状態を承認、記録、公開、観測、制限、復旧できる実務上の支配力に沿って配分されるべきである。
  • 運用上の連鎖は、登録者アカウント、レジストラ、EPP取引、レジストリ保持情報、親ゾーンの委任、権威DNS、再帰リゾルバー、返されたレコードが選ぶ接続先へと続く。
  • レジストリは重要な台帳兼運用記録管理者だが、ドメインの正当性を一方的に創設する主権者ではない。利用者が実際に受け取るDNS応答こそが到達性を左右する現実層である。
  • 見慣れたドメイン名とクライアントが受け入れる証明書は、不正に変更されたDNS状態と同時に存在し得る。名前解決、証明書発行、組織の意思は、それぞれ異なる検査だからである。
  • DNSSECは設定された信頼連鎖を通じてDNSデータを認証するが、プロビジョニング権限が侵害された場合に、そのデータが登録者の意思を表すことまでは証明しない。
  • レジストラロック、レジストリロック、多要素認証、証明書透明性監視、独立DNS監視は異なる境界を守る。どれか一つを万能策として扱うことはできない。
  • 防止能力だけでなく、独立観測、保護された変更承認、証拠保全、帯域外確認、検証済みの巻き戻し手順が、不正変更をどれほど早く検知し、範囲を限定し、復旧できるかを決める。

なぜ「正しい名前」と「有効な証明書」だけでは足りないのか

利用者は通常、ブラウザーのアドレス欄に見慣れたドメイン名があり、TLS接続が受け入れられれば、意図した組織のサービスに到達したと考える。しかし、その判断には少なくとも三つの独立した状態が重なっている。

第一は、利用者が入力した名前である。第二は、その名前についてDNSが返した委任先やアドレスである。第三は、接続先が提示し、クライアントが検証した証明書である。名前が正しく入力されていても、権威DNSの状態や親ゾーンの委任が不正に変更されれば、名前解決は別の接続先を選び得る。また、DNSに対する支配が変わった後、公開された認証手続きに従って証明書が有効に発行される場合がある。そのとき問題になるのは「証明書が偽造された」ことではない。証明書発行時の検証条件と、登録者が本来意図していたDNS状態とが一致しなかったことである。

この区別は、責任の所在を曖昧にしないために重要だ。証明書発行機関は自らの検証規則を管理し、レジストラは顧客認証と登録情報の変更経路を管理し、レジストリはEPPを通じて受け付けた状態と親ゾーンへの委任を管理する。権威DNS事業者は配信するゾーンデータを管理し、利用組織はアカウント、回復連絡先、監視、承認手順を管理する。どの当事者も連鎖全体を単独では支配していない。

したがって、DNS改ざんを「DNS全体の失敗」や「インターネット統治の失敗」と一括りにするだけでは、再発防止につながらない。問うべきなのは、どの境界で変更が承認され、どのシステムが状態を記録し、誰が異常を観測でき、どの証拠を使って変更を取り消せたのかである。

2019年の公的記録を分けて読む

1月：CISAの緊急指令

CISAは2019年1月22日、Emergency Directive 19-01を発出し、DNSインフラの改ざんに関する一連の事案を説明した。対象となった米国の連邦文民行政機関の多くに対し、公開DNSレコードの監査、DNSを変更できるアカウントの認証情報変更、利用可能な場合の多要素認証、政府機関ドメイン向けに発行された証明書の証明書透明性データ監視を求めた。

この指令から読み取れるのは、CISAが実際の運用上の危険を認識し、限定された緩和措置を要求したということである。指令は、すべての対象機関が侵害されたと認定したものでも、すべての事案について攻撃者や被害者を裁定したものでもない。重要なのは、DNSレコード、特権アカウント、証明書発行という別々の境界を同時に点検する必要があるとされた点だ。

CISAが求めた対策は、単なるパスワード変更にとどまらない。現在の公開状態を監査し、変更権限を持つアカウントを洗い出し、外部に現れる証明書発行を観測するという組み合わせだった。これは、予防、検知、証拠確認を別の機能として扱う考え方に合致する。

1月：MandiantによるDNSレコード操作の報告

Mandiantは同月、複数の地域にまたがる政府、通信、インターネットインフラ関係のドメインを含むDNSハイジャックの動向を報告した。同社の説明では、DNSレコードを変更できるアクセスが取得され、通信が攻撃者側の管理するインフラへ向けられた。

これはMandiantによる観測と評価として扱う必要がある。ICANNが後の警告でMandiantの調査を参照したことは、DNS登録・委任情報の整合性を確認すべき広範な懸念が存在したことを補強する。一方、Mandiantの報告だけに依存して、公開資料全体から独立には確かめられない個別事実を断定するべきではない。

また、この報告を後に公表されたSea Turtleの全活動と同一視することもできない。時期や技術的類似性があっても、公開資料が異なる観測集合を扱っている以上、記事上の整理も分ける必要がある。

2月15日：ICANNの警告

ICANNは2019年2月15日、CISAの指令、Mandiantの調査、その他の公的報道に関連づけてDNSインフラへの攻撃に関する警告を発した。管理者アクセスへの多要素認証、ドメイン情報とネームサーバー情報の確認、認証情報の衛生管理、監視などを推奨した。

同時にICANNは、ICANN自身のシステムが侵害されたことを示す兆候はないと述べている。この境界を落としてはならない。DNS調整機関が警告を出したという事実は、ICANNのシステム、ルートゾーン、すべてのトップレベルドメインレジストリ、あるいはすべてのレジストラが侵害されたことを意味しない。

むしろ警告が示すのは、登録者、レジストラ、レジストリ、DNS運用者の間にまたがる確認が必要だったということだ。各組織が自分の内部ログだけを確認しても、親ゾーンの委任、権威DNSの応答、証明書発行といった外部状態が一致しているとは限らない。

4月：TalosによるSea Turtleの報告

Cisco Talosは2019年4月、Sea Turtleと名づけた活動について公表した。Talosの評価では、活動は少なくとも2017年初頭から2019年第1四半期まで続き、13か国の少なくとも40組織が対象となった。Talosは、主要な対象と、レジストラ、通信事業者、ISP、レジストリなどの二次的なインフラ提供者を区別した。

Talosが説明した連鎖では、DNSレコードに対する支配が取得され、利用者が別のシステムへ誘導され、認証情報が収集されたとされる。場合によっては、変更後のDNS支配を背景に発行された証明書によって、転送先がブラウザー上で有効に見えた。ここでも、証明書が偽造されたと表現するのは不正確である。DNS状態と証明書発行の検証経路が、組織の意図とは別に成立してしまったことが問題だった。

TalosはSea TurtleをDNSpionageとは区別している。この区別は単なる名称の違いではなく、公的証拠の限界を守るための境界である。類似するDNS操作を扱っていても、それだけで同一の実行主体、同一の被害者集合、同一の作戦と判断することはできない。

7月：Talosによる継続報告

Talosは7月の追跡報告でもSea Turtleに関する観測を更新した。4月と7月の報告は、DNS状態の変更が一時的な技術障害ではなく、登録、委任、権威応答、認証情報、復旧にまたがる運用上の問題であることを示す材料となった。

ただし、Talosはルートゾーンサーバーが攻撃または侵害された証拠はないとも述べている。この事実は、影響の大きさを過小評価する理由ではない。逆に、インターネット全体の最上位機構を侵害しなくても、より限定された登録者、レジストラ、レジストリ、DNS運用の境界を操作すれば、特定ドメインの利用者が受け取る現実の応答を変え得ることを示している。

以上の四つの報告系列は、共通する失敗類型を照らす。しかし、それらを一つの巨大な事件へ統合すると、各情報源が実際に確認した範囲、帰属評価の確度、対象組織、技術的経路の違いが失われる。説明責任の分析には、類似性と同一性を分ける姿勢が必要である。

DNS運用の制御面をたどる

DNS状態が利用者の接続先へ反映されるまでには、複数の管理境界が連なる。

  1. 登録者アカウント
    ドメインを利用する組織または個人が、レジストラやDNS事業者の管理画面へアクセスする。ここでは、認証情報、多要素認証、担当者権限、回復用連絡先、内部承認が重要になる。

  2. レジストラ
    レジストラは顧客を認証し、登録情報やネームサーバー変更を受け付ける。サポート窓口、API、管理画面、緊急時の本人確認は、同じ変更権限へ至る複数の入口になり得る。

  3. EPP取引
    レジストラは一般に、Extensible Provisioning Protocolを通じてレジストリへドメイン状態の変更を送る。ここでは、どのレジストラ資格情報から、いつ、どのオブジェクトに、どの更新が送られたかが証拠となる。

  4. レジストリ保持情報
    レジストリは、ドメインオブジェクト、状態コード、登録レジストラ、ネームサーバー、DNSSEC関連情報などを保持する。レジストリはこの意味で台帳と運用記録管理者であり、変更の受理、拒否、記録、公開に重要な役割を持つ。

  5. 親ゾーンの委任
    レジストリ側の状態から、親ゾーンに委任情報が反映される。利用者側の名前解決は、この公開された委任に従って権威DNSを探す。

  6. 権威DNSサービス
    権威DNSは、対象ゾーンについてNS、A、MX、TTLを含む構成済みレコードを提供する。委任先が正しくても、権威ゾーンの内容が不正なら、利用者は意図しない結果を受け取る。

  7. 再帰リゾルバー
    再帰リゾルバーは委任をたどり、応答を取得し、TTLに従ってキャッシュする。複数のリゾルバーや観測地点で状態が異なる期間が生じることもある。

  8. 選択された接続先
    最終的に、返されたアドレスやメール交換先などが接続先を決める。ここで利用者が実際に到達するサービスが、登録者の意図したサービスとは限らない。

この連鎖では、登録者が「正しい設定を保存した」と考えていても、それだけで外部の現実状態は証明できない。レジストラの画面表示、レジストリの保持情報、親ゾーンの委任、権威DNSの応答、複数地点の再帰結果を比較しなければ、どこで不一致が生じたかを特定できないからである。

逆に、レジストリが正確な台帳を保持していても、権威DNS事業者のゾーン内容が不正なら、利用者に返される応答は誤り得る。権威DNSが正しくても、親ゾーンの委任が別のネームサーバーを指せば、その正しいゾーンに問い合わせが届かない場合がある。説明責任は、このように境界ごとに分割して考えなければならない。

レジストリは台帳であり、到達性の主権者ではない

レジストリの記録は、ドメイン状態、登録レジストラ、委任、セキュリティ属性を追跡するうえで不可欠である。登録情報の正確性、変更履歴、状態コード、移管記録、DNSSEC関連情報は、異常の検知と復旧のための証拠になる。

しかし、レジストリが記録を保持することと、ドメインの正当性を最終的に創設することは同じではない。ドメインを利用する組織の意思、レジストラによる顧客認証、レジストリによる取引受理、DNS運用者によるゾーン配信、証明書発行機関による検証、利用者側の名前解決は、それぞれ異なる仕組みである。

インターネット上で実際に作用するのは、制度上の肩書ではなく、稼働中の設定とコードが返す状態だ。親ゾーンがどこへ委任し、権威DNSが何を返し、リゾルバーが何をキャッシュし、クライアントがどこへ接続するかが到達性を決める。この意味で、配信中のDNS状態が現実層である。

したがって、台帳としてのレジストリには強い責任がある一方、すべての正当性や安全性をレジストリ一社へ帰属させるのも誤りだ。正確な変更記録、保護されたEPP資格情報、異常な更新の検知、適切なロック、緊急連絡、復旧協力という具体的な能力ごとに評価する必要がある。

レコード種別ごとの影響と境界

DNS改ざんの説明では、「DNSレコードが変更された」という表現だけでは粗すぎる。レコード種別によって、変更が到達性や認証情報へ及ぼす作用が異なる。

対象 変更が持ち得る効果 分析上の注意
NS ゾーンの問い合わせ先となる権威ネームサーバーを別の系統へ向け得る 親ゾーンの委任変更とゾーン内部のNS変更を区別する必要がある
A ホスト名に対応するIPv4アドレスを別の接続先へ向け得る すべての事案でAレコードが変更されたとは限らない
MX メール配送先を変更し、通信や認証情報に影響を与え得る ウェブ転送とメール転送は別の経路であり、同一視できない
TTL リゾルバーが応答を保持する時間に影響し、変更の広がり方や復旧時の収束を変え得る TTL自体が接続先を指定するわけではなく、キャッシュ期間を制御する

NS変更は、ゾーン全体について別の権威応答を返させる可能性がある。A変更は特定ホストの接続先を変え得る。MX変更はメールの配送経路へ作用する。TTLの短縮や延長は、変更がどの程度早く観測され、どれほど長くキャッシュに残るかへ影響する。

ただし、これらは技術的に可能な効果を示すものであり、公開されたすべての事案でNS、A、MX、TTLの全種類が変更されたという意味ではない。個別の事件については、当該資料が確認したレコード種別と証拠に限定して述べる必要がある。

実務上の支配力に基づく責任マトリクス

当事者 主な支配境界 保持すべき証拠 失敗が見える場所 復旧能力
登録者 アカウント、担当者権限、変更依頼、回復連絡先 承認記録、担当者名簿、通知、既知の正しい設定 管理画面通知、独立監視、サービス異常 資格情報の無効化、正しい状態の提示、緊急申告
レジストラ 顧客認証、管理画面、API、サポート、EPP資格情報 ログイン、MFA、サポート照合、EPP更新、通知記録 異常なログイン、変更要求、顧客申告 アカウント保護、更新停止、レジストリとの調整
レジストリ ドメイン状態、サーバー側ロック、EPP受理、親ゾーンへの反映 EPP取引、状態変更、委任履歴、緊急対応記録 異常な更新系列、ロック解除、レジストラからの申告 更新拒否、状態復元、委任の再公開
権威DNS運用者 ゾーンデータ、配信、署名、ログ、ロールバック ゾーン履歴、変更者、配信時刻、署名状態 外部応答との不一致、管理ログ、監視 既知の正しいゾーンへの復元、鍵・資格情報の更新
証明書発行機関 証明書申請の検証と発行 検証記録、発行時刻、失効記録 証明書透明性ログ、失効要求 必要に応じた失効と再発行
利用組織 公開サービス、ID管理、インシデント対応 サービス構成、認証ログ、影響確認、連絡記録 利用者報告、接続異常、認証イベント セッション無効化、資格情報更新、利用者通知
公的機関・調整機関 指令、基準、情報共有、制度的調整 公表文書、指令範囲、勧告、受領確認 組織横断の兆候、報告、監査 緩和要求、連絡調整、ガイダンス更新

この表は、法的責任や過失を認定するものではない。公開資料だけでは、各組織の契約、内部承認、補償管理、認識時刻、個別損失を確定できない。ここで評価しているのは、各当事者が技術的・運用的にどの状態を管理し、どの証拠を持ち、どの復旧操作を実行できるかである。

責任の重さは、単に「DNS業界に属するか」で決まらない。変更権限を持っていたか、異常を観測できたか、通知を受け取ったか、証拠を保持していたか、復旧を妨げる要因を制御できたかという具体的な問いによって決まる。

DNSSECが証明するもの、証明しないもの

DNSSECは、DNSデータへ暗号学的な署名を付し、検証側が設定された信頼連鎖をたどって応答の真正性と完全性を確認する仕組みである。正しく導入され、署名され、検証されていれば、経路上で応答が単純に書き換えられた場合などに重要な防御を提供する。

しかし、DNSSECは「この設定は登録者が本当に望んだものか」を直接証明する制度ではない。登録者、レジストラ、レジストリ、DNS運用者のプロビジョニング権限が侵害され、正規の管理経路を通じて委任やDS情報、ゾーン内容が変更された場合、信頼連鎖そのものが誤った運用状態を反映する可能性がある。

この場合、検証結果は「構成済みの信頼連鎖に照らしてデータが認証された」ことを示すが、「変更依頼が組織の正当な意思から生じた」ことまでは示さない。技術的な署名検証と、業務上の変更承認は別の制御である。

さらに、DNSSECの安全性は署名鍵だけで決まらない。鍵のライフサイクル、DS情報の更新、署名の継続、失敗時のロールオーバー、検証可能性、ゾーン運用の可用性が関係する。署名があること自体と、運用が安全に継続できることも区別しなければならない。

したがって、「DNSSECがあれば2019年のすべての事案を防げた」と結論づけることはできない。DNSSECは重要なデータ認証層だが、顧客認証、EPP資格情報保護、帯域外承認、ロック、監視、証拠保持、復旧手順を置き換えない。

レジストラロックとレジストリロック

「ドメインロック」という言葉は、実際には異なる制御を指す場合がある。

レジストラ側のロックは、通常の移管や更新を抑止する状態として有用である。登録者アカウントが侵害されたとき、攻撃者が自由に操作できる範囲を狭められる可能性がある。しかし、攻撃者がレジストラ内部の権限、レジストラのEPP資格情報、ロック解除に必要なサポート経路を支配している場合、クライアント側のロックだけで変更を止められるとは限らない。

レジストリロックは、レジストリ側で特定の更新を制限し、解除や変更に追加の確認を要求する、より深い制御境界になり得る。適切に設計されていれば、通常のレジストラ操作とは別の帯域外確認を必要とし、単一アカウントの侵害が直ちに委任変更へ波及するのを防ぐ。

ただし、レジストリロックも絶対ではない。解除手続きの本人確認が弱い、緊急連絡先が古い、承認担当が一人に集中している、内部権限が過大である、例外処理が監査されない、といった条件があれば防御力は低下する。強いロックとは状態コードそのものではなく、解除を誰が、どの経路で、どの証拠に基づいて承認するかを含む運用プロセスである。

レジストラロックとレジストリロックは競合する対策ではない。異なる深さの境界で働くため、重要ドメインでは重ねて使う価値がある。さらに、変更通知、二者承認、緊急時の支援窓口、独立監視、復旧演習と組み合わせる必要がある。

多要素認証の価値と限界

多要素認証は、パスワード単独の漏えいが直ちにDNS変更権限へ結びつく危険を下げる。CISAとICANNが2019年に推奨した理由も、DNSを変更できる管理アカウントが高い影響力を持つためである。

しかし、MFAは「有効か無効か」だけで評価できない。どのアカウントに適用されるのか、API資格情報やサポート経路にも同等の確認があるのか、回復手続きが認証を迂回しないか、管理者が同じ認証基盤へ過度に依存していないかが重要になる。

登録者用画面にMFAがあっても、レジストラの内部運用アカウントやEPP資格情報が別の弱い経路で管理されていれば、連鎖全体の防御にはならない。反対に、すべての変更を一律に複雑化すると、緊急復旧が遅れ、可用性上の危険が増すこともある。

必要なのは、影響の大きい変更について、強い認証、権限分離、帯域外承認、変更通知、監査証跡を組み合わせることだ。MFAは重要な部品だが、説明責任の終点ではない。

独立監視が必要な理由

同じ管理系統が設定変更と監視の両方を担うと、その系統が侵害された際に「正常」と表示される可能性がある。レジストラの管理画面が正しいように見えても、親ゾーンや権威DNSが別の状態を返しているかもしれない。権威DNSの内部監視が正常でも、委任先自体が変えられている可能性がある。

独立監視では、少なくとも次の状態を別経路から比較する必要がある。

  • 登録者が承認した既知の正しいネームサーバーと、レジストリまたは親ゾーンに公開された委任
  • 権威DNS事業者が保持するゾーン内容と、外部観測地点が受け取る応答
  • 重要ホスト名やメール経路の現在値と、承認済み基準値
  • DNSSECの委任・署名状態と、想定する鍵運用状態
  • 証明書透明性ログに現れる新規証明書と、組織が承認した発行
  • レジストラ、レジストリ、DNS運用者から届く変更通知と、内部の変更記録

証明書透明性監視は、予期しない証明書発行を知る有力な手段である。ただし、それだけでDNS状態の変更地点や原因は分からない。新規証明書が見つかった時点で、委任、権威応答、アカウント活動、EPP更新、証明書申請の検証記録を横断的に確認する必要がある。

同様に、DNS監視が異常を知らせても、それだけで侵害を証明するとは限らない。計画された移行、キャッシュの残存、配信遅延、障害対応による一時的変更も考えられる。監視は判決ではなく、追加確認を開始するための観測である。

証拠を残さなければ復旧できない

不正変更を発見しても、既知の正しい状態、正当な所有・管理関係、変更履歴を示せなければ復旧は遅れる。特に、登録者アカウント、回復用メール、DNS、証明書、組織内ID基盤が相互依存していると、通常の回復手段が同時に使えなくなる可能性がある。

必要な証拠には、承認済みのネームサーバーと主要レコードの基準値、変更申請と承認の記録、登録者とレジストラの関係を示す文書、独立した回復連絡先、EPP取引履歴、ロック状態の変更記録、権威ゾーンの版履歴、DNSSEC鍵とDS変更の履歴、証明書発行・失効記録などが含まれる。

証拠は、侵害の可能性がある同じアカウントや同じ管理面だけに保存すべきではない。独立した保管、アクセス制御、時刻の整合性、改変検知、保持期間が必要である。ただし、証拠保全は無制限なデータ収集を意味しない。復旧と監査に必要な範囲を定め、個人情報や機密情報へのアクセスを制限すべきである。

復旧手順も文書だけでは不十分だ。誰がレジストラへ連絡し、誰がレジストリ側の緊急対応を要請し、どの基準値へ戻し、DNSキャッシュの収束をどう観測し、証明書や利用者セッションをどう扱うかを演習しておく必要がある。

防止、検知、限定、復旧を分ける

DNS変更管理の成熟度は、侵害を完全に防げるという主張ではなく、失敗時の各段階をどれだけ制御できるかで評価すべきである。

防止では、強い認証、最小権限、二者承認、レジストラロック、レジストリロック、EPP資格情報保護、帯域外確認が中心になる。

検知では、独立DNS観測、変更通知、証明書透明性監視、異常なログインやEPP取引の検出、利用者からの報告が役立つ。

限定では、影響を受けたアカウントやAPI資格情報の無効化、更新の一時停止、セッションの失効、変更範囲の特定が必要になる。

復旧では、既知の正しい委任とゾーンへの巻き戻し、ロックの再設定、証明書対応、キャッシュ収束の確認、利用者連絡、証拠保全が重要になる。

一つの制御が失敗しても、別の制御が影響を小さくできる設計が望ましい。たとえばMFAが突破されても、レジストリロックの帯域外承認で変更を止められる可能性がある。変更が通っても、独立監視が短時間で検知できるかもしれない。検知が遅れても、完全な取引履歴と既知の正しい状態があれば復旧時間を短縮できる。

後年の標準とガイダンスをどう位置づけるか

2019年の公的記録を、後に公表または更新された標準で遡って評価する際には注意が必要である。後年の文書は、現在どのような制御が望ましいかを考えるための材料にはなるが、2019年当時にすべての運用者がその制御を実装していた証拠にはならない。

RFC 5731は、EPPにおけるドメインオブジェクトの状態や更新の意味を理解する基礎になる。状態コードや更新操作が明確であることは、変更権限と履歴を監査する前提となる。

RFC 5910は、DNSSECに関する情報をEPPで扱う方法を定義する。DNSSECの信頼連鎖が、登録者、レジストラ、レジストリ間のプロビジョニングから独立して存在するわけではないことを理解するうえで重要である。

RFC 4033とRFC 4035はDNSSECの基本的な仕組みとプロトコル上の動作を示し、RFC 6781は運用実務の文脈を与える。これらは、DNSSECがDNSデータをどのように認証するかを説明する根拠になるが、登録者の意思確認を代替する根拠にはならない。

RFC 9154が扱う、より強いEPP移管認証情報の考え方は、後年の認証制御として参考になる。しかし、2019年の個々の事案でその仕組みが使われていたと述べることはできない。

RFC 9364もDNSSEC運用を考える後年の文脈であり、2019年の全運用者の導入状況を示すものではない。同様に、ICANNの2021年DNS Security Facilitation Initiative調査は、後から見た制御上の課題と選択肢を検討する資料であって、2019年の配備状況を証明する事件資料ではない。

一方、SAC007、SAC040、ICANNの登録者向け案内やハイジャック復旧文書には、2019年以前から、ドメインハイジャック、ロック、認証、緊急支援、証拠文書の重要性が認識されていたことを示す文脈がある。それでも、一般的なガイダンスの存在だけから、特定組織の統制状況や過失を推定することはできない。

NISTのDNS導入ガイドは、完全性、可用性、DNSSECを含む運用設計を考えるための技術的背景を提供する。CISAの現在のドメイン信頼悪用に関する分類は、ドメインやアカウントの支配がどのように利用され得るかを整理するための現代的な用語体系として使える。いずれも、2019年の帰属や個別被害を新たに証明する資料ではない。

管理策は重ね合わせて評価する

管理策 主に守る境界 単独では解決しない問題
MFA アカウント認証 内部権限侵害、弱い回復経路、EPP資格情報侵害
レジストラロック 通常の移管・更新経路 レジストラ内部侵害、ロック解除手続きの弱点
レジストリロック レジストリ側の変更受理 誤った帯域外確認、内部権限、緊急対応の失敗
DNSSEC 配信データの暗号学的認証 侵害された正規プロビジョニング、登録者意思の証明
証明書透明性 証明書発行の外部可視化 DNS変更そのものの防止、原因や承認経路の特定
独立DNS監視 公開状態の不一致検知 単独での帰属判断、証拠保全、状態の復旧
変更通知 変更の早期把握 通知経路自体の侵害、誤警報、承認の正当性確認
ロールバック手順 既知状態への復元 元の基準値が不明な場合、侵害資格情報の除去

ここから導かれるのは、単一製品の導入リストではない。重要なのは、各制御がどの失敗を想定し、前後の制御が失敗したときに何を補うかを説明できることである。

MFAを導入していても、回復窓口が弱ければ認証境界は迂回され得る。レジストリロックがあっても、解除の帯域外確認先が侵害アカウントと同じなら独立性は低い。証明書透明性を監視していても、アラートに対応する担当者とDNS状態の確認手順がなければ検知は行動につながらない。

説明責任とは、「制御を導入した」と表明することではなく、制御がどの境界で働き、どの証拠を残し、異常時に誰が何を実行するかを示すことである。