第 10 章: ログ、監視、インシデント対応

10.1.1 転送ライフサイクルのイベント

• 転送の作成 (transferId の生成)
• チャンクのアップロード完了 (平文ではなく、暗号文のレベルで記録)
• マニフェストの書き込み/更新
• 有効期限切れによるクリーンアップ、ユーザーによる削除/取り消し (クリーンアップタスクの起動と完了を含む)
• ダウンロードの開始/完了 (暗号文のダウンロードのレベルで計測)

10.1.2 認証・認可のイベント

• セッショントークンの発行、検証の失敗 (スコープの不一致、期限切れ、取り消し済みなど)
• 長期ログイントークンの検証の失敗 (管理操作の拒否)
• 不審なアクセスパターン: 401/403/404 の異常な急増

注: 記録するのは「結果と理由コード」のみです。トークンの平文、Authorization ヘッダーの平文、署名パラメーターの平文を記録してはなりません (MUST NOT)。

10.1.3 システムの健全性とパフォーマンスの指標

• リクエストのレイテンシー (p50/p95/p99)、エラー率、スループット
• オブジェクトストレージの読み書き失敗率、オリジン取得の失敗率、リトライ回数
• エッジノードの異常、キューの滞留、バックグラウンドのクリーンアップタスクの成功率
• 帯域幅とトラフィックの推移 (集計した単位)

10.1.4 セキュリティ保護のイベント

• レート制限の発動、WAF/ファイアウォールのルールへの該当
• 列挙やブルートフォースの疑いがある動作のしきい値超過
• 異常な同時実行数とトラフィックのパターン (同一の送信元からの高い同時実行数、リソースへの異常なアクセス集中)

10.1.5 集計とサンプリング

• SHOULD: 件数とレイテンシーの分位数を分/時間単位で集計し、粒度の細かいログを減らします。
• SHOULD: 成功した高頻度のリクエストはサンプリングし、エラーや異常な経路についてのみ必要な詳細を保持します。
• SHOULD: 異常イベントについては、監査や機械による分析を容易にするため、安定した分類フィールド (eventType、reasonCode など) を保持します。

10.2.1 サーバー側で記録してはならないもの (MUST NOT)

• CEK (コンテンツ暗号鍵) と、導出可能なすべての素材
• URL フラグメント (#...)、location.hash、およびフラグメントを含む完全な URL
• 平文のコンテンツ: ファイルの平文、プレビューの内容、復号されたチャンク、または平文の要約
• 機密性の高い認証情報の平文: セッショントークン、長期トークン、Authorization ヘッダーの平文、署名付き URL に含まれる署名フィールドの平文

デバッグのために URL を記録する必要がある場合は、サニタイズ (フラグメントの削除、機密性の高いクエリのマスクまたは削除) を必ず行い (MUST)、それをコードのレベルで強制します (人手による運用ルールに頼りません)。

10.2.2 クライアント側で記録してはならないもの (MUST NOT)

• 本番環境で location.href (フラグメントを含む可能性があります) を出力しないこと
• フラグメント、CEK、noncePrefix を含む URL をエラーレポートに含めないこと
• デバッグログと開発者ツールの出力は、デフォルトでは無効にするか最小限にすること

SHOULD: フロントエンドでログ/レポートの出力用関数を 1 つにまとめ、出力や送信の前に、その内部で URL のサニタイズと機密フィールドのフィルタリングを行います。

10.3.1 可用性とパフォーマンスのアラート

• エラー率のアラート: 5xx の急増、4xx の異常な上昇 (認証の失敗と不正利用を区別する)
• レイテンシーのアラート: p95/p99 のしきい値超過、リージョンごとのオリジン取得の異常
• ストレージのアラート: オブジェクトストレージの書き込み失敗の増加、読み取りのタイムアウト
• クリーンアップタスクのアラート: 有効期限切れのクリーンアップの滞留、削除タスクの過度なリトライ

10.3.2 セキュリティのアラート

• レート制限の発動率の異常な上昇
• 同一の送信元からの高頻度の 401/403/404 (列挙やブルートフォースの疑い)
• 単一のリソースに対する異常なダウンロード帯域幅/同時実行数 (トラフィックの洪水やホットリンクの疑い)
• 重要なポリシーの変更 (WAF ルール、CSP/ヘッダーの変更など) は、変更監査とアラートの対象とすべきです (該当する場合)

10.3.3 アラートの運用管理

• SHOULD: アラートを分類 (P0/P1/P2) し、ローテーションとエスカレーションの経路を設けます。
• SHOULD: ノイズの多い指標にはデバウンスやウィンドウ集計を適用し、アラート疲れを避けます。
• SHOULD: 各アラートには、機密データを含まない最小限の診断情報 (理由コード、推移グラフ、影響を受けるリージョン/経路) を添付します。

10.4.1 代表的な異常パターン

• 列挙: 短時間に transferId やリソースのパスを大量に探る試行、404/401/403 の急増。
• ブルートフォース: 短いコード、パスワード、トークンに対する高頻度の試行、異常な失敗率の推移。
• トラフィックの洪水: 単一のリソースの異常な帯域幅、同一の送信元からの大量の同時接続、繰り返されるダウンロード。
• プロトコルの異常: 不自然なチャンクの順序、重複したアップロード、頻繁な中断とリトライ、異常な UA パターン。

10.4.2 緩和策 (原則)

• SHOULD: レート制限、段階的なブロック、チャレンジの仕組み (該当する場合)、ASN/リージョン/フィンガープリントに基づく動的なポリシーを用います。
• SHOULD: 誤検知の影響を受けやすい経路 (通常のユーザーでも頻繁にダウンロードすることがあります) には、遅延や段階的なスロットリングなど、より穏やかな対策を採用します。
• MUST: 実施した措置について、監査可能な発動条件 (理由コード、しきい値の区分) を保持し、(該当する場合) サポート窓口を提供します。