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

広いSG、順序を誤ったNACL、戻り通信の不足を事例から診断します。ルールを足す前に、許可が合算されるのか順序で決まるのかを確認します。

この単元で学ぶこと

1. 狭いSGを追加したのに公開 EC2に全世界から443を許すSG-Aと社内だけ許すSG-Bが付いています。SG-Bを追加してもAの広い許可は消えません。意図しない公開を止めるには、関連SGをすべて確認し不要な許可を取り除きます。拒否の優先順位で解決するNACLの発想を使わないことが重要です。

2. DBの接続元台数が変わるアプリ群のIPをDB側へ毎回列挙する代わりに、同一VPCではアプリSGを送信元にしたDBポートの許可を設計できます。アプリSGを使う資源の範囲も管理します。参照先のSGに書かれたルールが丸ごとDBへコピーされる仕組みではありません。

3. 同じSGの誤解二台のEC2に同じSGを付けても、そのSGに両者間を許可する条件がなければ自動的に全通信が通るわけではありません。相互通信が必要なら、必要ポートの自己参照を検討します。動かすために全プロトコルを自己参照するのではなく業務要件へ絞ります。

4. NACLの先勝ち受信番号100で0.0.0.0/0を許可し、番号200で特定IPを拒否しても、そのIPは先の100に一致します。拒否を先に評価させる適切な番号と範囲へ直します。一方、広い拒否を先に書くと必要な許可へ到達しなくなるため、各パケットの最初の一致を検算します。

5. 戻りが欠ける例内部EC2が送信元51000から外部443へ通信し、応答は外部443から内部51000へ戻ります。NACL受信側を443だけ許可しても、この応答の宛先は51000です。使用OSとアプリの一時ポート範囲を確認し、送受信の表で不足を見つけます。

6. 新規NACLで全停止デフォルトNACLから新しいカスタムNACLへ付け替えると、許可を追加するまで全拒否になる場合があります。置換前に必要な双方向ルールを準備し、関連するサブネットと影響範囲を確認します。SGが変わっていなくてもサブネット境界で止められます。

7. ログの読み方 Flow Logsで対象フローが拒否されていれば、適用するSGやNACLを調べる手掛かりになります。ただし記録の対象や集約、経路を考慮し、一件のACCEPTだけでWebアプリ成功としません。接続先ポートの待受け、OS側フィルター、TLSやアプリ認証も確認します。

8. 検証すべき拒否アプリからDBの指定ポートは成功し、別の層や不要ポートは失敗することを確かめます。Amazon提供DNSの制御などSG/NACLが同じように作用しない対象も分けます。正常経路と拒否経路を記録し、接続不能をすべてルール全開放で覆い隠さないようにします。

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

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