この記事で分かること
- SGの基礎
- SGの設定方法
- EC2に繋げるための設定
はじめに
今回はセキュリティグループ(SG)について纏めたいと思います。ソリューションアーキテクトアソシエイトで仕様の理解が必須で、ネットワークアクセスコントロールリスト(NACL)、通称ナクル(ナックル)もセットで覚える必要があります。タイトルは基礎となっていますが、ちょっと踏み込んだ記載もあります。
SGの基礎
SGはトラフィック制御のためのファイアウォールです。仕様のポイントは二つで「ホワイトリスト」「ステートフル」です。
ホワイトリスト
許可した設定のみ通信可能で、この許可設定に合致しないものは全て拒否となる方式です。つまり「拒否設定」はできません。「拒否設定ができない」が重要ポイントで資格試験で「SGで拒否設定をする」と記載があったら、真っ先に除外となります。しかし、説明においては「拒否」という言葉も使用されるので混乱しないようにしてください。繰り返しになりますが、「許可」のみ記述可能です。
ステートフル
SGを通過した通信は「状態が維持」されます。例えば、外からの通信(インバウンド)のみを受け入れるEC2があった場合は、インバウンド設定のみ、でOKとなります。(アウトバウンド設定なし=全て拒否、でも通信可)
蛇足ですが、ワンダフル、ビューティフルと同様に、ステート(状態)がフル(満ちた)という意味です。
SGの設定情報は以下画像のとおり、そのSGを使用する「VPC」を設定します。つまり、SGは自アカウントのVPCに紐づくリソースのため、自アカウントを越えての設定はできません。したがって、他アカウントのVPCやS3等のグローバルリソースに付与はできません。また、同一VPC内で同名のSGは作成できません。
↓SG作成時の設定情報↓

さらに、AWS公式資料には記載されていないですが(私には見つけられませんでしたが)、作成後は別のVPCへの付け替え(変更)はできません。既存SGの設定値を別VPCでも使用したい場合は、コピーからの新規作成としてください。
SGの設定先は、「EC2」や「RDS」など、いわゆる通信を発生させる/通信を受け取るリソース、と思っておけばよいかと思います。また、インターフェース型のVPCエンドポイントにもセキュリティグループを設定することが可能です。面白いところでいくと、VPC配置としたLambdaに対しても設定可能です。(グローバル配置のLambdaに対してはSGの設定は不可)
SGの初期設定
VPCごとに「デフォルトSG」が自動で1つ作成されます。以下画像のとおり「セキュリティグループ名」に「default」とあるものが自動で作成されたSGとなります。(私のアカウントにはVPCが4つあるので、defaultも4つある)

このデフォルトSGをカスタマイズして使用するのもよいですし、自分で作成したSGを使用するのも問題ありません。ただし、業務運用上は新規にSGを作成することをお勧めします。というのも「セキュリティグループ名」と「説明」欄がSG作成後は変更不可のためです。つまり、どういったSGなのかを判別することができないので、新規にSGを作成することをお勧めします。
デフォルトSGの設定は以下のようになっています。
インバウンド:
同SG以外からの通信のみ許可(=それ以外の通信は拒否)
アウトバウンド:
すべての通信を許可
以下、Security Group AをデフォルトSGとして,、初期の通信許可/拒否の設定を図示します。


1つ目のSecurityGroup Aどうしの通信ですが、以下ガイドより「プライベートIP」での通信に限ります。

引用元:セキュリティグループのルール
つまり、SGの設定において、ソース(送信元)を「SG」にしただけではパブリックIPでの通信はできません。
2つ目のアウトバウンドに関する通信ですが、アウトバウンドについては全て許可されています。
勘違いしやすいポイントだと思うのですが、同じSGを使用していることが理由で通信ができるわけではありません。あくまでインバウンド・アウトバウンドに対し適切に許可がされていることで通信が可能となります。そのため、たまに見かける以下の略式図は本質的には間違いです。(インバウンド・アウトバウンドの設定が適切に行われている、という前提で以下の略式図が成り立ちます)

なお、以下画像内の理由のとおりデフォルトのSGは削除はできません。

まずEC2に繋げるために・・
EC2でどんなサービスを使用するのか、また、そのEC2がサーバなのかクライアントなのか、、でイン/アウトの設定がガラッと変わると思いますが、初心者の方はまずは「ICMP(Ping)」とLinuxであれば「SSH」、Windowsであれば「RDP」の通信許可設定をしてみましょう。EC2への接続(SSH、RDP)はEC2側の設定もあるので、それらはEC2側の記事で纏めるとして、今回はICMPについての設定を紹介したいと思います。ICMPであれば、EC2さえ起動していれば問題ありません。

前提は、セキュリティグループが設定されている起動状態のEC2があること、となります。またEC2のパブリックIPをメモしてください。以下画像は、今回作成したEC2のパブリックIP「43.207.59.100」に向けての自宅PCからのPingとなります。画像のとおりデフォルトのSGではPingは通りません。

自IPの確認
こちらなどで現在操作しているPC(自宅PC)で使用しているグローバルIPを確認します。
SGの設定
検索窓に「セキュリティグループ」と打ち込んで、セキュリティグループ設定画面を開きます。

※EC2やVPCサービスに入って左側のメニューからセキュリティグループを開くでも問題ありません。
EC2に付与しているSGに☑して、インバウンドルールタブ内の「インバウンドルールの編集」をクリックします。

「ルールの追加」をクリックして、新規に空項目が作成されますので、タイプ:「すべてのICMP - IPv4」を選択して、ソース:STEP1で調べた「IPアドレス/32」(下記画像のxxx.xxx.xxx.xxx/32の部分)を入力し、「ルールを保存」をクリックします。

ソースは「0.0.0.0/0」つまり、Anywhere IPv4でももちろん通信はOKですが、SEとして褒められた設定ではありませんので、自アドレスを調べる手順を設けています。
なお、代表的なサービスはAWS側で用意されています。そのため、タイプの項目で「SSH」「RDP」を選べば、自動でポートを「22」「3389」と設定してくれます。
Ping確認
最初にメモしたEC2のパブリックIPに対して、実際にPingを実行します。LinuxであればCLIからそのまま、Windowsであればコマンドプロンプトを立ち上げてPingを実行してください。以下画像は、今回作成したEC2のパブリックIP「43.207.59.100」に向けてのPingとなります。

無事、疎通確認ができました。
さいごに
セキュリティグループ(SG)の基礎と設定について纏めました。実際にクラウド上に立てたリソースに対してアクセスができることを確認できると、SEとして一歩前進した気持ちになれます。EC2に関しては別記事にて纏めますので、そちらと併せて是非SGの挙動について実際に触って学んでみてください。
補足
・SG作成後の編集不可項目について
「SGの基礎」「SGの初期設定」の箇所で記載しましたが、「セキュリティグループ名」「説明欄」「VPC」は作成後に編集不可です。しかし、セキュリティグループ名は作成後に編集不可と明確に記載ありますが、「説明欄」「VPC」には編集不可の旨は書いていないんですよね。片手落ちな説明であることは否めないですね。

・WindowsServer2022を立ててRDP
WindowsServer2022のEC2を立ち上げて、SGにてRDP:3389を許可してRDPを実行した様子が以下の画像です。

WindowsServerなんて、一昔前であれば、例えばOSイメージを持ってきてVirtualBOXやVMwareで(検証のために)建てたりしましたし、それより前はそもそも個人でWindowsServerを起動させることすら難しかったように思います。提供されるOSは英語版ではありますが、こんなのが無料枠で提供されているのですから、クラウドの凄まじさを痛感せざるを得ません。