0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

なぜセキュリティ界隈で改ざん検知が下火になったのか

Posted at

近年、セキュリティ対策として改ざん検知とかあまり強く求められなくなったなと漠然と感じていたので、その感覚の正体をCopilotに言語化してもらいました。

1. はじめに:かつて改ざん検知は“必須”だった

2000〜2010 年代前半、Tripwire を代表とする「ファイル改ざん検知」は、
セキュリティ対策の中心的存在でした。

  • Web サーバーは OS 上に直接アプリを配置
  • 手作業デプロイが一般的
  • root 侵害が多発
  • 改ざん=即アウト
  • 監査要件でも必須

この時代、ファイルのハッシュを監視することが侵害検知の最前線でした。

2. 改ざん検知が下火になった理由(本質的な構造変化)

2-1. インフラが「不変(Immutable)」になった

現代のインフラは、以下のように“書き換えられない前提”で設計されます。

  • コンテナ(Docker)
  • イメージベース(AMI, Image Builder)
  • IaC(Terraform, CloudFormation)
  • GitOps(ArgoCD, Flux)

本番環境は読み取り専用で、変更は Git に記録されるという世界では、
「ファイル改ざん検知」は役割を失います。

改ざんされる前提 → 改ざんされない前提へ

2-2. 攻撃モデルが“ファイル改ざん”から“ランタイム侵害”へ移行

昔の攻撃:

  • Web サーバーに侵入
  • ファイルを書き換える
  • 改ざんされたページを配信

今の攻撃:

  • API 経由の不正操作
  • クラウド IAM の悪用
  • ランタイムでの不正プロセス
  • コンテナの脱出
  • サプライチェーン攻撃

つまり、ファイル改ざんは攻撃の中心ではなくなった

2-3. クラウドネイティブな監査ログが“改ざん前”の操作を記録するようになった

AWS / Azure / GCP は、すべての管理操作を監査ログに残します。

  • IAM の変更
  • セキュリティグループの変更
  • S3 の削除
  • EC2 の停止
  • Lambda の更新

これらは ファイル改ざんより前の段階で侵害を検知できるため、
ファイル監視の優先度が下がりました。

2-4. CSP・SRI により“改ざんされても実行されない”世界になった

ブラウザ側の進化も大きいです。

  • CSP(Content Security Policy)
  • SRI(Subresource Integrity)

これにより:

  • 改ざんされた JS/CSS は実行されない
  • CDN 改ざんも検知できる

“改ざんされても動かない”世界では、改ざん検知の価値は相対的に低下します。

2-5. EDR・WAF・eBPF によるランタイム監視が主流に

現代の侵害検知は:

  • EDR(Endpoint Detection & Response)
  • WAF
  • eBPF ベースのランタイム監視(Falco など)

これらは ファイル改ざんよりも上位レイヤーで侵害を検知します。

結果として:

ファイル改ざん検知は“最後の砦”から“補助的な対策”に降格した。

2-6. Web が動的化し、改ざんされる静的ファイルが減った

昔:

  • HTML/CSS/JS がサーバー上に置かれていた
  • 改ざん=画面が書き換わる

今:

  • SPA(React/Vue)
  • CDN 配信
  • API サーバーは JSON を返すだけ

そもそも改ざんされるファイルが減った

2-7. Tripwire のポリシーが現代の運用と合わない

  • 変更が多い
  • CI/CD と衝突
  • 誤検知が多い
  • 運用コストが高い

結果:

“入れたけど運用できず無効化される”ケースが多発

3. それでも改ざん検知が必要な領域は残っている

3-1. 金融・政府(法規制で義務)

  • SEC 17a-4
  • FINRA
  • FISC
  • ISMAP

これらは WORM ストレージや改ざん検知を要求します。

3-2. 物理サーバー運用

クラウドではなくオンプレの場合、
ファイル改ざん検知は依然として有効です。

3-3. サプライチェーン攻撃対策

ビルド環境や署名キーの改ざん検知は今も重要。

4. 改ざん検知の“現代版”は何か?

現代では、改ざん検知は以下の形に進化しています。

🔹 1. WORM ストレージ(S3 Object Lock)

ログを削除不可にする。

🔹 2. GitOps による構成の一貫性

本番環境は Git の状態と一致しているかを監視。

🔹 3. eBPF / Falco によるランタイム監視

不審なプロセス・ファイルアクセスを検知。

🔹 4. イメージ署名(Cosign)

改ざんされたコンテナイメージをデプロイできない。

🔹 5. クラウド監査ログ

改ざん“前”の操作をすべて記録。

5. まとめ:なぜ改ざん検知が下火になったのか

要因 内容
インフラの不変化 改ざんされる前提が消えた
攻撃モデルの変化 ファイル改ざんより IAM・API 攻撃が主流
クラウド監査ログ 改ざん前の操作を検知できる
ブラウザの進化 改ざんされても実行されない
ランタイム監視の普及 ファイル監視より上位レイヤーで検知
Web の動的化 改ざんされる静的ファイルが減った
Tripwire の運用負荷 現代の CI/CD と相性が悪い

6. 結論:改ざん検知は“不要になった”のではなく、“役割が移動した”

現代のセキュリティはこう変わりました。

  • 昔:ファイル改ざん検知が中心
  • 今:構成管理・ランタイム監視・クラウド監査が中心

つまり:

改ざん検知は下火になったのではなく、より上位の仕組みに吸収された。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?