通信制御の基本から安全な運用設計・管理のポイントまで解説
AWS環境では、インターネットやほかのリソースとの通信をどのように制御するかが、セキュリティ対策の基本となります。その中心的な役割を担うのが「セキュリティグループ」です。
しかし、実際の運用現場では「とりあえず必要なポートを開けている」「過去の設定をそのまま使っている」といったケースも少なくありません。例えば、SSH（22）やRDP（3389）を0.0.0.0/0で全開放してしまうと、総当たり攻撃による侵入リスクが高まります。また、障害対応のために一時的に許可したルールを戻し忘れ、意図せず公開状態が放置されることもあります。
さらに、ネットワークACL（NACL）との違いや使い分けが曖昧なまま運用されているケースもあるでしょう。本記事では、セキュリティグループの基本的な役割や仕組みを整理したうえで、ネットワークACLとの違い、設定方法、運用時の注意点について解説します。
目次
1. AWSのセキュリティグループとは
AWSのセキュリティグループとは、AWS上の各リソースに対する通信を制御するための仕組みです。主にEC2インスタンスなどのリソースに適用され、許可する通信をルールとして定義することで、外部や他リソースからのアクセス可否を管理できます。
AWS環境では、インターネットやVPC内のリソース間で絶えず通信が発生します。これらをすべて無制限に許可すると、不正アクセスや情報漏えいにつながりかねません。一方で、必要な通信まで遮断してしまうと、アプリケーションの動作や他サービスとの連携に支障をきたします。
こうしたセキュリティの確保と利便性の維持を両立するための、基本的なアクセス制御の仕組みがセキュリティグループです。
セキュリティグループの特徴
セキュリティグループには、通信制御の考え方として以下のような特徴があります。
リソース単位での適用
セキュリティグループは、EC2インスタンスやロードバランサーなどのAWSリソースに直接関連付けられ、そのリソースへの通信を制御します。
制御の対象となる通信には、外部からリソースへ向かう通信（インバウンド）と、リソースから外部へ向かう通信（アウトバウンド）があります。これにより、同じサブネット内であっても、リソースごとに異なる通信ルールを設定可能です。
ホワイトリスト型
セキュリティグループは、許可する通信のみをルールとして定義するホワイトリスト型です。ルールに記載されていない通信はすべて拒否されます。
明示的に「拒否ルール」を設定することはできないため、必要な通信だけを厳選して許可する設計が必要です。また、登録されたすべてのルールが評価の対象となり、特定のルールがほかのルールより優先されることはありません。
ステートフル
ステートフルとは、通信の状態（やり取りの流れ）を保持して判断する仕組みです。セキュリティグループはステートフルな仕組みのため、インバウンドで許可した通信は、戻りの通信をアウトバウンドで個別に定義しなくても自動的に許可されます。
この仕組みにより、通信の往復を意識した複雑なルール設計が不要になる一方、通信の流れを細かく分けて制御する用途には向いていません。
セキュリティグループのルール
セキュリティグループで定義するルールには、以下のような項目を指定します。
- プロトコル：通信に使用するプロトコル（TCP、UDP、ICMPなど）
- ポート番号：許可するポート番号（単一または範囲で指定可能）
- 送信元／送信先：IPアドレスやCIDRブロック、セキュリティグループ、プレフィクスリストなど
- 説明文：ルールの意図や用途など、各ルールを管理しやすくするための文章
AWSのセキュリティに関する基本的な考え方や全体像については、以下の記事をご覧ください。
2. セキュリティグループとネットワークACLの違い
AWSでは通信を制御する仕組みとして、セキュリティグループのほかに「ネットワークACL」も用意されています。どちらもアクセス制御に使われるため混同されやすいですが、両者の大きな違いはセキュリティグループがリソース単位、ネットワークACLがサブネット単位で適用される点です。
主な違いをまとめると以下のとおりです。
| 【比較観点】 | 【セキュリティグループ】 | 【ネットワークACL】 |
| 適用範囲 | リソース単位 | サブネット単位 |
| 設定方法 | 許可のみ | 許可・拒否 |
| 設定効果 | ステートフル | ステートレス |
| ルールの評価 | 優先順位はなく、すべて評価される | 優先度順に評価される |
通信はサブネットに適用されたネットワークACLで先に評価され、その後、リソースに関連付けられたセキュリティグループで評価されます。そのため、いずれか一方の設定で通信が拒否されている場合、意図した通信であっても成立しません。両者の違いや評価の順番を正しく理解したうえで、設計や設定内容を確認することが重要です。
セキュリティグループとネットワークACLの使い分け方
リソース単位で柔軟に制御できるセキュリティグループを中心にアクセス制御を行い、ネットワークACLは全許可のまま運用するケースが一般的です。
一方で、サブネット単位で特定のIPアドレスをまとめて拒否したい場合や、より厳格なトラフィック制御が求められる環境では、拒否設定のできるネットワークACLが有効です。
ただし、両者を併用すると設計や運用の難易度が上がるため、日常的な制御はセキュリティグループに集約し、ネットワークACLは本当に必要な場面に限定して導入を検討するとよいでしょう。
3. セキュリティグループの設定方法
セキュリティグループの基本的な設定手順を解説します。
1.セキュリティグループを作成する
Amazon VPCコンソールから[セキュリティグループの作成]を選択し、セキュリティグループ名と説明を設定します。作成後は変更できないため、慎重に設定しましょう。
新しく作成したセキュリティグループには、デフォルトですべてのアウトバウンド通信を許可するルールのみが設定されています。
2.インバウンド／アウトバウンドルールを設定する
次に、実際に必要な通信のみを洗い出したうえで、ルールを追加します。インバウンドルールでは「どこからの通信を受け付けるか」、アウトバウンドルールでは「どこへの通信を許可するか」を定義します。ルールごとに、プロトコル、ポート番号、送信元または送信先を指定しましょう。
この際、広範囲なIPアドレス指定は極力避け、業務やシステム要件に必要な範囲に限定することが重要です。
3.リソースにセキュリティグループを適用する
最後に、作成したセキュリティグループをEC2インスタンスやロードバランサーなどの対象リソースに関連付けます。1つのリソースには複数のセキュリティグループを同時に適用でき、許可ルールはすべて統合して評価されます。
そのため、どのセキュリティグループがどの通信を許可しているのかを把握したうえで設計することが重要です。適用後は、想定どおり通信できるかを確認し、不要な許可ルールが含まれていないかもあわせてチェックしておきましょう。
上記の手順で設定したあとも、AWSでは運用や構成の変更に伴って設定を見直す機会が多く、継続的な管理が必要です。設定内容に誤りがあると、意図せず外部からアクセス可能な状態になり、不正アクセスや不正ログインなどの攻撃を受けるリスクが高まります。
運用開始後も定期的に設定内容を確認し、不要な許可が残っていないかをチェックすることが重要です。
4. セキュリティグループ設定時の注意点
セキュリティグループは、AWS環境における基本的なアクセス制御の仕組みですが、設定や運用を誤ると、意図しない通信許可や遮断を招く原因となります。ここでは、セキュリティグループを運用するうえで意識しておきたいポイントを整理します。
セキュリティグループの数は必要最小限にする
セキュリティグループは用途ごとに複数作成できますが、役割単位で整理し、必要最小限の数にとどめることが大切です。数が増えすぎたり、ルールを細かく分けすぎたりすると、どのセキュリティグループがどの通信を許可しているのか把握しにくくなり、設定ミスや不要な許可の見落としにつながります。
定期的に棚卸しを行い、まとめられるものは統合するなど、管理できる範囲を意識して設計しましょう。
設定を変更できるユーザーを限定する
セキュリティグループの設計は、技術的な設定だけでなく、IAM（AWS Identity and Access Management）による権限管理や運用体制とセットで考える必要があります。
誰でも設定を編集できる状態だと、意図しないルール追加や削除が発生するリスクが高まります。特に、緊急対応や一時的な検証のために追加したルールが、そのまま削除されずに残り続けてしまうケースは少なくありません。
そのため、IAMを活用し、セキュリティグループの作成・変更が可能なユーザーやロールを明確にしたうえで、権限を限定した運用ルールを定めておくことが重要です。
必要なポートだけを開放する
セキュリティグループでは、通信に使用するポート番号を細かく指定できるため、「とりあえず広く許可する」といった設定は避けるべきです。
不要なポートを開放してしまうと、それだけ攻撃や不正アクセスの入り口を増やすことになります。実際に利用しているサービスや通信要件を整理し、必要最小限のポートと通信範囲に限定して許可することが基本です。
また、不要になったポートが開放されたままになっていないか、定期的に見直しましょう。
管理用のアクセスは特定のIPアドレスのみ許可する
SSHやRDPなど、管理操作に関わる通信は特に慎重に扱う必要があります。これらを不特定多数に対して許可してしまうと、第三者による不正ログインや総当たり攻撃の対象になりやすく、サーバーの乗っ取りや設定改ざんにつながるリスクが高まるためです。
社内ネットワークや担当者の固定IPアドレスなど、特定の送信元のみに限定して許可する設計が望ましいです。あわせて、踏み台サーバーの利用や運用方法も含めて検討することで、より安全な管理体制を構築しやすくなります。
運用中の変更を前提に管理する
セキュリティグループは一度設定して終わりではなく、運用中に変更されることが前提となります。そのため、「いつ・誰が・どのルールを変更したのか」を把握できる状態に保つことが重要です。
変更内容を把握できていないと、設定ミスによって意図せず外部からアクセス可能な状態になったり、逆に必要な通信が遮断されたりするおそれがあります。特に稼働中のシステムに対する変更は影響範囲に気づきにくいため、細心の注意が必要です。
変更履歴を確認できる仕組みを整え、監査の視点を持って管理することで、トラブルの早期発見や原因特定につながります。
AWS公式のユースケースを参考にする
セキュリティグループの設計に迷った場合は、AWS公式で公開されているユースケース別のルール例を参考にするのも有効です。
ゼロからルールを考えるよりも、公式の設計例をベースに自社環境に合わせて調整するほうが、設定ミスを減らしやすいでしょう。特にAWSの利用に慣れていない場合や、少人数体制で運用している場合には、判断の属人化を防ぐうえでも有効な手段といえます。
さまざまなユースケースのセキュリティグループのルール – Amazon Elastic Compute Cloud
セキュリティグループは重要なアクセス制御の仕組みですが、単体ですべての脅威を防げるわけではありません。例えば、設定ミスや正規の認証情報を使った操作などにより、侵入に気づきにくいケースもあります。
そのため、ログや挙動をもとに不審な振る舞いを検知するAmazon GuardDutyに加え、設定不備や公開リスクを継続的にチェックするAWS Security Hub CSPMを組み合わせて運用すると、より効果的なセキュリティ対策を実現できます。
まとめ
AWSのセキュリティグループは、AWS上のリソースに対する通信を制御する基本的なセキュリティ機能です。適切に設計・運用することで、不正アクセスや意図しない公開リスクを抑えられます。
一方で、設定内容は運用中に変更されることが多く、ルールの増加や変更履歴の把握不足によって、設定ミスや想定外の通信が発生するケースも少なくありません。セキュリティグループの効果を維持するには、設計時だけでなく、変更管理や監査、ほかのAWSセキュリティサービスと組み合わせた継続的な運用が重要です。
ハートビーツの「SecureOps+」は、AWSの各種セキュリティサービスによる検知機能を活用しながら、24時間365日の監視、初動判断、設定支援までを一貫して提供するマネージドセキュリティサービスです。セキュリティグループを含むAWS環境の運用に不安がある場合は、ぜひハートビーツへご相談ください。
