要約

  • RIPE NCCによると、rpki.ripe.net のrsyncサービスは10月2日のソフトウェア更新後に利用できなくなった。rsync-3.1.3-28.el8_10.x86_64 から戻し、その後、パッケージのダウングレードで解消したと説明した。
  • 公開記録は対象サービスと復旧措置を示す一方、依存する利用者の数、取得失敗数、検証への影響を示していない。サービスの復旧は、クライアントへの影響測定とは異なる。

分析

RIPE NCCのステータスページは10月2日09:45 CESTに、ソフトウェア更新後に rpki.ripe.net のrsyncサービスが利用できないとして障害を登録した。6分後、rsync-3.1.3-28.el8_10.x86_64 からロールバックして問題を緩和したと報告。10:57には、パッケージのダウングレードで解決したとした。この時刻列は公開された更新を表すもので、影響の正確な開始時刻や各クライアントがオブジェクトを取得できなかった時間を特定するものではない。

このリポジトリが配信するのは運用データだ。RIPEの説明によれば、証明書、マニフェスト、Route Origin Authorization（ROA）などのRPKIオブジェクトが含まれ、依存側のバリデーターソフトウェアが利用する。RFC 8182はrsyncを従来からあるリポジトリ同期手段とし、HTTPSを使うRRDPを追加の配信方式として定義している。両方式が存在することだけでは、各バリデーターがどちらを利用したか、切り替えたか、また障害中に検証エラーがあったかは分からない。

RIPEの解決報告にはもう一つの運用上の事実がある。パッケージのセキュリティ更新には本番サービスの挙動を変えるものがあり得るとして、パッチ適用方針を見直すという。これは脆弱性の公表でも、不正行為の証拠でもない。本番リポジトリを支える依存パッケージを変更する際の運用リスクについての説明だ。セキュリティ目的の更新でも、依存サービスとの互換性確認は必要になり得る。

その後確認したステータスページでは、rsync RepositoryとRRDP Repositoryの両方がOperationalと表示されていた。これは確認時点の表示であり、取りこぼした取得数や利用者のローカルコピーが最新だったかを遡って示すものではない。障害記録には、利用者数、エラー率、オブジェクトの鮮度、検証結果、クライアント側の復旧確認はない。

証拠に沿った結論は限定的だ。RIPEが指定したrsyncサービスはソフトウェア更新後に利用できなくなり、パッケージのロールバックが緩和と解決につながった。RIPEはパッチ適用方針の見直しを表明した。一方、バリデーターが同期失敗や遅延を経験したかは公開記録で測られていない。この影響母数の欠落が、運用上の復旧確認と、下流への影響を網羅した説明との境界である。

出典