はじめに
本記事の目的
本記事はAWSのセキュリティグループ（Security Groups）について、基礎から実践まで分かりやすく解説することを目的としています。クラウド上の通信制御を理解し、安全な設計に役立てられるように書きました。
誰に向けているか
- クラウド運用を始めたエンジニアや担当者
- セキュリティ設計を学びたいIT担当者
- 既にAWSを使っているが、より安全に運用したい方
専門用語は必要最小限に抑え、具体例を交えて説明します。例えば、”WebサーバーへのHTTPのみ許可”といった日常的な設定例でイメージしやすくします。
本記事で学べること
- セキュリティグループの定義と基本動作
- ルールの作り方と注意点
- ネットワークACL（NACL）との違い
- VPC間やマルチアカウントでの利用方法
- AWS Cloud WANなど新しい機能の参照方法
読み方のポイント
各章を順に読むことで、基礎から応用まで無理なく理解できます。まずは第2章でセキュリティグループの役割を押さえてください。
セキュリティグループとは何か
概要
セキュリティグループは、AWSのVPC内で動作する仮想ファイアウォールです。Amazon EC2やRDSなどのリソースに適用し、入出力のネットワークトラフィックを制御します。許可された通信だけを通す仕組みです。
何を制御するか
主にインバウンド（外からの接続）とアウトバウンド（外への接続）を管理します。たとえば、WebサーバーならHTTP(ポート80)とHTTPS(ポート443)を許可し、不要なポートは閉じます。
主な特徴
- ステートフル：インバウンドを許可すると、その応答は自動的に許可されます。
- リソース単位で適用：インスタンスごとに複数のセキュリティグループを割り当てられます。
- 参照指定が可能：IPレンジだけでなく、他のセキュリティグループを指定して通信を許可できます。
簡単な例
Web公開用のサーバーには「HTTP/HTTPSを0.0.0.0/0へ許可、SSHは管理者のIPだけ許可」といったルールを設定します。
利用時のポイント
最小権限の原則で必要な通信のみ許可してください。名前付けやタグで管理すると運用が楽になります。
セキュリティグループの動作原理
概要
セキュリティグループはインスタンスやENI（ネットワークインターフェイス）に適用する仮想ファイアウォールです。主な特徴は「ステートフル」であることです。インバウンドで許可した接続の応答パケットは、アウトバウンドルールに関係なく自動的に許可されます。
ステートフルの意味
ステートフルとは、接続の状態を保持して応答を許可する仕組みです。例えばクライアントがサーバーにTCP接続を作ると、サーバーからの応答は戻りパケットとして自動的に通ります。管理者は往復で別々のルールを用意する必要が少なくなります。
パケットの流れ（具体例）
例：Webサーバーに80番ポートを開ける場合、インバウンドで80許可だけでクライアントの応答は通ります。クライアント側のエフェメラルポート（短期間使う高番ポート）も自動的に追跡されます。
ルール評価のポイント
- ルールは「許可」だけを記述します。明示しない通信は拒否されます（暗黙の拒否）。
- ルールの順序は評価に影響しません。どのルールでもマッチすれば許可されます。
- セキュリティグループは他のグループを送信元／送信先として指定できます。
注意点
接続追跡は短時間で行われます。長時間の接続や状態変化には別途監視やログ確認を行ってください。
セキュリティグループのルール体系
概要
セキュリティグループは「インバウンド（受信）」と「アウトバウンド（送信）」の二つのルール群で成り立ちます。どちらも許可ルールのみを定義できます。拒否ルールは直接設定できません。これは設計上の特徴で、設定がシンプルになります。
インバウンドルール
インバウンドでは、どのプロトコル（例：TCP）とポート（例：80）をどの送信元（IPや別のセキュリティグループ）から許可するかを決めます。例えば「0.0.0.0/0からTCPの80番ポートを許可」すれば、誰でもHTTPで接続できます。
アウトバウンドルール
アウトバウンドでは、インスタンスからどこへどのプロトコル・ポートで接続できるかを指定します。たとえば「宛先データベースへの3306番を許可」すると、アプリがDBへ接続できます。
ルールの指定方法
- プロトコル：TCP、UDP、ICMPなど。
- ポート範囲：単一（80）や範囲（1024-65535）。
- 送信元／宛先：IPレンジ（例：192.0.2.0/24）や他のセキュリティグループ。
拒否ルールがないことの注意点
拒否を明示できないため、不要な許可を残さないことが重要です。狭く具体的に許可して、最小権限を心がけてください。例えば管理用のSSHは特定の管理IPだけに限定する、などです。
具体例
- Webサーバー：インバウンドで80/TCPと443/TCPを許可、アウトバウンドは必要に応じて制限。
- DBサーバー：インバウンドはアプリサーバーのセキュリティグループからのみ3306/TCPを許可。
順序は関係なく、ルールは合致すれば適用されます。
セキュリティグループとNACLの比較
基本の役割
セキュリティグループ（SG）はインスタンス単位で適用するファイアウォールです。ステートフルで、許可した通信の応答は自動で許可されます。NACL（ネットワークACL）はサブネット単位で適用するアクセス制御で、ステートレスです。許可と拒否のルールを持ち、番号順に評価します。
ステートフルとステートレスの違い
SGは接続を確立すると戻りのトラフィックを自動で許可します。例えば、インスタンスから外へHTTPリクエストを送ると、その応答は明示のルールが不要で戻ります。NACLは応答も明示的に許可する必要があります。戻りポート（エフェメラルポート）を忘れると通信が切れます。
ルール評価と優先度
NACLは番号の若い順に評価し、最初にマッチしたルールが適用されます。SGはすべてのルールを評価し、いずれかで許可されれば通信を通します。SGに拒否ルールはありません（許可しないものは暗黙に拒否されます）。
実践的な使い分け
- 公開Web: SGでインスタンスのポート（80/443）を限定し、NACLで既知の悪意あるIPをブロックして境界防御を追加します。
- データベース: プライベートサブネットに配置し、SGでアプリサーバーのSGのみ許可します。NACLは標準のままでも問題ない場合が多いです。
運用上の注意
両方が同時に適用されます。サブネットのNACLで許可されていてもインスタンスのSGで弾かれれば通信は通りません。設定変更は影響範囲が異なるため、誰にどの権限で変更させるかをルール化してください。ログ（VPC Flow Logs）を活用すると問題切り分けが楽になります。
セキュリティグループの作成と管理
作成方法（コンソール・CLI・コピー）
- コンソール：VPCメニューから「セキュリティグループ作成」を選び、名前・説明・VPCを指定します。インバウンド／アウトバウンドの初期ルールを追加できます。
- CLI：
aws ec2 create-security-group --group-name MySG --description "My SG" --vpc-id vpc-12345のように作成し、authorize-security-group-ingress/egressでルールを追加します。 - 既存からコピー：既存グループを参考に新規作成し、ルールだけ複製することで設定ミスを減らせます。
割り当てと範囲
- セキュリティグループは同じVPC内のインスタンスやENIに割り当てます。複数割り当ても可能です。
- 変更は即時適用され、接続に速やかに反映されます。
管理の実務ポイント
- 名前と説明を具体的に付け、目的やポート範囲を明記します。
- タグを活用して所有者や環境（dev/prod）を管理します。
- 最小権限（必要なポートのみ許可）を徹底してください。
- 監査はCloudTrailやAWS Configで行い、定期的に見直します。
削除と注意点
- 削除前に割り当てられているリソースを確認し、未割当てにしてから削除します。誤って開放したルールや冗長なグループがないか定期点検してください。
VPC間でのセキュリティグループの利用
概要
Security Group VPC Association により、同一リージョン内の複数VPCで単一のセキュリティグループを使えます。例えば、本番VPCと共有サービス用VPCで同じファイアウォール設定を適用できます。複数アカウント間ではAWS RAMを使って共有します。
利点
- 設定の一元化: ルール変更が全VPCに反映されます。例: 管理者IPだけを許可する設定を一度変更するだけで済みます。
- 一貫したポリシー: 環境ごとの差異を減らし、ミスを防げます。
簡単な手順（流れ）
- 代表のVPCでセキュリティグループを作成します（例: 管理用SG）。
- AWS RAMで共有対象のアカウントやVPCを指定して共有します。
- 共有先で招待を承認し、対象のENIやインスタンスにそのセキュリティグループを関連付けます。
注意点
- ネットワーク経路は別途必要です。VPC間の通信はピアリングやトランジットゲートウェイなどで確保してください。セキュリティグループはアクセス制御だけを担います。
- リージョンをまたいだ共有はできません。
- 権限管理に注意してください。誤って広いルールを配布すると影響範囲が大きくなります。
具体例
社内管理IPからのSSHのみ許可するSGを作成し、開発VPCと本番VPCで共有します。管理IPを追加すれば全VPCで即時有効になります。
セキュリティグループの共有機能
概要
VPC所有アカウントは、自ら作成したセキュリティグループを参加アカウントと共有できます。共有されたセキュリティグループは、共有対象サブネット内のリソースにのみ適用できます。参加アカウントはそのグループを利用できますが、ルールの変更や再共有はできません。これにより、複数アカウント間でセキュリティポリシーの一貫性を保てます。
共有のしくみ（簡単な流れ）
- VPC所有者がセキュリティグループを選び、共有設定を行います（例：AWS Resource Access Managerを利用）。
- 参加アカウントが共有招待を受け取り、承認します。
- 承認後、参加アカウントは共有サブネット内のインスタンスやENIにそのセキュリティグループを割り当てられます。
制限と注意点
- 参加アカウントはルールの変更ができません。変更は必ず所有アカウントで行ってください。
- 共有は指定サブネット内のリソースに限定されます。別のサブネットやVPCには適用できません。
- 所有者が削除すると利用できなくなります。
運用のベストプラクティス
- 名前や説明に用途とバージョンを明記して分かりやすく管理してください。
- 変更履歴を残し、変更は所有アカウントで計画的に行ってください。
- ログや監査を有効にして誰がどのリソースに割り当てたかを追跡してください。
よくあるトラブルと対処
- 割り当てができない：共有が承認されているか、対象サブネットが正しいか確認してください。
- 想定どおり通信できない：インバウンド/アウトバウンドのルールとサブネットのルーティングを見直してください。
- 権限エラー：参加アカウント側での受け取り手続きやRAMの権限を確認してください。
AWS Cloud WANでのセキュリティグループ参照
概要
AWS Cloud WANの更新により、同じCloud WAN Core Network Edgeに接続された複数のVPC間で、セキュリティグループ（SG）を参照するインバウンドルールを作成できるようになりました。IPv4/IPv6アドレスを個別に書き込む必要がなく、動的でスケーラブルな設定を行えます。
何ができるか（イメージ）
- VPC AのWebサーバーがVPC BのDBにアクセスするとき、VPC B側のインバウンドルールでVPC AのSGを参照できます。
- 新しいサーバーをVPC Aに追加して同じSGに参加させれば、個別のIP更新は不要です。
主な利点
- アドレスのハードコーディングが不要で運用負荷が下がります。
- IPv4とIPv6の両方に対応でき、ネットワーク設計が柔軟になります。
- 大規模なマルチVPC環境でもルール管理が簡素化され、スケーラビリティが向上します。
注意点と運用のポイント
- 参照は同じCore Network Edgeに接続されたVPCに限定されます。設計時にどのEdgeに接続するかを整理してください。
- クロスアカウントで使う場合は権限や共有設定を確認してください。
- テスト環境で接続確認を行い、想定外の通信がないかログで監視してください。
- 名前付けやタグ付けを整備すると、どのSGを参照しているか追跡しやすくなります。
この機能は、VPC間の通信制御をより動的で管理しやすくする便利な手段です。慎重に設計し、ログや最小権限の原則と合わせて運用すると安全に活用できます。
セキュリティグループの実践的なユースケース
概要
セキュリティグループ参照機能は、VPCをまたいで安全に通信させるために便利です。IPアドレスを公開せずに特定のリソース間で接続を許可できます。以下に実務でよく使う具体例と注意点を挙げます。
主なユースケース
- Webサーバー → 別VPCのデータベース
- WebはパブリックIPを持たず、データベースはセキュリティグループ参照で許可します。通信は内部ネットワークで完結します。
- 共有サービス（Active Directory、認証基盤）への選択的アクセス
- 複数VPCからID管理サーバーへ限定的にアクセスを許可します。
- マイクロサービス間のセグメンテーション
- サービスごとにセキュリティグループを分け、最小権限で通信を制御します。
- 管理用アクセス（Bastion、バックアップ）
- 管理用インスタンスからのみ特定ポートを開放します。
実装のポイント
- セキュリティグループIDで参照を使い、IPベースのルールを避けると柔軟性が高まります。
- 名前付けとタグを整え、どの用途か明確にします。
ベストプラクティスと注意点
- 最小権限の原則を適用してください。
- トラフィックのログや接続テストで動作確認を行ってください。
- 相互参照でループや意図しない経路が生じないよう設計を確認してください。
