セキュリティのこれまでとこれから
境界防御、Webセキュリティ、クラウド、ゼロトラスト、DevSecOps、AIエージェント時代へとセキュリティの重心がどう移ってきたかを整理する。
セキュリティの重心は移動してきた
セキュリティは、時代ごとに守る対象と攻撃面を変えてきた。
かつては社内ネットワークと外部ネットワークの境界を守ることが中心だった。
その後、Webアプリ、クラウド、モバイル、SaaS、サプライチェーン、DevOpsが広がり、境界は曖昧になった。
AIエージェント時代には、さらに「自然言語で動く実行主体」と「外部知識を取り込むシステム」が攻撃面に加わる。
変化しているのは、セキュリティの目的ではなく、目的を達成するための設計対象である。
大きな流れ
| 時代 | 中心課題 | 代表的な考え方 |
|---|---|---|
| 境界防御 | 社内と外部を分ける | Firewall、VPN、IDS/IPS |
| Webアプリ | 公開アプリの入力と認証を守る | OWASP Top 10、セキュアコーディング |
| クラウド | 責任分界とIAMを管理する | Shared Responsibility、Infrastructure as Code |
| ゼロトラスト | 内外を問わず検証する | Never trust, always verify |
| DevSecOps | 開発フローに安全性を埋め込む | Shift Left、SAST、SCA、CI/CD |
| AIエージェント | 自然言語、知識、ツール権限を制御する | LLM Security、Human-in-the-Loop、権限分離 |
1. 境界防御の時代
境界防御では、社内ネットワークを信頼できる内側、インターネットを信頼できない外側として扱った。
主な対策:
- Firewall
- VPN
- IDS/IPS
- ネットワークセグメント
- 社内端末管理
この考え方は今も必要だが、SaaS、リモートワーク、クラウド、API連携が増えたことで、境界だけでは守れなくなった。
2. Webアプリセキュリティの時代
インターネットに公開されたWebアプリは、世界中の誰でもリクエストを送れる。
そのため、入力検証、認証、認可、セッション管理、出力エンコーディングが中心課題になった。
主な対策:
- OWASP Top 10
- セキュアコーディング
- WAF
- セキュリティヘッダー
- ペネトレーションテスト
- SAST/DAST
AI時代でも、Webアプリの基本は変わらない。
AI機能の多くはWebアプリやAPIの上に載るため、土台が弱いとAI固有対策だけでは守れない。
3. クラウドと責任分界
クラウドでは、物理サーバーや一部の基盤はクラウド事業者が守るが、設定、IAM、データ、アプリケーションは利用者が責任を持つ。
主な対策:
- IAM最小権限
- ネットワーク制御
- 暗号化と鍵管理
- 監査ログ
- CSPM
- IaCスキャン
クラウドの失敗は、設定ミスと過剰権限から起きやすい。
AIエージェントがクラウド操作権限を持つ場合、この問題はさらに重要になる。
4. ゼロトラスト
ゼロトラストは、ネットワークの内側だから信頼するという前提を捨てる考え方である。
ユーザー、端末、アプリ、リクエスト、コンテキストを継続的に検証する。
主な考え方:
- 明示的に検証する
- 最小権限を適用する
- 侵害を前提にする
- 継続的に監視する
AI開発でもゼロトラストは相性がよい。
モデル、外部文書、ツール、生成コード、ユーザー入力を無条件に信頼しない設計に接続できる。
5. DevSecOps
DevSecOpsは、セキュリティを開発・運用の外側ではなく、日々の開発フローに組み込む考え方である。
主な実践:
- PRでのSAST
- 依存関係スキャン
- Secret scanning
- IaCスキャン
- セキュリティレビュー
- 脅威モデリング
- インシデント後の学習
AI開発では、生成速度が上がるため、DevSecOpsの重要性も上がる。
AIがコードを書いても、リポジトリに入る前の検査、レビュー、テスト、依存関係管理は必要である。
6. AIエージェント時代
AIエージェント時代の特徴は、AIが単に文章を返すだけでなく、外部情報を読み、計画を立て、ツールを呼び出し、業務操作を行うことにある。
新しい課題:
- 外部コンテンツに埋め込まれた指示をどう扱うか
- RAGの検索範囲と権限をどう制御するか
- モデル出力を実行前にどう検証するか
- エージェントにどこまで権限を与えるか
- 人間の承認をどこに挟むか
- プロンプト、出力、ツール実行履歴をどう監査するか
AIエージェントは、開発者、運用者、利用者の作業を代行する。
そのため、セキュリティ設計では「モデルが何を知っているか」だけでなく、「モデルが何をできるか」を管理する。
これからのセキュリティで重要になること
Secure by Design
セキュリティを利用者や運用担当者の努力に押し付けるのではなく、製品・機能の設計段階から安全にする考え方が強くなる。
AI機能でも、初期設定で過剰権限を与えない、危険操作は確認を挟む、ログと監査を標準で持つ、といった設計が求められる。
人間とAIの責任分界
AIが提案し、人間が承認するのか。AIが自動実行し、人間が監査するのか。
責任分界を曖昧にすると、事故が起きたときに原因も改善策も説明できない。
セキュリティの民主化
AIは攻撃者にも防御者にも使われる。
開発者がAIでコードを書くなら、セキュリティレビュー、脅威モデリング、ログ分析、脆弱性修正にもAIを使う流れになる。
ただし、AIの提案を採用する責任は人間と組織に残る。
継続的な検証
AI機能はモデル更新、プロンプト変更、RAG文書更新、ツール追加で挙動が変わる。
一度レビューして終わりではなく、継続的にテストし、監視し、改善する必要がある。
変わらない原則
技術が変わっても、次の原則は変わらない。
- 守る資産を明確にする
- 信頼境界を描く
- 最小権限を適用する
- 入力を信頼しない
- 出力を文脈に応じて検証する
- 監査できる記録を残す
- 失敗時の被害範囲を限定する
- 学びを開発プロセスに戻す
AI開発時代のセキュリティは、過去のセキュリティを捨てることではない。
過去の原則を、自然言語、モデル、RAG、エージェント、生成コードに拡張することである。
関連Docs
参考リソース
- NIST SP 800-207 Zero Trust Architecture - https://csrc.nist.gov/publications/detail/sp/800-207/final
- NIST SP 800-218 Secure Software Development Framework - https://csrc.nist.gov/pubs/sp/800/218/final
- CISA Secure by Design - https://www.cisa.gov/securebydesign
- OWASP Top 10 for LLM Applications - https://owasp.org/www-project-top-10-for-large-language-model-applications/
- 1. 🤖AI開発時代のセキュリティとは
- 2. 🗺️AI開発時代のセキュリティリスク地図
- 3. 🧭リスクから逆算するセキュリティ学習ロードマップ
- 4. 🧠セキュリティスペシャリストに求められる人的能力
- 5. 🏢業界・業種で変わるセキュリティの見方
- 6. ⏳セキュリティのこれまでとこれから
出典: NIST SP 800-207 Zero Trust Architecture / NIST SP 800-218 SSDF / CISA Secure by Design / OWASP Top 10 for LLM Applications