ヘッダーをバッグとして
HTTP ロギングフレームワークは、リクエストヘッダーをキーバリューのバッグとして処理します。ログ API は、フルなバッグを露出します。オペレーターは、リクエストが失敗したときにヘッダーが物語を伝えるために、ヘッダー ロギングをデバッグに有効にします。内部に否認リストはありません。ドキュメントにクレデンシャルフィルタリングはありません。フルなヘッダーをディスクに。
通常のリクエストに含まれるクレデンシャルヘッダー:
- Authorization: Bearer eyJhbGciOiJIUzI1NiJ9... (JWTまたはOAuthトークン)
- Cookie: session=abc123; auth=xyz789
- X-API-Key: sk-live-abc123...
- X-Auth-Token: ghp_abc123... (GitHub個人アクセストークンパターン)
これらの値は、リクエストを認証します。ログファイルに記録されると、どのリクエストも認証されます。
クレデンシャルパイプライン
クレデンシャルがログファイルに記録されると、1つの場所にとどまらず、次の場所に移動します:
1. Web サーバーは /var/log/nginx/access.log に記録します
2. ロットレーションエージェント（logrotate）は、/var/log/nginx/access.log.1 にコピーします
3. ログシッパー（Fluentd、Filebeat、Logstash）は、読み取りとシッピングをアグリゲーターにします
4. ログアグリゲーター（Elasticsearch、Splunk、Datadog）は、インデックスと保持します
5. 30-90日間の既定のポリシーで保持されます
クレデンシャルは、5つの場所に同時に存在します。セッショントークンの削除は、ログアグリゲーターからクレデンシャルを削除しません。ログアグリゲーターからクレデンシャルが盗まれると、30-90日間の保持期間中、検索、エクスポート、およびログアクセス権限があるすべての人にアクセス可能です。
###露出期間
メモリ内でのクレデンシャル露出期間：最大（セッション期間、プロセスライフタイム）。セッション：数時間から数日。プロセス：数時間から数週間。
ログ内でのクレデンシャル露出期間：最大（セッション期間、ログ保持期間）。セッション：数時間から数日。保持期間：30-90日。
メモリからクレデンシャルを盗むには、攻撃者がセッション期間中にプレゼンスが必要です。ログからクレデンシャルを盗むには、ログアグリゲーターにアクセスするだけで、保持期間全体にわたって、過去にリトロアクセスが必要です。
MOAD-0003 vs MOAD-0004
MOAD-0003（リークコンテキスト）：クレデンシャルがメモリにリークされ、間違ったリクエストハンドラにアクセスします。プロセス期間中にのみアクセス可能です。スレッドプールを通じて。ephemeral。
MOAD-0004 (ログ済み秘密): ディスクに保存された資格情報はロットレーション、ログシッピング、およびログアグリゲーションを通じてパERSISTENTです。30-90日後に誰でもログアクセスが可能な場合に後付けでアクセス可能です。持続的です。
構造的な違い：ephemeral vs persistent。修正は異なるレイヤーで作用します。
ephemeral vs Persistent
ephemeral/persistentの区別はリスク表面、修正レイヤ、およびインシデント対応要件を決定します。
シリアル化レイヤーでの資格情報denylist
修正：シリアル化レイヤーでの資格情報denylist。ログ出力に達する前にヘッダー名がdenylistに含まれているかどうかを確認し、値を[REDACTED]に置き換えます。
CREDENTIAL_HEADERS = {
'authorization',
'cookie',
'x-api-key',
'x-auth-token',
'x-csrf-token',
'proxy-authorization',
}
def sanitize_headers(headers: dict) -> dict:
return {
k: '[REDACTED]' if k.lower() in CREDENTIAL_HEADERS else v
for k, v in headers.items()
}denyリストはシリアル化レイヤに属し、ログクエリレイヤには属しません。ログクエリの削除は、資格情報がディスクに到達した後に適用されます。RAW値は存在しますが、表示から隠蔽されます。シリアル化レイヤの削除は、資格情報がディスクに到達することなく終了します。RAW値はログファイル、ログシッパ、またはログアグリゲーターに到達することなく終了します。
denyリストのテスト
3つのテストパターンがあります:
- 正の結果: Authorization: Bearer token123を含むリクエストは、ログエントリに Authorization: [REDACTED]を生成します
- 負の結果: Content-Type: application/jsonを含むリクエストは、値が不変のままログエントリを生成します
- 大文字・小文字無視: AUTHORIZATION: Bearer token123も [REDACTED]を生成します(HTTPヘッダー名は大文字・小文字無視されます)
denyリストはメンテナンスが必要です: 新しい資格情報ヘッダー パターン(例: カスタム X-Service-Authヘッダー)は、明示的に追加する必要があります。修正は構造的ですが、自己維持ではありません。
denyリストの適用
チームは、Nginxアクセスログフォーマットを、リクエストヘッダーすべてを含めるように設定し、生産性の問題を解決するためにログを調整します。設定は次のとおりです:
log_format debug_format '$remote_addr - $request - $http_authorization - $http_cookie';
access_log /var/log/nginx/debug.log debug_format;問題を解決し、デバッグ構成を削除する予定ですが、次のデプロイサイクル(7日後)まで変更が生産環境に到達しません。