この記事の要点

セキュリティグループは、クラウドの仮想マシンなどに付与する「インスタンス単位の仮想ファイアウォール」。 インバウンド(着信)とアウトバウンド(発信)のルールを定義し、許可した通信だけを通す(デフォルト拒否)。 セキュリティグループはステートフルで、許可した通信の戻りパケットは自動的に通る(戻り側の許可は不要)。 サブネット境界で動く NACL はステートレスで、戻り通信も明示的に許可する必要がある点が大きく異なる。 ルールの送信元には IP/CIDR だけでなく「別のセキュリティグループ」を指定でき、構成変更に強い設計ができる。 必要最小限のポート・送信元だけを開ける「最小権限の原則」で書くのが、クラウドセキュリティの基本。

概要

セキュリティグループ(Security Group)とは、クラウド上の仮想マシン(インスタンス)やコンテナ、データベースなどに直接付与する、インスタンス単位の仮想ファイアウォールです。どの送信元から、どのポートへの通信を許可するかをルールとして定義し、許可していない通信はすべて遮断します(デフォルト拒否)。

従来のオンプレミスでは、ファイアウォールはネットワークの境界(ルータやアプライアンス)に置くのが一般的でした。これに対しセキュリティグループは、個々のサーバそのものに「持ち運べる防壁」を貼り付けるイメージです。サーバが別のサブネットへ移動しても、同じセキュリティグループを付けていれば同じ通信制御が適用されます。クラウドでは、この粒度の細かいアクセス制御が安全性の要になります。

仕組み

セキュリティグループはインバウンドルール(そのインスタンスへ入ってくる通信)とアウトバウンドルール(そのインスタンスから出ていく通信)の 2 種類を持ちます。各ルールは「プロトコル・ポート範囲・送信元(または宛先)」で構成されます。

Web サーバ用セキュリティグループ (インバウンド)
┌──────────┬─────────┬──────────────────┐
│ プロトコル │ ポート   │ 送信元            │
├──────────┼─────────┼──────────────────┤
│ TCP      │ 443     │ 0.0.0.0/0 (全世界) │ ← HTTPS 公開
│ TCP      │ 80      │ 0.0.0.0/0          │ ← HTTP 公開
│ TCP      │ 22      │ 203.0.113.10/32    │ ← SSH は自社IPのみ
└──────────┴─────────┴──────────────────┘
※ 上記以外の着信はすべて拒否

セキュリティグループの最大の特徴はステートフルであることです。あるインバウンド通信を許可すると、その通信に対する戻りのパケットは、アウトバウンドルールに関係なく自動的に通過します。たとえば「443 番への着信」を許可すれば、その応答(サーバ → クライアント)は明示的に許可しなくても返せます。「行きを許可すれば帰りも通る」ため、ルールがシンプルになります。

もう 1 つの強力な機能が、ルールの送信元に別のセキュリティグループを指定できる点です。たとえば DB サーバのセキュリティグループで「送信元 = アプリサーバのセキュリティグループ」とすれば、アプリサーバが増減しても IP を書き換える必要がなく、構成変更に強い設計になります。

構成・実用例

3 層構成でセキュリティグループ同士を参照させ、階層ごとにアクセスを絞る例です。

[インターネット]
     │ 443/80
 ┌───▼──────────── ALB-SG ───────────────┐
 │  in : 443,80 from 0.0.0.0/0           │
 └───┬───────────────────────────────────┘
     │ 8080 (送信元 = ALB-SG)
 ┌───▼──────────── APP-SG ───────────────┐
 │  in : 8080 from ALB-SG                │
 └───┬───────────────────────────────────┘
     │ 3306 (送信元 = APP-SG)
 ┌───▼──────────── DB-SG ────────────────┐
 │  in : 3306 from APP-SG                │ ← アプリ層からのみ
 └───────────────────────────────────────┘

AWS CLI でセキュリティグループを作り、SSH を特定 IP に限定する例です。送信元を 0.0.0.0/0 にしないことが重要です。

# セキュリティグループ作成
aws ec2 create-security-group --group-name web-sg \
    --description "web" --vpc-id vpc-xxxx

# SSH(22) を自社グローバルIPのみ許可
aws ec2 authorize-security-group-ingress --group-id sg-xxxx \
    --protocol tcp --port 22 --cidr 203.0.113.10/32

このようにセキュリティグループ参照で階層を組むと、「DB は誰からアクセス可能か」がルールを見るだけで明確になり、監査やトラブルシュートが容易になります。

主な用途

• 公開ポートの限定 — Web サーバなら 443/80 のみ公開し、それ以外は閉じます。
• 管理ポートの保護 — SSH(22)・RDP(3389)を自社 IP や踏み台サーバからのみ許可します。
• 階層間アクセス制御 — セキュリティグループ参照で「DB はアプリ層からのみ」のような関係を表現します。
• マイクロサービス間の通信制御 — サービスごとにグループを分け、必要な経路だけを開けます。

関連技術との比較

項目	セキュリティグループ	ネットワーク ACL(NACL)
適用単位	インスタンス(ENI)単位	サブネット単位
状態管理	ステートフル(戻りは自動許可)	ステートレス(戻りも明示許可)
ルールの種類	許可ルールのみ	許可・拒否ルール両方
評価順序	全ルールを総合判定	番号順に最初に一致したもの
送信元の指定	IP/CIDR + 他のセキュリティグループ	IP/CIDR のみ
主な役割	サーバ単位の細かい制御	サブネット境界の粗い制御

注意点・落とし穴

• 0.0.0.0/0 で SSH/RDP を開けない — 管理ポートを全世界に開放するのは典型的な事故原因です。送信元 IP を必ず絞ります。
• セキュリティグループは「許可」しか書けない — 特定の IP だけ拒否したい(ブロックリスト)用途には向きません。それは NACL の役割です。
• NACL とは別物 — ステートフル/ステートレスの違いを混同すると、NACL 側で戻り通信を許可し忘れて「行きは通るのに帰りが落ちる」不具合が起きます。
• ルールの上限 — 1 グループあたりのルール数や、1 インスタンスに付けられるグループ数には上限があります。むやみに増やさず整理します。
• 最小権限を徹底する — 「とりあえず全許可」で動かすと、後から絞るのは難しくなります。最初から必要な通信だけを開けます。

関連リンク

• クラウドネットワーク
• VPC
• サブネット(クラウド)
• クラウドロードバランサ
• VPNゲートウェイ・専用線接続
• クラウド・インフラ
• アドレッシング・識別子
• プライベートIPアドレス