要約

  • ARINは個別の操作を個別のAPIキーに結びつけられるとしている一方、現行ガイドは管理表でキーを識別できる項目をプレフィックスと作成日に限っている。
  • 利用者がキーの説明を書けるようにするACSP 2023.15は、ARINが有用性を認めた2023年10月以来、公開上はOpenのままである。
  • 説明文は権限を狭めず、有効期限も設定せず、秘密の保管者も証明しない。宣言した用途と観測された利用を比較するための証拠である。
  • ARINは説明欄を、非秘密識別子、発行主体、利用サービス、レビュー責任者、変更履歴、無効化確認を結ぶ版管理された「用途記録」にすべきだ。

消せないキーは、危険だからではなく説明できないから残る

古いAPIキーを無効化する場面を考える。画面にはプレフィックスと作成日が並ぶ。担当者は、そのキーが現在も重要な自動処理を支えているのか、移行のために一度だけ作られたのか、緊急時の予備なのかを知りたい。しかし停止してから答えを得るわけにはいかない。障害を起こす可能性があるためだ。

ARINのAPIキーガイドは、この判断に使える情報を明記している。秘密の完全な値が表示されるのは作成時の一度だけで、その後は管理表のKey Prefixと作成日で識別される。秘密を隠す設計は妥当である。問題は、秘密ではない用途まで同時に残らないことだ。

プレフィックスは行を一意に指せる。日付は開始点を示す。しかし、そのキーがReg-RWSでネットワーク記録を書き換えるためのものか、RPKIやIRRを管理するのか、DNSSECや逆引きDNSを扱うのか、制限付きレポートを取得するのかは分からない。ARIN自身がこれらをキーの利用先として挙げている。同じキーで複数の操作ができ、用途を追うために複数のキーを作ることもできる。キーは自動失効しないが、無効化は可能だ。

つまり、管理表には技術的な同一性があり、運用上の同一性がない。「どのキーか」は分かっても「何のためのキーか」は外部に委ねられる。秘密管理製品の名前、環境変数、コード、変更申請、運用手順、担当者の記憶が補うことになる。外部台帳とARINのプレフィックスが正しく結ばれていればよいが、名称変更や人事異動を経るほど、その対応関係は壊れやすい。

この不足は新しい指摘ではない。2023年10月25日のACSP 2023.15は、APIキーに利用者指定の説明を付けられるよう求めた。提案者は細粒度の権限や名前付きサービスロールにも触れたが、説明欄と同じものだとは述べていない。説明は各キーの想定機能を追うためのもの、権限は実際にできる操作を制限するものだ。

ARINは10月27日、複数キーを持つ顧客には有用だと認め、他の開発案件とともに導入予定へ加えると回答した。実装までは提案をOpenにするとも書いた。現在の提案ページとACSP一覧でも状態はOpenで、その後の公開追跡コメントはない。

公開更新がないことから、ARIN内部に計画が存在しないとは言えない。未公開画面の全てに説明欄がないとも断定できない。確認できるのは、公開の約束に公開の完了記録がなく、現在の公開ガイドがなおプレフィックスと作成日だけを説明しているという範囲である。

追跡結果だけでは期待違反を見つけられない

ARINは2025年、チームで個人のキーを共有しないよう強く勧めた。共有すれば大きな権限を渡すだけでなく、誰が何をしたかという追跡性も失われる。代わりにRole POCと個別キーを組み合わせる。キーは作成したARIN Online利用者の権限を持ち、個別操作を個別キーまで追跡できる、とARINは説明する。

これは重要な改善だ。ただし、追跡が示すのは実績であり、期待ではない。

たとえば、二年前に作られたキーが昨日IRRオブジェクトを変更したとする。ログはプレフィックスを示し、認証した主体も明らかにできるかもしれない。しかし、そのキーがIRR管理用だったのか、レポート取得用から役割を広げたのか、終了済み移行処理が残っていたのかは、事前の用途宣言がなければ評価できない。

用途ラベルは、その比較の基準を作る。「RPKI定期更新」「月次WhoWas取得」「逆引きDNS移行」と書かれていれば、観測されたサービスや操作種別と照合できる。ラベルは真実の保証ではない。古くなることも、曖昧に書かれることも、現状を正当化するため後から変更されることもある。だからこそ変更履歴と利用実績が必要になる。

一致や不一致から自動的に結論を出すべきでもない。長期間使われていないキーは不要かもしれず、災害時だけ使う予備かもしれない。想定外のサービスに触れたキーは不正利用かもしれず、正式に役割を変えた結果かもしれない。用途と活動の差はレビューを始めるシグナルであって、事件の証明ではない。

説明欄を権限制御のように見せるのも危険だ。「読み取り専用」と入力しても、作成者の権限に書き込みが含まれればキーは書ける。「六月まで」と書いても六月に失効しない。「IRR」と名付けても、認められた別のAPI呼び出しを防げない。自由記述を安全境界に見せれば、実装されていない制限を利用者が信じる。

ARINの別の公開案件を見ると、これらが別レイヤーであることが分かる。ACSP 2011.17は操作別・POC別のアクセス制限を求める。ACSP 2024.1はMFA、接続元ネットワーク、有効期間を問題にする。2024.3の協議はAuthorizationヘッダーとIP範囲制約を扱った。これらはキーの力や秘密の露出を変える。説明欄は、その力を見直すための情報を変える。

説明欄の周囲では実装が進んだ

2026年7月28日、ARINはAPIキー周辺で二つの具体的変更を公開した。一つは、URLのクエリに秘密を入れる代わりにAuthorizationヘッダーで送る方法を推奨したこと。もう一つは、非人間のサービスアカウントを妨げていたアカウント作成制限を撤廃したことだ。ソフトウェアリリースには両方が記録され、該当する提案は閉じられた。現行のReg-RWSクイックスタートもヘッダー方式をRecommendedとし、URL方式を引き続きSupportedとしている。

ヘッダー化は秘密がURLログや中間装置に不用意に残る範囲を減らす。サービスアカウントは、長期稼働する自動処理を一人の社員になりすませずに表現できる。この二つは実質的な改善である。

それでも、秘密をどこに置いて送るかは、なぜその秘密が存在するかを説明しない。サービス主体を認めても、その主体が持つ複数キーの役割は区別されない。一つのサービスアカウントがRPKI、レポート、移行用の三つのキーを持てば、主体は正確でも、プレフィックスと日付だけの三行は用途を語らない。

Role POCも同じだ。どの権限を作成者が得るかという根拠にはなるが、どの自動処理がその権限を行使する予定だったかは記録しない。主体、権限、用途、活動は連続した証拠だが、同一ではない。

このリリース経緯は、ACSPをどう閉じれば検証可能になるかも示す。2023.15を完了とするなら、ARINは説明を入力する場所、作成後の表示、編集できる役割、検索・出力の可否、履歴の保存、活動ログとの共通識別子を公表できる。単に「実装済み」とするより、利用者は自分の運用で結果を確認できる。

テキスト欄ではなく用途記録にする

説明欄だけでも、今日の識別は楽になる。しかし明日の監査まで支えるには、ラベルがどのキーとどの期間に対応したかを残す必要がある。ARINが顧客の秘密管理製品になる必要はない。ホスト名、リポジトリ、当番表などの機微な詳細は顧客側に置ける。ARIN側には、受け入れるキーと顧客の宣言を結ぶ非秘密の軸があればよい。

用途記録には、少なくとも次の項目が必要だ。

  1. キーのプレフィックス、または変更されない非秘密ID。
  2. 新規キーに必須の用途説明と、Reg-RWS、RPKI、IRR、DNSSEC、逆引きDNS、レポートなど任意の構造化タグ。
  3. 発行した人間またはサービス主体と、権限の由来となる組織・POCの文脈。
  4. 作成時刻、最終利用時刻、安全に示せる範囲の直近サービス・操作種別。
  5. 顧客が定めるレビュー責任者と次回レビュー日。
  6. 用途説明を変更した主体と時刻を含む履歴。
  7. 無効化の時刻、理由、ARINが受け付けなくなったことの確認。
  8. 説明は権限を付与、削除、制限しないという明記。

最終利用は「古いから削除」という自動規則のためではない。用途と並べて、質問を具体化するためにある。操作種別も全ての対象資源を見せる必要はなく、レポート読み取り、Reg-RWS更新、RPKI管理、IRR変更といった分類だけで監査の入口になる。

変更履歴は、現在の説明で過去を塗り替えないために必要だ。移行用のキーが恒久運用へ変わるなら、新しいキーを発行する方法と、役割変更を承認する方法がある。どちらを選んでも、「移行」を「本番」に上書きするだけでは、いつ誰が責任範囲を変えたかが失われる。

無効化もボタン操作で終わらせない。どの用途の権限をいつ終了したかを記録すれば、顧客は秘密管理庫、プログラム、手順書からの削除と照合できる。ARINの確認は世界中の秘密コピーが消えた証明ではないが、そのキーをARINが受理しないことの証拠になる。

詳細用途を顧客側だけに置く選択も成り立つ。その場合ARINは、変更されないIDを台帳と活動ログの双方に出し、活動をエクスポートできるようにすべきだ。用途を外部へ委ねても、結合キーがあれば証拠はつながる。結合キーを提供せず「顧客の責任」とするのは分担ではなく分断である。

事故の数字を作らずに改善できる

今回の資料には、放置されたARINキーの総数も、用途不明のため停止できなかった顧客数もない。漏えい、不正操作、停止事故の証拠もない。したがって、危険の仕組みを既発生の事件として描くことはできない。

それでも設計上の問いは成立する。キーは長期間存続でき、複数サービスに使え、活動は個別キーに帰属できる。一方、公開ガイドが示す管理表には用途がない。将来の担当者が権限を残すか終えるか判断するとき、説明の再構築費用は顧客側に残る。

説明欄が攻撃を防ぐか、という問いなら答えは否だ。問うべきなのは、番号資源の権限を自動化する仕組みが、後日その権限を見直せるだけの意図も保存するかどうかである。キーが何をしたかを追えるなら、その追跡結果を評価する基準——何をするはずだったか——も残せる。

運用者の目線では、既存キーへの移行方法も重要になる。新規キーだけ説明を必須にすれば、最も古く、説明が失われやすいキーは空欄のまま残る。だからといって、既存の目的を推測して自動入力すれば、推測が発行時の事実として固定される。より正直な方法は、既存行を「未確認」として表示し、顧客が根拠を調べ、現在の用途を確認した時刻と確認者を記録することだ。これは元の意図を復元したという主張ではなく、現在の継続判断を新たに残す手続きになる。

構造化タグにも限界がある。RPKIやIRRという分類は検索や集計に役立つ一方、同じサービス内の本番、試験、緊急、移行という違いまでは表せない。したがってタグだけにも自由記述だけにも寄せず、再利用できる分類と短い固有説明を組み合わせるのがよい。顧客が内部詳細を伏せたい場合は、具体名ではなく責任ある役割や管理番号を記せばよい。大切なのは、次の担当者が権限の存続理由を検証できる入口である。

公開処分の書き方も顧客の行動を左右する。もしARINが説明を実装しないと決めたなら、その理由と期待する代替手段を示すべきだ。顧客側の台帳を正とするなら、ARINの固定IDと活動出力をどう結ぶかまで説明する。未完了を永久にOpenとするより、境界を明示した否決の方が運用上は有用な場合がある。状態の目的は期待を保留することではなく、誰がどの証拠を持つかを確定することにある。

閲覧権限も設計事項になる。用途には内部プロジェクト名や担当部署が含まれ得るため、公開Whoisのように外へ出す必要はない。一方で、キーを無効化できる管理者だけが見られる設計では、監査や交代準備に使いにくい。閲覧、編集、無効化を別々の役割として定義し、誰が説明を変更したかを残せば、機密性と検証可能性を両立できる。用途証拠は公開情報である必要はないが、必要な責任者から隠れていてもいけない。

さらに、説明の品質は長さだけで測れない。「用途を空欄にしない」という要件が、定型句の大量発生に終われば意味は薄い。レビュー時に責任者と停止条件をたどれるか、観測された操作と比較できるかを基準にすべきだ。良い説明は長文ではなく、次の判断へ進める説明である。

その判断経路まで残って初めて、説明欄は運用証拠になる。

そして、その証拠は次の交代時にも同じ意味で読めなければならない。短期の便利さではなく、時間を越える説明責任が設計基準になる。

情報源