女性向けエンジニアスクール
3秒でわかる
AWS のサーバー 1 台ずつに付ける通信の許可リスト。どこから何番ポートへの接続を通すかを書き、書いていない通信は自動的に遮断されます。
もう少し詳しく
どういうものか
セキュリティグループは、EC2 インスタンスやロードバランサーなどに割り当てる仮想的なファイアウォールです。インバウンド (入ってくる通信) とアウトバウンド (出ていく通信) それぞれに、許可するルールを書きます。
大きな特徴が 2 つあります。1 つは許可しか書けないことで、拒否のルールは存在しません。書かれていないものはすべて遮断されます。もう 1 つはステートフルであることです。入ってきた通信への返信は、アウトバウンドに何も書かなくても自動的に通ります。
なぜ必要か
サーバーを立ち上げた直後は、公開したいポートも塞がっています。逆に言えば、うっかり全開放しない限り安全な状態から始められます。手作業の設定漏れで管理用ポートを世界中に晒す事故を防ぐため、通信の許可はサーバー内の設定ではなくクラウド側の設定として一元管理します。
具体例
sg-web (ロードバランサー用)
インバウンド 0.0.0.0/0 から TCP 443 を許可
sg-app (アプリサーバー用)
インバウンド sg-web から TCP 8080 を許可
※ IP ではなくセキュリティグループ ID を指定できる
sg-db (<a href="/glossary/database" class="text-primary font-medium underline underline-offset-2 hover:text-primary-dark">データベース</a>用)
インバウンド sg-app から TCP 3306 を許可送信元にセキュリティグループ ID を書けるのが実務上の要点です。アプリサーバーを増減させても IP を書き換える必要がなく、新しい台に sg-app を付ければそのままデータベースへ繋がります。
つまずきやすいところ
繋がらないときにセキュリティグループばかり疑ってしまうのが典型です。通信経路にはルートテーブル、ネットワーク ACL、サブネットの公開設定、そしてサーバー内の firewalld なども関わります。片方向だけ通らない場合は、拒否も書けてステートレスなネットワーク ACL 側が原因のことが多くあります。
もう 1 つは、動作確認のために 0.0.0.0/0 で 22 番を開け、そのまま忘れる運用です。数分でログイン試行が始まります。接続元は自分の IP か、踏み台サーバーのセキュリティグループに限定します。
運用のこつ
1 台ごとに個別のルールを書くのではなく、役割ごとにセキュリティグループを 1 つ作り、
サーバーには役割の分だけ割り当てます。1 台に複数割り当てると、許可は合算されます。
監視用の通信を全台に通したい場合も、監視用のグループを追加で付けるだけで済みます。
似た用語との違い
| 項目 | セキュリティグループ | ネットワーク ACL |
|---|---|---|
| 適用先 | サーバーなどの単位 | サブネットの単位 |
| ルール | 許可のみ | 許可と拒否 |
| 状態 | ステートフル | ステートレス |
覚え方
サブネットがフロア、セキュリティグループは部屋のドアに貼った入室許可者の名簿です。名簿に無い人は入れません。
