要約

  • AFRINICの2025年年次報告書は、物理データセンターの占有を小さくし、クラウドとハイブリッドの利用を増やす方針を記す。同時に、Baculaの更新、重要サービスの全面的なバックアップ、AWS S3への遠隔コピー、四半期ごとの復元テスト、Ansibleによる自動化を挙げている。
  • これらは妥当な改善であり、障害の証拠ではない。ただし、バックアップジョブの完了、オブジェクトの読出し、スナップショットの復元、アプリケーションの起動、会員による重要操作の成功は、それぞれ別の状態である。
  • AFRINICは、目標、試験シナリオ、整合性と業務受入れ、供給者が制御する段階、例外、独立環境での最新演習を示す「サービスから復旧まで」の管理表を、アカウント名やバケット名、鍵、緊急手順を明かさずに公開できる。

小さくする対象を取り違えない

AFRINICの方針を評価するとき、まずその最も強い根拠を確認する必要がある。年次報告書は、単に自前のサーバーを減らすと述べているのではない。老朽化した機器や耐用年数を終えた機器を廃止し、故障したネットワーク部品とストレージ部品を交換し、10Gのピアリング設備を導入し、バックアップ用ストレージを拡張した。さらに、ルーティングとアップリンクの冗長設計を準備した。作業地点としてモーリシャス、ヨハネスブルク、Parklands、モンバサ、Isandoが記され、一部の施策は供給者の予定と承認に左右されたとも明記されている。

古い機器を所有し続けることは、統制そのものではない。保守が難しくなった機器は、むしろ既知の障害点である。遠隔地のコピーは、一つの物理事象からデータを切り離す。クラウドやハイブリッドの資源は、代替の自社設備が完成する前に復旧先を用意できる可能性がある。BaculaとAnsibleは、特定の技術者の記憶に依存した作業を、再現可能な手順に変えうる。四半期ごとに実際の復元を試すことは、バックアップ完了率だけを報告するよりはるかに強い。

したがって、論点は「クラウドか、自前か」という二者択一ではない。合理的な近代化によって、証明の経路が変わることにある。物理機器への依存が減る一方で、アカウント、アイデンティティ、権限、リージョン、暗号鍵、復元時の製品挙動、契約、承認待ちが経路に入る。供給者が関わること自体は失敗ではない。試験がどの境界を通過し、どの境界を通常どおり利用したのかを区別しなければ、何を検証したのかが分からないのである。

報告書は、重要サービスを全面的にバックアップし、AWS S3を遠隔バックアップに使うと述べる。しかし、各サービスと権威あるデータ種別の対応、RPOとRTO、試験対象のスナップショット、保存リージョン、アカウントと鍵の管理、復元した版、試験先の種類、検査ごとの結果、通常の供給者環境から離れた演習は公表していない。これは公表されていない事実の一覧であって、不備が発見されたという意味ではない。

復元という一語を九つに分ける

最初の状態は、バックアップジョブが完了したことである。次に、保存したオブジェクトが読めること。三番目は、選択したスナップショットが復元先へ展開できること。四番目は、スキーマ、署名、参照整合性の検査を通ること。五番目にアプリケーションが起動し、六番目に公開エンドポイントが応答する。七番目に、会員または依拠する利用者が重要な操作を完了する。八番目に、RPOとRTOを満たす。九番目に、同じ権威ある状態を、日常の制御環境とは独立した場所で再構成できる。

一段目の成功は二段目を保証しない。データベースが起動しても、アプリケーションの版と合わないことがある。HTTP応答が返っても、認証を伴う資源操作が失敗することがある。全バイトが存在しても、署名や相互参照が壊れていれば意味は変わる。最終的にサービスが戻っても、約束した時間を過ぎていれば別の評価になる。通常のアカウント内での復元が完璧でも、そのアカウントを利用できない事故への備えにはならない。

地域インターネットレジストリでは、この区別は特に重要だ。WHOIS、MyAFRINIC、DNS、RPKIは、単に画面を表示するだけのサービスではない。登録情報、認可された操作、下流で使われる判断を支えている。復旧の終点は、プロセスが起動した時ではなく、権威ある機能が受け入れられた時に置くべきである。

その証明の公開に、攻撃者向けの設計図は不要だ。AFRINICは、アカウントID、バケット名、鍵、設備の場所、ネットワーク構成、緊急コマンドを伏せたまま、復旧先のクラス、権限と鍵の管理区分、通過した境界、検査の種類、所要時間を示せる。管理結果の透明性と、運用秘密の公開は別物である。

第三者の境界は既に文書化されている

AFRINICの公開Service Level Commitmentは「Version 1, November 2015」と記されている。登録と顧客サービス、データベースと公開オンラインサービス、逆引きDNS、請求、サービス基盤を対象とし、WHOIS、MyAFRINIC、ウェブサイト、IRR、DNS、DNSSEC、メール、RPKIを挙げる。各サービスとネットワークに99.8%の稼働率を約束する一方、第三者の利用不能時間を計算から除外する。

同文書は、AFRINICが第三者供給者のサービスレベルを保証できないとしながら、重要サービスに影響する取引関係では自らの約束を反映するよう努めると述べる。これを供給者の不履行の証拠として読むことはできない。注目すべきなのは、測定の境界が既に公表されている点である。

復旧が外部の承認を待つ間も、会員が経験する停止は続く。契約は責任を配分できるが、実際の停止時間を消すことはできない。したがって、復旧時計は事故の開始から業務受入れまで継続させ、その内訳としてAFRINIC管理、供給者管理、承認待ちを示す方が分かりやすい。

年次報告書は、2025年の重要サービスが通常99.7%を超える可用性だったとする。証拠取得時の公開ステータスページでは、WHOIS Database、MyAFRINIC Portal、AFRINIC Web Sites、Mailing Lists、New Member Registration Portal、DNS Services、RPKI Systems、Other SystemsがOperationalであり、ルート項目のメトリクス要約は空だった。年間可用性、現在の緑表示、復旧可能性は異なる観測である。どれか一つを他の二つの代わりにしてはならない。

S3の仕様は結果に文脈が要ることを示す

AWSの災害復旧文書は、AFRINICの構成を推測するためではなく、責任境界を理解するために使える。共有責任モデルでは、AWSがS3などのマネージドサービスの基盤層を運用し、顧客はバックアップ、バージョニング、レプリケーションを含むデータのレジリエンスに責任を持つ。

文書化されたS3のバックアップ機能には、継続的または定期的なバックアップ、時点復旧、バックアップデータへの直接アクセスがある。AWS BackupをS3に用いる経路ではS3 Versioningが必要になる。権限とロール、ACLの組合せ、復元先のバージョニング、リージョン、暗号鍵の可用性も結果を変える。復元先に同じ名前またはバージョンIDのオブジェクトがあれば、処理対象から外れる場合がある。元のバケットへの復元は非破壊的で、既存の全てを一律に上書きするものではない。

これは、AFRINICがAWS Backup、S3 Versioning、Replication、リージョン間コピー、特定のリージョン、IAM設計、暗号構成を採用している証拠ではない。公開資料からは、いずれも判断できない。ここから導けるのはもっと限定的な結論だ。「S3の復元に成功」という報告には試験の種類が必要である。オブジェクトの読出し、アプリケーションの再構築、業務操作の受入れ、独立環境への退出は、全て良い結果だが同じ結果ではない。

同じく成功と判定された二つの復元が、異なる権威状態を生む可能性もある。一方は既存オブジェクトとの衝突で一部を飛ばし、他方はクリーンな復元先を使うかもしれない。一方は通常の鍵とアイデンティティを使い、他方は代替の制御経路を検証するかもしれない。「成功」という一語だけでは、将来の担当者がその差を再現できない。

公開するのは設計図ではなく管理表

サービスから復旧までの管理表は、各公開コンポーネントにつき一行でよい。その行に、権威あるデータのクラス、RPO、RTO、機密性のない演習ID、基準時刻、整合性ハッシュ、保持区分を置く。

次に、AFRINICが制御する段階と供給者が制御する段階を分ける。シナリオと復元先クラスは、アカウント、リージョン、供給者のどの境界を越えたかを示す。権限と暗号鍵は「組織独立管理」「共同管理」「供給者経路」といった区分にとどめる。検査結果は、完全性、スキーマ、署名、参照、アプリケーション起動、外部応答、利用者受入れを別々に記録する。

時刻も一つでは足りない。開始、技術的に利用可能になった時刻、業務的に受け入れられた時刻を分ければ、アプリケーションが早く起動しても実際の操作が遅れたことが見える。スキップされたオブジェクト、未解決の承認、是正担当者、期限、ロールバックまたは訂正経路も残すべきだ。失敗を記録することより、次の四半期に同じ例外が説明なく消えることの方が危険である。

最後に、独立環境で行った最新演習を示す。「独立」とは、常時同規模の第二基盤を維持することに限らない。通常のアカウント、リージョン、アイデンティティ面、または供給者が使えない想定で、権威状態と最低限のサービスを再構成したという意味である。具体的な構成は秘密のままでよい。退出を実行したかどうかは統治上の事実である。

この表自体は次の事故を防ぐ保証書ではない。更新されず形骸化する可能性もあり、独立した確認も必要だ。それでも、試験の意味を四半期ごとに変えない共通言語になる。失敗を説明し、期限を設けて修正する記録は、定義のない成功を並べるより強い。

証拠からは言えないこと

確認した資料は、AFRINICで障害、復元失敗、バックアップ欠落、侵害、データ損失が起きたことを示していない。S3に全重要サービスや全登録データが入っているとも書かれていない。供給者の契約不履行、AWSから退出できない状態、現在のロックイン、99.7%という年間値の誤りも立証されていない。ステータスページは過去の可用性台帳ではないが、現在のOperational表示が誤りだという意味ではない。

また、公開管理表を提案することは、内部の試験が弱いと決めつけることでもない。四半期の復元、遠隔コピー、自動化、部門別の事業継続・災害復旧計画は、バックアップだけを作って確認しない運用より進んでいる。提案は予防的である。インフラの境界が移ったなら、証拠の境界も移すべきだということだ。

したがって、これはクラウド賛否の議論ではない。AFRINICは、古い機器を減らし、物理的な障害を分離し、運用負担と費用の予測可能性を改善する理由を既に示した。問われるのは、責任が分散した後にも、何を、どこまで、誰が、何分で戻し、どの利用者が受け入れたかを説明できるかである。

出典