要約

  • 2025年11月13日、ARINは米東部標準時13時30分から14時30分までHostedとRPSのRPKIリポジトリへのアクセスを意図的に遮断した。14時35分に完全な冗長性を確認し、14時50分には試験前の水準へ戻ったと報告した。
  • この試験が示したのは、リポジトリにアクセスできない状態からの復旧である。ACSP提案2025.7が問う外部依存の種類、共通障害領域、循環依存、観測範囲は、公表資料だけでは分からない。
  • 攻撃に役立つ内部構成を開示する必要はない。サービスと処理面ごとに、守るべき状態、試験境界、復旧時刻、未検証の前提、変更通知の条件を版管理して示せばよい。

この事例には、似ているようで異なる三つの記録がある。

2025年10月23日、ARINはROAの移転対応機能を導入した後、Hosted RPKIに関する顧客からの報告を受けた。27日に公表したインシデント報告では、特定のROA設定条件に限られ、影響を受けた顧客は一者だったとされる。ARINは処理中の移転を止め、コードの不具合を修正し、追加の検証を組み込んだ。

翌28日、Ramakant PandrangiがACSP提案2025.7を提出した。求めたのは、障害の説明ではなく、サービス別の依存関係、重要な運用・構成変更の事前通知、RTOやRPOを含む継続性の見通しだった。DNS、CDN、IPアドレス、BGP経路、事業者などに加え、システム全体に波及する依存や循環依存も挙げられている。

11月12日、ARINは主要な依存関係、変更管理、レジリエンスと継続性の目標を文書化する計画を策定中で、完成後はコミュニティの意見と検証に付すと回答した。そして翌13日、本番環境でRPKIのフェイルオーバー試験を行った。

時期が近くても、証拠の役割は別だ。10月の報告はソフトウェア変更の結果を扱う。提案はサービスを支える条件を問う。11月の試験は、設定した停止条件から復旧できるかを確かめる。

分単位の記録が証明したこと

ARINの技術メーリングリストによると、13時にHostedとRPSのリポジトリを提供するサイトへのアクセス制限を開始した。13時30分には全アクセスを管理上遮断し、完全なリポジトリ停止を模擬した。14時30分にアクセスを戻し、14時35分に完全な冗長性を確認、14時50分に試験前の水準へ戻った。

本番で実施した理由も記されている。試験環境では、リポジトリ障害時の性能と備えを正確に再現できないとARINは判断した。これは重要な説明だ。対象サービス、介入、復旧の節目が結びついており、単なる可用性の宣伝ではない。

一方、介入は「アクセスを管理上遮断する」ことだった。二つの経路が同じDNS、CDN、上流接続、施設、電源、認証基盤に依存するかは示されていない。どの物理的・論理的な障害領域を切ったのかも、外部のどのバリデータで復旧を確認したのかも、経路運用への影響も公表資料にはない。

だから試験が無意味なのではない。結論の射程が、アクセス遮断からの復旧までだということだ。

冗長な二系統が、同じ前提に乗ることもある

提案2025.7がシステム依存と循環依存を持ち出した理由は明快だ。アプリケーションが二重化されていても、名前解決や管理権限が共通なら同時に止まり得る。逆に、外部事業者への依存があるだけで危険とは言えない。複数化、キャッシュ、代替可能性、運用分離によって管理できるからだ。

したがって、事業者名の一覧だけでは足りない。「DNS」「CDN」「回線」とだけ書いても粗すぎる。必要なのは、ある依存の種類が使えないときに、何を保つ設計なのかという説明だ。

RPKIリポジトリなら、既に受理した情報を読み出せること、最後の公開状態が一定以上古くならないこと、提供中の内容の完全性、復旧後に保留中の更新を順序どおり照合できることなどが候補になる。何を守るかは処理面で異なる。情報を取得する依存者、ROAを変更する資源保有者、RPSへ送る委任CA、復旧を担当するARIN運用者は、同じ操作をしていない。

2026年7月の保守案内は、この違いを既に公表している。ARIN Online、RESTful Provisioning、RPKI Up/Down、RPSは停止する一方、RPKIリポジトリは更新を出さずに稼働を続けるとされた。以前のTheo Marchの記事は、読めることと新しいことの二つの時計を扱った。本稿の焦点は、各処理面がどの障害領域に依存し、どの組合せが実際に試験されたかである。

Hosted、Delegated、RPSで責任の置き場所が変わる

ARINの現行案内では、同地域のRPKI導入の95％超がHostedを利用する。Hostedでは、ARINが認証局を運用し、高可用性リポジトリへ公開する。Delegatedでは、資源保有者が自らCAと公開サーバを運用できる。RPSは中間で、資源保有者がCAと秘密鍵の管理を続け、ARINがリポジトリを引き受ける。

RPSの説明は、この分割を意図的な選択としている。RPKI情報を発行する組織の管理範囲外に統合リポジトリを置くことがあり、暗号上の決定権を保ちたい組織でも、24時間の公開運用までは担いたくない場合がある。

その場合、継続性も二つに分けて考えなければならない。発行者が有効な情報を作れるか。リポジトリがそれを受理し、依存者へ届けられるか。リポジトリアクセスの復旧試験は後者を確かめる。しかしCA、公開プロトコル、アカウント操作、変更通知まで一括して証明するものではない。

RPSの価値は、暗号上の権限と公開運用を別の管理主体に置ける点にある。片方の試験結果をもう片方の保証にすれば、その境界をかえって曖昧にする。

99.9％は実績であって、依存図ではない

ARINの2025年年次報告は、RRDPとRsyncの両リポジトリについて99.9％の可用性を示す。年ごとに比較でき、「信頼できる」という言葉を数値に置き換える点で有用だ。

ただし、その数字から共通障害領域、RTO、RPO、読み出しだけが続く期間の情報の古さは分からない。どの試験がどの結果を支えたかも分からない。高い可用性と、依存関係の説明がまだ公開されていないことは両立する。依存をうまく分けたサービスでも、記録される停止は起こり得る。

10月のインシデント報告も別の材料だ。ARINは原因を導入後のコード不具合とし、特定条件の一顧客に限った。変更管理と修正対応を評価する証拠ではあるが、外部サービスやリポジトリの冗長性が破れた証拠ではない。

異なる資料を強引につなげないことが、公開説明の信頼性を上げる。

内部配線ではなく、障害の境界を示す

依存関係の透明性には安全上の反論がある。事業者名、施設、正確な経路、制御点、切替条件を並べれば、攻撃の調査資料になりかねない。契約上開示できない情報もある。詳細図はすぐ古くなる。

それでも、沈黙との二択にはならない。重要サービスと処理面ごとに、短い版管理文書を用意すればよい。内容は次の通りだ。

  1. 公共機能と、読み手・書き手の範囲
  2. 機微な事業者名や場所を除いた依存の種類と共通障害の前提
  3. その依存を失った際に守る状態
  4. 直近試験のシナリオと介入境界
  5. 制限、復旧、冗長性確認、基準状態への復帰時刻
  6. 試験していない障害モード
  7. 採用済みなら可用性、RTO、RPOの目標
  8. 会員へ通知する構成変更の基準
  9. 版、見直し日、訂正履歴

公開する依存の種類は「名前解決」「コンテンツ配信」「接続」「認証」「運用拠点」程度でよい。誰がどこで提供するかを明かさなくても、試験条件と守る状態を結べば説明は具体的になる。

見直し期限も不可欠だ。構成が変わっても、2025年の「完全な冗長性」という文言だけは残り続ける可能性がある。期限がなければ、当時正しかった結果が、異なる現在の境界に誤用される。提案2025.7が依存関係と変更管理を同時に求めたのは、この問題への適切な答えだ。

Openは公開状態であり、内部作業の評価ではない

調査時点で提案2025.7はOpenと表示されている。ARINは実装まで開いたままにし、計画完成後にコミュニティへ提示すると回答している。ここから言えるのは公開上の状態だけだ。内部作業がない、遅れている、具体的な弱点を隠しているとは言えない。

次に必要なのは、万能な保証ではなく、最初の限定的な説明である。サービス、処理面、依存の種類、試験済み条件、残る前提、見直し日を揃えれば、次の試験結果を同じ枠へ積み重ねられる。

ARINは既に、実運用への介入と分単位の復旧記録という難しい部分を実行した。依存関係の問いが残るのは、試験の成功と依存の独立が別の命題だからだ。両者の境界を示すことで、この試験は一度きりの朗報から、長く使える運用証拠へ変わる。

出典