Security GroupとNetwork ACLのシナリオ判断

通信失敗を「ファイアウォールが原因」と一括りにせず、要求と返信、SGとNACL、経路とアプリへ分解します。条件が示された事例で、許可がどこに不足しているかを判断します。

この単元で学ぶこと

1. 調査の表を作る障害時は送信元IP・宛先IP、プロトコル、送信元と宛先のポート、開始方向を書き出します。「HTTPSが失敗」だけでは要求が届かないのか返信が戻らないのか分かりません。例えばクライアント55000番からWebの443番へ送信したという一組を基準に調べます。

2. 許可の重なりを読む一つのEC2に付くSG Aが社内から22番を許可し、Bが全IPv4から22番を許可していれば、Aを狭くしてもBの広い許可が残ります。最小権限化では個別の画面だけでなく、関連付く全グループの同じ通信に対する許可を確認します。

3. NACLの順序をたどる 100番で特定IPをAllowし、200番で広い範囲をDenyすると、その特定IPは先のAllowで決まります。Denyという語が付いているだけで番号に関係なく優先されるわけではありません。意図した例外と包括的なルールの順序を図にすると判定しやすくなります。

4. 返信先を入れ替える Webへの要求がサーバー443番へ届いても、NACL送信で宛先443番だけ許可していると、クライアント55000番への返信には一致しません。SGの状態追跡とNACLを混ぜず、復路の送信元・宛先を入れ替えた表で確認します。この55000番は事例で実際に使った番号です。

5. 境界ごとに確認する別サブネットのサーバーへ送る場合、送信側と受信側の経路・境界ルール・SGを確認します。片側のNACLだけを見て両方向が許可済みと判断しません。同じサブネットのEC2同士ならNACLの境界ではなく、SGやOS、アプリの待受け等へ着目します。

6. 変更を絞る管理元IPが一つに限定されているなら、そのIPから必要な管理ポートだけを許可する方法を検討します。通信を通すために全IPv4・全ポートへ広げると、当初の管理条件を失います。変更後は期待する通信の成功だけでなく、不要な通信が許可されていないことも確かめます。

7. 許可とサービス稼働を分けるルートとフィルターが整っていてもアプリが443番で待ち受けていなければ、要求は成功しません。逆にアプリへ到達して403等の認可エラーが返っているなら、ネットワークの全面開放より認証情報とアプリの権限を確認する方が直接的です。

8. 修正を記録して再確認どの接続がどのルールで許可されるか、番号と適用先を記録します。NACLを別のものへ関連付け直す場合は、追加で重ねるのではなく関連付けが変わることを意識します。AWS提供DNS等の例外通信については、通常のSG/NACLだけで全通信を制御できると判断しないようにします。

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。