本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「セキュリティアーキテクチャ」カテゴリ第5弾として、ネットワークセキュリティについて解説する記事です。
外部からの不正アクセス・不審通信・内部からの情報流出をネットワーク層で検知・遮断する設計です。本記事ではFW／VPC／WAF／IDS/IPS／DDoS防御の主要要素、ゼロトラストへの移行、AI時代のEgress制御まで扱い、「境界さえあれば安全」という神話から脱却する指針を示します。
本記事のテーマについてさらに詳しく知りたい方は『Amazon Web Services基礎からのネットワーク＆サーバー構築 改訂4版』も参考にしてみてください。
この記事の結論
- ゼロトラストを出発点にする（「社内LANだから安全」は2015年で終わった）
- CDN+WAF+DDoS対策で攻撃面を減らし、オリジンIPを隠す
- DBは必ずPrivateサブネットに隔離する
- Egress（外向き通信）制御でAIの行き先を絞る
この記事を読む前に
本記事は認証・認可・暗号化といったセキュリティ用語が多めに登場します。IT用語にあまり馴染みがない方は、基礎編の「セキュリティと認証の基本」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもネットワークセキュリティとは何か
ネットワークセキュリティとは、ざっくり言えば「通信経路上で不正アクセスや情報漏洩を検知・遮断する防御の仕組み」です。
空港のセキュリティチェックを想像してください。入国審査（ファイアウォール）で不審者を弾き、手荷物検査（IDS/IPS）で危険物を検知し、搭乗ゲート（セキュリティグループ）で最終確認します。どれか1つが突破されても次の層で止められる──この多層構造がネットワークセキュリティの基本です。
なぜネットワークセキュリティが重要なのか
どれだけアプリを堅牢にしても、不要なポートが開いていれば突破されます。ネットワーク層で「見えない・届かない」を作るのが最も確実で、アプリの脆弱性や鍵の漏洩に備える多層防御（Defense in Depth）の土台にもなります。PCI DSS・ISO 27001等の監査でもネットワーク層の制御は必須要件です。
そして前提が変わりました。かつての「社内ネットワークは安全・外部は危険」という境界型の考え方は、クラウド・リモートワーク時代に崩壊し、全てを信用せず常に検証するゼロトラストに移行しています。
多層防御の主要要素
| 要素 | 役割 | 代表例 |
|---|---|---|
| VPC・サブネット分離 | ネットワークの論理隔離 | Public / Private / Isolated |
| ファイアウォール | 通信の許可 / 拒否 | Security Group・NGFW |
| WAF | Webアプリ特化の防御 | AWS WAF・Cloudflare |
| DDoS対策・CDN | 大量トラフィック吸収 | CloudFront・Shield |
| IDS / IPS・SIEM | 侵入検知・ログ相関分析 | GuardDuty・Suricata |
| VPN / ZTNA | リモート接続 | WireGuard・Cloudflare Access |
VPCとサブネット分離 ― DBは必ずPrivateへ
論理的に隔離されたネットワーク空間（VPC）を作り、Public / Private / Isolatedのサブネット分離で多層化します。DBは必ずPrivateサブネットに配置し、インターネットから直接到達できないようにするのが鉄則です。この基本を守らずDBをPublicに置く事故が今でも発生します。ファイアウォールはクラウドではSecurity Group（AWS）等が標準で、インスタンスごとに最小限のポートだけ開けます。
WAFとDDoS対策 ― CDN前置が最低ライン
WAFはSQLインジェクション・XSS・ボット攻撃などWebアプリ特有の攻撃を署名・行動ベースで遮断します。クラウドWAFは数時間で導入でき、Cloudflareは無料プランでも基本機能を提供します。DDoSは数百Gbps規模の攻撃が当たり前で、単独サーバーでは受けきれないため、CDN（Cloudflare・CloudFront+Shield）で分散吸収します。CDNにはオリジンIPを隠せるという重要なセキュリティ効果もあります。2016年のDyn DNS事件（Miraiボットネットの1.2Tbps DDoSでTwitter / GitHub / Netflixが数時間停止）は、単独で受け切るのは不可能という現実を突きつけました。
IDS / IPS・VPN / ZTNA・マイクロセグメンテーション
IDSは侵入検知、IPSは自動遮断まで行い、複数レイヤーを統合するXDR・ログを相関分析するSIEMへと発展しています。リモート接続は、従来のVPN自体が攻撃対象になる時代（2021年のPulse Secure脆弱性事件で米政府機関まで侵害）となり、アプリ単位で認可するZTNA（Cloudflare Access・Tailscale等）への移行が進んでいます。新規にVPNを組むなら高速なWireGuardが第一候補です。
さらに侵害時の横展開（Lateral Movement）を防ぐため、ネットワークを小さなセグメントに分割し、サービス間通信をmTLSで暗号化・認証する（Istio等のサービスメッシュ）のがゼロトラストの目標形です。
どう選べばいいのか ― 規模×脅威別の段階表
※ 2026年4月時点の業界相場値です。
ネットワーク防御は「全部入り」ではなく、規模と脅威レベルに合わせた段階的導入が現実解です。
| 規模・脅威 | 最低限の構成 | 実装の目安 |
|---|---|---|
| 個人・公開サイト | Cloudflare無料枠+Private Subnet | 1時間 |
| 小規模SaaS | CloudFront+WAF+Security Group | 1週間 |
| 中規模B2C | +Shield Standard+Rate Limit+Bot対策 | 2週間 |
| 大規模B2B | ZTNA+IPS+SIEM | 数ヶ月 |
| 金融・医療 | +専用線+24/7 SOC+mTLS全通信 | 1年〜 |
「DDoS対策の実質下限はCDN経由配信」です。Cloudflareの無料枠だけでもDDoS吸収・WAF・ボット対策が入り、個人サイトでも商用級の防御を敷けます。公開IPはBotに24時間365日スキャンされているため、CDN前置は最低ラインの防御です。
3つのシナリオで考える
個人開発・スタートアップの場合
Cloudflareの無料枠とPrivateサブネットの2点だけで、商用級の防御になってしまいます。DDoS吸収・WAF・ボット対策が無料で手に入りますし、DBをインターネットから隔離しておけば、公開IPをスキャンし続けているBotの大半を無力化できるのです。所要時間はたったの1時間程度だと思います。
中小SaaSの場合
CloudFrontとAWS WAF、Security Groupの最小化にRate Limitを加えたあたりが標準装備になります。オリジンIPはCDNの背後に隠して、SSHはSSM Session Manager経由にすることで22番ポート自体を閉じてしまいましょう。リモートアクセスについては、VPNではなくZTNA（Cloudflare AccessやTailscale）から始めるのが2026年の正解だと考えています。
大企業・金融の場合
ZTNAにIPS、SIEM、mTLSによるマイクロセグメンテーションまで含めたフル多層防御となります。侵害時の横展開を防ぐサービス間mTLSや、24/7のSOCによる監視、専用線接続まで含めて、FISCなどの規制要件がネットワーク設計そのものを規定していく世界です。
AI判断軸 ― Egress制御がAI時代の新しい柱
Egress制御がAI時代に重要度を増す理由
AIエージェントが外部APIを呼ぶ構成では、エージェントが意図しない宛先にデータを送信するリスクがあります。プロンプトインジェクション攻撃によって、AIが内部データを外部の攻撃者サーバに送信させられる可能性は現実的なものです。Egress制御（外向き通信のホワイトリスト化）をネットワーク層で設定しておけば、AIがどのような指示を受けても許可されたAPIエンドポイント以外には通信できません。セキュリティグループ・NAT Gateway経由のルーティング・プロキシでの宛先フィルタリングが具体的な実装手段です。
WAFルールのコード化とAI活用
WAFルールをTerraformで管理していれば、新しい攻撃パターンへのルール追加をAIに書かせることができます。ただしWAFルールの誤検知（正規リクエストのブロック）はビジネス影響が大きいため、AIが生成したルールは必ずステージング環境でのテストを経てから本番に適用する運用が必須です。
やってはいけないこと
侵害時の被害範囲を最大化する典型を、特に危険な6つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| DB / Redis / ElasticsearchをPublicに配置 | 2017年のランサム事件と同じ地雷 → Isolatedサブネットへ隔離する |
Security Groupで 0.0.0.0/0:22（SSH全開放） | 数時間でブルートフォース数千件が来る → 接続元を絞る / SSM経由にする |
| CDNなしでオリジン直公開 | 1.2Tbps級のDDoSを受けたら即終了 → Cloudflare無料枠でも前置する |
| VPNを最終防衛線として全信頼 | VPN自体が侵入口になる → ZTNAへ移行する |
| FWルールをGUIで手作業管理 | 変更履歴が残らず監査対応不能 → Terraformでコード化する |
| Egress制御なしでAIエージェント運用 | データ持ち出しリスクが残る → 外向き通信を許可リスト化する |
なおWAFを入れただけでアプリ側のSQLインジェクション対策をサボるのは論外です。WAFは一次遮断にすぎません。
筆者メモ ― 「大規模攻撃は届かない」と油断して沈んだ事例
Dyn DNS 2016年事件はCDN・DDoS対策サービスへの委譲を定石にし、2021年のPulse Secure VPN脆弱性（CVE-2021-22893）はVPN自体が攻撃の入り口となって米政府機関まで侵害され、ZTNAへの移行を一気に加速させました（詳細は付録「重大インシデント事例集」）。
身近なところでは、検証用EC2のSecurity Groupを 0.0.0.0/0 のまま数時間放置した翌朝、認証ログに数千件のSSHブルートフォースとマイナー混入試行が並んでいた、という経験談がよく聞かれます。公開IPは「開けた時点で攻撃が来る」と思って構え、検証用も本番並みに守るのが鉄則です。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- ネットワーク分離（VPC・サブネット設計）
- ファイアウォールルール（Security Group・コード化）
- WAF・DDoS対策（Cloudflare / AWS WAF+Shield）
- リモート接続方式（VPN / ZTNA）
- IDS / IPS・SIEMの採用（規模次第）
- Egress制御（外向き通信の許可リスト）
この記事に関連する記事
まとめ
本記事はネットワークセキュリティについて、多層防御の主要要素・規模×脅威別の段階表・AI時代のEgress制御まで含めて解説しました。如何だったでしょうか。
ゼロトラストを出発点に、CDN+WAF+DDoS対策で攻撃面を減らし、DBはPrivate隔離、Egress制御でAIの行き先を絞る。これが2026年のネットワークセキュリティの現実解です。
次回はゼロトラスト（BeyondCorp・ZTNA・継続検証）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は AWS WAF も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（56/95）