定義：壊れない防御はなぜ成立しにくいのか
「壊れない防御を作る」という表現は、現実のサイバー環境の性質と相いれないことが多いです。攻撃は常に変化し、守り側も技術更新や運用の変更で条件が変わります。また、脆弱性はソフトウェアだけでなく、設定、認証、権限、プロセス、人の判断、外部委託など多層に存在し得ます。
そのため、目標としては「侵入しない」一点に寄せるより、侵入・悪用が起きても被害を最小化し、素早く検知・封じ込め・復旧できる状態を作るほうが現実的です。
仕組み：攻撃チェーンに合わせて重ねる防御
サイバー戦の文脈で語られる「ソリューション」は、概念としては多くの場合、攻撃の流れ（偵察→侵入→拡大→目的達成）に対して、複数の防御を段階的に置く考え方に近いです。要点は次のように整理できます。
- 入口を狭める（侵入の難化）
- 不要なサービス停止、最小権限の徹底、強固な認証（多要素など）、脆弱な設定の是正など。
- ここで重要なのは「設定が維持されるか」で、導入直後だけ強くしても運用で崩れれば効果が落ちます。
- 拡大を抑える（横移動・権限昇格の抑制）
- セグメンテーション、権限設計、特権の扱い、重要資産へのアクセス制御など。
- “一つ突破されても全体に波及しにくい”構造を意識します。
- 検知して止める（観測と封じ込め）
- ログの収集と相関、異常検知、アラートの運用（誰が何を見てどう判断するか）。
- 検知は「見える」だけでは不十分で、実際に止められる手順が必要です。
- 復旧を早める（被害の回復力）
- バックアップ、復旧手順の訓練、再発防止の反映。
- “壊れない”よりも、“壊れても戻せる”を現実目標にします。
制限：どこで破綻しやすいか
「完全に壊れない」ことを難しくする要因は複数あります。代表的には次の制限が挙げられます。
- 攻撃側の更新：攻撃手法は変わり続け、同じ対策でも再現条件が変わることがあります。
- 人的要因：パスワード運用、例外申請、アカウント棚卸しの遅れ、インシデント時の判断ミスなど。
- 脆弱性の見落とし：テスト範囲外の設定・依存関係・サプライチェーン由来の弱点が残る場合があります。
- 検証不足：机上の整備で終わり、実際の攻撃想定に対する“成立性”が確認されない。
- 部分最適：ある製品や対策を入れて安心しても、全体の運用設計（可視化、応答、復旧）が連動していない。
ここでのポイントは、限界は一度で決まるものではなく、対策の重なり方と運用の品質で変動する点です。そのため「壊れない防御」という単語に引きずられるより、「破られた後の挙動を設計し、確認する」姿勢が重要になります。
実践的な確認方法：本当に効いているかを確かめる
“確認”は、導入物の性能を聞くよりも、あなたの環境で想定が通るかを見ます。次のチェック項目は、比較的汎用的に使えます。
- 脅威モデリングと想定の整合
- 「何を守るか」「どの入口から入られるか」「侵入後にどこまで到達するか」「最後に何が起きれば目的達成か」を整理します。