SGとNACLの設計

このレッスンを終えると、通信要件の文を読んで、セキュリティグループで書くべきか、ネットワーク ACL で書くべきか、両方が要るのかを判断できるようになります。

まず要件から

ある企業が、ALB の後ろに Web サーバー、その後ろに RDS という3層構成を組んでいます。運用中に、特定の IP アドレス帯から不正なアクセスが続いたため「このサブネット全体で、その IP 帯を丸ごと落としたい」という要望が出ました。担当者はセキュリティグループに拒否ルールを書こうとしています。

これは書けません。セキュリティグループには許可ルールしか書けず、拒否ルールは存在しません。特定の相手を落としたいなら、ネットワーク ACL の Deny ルールを使います。この一点だけで正解が決まる問題が本番でも出ます。

2つの違い

実務でも試験でも、通常の許可設計はセキュリティグループで行い、ネットワーク ACL は既定のまま触らないのが基本形です。ネットワーク ACL を持ち出すのは、特定の相手を明示的に落とす要件が書かれているときだけと覚えます。

ステートレスの落とし穴

ネットワーク ACL でインバウンドの 443 だけを許可し、アウトバウンドを絞ると通信が壊れます。戻りのパケットは、クライアント側が使った一時的なポート番号あてに返るためです。ネットワーク ACL でアウトバウンドを制限するなら、この一時ポートの範囲を許可しなければなりません。セキュリティグループはステートフルなので、この考慮は要りません。

試験では「443 のインバウンドを許可したのに応答が返らない」という症状で問われます。症状を見たらネットワーク ACL のアウトバウンドを疑います。

3層をセキュリティグループで書く

多層防御の型は、IP ではなくセキュリティグループ ID を参照して連ねることです。

この書き方なら、Auto Scaling でインスタンスが入れ替わって IP が変わってもルールを直す必要がありません。要件文に「インスタンスが動的に増減する」「IP が固定されない」とあれば、この参照方式が正解です。CIDR で書く選択肢は、動きはしますが増減のたびに保守が要るので負けます。

要件語から構成へ

最後の2行は層が違います。SQL インジェクションのようなリクエストの中身に基づく防御は、セキュリティグループでもネットワーク ACL でもできません。要件文に攻撃の種類が書かれていたら WAF を選びます。

よくある引っ掛け

ひとつめは、セキュリティグループで拒否ルールを書く選択肢です。存在しないので即座に落とせます。

ふたつめは、ネットワーク ACL の評価順です。番号 100 で許可し、番号 200 で同じ相手を拒否しても、先に一致した許可で確定します。落としたいなら小さい番号に置きます。

まとめ

• セキュリティグループは ENI 単位、ステートフル、許可のみ
• ネットワーク ACL はサブネット単位、ステートレス、拒否も書ける
• 明示的に遮断したい要件が出たときだけネットワーク ACL を持ち出す
• 多層防御はセキュリティグループ ID を参照して連ねる
• リクエストの中身に基づく防御は WAF の担当