本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「セキュリティアーキテクチャ」カテゴリ第5弾として、ネットワークセキュリティについて解説する記事です。
外部からの不正アクセス・不審通信・内部からの情報流出をネットワーク層で検知・遮断する設計です。本記事ではFW/VPC/WAF/IDS/IPS/DDoS防御の主要要素、境界型防御からゼロトラストへの移行、AI時代のEgress制御の重要性まで扱い、境界さえあれば安全という神話から脱却する指針を示します。
このカテゴリの他の記事
「内側は安全」という神話が崩れてから始まる
かつては「社内ネットワークは安全・外部は危険」という境界型(Perimeter-based)の考え方が主流でしたが、クラウド・リモートワーク時代には境界が曖昧になり、全てを信用せず、常に検証するゼロトラストに移行しています。
「社内LANだから安全」という発想は2015年で終わっている。境界防御だけでは守れません。
なぜ必要か
① 攻撃の入り口を減らす
どれだけアプリを堅牢にしても、不要なポートが開いていれば突破されるリスクがあります。ネットワーク層で見えない・届かないを作るのが最も確実です。
② 多層防御の土台
「アプリが脆弱だったら」「鍵が漏れたら」に備え、ネットワーク層でも被害を止められる仕組みが必要です。1つ破られても他で守るDefense in Depthの考え方です。
③ コンプライアンス要件
PCI DSS・ISO 27001・個人情報保護法──いずれもネットワーク層の制御を求めます。ファイアウォールが無い環境は監査で即NGです。
ファイアウォール
通信を許可/拒否するフィルタで、ネットワークセキュリティの最も基本的な機能です。現代は単純なポート制御から、アプリケーション層まで見る次世代ファイアウォール(NGFW)へ進化しています。
| 種類 | 機能 |
|---|---|
| ステートフル | 接続状態で判断 |
| パケットフィルタ | ヘッダーで判断(古典) |
| 次世代(NGFW) | アプリ認識・IDS/IPS統合 |
| WAF | Webアプリ特化(SQL injection等) |
| クラウドFW | Security Group・NSG(Network Security Group、Azureのネットワーク層アクセス制御)等 |
クラウドでは Security Group(AWS)・NSG(Azure)・ファイアウォールルール(GCP)が標準で、インスタンスごとに細かく制御できます。
VPCとネットワーク分離
論理的に隔離されたネットワーク空間を作るのが VPC(Virtual Private Cloud)です。クラウド上で自社専用のネットワークを構築でき、サブネット分離(Public/Private/Intranet)で更に多層化できます。
flowchart TB
NET([インターネット<br/>= 攻撃者を含む])
subgraph VPC["VPC (自社専用ネットワーク)"]
PUB["Public Subnet<br/>Load Balancer / NAT"]
PRIV["Private Subnet<br/>アプリサーバ"]
ISO["Isolated Subnet<br/>DB / 機密データ"]
PUB --> PRIV --> ISO
end
NET --> PUB
BAD[DBをPublicに置く<br/>= 即漏洩事故]
BAD -.|アンチパターン| ISO
classDef threat fill:#fee2e2,stroke:#dc2626;
classDef pub fill:#fef3c7,stroke:#d97706;
classDef priv fill:#dbeafe,stroke:#2563eb;
classDef iso fill:#dcfce7,stroke:#16a34a,stroke-width:2px;
class NET,BAD threat;
class PUB pub;
class PRIV priv;
class ISO iso;
DBは必ずPrivateサブネットに配置し、インターネットから直接到達できないようにするのが鉄則です。この基本を守らずDBをPublicに置く事故が今でも発生します。
WAF(Web Application Firewall)
Webアプリ特有の攻撃を防ぐ専用ファイアウォールです。SQLインジェクション・XSS・CSRF・ボット攻撃──これらを署名ベース・行動ベースで検出・遮断します。クラウドWAFは設定が簡単で、数時間で導入可能です。
| サービス | 特徴 |
|---|---|
| AWS WAF | CloudFront・ALB統合 |
| Azure WAF | Application Gateway統合 |
| Cloudflare | CDNと一体化・人気 |
| Akamai | エンタープライズ |
| Imperva | 老舗・高機能 |
Cloudflareは無料プランでも基本WAF機能を提供しており、小規模サイトでも気軽に導入できます。
DDoS対策
大量トラフィックで停止させる攻撃(DDoS)は、ボットネットを使った数百Gbps規模の攻撃が当たり前です。単独サーバーでは受けきれないため、CDN・DDoS対策サービスで分散吸収します。
| 対策 | 内容 |
|---|---|
| CDN(Cloudflare・CloudFront) | 攻撃トラフィック吸収 |
| AWS Shield / Cloud Armor | クラウドネイティブ |
| レート制限 | IPごとのリクエスト数制限 |
| Captcha | ボット識別 |
| 地理的ブロック | 不要な国から遮断 |
Cloudflare は無料で基本的な DDoS 対策を提供しており、小規模でも対策可能です。大規模は Cloudflare Enterprise や AWS Shield Advanced が必要になります。
Dyn DNS 2016年事件(Miraiボットネットによる1.2Tbps DDoS で Twitter / GitHub / Netflix が数時間停止)は単独サーバーで受け切るのは不可能という現実を世界に突きつけました(詳細は付録「重大インシデント事例集」)。
IDS / IPS
侵入を検知・防止する仕組みです。IDS(Intrusion Detection System)は検知のみ、IPS(Intrusion Prevention System)は自動遮断まで行います。近年はAI/機械学習で既知パターンだけでなく異常行動も検知できるようになっています。
| 種類 | 内容 |
|---|---|
| NIDS / NIPS | ネットワーク型 |
| HIDS / HIPS | ホスト型(各サーバーに導入) |
| XDR(Extended Detection and Response、複数層横断の脅威検知) | 複数レイヤー統合(Endpoint + Network + Cloud) |
| SIEM(Security Information and Event Management、ログ統合監視) | ログ統合・相関分析 |
代表的な OSS は Snort・Suricata・Zeek で、商用は CrowdStrike・Palo Alto・SentinelOne 等が主要プレイヤーです。
VPN と プライベート接続
社外から社内へ安全に接続する仕組みです。リモートワークの普及で重要性が増しましたが、VPN自体が攻撃対象になる時代(2021年の Pulse Secure・Ivanti の脆弱性事件)で、ゼロトラストへの移行が進んでいます。
| 接続方式 | 内容 |
|---|---|
| IPsec VPN | 拠点間接続の伝統 |
| SSL/TLS VPN | ユーザー接続・OpenVPN等 |
| WireGuard | モダン・高速・シンプル |
| ZTNA(Zero Trust Network Access) | VPN代替・アプリ単位接続 |
| Direct Connect / ExpressRoute | クラウド専用線 |
WireGuard は従来の VPN より10倍高速で、新規構築なら第一候補です。ゼロトラスト環境では ZTNA(Cloudflare Access・Tailscale・Twingate等)が VPN を代替しつつあります。
CDN(Content Delivery Network)
静的コンテンツを世界中のエッジサーバーから配信する仕組みで、性能向上と同時にセキュリティ機能も提供します。DDoS吸収・WAF統合・ボット対策が標準で、現代ウェブサービスの必須インフラです。
| CDN | 特徴 |
|---|---|
| Cloudflare | 無料枠あり・最も普及 |
| AWS CloudFront | AWS統合 |
| Fastly | 開発者向け・柔軟 |
| Akamai | 老舗・エンタープライズ |
| Vercel / Netlify Edge | JAMstack(JavaScript + API + Markup、静的サイト + API構成)向け |
オリジンIPを隠せるのがCDNの重要なセキュリティ効果で、攻撃者がサーバーを直接狙えなくなります。
ネットワーク分割とマイクロセグメンテーション
大きなネットワークを小さなセグメントに分割し、セグメント間の通信を必要最小限に絞る設計です。侵害が発生しても横展開(Lateral Movement)を防ぐのが目的で、1つのサーバーが落ちても全社に被害が広がりません。
| レベル | 例 |
|---|---|
| VPC分離 | 本番/開発/検証で別VPC |
| サブネット分離 | Public/Private/Isolated |
| Security Group | インスタンス単位 |
| Service Mesh | マイクロサービス間 |
| mTLS | サービス間暗号認証 |
ゼロトラスト的には、全てのサービス間通信を暗号化・認証するのが目標です。Istio・Linkerd 等のサービスメッシュがこれを実現します。
判断基準
① システム規模
| 規模 | 推奨 |
|---|---|
| 小規模・SaaS中心 | Cloudflare + クラウドSG |
| 中規模・独自サーバー | VPC分離 + WAF + DDoS対策 |
| 大企業・マルチクラウド | ゼロトラスト + SIEM + XDR |
| 金融・政府 | 専用線 + HSM + 24/7 SOC |
② 脅威レベル
| 脅威レベル | 対策 |
|---|---|
| 低(内部利用のみ) | SG + VPN |
| 中(一般公開B2C) | CDN + WAF + DDoS対策 |
| 高(金融・医療) | 上記 + IPS + SIEM + 専門SOC |
| 最高(重要インフラ) | 全層 + 物理隔離 + 人的監視 |
ケース別の選び方
小規模な公開Webサービス(個人・スタートアップ)
Cloudflare無料枠 + クラウドSG + Private Subnet。CloudflareがDNS・CDN・WAF・DDoS対策を無料で提供するため、個人サイトでも商用級の防御を敷ける。AWS/GCPのセキュリティグループで最小限のポートだけ開ける。
B2Cサービス(EC・SNS)
Cloudflare or CloudFront + WAF + Shield + レート制限。ボット攻撃・クレデンシャルスタッフィングが日常的に来るため、WAFルールとBot対策(CAPTCHA・チャレンジ)を組み合わせる。Private/Publicサブネットで DBを完全隔離。
B2B SaaS・業務システム
ZTNA(Cloudflare Access・Tailscale)+ WAF + SIEM。従来のVPNより細かくアプリ単位で認可できるため、リモートワーク時代に適する。SSOと統合しアクセスログをSIEMに集約。
金融・医療・政府系
専用線(Direct Connect / ExpressRoute)+ IPS + 24/7 SOC + マイクロセグメンテーション。横展開を完全に抑えるため、サービスメッシュ(Istio)で全通信mTLS化。監査対応のために全パケットログを保存する。
規模×脅威別の実務段階表
※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。
ネットワーク防御は「全部入り」ではなく、規模と脅威レベルに合わせた段階的導入が現実解です。
| 規模・脅威 | 最低限の構成 | 月額目安 | 実装の目安 |
|---|---|---|---|
| 個人・公開サイト | Cloudflare無料枠 + Private Subnet | 0円 | 1時間 |
| 小規模SaaS | CloudFront + WAF + Security Group | 数万円 | 1週間 |
| 中規模B2C | CloudFront + WAF + Shield Standard + Rate Limit | 数十万円 | 2週間 |
| 大規模B2B | ZTNA + CDN + IPS + SIEM | 数百万円 | 数ヶ月 |
| 金融・医療 | 上記 + 専用線 + 24/7 SOC + UEBA | 数千万円〜 | 1年〜 |
「DDoS対策の実質下限はCDN経由配信」オリジン直公開は1.2Tbps級の攻撃(2016年 Mirai / Dyn 事件)を受けたら即終了です。Cloudflareの無料枠だけでもDDoS吸収・WAF・ボット対策が入り、最低限の防御すらない状態から一気に解放されます。
公開IPはBotに24時間365日スキャンされている。CDN前置は最低ラインの防御です。
ネットワーク運用の鬼門・禁じ手
ネットワークセキュリティで事故る典型を整理します。どれも侵害時の被害範囲を最大化します。
| 禁じ手 | なぜダメか |
|---|---|
| DB / Redis / ElasticsearchをPublic Subnetに配置 | 2017年のMongoDB / Redisランサム事件と同じ地雷。Isolated必須 |
Security Groupに 0.0.0.0/0:22(SSH全開放) | 数時間でSSHブルートフォース数千件 + マイナー仕込み試行 |
| 本番と開発を同一VPCで運用 | 開発ミスが本番に波及。VPC単位で分離 |
| VPNを最終防衛線として全信頼 | 2021年Pulse Secure事件でVPN自体が侵入口に。ZTNAへ移行 |
| CDNなしでオリジン直公開 | 2016年Dyn DDoS(1.2Tbps)を受けたら終わり。Cloudflare無料で十分 |
| WAFを入れただけで満足 | SQLインジェクション対策をアプリ側でサボるのは論外 |
| 社内通信を平文のまま運用 | 横展開攻撃で全てが見える。mTLSで全通信暗号化 |
| ファイアウォールルールをGUIで手作業管理 | 変更履歴が残らず、監査対応不能。Terraformでコード化 |
| Egress制御なしでAIエージェント運用 | AIが外部APIに情報漏洩、データ持ち出しリスク |
| 不要なポート・サービスを残したまま | 攻撃面が広がる。最小限のIngressルールに |
| CDN障害時のフォールバック未設計 | 2021年Fastly・2019年Cloudflare障害で単一CDNがSPOFに |
2016年10月のDyn DNS攻撃(IoT踏み台のMiraiボットネットで1.2Tbps DDoS、Twitter / GitHub / Netflix / Spotify が数時間停止)、2021年Pulse Secure VPN脆弱性(VPN自体が攻撃の入り口、米政府機関侵害)——境界防御だけでは守れない現実が繰り返し示されています。
境界型の神話は2015年で終わっている。CDN + ZTNA + Egress制御が現代の三本柱です。
AI時代の視点
AI駆動開発(バイブコーディング)とAI活用が前提になると、ネットワークセキュリティはAIエージェントの通信を制御する境界として新しい意味を持ちます。AIエージェントが外部APIを自律的に叩く時代には、「どこへ通信してよいか」を厳密に制御する必要があります。
| AI時代に有利 | AI時代に不利 |
|---|---|
| Egress制御(外向き通信制限) | 外向き自由 |
| ゼロトラスト・マイクロセグメント | 平坦な社内LAN |
| クラウドネイティブWAF | オンプレの重厚装置 |
| 監査ログの集約(SIEM) | サイロ化されたログ |
AIが勝手に外部APIを呼んで情報を漏らすリスクがあるため、Egress Firewall(外向き通信の制御)が重要性を増しています。許可リスト方式で、AIが到達できる外部サービスを絞るのが安全です。
AI時代のネットワーク設計はEgress制御が鍵。AIの行き先を絞ります。
筆者メモ — 「大規模攻撃は届かない」と油断して沈んだ事例
DDoS や VPN 脆弱性で社会インフラ級のシステムが落ちた事例が、近年の定番の語り草になっています。
Dyn DNS 2016年事件(IoT踏み台のMiraiで1.2Tbps DDoS、Twitter / GitHub / Netflix が数時間停止)はCDN・DDoS対策サービスへの委譲が鉄板の定石となるきっかけになりました(詳細は付録「重大インシデント事例集」)。
もう一つ、2021年4月に発覚したPulse Secure VPNの脆弱性(CVE-2021-22893)では、VPN自体が攻撃の入り口となって、米政府機関や大手防衛産業まで侵害を受けました。「VPNがあれば安全」という前提が崩れ、ZTNA(Zero Trust Network Access)への移行を一気に加速させた事件として語り草になっています。
筆者自身、検証用EC2のSecurity Groupを 0.0.0.0/0 のまま数時間放置した翌朝、認証ログに数千件のSSHブルートフォースとBitcoinマイナー混入試行のログが並んでいた、という経験があります。どちらも「境界さえあれば安全」という前提が致命傷で、多層防御とゼロトラストへの移行を決定づけた事例です。
公開IPは開けた時点で攻撃が来ると思って構えます。検証用も本番並みに。
よくある勘違い
- 社内LANだから暗号化不要 → 現代はゼロトラスト。内部でもmTLSが標準。内部侵害の方が被害が大きい
- DBにパブリックIPを付けて繋ぎたい → 絶対禁止です。検証用EC2のSecurity Groupを
0.0.0.0/0のまま数時間放置した翌朝、認証ログに数千件のSSHブルートフォースとBitcoinマイナー混入試行のログが並んでいた、という事例は現場で後を絶ちません - VPNがあれば安全 → VPN自体が攻撃対象。VPN突破 → 社内全アクセスの事故が多発。ZTNAへ移行を検討
- WAFを入れたらSQLインジェクション対策は不要 → WAFは「保険」であり本質的対策ではない。アプリ側でパラメータ化クエリを書くのが根本対策
決めるべきこと — あなたのプロジェクトでの答えは?
以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- ネットワーク分離(VPC・サブネット設計)
- ファイアウォールルール(Security Group・NSG)
- WAFの採用(Cloudflare・AWS WAF等)
- DDoS対策(CDN・Shield等)
- リモート接続方式(VPN / ZTNA)
- IDS/IPS・SIEMの採用(規模次第)
- Egress制御(外向き通信の許可リスト)
最終的な判断の仕方
ネットワークセキュリティの核心は攻撃の入り口を減らし、破られても被害を広げないという多層防御の発想です。社内LANだから安全という境界型の思想は2015年で終わり、リモートワークとクラウド前提の現代ではゼロトラストへの移行が既定路線になっています。DBをPublicサブネットに置かない・VPCで分離する・CDN + WAFで攻撃面を減らす・内部通信もmTLSで暗号化する、という基本を積み上げるのが合理的な判断です。
もう一つの決定的な軸はEgress制御(外向き通信の制限)です。AIエージェントが外部APIを自律的に叩く時代、内向きだけでなく「AIの行き先」を絞らないと情報漏洩リスクが跳ね上がります。許可リスト方式でAIが到達できる外部サービスを絞り、ZTNAでアプリ単位の認可を敷くのが、AI時代のネットワーク設計の新常識です。
選定の優先順位
- ゼロトラストを出発点に — 社内LANも信用しない、全通信で認証・暗号化
- CDN + WAF + DDoS対策 — Cloudflare / CloudFrontで攻撃面を減らし、オリジンIPを隠す
- VPC + Privateサブネット — DBは必ず隔離、Public直接配置を禁止
- Egress制御でAIの行き先を絞る — 許可リストで外部API接続を限定
「境界防御からゼロトラストへ、AI時代はEgress制御が鍵」内と外の両方向で攻撃面を減らします。
まとめ
本記事はネットワークセキュリティについて、ファイアウォール・VPC・WAF・DDoS対策・IDS/IPS・VPN/ZTNA・CDNなどの主要要素・規模×脅威別の段階表・AI時代のEgress制御まで含めて解説しました。如何だったでしょうか。
ゼロトラストを出発点に、CDN+WAF+DDoS対策で攻撃面を減らし、DBはPrivate隔離、Egress制御でAIの行き先を絞る。これが2026年のネットワークセキュリティの現実解です。
次回はゼロトラスト(BeyondCorp・ZTNA・継続検証)について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ:生成AI時代のアーキテクチャ超入門(50/89)