# 多層防御 ## 定義 多層防御(defense in depth)とは、複数の防御境界層を設けることで攻撃者に与える可視性を制限し、悪用の実行を難しくする設計原則である。単一の防御が突破された場合でも、次の層が前の層の弱点や失敗しやすい箇所を見越して補完するよう設計されて初めて成立する。トロイの木馬の逸話は、脅威モデリングと脆弱性発見・展開・実行・侵害という攻撃の4段階それぞれに対応する防御機会を逃したという多層防御欠如の教訓として提示される。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 8 Design for Resilience]] ch.8 §The Trojan Horse) Google App Engine のサンドボックス設計はこの原則の具体例であり、危険 API の除去・Native Client(NaCl)へのコンパイル・`ptrace` によるシステムコール監視という3層を重ねる。各層は「前の層で防ぎきれなかった場合」を明示的に想定して設計されており、5年間の運用で発見された悪用はいずれも設計上の範囲内に封じ込められた。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 8 Design for Resilience]] ch.8 §Google App Engine Analysis) ## 横断的知見 (本概念は今回の ingest で初めて作成された。複数ソースの突き合わせによる横断的知見は今後の ingest で蓄積する。) ## 未解決の問い - App Engine の「危険 API 除去 → NaCl → `ptrace`」という3層は、それぞれ独立した前提(バイトコード生成の悪用・メモリ破壊・予期しないシステムコール)を防ぐよう設計されているが、層の数を増やすほど運用・監査コストも増える。何層が最適かを判断する一般的な基準はあるか。 - トロイの木馬の4段階(脅威モデリング・展開・実行・侵害)モデルは、現代のキルチェーン/TTP フレームワーク(MITRE ATT&CK 等)とどこまで対応し、どこが単純化されているか。 - 多層防御が[[ゼロトラスト]]と両立する場合(層ごとに独立して信頼を検証する)と、単に境界防御を重ねるだけで内部は暗黙に信頼したままの場合(多層セキュリティ(MLS)寄りの発想)を、実装の観点でどう見分けるか。 ## 関連 - ソース: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 8 Design for Resilience]] - 概念: [[レジリエンス]] / [[影響範囲の制御]] / [[ゼロトラスト]] - 実体: [[Google App Engine]] ## 出典 - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 8.