第 10 章: ロギング、モニタリング、およびインシデント対応

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

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

10.1.2 認証および認可イベント

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

注: 「結果コードと理由コード」のみを記録します。 してはなりません レコードトークン平文、認可ヘッダー平文、または署名パラメータ平文。

10.1.3 システムの健全性とパフォーマンスのメトリクス

• リクエストのレイテンシー (p50/p95/p99)、エラー率、スループット
• オブジェクトストレージの読み取り/書き込み失敗率、オリジンフェッチ失敗率、再試行回数
• エッジノードの異常、キューのバックログ、バックグラウンドのクリーンアップタスクの成功率
• 帯域幅とトラフィックの傾向 (合計ディメンション)

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

• レート制限トリガー、WAF/ファイアウォール ルールのヒット
• 疑わしい列挙/ブルートフォース動作のしきい値トリガー
• 異常な同時実行性とトラフィック パターン (同じソースからの高い同時実行性、異常なリソース ヒート)

10.1.5 集約とサンプリング

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

10.2.1 サーバー側で記録してはなりません

• CEK (コンテンツ暗号化キー) および派生可能なマテリアル
• URL フラグメント (#...), location.hash、およびフラグメントを含む完全な URL
• 平文コンテンツ: ファイルの平文、プレビュー コンテンツ、復号化されたチャンク、または平文の概要
• 機密資格情報の平文: セッショントークン、長期トークン、認証ヘッダー平文、署名付き URL の署名フィールド平文

デバッグのために URL のログ記録が必要な場合: MUST サニタイズ (フラグメントの削除、機密性の高いクエリの編集または削除) を行い、これをコード レベルで強制します (手動の規則に依存しません)。

10.2.2 クライアント側で記録してはなりません

• 印刷しないでください location.href 運用環境では (フラグメントが含まれる場合があります)
• フラグメント、CEK、または noncePrefix を含む URL をエラー レポートに含めないでください
• デバッグ ログと開発ツールの出力はデフォルトで無効にするか最小化する必要があります

SHOULD: 出力/レポートの前に 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 一般的な異常パターン

• Enumeration：短時間での transferId / リソース パスの大規模なプローブ、404/401/403 の急増。
• ブルートフォース: ショート コード/パスワード/トークンの試行頻度が高く、異常な失敗率曲線。
• トラフィックの洪水: 単一リソースの異常な帯域幅、同じソースからの大量の同時接続、繰り返しのダウンロード。
• プロトコルの異常：不合理なチャンク順序、重複アップロード、頻繁な中断/再試行、異常な UA パターン。

10.4.2 緩和戦略 (原則)

• SHOULD: レート制限、段階的禁止、チャレンジ メカニズム (該当する場合)、ASN/リージョン/フィンガープリントに基づく動的ポリシー。
• SHOULD: 誤検知の影響を受けやすいパスに対しては、より穏やかな戦略 (遅延、セグメント化されたスロットルなど) を採用します (通常のユーザーは頻繁にダウンロードする可能性があります)。
• MUST: 実行されたアクションの監査可能なトリガー (理由コード、しきい値カテゴリ) を保持し、サポート チャネルを提供します (該当する場合)。