# セキュリティログの設計と保護 ## 定義 セキュリティログの設計と保護とは、将来のデバッグ・セキュリティ調査のために「何を記録するか」「どれだけ保持するか」「誰がどうアクセスできるか」を、コスト・プライバシー・調査有用性のトレードオフのもとで決定する設計問題である。*Building Secure and Reliable Systems* 第15章は、ログをはじめとする構造化・タイムスタンプ付き記録が、事故・意図的攻撃を問わずシステム調査の基盤であるとしたうえで、次の4つの設計軸を挙げる。(1) **不変性**: ログは書き込み後に改竄しにくくすべきだが完全に不可能である必要はなく、変更自体に監査可能な証跡を残せばよい。集中リモートログサーバへの書き込みは、攻撃者に元システムに加えてログサーバも侵害させる追加コストを課す。(2) **プライバシー**: 記録の深度・保持期間・アクセス制御・匿名化(仮名化)・暗号化を、プライバシー・法務部門と協議したうえで組織方針として定める。(3) **収集源の選定**: OS ログ・ホストエージェント・アプリケーションログ・クラウドログ・ネットワークベースの検知(NIDS/IPS・DNS ログ・Web プロキシログ)のどれを、どの粒度で保持するかを選ぶ。(4) **予算**: ログは無限に貯められないため、信号対雑音比の高いログを優先し、圧縮・warm/cold ストレージの分離・段階的劣化(データサマリゼーション)によってコストを制御する。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 15 Investigating Systems]] §Collect Appropriate and Useful Logs) ## 横断的知見 - **「tamper-proof でなく tamper-evident」という設計哲学が、物理封印とデジタルログの双方で独立に到達される**: [[封印と偽造防止印刷]] が集約する Security Engineering 第16章は、封印の設計目標を「改竄を物理的に防ぐこと」ではなく「改竄を検知可能にすること」に置くのが現実的だと述べ、ハードウェアではなく人間(適用者・検査者の動機・機会・技能)を欺く問題として封印のライフサイクル全体を捉える。第15章のログ不変性設計もこれと同型の判断を下す——ログは改竄を完全に不可能にする必要はなく、改竄されれば監査可能な痕跡が残る設計で十分だとし、ラインプリンタへの直接出力(遠隔攻撃者が痕跡を消すには誰かが物理的に用紙を持ち去って燃やす必要がある)を、その原初的な実装例として提示する。物理的封印とデジタルログという全く異なる媒体で、同じ「検知可能性を目標にする」設計哲学が独立に定着していることがわかる。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 15 Investigating Systems]] §Collect Appropriate and Useful Logs > Design Your Logging to Be Immutable, [[@2020__Wiley__Security Engineering 3e - Chapter 16 Security Printing and Seals]]) - **「大量のログの大半が使われない」という無駄を、運用側の予算論(ch.15)とコード側の定量分析(LogReducer)が異なる粒度で裏づける**: 第15章は「100 TB のログを持つシステムで、そのほとんどが一度も使われなかった」という実例を挙げ、信号対雑音比の低いログ(ファイアウォールが遮断した大量の無害パケットなど)を収集し続けることの無駄を組織の予算論として警告する。[[ログ生成]] が集約する [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]] は、この無駄をコードレベルで定量化しており、WeChat のログホットスポットの根本原因の 63.15% がログレベル誤設定とテストログ消し忘れに起因し、修正の 61.69% がログレベル修正・ログ文削除であったと報告する。前者は「保持コスト」という運用の粒度で、後者は「生成時点の記述品質」というコードの粒度で、同じ「有用性を検討せずログを積み増す」問題を異なる側面から確認しており、ロギングの経済性はログ生成段階と保持段階の両方で作り込む必要があることを示す。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 15 Investigating Systems]] §Collect Appropriate and Useful Logs > Budget for Logging, [[@2023__ICSE__LogReducer - Identify and Reduce Log Hotspots in Kernel on the Fly]]) - **「段階的劣化」という設計パターンが、バックアップ階層化(データ保護)とログのデータサマリゼーション(本ページ)で共通の形を取る**: [[データ保護]] が集約する SRE Book 第26章は、バックアップを層ごとに保持期間・復旧時間・コストの異なる階層として設計し、「バックアップを取ること自体でなく復旧できることを継続的に検証する」ことを重視する。第15章のログ予算論も同じ発想を取り、ストレージ上限に達したら収集を止めるのではなく、全量ログの一部を低精度な要約データへ切り替えて段階的に劣化させる(例: 完全パケットキャプチャは *N* 日で削除するがネットフローデータは1年保持する)ことを推奨する。両者は「限られた予算のもとで、価値の高いデータほど長く高精度に、価値の低いデータほど早く低精度に落とす」という同一の階層化原則を、バックアップとセキュリティログという異なる対象に独立に適用している。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 15 Investigating Systems]] §Collect Appropriate and Useful Logs > Budget for Logging, [[@2016__OReilly__SRE Book - Chapter 26 Data Integrity - What You Read Is What You Wrote]]) ## 未解決の問い - ログの匿名化・仮名化(デイリーキーペア方式など)は、調査者が個人を特定できないままセッション単位の行動タイムラインを構築できることを目指すが、この両立を定量的に検証した実装・評価事例は本 wiki にまだない。 - 「信号対雑音比の高いログを優先する」という予算論の指針は定性的である。どのログ源をどの優先順位で保持すべきかを決める定量的なフレームワーク(コスト対調査価値のモデル)は存在するか。 - tamper-evident なログ設計(集中リモートログサーバ)と、封印の検査体系(一次・二次・三次検査)のような「検知の階層化」は、デジタルログの改竄検知にどこまで応用できるか。 ## 関連 - ソース: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 15 Investigating Systems]] - 概念: [[封印と偽造防止印刷]](tamper-evident 設計哲学の物理的な対応物) / [[データ保護]](段階的劣化・階層化保持の対応物) / [[ログ生成]](ログ品質の経済性というコード側の対応物) / [[デバッグアクセスの設計]](ログへのアクセス制御という接続点) / [[オブザーバビリティ]] - 書籍: [[Building Secure and Reliable Systems]] ## 出典 - Pete Nuttall, Matt Linton, David Seidman, "Investigating Systems", Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 15, §Collect Appropriate and Useful Logs。