AWSのインフラ設計にあたって、セキュリティグループの設計は結構重要だと思うのですが、あまり意識して設計されていないケースも見受けられます。
メンテナンス性が考慮されていないと、後々かなり変更しづらくなりますし、誤って設定してしまい障害を発生させてしまうことも起こりえます。
そこで今回は一般的なWebシステム構成をベースにSecurityGroupの設定のポイントを紹介したいと思います。

環境

以下のようなWebシステムを前提に考えてみます。

※赤枠がアタッチするセキュリティグループになります。

基本的な設定ポイント

サービスのRole(役割)ごとにSecurityGroupを作成する

内部通信の許可はSourceにSecurityGroupを定義する(IPで定義しない。VPNやDXなどで外部と接続するようなケースはこの限りではないです)

管理用通信(ssh、監視)などは扱うグループ(開発者、インフラなど)ごとにSecurityGroupを分けて管理する。ただし、デフォルトで付与できるSGは5つまでなので分けすぎにも気をつけてください

具体的な設定内容は以下に記載します。
以下は全てInBound通信の設定となります。

サービスの役割ごとに応じたセキュリティグループ

ELB、Webサーバ、RDSがあるためそれぞれにセキュリティグループを作成します

ELB-SG(sg-elbsg)

Type Protocol Port Range Source Description
HTTP TCP 80 0.0.0.0/0 webアクセス用
HTTPS TCP 443 0.0.0.0/0 webアクセス用

WEB-SG(sg-websg)

Type Protocol Port Range Source Description
HTTP TCP 80 sg-elbsg elb→web通信用
HTTPS TCP 443 sg-elbsg elb→web通信用

※sourceにELBのセキュリティグループをセット

DB-SG(sg-dbsg)

Type Protocol Port Range Source Description
MYSQL/Aurora TCP 3306 sg-websg web→db通信用

※DBの種類に応じてポートは変更してください

管理用通信(ssh、監視)のセキュリティグループ

開発者とインフラ担当という想定で2つのセキュリティグループを作成しました。
ここは関係者に応じて作ってください。

DEV-SG(sg-devsg)

Type Protocol Port Range Source Description
SSH TCP 22 xxx.xxx.xxx.xxx/32
SSH TCP 22 xxx.xxx.xxx.xxx/32

INFRA-SG(sg-infrasg)

Type Protocol Port Range Source Description
SSH TCP 22 xxx.xxx.xxx.xxx/32
Custom TCP Rule TCP 1234 xxx.xxx.xxx.xxx/32 監視用

セキュリティグループについては送信元をIPではなくSGを指定することができます。
そうすることで通信経路が分かりやすくなるので、メンテナンス性も向上します。
また、例えばDBへの通信をWebサーバのIPで許可していたりすると、何かしらでIPが変更されたもしくはオートスケールでサーバが増えた際に、接続できなくなるトラブルも発生します。
こうしたことからもできるだけIPやCIDRで設定しない方向で設計してもらえればと思います。

また、OutBoundの通信の制限については、所属している組織のセキュリティポリシーにもよるかと思いますが、セキュアになる反面、トラブル時に原因が分かりにくくなる場合もあるのでその点を注意して使用するかどうかを判断してもらえればと思います。

元記事はこちら

SecurityGroup設定のポイント