y yoi1skalv

2024/10/13 08:15

ping-tの問題に対してというより、VPCの単元の「参考」を読んでいて、ふと疑問に感じたため、投稿させて頂きました。 >基本的には「許可されたアウトバウンドトラフィックに対する戻りのインバウンドトラフィックは許可」される認識で良いかと思います。 ということは、セキュリティグループのみを使って通信をフィルタしきることは難しいのでしょうか？

a arashi1977

2024/10/13 08:24

> ということは、セキュリティグループのみを使って通信をフィルタしきることは難しいのでしょうか？ 具体的にどのようなことをイメージされているかがわからないのでコメントできません。お役に立てずすみません。

y yoi1skalv

2024/10/13 18:15

言葉足らずですいません。 例えば、インスタンスへのインバウンド通信でhttpsの通信のみ許可する為に「セキュリティグループのインバウンドルールに「送信元：0.0.0.0/0」、「ポート範囲：443」、「許可」の設定を追加する」の設定をしたとします。しかし何らかの原因で意図せずに、インターネット宛に「http（80番ポート）」の通信が出ていってしまった時、セキュリティグループのステートフルな特性の為、その戻りのhttpの通信は帰ってきてしまいます。 このような時、インスタンス宛のインバウンド通信はその他の機能を使わずに、セキュリティグループのみで、（ネットワークACLなどと併用せずに）ユーザーが想定するようなフィルタ設定を施すことは難しいのでしょうか。 前提として学習中の内容なので、私自身の認識が間違っているところあるかもしれません。

a arashi1977

2024/10/14 23:36

考慮すべきポイントがいろいろ混ざっているようなのでひとつずつ整理すべきかなと言うところではあります。 前提として、ご質問の冒頭にあるように > VPCのセキュリティグループのデフォルトのルールでは「インバウンドは全て拒否、アウトバンドは全て拒否」かと思います。ルールも許可設定しかできないはずです。 ですので、基本的には許可制であり、許可されていないものは通さないわけです。そして同様に冒頭でご認識されている通り > デフォルトだとアウトバンドは許可されている ので、ここをきちんと「不許可」とすれば良いわけです。 また、「本来この通信のみが自発かつ想定される通信パターン」と言う前提でセキュリティグループの設定をするわけですから、それ以外のトラフィックが通らないように「デフォルト許可」を編集して意図しない自発トラフィックが出て行かないようにするのも大事な対応かと思います。 さらに言えば「そのような想定外の自発トラフィックを発生させるプロセス」が存在しないようにサービスを作り込む、と言うのも必要なことかなと思います。不正プロセスが組み込まれるとしたら EC2 インスタンスがありそうですが、その場合は検知して即インスタンスをイメージから作り直すことで不正プロセスが稼働していない状態にするとか、インスタンスの元イメージの改ざんをさせないことでインスタンス生成後即時不正プロセス起動といったことが起こらないようにするとか、いろんな観点で「そもそも意図しないアウトバウンドトラフィックが発生しない」ように対策するというのが必要になる、と言うことではないかなと思います。

y yoi1skalv

2024/10/15 08:58

なるほど。 > VPCのセキュリティグループのデフォルトのルールでは「インバウンドは全て拒否、アウトバンドは全て拒否」かと思います。ルールも許可設定しかできないはずです。 ここの認識がそもそも間違っていたようです。ここを訂正出来ましたので、理解出来ました。 ここまで私自身かなり説明不足なところあり、ご迷惑おかけしてしまい申し訳ございませでした。 そして懇切丁寧に回答してくださりありがとうございました。

y yoi1skalv

2024/10/15 09:03

ご回答いただきありがとうございます。 アウトバンドルールを削除できるんですね。知りませんでした。 それでしたら、ご回答頂いた中にもある通り、セキュリティグループだけでもフィルタリング出来そうです。 回答して頂い内容とても分かりやすかったです。 ありがとうございました。