セクション 02 · タスク 1.2 · SAP-C02-016
ネットワークセキュリティコントロールの設計
ルートテーブル / セキュリティグループ / ネットワークACL / ステートフル / ステートレス / AWS Network Firewall / AWS Firewall Manager / 多層防御
このページのゴール
通信要件から、ルートテーブル・セキュリティグループ・ネットワークACL・AWS Network Firewall・AWS Firewall Managerの責任を分け、ステートフル / ステートレスを踏まえた多層防御を設計できることをゴールにします。
1. ネットワークセキュリティは1つの制御だけでは完成しない
VPC内の通信を保護するとき、セキュリティグループを設定しただけでネットワークセキュリティが完成するわけではありません。
どの経路を通る?
↓
ルートテーブル
リソースへ何を許可?
↓
セキュリティグループ
サブネット境界で何を許可 / 拒否?
↓
ネットワークACL
通信内容を詳しく検査?
↓
AWS Network Firewall
多数アカウントへ同じポリシーを展開?
↓
AWS Firewall Manager重要なのは、同じ機能を何重にも置くことではなく、異なる責任を持つ制御を組み合わせることです。
2. ルートテーブルは「どこを通るか」を決める
ルートテーブルは、この宛先へのトラフィックをどのターゲットへ送るかを決めます。
宛先
10.20.0.0/16
│
▼
Transit Gateway
0.0.0.0/0
│
▼
NAT ゲートウェイしたがって、ルートテーブルの主責任は経路選択です。
3. ルートテーブルはファイアウォール ルールではない
0.0.0.0/0 → インターネットゲートウェイというルートがあることは、インターネットから全通信を許可するという意味ではありません。
逆にセキュリティグループでTCP 443を許可していても、宛先まで到達するルートがなければ通信は成立しません。
ルート
→ 経路を成立させる
セキュリティ制御
→ その経路上のトラフィックを許可 / 拒否するAWS Network Firewallのような検査ポイントを利用する場合は、トラフィックをファイアウォールエンドポイントへ通すこと自体をルートテーブルで設計します。つまり、ルートテーブルもセキュリティアーキテクチャを成立させる重要な要素です。
4. セキュリティグループはリソースに近いアクセス制御
セキュリティグループは、関連付けたリソースのインバウンド / アウトバウンドトラフィックを制御します。
インターネット
│
│ TCP 443
▼
ALB セキュリティグループ
│
▼
アプリケーションセキュリティグループリソース単位で必要な通信だけを許可したい場合、セキュリティグループを基本制御として考えます。
5. セキュリティグループは許可ルールだけを持つ
セキュリティグループでは許可を定義し、明示的な拒否ルールは持ちません。
TCP 443
送信元:
Application Load Balancer SGだけを許可すれば、それ以外のインバウンドトラフィックは許可されません。
6. セキュリティグループはステートフル
セキュリティグループの重要な特徴がステートフルであることです。
クライアント
│
│ リクエスト
▼
サーバー
サーバー
│
│ 応答
▼
クライアントリクエストがセキュリティグループルールで許可されて接続が成立した場合、その応答トラフィックは接続状態に基づいて処理されます。
したがって、許可した通信の応答用に反対方向のルールを必ず追加する、という設計にはなりません。
7. リソース同士の関係をセキュリティグループで表現する
対応する構成では、CIDRだけでなくセキュリティグループをルールの送信元 / 宛先として参照できます。
ALB SG
│
│ TCP 8080
▼
アプリケーション SG10.0.1.0/24のようなIP範囲ではなく、ALBとして許可されたリソースからの通信という意図に近いアクセス制御を表現できます。
8. ネットワークACLはサブネット境界の制御
ネットワークACLはサブネットに関連付け、そのサブネットへ入るトラフィックとサブネットから出るトラフィックを制御します。
VPC
│
├─ パブリックサブネット
│ └─ ネットワークACL A
│
└─ プライベートサブネット
└─ ネットワークACL Bリソースに近い制御をセキュリティグループで行い、サブネット境界に追加の粗いガードレールが必要ならネットワークACLを評価します。
9. ネットワークACLは許可と拒否を持つ
セキュリティグループと異なり、ネットワークACLには許可と拒否の両方があります。
特定の既知の悪意あるCIDR
↓
サブネット全体で拒否という要件ならネットワークACLを評価できます。
リソースごとに必要トラフィックを許可
→ セキュリティグループ
サブネット境界で特定トラフィックを明示拒否
→ ネットワークACL10. ネットワークACLはステートレス
ネットワークACLはステートレスです。
インバウンド
クライアント → サーバー
TCP 443
アウトバウンド
サーバー → クライアント
対応インバウンドとアウトバウンドをそれぞれ評価するため、応答トラフィックもネットワークACLルールで許可する必要があります。クライアントが動的ポートを使用する場合は、戻りトラフィックのエフェメラルポートも考慮します。
11. ネットワークACLは番号の小さいルールから評価する
ネットワークACLではルール番号の小さいものから評価し、最初に一致したルールを適用します。
100 DENY 203.0.113.0/24
200 ALLOW 0.0.0.0/0なら対象CIDRはルール 100で拒否されます。
100 ALLOW 0.0.0.0/0
200 DENY 203.0.113.0/24ではルール 100で先に一致するため、後続の拒否まで評価されません。
12. セキュリティグループとネットワークACLを比較する
| 判断 | セキュリティグループ | ネットワークACL |
|---|---|---|
| 主な適用範囲 | リソース | サブネット |
| 許可 | ○ | ○ |
| 明示的な拒否 | × | ○ |
| ステートフル | ○ | × |
| 戻りトラフィック | 接続状態で処理 | 明示的なルールが必要 |
| ルール評価 | 適用されるルール全体 | ルール番号順で最初に一致 |
| 主用途 | リソースアクセス制御 | サブネットガードレール / 追加防御 |
13. 高度なトラフィック検査にはAWS Network Firewall
セキュリティグループやネットワークACLより高度なネットワーク検査が必要な場合はAWS Network Firewallを評価します。
代表的な要件には、ドメインベースの フィルタリング、侵入防止、ディープパケット検査、ネットワーク全体のトラフィック検査などがあります。
14. AWS Network Firewallにはステートレスとステートフルの両方がある
セキュリティグループ
→ ステートフル
ネットワークACL
→ ステートレス
AWS Network Firewall
→ ステートレス + ステートフルAWS Network Firewallではステートレスルールエンジンがパケットを個別に評価し、アクションに応じて通過(Pass) / 破棄 / ステートフルエンジンへの転送などを行えます。
パケット
│
▼
ステートレスエンジン
│
├─ 通過(Pass)
├─ 破棄
└─ ステートフルへ転送
│
▼
ステートフルエンジンステートフルエンジンはトラフィックフローのコンテキストを追跡して評価します。したがって、AWS Network Firewallを単純に「ステートフルファイアウォールだけ」と理解しません。
15. ファイアウォールを作っただけではトラフィックは検査されない
AWS Network Firewallを作成するとファイアウォールエンドポイントが用意されますが、VPC トラフィックが自動ですべてそこを通るわけではありません。
検査対象トラフィック
↓
ルートテーブル
↓
ファイアウォールエンドポイントというトラフィック誘導が必要です。
検査ルール
+
トラフィック誘導の両方がそろって、AWS Network Firewallによる検査経路が成立します。
16. ステートフル検査では対称ルーティングが重要
ステートフル検査では、関連するリクエストと応答を同じファイアウォール経路へ通すように設計します。
転送
ワークロード
↓
ファイアウォールエンドポイント A
↓
宛先
戻り
宛先
↓
ファイアウォールエンドポイント A
↓
ワークロード転送と戻りが異なるファイアウォールエンドポイントへ分かれる非対称ルーティングでは、ステートフルフローの追跡が成立しません。
集中検査でTransit Gatewayを利用する場合も、往復トラフィックが同じ検査経路を維持できるようルートやアプライアンスモードを検討します。
17. AWS Firewall Managerはファイアウォール本体ではない
AWS Firewall Managerは、各パケットを直接検査するファイアウォールエンジンではありません。
役割は、複数AWSアカウント / リソースへセキュリティポリシーを中央適用・監査することです。
AWS Organizationsを利用するエンタープライズ環境では、セキュリティグループポリシーなどを組織全体または対象アカウント / リソースへ適用し、非準拠を継続的に検出・管理できます。
18. Firewall Managerで中央管理できるネットワーク制御
| 中央管理したい対象 | Firewall Manager ポリシー |
|---|---|
| セキュリティグループ | セキュリティグループポリシー |
| ネットワークACL | ネットワークACL ポリシー |
| AWS Network Firewall | AWS Network Firewall ポリシー |
AWS Network Firewall
→ トラフィックを検査
AWS Firewall Manager
→ ファイアウォール / ネットワークポリシーを
組織へ展開・統制と責任を分けます。
19. 多層セキュリティは責任の違う制御を重ねる
インターネット向けアプリケーションを例にすると、概念的には次のように役割を分けられます。
インターネット
│
▼
ルートテーブル
→ 検査経路
│
▼
AWS Network Firewall
→ ネットワーク全体 検査
│
▼
ネットワークACL
→ サブネットガードレール
│
▼
セキュリティグループ
→ リソース アクセス 制御
│
▼
アプリケーション重要なのは、全部の制御へ同じTCP 443 ルールを書くことではありません。
ルートテーブル
→ 経路
AWS Network Firewall
→ 検査
ネットワークACL
→ サブネット 境界
セキュリティグループ
→ リソース権限
Firewall Manager
→ 組織全体のガバナンスという異なる責任を持たせることが多層セキュリティです。
20. 要件から制御を選ぶ
| 要件 | 基本判断 |
|---|---|
| アプリケーションサーバーへALBからTCP 443だけ許可 | セキュリティグループ |
| 特定CIDRをサブネット全体で明示拒否 | ネットワークACL |
| 戻りトラフィックを接続状態で追跡 | ステートフル制御 |
| インバウンド / アウトバウンドを個別ルールで管理 | ステートレス制御 |
| ドメイン / プロトコル / フローを詳しく検査 | AWS Network Firewall |
| AWS Network Firewallへ必ず通したい | ルートテーブルで経路を設計 |
| 多数アカウントのSGを中央監査・統制 | AWS Firewall Manager |
| 組織内VPCへAWS Network Firewallを展開 | Firewall Manager AWS Network Firewall ポリシー |
| 複数制御で異なる責任を持たせる | 多層セキュリティ |
21. 混同ポイント
- ルートがある = トラフィックが許可される:ルートは経路を決めます。
- セキュリティグループ = ステートレス:セキュリティグループはステートフルです。
- ネットワークACL = セキュリティグループのサブネット版だけ:ネットワークACLは許可 / 拒否を持ち、ステートレスでルール順序もあります。
- ステートフル = セキュリティグループだけ:AWS Network Firewallにもステートフルエンジンがあります。
- AWS Network Firewallを作る = トラフィックが自動で検査される:ルートテーブルでファイアウォールエンドポイントへトラフィックを送る必要があります。
- Firewall Manager = ファイアウォールエンジン:Firewall Managerは組織横断のポリシー管理を担います。
- 多層セキュリティ = 同じルールを全部へコピー:制御ごとに異なる責任を持たせます。
22. SAP-C02判断フロー
ネットワークトラフィックを制御したい
│
▼
どの経路を通す?
│
▼
ルートテーブル
│
▼
リソース単位で許可?
│
はい
▼
セキュリティグループ
│
▼
サブネット単位の拒否 / ガードレールも必要?
│
はい
▼
ネットワークACL
│
▼
高度なトラフィック検査が必要?
│
はい
▼
AWS Network Firewall
│
▼
ファイアウォールエンドポイントへ
往復トラフィックをルーティング
│
▼
多数アカウントへ中央展開・監査?
│
はい
▼
AWS Firewall Manager23. まとめ
ルートテーブル
→ トラフィック経路
セキュリティグループ
→ リソースレベル
→ 許可 のみ
→ ステートフル
ネットワークACL
→ サブネットレベル
→ 許可 / 拒否
→ ステートレス
→ ルール番号順
AWS Network Firewall
→ 高度な検査
→ ステートレス + ステートフルエンジン
→ ルートでエンドポイントへトラフィックを誘導
→ 転送 / 戻りの対称性が重要
AWS Firewall Manager
→ 組織全体のポリシー管理
多層セキュリティ
→ 各制御へ異なる責任を持たせる最重要ポイントは、どのセキュリティサービスが一番強いかではなく、経路・リソース・サブネット・検査・組織ガバナンスのどの責任を満たす必要があるかで制御を選ぶことです。
24. 主要AWS公式資料
理解確認
このページの内容を14問で確認します。
理解確認14問へ →