要約

  • 2026年9月時点で固定したRIPE WHOISソースでは、ApiKeyAuthProviderが空のトークンを確認したり検証クライアントの判定を得たりする前に、Basic認証のユーザー名をAPIKeySession.keyIdへ設定する。
  • Syncupdatesの統合テストは、存在しないテスト用キーについて、key ID、nullの本人属性、errorStatus=Invalid APIKEYを持つ監査XMLを期待する。これは失敗を帰属できる仕組みの証拠であり、更新が認可された証拠ではない。
  • RIPEの文書ではkey IDがユーザー名、一度だけ表示される秘密がパスワードである。確認できた文字列表現に前者は入るが、後者があらゆる本番ログや中継層から排除されているとまでは証明できない。
  • 運用上の焦点は失敗を記録するか否かだけではない。key IDを検索できる権限、相関の目的、複製先、保存期間を決め、合成値で拒否・記録・非更新を別々に確かめる必要がある。

信頼を得る前に識別子が設定される

この経路を理解するうえで重要なのは、例外の文言より処理順序である。コミット252681a0865d5a10dbcfeaeeaf81bf33ef2c3855に固定したApiKeyAuthProviderは、Basic認証から提示された情報を受け取り、認証名と資格情報をAPIキー検証側へ渡す。ところが検証が成功した後にIDを付けるのではない。空のアクセストークンを調べる前、検証クライアントの応答前にAPIKeySessionを組み立て、keyId(authentication.getName())を実行する。

その後で判定が来る。トークン値が空なら、コードはInvalid APIKEYというメッセージを持つAccessTokenValidationExceptionを投げる。例外処理は途中まで作った文脈を捨てず、tryToBuildOAuthSessionを呼び、エラーセッションを含むApiKeyAuthenticationTokenを返す。型名にAuthenticationTokenとあることは、成功を意味しない。このオブジェクトは否定的な判定を運ぶ器にもなっている。

つまり、セッション内のkey IDは「検証済みユーザーのID」ではなく、「要求が自称した管理可能なキーのID」である。ここを混同すると、ログに識別子があるだけで本人確認まで済んだと誤認する。確認できるのは、提示された名前が検証に先立って保存され、失敗の文脈にも残り得るということだけだ。

RIPE DatabaseのAPIキー文書は、この名前の役割を明確にする。APIキーはkey IDとパスワードの二つの部分を持つ。key IDはBasic認証のユーザー名、作成時に一度だけ表示される秘密はパスワードとして用いる。管理画面ではKey ID、Last Used、有効期限などを確認し、用途ごとにキーを分け、不要になれば失効させられる。

したがって、監査に残る値はロガーが任意に作った追跡番号ではない。利用者が管理する資格情報オブジェクトの取っ手である。古い自動処理がローテーション後も失効キーを使い続ければ、同じIDに集まる失敗から原因を探せる。サポート担当はパスワードを尋ねずに対象キーを見つけ、安全担当は単一IDへの反復と広範な障害を分けられる。

ただし、パスワードではないことと、どこでも公開してよいことは同義ではない。鍵管理データと照合できる読者にとって、key IDはアカウント、アプリケーション、あるいは運用履歴と結び付く可能性がある。相関できるから調査に役立つのであり、その相関可能性を理由に閲覧範囲と保存期間を設計しなければならない。

テストが「残る形」を仕様として示す

コードから推測できる経路と、保守者が期待値として固定した挙動は区別すべきである。syncupdates_gets_logged_invalid_apikeys統合テストは、テスト用SyncupdatesエンドポイントへBasic認証付きのPOSTを送り、存在しないfixtureキーを提示する。そして期待する監査XMLに、ダミーのkey ID、nullのメール・UUID・スコープ、errorStatus=Invalid APIKEYを並べている。

隣接するテストも意味を補強する。有効なキーでは本人属性とスコープが入り、期限切れまたは無効なキーではkey IDとエラー状態が残る。監査表現は「このIDを名乗る資格情報が提示された」ことと、「資格情報が受理され、本人属性と権限が得られた」ことを分けている。

この区別は、レジストリ更新の監査にとって実務的である。失敗をすべて匿名カウンターにすれば、総量の増加は分かっても、退役し損ねた一つのスクリプトと多数の無関係な入力ミスを分けにくい。一方、提示された秘密を丸ごと残せば、監査基盤そのものが資格情報の保管庫になる。key IDだけを相関軸として残す設計は、その両極の間にある。

文字列化の実装は、観察できた範囲をさらに絞る。APIKeySession.toString()にはaud、keyId、email、uuid、scopes、azp、jti、errorStatusなどが列挙される。OAuthCredentialは提示されたセッションを包み、確認した文字列表現ではそのセッションを出力する。ここにpasswordやaccess tokenというフィールドはない。

これは好ましい具体的事実だが、システム全体への保証ではない。リバースプロキシ、例外トレーサー、検証バックエンド、ホスティング基盤、別のログ設定が完全なAuthorizationヘッダーや秘密を記録しないことまでは分からない。「この二つの文字列表現にフィールドがない」を「どの層にも秘密がない」へ広げてはいけない。

さらに、テストのkey ID、メール、UUID、スコープはfixtureであり、実在の利用者記録ではない。調査では本物のAPIキー、パスワード、Basicヘッダー、アクセストークン、本番アカウントを作成も送信も閲覧もしていない。攻撃、総当たり、侵害、顧客事故、成功した不正更新は観測していない。

公開リポジトリの時点と本番配備も同一視できない。固定したheadと変更コミット0ad411c9f4cb4ba0c278142f8bbf886bb9c0a89cは、ソース上に機構があることを示すだけで、どのリリースが稼働し、いつ何割に展開されたかを示さない。changes.txtに近接して記されたAPIキーバックエンド障害時の耐性やログ改善も、脆弱性告知や展開証明ではない。

最小化はフィールドを選んだ後も続く

OWASPのロギング指針は、認証の成功と失敗を記録しつつ、パスワードやアクセストークンを直接ログへ残さないよう勧める。この指針がRIPE WHOISを監査したわけでも、準拠を証明するわけでもない。それでも、なぜ失敗の証拠は必要で、なぜ bearer secret はその最小集合に入らないのかを考える外部基準になる。

key IDとエラー状態の組み合わせは、そうした最小化の方向と整合する。ただし、最小化はJavaクラスのフィールドで終わらない。主ログが短期保存でも、SIEM、エクスポート、サポートチケット、バックアップ、インシデント報告へコピーされれば、それぞれ別の権限と保存期間を持つ。一つの値が調査に便利であるほど、別のシステムも取り込みたくなる。

複製のたびに、当初の目的から離れる可能性が高まる。失効支援のためのIDが、いつの間にかアカウント活動を横断検索する一般索引になるかもしれない。主ログから消しても、長期バックアップやチケットに残れば、削除方針は実質的に不完全になる。設計時の「秘密は残さない」という成功だけで、識別子のライフサイクル管理まで成功したとは言えない。

key IDを直ちに自然人のIDとして扱うのも誤りである。アカウントや人物との関連付けには鍵管理サービス側の記録が要る。ダミーIDからは世界的な一意性、衝突耐性、エントロピー、機密性のいずれも分からない。ID単独で人物が特定できるとも、無害な公開情報だとも断定できない。

今回の資料は、不正なBasicヘッダー、ユーザー名欠落、重複名、パーサー境界をテストしていない。全REST経路や更新インターフェース、オンライン・オフライン検証の差、レート制限、集約、アラート、インシデント対応も評価していない。本番の閲覧者、検索権限、エクスポート、バックアップ、削除も確認していない。法令、プライバシー規則、ISO 27001、SOC 2、NIS2への適合判断はできない。

それでも、この狭い機構は運用レビューを始めるのに十分である。少なくとも一つのテスト対象経路で、ID設定は検証より早く、無効判定後も期待監査表現へ届く。それ以上でも、それ以下でもない精度で扱うなら、調査価値とデータ統制を同時に検討できる。

実資格情報を使わない検証方法

最初の確認は、許可された合成トレースにすべきだ。テスト環境または明示的に承認されたアカウントで専用キーを作り、そのkey IDを記録し、失効・期限切れ・誤ったパスワードのいずれかを安全に作る。そのうえで、破壊的でない要求を対象インターフェースへ送る。実顧客のキーを試してはならず、文書の例を生きた安全な鍵のように再掲してもならない。

合格条件は三つに分ける。第一に、要求がアプリケーション境界で拒否される。第二に、監査イベントには合成key IDと明確な無効状態があり、パスワード、完全なBasicヘッダー、アクセストークンがない。第三に、対象リソースが変化していない。エラーセッションを含むオブジェクトの生成は、非更新確認の代わりにならない。

次に、書き込み後の経路を追う。key IDで検索できる役割、SIEMとサポートツールへの転送、エクスポートとバックアップ、各保存期間、鍵削除やアカウント終了時の扱いを一覧化する。調査に必要な期間と「念のため永久」は別物である。主システムの削除だけを確認しても、複製先が残れば目的制限は守れない。

エラーの区別も試す必要がある。未知のID、既存IDへの誤パスワード、期限切れ、検証バックエンド停止は、運用上異なる対応を要する。隣接テストは有効・期限切れ・無効の形を示すが、本番アラートの完全な分類を証明しない。バックエンド障害を普通の無効キーとして集計すれば、安全調査と可用性診断が同じ信号を奪い合う。

ただし、外部応答を細かくし過ぎればキーの存在を列挙する手掛かりになる可能性がある。内部監査では診断に必要な差を保ち、外部応答では不要な差を公開しないという分離が望ましい。これも実利用者を使わず、fixtureと認可済み環境で確かめられる。

最後に、監査上のkey IDの所有者と目的を文章化する。安全担当には相関、サポートには診断、サービス所有者には失効という利益がある。プライバシー担当は関連付けと保存を監督する。これらは両立できるが、誰も目的を定義しなければ、便利な検索キーは際限なく再利用される。

資料

  1. RIPE NCC、変更コミット0ad411c9: https://github.com/RIPE-NCC/whois/commit/0ad411c9f4cb4ba0c278142f8bbf886bb9c0a89c
  2. RIPE NCC、ApiKeyAuthProvider.java: https://github.com/RIPE-NCC/whois/blob/252681a0865d5a10dbcfeaeeaf81bf33ef2c3855/whois-api/src/main/java/net/ripe/db/whois/api/security/auth/provider/ApiKeyAuthProvider.java
  3. RIPE NCC、APIKeySession.java: https://github.com/RIPE-NCC/whois/blob/252681a0865d5a10dbcfeaeeaf81bf33ef2c3855/whois-commons/src/main/java/net/ripe/db/whois/common/oauth/APIKeySession.java
  4. RIPE NCC、OAuthCredential.java: https://github.com/RIPE-NCC/whois/blob/252681a0865d5a10dbcfeaeeaf81bf33ef2c3855/whois-commons/src/main/java/net/ripe/db/whois/common/credentials/OAuthCredential.java
  5. RIPE NCC、更新・監査統合テスト: https://github.com/RIPE-NCC/whois/blob/252681a0865d5a10dbcfeaeeaf81bf33ef2c3855/whois-api/src/test/java/net/ripe/db/whois/api/log/UpdateAndAuditLogTestIntegration.java
  6. RIPE NCC、WHOIS変更履歴: https://github.com/RIPE-NCC/whois/blob/252681a0865d5a10dbcfeaeeaf81bf33ef2c3855/changes.txt
  7. RIPE Database文書、API Keys: https://docs.db.ripe.net/Appendices/Appendix-K--API-Keys
  8. RIPE Database文書、RESTful API: https://docs.db.ripe.net/Update-Methods/RESTful-API
  9. RIPE Database文書、認可モデル: https://docs.db.ripe.net/Authorisation/Authorisation-Model/
  10. OWASP、Logging Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html