要約

  • 2026年7月28日、ARINはReg-RWSにAuthorizationヘッダーによるAPIキー認証を加えた。翌日、ACSP提案2022.5を終了扱いにしたが、URLパラメーターでのキー受け入れは続けると明記した。
  • 確認した公開資料は新方式と切り替えの推奨を示しているものの、終了日、移行の節目、URL方式で残る呼び出し数、ヘッダーの利用率は公表していない。提案の終了が記録するのは機能の実装であり、旧方式の廃止やクライアントの移行完了ではない。

ひとつの呼び出しに、ふたつの節目

レジストリへのAPI呼び出しでは、対象リソースを特定することと、呼び出し元がその操作を行う権限を持つことを確かめることが別々に必要になる。Reg-RWSはRPKIやIRRの管理、再割り当てや再配分、ネットブロックの更新などを自動化できる。従来の資料では、APIキーをURLのクエリー部分に載せてリクエストできた。2026年7月に加わった方法では、URLは対象を示し、キーはAuthorizationヘッダーに分けて送る。

処理の結果は同じでも、露出する場所は同じではない。URLはブラウザー履歴、リクエストログ、プロキシ記録、障害調査資料などに残りやすい。ARINが8月に公開した説明も、URLに含まれるキーがブラウザー履歴、サーバーログ、プロキシログに保存される可能性を挙げている。ヘッダーへ移すことで、意図しない記録に巻き込まれる可能性は下げられる。ただし、資格情報が見えなくなるわけではない。アプリケーション、プロキシ、トレース収集ツール、サポート用の添付ファイルが、設定次第でAuthorizationの値を記録することはあり得る。実務上の効果はデフォルトの露出面を狭めることにあり、キー管理を不要にすることではない。

時系列を並べると、ふたつの問題は切り分けやすい。ACSP提案2022.5は2022年2月11日に提出された。REST呼び出しでURLにAPIトークンを置く方式の代替を求め、URL全体を記録するシステムが有効なキーをログ閲覧者に漏らし、権限のないアクセスにつながる可能性を指摘した。実現時期は指定されなかった。2月23日、ARINはHTTPヘッダーを最善の代替と評価し、2023年のエンジニアリング・ロードマップで優先度を検討する対象に加えると回答した。実装されるまでは提案を開いたままにするとも述べた。

2026年7月28日、ARINはREST呼び出しでAuthorizationヘッダーとApiKey方式を使えるようになったと発表した。翌29日の終了回答は、推奨された代替方式が実装されたことと、URLパラメーターのトークンも引き続き受け付けることを記した。つまり、要求された選択肢が追加されたので提案は閉じられた。古い呼び出し方を止めたという意味ではない。8月11日の技術解説と9月のARIN Bitsも、URL方式が当面受け付けられ、いずれ廃止される予定で、今のうちに切り替えることを推奨していると説明している。

ここにはふたつの時計がある。ひとつは実装の時計だ。提案が登録され、評価され、機能が提供され、提案が閉じる。もうひとつは移行の時計である。顧客が変更を知り、利用中のツールを直し、リクエスト形式を検証し、キーをURLから除き、最後に旧方式の呼び出しを止める。前者には公開記録上の終点がある。後者には、今回確認した範囲で、公開された日付も進捗指標もない。

この違いは、提案を閉じる判断を批判するものではない。代替機能を求める提案なら、その選択肢が動くようになった時点で対応済みとできる。顧客側の採用まで提案を開いたままにする必要はない。論点はその後に移る。旧方式を支え続けるなら、もはやコード変更だけではない。レジストリを呼び出すスクリプト、自動化基盤、運用委託先を持つ組織とのサービス上の取り決めになる。

キーを置く場所が変えるもの

APIキーは通常のリクエストデータではない。ARINはこれを利用者を識別する秘密情報と説明し、一部のREST操作では、必要な権限を持つPoint of Contactにアカウントが関連づけられている必要があるとしている。キーがクエリー文字列に入ると、対象リソースのアドレスと一緒に運ばれる。URLを保存または複製する仕組みがあれば、呼び出しを行ったプロセスが終わった後もキーが残ることがある。ARINが挙げたブラウザー履歴やサーバー・プロキシのログは、こうした意図しない残存の経路だ。

ヘッダー方式が変えるのは、リソースではなく認証情報の置き場所である。ARINの資料ではAuthorizationフィールドにApiKey方式を指定する。クライアント、運用自動化ツール、プロビジョニングサービスは、エンドポイントとリクエストの意味を変えずにこのフィールドを送れる必要がある。そうすれば、URLに秘密情報を追加する必要はなくなる。

技術標準にも参考になる類似例がある。ただし境界は明確にしておきたい。IETF RFC 6750が扱うのはOAuthのベアラートークンであり、ARINのApiKey方式ではない。同文書はAuthorizationヘッダーを推奨し、URLが記録される可能性が高いとしてURIパラメーターでのトークン送信を避けるよう述べている。これはReg-RWSがOAuthを使う、あるいはRFC 6750の直接の対象であるという意味ではない。HTTP運用における露出の違いを示す参考例である。URI内の秘密値は一般的なログへ入りやすく、専用フィールドなら分けて管理しやすい。

ヘッダーを使えば安全対策が完了するわけではない。全ヘッダーを記録する管理設定、トレース製品、デバッグダンプが値を保持することもある。リダイレクトの前にクライアントがキーをURLへ戻してしまうことも考えられる。したがってヘッダーへの移行と合わせて、ログからAuthorizationの値を除外すること、キーを保護して保存すること、証明書を検証すること、露出時にキーを置き換える手順を用意することが必要だ。ここで述べているのは利用組織側の管理であり、ARINが新機能として提供したと主張しているわけではない。

移行の負担は組織によって違う。保守対象が一つのクライアントだけなら、設定項目を変えて複数の呼び出しを試せるかもしれない。古いスクリプト、ベンダー製品、定期ジョブ、委託運用、RPKIとIRRそれぞれのツール群を使うネットワーク事業者には、クエリーを組み立てている箇所を探す作業が残る。ARINが計測しない限り、この作業はレジストリから見えない。だから、互換性が残っていることだけで、顧客が変更を知ったうえで安全性の低い方式を選び続けていると判断するのは早い。

公開資料が裏づける範囲

確認できた証拠は、次の四つを別々の事実として示している。

  1. Reg-RWSではリクエストヘッダー認証が利用できる。7月のリリースと現在のREST方法資料が説明している。
  2. ARINはヘッダー方式を優先し、移行を勧めている。8月の技術解説と9月のまとめに明記されている。
  3. 確認した公開資料では、URLパラメーターによるトークンも引き続き受け付けられる。7月29日の終了回答と現在のREST方法ページがそう記している。
  4. 同資料には、終了日、移行の段階、URL方式の呼び出し数、ヘッダー方式の採用率は掲載されていない。

四つ目は対象範囲を限定した記述である。引用した公開資料に数値がないという意味であり、ARINが内部データを持たない、非公開計画を持たない、顧客と話していないという意味ではない。また、資料は情報漏えいを報告していない。2022年の提案は起こり得る露出の仕組みを挙げ、2026年の資料はARINが代替方式を推す理由を説明している。キーが実際に漏れたことも、無許可の登録操作が発生したことも報告されていない。

この区別があれば、逆向きの二つの誤読を避けられる。ひとつは、4年かかったことを失敗の証拠にすることだ。提案には期限が記されず、公開記録は代替策の実装を示している。もうひとつは、提案の終了をリスク消失の証拠とみなすことだ。終了回答はURL方式の受け入れを明言し、9月の資料は日付を示さず将来の廃止に触れている。より安全な方法が利用できても、より露出しやすい旧方式が残ることはある。

互換性はサービス上の責任でもある

移行期間に旧方式を残すこと自体は、責任ある判断になり得る。即時の停止で、リソース管理に不可欠な無人処理が動かなくなるかもしれない。呼び出しが止まれば、登録情報の変更、RPKIやIRRの操作、再割り当て、Reg-RWSを組み込んだ他の業務が遅れる可能性がある。公開資料は一般的な用途を示しているが、特定の中断による損失を数値化してはいない。レジストリAPIは運用インフラの一部であり、気軽に捨てられるデモ用エンドポイントではない。

互換性には維持コストもある。受け付けるリクエスト形式が増えるほど、ドキュメント、サポート担当者、クライアントの保守者、利用チームは複数の状態を理解する必要がある。ひとつを推奨し、もうひとつを無期限に使えるままにすれば、「推奨」が判断日を伴わない注意書きになることもある。新しい連携が古い例をコピーし、休眠中のスクリプトは見直されず、ヘッダーが使えるというだけで社内のセキュリティ確認が済んだ扱いになる可能性もある。

ARINに顧客を特定できる利用履歴を公開するよう求める必要はない。顧客名や秘密情報を明かさずに移行を見えるようにする方法はある。最低限、予定する段階、廃止までの時計を動かす条件、事前通知の期間、互換性変更の告知方法、期間延長を検討する基準を説明できる。日付が決まっていないなら、そう記す方が、「いずれ」という語から顧客が締め切りを推測するより役に立つ。

今回調べた公開資料は、ARINがこうした節目を約束したことを示していない。ここで挙げるのは将来の移行を予測可能にする提案であり、現行計画の説明ではない。日付を公開することには約束が伴う。ARINがまだ決めていないのなら、決定済みであるかのように記すべきではない。

廃止の記録はリリースノートだけでは足りない

技術的にヘッダーが動くだけで移行が完了したとは言えない。どのエンドポイントやツールが対応するのか、クライアントライブラリーに既知の不整合はあるのか、ヘッダーの欠落や形式違いをどんなエラーで知らせるのか、ヘッダーとURLキーが同じ呼び出しで重複送信されることはあるのか。運用者にはこうした確認事項がある。ARINの公開ガイドは基本構文を説明しているが、今回の調査範囲では、製品ごとの互換一覧や採用状況の公開ダッシュボードは見当たらなかった。

採用状況は顧客を特定せずに集計できる。ヘッダー方式の呼び出しがURL方式を置き換えているか、古いクライアントが長い裾野として残っているか、移行が少数の連携に集中していないかを示せる。廃止の告知には、告知日、新規文書でURL方式を例示しなくなる日、警告期間、互換性の最終確認、廃止予定期間を組み合わせられる。運用情報の公開が難しければ、判断基準だけを示し、各段階を満たしたかを公表する方法もある。

顧客にとって、共通の廃止日を待つことはセキュリティ対策にならない。現在の推奨はすでに明確だ。クライアントが対応するなら、APIキーをURLから取り除くべきである。コードと設定からクエリー文字列を作る箇所を探し、共用ライブラリーを先に直し、ログやトレースがAuthorizationの値を伏せていることを確認する。自社の変更管理に沿って代表的な読み取り・書き込み操作を試し、露出したキーがあれば交換する。これらは廃止日がいつ決まるかにかかわらず有効だ。文字列をひとつ置き換えただけで全クライアントが動くと仮定せず、移行を検証することが大切だ。

廃止日を直前の驚きにしてもいけない。段階を設ければ、自分たちが保守していないクライアントを探し、ベンダーへ連絡し、手順書を更新し、監視を確かめる時間が得られる。拒否より前に警告を出す、最終拒否は後段の節目に置く、実在する依存について例外を記録する、といった方法がある。これで暫定手段が無言のまま恒久化することも避けやすい。資料はARINがこれらを選んだと示してはいない。変更の影響が実装組織の外へ及ぶときに使える、一般的な移行手段である。

「終了」が指すもの

2022年の提案は、REST呼び出しにより安全な認証方法を設けるよう求めた。ARINはその方法を提供し、記録を閉じた。この限定された意味では「終了」は正しい。しかし、追跡項目の状態は移行指標ではない。代替機能が実装されたことはわかるが、旧方式を使い続けるクライアント数、告知期間、互換性の終わりはわからない。

ARINの利用者にとって実務上の結論は単純だ。新しいクライアントと保守中のクライアントではヘッダー方式を使い、URL方式の継続受け入れは互換性措置として扱う。同等に安全な選択肢ではない。ARINに残るガバナンス上の仕事は、将来の廃止を十分に見える形にし、推奨を協調した移行へつなげることだ。漏えいを断定したり責任を問う証拠はない。一方で、二つ目の時計がいつ動き出すのか、どんな公開情報で知らせるのかを問う理由はある。

出典