本記事では、AWSのセキュリティグループの基本から、ネットワークACL（NACL）との違い、ステートフルな通信の特徴、そして安全に運用するためのベストプラクティスまでを詳しく解説します。
セキュリティグループとは何か？
AWS（Amazon Web Services）を利用する上で、避けては通れない非常に重要な要素が「セキュリティグループ」です。「クラウドはセキュリティが心配」という声もありますが、このセキュリティグループの仕組みを正しく理解し設定することで、オンプレミス環境以上の堅牢なシステムを構築することが可能です。
AWSのセキュリティグループ（Security Group）を一言で表すと、「仮想ファイアウォール」です。AWS上のリソース（EC2インスタンスなど）へのインバウンド（受信）およびアウトバウンド（送信）トラフィックを制御する役割を担っています。
インスタンス単位の防護壁
セキュリティグループの最大の特徴は、サブネット単位ではなく、インスタンス（ネットワークインターフェース：ENI）単位で適用される点です。これにより、同じサブネット内に存在するサーバーであっても、「WebサーバーにはHTTP通信を許可し、DBサーバーにはWebサーバーからの通信のみを許可する」といった、きめ細かな制御が可能になります。
- ホワイトリスト方式: デフォルトではすべての通信が拒否されており、許可する通信のみを「ルール」として定義します。
- 拒否ルールは作れない: 「特定のIPをブロックする」といった拒否の設定はできず、あくまで「何を許可するか」を指定します。
セキュリティグループとNACLとの違い
AWSにはセキュリティグループに似た機能として「ネットワークACL（NACL）」があります。これらは併用されることが多いですが、動作のレイヤーや特性が大きく異なります。
| 比較項目 | セキュリティグループ | ネットワークACL（NACL） |
|---|---|---|
| 適用対象 | インスタンス（ENI）単位 | サブネット単位 |
| ルールの種類 | 許可ルールのみ | 許可ルールと拒否ルール |
| 通信の特性 | ステートフル（戻り通信は自動許可） | ステートレス（戻り通信もルールが必要） |
| ルールの評価順 | すべてのルールを評価して判断 | 番号順に評価（先に一致したものが優先） |
実務的な使い分けとしては、「セキュリティグループをメインの防御壁」として使い、「NACLは特定の悪意あるIP帯域をブロックするサブの防御壁」として使うのが一般的です。
セキュリティグループを適用できる場所・内容
セキュリティグループは、単にEC2インスタンスだけでなく、多くのAWSリソースに適用されます。
主な適用対象リソース
- Amazon EC2: 仮想サーバー本体。
- Amazon RDS: データベース。Webサーバーからのアクセスを制限するために必須。
- AWS Lambda: VPC内で動作する関数。
- Elastic Load Balancing (ELB): ロードバランサー。外部からのトラフィックを受ける最初の窓口。
設定できるルールの内容
ルールを設定する際は、以下の要素を組み合わせて定義します。
- プロトコル: TCP, UDP, ICMP など。
- ポート範囲: 80 (HTTP), 443 (HTTPS), 22 (SSH) など。
- ソース（送信元）/ 送信先:
- IPアドレス（CIDR形式）:
203.0.113.0/24など - 他のセキュリティグループID: これが非常に強力です。特定のセキュリティグループが付与されたリソースからの通信だけを許可する「グループ間連携」が可能です。
- IPアドレス（CIDR形式）:
セキュリティグループ通信の特徴（ステートフルな通信）
セキュリティグループを理解する上で最も重要なコンセプトが「ステートフル（Stateful）」です。
ステートフルとは？
「状態を保持する」という意味です。セキュリティグループは、一度許可されたインバウンド通信に対して、その「戻りの通信（レスポンス）」を自動的に許可します。
例えば、インバウンドルールで「ポート80（HTTP）を許可」していれば、サーバーからクライアントへ返すレスポンス通信のためにアウトバウンドルールをわざわざ設定する必要はありません。逆もまた然りで、アウトバウンドで外部へリクエストを出した場合、その戻りパケットはインバウンド設定に関わらず通過します。
この特性により、管理者は「必要な通信の入り口」だけを考えればよく、複雑なポート番号の動的変化（エフェメラルポートなど）を気にする必要がなくなるため、設定ミスを大幅に減らすことができます。
安全に利用するために（最小の通信のみ開ける）
クラウドセキュリティの鉄則は「最小権限の原則（Least Privilege）」です。セキュリティグループの運用において守るべきポイントをまとめます。
0.0.0.0/0（フルオープン）を避ける
特にSSH（22番ポート）やRDP（3389番ポート）といった管理用ポートを 0.0.0.0/0（世界中の誰からでもアクセス可能）に設定するのは極めて危険です。必ず管理者の拠点の固定IPや、特定のVPN経由のIPに制限しましょう。
セキュリティグループIDによる参照を活用する
IPアドレスでルールを書くと、サーバーが増減した際にメンテナンスが困難になります。代わりに「Webサーバー用SG」からの通信を「DBサーバー用SG」で許可するといった、セキュリティグループ間のID参照を優先的に使いましょう。これにより、IPが変わっても自動的に許可設定が維持されます。
定期的な棚卸し
プロジェクトの進行に伴い、「一時的に開けたポート」がそのまま放置されるケースが多々あります。AWS Configやセキュリティハブなどのサービスを活用し、不要なルールや強すぎる権限が残っていないか定期的に確認しましょう。
まとめ：
AWS セキュリティグループは、クラウド環境の安全を守るための第一防衛線です。ステートフルな特性を活かしつつ、最小限の許可ルールを適用することで、外部からの攻撃リスクを最小限に抑えることができます。まずは自分の作成しているリソースが「誰と、どのポートで話す必要があるのか」を整理することから始めてみましょう。
最後にNACLとセキュリティグループを設定した簡易的な構成図を載せておきます。
コメント