SAA / SAP 攻略ナビ
ホーム セキュリティ監視・コンプライアンス

ネットワークセキュリティ — SG / NACL / WAF / Shield

セキュリティグループ、NACL、AWS WAF、Shield、Firewall Manager を組み合わせた多層ネットワークセキュリティ設計を SAA 基礎から SAP 高度設計まで解説。

最終更新: 2026-07-27 カテゴリ: セキュリティ監視・コンプライアンス

AWS のネットワークセキュリティは 複数レイヤの防御 (Defense in Depth) で設計します。 セキュリティグループ (SG)、NACL、AWS WAF、Shield が各レイヤを担当します。 本記事では多層防御のネットワークセキュリティ設計を SAA / SAP 両面から整理します。

SAA レベル：基礎概念

セキュリティグループ (SG) と NACL の違い

SG と NACL は VPC の基本的なファイアウォールですが、性質が異なります。

項目セキュリティグループ (SG)NACL (Network ACL)
適用単位ENI（EC2 等）サブネット
ステートフルはい（戻り通信自動許可）いいえ（戻り通信もルール必要）
ルール評価全ルールを評価（Allow の AND）番号順に評価（最初の Match で決定）
拒否ルール不可（Allow のみ）可（Allow と Deny）
デフォルト全通信拒否全通信許可

SAA レベル：基礎概念

SG と NACL の最大の違いは 「ステートフルかステートレスか」 です。

  • SG（ステートフル）: 外向き通信の戻りは自動許可。ルールは Allow のみ。
  • NACL（ステートレス）: 戻り通信もルールで明示。Allow と Deny が可能。 この違いが SAA の超頻出です。

セキュリティグループの設計原則

SG は インスタンス単位 のファイアウォールで、最も細かい制御が可能です。

  • Allow のみ: Deny ルールは書けない（デフォルト全拒否）
  • ステートフル: 外向き許可の戻りは自動許可
  • 参照設定: 別 SG / リソースをソースに指定可能（動的）
  • 全ルール評価: 番号順ではなく、全 Allow ルールの AND

SAA 試験のポイント

SG は 「別の SG をソースに指定」 できます。 例えば「Web SG をソースに許可」すると、Web SG を持つインスタンスからの通信だけ許可。 IP 変更時のメンテが不要なため、SAA で推奨設計として頻出します。

# 推奨される SG 参照設計
ALB-SG:  0.0.0.0/0 (80, 443) を許可
Web-SG:  ALB-SG をソースに許可 (8080)
DB-SG:   Web-SG をソースに許可 (3306)

NACL の設計原則

NACL は サブネット単位 のファイアウォールで、境界防御に使います。

  • Allow と Deny: 両方のルールを書ける
  • ステートレス: 戻り通信のルールも明示必要
  • 番号順評価: 番号が小さい順に評価、最初の Match で決定
  • デフォルト全許可: 明示的な Deny を入れないと全通過

SAA 頻出

NACL は ステートレス なので、「外向き通信を許可しても戻りは自動許可されない」です。 エフェメラルポート (1024-65535) の戻り通信を許可するルールが必要。 これを忘れると「アウトバウンド通信できるはずなのにできない」現象に。SAA の定番ひっかけです。

AWS WAF の基本

AWS WAF は L7 (アプリケーション層) のファイアウォール です。

  • 対象: CloudFront, ALB, API Gateway, AppSync, Cognito
  • ルール: SQL Injection, XSS, IP 制限, Geo 制限, レートベース制限
  • Web ACL: ルールの集合体をリソースに適用
  • マネージドルール: AWS / マーケットプレイス提供のルールセット

WAF の適用対象

WAF は CloudFront, ALB, API Gateway, AppSync, Cognito に適用可能です。 NLB には適用できない 点に注意（NLB は L4）。SAA で「WAF を ALB に適用」が頻出。

AWS Shield と Firewall Manager

サービス役割説明
Shield StandardDDoS 防御全 AWS ユーザーに自動適用・無料
Shield AdvancedDDoS 防御（高度）有料、CloudFront/Route53/ALB/NLB/Global Accelerator 保護
Firewall Managerマルチアカウント WAF 管理Organizations 配下の WAF/SG/Shield を一元管理

SAA レベル：基礎概念

Shield Standard は全 AWS ユーザーに無料で自動適用 されます。 これだけでよくある L3/L4 DDoS 攻撃は緩和されます。 Shield Advanced は有料 で、より高度な保護と DDoS 対応チーム (SRT) の支援、 保護対象リソースの WAF 料金割引等の追加メリットがあります。

SAP レベル：高度な設計シナリオ

多層防御 (Defense in Depth) アーキテクチャ

SAP では 複数レイヤの防御 を設計します。

SAP レベル：高度な設計シナリオ

SAP のネットワークセキュリティ定石は 「複数レイヤの防御 (Defense in Depth)」 です。 インターネット境界 (CloudFront + WAF + Shield) → VPC 境界 (NACL) → インスタンス境界 (SG) → アプリ境界 (アプリ内認証) の多層構造で、 1 レイヤ突破しても次で止める設計にします。

[インターネット]
  │
  ▼
[CloudFront + WAF + Shield Advanced]  ← L7/L3/L4 DDoS 防御
  │
  ▼
[VPC NACL]  ← サブネット境界
  │
  ▼
[ALB + WAF]  ← L7 ロードバランサ
  │
  ▼
[EC2 SG]  ← インスタンス境界
  │
  ▼
[アプリ認証]  ← アプリ層

WAF ルールの設計

WAF は複数のルールタイプを組み合わせて設計します。

ルールタイプ説明設計論点
マネージドルールAWS / ベンダ提供OWASP Top 10 防御
IP セットIP ベース許可/拒否ブラックリスト管理
Geo 制限国単位の制限データ主権対応
レートベースルール5 分間のリクエスト数閾値DDoS / ブルートフォース防御
カスタムルール条件組み合わせ組織固有要件

レートベースルールの活用

WAF の レートベースルール は「同一 IP から 5 分間で N 回以上リクエストがあれば遮断」。 ブルートフォース攻撃や DDoS の軽減に有効。SAP では閾値のチューニングが運用論点です。

SG の相互参照設計

SAP では SG の相互参照を活用した最小権限設計 が推奨されます。

# マイクロサービスアーキテクチャの例
Frontend-ALB-SG:  0.0.0.0/0 (443) を許可
  ↓ (Frontend-ALB-SG をソースに参照)
Frontend-App-SG:  Frontend-ALB-SG をソースに (8080)
  ↓ (Frontend-App-SG をソースに参照)
Backend-ALB-SG:   Frontend-App-SG をソースに (443)
  ↓
Backend-App-SG:   Backend-ALB-SG をソースに (8080)
  ↓
DB-SG:           Backend-App-SG をソースに (3306)

相互参照の利点

SG の相互参照を使うと IP アドレス変更のメンテが不要 になります。 オートスケールでインスタンス IP が変わっても、SG ベースの参照なら自動追従。 SAP ではこの 動的参照 を基本設計にします。

Firewall Manager によるマルチアカウント管理

AWS Firewall Manager は Organizations 配下の全アカウントの WAF / SG / Shield を一元管理します。

  • 一元設定: 管理アカウントから全アカウントに WAF ルールを適用
  • 新規アカウント自動適用: 組織に追加されたアカウントに自動適用
  • コンプライアンス監視: ルール非準拠リソースを検知

Firewall Manager の設計論点

Firewall Manager は 「全アカウントで統一 WAF/SG ポリシー」 を実現しますが、 個別アカウントでのルール変更は Firewall Manager で上書き される点に注意。 「部門ごとの個別調整」が必要な場合は タグベースの適用範囲 で制御します。SAP の論点です。

Shield Advanced の詳細設計

Shield Advanced は有料ですが、以下の高度な保護を提供します。

機能説明
DDoS Response Team (SRT)24/7 で AWS の専門チームが支援
保護対象CloudFront, Route 53, ALB, NLB, Global Accelerator, Elastic IP
WAF 料金割引保護リソースの WAF 利用料金が割引
自動応用任意の攻撃に対する自動緩和ルール適用
Visibility攻撃の可視化と CloudWatch 連携

Shield Advanced の適用判断

Shield Advanced は 「公共面向アプリで DDoS リスクが高い」 場合に投資判断します。 「EC2 単体への攻撃」も Elastic IP 保護で対応可能。SAP では費用対効果で Standard vs Advanced を判断します。

VPC セキュリティのベストプラクティス

SAP での VPC セキュリティ設計の定石：

設計要素推奨理由
パブリックサブネットALB / NAT Gateway のみ直接インターネット公開を避ける
プライベートサブネットアプリ / DBインターネット直接不可
NACL境界 Deny 追加既知の悪意 IP の遮断
VPC Flow Logs全通信記録通信監査と異常検知
VPC エンドポイントAWS サービスへのプライベートアクセスインターネット経由回避

パブリックサブネットの最小化

パブリックサブネットに置くリソースは ALB と NAT Gateway のみ が原則です。 EC2 をパブリックサブネットに直接置くと、攻撃面が拡大します。 「アプリは必ずプライベートサブネット」が SAP の基本姿勢です。

インターネット向けアーキテクチャの防御

[インターネット]
  │
  ▼ (Shield Standard/Advanced で L3/L4 DDoS 緩和)
[CloudFront] ── WAF (OWASP Top 10, Geo 制限, レート制限)
  │
  ▼ (CloudFront からのみアクセス許可)
[ALB] ── WAF (追加ルール)
  │
  ▼ (ALB の SG をソースに参照)
[EC2 (プライベートサブネット)] ── SG (最小権限)
  │
  ▼
[RDS (プライベートサブネット)] ── SG (EC2 の SG を参照)

SAP レベル：高度な設計シナリオ

SAP のインターネット面向アプリの完成形は 「CloudFront + WAF + Shield → ALB + WAF → プライベートサブネットの EC2/RDS」 の多層構造です。 各レイヤで異なる防御を提供し、CloudFront の SG で CloudFront からのみ ALB へアクセス許可 とすることで、ALB を直接叩く攻撃も遮断できます。この設計が SAP の核心です。

Network Firewall による VPC 境界防御

AWS Network Firewall は VPC の境界で L3〜L7 の通信を検査します。

  • ステートフル検査: 通信状態を追跡
  • Suricata 互換ルール: 既存ルールの再利用可
  • VPC 内配置: VPC サブネットに ENI として配置
  • マネージドルール: AWS 提供のドメインリスト等

Network Firewall の位置づけ

Network Firewall は 「VPC の境界検査」 に特化し、WAF（L7 アプリ向け）とは補完関係です。 「VPC からインターネットへの通信を検査」「サードパーティ製ファイアウォールルールを再利用」 等の要件で SAP では Network Firewall の活用が問われます。

制約と考慮事項

項目制約
SG ルール数1 SG あたり 60（クォータ拡張可）
NACL ルール数1 NACL あたり 20（拡張可）
WAF 適用対象CloudFront / ALB / API Gateway / AppSync / Cognito
Shield Standard無料・自動適用
Firewall ManagerOrganizations 連携必須

まとめ

  • SAA: SG（ステートフル・Allow のみ）と NACL（ステートレス・Allow/Deny）の違い、 WAF は L7、Shield Standard は無料自動、を理解する。
  • SAP: 多層防御アーキテクチャ、SG 相互参照、Firewall Manager によるマルチアカウント管理、 Shield Advanced の費用対効果判断が求められる。

次は マルチAZ・マルチリージョンアーキテクチャ で、高可用性設計に入ります。

スポンサーリンク（広告枠） 728×90

関連記事