ログを共有する前にIPアドレス・URL・認証情報を隠す方法

ログに含まれやすい機密情報

• 送信元・接続先IPアドレス、内部ホスト名、ポート番号
• URLのパスやクエリ文字列に含まれる顧客番号
• Authorization、Cookie、セッションID、JWT
• メールアドレス、ユーザー名、端末名、ファイルパス
• スタックトレース内のパッケージ名や社内クラス名

調査価値を残すマスキング

時刻、ログレベル、スレッド、処理の順番、HTTPステータス、例外の種類は原因調査に役立ちます。すべてを削除せず、同じ値を同じ代替値へ置き換えると、同一利用者や同一処理の流れを追えます。

1. 必要な時間帯と事象に関係する行だけを切り出します。
2. ログ形式を選び、IP、URL、識別子、値、コメントをマスキングします。
3. 複数行のスタックトレースとJSON埋め込み部分を確認します。
4. 元データに含まれていた固有名詞や識別子を全文検索し、置き残しがないか目視確認します。

時刻と件数の扱い

正確な発生時刻を公開したくない場合は、全行に同じ時間差を加えて間隔だけを残す方法があります。大量ログでは先頭数行だけでなく、末尾やローテーション後のファイルも確認してください。

ログをマスキングしても、元ログのアクセス権限や共有先での保存期間は変わりません。組織のログの取扱いルールを優先してください。

具体例：認証エラーのアクセスログを共有する

認証エラーでは、送信元IP、ユーザーID、セッションID、リクエストURL、User-Agentが同じ行に並ぶことがあります。前後数行の相関を残しつつ、個人や環境を特定できる値を置換します。

同じセッションIDを毎回異なる値へ変えると、ログを時系列で追えません。元値とマスキング値の対応を保ち、複数行の追跡可能性を残します。

1. 調査対象時刻の前後だけを切り出します。
2. IP、URLクエリ、Cookie、Authorization、メールアドレス、ホスト名を確認します。
3. ログ形式を選び、同一値の対応を維持してマスキングします。
4. スタックトレース、SQL、埋め込みJSONにも実値が残っていないか確認します。

パスワードやアクセストークンがログへ出力されていた場合は、共有前の置換だけでなくログ出力設定そのものも修正してください。

よくある質問

タイムスタンプは残してよいですか？

障害調査には有用ですが、勤務状況や利用時刻が機密になる場合があります。必要なら一定時間を加算し、行同士の間隔だけを保ちます。

IPアドレスの末尾だけを伏せれば匿名化できますか？

用途によっては他の情報と組み合わせて推測できます。公開範囲が広い場合は、元値との対応だけを保ったダミーIPへの置換が安全です。