多層防御（Defense in Depth）

導入

「ファイアウォールさえあれば安全」という発想はSAAでは通用しません。1つの防御が突破されても被害が広がらないように、何重にも守りを重ねる——これが多層防御の考え方です。

説明

多層防御（Defense in Depth） は、単一の対策に頼らず、複数の層でそれぞれ独立した防御を行う設計原則です。SAAで扱うセキュリティサービスは、たいていこの「どの層を守るか」で整理できます。

flowchart TD
    subgraph エッジ層
      WAF["WAF / Shield"]
    end
    subgraph ネットワーク層
      SG["セキュリティグループ / ネットワークACL"]
    end
    subgraph ホスト層
      IAM["IAMロール / パッチ管理"]
    end
    subgraph データ層
      KMS["KMS暗号化 / ACM"]
    end
    エッジ層 --> ネットワーク層 --> ホスト層 --> データ層

例えばWebアプリを守る場合、WAFで不正なリクエストを弾き（エッジ層）、セキュリティグループで許可するポートを絞り（ネットワーク層）、EC2にはロールだけを渡してアクセスキーを持たせず（ホスト層）、保存するデータはKMSで暗号化する（データ層）——というように同時にすべての層を固めるのが正しい設計です。

具体例

「1つの守りに頼る」ことの危うさを、攻撃者に一歩ずつ突破されるシナリオで考えてみましょう。単層防御と多層防御の差が見えます。

単層防御（危険）：入口のWAFだけで守っているアプリ。攻撃者が新種の手口でWAFをすり抜けると、そこから先は無防備。DBまで一直線でデータを抜かれる。

多層防御（正しい設計）：仮に1枚破られても、次の壁が待ち構えています。

1. WAFをすり抜けた → でもDBはプライベートサブネットにいて、セキュリティグループが特定サーバー以外を弾く（ネットワーク層）
2. 運よくサーバーに侵入 → でもそのサーバーはアクセスキーを持たず、ロールの最小権限しか行使できない（ホスト層）
3. 権限内でデータを取得 → でもデータはKMSで暗号化されていて、鍵がなければ中身は読めない（データ層）
4. これらの試みはCloudTrailとGuardDutyが記録・検知し、運用チームに通報（監査・検知層）

どの1枚も完璧ではありませんが、重ねることで全体として破られにくくなる。これが多層防御の思想で、この章の残りのレッスンはすべてこの表のどこかの層を担っています。

読んでみよう

この章の残り5レッスンは、実はすべてこの表のどこかに位置づけられます。「今学んでいるサービスはどの層を守っているのか」を意識しながら読み進めると、知識がバラバラにならず整理できます。