セキュリティグループで、サーバーの壁に必要な穴だけを開ける

手順に迷ったときや、用語の意味を確かめたいときに開きましょう。

※ リンク切れの場合は、ページタイトルで検索してください。

同じ EC2 インスタンス・同じ Web サーバーのまま、セキュリティグループのインバウンドルールだけを変えて、ブラウザからの見え方がどう変わるかを比べます。

以下の要件を満たし、「HTTP を許可する前は見えず、許可すると見える」という変化を自分の手で確認してください。

「壁の外側（ネットワーク）を作る → 壁そのもの（セキュリティグループ）を作る → 中にサーバーを立てる → 穴が無い状態を確認する → 穴を 1 つ開ける」という順番で進みます。各ステップで「なぜそうするのか」を意識してみてください。

1. VPC を作成する

   VPC コンソールで「VPC を作成」→「VPC のみ」を選び、名前タグを sg-demo-vpc、IPv4 CIDR ブロックを自由に決めた値（例：10.0.0.0/16）で作成します。

   まずは土台となるネットワーク

   セキュリティグループは VPC の中で動く仕組みです。壁そのものを作る前に、壁を立てる場所となる VPC を用意します。

2. インターネットゲートウェイを作成してアタッチする

   「インターネットゲートウェイを作成」で名前タグ sg-demo-igw のものを作り、作成後に「VPC にアタッチ」から手順 1 の VPC に接続します。

   アタッチを忘れがちな理由

   インターネットゲートウェイは、作成しただけでは何もしてくれません。VPC にアタッチして初めて、インターネットとの出入り口として機能します。

3. パブリックサブネットとルートテーブルを用意する

   サブネットを 1 つ作成します（名前タグ sg-demo-public、CIDR は VPC の範囲内で自由に、例：10.0.0.0/24）。続けてルートテーブルを作成し（名前タグ sg-demo-public-rt）、ルートに 0.0.0.0/0 → 手順 2 のインターネットゲートウェイを追加し、このサブネットに関連付けます。

   「パブリック」を決めているのはルートテーブル

   サブネットが「パブリック」と呼ばれるのは、インターネットゲートウェイへの経路を持つルートテーブルが関連付けられているからです。この関連付けがないと、インターネットとやり取りできません。

4. セキュリティグループを作成する（最初は SSH のみ）

   EC2 コンソールの「セキュリティグループ」から、名前を sg-demo-web、説明を自由に入力して作成します。VPC は手順 1 で作成したものを選び、インバウンドルールに タイプ：SSH、送信元：マイ IP を 1 つだけ追加します。

   インバウンドルールを追加 — 現在の状態（イメージ）

   インバウンドルール

   SSH / TCP / 22

   送信元：マイ IP

   HTTP / TCP / 80

   まだ追加していない

   ↳この時点では SSH の穴しか開いていません

   「マイ IP」を選ぶ理由

   SSH は管理用の入り口です。誰からでも接続できる状態にすると、総当たり攻撃の対象になりやすいため、まずは自分の IP アドレスからだけ許可しておきます。

5. EC2 インスタンスを起動する

   「インスタンスを起動」で名前タグを sg-demo-web-server、AMI に Amazon Linux 2023、インスタンスタイプに無料利用枠対象のもの（例：t2.micro）を選びます。新しいキーペア sg-demo-key を作成してダウンロードし、ネットワーク設定で手順 3 のサブネットとパブリック IP の自動割り当て「有効」、セキュリティグループに手順 4 の sg-demo-web を選んで起動します。

   キーペアの .pem ファイルは失くさない

   ダウンロードできるのはこの 1 回だけです。分かりやすい場所（例：ユーザーフォルダ直下）に保存しておきましょう。

6. SSH 接続して Web サーバーをインストールする

   インスタンスが「実行中」になったら、パブリック IPv4 アドレスを確認し、PowerShell から SSH 接続します。接続できたら、Web サーバー（Apache）をインストールして起動します。

   PowerShell（ローカル）

   # 鍵ファイルの権限を自分のみ読み取り可に絞る
   icacls .\sg-demo-key.pem /inheritance:r
   icacls .\sg-demo-key.pem /grant:r "$($env:USERNAME):(R)"
   
   # SSH接続（IPは自分のインスタンスのものに置き換える）
   ssh -i .\sg-demo-key.pem ec2-user@<インスタンスのパブリックIP>

   EC2 インスタンス内

   # パッケージを更新し、Webサーバー（Apache）をインストールする
   sudo dnf update -y
   sudo dnf install -y httpd
   
   # Webサーバーを起動し、再起動時にも自動起動するようにする
   sudo systemctl start httpd
   sudo systemctl enable httpd
   
   # 確認用の簡単なページを作成する
   echo "<h1>Hello from Security Group Handson</h1>" | sudo tee /var/www/html/index.html

7. ブラウザでアクセスし、見えないことを確認する

   ブラウザで http://<インスタンスのパブリックIP>/ にアクセスします。Web サーバーは動いているのに、ページが読み込めずタイムアウトすることを確認します。

   これは正常な状態

   Web サーバー自体は動いていますが、セキュリティグループのインバウンドルールに HTTP(80) の許可が無いため、通信が壁の外で止められています。「サーバーが動いていること」と「外から見えること」は別ものだと分かる場面です。

8. HTTP(80) のルールを追加し、見えることを確認する

   セキュリティグループ sg-demo-web の「インバウンドルール」タブから「ルールを編集」→「ルールを追加」で、タイプ：HTTP、送信元：自由に選んだ値（例：0.0.0.0/0）を追加して保存します。もう一度同じアドレスにブラウザでアクセスし、作成したページが表示されることを確認します。

   穴を 1 つ開けただけで変わる

   サーバー側の設定は何も変えていません。セキュリティグループに HTTP(80) のルールを 1 行追加しただけで、外から見える状態に変わったことを確認しましょう。

初学者がよく引っかかる箇所を先回りでまとめました。答えそのものは載せていませんが、「どこを見直せばよいか」の手がかりとして使ってください。

要件の再確認ではなく、画面のどこを見れば達成を確認できるかをまとめました。EC2 コンソールとブラウザで、次を順に確かめましょう。

• EC2 インスタンスの詳細画面「セキュリティ」タブに、作成したセキュリティグループ（例：sg-demo-web）が表示されている。
• そのセキュリティグループの「インバウンドルール」タブに、SSH(22) と HTTP(80) の 2 行が並んでいる。
• ブラウザで http://<パブリックIPv4アドレス>/ を開くと、手順 6 で作成したページが表示される。
• EC2 の「ネットワーキング」タブで確認できるパブリック IPv4 アドレスと、ブラウザでアクセスしたアドレスが一致している。
• 同じキーペアで SSH 接続も引き続きでき、Web サーバーとしての公開と、管理用の SSH 接続が両立できている。

手を動かすことに加えて、次の問いに自分の言葉で答えられるようにしておくと、理解がより深まります。

1. なぜセキュリティグループは、新規作成した時点で「インバウンドは何も許可しない」状態から始まるのでしょうか。もし逆に「最初から全部許可」だったら、何が起きるか考えてみましょう。
   ヒント

   インターネットには、開いているポートを探して接続を試みる通信が常に存在します。「必要な穴だけを自分で開ける」というホワイトリスト方式と、「全部開けてから危険なものだけ塞ぐ」というブラックリスト方式、どちらが安全に保ちやすいか比べてみましょう。
2. 今回は HTTP(80) の送信元を自由に選べるようにしましたが、SSH(22) の送信元は「マイ IP」のままにしました。もし SSH の送信元も 0.0.0.0/0（どこからでも）にしてしまうと、どんなリスクがあるでしょうか。
   ヒント

   SSH は鍵さえあればサーバーの中に入れる、管理者向けの入り口です。誰からでも接続を試みられる状態にすると、総当たりでの認証試行の対象になりやすくなります。「見せてよい通信」と「絞るべき通信」の違いという観点で考えてみましょう。
3. セキュリティグループのルールを削除すると、そのルールで許可されていた今まさに確立している通信（例えば開いたままの SSH セッション）はどうなると思いますか。実際に試して確かめてみましょう。
   ヒント

   セキュリティグループは「ステートフル」だと言われます。まずは自分の予想を立ててから、実際にルールを一時的に変更し、既存の接続がどうなるかを観察してみましょう。公式ドキュメントの「セキュリティグループのルール」のページも手がかりになります。

作ったものを片づけるところまでが一連の流れです。作成した順とは逆の順番で、依存関係のあるものから削除していきます。

1. EC2 インスタンスを終了する：EC2 コンソールでインスタンスを選択し、「インスタンスの状態」→「インスタンスを終了」を選ぶ。
2. キーペアを削除する（任意）：不要であれば「キーペア」から sg-demo-key を削除し、手元の .pem ファイルも整理する。
3. セキュリティグループを削除する：インスタンスの終了後、sg-demo-web を選択して削除する。
4. サブネットを削除する：VPC コンソールでサブネット sg-demo-public を削除する。
5. ルートテーブルを削除する：自作したルートテーブル sg-demo-public-rt を削除する（デフォルトのルートテーブルは残る）。
6. インターネットゲートウェイをデタッチ・削除する：sg-demo-igw を VPC からデタッチしたあと、削除する。
7. VPC を削除する：最後に sg-demo-vpc を削除する。