【要約】OpenTelemetryで会話本文を止めても、IPアドレスとAPIキー識別情報は残る —— LLMゲートウェイのspan属性を55個数えた [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
LLMゲートウェイの運用者が、機密情報保護のためにLiteLLMの設定を変更した際、想定外の属性が漏洩する問題に直面した。自動計装は便利だが、ライブラリが意図せず付与する属性の範囲を制御しにくい。具体的には以下の課題がある。
- ・
turn_off_message_logging設定は、会話本文のみを対象とする。 - ・
metadata.*属性（IP、User-Agent、APIキー関連）が全体の53%を占め、実値のまま残る。 - ・外部SaaSへトレースを送信する場合、これらが機密情報として漏洩するリスクがある。
// Approach
開発者は、未知の属性による漏洩を防ぐため、許可リスト（Allow list）方式による属性フィルタリングを採用した。消去したいものを指定するDeny listでは、列挙漏れが即座に漏洩に繋がるためである。具体的な手法は以下の通りである。
- ・
RedactingExporterを実装し、カスタムSpanExporterを作成する。 - ・
any(k.startswith(p) for p in self.allow)を用い、許可されたプレフィックスを持つ属性のみを保持する。 - ・ライブラリ側のスイッチとAllow listを併用し、多層防御を実現する。
// Result
この対策により、運用者はセキュリティと観測性の両立を実現した。属性の絞り込みにより、不要な情報を排除しつつ、運用に必要な指標を確実に維持できる。具体的な成果は以下の通りである。
- ・属性数を55個から15個（併用時）まで削減した。
- ・会話本文、IPアドレス、APIキー識別情報などの機密属性を完全に排除した。
- ・トークン数、コスト、モデル名などの重要な観測指標は維持した。
Senior Engineer Insight
> 非常に実践的な知見である。自動計装の利便性の裏にある「意図しない露出」を定量的に示した点は高く評価できる。Deny listではなくAllow listを選択する判断は、ライブラリのアップデートによる属性追加リスクを考慮した、堅牢な設計思想である。ただし、SDKの内部プロパティを直接操作する実装は、将来的な破壊的変更に対して脆弱である。本番環境への投入に際しては、アプリ側での処理に加え、OTel CollectorのAttributes Processorを用いた、より標準的なフィルタリング手法との比較検討を推奨する。